Cineform Decoder now in ffmpeg

[poisondeathray]

nice job kieranrk!

https://medium.com/@kierank_/reverse-engineering-the-gopro-cineform-codec-7411312bfe1c#.tcm0sjtmi

ffmpeg -codecs


.
.
D.V.L. cfhd Cineform HD
.
.



I know it's early but some early observations/test data

UHD 10bit 4:2:2 cineform stream

VFW decode through official cineform decoder (via avisynth, avsmeter) ~85FPS
ffmpeg decode ~15FPS

[smok3]

Interesting, so for now I can conclude that ffmpeg decoder is substantially slower than ffmpeg prores one?

[kolak]

Even if it's than give it some time and it will be way faster. Cineform can be faster than ProRes and because it's wavelet based than decoding to 1/4, 1/8 etc resolution can be blazing fast. It's quite useful feature to be able to watch 4K file at half res on very low CPU. You can't do it with any DCT based codec.
You should be able to decode 4K 60p Cineform on dual core i3 without problems. Original decoder is very fast, so lets hope ffmpeg will be the same soon.

[nevcairiel]

The FFmpeg decoder is not optimized yet, nor is it fully complete yet when it comes to all variations of CineForm, so yes, give it time.
From what I've been told by kierank, he thinks it can be made really fast.

[kolak]

Exactly- if original decoder can be fast than I'm sure community can make ffmpeg one very fast also.
Just typical optimisation gives 3-4x speed boost compared to some basic/first code no?

[Jamaika]

That's great! I was convinced that patents do not allow. Codec are not responsive to the color matrix. I think it is a bad writing yuv444p12le as gbrp12le (10 bpc).
Of course, I lack BT2020.

[kolak]

CF has 12bit RGB mode. You can have whatever video data you want as CF- rest is just flagging.

[Jamaika]

I'm surprised. AVI codec description is misleading.

[kolak]

AVI container is crap- no standardised matadata, timecode, field order etc.
You better to use MOV or MXF.

[kieranrk]

If you do have files that don't play - please let me know.

Upload them here:
https://trac.ffmpeg.org/ticket/1087

[smok3]

It does work for files that premiere calls "10 bit yuv" and does not work with files that premiere calls "12 bit RGB with alpha".

[Jamaika]

Test decoder Cineform yuv422p10le:
Three films and three different screenshots output.
http://i63.tinypic.com/2eggx7t.png
for %%f in ("%~dp1*.avi") do ffmpeg.exe -loglevel info -y -i %%f -ss 00:00:00.500 -f image2 -c:v png -frames:v 1 -pix_fmt rgb48be %%~nf.png
yuv422p10 noRGB, noBT709 | size file: 77.127.688
yuy422p10 RGB | size file: 83.961.528 --> color change
yuv422p10 BT709 | size file: 77.174.536 --> color change

[shekh]

AFAIK vfw encoder uses these options to convert RGB to YUV when you feed it RGB, but it does not store these options nowhere in video.
This is easy to confirm when you read from vfw back as RGB, the colors will be different depending on what options are set (while typing I got feeling that I need to doublecheck this again).
Btw from my research "use video systems RGB" has same meaning as "full range", can someone please confirm it.

edit:
I repeated my tests and now it looks more complicated.
"enc:709" option is always preserved within video. When sending RGB it is used for conversion. When sending yuv (v210) it is just saved without affecting data.
"dec:709" option is never used at all, instead it behaves like it is retrieved from the video.
"enc:video rgb" option affects conversion when sending RGB but never saved in video (or never retrieved by decoder, I have no way to know).
"dec:video rgb" used when decoding as RGB.

So what it means for ffmpeg decoder, at least it has chance to setup 601/709 choice.

[WorBry]

Re: the encoder.

Great stuff ! I can now convert some archived Cineform.avi edits encoded with the Cineform vfw codec (via AVISynth/VDub) to mov files for loading in DaVinci Resolve 12 (the Windows standalone version, now 12.5 beta). Resolve wouldn't even acknowledge the Cineform.avi files, but accepts the "re-wrapped" mov files just fine.

[shekh]

I can now convert some archived Cineform.avi edits...

Are you sure anything has changed? Re-wrapping does not care about cineform codec (avi->mov conversion worked fine for me 2 years ago).

ps. Glad you found the solution that suits you

[WorBry]

Are you sure anything has changed? Re-wrapping does not care about cineform codec (avi->mov conversion worked fine for me 2 years ago).

Oh you're right of course - it's just a direct stream copy.:o

I only started using Resolve a few days back, and every NLE I used or tried-out before (that supports third-party vfw codecs) accepted these Cineform.avi files without any problem. So I hadn't had need to convert to mov files until now.

Glad you found the solution that suits you

Yes, I was delighted to find that merely "re-wrapping" to mov is the solution. At first, I figured the reason why these Cineform.avi files were not accepted by Resolve was because they lacked some "legitimacy" metadata - given that the Cineform.avi render files created by Resolve are (of course) accepted as are those produced from GoPro Studio and Vegas.

[kolak]

You could make just QT ref files with QT 7 PRO and this should also work.

[WorBry]

I don't have QT 7 Pro, but thanks, that's useful to know.

[ianken]

Oh god, where was this last year when I had to build a solution to migrate 100k+ Cineform mezzanine files to H264? Oh, huge manatee!

[zcream]

Is the Cineform option also available in the OSX build ? Not sure if there are any extra options to include when I build with homebrew.

[kolak]

It should work with standard build.

[Malow]

Cineform is now open-source:

https://gopro.com/news/gopro-open-sources-the-cineform-codec

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

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

[kolak]

Great news!

[WorBry]

Thought that would never happen ! What do you think the prospects are then of seeing a Cineform encoder in ffmpeg any time soon?

[kolak]

I hope it will happen. ffmepg decoder is not very well optimised. "Original" code is few times faster and has all features, so I hope someone will port it.
Clineform due to its wavelet nature is quite unique and fact that you can now edit 4K streams at 1/2 resolution on i5 laptop in Premiere is amazing. No need for any proxy or optimised media.

[Midzuki]

What do you think the prospects are then of seeing a Cineform encoder in ffmpeg any time soon?

Assuming the answer from Paul B Mahol is to be taken seriously...

https://forum.videohelp.com/attachments/43740-1510717165/cineform+ffmpeg.png

[WorBry]

What an oddly worded reply from Paul B Mahol. I'm not a programmer, but if the quality of the coding is of "astonishing quality" (implying high level), surely that's a good thing - or is it just that he personally finds it too complex to tackle ? So is his the final word on the matter or do we hope for some other FFMPEG developer able and willing to step up to the plate ?

[kolak]

Yes, I was thinking about the same.

I'm not a programmer either, so don't understand what it's involved, but surely this is SDK, so you just plug into it. Don't have to re-write core.

[Rumbah]

I think it's irony (bad code quality and not well documented).

[kolak]

I couldn't decide if it's irony or not.
So it means ffmpeg code is total rubbish as it's few times slower for decoding :)

[nevcairiel]

Speed doesn't relate to code quality. But instead of wise-cracking here, maybe contribute improvements to ffmpeg? :)

[kolak]

Not directly, I understand this.
ffmepg code is written by many people and overlooked to have "fixed structure".
Cineform SDK was written by 1 (or 2) guys. You do write it very different in such a case. I know this from writing Python scripts.

This still doesn't change fact that Cineform SDK is few times faster than ffmpeg and I assume it can be speed up even further.
This just shows that ffmpeg code may have nice structure but it's far from being optimal. This applies to many parts of ffmpeg code.

I would help, but I'm not far good enough.

[Rumbah]

I couldn't decide if it's irony or not.
So it means ffmpeg code is total rubbish as it's few times slower for decoding :)

Actually it was meant the other way round. The code for integrating the SDK has to be maintained in ffmpeg. And if the SDK's code quality and documentation is not very good (and that is very likely in a 1-2 man project) then maintaining is nearly impossible.

[shekh]

To anyone. What do you think about the Active Metadata? Good/bad? Do you imagine it in FFMpeg? It is very weird part of the sdk...

[kolak]

It's quite cool. Industry is so legacy and lazy. Those sort of things should be already "present" years ago.
There was FirstLight (I think) programme which made a use of it. You could open video with it, do adjustment and if you had this file loaded in some player or NLE change were visible straight away.
Matada or rather active metadata is something very underestimated in my opinion. We still can't even pass properly simple things like color space etc properly, so maybe active meted is just to much :)
David's (guy who wrote Cineform) ideas were just to much ahead of the time and lacked support+money from bigger company. Even so he did manage to make it SMPTE standard.

[WorBry]

The code for integrating the SDK has to be maintained in ffmpeg. And if the SDK's code quality and documentation is not very good (and that is very likely in a 1-2 man project) then maintaining is nearly impossible.

So if Paul B Mahol was being ironic/sarcastic/snobbish and that actually is the case then, are all hopes of integrating the SDK in ffmpeg dashed ?

DaVinci Resolve 14.1 has now incorporated the Cineform SDK and I believe Lightworks Pro 14.1 beta and Hitfilm Express 2017 have also. There is this expectation that it is just a matter of time before FFMPEG incorporates full Cineform support.

https://hitfilm.com/forum/discussion/45239/cineform-now-fully-open-source

If that is not to be, it would be helpful to get an unambiguous statement from FFMPEG on that.

[shekh]

VDFM is also in the list. I think the FFMpeg statement was right there: "patch welcome" :)

[nevcairiel]

If that is not to be, it would be helpful to get an unambiguous statement from FFMPEG on that.

It all depends on the contributions of volunteers. Like already said above, contribute! Thats all the statement you'll ever get. FFmpeg already has a cineform decoder, so maybe someone will improve that based on the knowledge gained from the SDK, and maybe someone will clean up the encoder for integration, but until someone does, we won't know.

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.

[WorBry]

It all depends on the contributions of volunteers. Like already said above, contribute! Thats all the statement you'll ever get.

I would, but I'm not a programmer. Thanks for the explanation anyway.

[WorBry]

A comment from David Newman, who wrote the Cineform code:

http://www.dvinfo.net/forum/cineform-software-showcase/534863-cineform-sdk-now-open-source.html#post1939158

[kolak]

And there are quite a few software which did use of it and have direct integration.
Hopefully someone will take this task :)

[WorBry]

VDFM is also in the list. I think the FFMpeg statement was right there: "patch welcome" :)

Hey shekh, great to see that VDFM does now have native Cineform support also. Ran a quick test comparing Cineform (YUV 422 10-bit) avi encode bitrates at the different quality levels and they tally with those obtained with the vfw Cineform codec (v 9.2.1) from GoPro Studio (Quik).

But where did "Filmscan 3" come from ? Not that I'm complaining, but I was under the impression that "Filmscan 2" was the max quality level. I haven't done any quality metric tests (yet), but with the same source clip the bitrate of the 'Filmscan 3" encode was about 5% higher than that of the 'Filmscan 2" encode.

Edit:
I haven't done any quality metric tests (yet)....

With this one test clip (HD-AVC 1080/30p mp4) as source:

Bitrate (Mb/s) SSIM score (%)

Filmscan 3 346 98.28
Filmscan 2 327 98.09
Filmscan 1 239 96.43

And that's after converting the Cineform encodes back to YV12 for the AVISynth SSIM test.

[shekh]

From the sdk:


CFHD_ENCODING_QUALITY_FILMSCAN3, // overkill but useful for get higher data-rates from animation or extremely clean sources

[WorBry]

Thanks shekh.

[kolak]

FilmsScan3 is a "special" mode made for Disney for very clean sources. For typical or noisy source it may rise bitrate a lot for not much quality gain.

Cineform was made with idea of high-end RAW (or film scan) sources, not already pre-compressed ones. When you test it with h264 etc (or even already compressed ProRes) source it will tend to use relatively low bitrates even for FS2 mode. If you take some RAW source (RED, Arri) etc then it's a different story. It will nicely preserve quality over whole source.
Here is an example:

http://s32.postimg.org/u54dzr079/test.png

Great to see native Cinefrom in Vdub!

[WorBry]

Interesting. I knew 'Film Scan' per se was developed to accurately reproduce the grain characteristics in high grade film scans but had seen no mention of 'Film Scan 3' before:

https://cineform.zendesk.com/hc/en-us/articles/206528816-Understanding-CineForm-Quality-Settings

[kolak]

FilmScan3 or mode 6 in old cmd tools was rather a "secret" mode for typical users. You could turn it on with registry "hack" on PC.

[poisondeathray]

Ran a quick test comparing Cineform (YUV 422 10-bit) avi encode bitrates at the different quality levels and they tally with those obtained with the vfw Cineform codec (v 9.2.1) from GoPro Studio (Quik).


I'm not getting bit for bit identical the same result.... Very slightly different bitrate and differences on a 10bit422 source . Anyone else ?

[shekh]

Very slightly different bitrate and differences on a 10bit422 source . Anyone else ?

I am not sure it is possible to compare results bit-to-bit from current sdk vs vfw 9.2.1 implementation. Probably something was changed.

[poisondeathray]

There seem to be decoder differences as well , between ffmpeg and VFW (regardless if file was encoded with 9.2.1 or native vdfm sdk implementation)

Or how do you test "proper" 10-bit VFW decoding ? Maybe some testing methodology errors ? I'm testing in vapoursynth, with avisource and pixel_type="v210" . The differences don't look like a simple 10bit vs 8bit issue . And the difference pattern is quite different when testing v9.2.1 vs SDK


import vapoursynth as vs
core = vs.get_core()

c0 = core.ffms2.Source(source=r'F:\_Video Tests\QT Prores\cineform_filmscan2_native.avi')
a0 = core.avisource.AVISource(r'F:\_Video Tests\QT Prores\cineform_filmscan2_native.avi', pixel_type="v210")
#c0 = core.ffms2.Source(source=r'F:\_Video Tests\QT Prores\cineform_filmscan2_v9.2.1.avi')
#a0 = core.avisource.AVISource(r'F:\_Video Tests\QT Prores\cineform_filmscan2_v9.2.1.avi', pixel_type="v210")

d = core.std.MakeDiff(c0,a0)
da = core.std.Levels(d, min_in=511, max_in=513, gamma=1, min_out=0, max_out=1023, planes=[0,1,2])

da.set_output()

[shekh]

Can you post pictures with your results? And the source file.

[poisondeathray]

The original file is prores , then I used vdfm to encode either with native cfhd, or gopro v9.2.1 implementation
http://www.mediafire.com/file/fzxi5p7f6kikg74/ArriAlexa.PR422.BT709.v210.part1.rar
http://www.mediafire.com/file/pqrydie75vmv9bv/ArriAlexa.PR422.BT709.v210.part2.rar

I'm still investigating, but it looks like ffms2 issue (I'll try a few others later) ; but it also looks like recent ffmpeg.exe (zeranoe) decoding it incorrectly too when outputing v210 and checking the uncompressed stream. Looks almost like interlace issue

EDIT:
1) It seems like only the 9.2.1 streams are affected . The native implmentation encoded streams are decoded correctly by everything. ffmpeg, ffms2 derivatives all decode it incorrectly. Yet vdfm decodes it correctly. I had video format "automatic" for the 9.2.1 settings. I'll try with progressive

Yes that's it for that "interlace" issue. You have to explicity set progressive encoding settings for 9.2.1, otherwise ffmpeg, ffms2 exhibit the issue

2) Does the SDK expose progressive / interlaced settings ? I didn't see the option in the vdfm native implementation

3) But there are still differences between decoders. e.g when I test a native stream such as in post #50 . The ffms2 result is consistent with ffmpeg result (decoding to v210) as expected , but the VFW result is still different

[shekh]

This is what I see: https://s8.postimg.org/hpxoe38id/alexa.png
(Levels min_in=512-20, max_in=512+20)

The lower edge is maybe this problem: http://trac.ffmpeg.org/ticket/6675
Other parts look good to me.

Btw in VDFM there are 3 ways to decode CineForm, this way I saw some defects with different behavior across implementations.
1) Native: through caching input driver and default options
2) FFMpeg: through caching input driver and uncheck "Use native decoder" in open dialog options
3) VFW: through AVI driver

[poisondeathray]

Yes, some differences similar to that when testing VFW vs. FFMS2 in vapoursynth . I would expect on the decode side things would be identical for the same input stream . Not just the lower edge issue, but decoder should output bit identical, so the other parts don't look good to me in terms of testing (they look fine to naked eye when not testing differences)

I know it's work in progress, but it's supposed to be standardized STMPE VC5 , so results so be more consistent IMO . I don't know a thing about writing code. I can't even spel properly :D . I can only help by making observations and test


I'll look in the QT/MOV and Adobe implementation next . Do you know if it's based on the same SDK or did they do some tweaks ?


Is there a "reference" decoder ? Similar to JVT JM bitstream reference decoder for AVC streams ? I would assume it's the go pro implementation

[shekh]

But this is hacked ffmpeg decoder that makes this test look bad.
I just compared:
vfw decode of vfw.avi, vfw decode of native.avi, native decode of native.avi, native decode of vfw.avi: all appear bit-identical. I am lazy to run it through md5, just seeing perfectly gray difference.
I'm not getting bit for bit identical the same result....

So returning to your observation, how you see that?
Bitrate may be slightly different due to embedded metadata (things like encoding date etc).

Previously the sdk included compiled dlls, I doubt any at Adobe had source code. But I have no idea.

[poisondeathray]

Yes, the problem is the ffmpeg decoder (or derivatives , ffms2 etc...)

The not bit for bit identical results are from different decoder output. The ENcode side is ok

The ffmpeg decoder also requires 9.2.1 steams to select "progressive". When "automatic" is used for the encoding, they are decoded even more incorrectly. So something is written into the header that causes additional problems on top

[poisondeathray]

Actually there are differences between vfw decode of 9.2.1 encoded vs. vfw decode of vdfm native encoded . 1st frame is identical , as are a few others. But other frames are not.

But you said : "I am not sure it is possible to compare results bit-to-bit from current sdk vs vfw 9.2.1 implementation. Probably something was changed. "


a0 = core.avisource.AVISource(r'F:\_Video Tests\QT Prores\cineform_filmscan2_native.avi', pixel_type="v210")
ap = core.avisource.AVISource(r'F:\_Video Tests\QT Prores\cineform_filmscan2_v9.2.1_prog.avi', pixel_type="v210")

d = core.std.MakeDiff(a0,ap)
da = core.std.Levels(d, min_in=511, max_in=513, gamma=1, min_out=0, max_out=1023, planes=[0,1,2])

da.set_output()

[shekh]

It is probably possible to upgrade vfw codec to current state by replacing CFHDDecoder.dll etc. Not curious enough to try this right now :)
Which frame was most different?

[poisondeathray]

I don't know about "most" different, but

frame zero (1st frame) was the same
frame one (2nd frame) was different

Some frames later on were identical, some were different. Again this is on amplified differences. On plain difference you can barely see any differences

[WorBry]

Ran a quick test comparing Cineform (YUV 422 10-bit) avi encode bitrates at the different quality levels and they tally with those obtained with the vfw Cineform codec (v 9.2.1) from GoPro Studio (Quik).


I'm not getting bit for bit identical the same result.... Very slightly different bitrate and differences on a 10bit422 source . Anyone else ?

The actual results obtained with that one 1080/30p HD-AVC.mp4 (8-bit 4:2:0) source clip (795 frames)

Bitrate of Cineform avi encode (Mb/s) - no audio

Native VFW
Filmscan 2 327 326
Filmscan 1 239 239
High 169 168
Medium 133 133
Low 122 122


Same frame count in all cases. I didn't record the actual file sizes (in bytes).

Edit: And just for reference, same source clip transcoded to Cineform.avi with DaVinci Resolve 14.1 (at Full 'Data' levels), which uses a different terminology for the quality levels, just to confuse matters:

Bitrate Mb/s

Best (= Film Scan 2) 332
High (= Film Scan 1) 242
Medium (= High) 172
Low (= Medium) 135
Least (= Low) 124


Same frame count (795)

[kolak]

I'm not getting bit for bit identical the same result.... Very slightly different bitrate and differences on a 10bit422 source . Anyone else ?

I don't think it meant to be bit identical. You can ask this question David on github.
SDK and GoPro codec are not necessarily 100% the same.
Decoder should be the same I think.
I would not trust ffms2 at this point.

[kolak]

I know it's work in progress, but it's supposed to be standardized STMPE VC5 , so results so be more consistent IMO . I don't know a thing about writing code. I can't even spel properly :D . I can only help by making observations and test


STMPE VC5 is actually different to SDK and GoPro codec, even in codec structure. Not much but it's different. I assume this was enforced by SMPTE during whole process to make it "better".

[sneaker_ger]

Are the encoders deterministic in the first place? (i.e. encode twice with very same encoder gets same result?)

[kolak]

The actual results obtained with that one 1080/30p HD-AVC.mp4 (8-bit 4:2:0) source clip (795 frames)

Bitrate of Cineform avi encode (Mb/s) - no audio

Native VFW
Filmscan 2 327 326
Filmscan 1 239 239
High 169 168
Medium 133 133
Low 122 122


Same frame count in all cases. I didn't record the actual file sizes (in bytes).

Edit: And just for reference, same source clip transcoded to Cineform.avi with DaVinci Resolve 14.1 (at Full 'Data' levels), which uses a different terminology for the quality levels, just to confuse matters:

Bitrate Mb/s

Best (= Film Scan 2) 332
High (= Film Scan 1) 242
Medium (= High) 172
Low (= Medium) 135
Least (= Low) 124


Same frame count (795)

Resolve uses RGB pipe, so it will probably never be the same.
As I said- I don't think you should expect bit identical encodes (definitely not from Resolve).

[kolak]

Are the encoders deterministic in the first place? (i.e. encode twice with very same encoder gets same result?)

Within the same implementation I think they are.

[shekh]

Found something interesting.
Native encode in single threaded mode: identical results to vfw 9.2.1 (compared 4 frames).
Native encode in multi threaded mode: only 1st frame is identical. Looks like temporal dithering behaving differently.

[kolak]

Maybe it's the number of threads which is set differently for 2 encodes (codec uses some setting, SDK other).
Even if it's different I don't think it's a problem at all.

[shekh]

I think vfw codec is using single-threaded method because there is no standard way to run vfw encoder asynchronously.

[WorBry]

Maybe it's the number of threads which is set differently for 2 encodes (codec uses some setting, SDK other).

In that 'quick test' I did the native encoder was set for multi-threading.

Even if it's different I don't think it's a problem at all.

I'm inclined to think the same. IIRC, a year or so back when I did some tests comparing available Cineform transcoders, the results obtained with Adobe Media Encoder (file sizes, quality metrics) were different still.

[Jamaika]

Has anyone tried to compile Cineform codecs?
I read the article on Hitfilm, I downloaded the codecs. Unfortunately, GCC doesn't want to compile.
How do I set parameters for encoder testcfhd.exe?
usage: cfhd.exe [switches] or <filname.MOV|MP4|AVI>
-D = decoder tester
-E = encoder tester
ffmpeg.exe -i 111.tiff -f yuv4mpegpipe -vframes 1 -pix_fmt yuv420p - | testcfhd.exe -E=-
https://hitfilm.com/forum/discussion/45239/cineform-now-fully-open-source

[shekh]

The code was intended for Visual Studio. I compiled with GCC but had to correct few small things.

[kolak]

Has anyone tried to compile Cineform codecs?
I read the article on Hitfilm, I downloaded the codecs. Unfortunately, GCC doesn't want to compile.
How do I set parameters for encoder testcfhd.exe?
usage: cfhd.exe [switches] or <filname.MOV|MP4|AVI>
-D = decoder tester
-E = encoder tester
ffmpeg.exe -i 111.tiff -f yuv4mpegpipe -vframes 1 -pix_fmt yuv420p - | testcfhd.exe -E=-
https://hitfilm.com/forum/discussion/45239/cineform-now-fully-open-source

This is not how this app works.
It's very simple test app which you can simulate encoding or decoding. There is no piping support. Read description.

[Jamaika]

Unfortunately, I see it. What is this free software for?

PS Different developers call the test app. The simple test is for jpegxr and jpegls.

[kolak]

It's not a software. It's SDK which you can use to add Cineform import/export you your own app.

[Midzuki]

For what it's worth...

https://trac.ffmpeg.org/ticket/6863

[dipje]

That's the same ticket that has existed from the start.

FFmpeg-maintainers response is still the same and expected (and correct to be honest): "we welcome a patch" but they don't actively make stuff. They fix bugs, they don't do completely new implementations.
So it's up to someone to make it and submit a patch.

And most people don't want to go near it since it apparently isn't a 'neat' library or it doesn't compile on a lot of stuff.

Shame though, would be nice... But most people don't have the (free) time or the knowledge to work on this.

[nevcairiel]

they don't actively make stuff. They fix bugs, they don't do completely new implementations.

The Cineform implementation in FFmpeg right now was created by a FFmpeg maintainer, as have the majority of others in FFmpeg, so not sure where you are coming from.

But the fact remains that open-source development works on a simple concept: You need someone motivated to work on something. Integrating some external SDK is usually not much fun.

There is actually a GSoC task listed to improve the existing decoder both in missing features/bugs and speed, maybe a student will be interested in picking that up.