![]() |
Re: CineForm SDK is now open source
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. |
Re: CineForm SDK is now open source
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 ? |
Re: CineForm SDK is now open source
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.
|
Re: CineForm SDK is now open source
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. |
Re: CineForm SDK is now open source
> 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. |
Re: CineForm SDK is now open source
Quote:
So it's purely a 'VDFM thing'. OK, all clear now. |
Re: CineForm SDK is now open source
Quote:
|
Re: CineForm SDK is now open source
Quote:
|
Re: CineForm SDK is now open source
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?
|
Re: CineForm SDK is now open source
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.
|
Re: CineForm SDK is now open source
|
All times are GMT -6. The time now is 11:28 PM. |
DV Info Net -- Real Names, Real People, Real Info!
1998-2025 The Digital Video Information Network