QuickTime Working at 50/100 Mbps 4:2:2

[Mike Schell]

Originally Posted by Ronan Fournier

It looks good on my MacPro, thank you!
However I look forward for a comparaison with the same shot in HDV or XDCAM EX and the Flash XDR@100MB/s.
If you could shoot some clips in outdoor, in both formats, with more complexe pictures (leaves on tree for example) and pan and travelling, that would be really great. Because movements are the weak point of HDV… so we would better be able to appreciate the improvement of the Flash XDR, I think.

Hi Roman-
Thanks for the suggestion, we do plan to make these comparisons. We can actually feed the same HD-SDI signal to multiple XDRs set at these various compression levels. We can also record to the native HDV tape and to the XDR simultaneously.

We have already arranged for a local user to shoot this exact type of scenery. Hopefully we can post footage in the next week or so.

[David Taylor]

FYI for those interested in a CineForm editing workflow, we've tested XDR MOV files on Mac and they convert fine to CineForm files through either QT Player or FCP (FCP v6.0.3 or higher). If going this route we'd recommend FCP (not QT Player) because they'll convert into 10-bit CineForm files (QTP is 8 bits only).

Also...and this is a heads up to this group...we'll finally have a native CineForm converter for Mac in beta in a week or so, and we should be able to convert the XDR files directly without going through QT Player or FCP.

Finally, we haven't yet tested the MXF version of XDR files, but by their description (from Mike) we should be able to convert those files as soon as they're released.

[Mike Schell]

Originally Posted by David Taylor

FYI for those interested in a CineForm editing workflow, we've tested XDR MOV files on Mac and they convert fine to CineForm files through either QT Player or FCP (FCP v6.0.3 or higher). If going this route we'd recommend FCP (not QT Player) because they'll convert into 10-bit CineForm files (QTP is 8 bits only).

Also...and this is a heads up to this group...we'll finally have a native CineForm converter for Mac in beta in a week or so, and we should be able to convert the XDR files directly without going through QT Player or FCP.

Finally, we haven't yet tested the MXF version of XDR files, but by their description (from Mike) we should be able to convert those files as soon as they're released.

Hi David-
Thank you. This great news! I am sure users will be able to simply convert the MPEG2 files directly from the Compact Flash cards (via a FW-800 CF reader) and then keep the CF cards as a temporary backup.

I know that Cineform is an outstanding CODEC and that this transcode will not introduce any perceptible loss of quality.

As soon as we have the MXF format complete, I will forward some test files.

[Steve Phillipps]

Worked fine on my Mac.
Lot of interlace artefacts, not relevant I suppose.
Doesn't really show much as there's very little motion in there, so would need to be panning or a moving subject, and also need to do side-by-side with other codecs. I would be very interested in seeing the difference between say a 50 mb/sec long GOP and a 160 mb/sec I frame on a moving target.
Steve

[Mike Schell]

Originally Posted by Steve Phillipps

Worked fine on my Mac.
Lot of interlace artefacts, not relevant I suppose.
Doesn't really show much as there's very little motion in there, so would need to be panning or a moving subject, and also need to do side-by-side with other codecs. I would be very interested in seeing the difference between say a 50 mb/sec long GOP and a 160 mb/sec I frame on a moving target.
Steve

Hi Steve-
Thanks for the feedback. Our primary intent of the file was to demonstrate our ability to generate correct QuickTime files. That said, we do plan more shots in the coming weeks with some panning and high-motion, highly complex scenes at various bit-rates.

I too am most interested in the comparison of 100 Mbps Long-GOP and 160 Mbps I-Frame, especially during panning. My bet is that the Long-GOP format will hold up surprisingly well, especially at the 100 Mbps level.

[Thomas Smet]

The 100 mbits long form could in theory actually look a bit better then the 160 I frame version. Long form needs enough bits to look good and once you get to a certain level it really will start to look near perfect.

The max quality level for mpeg2 HD at 4:2:0 long form is 80 mbits/s. This is a pretty darn perfect level of quality. Of course 4:2:2 needs more bits then that which is why 100 mbits should help fill that need.

160 mbits I frame on the other hand is only half the max level for that type of mpeg2. The max bitrate for I frame only mpeg2 is 300 mbits/s so really the I frame only video from the XDR is at half the max level of quality. If you can think of SD IMX material shot at 25 mbits/s instead of the max 50 mbits/s. Of course the mid level still looks awesome even compared to DVCPROHD and HDCAM but it isn't at the top level. I frame only also tends to waste bits so if you are shooting an interview your scene could have maybe used 100 mbits and it would have still had the exact same level of quality. The IPB format with close to the highest level of bits it could handle means the frames that need it get the extra boost while the simple frames save the bits.

The 100 mbit long form is IPB based so may not seek as fast but it shares the bits much better giving an overall level of image quality in theory. I say in theory because all encoders are different but that is usually the general rule of thumb. I also say in theory because mpeg2 is a funny little creature that never sits in one place. Nobody can really predict exactly how something is going to look with mpeg2 because of he way it calculates it's bits based on the image and scene. One video clip encoded at a certain rate is going to have a different look then another video clip encoded at that exact same rate. What we can do however you use best guess estimates to figure out roughly how the bitrate ratios will work out.

What I am trying to say here is that 100 mbits IPB would sort of look more like I frame only at 300 mbits which is almost double the quality level of the 160 mbit mode. At the same time however it starts to get pretty rare to have a scene that usually ever needs more then 200 mbits/s so it is going to be super super hard for most people to be able to tell with sample shots. You would really need a certain hardcore benchmark type of a shot to really strain mpeg2 to the level where these extreme bitrates really make a difference. No posted shot is going to show a night and day difference. Thats the beauty of mpeg2 and why it really is such an awesome format.

[Ray Bell]

This is good news that Cineform is on top of the implimentation of the XDR/Nano...

This way you get to open the compressed files even further....

[Robert C. Fisher]

David I have a question. Will your converter use every core available. I think thisis called multi-thredding. Most apps including compressor don't make full use of all of the cores, compressor does allow you to make it think it's using more machines to make use of all of the cores available. I acctually found this out a few months ago. Any way this would speed up the conversion considerably if it fully utilizes all available cores.

Does this make sense?

Cheers
Robert C. Fisher

[Steve Phillipps]

Thomas, does what you're saying hold true for moving subjects too? I assumed that long GOP was always at a disadvantage as it's "guessing" some of the frames. Appreciate your expertise.
Steve

[David Heath]

Originally Posted by Steve Phillipps

I assumed that long GOP was always at a disadvantage as it's "guessing" some of the frames.

Up to a point, but the higher the bitrate gets, the less "guesswork" to be done until eventually there's no guessing - the compression is increasingly utilising true redundancy in the signal, rather than throwing information away.

At that point, the decoded output will be indistinguishable from uncompressed - and the bitrate will vary with the scene and codec used. Quality wise, long GOP will be at an advantage compared to I-frame only at a given bitrate - but at a disadvantage when you consider processing power required.

Basically it's a three way trade - quality, bitrate, and processing power. Long GOP trades the latter to gain improvements in one or both of the former.

[Dean Harrington]

Originally Posted by David Taylor

FYI for those interested in a CineForm editing workflow, we've tested XDR MOV files on Mac and they convert fine to CineForm files through either QT Player or FCP (FCP v6.0.3 or higher). If going this route we'd recommend FCP (not QT Player) because they'll convert into 10-bit CineForm files (QTP is 8 bits only).

Also...and this is a heads up to this group...we'll finally have a native CineForm converter for Mac in beta in a week or so, and we should be able to convert the XDR files directly without going through QT Player or FCP.

Finally, we haven't yet tested the MXF version of XDR files, but by their description (from Mike) we should be able to convert those files as soon as they're released.

David~ which of the mac related cineform programs will this cover? Prospect HD and/or Neo HD? Which format will the Cineform converter convert to other than QT and FCP? I guess I'm wondering whether we need to use cineform programs for this converter?
... it appears that Neo HD is the route to go with 4.2.2 10 bit.

[Mike Schell]

Originally Posted by David Heath

Up to a point, but the higher the bitrate gets, the less "guesswork" to be done until eventually there's no guessing - the compression is increasingly utilising true redundancy in the signal, rather than throwing information away.

At that point, the decoded output will be indistinguishable from uncompressed - and the bitrate will vary with the scene and codec used. Quality wise, long GOP will be at an advantage compared to I-frame only at a given bitrate - but at a disadvantage when you consider processing power required.

Basically it's a three way trade - quality, bitrate, and processing power. Long GOP trades the latter to gain improvements in one or both of the former.

Hi David-
Just for clarification, the added processing power you describe is only incurred during the compression (or recording) and not during decompression (or playback). MPEG is an asymmetrical algorithm, in that it requires 3x to 4X the processing power to compress the video as compared to decompression. I-Frame only CODECs (ProRes, DVCProHD, AVC-I, DNxHD, etc) on the other hand tend to be symmetrical in nature, requiring about the same processing power for either compress or de-compress operation.

So, while high-quality MPEG compression does require considerably CPU power, MPEG decompression (or playback) is a relatively light load, even compared to I-Frame only CODECs. That's why 100 Mbps MPEG is about the same processor load as 50 Mbps (on playback).

So, aside from the extra storage requirement, there is no downside to using the 100 Mbps recording in terms of everyday editing performance. Our MPEG2 CODEC (made by Sony) can happily create very high-quality MPEG2 at 100 Mbps 4:2:2 all day long. This module has the extra processing power to handle the complex scenes.

Our experience has shown almost no problems with panning or high-motion shots when the bit-rate is increased to 100 Mbps. Sony's our CODEC quality charts show this 100 Mbps Long-GOP format to be above HDCAM and just below HDCAM SR.

[John Richard]

One thing to keep in mind is that with the current QT/XDR combo, you cannot playback the shots/files directly from the XDR to a monitor.

Dummy me; it states this directly in the Release Notes.

Updated the XDR firmware to the recent QT beta; shot some footage/files; tried to play them back as we had been thru HD-SDI from XDR to Panasonic BTH1700 and spent an hour trying to figure out what was wrong before re-reading the Release Notes.

[Mike Schell]

Originally Posted by John Richard

One thing to keep in mind is that with the current QT/XDR combo, you cannot playback the shots/files directly from the XDR to a monitor.

Dummy me; it states this directly in the Release Notes.

Updated the XDR firmware to the recent QT beta; shot some footage/files; tried to play them back as we had been thur HD-SDI from XDR to Panasonic BTH1700 and spent an hour trying to figure out what was wrong before re-reading the Release Notes.

Hi John-
We should have a firmware update very soon. We are testing the 1080psf code now and Brent is working on a menu update. QT playback should be available next week.