I know Cineform is a proprietary codec, but is there any possibility of getting a Cineform decoder in the open source project. The encoder can stay in GoPro studio.

Why? For one, the best AVC/H.264 encoder is x264 which is GPL and thus cannot be directly included in commercial programs, like Vegas Pro. Tools like Handbrake and others are nice front ends to x264 and it would be nice to use Cineform as an intermediate to these external encoders.

I know GoPro studio install into Vfw, DirectShow and Quicktime but the open source world does not use these platform specific interfaces. These tools run on all platforms, and ones where these APIs do not exist.

This was brought up some years back:

http://www.dvinfo.net/forum/cineform-software-showcase/483035-cineform-playback-linux.html

I don't think anything has changed with Cineform on the open source FFMPEG front.

Have you considered maybe DNxHD as an alternative....the FFMPEG implementation that is?

I did a fair bit of comparative testing of intermediate edit formats a few months back (lossless and 'visually lossless'), including metric quality analyses.

Here are the results of one such series comparing Cineform and DNxHD (FFMPEG).

http://i1276.photobucket.com/albums/y475/WorBry/CineformvsDNxHD_zps3b4bd0a6.png~original (http://s1276.photobucket.com/user/WorBry/media/CineformvsDNxHD_zps3b4bd0a6.png.html)

In those tests I used the VFW Cineform codec (from GoProStudio) accessible in VirtualDub. For DNxHD I used a Zeranoe FFmpeg Windows (64-bit) build. The test video source was a native 1080/50p (H264) mp4 clip from a Canon HF-G30 camcorder converted to lossless HuffYuv-YV12 (FFMPEG variant). For the 1080/25p series, the same source was merely decimated (dropped alternate frames) from 50p to 25p. I let the respective encoders internally convert the 8-bit YV12 (4:2:0) input.

For the metric quality analysis, I used an AVISynth (filter) implementation of the SSIM (Structural Similarity Index) metric. The filter requires files in YV12 colorspace, so to enable comparison with the source it was necessary to convert the YUY2 4:2:2 outputs from the decoded Cineform and DNxHD files to YV12 4:2:0 - which is OK, as that is what I'd being doing in practice anyway prior to encoding to x264 or MPEG-2.

I appreciate that quality metric scores aren't everything (and can sometimes be misleading), but generally, to achieve an SSIM score of 97% and above, you are looking at a very high quality video reproduction. You could probably add another 0.05% to each of the scores, as that is around what is lost in the YV12 - YUY2 inter-conversions.

I think the results pretty much speak for themselves. In my estimation DNxHD (FFMPEG) is easily on par with Cineform. Interesting that 10bit DNxHD gave slightly higher scores than 8-bit DNxHD, with an 8-bit YV12 source.

I might add also that to get up around those SSIM scores with a (well optimized) 8-bit "intra-frame only" x264 encode, you'd be looking at comparably high bitrates, and even more so using 10-bit x264.

On that basis, I think the results pretty much speak for themselves. In my estimation DNxHD (FFMPEG) is easily on par with Cineform. Interesting that 10bit DNxHD gave slightly higher scores than 8-bit DNxHD, with an 8-bit YV12 source.

I've been reading a bit about DNxHD lately and considering switching to that codec for in-house Premiere CC projects that I shoot on my C100 + Ninja Blade.

In my estimation DNxHD (FFMPEG) is easily on par with Cineform.

Well, I was just about to modify that statement. More appropriate (less presumptous) might be "For my purposes, I'd have no issue using DNxHD (FFMPEG) as an alternative to Cineform as an edit intermediate for 8-bit AVCHD/H264 mp4 sources". I have no experience with higher bit-depth material.

Actually, my interest in DNxHD stemmed from a time when I was dabbling a little in Linux and KDenLive. For Windows though, I still think that Cineform has it all, on balance of quality, bitrate/file size and ease of use (speed).

One thing to bear in mind though is that with DNxHD you are restricted to the set bitrates that are available for the permitted frame resolutions, frame rates and pixel-format/bit-depths.

[FFmpeg-user] 10 bit DNXHD encoding (http://lists.ffmpeg.org/pipermail/ffmpeg-user/2013-January/012736.html)

And (for anyone still shooting HDV) there is no provision for anamorphic HD......at least in the FFMPEG implementation.

Can't say I know a whole lot about wavelet compression, but with Cineform, I can only assume the resulting bitrates (and so file sizes) are dictated by the transform coefficients and quantization parameters that are applied at the different quality levels. So in effect, Cineform encodes at 'Constant Quality'.

Perhaps, David Newman or one of his colleagues could elaborate?

That being the case, it would perhaps pay to test a wider range of source material (with varying degrees of complexity, motion etc) before drawing any firm conclusions about the relative performance of Cineform and DNxHD. Same goes for any 'codec comparison' really. Those metric test results I posted were obtained with just one test clip, after-all.

Another factor to consider when comparing edit intermediate formats is 'generational stability' i.e. the degree to which quality is preserved over successive re-encoding cycles. I did also look at that with Cineform some time back, using SSIM metrics again. Can't find the data now, but, as I recall, after the first encoding, there was little further loss in (metric judged) quality over 5 re-encode cycles, at least at Film Scan 1 level. I don't know how DNxHD compares in that regard. I did look at a few other DCT-based 'intra' formats though, including Matrox MPEG2 I-Frame and DVCProHD. Despite giving respectable metric scores on the first encode, both showed appreciable quality loss (metric and visually) after the first couple of cycles.

Still, it would be nice to hear back from Cineform as to whether there is any prospect, at all, of an fully open-source FFMPEG implementation of their codec. There's certainly been no lack of requests for it e.g.

http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=15&t=824
http://trac.ffmpeg.org/ticket/1087

CineForm has done the standards route, rather than directly open source. The first two parts of CineForm as a public standard are now published as SMPTE VC-5. Just like Avid DNxHD is VC-3. I will not speculate what that will mean for FFMPEG.

Your tests would be showing the quality of the color conversion pipe mixed with the compression itself. CineForm has no 4:2:0 input to its encoder, and via VfW we typically except 4:4:4 only at 8-bit (although the rare tool can get 4:2:2 to work.) So you are partly measuring the quality of your test environment. Another factor, we are designed for 10-bit or greater sources, we don't have an 8-bit internal profile. The is a minor hit in bit-rate encoding 8-bit as 10-bit, but for creative workflows where color correction will happen, this yields the best results. The technical measure of quality when compared with the 8-bit source has a minor decrease, but the subjective quality goes up.

Fun read: Post Magazine - 'Need for Speed': FotoKem ensures a smooth ride (http://www.postmagazine.com/Publications/Post-Magazine/2014/April-1-2014/Need-for-Speed-FotoKem-ensures-a-smooth-ride.aspx)

OK, thanks.


Your tests would be showing the quality of the color conversion pipe mixed with the compression itself.

I appreciate that. The 0.05% loss in SSIM score I mentioned was based on taking that same H264.mp4 test clip and converting to YUY2 4:2:2 (8-bit) and back.....all internally in AVISynth, so no intermediate encodes were actually generated. So there is inevitably some loss in the re-sampling, but it appears to be quite small in comparison.

CineForm has no 4:2:0 input to its encoder, and via VfW we typically except 4:4:4 only at 8-bit (although the rare tool can get 4:2:2 to work.)

Really? I was under the impression that the vfw Cineform codec does accept 4:2:0 input. If I feed raw 8-bit YV12 output from AVISynth to Cineform as a Fast Recompress (in VirtualDub), which should guarantee that there are no intermediary color format conversions, Cineform appears to encode OK - so, if it doesn't accept YV12, what is it receiving to encode?

And would you recommend then pre-converting YV12 to YUY2 4:2:2 (with appropriate chroma sub-sampling) for encoding to Cineform ? Easy enough to do in 8-bit with AVISynth.

Edit: Actually, having just dug out some of the files and scripts I retained from those comparative tests, I see now that I did actually pre-convert the decoded 1080/50p H264 mp4 clip to YUY2 4:2:2 and used a HuffYUV-YUY2 (not YV12) encode as the source for the tests; I was testing other 4:2:2 intermediate formats also (FFV1, ProRes, Canopus, MPEG-2 I-Frame) at the time, and so used a standard 4:2:2 source for all.

In routine practice though, I have been encoding to vfw Cineform on the assumption that it does (appear) to accept 8-bit YV12 input. Out of interest, what happens in GoProStudio then when native 8-bit H264 clips are converted to Cineform - are they pre-converted to RGB 4:4:4 as an intermediary step, and, if so, by what component?

Getting off topic a bit, I know, but I'd like to be sure about this.

The first two parts of CineForm as a public standard are now published as SMPTE VC-5. Just like Avid DNxHD is VC-3. I will not speculate what that will mean for FFMPEG.


So GoPro/Cineform does not require licensing and/or royalties, kind of like AVC and some other standards require under specific circumstances.

I'd still appreciate clarification the YV12 and YUY2 input query:

CineForm has no 4:2:0 input to its encoder, and via VfW we typically except 4:4:4 only at 8-bit (although the rare tool can get 4:2:2 to work.)


Really? I was under the impression that the vfw Cineform codec does accept 4:2:0 input. If I feed raw 8-bit YV12 output from AVISynth to Cineform as a Fast Recompress (in VirtualDub), which should guarantee that there are no intermediary color format conversions, Cineform appears to encode OK - so, if it doesn't accept YV12, what is it receiving to encode?

And would you recommend then pre-converting YV12 to YUY2 4:2:2 (with appropriate chroma sub-sampling) for encoding to Cineform ? Easy enough to do in 8-bit with AVISynth.


Is there any document that describes the color space transformations that Cineform performs?

Thanks.

I'd actually appreciate some practical info regarding the original post...
On Windows it is easy enough to bridge CineForm with whatever encoder you want through AviSynth/VirtualDub. What about Mac?
I can't find any tool that can connect the CineForm QT codec with ffmpeg/x264. The only solution I have is through Wine.
Is there anything available that I'm not aware of?
How about releasing a CLI decoder? It doesn't have to be open-source or integrated into ffmpeg, just provide raw video output that can be piped into another encoder...
This could be a solution for linux as well.
Thanks

There is actually a (developmental) linux port of AVISynth, called AVXSynth, that can be compiled on Mac OS:

https://github.com/avxsynth/avxsynth/wiki

I've no idea if or how it might interact with QT, but the resident guru's on the Doom9 forum could probably advise what's do-able:

AvxSynth: a Linux port of AviSynth - Doom9's Forum (http://forum.doom9.org/showthread.php?t=164386)

Thanks Bryan but I'm not sure trying to complie avxsynth or vapoursynth on osx is worth it at this point compared to running avisynth/virtualdub on wine, plus I'm pretty sure they only work with ffms2 input on *nix.

A native tool to pipe raw video to ffmpeg from quicktime/cineform would be great. Haven't found one yet, though.

Well you are obviously more up on this than me, but, reading around, yes, I think you are right about avxsynth and vapoursynth only working with ffms2 input.

Sorry to keep harping on about this, but I'd still appreciate clarification from Cineform on the query I raised earlier (Posts #7 and again in Post #9) regarding the vfw Cineform codec and direct YV12 input (via AVISynth). I know it was off-topic, but it's a pretty fundamental issue that I'd like to understand fully, and it would seem superfluous to ask the question again in a separate thread.

Thanks.

P.S. When you said "CineForm has no 4:2:0 input to its encoder, and via VfW we typically except 4:4:4 only at 8-bit (although the rare tool can get 4:2:2 to work." - is the '4:4:4' referring to RGB444 or YUV444 (YV24)? I've just looked at the AVISynth/VFW compressor interaction again using another codec - MagicYUV. This lossless (8-bit) VFW codec is in early development but does allow the supported input color-space to be specified, including RGB(24,32), YUV 4:2:0, YUV 4:4:4 and YUV 2:2:2. Again, If I feed raw 8-bit YV12 output from AVISynth directly to this codec in VirtualDub (set in Fast Recompress mode), it will only work if the input color-space is set to YUV 4:2:0 (YV12). So there is no way that any intermediary transformations are going on between AVISynth output and compressor input in FastRecompress mode.

So I am befuddled as to how vfw Cineform encodes from a YV12 source, when, according to your statement, it does not accept YV12 input. Surely there must be ancillary color-space transforms going on when native GoPro clips (8-bit H264) are converted to Cineform in GoProStudio? And if so, are these not part of the accessible vfw codec "complex"? And if that is the case, is YV12 being converted to RGB444 or YUV444 for encoder input? This is what I am trying to understand.

...
Why? For one, the best AVC/H.264 encoder is x264 which is GPL and thus cannot be directly included in commercial programs, like Vegas Pro. Tools like Handbrake and others are nice front ends to x264 and it would be nice to use Cineform as an intermediate to these external encoders.

....

Afaik the x264 commandline encoder accepts VfW through Avisynth, some others also accept VfW / Avisynth input.

FWIW, I have been transcoding AVCHD to DNxHD 10-bit 4:2:2 using, and for use in, Kdenlive. I preferred DNxHD to Cineform, I was discussing this with Bryan on another forum a while back.

The only way I know of to run Cineform on the Linux platform is to install Windows in VirtualBox, it will not work using Wine, although after a few bottles, who cares? Basically, Windows essentially becomes a Linux application and Windows applications can be launched from within Linux as if they are Linux packages. It is necessary to have a licensed version of Windows for this, but it means pretty much any Windows software can be run on Linux if you so desire.

I have changed to proxy editing, Kdenlive is set up for this and it is dead easy, so no more transcoding for me.

Dave