CineForm SDK is now open source

[Bryan Worsley]

I agree, it's an excellent tool. And he (shekh, the VDFM devloper) added 'Filmscan 3' as the max quality level as well:

https://forum.doom9.org/showthread.p...80#post1826780

Over-kill maybe for highly compressed sources, but it's always good to have 'near-lossless' (beyond 'visually-lossless') options.

Nice to have the 8-bit 422 option also. In 32-bit Float processing systems like DaVinci Resolve at least, I'm not convinced that transcoding 8-bit sources to a 10-bit intermediate really improves colour scaling precision, contrary to popular belief. I believe what you are seeing is primarily the smoothing (debanding) effect of dithered noise when 8-bit sources are padded to 10-bit. And likewise when 10-bit exports are dithered back to the usual 8-bit target formats. On balance, for 8-bit material I think it's best to stay in 8-bit. Shame Resolve doesn't give an 8-bit 422 Cineform export option. There's DNxHD in both 10-bit and 8-bit flavours but I still prefer Cineform as an exchange format in my workflows.

[Bryan Worsley]

I have a question though David, if you are looking in. The github documentation for the Cineform SDK states, quote:

....Pixel formats supported:

8/10/16-bit YUV 4:2:2 compressed as 10-bit, progressive or interlace....

https://github.com/gopro/cineform-sdk

So if the 8-bit YUV 422 variant (now given as an option in VDFM) is actually 8bit YUV 422 'compressed' as 10-bit, which I'd assume to mean 'padded' to 10-bit, what is different in the conversion of an 8-bit YUV 422 source to the 10-bit YUV 422 variant ? Is there actually some clever bit-depth re-scaling going on or is it still 8-bit data packaged as 10-bit ? Or is the 8-bit YUV 422 variant actually just that - compressed as 8-bit with no padding ?

[David Newman]

8-bit is shift up to 10-bit, lower two 2-bits are zero. This is no 8-bit YUV encoding mode, always 10-bit.

[Bryan Worsley]

Which leaves me wondering then what bearing the 8 or 10-bit 'intermediate bit depth' option in the VDFM Cineform settings has on the outcome if 8-bit sources are always padded to 10-bit?

Maybe I would be better addressing that point with the VDFM developer himself, but it must surely derive from provisions set in the sdk.

[Anton Shekhovtsov]

> Which leaves me wondering then what bearing the 8 or 10-bit 'intermediate bit depth' option in the VDFM Cineform settings has on the outcome if 8-bit sources are always padded to 10-bit?

1) Bandwidth. If all you care about is 8 bits it is more efficient to send it to CineForm as 8 bits and let the codec do its padding in place.

2) CineForm actually remembers what was the original format. It is good to know for decoding IMO because I can decode it to same 8-bit format as it was originally and not worry about losing 10-bit precision which did not exist in the original.

3) Also there is scaling conventions issue: it can be done differently. If you have any doubt how exactly bit depth change works and what piece is responsible for it, it is best to just have the same bitdepth for both encoding and decoding.

[Bryan Worsley]

Originally Posted by Bryan Worsley

Which leaves me wondering then what bearing the 8 or 10-bit 'intermediate bit depth' option in the VDFM Cineform settings has on the outcome if 8-bit sources are always padded to 10-bit?

Maybe I would be better addressing that point with the VDFM developer himself, but it must surely derive from provisions set in the sdk.

Ah, OK, after testing some native 8-bit and 10-bit 422 source clips, I've got it. The 'intermediate bit depth' option literally sets the bit depth of the VDFM output to the Cineform encoder. By default, VDFM decodes 10-bit YUV sources to YUV422P16 (16-bit 422 planar) and internally converts that to YUYV (YUY2, 8-bit 422) as the encoder feed. Setting the 'intermediate bit depth' option to 10-bit forces the decode and output format to v210 (10-bit 422), so preserving the 10-bit process chain. On the other hand, 8-bit 422 sources are decoded as YUYV (YUY2, 8-bit 422) by default. What setting the 'intermediate bit depth' to 10-bit does in that case is to force VDFM to perform the 8-bit to 10-bit conversion internally and supply the Cineform encoder with v210.

So it's purely a 'VDFM thing'. OK, all clear now.

[Bryan Worsley]

Originally Posted by Anton Shekhovtsov

> Which leaves me wondering then what bearing the 8 or 10-bit 'intermediate bit depth' option in the VDFM Cineform settings has on the outcome if 8-bit sources are always padded to 10-bit?

1) Bandwidth. If all you care about is 8 bits it is more efficient to send it to CineForm as 8 bits and let the codec do its padding in place.

2) CineForm actually remembers what was the original format. It is good to know for decoding IMO because I can decode it to same 8-bit format as it was originally and not worry about losing 10-bit precision which did not exist in the original.

3) Also there is scaling conventions issue: it can be done differently. If you have any doubt how exactly bit depth change works and what piece is responsible for it, it is best to just have the same bitdepth for both encoding and decoding.

I agree with you on all points Anton. It was just a matter of figuring out what these settings meant in the context of the VDFM implementation of the Cineform SDK. Interestingly, when I ran those tests with 8-bit 422 sources I found that when the Cineform encoder was allowed to perform the 8-bit to 10-bit conversion, the encoding rate was faster and the resulting encodes were of slightly higher quality (as judged by quality metrics - SSIM) than when the 8-bit to 10-bit conversion was carried out internally by VDFM - which bears out your your first point.

[Bryan Worsley]

Originally Posted by Bryan Worsley

Maybe I would be better addressing that point with the VDFM developer himself, but it must surely derive from provisions set in the sdk.

Hey Anton, or should I say Shekh, I just realized it's you. Thought the name was familiar but couldn't put my finger on it. You're a very unassuming guy for all the astounding work you've done breathing new life into VirtualDub.

[Jack Zhang]

Late to hear this news. So this is the codec only, right? Not the chroma upconversion tech that made HDV 4:2:0 look like amazing 4:2:2 back then?

[David Newman]

Yes, just the codec. However the 4:2:0 handling has got a lot better in third party tool since the HDV days. I think CineForm was just one of the first to do it correctly, there wasn't any secret sauce.

[Bryan Worsley]

A quick plug:

http://www.dvinfo.net/forum/panasoni...ml#post1940187