4k 8bit 420 -> 1080p - 10bit 444 in vegas ?

Mark_e wrote on 5/20/2014, 2:14 AM
Hi All,

I was just wondering in sony vegas to maximise the downscaling possibilities from 4k to 2k and 1080p along the lines of the article below is it just as simple as dropping the 4k footage into a 1080p timline flipping to 32bit and rending out to an appropriate format like dxhnd 10bit 444 or is there more to it than that. I couldn't see any info about how vegas does the downscale either i.e. what algorithm. Also is there a good tool to look at these types of file to check at a low level exactly what is going on to verify results ?

http://www.eoshd.com/content/12140/discovery-4k-8bit-420-panasonic-gh4-converts-1080p-10bit-444

thanks

Mark

Comments

John_Cline wrote on 5/20/2014, 2:36 AM
"Best" render quality uses bicubic scaling with integration, while "Good" uses bilinear without integration. You must use "Best" if you are using high resolution stills or video that is getting scaled down to the final output size. "Good" may have bad artifacts on the near-horizontal edges, while "Best" will look great.
musicvid10 wrote on 5/20/2014, 8:46 AM
A couple of points:
Bicubic downscaling is fine most of the time; however Lanczos may prove better in some cases (moire that becomes more apparent after scaling), for instance.

Although I use 10 bit DNxHD 4:2;2 as an intermediate to reduce banding in the final 8-bit output (for reasons that Laurence helped me flesh out), I think Cineform must be doing some things internally that Vegas isn't. David Newman's comments about "Luma precision can be increased to 10 bit" is something that I don't think is accomplished internally in Vegas.

Although DNxHD 444 is very good (it was invented for Arrie), it is not RGB 4:4:4 chroma subsampling as David Newman specified. In Avid-speak, it means 444 Mbps. DNxHD 444 is YUV 4:2:2

Do let us know further results from your Vegas tests. It's good to know that Cineform will handle this conversion internally.
NormanPCN wrote on 5/20/2014, 3:13 PM
Although DNxHD 444 is very good (it was invented for Arrie), it is not RGB 4:4:4 chroma subsampling

According to Avid it is 4:4:4. Page 4. It is also 444 Mbps which may be a source of confusion.
http://www.avid.com/static/resources/US/documents/DNxHD.pdf
Mark_e wrote on 5/21/2014, 3:16 AM
thanks all,

I read the response as if you up convert to RGB 10/16 bit first then do the down sample and transcode out to 4:4:4 you preserve the detail, I was guessing that internally vegas was doing that so it might just work. I'll have a play I can export to ciniform and as well just DNxHD plays better with a wider range of apps I've found. I'll find take some moire candidate shots as well and try compressing with both algorithms outside of vegas, the 4k from gh4 is 1:1 pixel crop from sensor so should avoid most moire situations is my understanding and if we have control over the downscale then if it does get introduced as part of that there are options to avoid it which is great.

There must be some way of verifying what's happening at a low level in the output files the codec to see if it's working developers must check it for regression testing etc., I'll keep looking :)
wwjd wrote on 5/21/2014, 9:59 AM
which 4k is 1:1? the 4096 or the 3840 4k? and how did you find this out? I been seeking that info
Mark_e wrote on 5/21/2014, 2:59 PM
Both 4k modes direct sensor crop from what I have read I was trying to find an official link but couldn't see one to hand just search "gh4 4k 1:1" you'll get loads of referances saying the same thing that's why the crop factor is slightly more when you switch to 4k from 1080p

I'll confirm for sure in a few days I just ordered a vintage c mount f1.8 TV par focal zoom if I'm correct I should be able to use in in 4k and cleanly crop at least 2k from that if my calculations correct :)

Looks like some prior art using avisynth to compress the luma and leave the chroma intact downscaling to 1080p on windows so perhaps could stay in 4k use debug frame server to export it out like that.

If it's all happening internally to vegas then obviously waste of time may as well let vegas deal with it and export to delivery format from there but will try and figure it out if I can.
musicvid10 wrote on 5/21/2014, 6:00 PM
"

Apples and oranges once again, Norman.
DNxHD 444 LE (the one we can download and use in Vegas), is 440Mbps YUV, 4:2:2 chroma subsampling.

Your link to a marketing blurb for another codec, DNxHD MXF, a commercially licensed product, does not alter the facts a bit (that's on page 5). That said, if you'd like to license the source and compile it yourself for Vegas under Windows, we'd love to see it!!

I don't need a pdf to tell me what the MOV files are, because I use the LE codecs every week. I will say though, that lately you've become better at attempting to check your facts before posting.
;?)

musicvid10 wrote on 5/21/2014, 6:45 PM
Mark_e,

The answer to your question was uncovered by Laurence a while back. In a nutshell, 10 bit YUV will preserve the full bit depth (available colors) from 8 bit RGB source, but 8 bit YUV will not.

All the mystery as to why my 10 bit DNxHD intermediates had less banding than the 8 bit ones, disappeared the minute he explained that to me. And it changed my mind regarding some other things I had said previously on the same general topic, despite the fact that other explanations found on the internet were equally flawed.

Chroma subsampling differences are more subtle, but can be differentiated on something like the Belle-Nuit charts. Encoding 4:2:0 source to 4:2:2 (or 4:4:4) will not change the net result, all else being equal.
NormanPCN wrote on 5/21/2014, 7:55 PM
Apples and oranges yet again, Norman.

Show us a document that states this codec spec you say. 4:2:2 444Mbps. Avid has nothing anywhere that lists that as a valid codec stream, or that Quicktime wrapped files support different and unique code streams.

Why do you assume MediaInfo is correct?

If you look at the MediaInfo source code, you will see that it always outputs 4:2:2 period. Procedure File_Vc3::Streams_Fill(). You can compare some other formats to see that 4:2:2 is hard coded for DNxHD/VC-3. For example file_hevc.cpp, Hevc_chroma_format_idc function.

MXF is not a codec. It is a generic file container. The DNxHD codec stream is independent of its container. Yes, page 5 talks about MXF, but in the exact same paragraph it mentions that DNxHD is also made available in Quicktime format. That is the only location in the document that mentions MXF and that same paragraph also mentions Quicktime.

My facts are fine. I reference company documents, and application source code. If you find something, then I will accept that. Until something concrete is referenced, I accept Avid's word as truth.
;?)
musicvid10 wrote on 5/21/2014, 9:03 PM
Norman,
It took me a while to catch on to this; references to Avid codecs that are not appended with "LE" don't apply to us Vegans. at least not at this time. DNxHD 444 MXF does not open in Vegas, and the reason is not the wrapper. It uses a different source, which was made licensable only very recently Nor is it natively portable to Quicktime, of which the LE* version has been around four years or so. So rather than making demands, why don't you simply point us to the legal, free download of DNxHD MXF?

*LE stands for "Light Edition," according to Avid.

You can see as clearly as me or anyone that the Belle-Nuit rendered version below displays a distinctive 4:2:2 fingerprint. That is indisputable, even if you insist on not believing me and MediaInfo. Again, I actually work with this stuff, not only read about it.

Coincidentally, I worked closely for over a year with the libavcodec developers to get DNxHD LE 444 working in Handbrake and Linux (see the docs for libav10 and the archive of Bug #99). In that year (it was dormant for a long time), with dozens of emails and samples changing hands, not once did anyone involved offer up the notion that it was anything but 4:2:2. You would be suggesting that the guys who wrote the decoder are wrong too?

Now that you have the proof you asked for, I'm not going to debate this notion of yours further. Eagerly awaiting your port of the MXF to Vegas.
Best.



And here, of course, is the 4:4:4.