QuickTime playback framerate artifacts

Posted by dcouzin 
Re: QuickTime playback framerate artifacts
February 11, 2011 07:43PM
I'm not sure why you do this, d - you're driving yourself crazy with minutiae. Photographing the screen at high speed? Is your output for some extremely high precision science project? I think everyone has already said that your equipment is not capable of what you're requiring of it.

I don't say this to be nasty, although I realise it's hard to prove that in text like this. I just wonder why you ask how to do things in a very difficult way, when there is often already a much simpler solution.

Re: QuickTime playback framerate artifacts
February 11, 2011 09:00PM
Jude, high speed photography? There is no high speed photography suggested. That would require specialized equipment. I'm setting out a method which anyone who owns a digital still camera (with adjustable shutter) and who can make a simple test video, can use to check whether a monitor or projected display is frame-accurate 60p. The method can be modified for other frame rates.

Minutiae? Every method must have a few details. Do you think buying and operating "professional" expensive test equipment involves no details? I tried to keep details to a minimum in the method. If you know a "much simpler solution" for verifying that a monitor or projector is displaying unartifacted 60p, please tell.

Actually no one else in the strand has suggested any method for analyzing the displayed image itself. I think it is essential to be able to verify that what you see is really 60p, etc. I've encountered projections that looked a little wrong, frame-accuracy-wise, and the experienced projectionist sitting next to me didn't agree. You can't just trust the eyes. You need to be able to verify the displayed image.

There are two approaches to quality display. One is to have very expensive over-spec'd components and then trust that the display must be right. For sure? The other is to have modest components and then verify that the display is right. Hopefully it is, but if not then there is the messy task of tracking down the causes. In this strand, several technical experts have made suggestions about causes. The post of mine that you questioned was not about the causes of frame inaccurate display but about detecting it.

Dennis Couzin
Berlin, Germany
Re: QuickTime playback framerate artifacts
February 12, 2011 01:57AM
OK. You took offence. Sorry. I think you know what the answer is here though. Don't use non-critical equipment if your output is critical. It's not about trusting, it's about knowing because thats what you paid for, and that's what has to be supplied, or it's false advertising.

Is your output critical? Does the producer / end user care about this / will they notice? If no, then you don't need to spend more money.


Re: QuickTime playback framerate artifacts
February 12, 2011 04:38AM
>does the I/O card bypass the graphics card and send what FCP reads directly to the
>monitor

Yes. The graphics card will NOT send a y'cbcr signal from a y'cbcr source. A capture card does just that over an HD-SDI signal. For 1080p50/60, you will need a 3G SDI connection, which is available with the AJA Kona 3G/LHi and the BMD Decklink Extreme 3D. You will also need a good calibrated broadcast monitor. FSI has been mentioned pretty often and they have a monitor that supports 1080p60 as an option. A broadcast monitoring set-up is designed to show your picture without introducing artifacts into the image.

Basically the equipment you are using for monitoring was never designed for frame accurate or color accurate monitoring. Heck, you aren't even monitoring in the proper color space. What you are using is a general purpose computer monitor, with a general purpose graphics card, from a monitoring route that was never recommended for critical monitoring. If you require professional monitoring, then you need to purchase professional gear.



www.strypesinpost.com
Re: QuickTime playback framerate artifacts
February 12, 2011 05:56PM
>One is to have very expensive over-spec'd components and then trust that the display must be right.
>For sure? The other is to have modest components and then verify that the display is right.

What D-Mac and I have been trying to say is that your components are not qualified for critical monitoring. To try to get it to work without qualified components means you end up banging your head repeatedly against a brick wall.



www.strypesinpost.com
Re: QuickTime playback framerate artifacts
February 12, 2011 06:28PM
Quote
strypes
The graphics card will NOT send a y'cbcr signal from a y'cbcr source. A capture card does just that over an HD-SDI signal.
Yes the .mov file is usually in Y'CbCr and the graphics card converts this to a RGB signal. But the monitor (or projector) itself is RGB. So at some point the Y'CbCr must be transformed to R'G'B' and finally to RGB. As you describe it, the capture card is doing nothing color-wise, and leaving the necessary transformations to the monitor. The color transformations follow simple equations. Can't a graphics card do them as well?

Dennis Couzin
Berlin, Germany
Re: QuickTime playback framerate artifacts
February 12, 2011 07:45PM
Y'CbCr is not a colour space, really. It's a way of encoding RGB information.

Re: QuickTime playback framerate artifacts
February 12, 2011 08:02PM
I always thought RGB was a way of encoding YCbCr video for a computer.

Never mind.

All the best,

Tom
Re: QuickTime playback framerate artifacts
February 12, 2011 08:08PM
Yes. No. You technically cannot view y'cbcr as that needs to be transformed into rgb primaries for display. The FSI monitors have built in LUTs to do the conversion between certain color profiles accurately.



www.strypesinpost.com
Re: QuickTime playback framerate artifacts
February 12, 2011 10:14PM
Quote
Jude Cotter
Y'CbCr is not a colour space, really. It's a way of encoding RGB information.

Y'CbCr is a color space, really. Look at L*a*b*, which the CIE (for heaven's sake) calls a color space. Y'CbCr strongly resembles L*a*b*. (Some differences are described on pages 6-8 of this primer). Sure there are equations for encoding RGB into Y'CbCr, but there are also equations for encoding X,Y,Z into Y'CbCr, etc., etc. One color space can be mathematically transformed to another color space just as one kind of map of the world can be mathematically transformed into another kind. A color space is a 3-dimensional arrangement (map) of some or all of the possible colors.

Incidentally, the color encoding employed between the retina and the brain, and some (not I) believe it to correspond to the color space used by the brain is similar to Y'CbCr. Though dated (pre-digital) the bible on the subject remains Hunt's "The Reproduction of Colour."

Dennis Couzin
Berlin, Germany
Re: QuickTime playback framerate artifacts
February 12, 2011 11:17PM
Quote
strypes
Yes. No. You technically cannot view y'cbcr as that needs to be transformed into rgb primaries for display. The FSI monitors have built in LUTs to do the conversion between certain color profiles accurately.

I understand the Yes, but am unsure what the No is for. Are ICC profiles based on equations instead of lookup tables? Does this make ICC profiles too slow to accomplish conversion between color profiles for real time video display with sufficient accuracy? There's software around for converting LUTs to ICC profiles, so the ICC equations are in a sense sufficient, but this software being used for Photoshop where there's lots of time.

The FSI 17" monitor is pretty cheap but the 1080/60p option almost doubles the price. So this must all be about processing speed limitations. What about doing critical color viewing without full pixel count or full frame rate? Then what about doing it with even fewer pixels or fewer frames per second on a garden variety LCD monitor plus a good instrument-assisted ICC profile.

Dennis Couzin
Berlin, Germany
Re: QuickTime playback framerate artifacts
February 13, 2011 01:16AM
>What about doing critical color viewing without full pixel count or full frame rate?

If you have an HD source going out for an SD master, you can monitor in SD. Ideally you want to monitor at least in the full delivery resolution and frame rate, so you know when to stop pushing the image. Erratic frame rate means you can't gauge the amount of noise, lower resolution means you can't tell when to stop pushing the image.

I don't know about getting ICC profiles and LUTs to work on a computer display and if you can get the display to show full and accurate 709 gamut. Is the monitor even capable of it? Also, is QuickTime able to accurately map color spaces? I have a cheap Samsung monitor and I can't calibrate it to resemble an H-IPS display in the same color space, much less a broadcast monitor. Last time I tried working on a non broadcast monitor (don't ask, but there are houses who are too cheap to buy a broadcast monitor), my colors were off by a mile and a half when I was going out to tape at the tape facility. One shot out of five looked like what I color corrected. It was a nightmare.

So yes, you can buy engineered equipment and put them through QC, or you can go cheap and end up with low quality output.



www.strypesinpost.com
Re: QuickTime playback framerate artifacts
February 13, 2011 05:23AM
OK. I'm out of this one. You clearly have an agenda to push and won't listen to anyone else. You have a car. Putting wings on it won't make it fly.

Y'CbCr is not an absolute colour space. But whatever. Go with your own thing if you need to.

Re: QuickTime playback framerate artifacts
February 13, 2011 03:47PM
strypes, I get your point, that critical color viewing involves viewing more than color, for example, noise.

I also agree that there may be gamut limitations with cheap monitors. In order to be brighter they choose more efficient primaries, reducing the triangle size. But I'm surprised that the color reproduction well away from the boundary can't be profiled to near perfection. Color science predicts that the RGB with one set of primaries can be converted to RGB with any other set of primaries (at least for one observer).

Dennis Couzin
Berlin, Germany
Re: QuickTime playback framerate artifacts
February 14, 2011 07:49AM
Quote
Jude Cotter
Y'CbCr is not a colour space, really. It's a way of encoding RGB information.
Quote
Jude Cotter
Y'CbCr is not an absolute colour space. But whatever.

Absolute Schmabsolute! RGB isn't an absolute color space either. Its primaries must be specified to make it absolute. But once that's done Y'CbCr is made an absolute color space via the BT.709 inverse transforms (or whatever) and some specified R'G'B'->RGB transform (which can be as simple as specifying the gamma).

Since almost everyone who edits video works in a Y'CbCr color space, it's worthwhile to understand these color spaces. An outstanding feature is that, unlike RGB which has a limited triangular chromaticity gamut, Y'CbCr color space (with enough bit depth) includes the complete chromaticity gamut and even includes impossible colors. (See page 1 of the primer.) Broadcast safe filters constrain Y'CbCr to the RGB triangle, but as a color space, Y'CbCr can have weaker constraint than that.

Dennis Couzin
Berlin, Germany
Re: QuickTime playback framerate artifacts
February 14, 2011 09:26AM
Be nice, dcouzin. And it would be great if you post your queries on the forum instead of pm or email so every gets to learn.

Video editing suites have transitionally relied on a properly calibrated broadcast monitor. This is because computer screens have been far from accurate. They have never been designed as accurate broadcast monitors to start with. At best they only approximate a broadcast display. Is there a substitute for an IO card for monitoring? No, not if you care about the quality of your work. They aren't very pricey either. A decklink can costs only $295. Of course, it won't do 1080p60 monitoring, but you get what you pay for.



www.strypesinpost.com
Re: QuickTime playback framerate artifacts
February 16, 2011 06:54AM
Quote
strypes
Also, is QuickTime able to accurately map color spaces? I have a cheap Samsung monitor and I can't calibrate it to resemble an H-IPS display in the same color space, much less a broadcast monitor. Last time I tried working on a non broadcast monitor (don't ask, but there are houses who are too cheap to buy a broadcast monitor), my colors were off by a mile and a half when I was going out to tape at the tape facility.

It is unlikely that the (non-broadcast) monitor itself is so bad as to have to be so far off. strypes' first question points to a key problem.

Usual monitor calibrations are RGB->RGB maps designed to give correct XYZ in the display. For example, the Datacolor Spyder3Elite monitor calibrator allows you to select the BT.709 aims. So if the monitor's primaries are different from the BT.709 primaries this device can make an ICC profile which corrects this. (I don't know what it does about deficient gamut.) However BT.709 also specifies how the Y'CbCr of the video is to be transformed to R'G'B' and then to RGB. The Spyder3Elite monitor calibrator bypasses the first step, which QuickTime may be doing incorrectly. QuickTime might do second step too, and incorrectly. So the result may be colors on this supposedly BT.709 calibrated (non-broadcast) monitor that are way off BT.709 when the video is played with QuickTime.

A different approach, with the player in the loop, is needed for calibrating a (non-broadcast) monitor for playing video to BT.709 specs. I think the safest course is to have the color test patterns in files for various codecs (and perhaps even various formats). Then play these files and read the XYZs off the display. Then produce different ICC profiles for different players with different codecs. I'm asking Datacolor their opinion on this.

Photographers, just as fussy about color as videographers, are generally satisfied by well-calibrated simple monitors. That's a reason to doubt that the (non-broadcast) monitor is itself strypes' culprit. I think the "different approach" sketched above can yield ICC profiles that decently fix the color errors. Whether the computer system can employ a very complex ICC profile while playing 1080 /60p video is another question.

Dennis Couzin
Berlin, Germany
Re: QuickTime playback framerate artifacts
February 16, 2011 12:36PM
Have you actually tried using the Apple monitor calibration on a low end monitor? Although in theory, you calibrate the hue at different shades of grey, and if you do it properly, you may get a relatively neutral image, but when put it next to an Apple cinema display that was also calibrated the same way, you realize that both pictures are off. Not by a lot, but enough for you to think twice about using both monitors side by side. Will a Spyder make any difference? I doubt so. The HP Dreamcolor makes quite a pretty picture, and it has built in LUTs and a separate probe for calibration, but it is a bit fussy about the signal. But that's color, then there is frame rate accuracy and as you mentioned, you need to pull off the calculation in time to run a video stream smoothly through it. Monitoring gear has never been cheap.



www.strypesinpost.com
Re: QuickTime playback framerate artifacts
February 16, 2011 01:50PM
strypes, I think the Apple monitor calibration can true up gain curves and yield neutrals, but it can't possibly correct for the hue shifts resulting from two monitors having different primaries. Nowhere in the Apple procedure do you decide "I want that green not that other green", etc. An instrument-aided calibration, aimed at standards, should be able to make those decisions and a color profile should be able to make the corrections. (As discussed, there are additional problems involving the video player.)

Dennis Couzin
Berlin, Germany
Re: QuickTime playback framerate artifacts
February 16, 2011 02:19PM
dcouzin,

For all of your reading on this general subject, you mentioned but dismissed some key points.

If a monitor (pretty much all of them under $1000, or even more) can't display a full gamut for video, then nothing you do will make it do so. And, cheaper monitors can't accurately reproduce colors even within a limited/reduced color gamut, regardless of the calibration tools used. Then, in-monitor processing speeds (separate from response rate), and other considerations make cheaper monitors a poor choice. If a monitor can't properly represent the full required color gamut, the primary colors, black point, and white point won't likely be well-represented, either. Again, no display connected via DVI/DisplayPort to a computer GPU is really intended to adequately work as a true video display, marketing double-speak notwithstanding. It's that simple.

I mentioned a good article that describes the entire processing chain involved with displaying video. Your continued comments indicate that you didn't really read or fully understand that article, as you have been hung up on the end of the chain (the actual monitor). Your measurement technique is probably also invalid. To sample a video signal being displayed on a monitor (at a given frame rate), you need to consider the Nyquist frequency for proper signal resolution, and use a sufficiently long enough sampling to yield a valid set of samples. So, roughly speaking, to capture 60 fps video, you'd need to sample (take pictures, or whatever) at least twice as often, over a "long enough" time period. Of course, this is all moot when discussing a computer display connected to a computer.

A big performance bottleneck in OS X (and likely Windows, as well), is the CMM (ColorSync engine for OS X) and the processing involved with changing color spaces, profile conversions, etc. This doesn't impact still image processing, but greatly influences video going through this subsystem (and other "graphical" parts of the OS). Dedicated video I/O cards bypass this "mess" by taking video signals directly from compatible applications and sending it to an external monitor.

While the Dreamcolor displays (and some NEC models) do provide adequate color gamuts for use with video, the entire processing chain is still not designed to provide accurate color and frame playback via a computer graphics interface.

Also, even with the Dreamcolor connected via a video I/O card, it still requires a Gefen, or other, converter to properly display video (the Dreamcolor cannot properly deinterlace an interlaced signal and doesn't convert Y'CbCr signals, as it only expects RGB). There is a white paper on the HP website that explains this ("Using the HP DreamColor LP2480zx Monitor for Professional Video Applications"winking smiley.

Are cheaper computer displays good enough? Even with adequate CPU, GPU, and disk speeds, I'd say "no" for any real professional, or high quality, use.

Editing systems used to cost into the $100K range before FCP showed up. Now, people complain about spending about $5K to $10K for a decent color and frame accurate setup to add to the computer and FCS software. This isn't elitism, it is just the way it is (and quite cheap, relatively speaking). If an adequate and cheaper solution existed, you'd know about it, most likely.

All of the professional photographers I know, who use computers as part of their workflow, are using Eizo and other similar quality monitors. The Apple Cinema display monitors used to be certified for use in digital (photographic) color workflows, but none of the recent "glossy" monitors have any sort of certifications (except for energy and recycling related features).

I personally couldn't tell a client that I was able to do proper color correction work without having a valid setup. But, a lot of people do. To me, the cost of HW is quite reasonable, if not cheap, if you are really working as a professional and charging fair rates.

Sorry for the commentary, but this thread has spun out of control and way off topic. You have even provided clear answers to some of your original questions, seemingly without realizing it. This stuff is pretty clear cut. If want to accurately monitor video projects, you need the proper gear. You can't cheat "physics."
winking smiley


-Dave
Re: QuickTime playback framerate artifacts
February 16, 2011 08:24PM
Quote
D-Mac
You can't cheat "physics."

Agree.

Quote
D-Mac
Your measurement technique is probably also invalid. To sample a video signal being displayed on a monitor (at a given frame rate), you need to consider the Nyquist frequency for proper signal resolution, and use a sufficiently long enough sampling to yield a valid set of samples.

Nyquist's theorem pertains to the instantaneous sampling of an analog function. It is irrelevant to the 60 Hz (fV) under discussion. The actual analog signal underlying the time change from one frame to the next is in MHz range. Consider that the huge amount happens between the display of one pixel and the next display of that pixel. So the time demarcations are very sharp, electronically, from frame to frame at one place on the display. Frame to frame is what my measurement technique examines. Whether the time demarcations are sharp optically depends on the physics of the display and is the purpose of the 3b measurement in the technique.

Quote
D-Mac
...you have been hung up on the end of the chain (the actual monitor).

As explained in a previous post, I think it is essential to be able to verify that what you see is really 60p, etc. The technique using a still camera is a verification techique. If we're going to form accurate opinions about how video looks depending frame rates, then we should take pains to verify the display.

Quote
D-Mac
I mentioned a good article that describes the entire processing chain involved with displaying video. Your continued comments indicate that you didn't really read or fully understand that article.

Do you mean Why software genlock at 60 FPS does matter! or Frame Rate? I responded to what I found missing from the first paper in a post to which you responded approvingly.

Video rests on a mountain of engineering. "Engineer" is an interesting word with a double etymology. It comes from "engine". It comes from "ingenuity". I try my best.

Dennis Couzin
Berlin, Germany
Re: QuickTime playback framerate artifacts
February 16, 2011 08:52PM
I may have been a little lax in my Nyquist statement, but the idea behind it still applies. Taking photos as you did is almost certainly not a valid way to test the display performance. Signal scopes, and other test equipment, are the proper way to do it.


Quote
dcouzin
As explained in a previous post, I think it is essential to be able to verify that what you see is really 60p, etc. The technique using a still camera is a verification techique. If we're going to form accurate opinions about how video looks depending frame rates, then we should take pains to verify the display.

I disagree. It isn't essential to verify this kind of setup because it is explicitly not designed to be accurate. You keep missing this essential point.

Testing a computer display connected via normal computer connections is not a valid setup, so testing is meaningless.

Outside of the limitations of the article I referenced, there is a lot of stuff happening before a signal even goes out to the monitor.

To test only the monitor, you need to have a verified signal going into the monitor and a valid way to test its display. But, whether or not your idea of testing is valid doesn't matter, because you are attempting to analyze the monitor itself without knowledge of the exact signal going into it. It isn't a monitor on a bench being fed a known and verified signal. It is a device at the end of the processing chain.

I'm sorry if I slightly misspoke in a few of my statements (I was trying to avoid as much overly technical info as possible, while remaining accurate in a broad sense). But, the fact of the matter is that doing your "tests" is a waste of time. Why test a system that isn't designed to do what you think it should?

Now, if you were properly testing the outputs of a video I/O card and a proper broadcast monitor, separately, and without the system involved, then that would be a valid test. That's why these things are produced. And, to test portions of the processing chain in the computer, prior to the GPU, you'd have to use tools that can isolate each step of the process. For a video I/O card, FCP sends it actual values from the video file. No influence from ColorSync CMM, Core Video, etc.

-----

Again, there is no reason to test a setup consisting of a computer monitor and a computer, connected via DVI/DisplayPort. That setup just isn't designed to provide accurate color, frame rate, etc. video.

If you really care about quality, you will buy a video I/O card from AJA, Blackmagic Design, Matrox, etc. and an external broadcast monitor, then do a proper calibration. That's it. It's simple. And, if you're really picky, you can buy very expensive test equipment to verify that the gear is working properly.

Anyway, I am done with this discussion...
winking smiley


-Dave
Re: QuickTime playback framerate artifacts
February 16, 2011 10:42PM
Quote
D-Mac
To test only the monitor, you need to have a verified signal going into the monitor and a valid way to test its display.

You're absolutely right that to test only the monitor you must start with a "verified signal".

I'm sorry if I induced misunderstanding by sometimes saying I'm verifying the display. I should have said I'm verifying the display of the video. I'm interested in the relation between (A) the frames in the video file and (B) the frames appearing in the display. The procedure starts with a test clip of a moving dash and relates it to snapshots of the display. That is the verification intended.

Even with the best of equipment and with each link of the chain verified, it is wise to verify the process whole: (A) to (B).

Dennis Couzin
Berlin, Germany
Re: QuickTime playback framerate artifacts
February 28, 2011 05:42PM
Quote
strypes
I don't know about getting ICC profiles and LUTs to work on a computer display and if you can get the display to show full and accurate 709 gamut.
Quote
D-Mac
If a monitor (pretty much all of them under $1000, or even more) can't display a full gamut for video, then nothing you do will make it do so.

I used the excellent Spyder3Elite tool to measure the primaries of my Samsung 305T monitor. This picture shows the comparison with BT.709. Indeed there is gamut failure at the blue corner. It might look insignificant in this CIE diagram, but the eye is highly sensitive to hue difference in that corner.

Dennis Couzin
Berlin, Germany
Sorry, only registered users may post in this forum.

Click here to login

 


Google
  Web lafcpug.org

Web Hosting by HermosawaveHermosawave Internet


Recycle computers and electronics