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

[Piotr Wozniacki]

Originally Posted by Gints Klimanis

Mike, do you recommend using I-frame Only at 140 MBps and above to avoid MPEG "shimmering"? Stepping through the frames in Sony Vegas, I can usually identify a higher quality frame every six frames or so, but I would guess that Long GOP length is 15. Is it 6 or 15?

Did CD need to tune the Sony encoder differently for higher bitrates? Also, is it possible to expose the bit allocation ratio between I and P frames to the user?

I can confirm the drastic change in the amount of noise when stepping through the frames within any given GoP - especially in nanoFlash Long-GoP files with data rate above 100 Mbps. In fact, this has been my observation throughout this entire thread; I even uploaded a couple of sample files to CD ftp server in hope they would be analyzed, compared with still grabs I have been posting here, and conclusively commented.

I'm still patiently waiting for some insight from CD (who are at the moment extremely busy with final tests and debugging of the newest firmware). I'm sure I'm not the only one to benefit from better understanding the actual Long-GoP implementation details on the nanoFlash.

I believe that the GoP length should be 15 for NTSC (or 60 Hz area), and 12 for the 50 Hz area. I still hope we will learn something from CD that would explain the fluctuation of noise, causing the shimmering and making the noise (which originates in camera, not in the nanoFlash) unacceptable in L-GoP files above 100 Mbps.

Piotr

[Peter Moretti]

Piotr,

How can you say this?

"Unfortunately, my efforts and request for cooperation has been ignored by CD."

CD has posted extensively in this thread and even gave you access to their FTP site so you could upload your files to them.

While it seems like you are noticing an important issue w/ the nano and your perseverance is impressive, you can't honestly say they have not cooperated with you. If I were Mike or Dan I'd be blowing a gasket after reading that.

Again, you've noticed something that is definitely useful to know. But also, you are shooting at a Long-GOP data rate above what's recommended. Perhaps you're the first one to notice this is b/c you're one of the few users shooting Long-GOP above 100 mbps.

So on the balance, your thread and contribution is very useful and helpful. Thank you.

But from an impartial observer's perspective, your criticism of Convergent Design as being uncooperative and ignoring you is uncalled for.

[Piotr Wozniacki]

Peter,

Throughout the entire thread, I kept stressing I was not "critical" of CD, or ranting, or bashing anyone - just looking for answers to the following questions:

- is my nanoFlash working up to specs?
- is my EX1's SDI output working up to specs?
- if the answers to the above are "yes" (which I now believe they are), what is the reason of the noise fluctuation at high bit rates?

Now, the thing is that if I finally could arrive at the conclusion that nothing is wrong with my nanoFlash and/or camera source, it was only thanks to other users, who took their time to check my sample files, and commented off-line (thanks Tim, Gints, Rafael, and Bob).

On the other hand, no such help has been offered by CD. I realize of course those great guys are extremely busy developing and testing new firmware versions, but I would think thoroughly explaining such a rudimentary issue would be in their own interest, and in the interest of all those lurkers in this thread, who are only trying to make their purchase decisions.

I did get an off-line message from Dan only after my last post (that seemed so harsh to you), explaining the lack of answers to my questions of June 25th with CD beig busy debugging the newest firmware, and I of course understand it (as pointed above). Keeping in mind all the great features that have been announced to come into future firmware versions, and realizing how complex developing such a wonderful device can be - I guess CD's engineers will permanently be as busy as they are at the moment, for quite some time to come... Should it mean questions like mine should be left unanswered, even though this forum is linked to on the official CD website, as their user forum? Peter - please answer this question for yourself.

Having said all that - if anybody has been hurt with my post - please accept my sincere apologies.This wasn't my intent - I was merely trying to remind Dan or Mike I was waiting for some response to a couple of very precise questions...

In order to prove I wouldn't like to leave a permanent "stamp" of what might be interpreted as bad feelings, I'm rewording the sentence you found offending, Peter :)

Piotr

[Mike Schell]

Originally Posted by Piotr Wozniacki

On the other hand, no such help has been offered by CD. I realize of course those great guys are extremely busy developing and testing new firmware versions, but I would think thoroughly explaining such a rudimentary issue would be in their own interest, and in the interest of all those lurkers in this thread, who are only trying to make their purchase decisions.
Piotr

Hi Piotr-
I am sorry that we did not respond to your concerns, but happy in the end that everything was resolved. As you know, we only have a limited amount of engineering resources to devote to any issue. Our central focus is reliability. To that end, we have devoted countless hours these past few months testing, testing and testing both hardware and software reliability. We resolved an issue with intermittent source and eliminated some rare problems with file corruption. We think the new firmware (1.6.29) is in excellent shape.

Yes, we still need to fix the power-down issue and yes, there are undoubtedly more bugs to fix, but the overall reliability should be in great shape. To this end, we will continue to devote most of our efforts to improving the product, so please excuse us if we are sometimes slow (or absent from the discussions). We're likely in the lab chasing down a problem or enhancing the product.

Best-

[Piotr Wozniacki]

Thanks for the answer, Mike.

Originally Posted by Mike Schell

Hi Piotr-
I am sorry that we did not respond to your concerns, but happy in the end that everything was resolved.

One thing though: when I said "nothing is wrong with my nanoFlash and/or camera source", I was merely meaning they're working up to specs (basing on other users' opinion). My questions on the high bitrate L-GoP modes of the nanoFlash being optimized or not, and the actual GoP structure the nano is using, still remain valid...

Oh, and one more thing: I really do appreciate your efforts, and its results!

Best,

Piotr

[Piotr Wozniacki]

Dear Dan,

It's nice and encouraging to see you being active and posting again in this forum.

I'd like to kindly remind you of the several promises you made within this thread, to provide us with some more insight to the specs and optimization issues of the nanoFlash Long-GoP format. Specifically, I'd like to quote myself:

Originally Posted by Piotr Wozniacki
Several posts ago, I asked you for providing us with some specification of the nanoFlash L-GoP structure (like the number of frames per GoP for PAL, using closed GoPs, etc.) - it could enable me to be more specific as to which frame is which. Also, if you could provide me with some official technical information from Sony explaining why the higher bitrates would result in more quality difference between adjacent frames of the Long-GoP structure - I'd happily accept my nanoFlash as working up to specs...

And another one:

Originally Posted by Piotr Wozniacki
Interestingly, at 50 Mbps (for which the Sony chip inside the nanoFlash was designed originally AFAIK), the I, P and B frames are much closer in their quality, and hence the shimmering of noise is waaay less noticeable. This confirms my observations throughout the entire thread.

Finally, just a humble reminder: have you been able to examine and assess the clips I uploaded to the Convergent Design ftp server?

The thing is that - as stated above in my answer to Mike's post - even though a couple of our friends in this forum (all EX camera/nanoFlash users) did test my samples, and didn't find anything that would suggest my camera and/or nanoFlash are malfunctioning, this main question still remains open:

Is there a room for further optimization of the nanoFlash Long-GoP codec at the high bitrates (100 Mbps and above), so that the frames created within any given GoP do not differ so much in the amount of detail (and inevitably, also noise) they contain? Reducing the difference in detail/noise content could be achieved by fine-tuning the encoding chip - of that I'm sure!

This is very important as it's this fluctuation of individual GoP frames quality that makes the noise so pronounced, thus negating the advantages of more detail inherent with high bitrates...

And let me say that - in the meantime - I experimented with NR plug-ins a lot. Unfortunately, the result of these experiments show that noise reduction in post can introduce so many artifacts by itself, that it negates the very purpose of nanoFlash recording at high data rates. Noise reduction in post is definitely not the way to go!

Thanks for your attention, and please address my doubts in detail -

Piotr

[Dan Keaton]

Dear Piotr,

Thank you for the "Welcome Back".

Let me start with this, then I will attempt to address your specific questions:


We recommend to “Use I-Frame Only above 100 Mbps". Thus, at 140 Mbps or above, we recommend using I-Frame Only, at 100 Mbps or below, we recommend Long-GOP.

MPEG-2 is actually a very good codec, in my personal opinion, especially when used at very high bit-rates. This is borne out with tests by very sophisticated test equipment such as the Video Clarity system.

Under 140 Mbps, Long-GOP definitely wins in terms of quality over I-Frame Only.

Above 100 Mbps, I-Frame Only wins.

This is due to a few factors.

Under 140 Mbps, the I-Frame can not always fully encode a frame in the space allocated for one frame, so quality has to be lost.

In Long-GOP, the I-Frame will use the space of two "GOP" frames, if the image can not be fully compressed into one I-Frame. This is the magic of Long-GOP.

Thus, in Long-GOP, the full quality of the image will be recorded in each I-Frame of the GOP (with each I-Frame sometimes taking up the space of two "GOP" frames.

Above 100 Mbps, the Long-GOP "B" Frame may have less quality than the I-Frame.

When the codec is presented with so much detail (or noise) in the image that each I-Frame has to take up the space of two "GOP" frames, the results could be that the B or P frames are restricted in quality.

So, if one steps through the footage, frame by frame, one can see a difference in quality.

If one wants extreme quality, then one should record in our I-Frame Only at 280 Mbps.
This is good enough for NBC-Universal, for their high production quality show, Trauma, shot with the Sony F35 and nanoFlash, at least for Steadicam shots. I do not know about the other shots at this time.

NBC-Universal tested the nanoFlash very thoroughly, and selected the 280 Mbps I-Frame as meeting their standards. Everybody in the production chain, as far as I am told, loves it.

To a codec, noise is considered detail and the codec makes every effort to preserve the detail to the best of its ability, within the limitations of the bit-rate and codec design.

Low bit-rate codecs will eliminate much of this noise as the codec eliminates some of the detail in the image.

Thus, for the highest quality, attempt to reduce, in the camera, by lighting or other techniques, the noise in the image before it is sent to the nanoFlash or any other recording device.

In HD, in your area of the world, one typically uses different frame rates than in 60 Hz power areas of the world. Thus 1080i50 is used, as an example, instead of 1080i60 (typically, 1080i59.94).

Thus it is PAL areas of the world and NTSC areas of the world, but HD is not PAL.

Our GOP structure does not change if you choose 1080i50, for example, as opposed to 1080i59.94.

And, in 1080, it is always 1920 x 1080.

We follow the GOP standards for the format that is being recorded, and we used Closed GOPs.

The quality difference that you describe is answered above.

If you follow our guidelines listed above, then you will be using the best options for the bit-rate you select.

I am sorry, but we have been extremely busy, and have not yet been able to devote one of our engineers to analyzing your videos.

Sorry, but I do not know of any way to further optimize the Long-GOP at high bit-rate. It is trying to do everything in its design to capture all of the detail (and noise) in the I-Frames of the Long-GOP. With excessive detail (or noise), the design uses more than one frame, thus the other frames are reduced in quality.

Just use I-Frame Only above 100 Mbps, especially if your images contain excessive detail (or noise).

I see no reason to think that your nanoFlash is not working up to spec.

[Piotr Wozniacki]

Dear Dan,

Thank you so much for your exhaustive answer. It contains a lot of information that I need to dig through, and consider thoroughly, before even attempting to response :)

Thanks again,

Piotr

[Piotr Wozniacki]

Originally Posted by Dan Keaton

In HD, in your area of the world, one typically uses different frame rates than in 60 Hz power areas of the world. Thus 1080i50 is used, as an example, instead of 1080i60 (typically, 1080i59.94).

Thus it is PAL areas of the world and NTSC areas of the world, but HD is not PAL.

Our GOP structure does not change if you choose 1080i50, for example, as opposed to 1080i59.94.

And, in 1080, it is always 1920 x 1080.

We follow the GOP standards for the format that is being recorded, and we used Closed GOPs.

Dear Dan,

OK, so the first thing I'd like to comment on is related to the above excerpt from your post. I realize there is no such thing as PAL or NTSC in HD - instead, terms like the "50 Hz area" or "60 Hz area" are used.

However, I don't quite agree that "not change[ing] the GOP structure if you choose 1080i50, for example, as opposed to 1080i59.94" is "follow[ing] the GOP standards". MPEG-2 usually does differ in the number of frames between consecutive I-frames in the GoP, depending on whether it's for the 50 Hz area (in which case, it usually has 12 frames between I-frames), or the the 60 Hz area (when it usually has 15 frames). Needless to say, this may be in favor of the 50 Hz area encoding quality.

You also say you're using Closed GoPs; this s good as with closed GoPs, the "All short" GoP length scheme can be taken advantage of, whereby all GoPs start with an I-frame and are the same length. Also (unlike with the "First short" or "None short" options), all GoPs are created as short GoPs - all this should potentially increase the encoding quality. But, are you using the "All short" GoP length for sure?

Originally Posted by Dan Keaton

Sorry, but I do not know of any way to further optimize the Long-GOP at high bit-rate

Well, ensuring that at least with 100 Mbps and above, "All short" GoP length is used might be one of them...

Having said all this, I fully agree that should the source (the camera) be noise-free, this would be a non-issue on the nanoFlash, too. But, we're not living in a perfect world, and some cameras do generate more noise than other ones - so trying to achieve the most consistent quality of individual frames in the GoP structure is the only way to help alleviate the problem. Because as I pointed out many times, it's the fluctuation of the noise content (intensity and pattern) that "animates" the noise in actual video, thus making it more pronounced.

Piotr

[Dan Keaton]

Dear Piotr,

For 720p, we use a GOP Length of 12, for 1080 we use 15.

[Piotr Wozniacki]

Dear Dan,

I'm sure that if the nanoFlash has the horsepower to encode I-frame only at up to 280 Mbps, it could also manage to encode Long-GoP at 100-140-180 Mbps, with GoP length shorter than 15 (e.g. 12) - even at 1080 modes.

This could be another way of optimizing the output.

[Mike Schell]

The NBC-Universal test involved a comparison of the video quality at 280 Mbps I-Frame only vs the HDCAM SR deck. The Steadicam operators wanted a lighter weight recorder to replace the heavy HDCAM SR deck. The quality of the 280 Mbps I-Frame was sufficient to replace these SR deck with a nanoFlash. The NBC engineers did a comprehensive review of the image quality and were satisfied with the results.

I was personally involved in the video analysis. You can clearly see an improvement of the video (from 220 to 280 Mbps), if analyzed on a waveform monitor. Yes, it's subtle, but it's clearly visible.

Does the nanoFlash deliver the same quality level as the HDCAM SR? Definitely not! But in this application, the 280 Mbps I-Frame was sufficient. Yes, the operators loved the lighter-weight and lower-power of the nanoFlash.

I understood that this thread was intended to discuss video quality.

[Gints Klimanis]

Originally Posted by Piotr Wozniacki

I'm sure that if the nanoFlash has the horsepower to encode I-frame only at up to 280 Mbps, it could also manage to encode Long-GoP at 100-140-180 Mbps, with GoP length shorter than 15 (e.g. 12) - even at 1080 modes.

I've posted some frame-grab PNG file sequences and unmodified source video (smallest files in shoot) of SxS and 100MBps LongGOP. The average frame from the SxS does not appear to have much less detail in this scene than the average Nano frame, but there is much less macroblocking in the Nano. Some Nano frames are much sharper than SxS frames. Overall, I'd say that the Nano video is much cleaner, mostly due to the absence of mosquito noise on the reflections from the water. I won't go back to 35 MB SxS.

MPEG-2 "shimmering" is seen on the blueish rocks in the back towards the end of the clip in both SxS and Nano. The 100 MB LongGOP appears to shimmer more when the camera is not moving. Some file name begin with Cmp, and they are randomly chosen frames that can be easily toggled in an image viewer. Piotr, is the shimmering more obvious on your 50+ inch TV?

Index of /Images/Video/NanoflashTest/NanoCompare2_RayPool

NOTE: Both clips have audio when played from Vegas, but the Nano MXF does not have audio when played from VLC.

EDIT : The frame grabs may now be downloaded in a Zip file.

[Eric Liner]

Mike,

I appreciate you sharing the results of third party tests like this. Even though 100mbps Long GOP has long been praised as the "sweet-spot," I've always thought 220 I-frame looks (objectively) better. It's nice to know that we're not crazy when we we're interpreting the way our footage looks. With more info like this, we can make better decisions in the field while we try to balance quality with storage constraints, etc.

I also think it's worth shedding some of the hyperbole surrounding the use of the Nano over tape based (or other) codecs like HDCAM SR. Let's face it, while the nano takes an uncompressed signal off of the chipset, it still compresses the heck out of it to achieve rates as low as it does. Whether it gets compressed in camera or out, it's still mpeg 2 compression.

That said, I have a few questions:

1) During the NBC test was the difference in quality noticeable without the scopes? Was it perceptibly better? How so?

2) Is anyone else out there disappointed (besides the few saying so on this thread) with the introduction of noise in their Long-GOP footage? Is there any real concern that quality is being compromised when we use high bit rate Long GOP with the Nano? And has anyone had negative responses to their footage from clients or broadcasters in regard to unsatisfactory noise levels?

Thanks,
Eric

[Eric Liner]

BTW: I meant "subjectively" not "objectively" in regard to my quality assessment of 100mbps versus 220 I-frame...

Not enough sleep over the past 24 hours ;).