Just in case you missed the news, the CineForm SDK for encoding and decoder any CineForm images is now open source. read more

Blog: GoPro/CineForm Insider: CineForm Goes Open Source (http://cineform.blogspot.com/2017/10/cineform-goes-open-source.html)
Byline: https://gopro.com/news/gopro-open-sources-the-cineform-codec
GitHub: https://gopro.github.io/cineform-sdk/

Very cool!

Excellent news, David.

Wow! Top news! Has been one of my fave codecs since its inception. Now hopefully others will pick it up.

That's really cool David! Congratulations. And thanks!

Thought that would never happen ! Finally some prospect of a Cineform encoder in ffmpeg. Also the existing ffmpeg Cineform decoder, that was developed by reverse engineering, is not well optimised; the original code is several times faster and has all features, so hopefully someone will port it also.

The latest Lightworks V14.1 beta now has CineForm as an option for transcoding and exporting.

This is very good news. Selling cineform to gopro was a very big mistake. I hope some of the tools will also be available. Particularly the ability to multiplex and demultiplex 3d streams. I would also like to be able have a container wich supports cineform with 5.1 audio. As far as I am aware the avi and mov containers only support stereo with cineform.

> As far as I am aware the avi and mov containers only support stereo with cineform

Why do you think so? AFAIK there is no restriction of audio based on video. If some programs do impose such limitations they must be mad.

I think this is a limitation of many software implementations. Premiere cs6 has no option for the ciniform avi or mov and vegas crashes with avi and exports as 6 seperate streams in mov format.

Finally some prospect of a Cineform encoder in ffmpeg.

But not likely any time soon, as it would appear:

https://forum.doom9.org/showthread.php?p=1824682#post1824682

It is a interesting response.
"On that note, the code quality of the Cineform SDK and the fact that it doesn't present a clear and usable interface for clean integration (basically, its not meant to be a re-usable library) mean that any such attempts would require a *significant* effort to meet the FFmpeg guidelines."

See the odd thing is the CineForm SDK was designed to be a library to integrate the codec into third party video tools, has it has be now for over 10 years. It actually predates FFMpeg. Yes is wasn't designed with FFmpeg guidelines, that would be have hard to plan for. ;)

I took the liberty of relaying back your comment David.

VirtualDub-FilterMod also now has native Cineform support :

https://sourceforge.net/p/vdfiltermod/wiki/cineform/

I now using VirtualDub-FilterMod almost daily, as it has native deep-color support for CineForm and MOV I/O, so it is an excellent companion to Adobe tools which way prefer MOV (their AVI support in 8-bit only.)

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.php?p=1826780#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.

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 ?

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.

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.

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

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.

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

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.

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?

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.

A quick plug:

http://www.dvinfo.net/forum/panasonic-lumix-g-gf-gh-gx-series/535138-gh5-video-documentaries-some-questions-please-6.html#post1940187