Cineform Issues

There are a few things regarding Cineform I've been meaning to post on for a while:

• Legacy NTSC Resolution support (720x486)
• Latest Cineform release

So for the first item... It appears I can't export content at 720x486, despite Resolve showing this as an option under delivery... and despite the codec being capable enough of exporting this resolution.

Any time I try at that res, it keeps spitting out the following error:

cineform_error.png (7.76 KiB) Viewed 3675 times

The second issue is that Resolve appears to be using a really old version of the Cineform codec... dating back to 2015... (GoPro Studio 2.5.8.0 / Cineform v9.2.1.108)... since then... Cineform has had numerous updates... gone Open Source (https://gopro.github.io/cineform-sdk/) and is now at a complete new revision (v10.0.2) including bugfixes and further optimizations.

So it begs the question... why not update the included Cineform libraries? I've actually compiled from the source and replaced the legacy libraries under Resolve with the new versions.

It's a good idea for here:

viewforum.php?f=33

486 is not mod 16 so Cineform does not support it.
There is still old and very bad limitation in Cineform code which requires dimensions to be mod 16.

486 is not mod 16 so Cineform does not support it.
There is still old and very bad limitation in Cineform code which requires dimensions to be mod 16.

I've gone through the source code and see no such limitation. The only reference I can see is multiples of 2.

I personally may suggest to stay away from Cineform, especially for SD interlaced video. It is not consistent abandoned codec now, it is very different from version to version. It seems it always force HD Rec709 color space even if video was actually SD with Rec601, so with SD video you will always expect tiny color shift in Resolve. It may produce artifacts due AVI vs MOV compatibility problems. I described some adventures with legacy Cineform here viewtopic.php?f=3&t=109259#p604955

486 is not mod 16 so Cineform does not support it.
There is still old and very bad limitation in Cineform code which requires dimensions to be mod 16.

I've gone through the source code and see no such limitation. The only reference I can see is multiples of 2.

Maybe it is due color sampling model https://forum.selur.net/showthread.php?tid=12 :

RGB: (4:4:4)

width no restriction
height no restriction if video is progressive
height mod-2 if video is interlaced

YUY2: (4:2:2)

width mod-2
height no restriction if video is progressive
height mod-2 if video is interlaced

YV12: (4:2:0)

width mod-2
height mod-2 if video is progressive
height mod-4 if video is interlaced

I personally may suggest to stay away from Cineform, especially for SD interlaced video. It is not consistent abandoned codec now, it is very different from version to version. It seems it always force HD Rec709 color space even if video was actually SD with Rec601, so with SD video you will always expect tiny color shift in Resolve. It may produce artifacts due AVI vs MOV compatibility problems. I described some adventures with legacy Cineform here viewtopic.php?f=3&t=109259#p604955

FFMpeg uses a hacked/reverse engineered version of Cineform - hence your issues. Resolve also converts 601 to 709 internally. FFMpeg developers refuse to incorporate the official open source version due to x86 specific targets. The rest of the commentary on it being "not consistent" and "abandoned" is pure speculation.

In my opinion Cineform is actually far superior to DNxHD and ProRes in a number of scenarios... for one it doesn't suffer from macroblocking issues. Far from being legacy, it has been been standardized by SMPTE as VC-5 only a few years ago.

I didn't claim that Cineform it totally bad codec, i told about problems when use that codec between different systems, different codec generations and and different OSes.

If workflow is simple and you work within single app, single OS and render/import to single version of current Cineform codec - it usually work ok.

But if you need to use Cineform files from different codec versions generated 10 years ago with different software - it may produce huge problems.
Codec consistency is very important thing. For example industry approved things like DV codec works in any modern app exact same as in 1995.
My additional problems with Cineform in past (probably fixed in new OSes and codec versions):
Gamma shifts between .mov vs .avi containers.
Active metadata disaster. It looked like nice idea, but in reality some apps read that Cineform active metadata some not, so your video may looked random in random apps. Total mess.
As i know there are no tools for quick lossless trim of Cineform files.

All Cineform history consists of endless changes, renames and bugfixes. It always feels like beta version. Nice technology but unlucky fate and inconsistent development. It don't feels like future proof thing for me, even if it weights slightly less than ProRes. Quality is also subjective. Compression vs Speed, Macroblocking vs too smoothed "plastic look" produced by wavelet compression.
Less codecs - more stable workflow. I prefer everything in ProRes that "just works" without any surprises and currently natively supported on Mac and Windows by most video editing apps, cameras, recorders and other hardware.

486 is not mod 16 so Cineform does not support it.
There is still old and very bad limitation in Cineform code which requires dimensions to be mod 16.

I've gone through the source code and see no such limitation. The only reference I can see is multiples of 2.

It has such a limitation:

"David Newman
We do have a mod 16 horizontal limit (not vertically.) Always had this. We might change this one day. Fortunately all the standard horizontal resolutions are divisible by 16: 320, 360, 704, 720, 960, 1280, 1440, 1920, 2048 and so on."

but horizontally (which I forgotten), so 720x486 should actually be fine.

There was 1 change in the Cineform code which broke compatibility if I remember well. After that point all files should be fine. When it comes to stability ProRes is the best implemented codec out there, mainly because Apple overlooks those implementations (with other codecs it's a free world).

Reviving this old discussion.

Now that ffmpeg 4.3.x has an implementation of Cineform, I thought I might check on the version of Cineform used in Resolve... and to no surprise, it's still the old v9.2 dating back to 2015.

Is there any technical reason preventing the implementation of the updated version that's now open sourced at https://github.com/gopro/cineform-sdk ?

All official Cineform release have mod 16 horizontal limit.
ffmpeg version may be different, but I haven't checked yet.

"Fortunately all the standard horizontal resolutions are divisible by 16: 320, 360, 704, 720, 960, 1280, 1440, 1920, 2048 and so on."

That begs the question of why Cineform fails at 2K DCI Scope. (2048 x 858)

Right. Failing here too.

And the old 720x486 fails as well.

Is it a Resolve specific arbitrary limit that's preventing the codec from being used with these resolutions?

These are Resolve related problems probably.
720 and 2048 should work.

It's actually the 858 that isn't working, which belies Newman's claim that there is no vertical limit in Cineform.

2048 x 1080 works fine.

David wrote that code so the knows what he is talking about

Resolve only issue. 858 vertical works fine with Cineform "core" code.

I suppose that can be tested by trying to encode 2K DCI in another program.

I just don't have any installed.

Exactly what I've done. Tested with Vdub2 which uses CF SDK and Premiere.

David wrote that code so the knows what he is talking about

Resolve only issue. 858 vertical works fine with Cineform "core" code.

Resolve really should fix this, it's a very simple fix.

Seems it was fixed in Resolve 17:
"Decoding and encoding GoPro CineForm clips with non multiple of 16 res."

Thanks, BM. I really like Cineform.

Not to rehash this thread again, but the Cineform codecs included with Resolve are still the old versions dating back to 2015.

There have been plenty of updates since then...

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

It's meaningless. Nothing changed in engine since 2015.
All files are compatible. 858 problem was a different problem, unrelated to used CF SDK.
There was some change in the core, but way before this (around 2005 or so).