Cineform Decoder now in ffmpeg

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