My Citation Sources
 

Dear Dan: Yes Dan I would. You can download the white paper from http://pro.sony.com/bbsccms/assets/f...itePaper_F.pdf

The document confirms what I had been saying many times - that for 50i, 25p the GOP length should be 12, not 15.

About The Cameras Listed & Other Points
 

Yes. I agree it is.
Yes you did, but I found your post confusing.

...Yes I think it does, because depending on which one it is, it can neither do HD or XDCAM EX 1440x 1080 codec. (Regular XDCAM can't). XDCAM HD 4:2:2 hardware encoders *implement one pass realtime VBR encoding.

....You listed the Sony PDW-F800. OK, but that's a well known XDCAM HD 4:2:2 camera, and this is part of what I find confusing.

...OK, and you also can do regular SD and HD .MPG, which is also a cool feature.

Long Group of Pictures Length
 

Hi Piotr: I wonder if this is yet another reason why Avid Media Composer has difficulty recognizing the Nano/XDR recorded CF card media in AMA mode ? Avid does not *see* the file structure of XDCAM HD files as the same as XDCAM HD files recorded on discs out of the XDCAM HD cameras.

I have no idea whether this is the reason, Mark, but wanted to thank you for finding out this white paper.

At least now we can start talking facts here, not suppositions, assumption, and wishes...

I hope CD will catch up. Dan is absolutely right when saying that no matter what the names are for standards and codecs, nanoFlash is capable of full raster, 422, at high bit rates (other formats aside). But if this is so (and we all know for the fact it is), this means the nanoFlash codec is in fact the XDCAM HD one - and thus can be fine-tuned and optimized (more optimal GoP lengths, VBR in addition to CBR, etc.).

I really think it's time for some official declaration from CD now.

Dear Dan,

I read again through your summary of formats/codecs, and I think where you went wrong in your above statement, is when you correctly quoted the PDW-700/F800 as using "XDCAM HD", but interpreted it as XDCAM instead (I have underlined the key fragments of your own quote):


AFAIK, XDCAM was the first, Standard Definition, incarnation of the XDCAM "Optical" technology (using Professional disks). The cameras using it have been the PDW-535p or 510p.

And obviously, as the nanoFlash is capable of the 422 HD at bitrates of up to 280, it clearly is of the "XDCAM HD" flavor (and not XDCAM, as you stated earlier).

Also, It's been mentioned many times before that CD recorders use the same encoding chips as the 700 and 800 cameras do.

So all in all, I think all that the article linked to by Mark says is applicable to the nanoFlash - including the VBR option viability.

Thank You For Clarifying the Heart of the Matter :-)
 

...I also think it *must XDCAM HD hardware encoder, because the regular XDCAM hardware encoder **cannot do the XDCAM EX codec @ 1440x1080,"" which is also an HD format of course.




....This statement is correct.


....Your deductive reasoning is quite correct.

...Yes. This is what threw me for a loop as well. These are well known XDCAM HD 4:2:2 hardware encoding cameras, so why does Dan list them and seem to be see, this proves it ??

...I thank you Piotr for getting to the heart of the matter here. It doesn't matter about listing a whole bunch of XDCAM cameras, or going into what the Nano Flash does- ***The heart of the matter is does the Nano Flash (and by extrapolation, the XDR) possess an XDCAM HD 4:2:2 Full Raster hardware encoder, and thus the Sony specification calls for the implementation of realtime hybrid V B R encoding. Will CD enable this feature ?***

Hi Piotr,

If I understand correctly, you anticipate that reducing the number of pictures in the GOP will reduce the shimmering you observe because the reference image will be renewed more often. Have you observed this shimmering in the final 1920x1080 product? Is it mostly on shiny objects? I am not sure what to look for.

What problem will the variable bit rate solve?

Many thanks,
Alan

Dear Alan,

If you read the entire thread, you will find answers to both your questions. The VBR encoding superiority over CBR can also be studied in numerous Internet sources. The 12 frames long GOP has long been the industry standard for 50i/25p/24p.

One thing I'd like to add: While I understand CD is currently very busy with maintaining the current firmware quality and reliability (and hopefully, also with introducing the long promised features like card hot-swapping or SDI-embedded + analog audio mixing), I still hope that once they're done with this (and the "important project" they've chosen never to discuss on this official forum of theirs), they will look into optimizing the code so that the maximum quality is squeezed out of the Sony encoding chips.

Piotr

Hi Piotr,
During my testing of the NanoFlash I also observed the same shimmering when recording Mpeg Long Gop 1920x1080. The same scene was also recorded in I-Frame and the shimmering was no longer an issue, now I record everything in 100Mbps I-Frame as standard.

Lance, please give it a closer look (and on a really large display, too - your clients may be using huge displays):

- 100 Mbps is way too low for I-Frame Only. In this mode, I recommend 220 and up.

I do not know if this is of any help but here is a screen grab of the pre set from CS5.

Dear Friends,

I just returned from a 10-day business trip which included a 3D-Workshop.

It is hard to determine the official "Family Name" for Sony's PDW-700 and PDW-F800 cameras.

For the PDW-F800, they put "XDCam" on one line and on the next line they put "HD422" and list the codec as MPEG-2 4:2:2P@HL.

For the PDW-700, the Put "XDCam" on one line and on the next line they put "HD".

Both the PDW-700 and PDW-F800 use the same codec module, and we use the same codec module.

The white paper presented by Mark is from 2007, and it appears that was written before the introduction of the PDW-700 and PDW-F800.

Ron Little's post shows that Adobe CS5 makes a distinction between XDCam HD, XDCam EX, and XDCam HD422.


I know that for 720p we use a Group of Pictures (GOP) of 12.

As I understand it, for 1080, we use a GOP of 15.

If this is wrong and causing any problems, we will look into it.


We also use a "Closed Gop" and I feel that we should. Otherwise one GOP will depend of the images from the previous GOP.

We use VBR where Sony uses VBR. Otherwise we use CBR, the same as Sony, as far as I know.

From Adobe CS5 - Third-party hardware compatibility
 

Dear Friends,

For 720p we use a GOP of 12.

For 1080p29.97, 1080p30, 1080i59.94, and 1080i60,we use a GOP of 15.

For other 1080i or 1080p frame rates we use a GOP of 12.

Thus 1080p23.976, 1080p24, 1080p25 and 1080i50 are a GOP of 12.

This information was obtained from our Chief Engineer.

That means that any GOP will use his own I frame and the one before as reference.
Two "I" frames instead of one.
Thats GREAT.
Professional MPEG-2 software compressors by default uses Open GOPs.
rafael

Dear Dan,

My understanding is that XDCAM HD as used by Sony, has only 4 bitrates available:

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

Since nanoFlash can use higher bitrates as well, and their very purpose is quality - all Long-GoP modes above 50 (like 80, 100, 140 and 180) should be VBR, if this is only possible from the chip programming viewpoint. As no such modes exist in Sony XDCAM HD, compatibility is irrelevant. The average bitrate would give the user an estimate of the recording time in a given mode, while the maximum bitrate actually used by the chip could in all cases go as high as the CF card can handle.

I guess this is what someone called a "Constant Quality" mode earlier in this thread.

Dear Friends,

I get conflicting information when I search on-line for Open versus ClosedGOP's.

In some cases, they indicate that the Closed GOP does not referrence previous frames.

In other cases, they indicate that the "B" frame at the end of an Open GOP can reference the next frame, thus allows this one "B" frame to be slightly smaller. Tektronix's website lists this description.

What is a closed GOP? > Frequently Asked Questions : Tektronix

I feel that this is most likely correct and this is different than what I previously posted.

Since, if one is using our MOV or MXF files for editing, I feel that Closed GOP is better as it does not need the next GOP to decode the previous GOP.

But, for creating a DVD, and not editing, using Open GOP's may be ok.


Here is another link to a discussion of the differences:

GOP closed/open ???? What does it mean ? [Archive] - Doom9's Forum


Here is my position:

In some limited cases, such as when creating a DVD, without multiple angles, and without the need to fast forward, the Open GOP, offers some slight advantages.

However, when editing the files, I feel that Closed GOPs are definitely better.

I am reluctant to change from Closed GOPs to Open GOPs for a slight advantage, which may cause problems in editing our files.

If we decide to try Open GOP's it would require substantial testing on on part, with every editor and condition to prove that it did not cause problems, and this would distract us from delivering other features that have been requested.

This is a moot point when using our I-Frame Only files as this applies only to our Long-GOP files.

Dear Piotr,

For 50 Mbps and higher 4:2:2, we follow the Sony codec standards, which is CBR for compatibility reasons.

We have proven that we can increase the bit-rate, and the professional NLE's, other than Avid, handle our Long-GOP files at these increased bit-rates, and Avid handles our 50 Mbps Long-GOP files and all of our I-Frame Only files.

We have not (yet) proven that any NLE can handle the Sony 4:2:2 codec if we modify it to be VBR.

The Sony XDCam EX codec is VBR, thus we use VBR for that codec.

At some point in the future, we could experiment, but this would require quite a lot of testing to ensure that all NLE's will work with VBR.

At this time, we need to concentrate on the other features that have been requested and we have promised.

Dear Dan,

I realize introducing VBR now would take a lot of testing; I just hope CD will keep such a possibility in mind when you are done with the more urgent things....

Thanks,

Piotr

VBR Encoding ?
 

Dear Dan:
The information I have at hand from Sony indicates realtime, one pass VBR to be part of the XDCAM HD standard. I still don't understand what type of encoder we have in our recorders from CF, but you wrote that it doesn't matter, so I'm assuming it could be done (??). Perhaps some experimental beta test software could be put out (Which I would be happy to test in my spare time to see what happens in Avid NLE with Long GOP and whatever ?

This is exactly what I meant when stating:

And it certainly can be done, the 35 Mbps VBR being the proof....

Do VBR files exist? May I have a special firmware that would allow my Nano to make them? I'll sign up as a tester for Sony Vegas - my regular platform.

Gints,

The nanoFlash is already capable of VBR - in the XDCAM EX mode (35 Mbps).

So we can start testing VBR Now
 

Dear Piotr: I suppose we have already at least one mode in which VBR is encoding away, so I should go test this. Personally, I've never used the EX Mode on my XDR. I guess it's time to go try it. :-) Isn't there also an 18 Mbps mode ?

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.

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

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.

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.

Dear Friends,

Currently, our MPG files are CBR.

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

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.

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?

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.

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

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

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.

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

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

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

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?