Noise comparison: 35/4:2:0 vs. 180/4:2:2

[Dan Keaton]

Dear Friends,

This is from Piotr's post (I added the item numbers):

1 - 18 Mbps (LP mode, VBR used to ensure maximum recording times)
2 - 25 Mbps (SP mode, CBR used to ensure compatibility with HDV)
3 - 35 Mbps (HQ mode, VBR used to ensure maximum quality)
4 - 50 Mbps (4:2:2 mode, CBR used to ensure compatibility with the legacy HD422 format)

Items 1 & 2 are XDCam HD. We do Item 1, we do not do Item 2, as far as I know, as we do not support 25 Mbps.
(Note, this is not XDCam, or XDCAM HD422.)

Item 3 is XDCam EX and we do this item, and it is VBR.

Item 4 is XDCAM, or XDCAM HD422, but it is not XDCam HD. We use this codec for 50 Mbps and higher, 4:2:2, CBR.

Our I-Frame Only also uses the codec in Item 4, but we put out only I-Frames.
Sony does not have an I-Frame Only option in their current cameras, as far as I know.

I feel confident that we have the technical ability to turn on VBR in our 50 Mbps and higher 4:2:2 modes.

But, there is a price to pay.

We either have to prove that this VBR mode is acceptable to all NLE's and this becomes our standard, or have to support both CBR and VBR.

If we have to have both, then this adds a level of complexity and an opportunity for someone to create a file that will not work with their editor.

And, not everyone knows which NLE will be used when the files are recorded.

If we need to have both, then it will take us substantially longer to test each new release as we would be almost doubling the testing that we do before each release.

This quality control testing takes one employee, running many nanoFlashes simultaneously, about two weeks or longer to test each and every variation that we have now.

Each file type, each bit-rate, each variation is recorded, then individually tested in each of the professional NLE's.

Multiply 2 (MOV and MXF) by the different frame rates we support, (23.976, 24 25, 2997, 30, 50, 59.94, and 60), by the number of codec type / bit-rate variations (I-Frame Only, 100, 140, 180, 220, 280, plus Long-GOP 18,35,50,80,100,140,180), and you get the number of files that we have to create for testing (approximately).

Then add the testing for all of the bit-rates, etc. for MPG mode.

Then take each appropriate file and test it in the various NLE's.
(For Avid we need to only test some of the Long-GOP files).

Now, when we find a problem, we fix the problem in our code, then start testing every option over again.

Thus, at this time, we want to concentrate on the other features that have been requested.

Please remember that the nanoFlash is an extremely versatile device. No camera, or device that I know of offers as many recording options / flavors / bit-rates, frame rates, etc.

I hope this explains fairly why we need to concentrate on the other features that we have promised.

[Rafael Amador]

Dear Dan,
As I said before somewhere, for me VBR makes no sense when Data Rate is not an issue.
VBR makes sense when you have to put 3 hours MPEG-2 in a DVD.rafael

[Tim Polster]

I have been losely following the thread since its beginning. Nothing wrong with trying to learn and improve.

I do wonder about this proposal to move the VBR long GOP recording. Has anybody measured how much better, I mean noticeably better for all of the hassle it would take for CD to add it?

Or is a spec improvement that would improve the 200% freeze frame blowups?

Because unless there is a visual improvement there is no point in following this path imho.

[Dan Keaton]

Dear Rafael and Tim,

I agree with both of your comments.

At high bit-rates I do not expect much of a difference.
(But, unless we test it, we do not actually know, and I think that would be Piotr's position, which is valid.)

At SD DVD bit rates, it could make a difference, in my opinon.
(But so far, we have not been including our MPG recording in these discussions)
And I do not know if our MPG is VBR or CBR at this moment. I am checking on this.

[Dan Keaton]

Dear Friends,

Currently, our MPG files are CBR.

In our upcoming release, our next firmware release, they will be VBR.

[Gints Klimanis]

Originally Posted by Rafael Amador

VBR makes sense when you have to put 3 hours MPEG-2 in a DVD.rafael

Currently, the quality fluctuation at bitrates of 100 Mbps and higher generates MPEG-2 Long GOP footage with a quality flaw due to the large differences between the I-Frame and P-frame, though I notice this quality jump nearly every six frames in Sony Vegas (100 or 140 Mbps). Other user comments along the lines of "I-Frame Only at 220-280 Mbps looks cleaner" indicate other users may notice the quality drop and or variation.

If VBR mode allows for specifying a constant quality per frame even if the bitrate varies and increases somewhat, VBR is not only sensible but critical to the quality of the Nano output files. Right now, I'm find that I need to record I-Frame only 220 Mbps to achieve a quality that should be available at LongGOP bitrates at half that rate.

[Gints Klimanis]

Originally Posted by Dan Keaton

Currently, our MPG files are CBR.

In our upcoming release, our next firmware release, they will be VBR.

Excellent news, though I'd prefer this in a user-programmable option. Is there a quality tuning effort underway? In MPEG-2 algorithm documentation, there is mention of constant quality (Q) as well as independent parameters to balance the relative degradation of I, B and P frames. Is CD looking at these?

[Dan Keaton]

Dear Gints,

We found for for our MPG files, the VBR was more compatible with other devices than CBR. I think, for these files, VBR is far more common.

Could you please send me a link to the MPEG-2 documenation you mentioned. I would like to read it.

[Piotr Wozniacki]

Originally Posted by Gints Klimanis

Currently, the quality fluctuation at bitrates of 100 Mbps and higher generates MPEG-2 Long GOP footage with a quality flaw due to the large differences between the I-Frame and P-frame, though I notice this quality jump nearly every six frames in Sony Vegas (100 or 140 Mbps). Other user comments along the lines of "I-Frame Only at 220-280 Mbps looks cleaner" indicate other users may notice the quality drop and or variation.

If VBR mode allows for specifying a constant quality per frame even if the bitrate varies and increases somewhat, VBR is not only sensible but critical to the quality of the Nano output files. Right now, I'm find that I need to record I-Frame only 220 Mbps to achieve a quality that should be available at LongGOP bitrates at half that rate.

Thank you Gints for reminding what this thread has been about since the very beginning : the evident quality problems due to shimmering noise in some nanoFlash modes.

Introducing additional VBR L-GoP modes (or even replacing the current CBR modes from 100 Mbps up for L-GoP recording) that's being discussed now, is just one of the ideas brought forward by the thread participants, as a potential remedy to the disappointing L-GoP quality, due to the quality fluctuation within any given GoP. The fluctuation is seen as shimmering especially on large screens, and can outweigh the advantages that the nanoFlash high bitrates bring about (like the reduced mosquito noise, better detail, and of course doubled chroma resolution).

Whether and how the VBR is able to eliminate this quality fluctuation can only be tested and assessed in the Convergent Design labs - we the end-users are in no position to decide on that, but we (myself, for one) are ready to test the VBR modes in our shooting scenarios, and NLE systems. Also, I do appreciate that introducing all new encoding modes would be a huge task for CD, and may not be viable as their number one priority at the moment.

So, to sum it up, the whole VBR idea is not even a "feature request" from nanoFlash users, but merely a suggestion on how its PQ could possibly be improved.

But, other methods of fine-tuning the encoding chips should also be considered by CD - in my own humble opinion, "opening up" the max bitrate may not help with the fluctuation in question. If one goes back to my first posts in this thread, my examples make it evident that the highest bitrates are even more disappointing in this respect than - say - the 50 Mbps mode.

Speaking of which: the advent of the newest PMW-500 camera with just 50 Mbps 422 CBR, and the fact the XDCAM HD422 codec has never been used in any Sony camera at higher a bit-rate than 50 Mbps, may indicate that this in fact is the sweet spot for this particular codec - and not much can be done to improve it by "brutal force" of increased data rates... Trying to catch up with the HDCAM may be pointless, as they are different animals - even though they also use MPEG 2 L-GoP, as well.

The bottom line of my reasoning here is: bitrates higher than 50 Mbps in 4:2:2 L-GoP may not be capable of further improving the "noise vs. detail" aspect of PQ, unless they are accompanied by further chroma resolution increase.

Dan, would the XDCAM HD chip be capable of 4:4:4, if only at limited data rate, like 100 Mbps?

;)

Piotr

PS. We can dream, can't we...

[Rafael Amador]

Hi Piotr,
Although I believe that VBR won't adds nothing, I agree very much with your post.
What I don't understand is the last paragraph:

"The bottom line of my reasoning here is: bitrates higher than 50 Mbps in 4:2:2 L-GoP may not be capable of further improving the "noise vs. detail" aspect of PQ, unless they are accompanied by further chroma resolution increase.
Dan, would the XDCAM HD chip be capable of 4:4:4, if only at limited data rate, like 100 Mbps?"

Why do you want more chroma?
If the processor or the "compression formula" are not able to cope properly with 422, you think will work better with a a 30% more info to cope with?
Aside that 422 still being the standard, more chroma just would add more problem. What we have to think is how to manage properly those 422.
For me the problem is simply the Closed/Long GOP structure.
More key frames and higher data rate is the only way to get a better picture in MPEG-2.
With the NANO, data rate is not an issue.
Probably is a matter of tweaking the SONY formula.
SONY has designed a format for the people that used Betacam (good enough if you don't give a closed look), but seems that the codec (Processor?) doesn't work when you try to get the most from your camera.
Cheers,
rafael

[Dan Keaton]

Dear Piotr,

The nanoFlash is not setup for 4:4:4 recording.

This requires dual-link or HD-SDI 3G, and a camera capable of outputting 4:4:4. Your camera, and most others, do not output 4:4:4. Usually only very high-end cameras are capable of 4:4:4.

Amazing as it seems, the Canon HV30/40 and maybe others output 4:4:4 over HDMI.

This would require fast CompactFlash cards.

At this moment, I do not know if the Sony Codec supports 4:4:4.

[Piotr Wozniacki]

Originally Posted by Rafael Amador

For me the problem is simply the Closed/Long GOP structure.
More key frames and higher data rate is the only way to get a better picture in MPEG-2.
With the NANO, data rate is not an issue.
Probably is a matter of tweaking the SONY formula.
SONY has designed a format for the people that used Betacam (good enough if you don't give a closed look), but seems that the codec (Processor?) doesn't work when you try to get the most from your camera.
Cheers,
rafael

Rafael,

You are absolutely right - I've always called for L-GoP "fine-tuning" throughout this thread.

My statement about 4:4:4 was meant as a kind of provocation for some more brain storm in this thread, you must have noticed the "blink" character. I expected Dan's answer to be what it is :)

Piotr

[Rafael Amador]

Hi Piotr,
The problem is that if we start to talk about 444 or 10b, we get lost on discussions again.
In short: When the MPEG-2 developers started to play with the ideas of 444 and 10b, they realized that was better to develop a new format: MP4.
8b 4.2.2 YUV is a solid formula. That's what I wanted when I purchased the NANO.
The point is to get the most that we can from the NANO instead of dreaming.
Would be great if Dan would say something about how "tuneable" is the NANOs processor.
As Dan points, some NLEs could have some issues working with these files, but some NLEs probably would manage them without problems.
That would be a good starting.
Cheers,
rafael

[Piotr Wozniacki]

Hi Rafael,

I agree 100%.

If I let my mind drift for a while was just because of the lack of a - shall I say - more constructive response from CD to our inquiries on "how tunable the nanoFlash encoder is"...The only firm answer so far being that Closed GoPs are used.

It took several weeks before I finally got the confirmation that indeed, 12-frame-long GoP is used in the 1080 50i/24p/25p modes.

With the competition around the corner now, let's hope this will get some more insight from CD engineers - but let's also remember there are still some promised features waiting for implementation!

Piotr

[Ron Little]

OK, with all this information out now,
am I to assume that the sweet spot for mpeg recording is now 50mbs not 100mbs?

And the sweet spot for I frame only recording is 220?