Piotr,

I have been following your threads and seeing how they turned out. This is how progress is made and how you get to know your equipment. This is a good thing and thanks for your efforts!

Now, I would say with my experinces with HD cameras, they are all going to seem a bit noisy under $20,000. I think it is a combination a chip technology and increased resolution for noise to appear.

Remember, we are still early on in the HD camera development cycle. The EX-1 was a ground breaking camera. So we have some improvement to be had as time goes forward.

Noise seems to be a much larger issue with my panasonic cameras than the EX-1. But the Nano has in my view really helped the noise situation on the HPX-500 as the Nano captures more detail allowing me to dial down the in-camera detail settings. This results in a cleaner signal going to the Nano which I then put higher quality sharpening on in post.

But on all of the cameras, I notice that the chips are a hair away from falling apart if light levels fall off. Basically, the HD chips and processing needs a lot of light. I have also noticed that the HD cameras have turned the "protect the highlights" style of exposing/shooting upside down. I find that I will get a better result with recovering overexposed images than underexposed images in post. Why? I think it relates to this noise issue.

To my eyes, the EX-1 is a very clean camera for $6,000. But I most often shoot in 720p60 so there is less real estate to show noise. On the Panny's the detail setting and the coring setting are the two noise controllers. I don't know what has the most influence on the EX-1. I guess that tells the whole story as I have never seen the need to eliminate the noise from my view on the EX-1.

So I would say keep on experimenting. My friend calls it "the sickness". and I have it too. But at the end of the day, you will get the best image you can get from your equipment.

Can you post some raw footage on a website that I could download and run through my system? I would be happy to compare to my footage.

Hi Tim,

Thanks for the encouragement. I guess "the sickness" is just a less gentle term for "perfectionism", but it describes the very same phenomenon in my case :)

Thanks for you offer of inspecting some of my raw footage; what length clips (in seconds) do you think would be enough for me to upload (as I mentioned, my Internet connection - particularly upload - is low speed)?

Cheers

Piotr

Coincidentally, the clip I mentioned earlier today (the one I had to use the NR filter on), has been shot with exactly the above philosophy in mind, i.e. on the verge of blowing out the highlights. It was my intention to let as much light in the camera as only possible without unrecoverably loosing highlight details, and then return to the correct levels in post. I even engaged Cine4 to stretch the lower midtones even more on the foreground subject. BTW, it turns out I've overdone a bit with the exposure - there are fragments of sky that are burnt out, and detail cannot be recovered by mapping the picture back to the proper level using color curves. But this is irrelevant to the main issue - the noise:

Because-surprise, surprise: the noise I got in some usual picture areas (mid-IRE, uniform color) is even more pronounced now, than in the same scene exposed traditionally - i.e. with just traces of zebra at 100% here and there. Go figure...

Dear Dan,

Unfortunately, I must retract the above statement. The nanoFlash encoder is still suspect - perhaps even the most suspect one in the hardware chain I'm using. Let me explain.

It's obvious and expected that any Long-GoP encoder will produce frames of varying quality within each GoP. For instance, the position and color of individual grains in the noise pattern change from one frame to another. The degree to which they differ determines intensity of the "shimmering" effect as perceived when watching video in motion.

Now, the problem with my nanoFlash Long-GoP encoder is that the higher the bitrate, the bigger those fluctuations between individual frames within any given GoP.

To exclude any other variables, the clip I've been analysing today contained exactly the same scene I posted previous examples of (the wooden shed), but this time I brought it out of the shade by engaging Cine 4 gamma which stretches blacks, and exposing so that the shed is much brighter (at the expense of the sky behind it starting to blow out, which is a limit for any practical shooting). Also, I shot the scene from the tripod, so the image is 100% static.

Then, I enlarged a cropped fragment (620 pixels wide), and studied *both* the native EX picture, and the 100 Mbps nano picture, frame by frame.

While in the case of the native EX1 encoding I could see *some* fluctuation to the noise pattern, they were very slight indeed; however - watching the nanoFlash 100 Mbps L-GoP picture - I noticed that some frames within each GoP are extremely noisy (see the grab to the right, below). In fact, those most noisy frames show some pixelation, similar to the example I attached to the post #103 we discussed earlier. The frames immediately next to those really bad ones, can be much smoother - as the attached grab to the left clearly show.

It is this strong fluctuation in the noise pattern and intensity which makes the actual video from nanoFlash shimmering - to the extent of being almost unusable (unless I run a NR filter on it in post).

Dan, I realize this thread has become very long and complicated one by now, but I hope you understand it took me some time and effort to reveal the true nature of the problem. Out of the hardware elements used, which is most probably responsible for the excessive shimmering noise my nanoFlash produces in L-GoP, high bitrate video? Here is my reasoning:

- it cannot be the camera sensors, as the native EX1 doesn't show such a strong fluctuation of noise between neighbouring frames within GoP's

- it cannot be the SDI connection, as there is no reason for it to fluctuate at all

- having eliminated the 2 above ones, it's most probably the nanoFlash encoder which is responsible. The only question remaining is whether it's just my unit, or all of them...

Dan, I'd like to put the clips I'm comparing here on a DVD and ship them to you for analysis. Is it OK?

Piotr

NOTE: the pictures below are NOT EX1 vs. nanoFlash comparison this time; instead they show 2 directly neighbouring frames in the same, 100 Mbps, L-GoP video from my nanoFlash!

Dear Piotr,

The Sony Long-GOP consists of I Frames, B-Frames, and P-Frames.

They are not all created equal in terms of quality.

If you want the highest quality, we recommend 220 Mbps or 280 Mbps I-Frames Only.

Our 280 Mbps I-Frame Only has been thoroughly tested by a major network for one of their high production value prime-time shows using the most sophisticated of test equipment.

The quality met their specifications and needs.

As I calculate it, you are looking at two frames, zoomed in 310%.

Please feel free to ship us the DVD, if you wish.

Piotr,

"Shimmering" highlights are a problem with native EX1 footage from component output, 12MP images from D3 on Sony PS3 or even BlueRay displayed on my Sony Bravia 52" LCD - state of the art in 2007. I was unable to find any TV controls that would eliminate the artifact, even when TV sharpness was at a minimum. Scenes with detailed highlights, such as from sunny sand or animal fur, would shimmer in panning or movement, and the artifacts were annoying. This visual trash is a product of the display, but still, it must be considered.

While there is a certain amount of pride involved in displaying the perfect image on a consumer TV, consider that you will be the only one to view your high quality footage unless you provide it to a production house. A better comparison would be to author two 4:2:0 BluRay disks or 10-20 MBps MP4 files and provide two input sources that allow you to pause and swap between them.

Also, do you see noise on a static image on your TV? I see some when I pause a BluRay disc played by a Sony PS3.

Piotr, I think a good thing would be to shoot a little footage and let me know the settings used. I can then shoot a simlar scene with my setup with the settings applied and compare to two. As far as file sizes, I guess as much as you are comfortable to send. enough to play a bit in realtime would be nice to see in terms of video instead of still frames. Do you have a website to upload them to? Maybe here at DVInfo?

If you can send the internal and the nano of the same footage that would help me with the comparisons.

Dear Dan,

I'm well aware of the Long-GoP structure, and realize that the I, P, and B frames cannot be the same quality by definition. All I'm saying is that the difference between the best quality frame, and the adjacent one which happens to be of the worst quality, seems too huge to be right in my nano's L-GoP files at 100 Mbps (and higher). Also, it's much greater than that between the native EX1 L-GoP frames (relatively speaking of course, as the two formats are not directly comparable).

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.

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...

Thanks,

Piotr

Gints,

I'm not sure why you are bringing a "shimmering highlight" subject here - I'm talking about shimmering grain (or noise, fluctuating from from to frame).

To answer your question: yes, I can see noise on static images; however - as I said just a couple of posts ago - it's the moving video where the noise becomes really disturbing, due to the said shimmering / fluctuation.

Dear Dan,

Just to let you know that I do agree with the above statement of yours; my reservations only apply to the high bit rate (100 Mbps and more), Long-GoP nanoFlash format.

In one of the very first posts in this thread, I have explicitly stated that neither 220 Mbps I-Frame Only, nor Long-GoP clips of up to 50 Mbps, show the increase of shimmering noise, as compared with the native EX compression.

Although later on, I guess I denied this original assessment of the I-Fo format being OK - that was a false impression on my side, due to my difficulties at some stage to properly synchronize the EX1 and nano clips with the single frame accuracy; I was evidently wrong at that stage - sorry for that (I realize it further complicated this convoluted investigation of mine).

So to recap - yes, the I-Frame Only format offers all the benefits of nanoFlash high bitrates and 4:2:2 color resolution, while -unlike the L-GoP format - NOT introducing excessive shimmering noise .

I hope we're clear now; please address my kind requests in the previous post.

Thanks again,

Piotr

Hi Tim,

I wonder if Dan would make access to CD's ftp available for me to upload such 2 files - it'd have the advantage that both yourself, and the CD engineers, could analyse them and help me make sure whether my nanoFlash is up to specs in L-GoP mode.

Dan, what's your word?

Dear Piotr,

I will send you the FTP File Upload instructions.

Piotr, thanks for the enlightenment. We need more education on how to decide between Long-GOP and I-Frame-only. I certainly would not want to collect a couple years of event footage at 100-140 MBps LongGOP only to learn that additional detail is lost in using using noise reduction in time-consuming post-production. If I have to switch from 140 MB Long-GOP to 220 I-Frame to get the benefits of the Nano, so be it. CD, please write a guide.

Hi Gints-
Take a look at the Video Quality Vs BitRate Chart (http://www.dvinfo.net/forum/converge...-bit-rate.html) which measure video quality vs bit-rate (using the Video Clarity System). It show as general trend of higher bit-rate equals better video quality, but with diminishing returns. 100 Mbps Long-GOP continues to be the sweet spot of quality vs storage requirements. Although not shown in the chart, our tests indicate that above 140 Mbps there is little difference in Long-GOP vs I-Frame only compression. At 100 Mbps and lower, Long-GOP clearly wins.

I am writing a more detailed explanation (with help form Video Clarity) to more fully explain the tests and results.

Best-

Thanks Dan.

I have uploaded 2 pairs of 5-7 secs clips (each pair consisting of the EX1 native and nanoFlash 100 Mbps L-GoP):

- back-lit (even though the sky is almost blown-out, the wooden surfaces and tree barks are darkish (up to 40%), and noisy)

- in bright sunshine, but contrasty (realistic exposure, with the wooden surfaces and tree barks in up to 70% range; still noisy in the shaded areas)

Please blow up a 720 crop (typical), and inspect any GoP - frame by frame, to see how much they vary in the contained noise for the nanoFlash version as compared with that from the EX1. Please note that in 180 Mbps clips, this phenomenon is even more pronounced (I haven't uploaded 180 Mbps clips due to their size, and my slow and unreliable connection).

I will, however, try to wait for the right weather, and shoot the same scene well lit, and flat (with no shaded areas). When I upload the clips, you will see how even very brightly lit surfaces of uniform color still shimmer with noise!

Of course I realize that the input (from the EX1 camera) is noisy in the first place; however - as said before - I'm afraid it's not right for the high bitrate L-GoP nanoFlash files to augment this noise so dramatically, and in such a fluctuating fashion (which intensifies the shimmering effect).

Comments welcome.

Great. Let me know where to get the files from and I will have a look and test with my camera.

Dear Dan,

Any comments on the uploaded clips?

Piotr

Dear Mike,

I'd be very grateful if - apart from the "detailed explanation" announced above - you answered my kind requests to Dan; quote:

I hope CD is not going to leave all the questions, doubts and theories, contained in this thread, unanswered. Like for example this observation of mine:


Thanks and Regards

Piotr

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?

Hi Gints-
Yes, I would definitely recommend I-Frame-Only at bit-rates of 140 Mbps and above. We don't see any improvement with Long GOP at these data-rates and I-Frame is a little easier to edit.

I suspect you are looking at the I or P frames when you identify the slightly higher quality frames in the GOP. We saw similar results with the Video Clarity tests. The I-Frame-Only quality was very smooth, while the Long-GOP quality varied from frame to frame (I-Frame was best, followed by the P-Frame and then the B-Frame). There was not a huge difference from frame to frame, but it was noticeable.

I'll speak to our engineers about the possibility of opening up the GOP length and bit allocation. But, I can't make any promises.

Best-

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

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.

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

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-

Thanks for the answer, Mike.

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

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:

And another one:

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

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.

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

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?

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

Dear Piotr,

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

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.

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.

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.

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

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 ;).

Besides Mike Schell's informative bitrate vs. quality chart, I'd like to see more information to help me decide when to use 100 MB LongGOP vs. 140+ MBps I-Frame only. 140 MB LongGOP seems to deliver more shimmering but few if any other gains than 100 MB LongGOP. 100 MB LongGOP is perceptibly better than 35 MB SxS, and comparison frame-grabs always show less mosquito (macroblocking) noise in the Nano footage.

Right now, I feel like I have to do these quality tests myself.

While I have followed this thread with some interest, our facility is Avid based. As such, I shoot I- frame at 220 Mbps in MXF. It does get tiresome moving media to drives but when I see the differences between the SxS footage and the Nano footage it really becomes a no brainer. If Long GoP does introduce noise at certain bit rates I'm grateful for those who are learning the limits of this technology and raising awareness for the benefit of all.

I don't see it as the limit of the nanoFlash technology or really the high bitrate but an indication of the limitations of the source. The nanoFlash at higher bitrates is capturing in more detail the material coming into it. If the camera is noisy, it will capture it more faithfully than at a lower bitrate where there is smearing going on.

There is a reason why camera ops, DPs and others bathe their scene's in light other than for aesthetic reasons. It's to get the image out of the noisy range of the image sensor's range. You want less noise, use more light.

Don't you see additional noise/detail with 220 MBps I-Frame only? I do, and I'm not surprised. Some of the cleanliness of the EX1/EX3 was simply due to Sony's encoder working at a lower bitrate.

The important discussion point is whether LongGOP magnifies MPEG "I-to-B/P frame shimmering" more and more as the bitrate increases. Are 140 and 180 MBps worse than 100 MBps? From my own tests, 50 MBps LongGOP is not enough to eliminate enough macroblocking artifacts. 100 MBps I-Frame-Only is too soft due to detail loss. CD is putting forth their opions, but we need to coax them more. Until this discussion, I did not know that at 140 MBps, I-Frame only is preferred. I upped my bitrate from 100 to 140 MBps LongGOP a few months ago. Now, I have to do some serious testing myself to decide if I-Frame-Only is really vetter for me.

While we all have seen the noise, the emerging issue is whether there is too much fluctuation in detail/noise from frame to frame in LongGOP MPEG-2. That is, is the faithfully-compressed noise too great or is the interframe detail fluctuation the primary objection?