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. 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: I don't think anything has changed with Cineform on the open source FFMPEG front.
BLACK MASK Friday, May 17, 2013. In 1967 it was reported by Science magazine that at the US government center in Fort Detrick, Maryland, dengue fever was amongst those 'diseases that are at least the objects of considerable research and that appear to be among those regarded as potential BW [biological warfare] agents.' 52 Over 239 open-air.
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). (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. 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 (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. 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).
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. 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? 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. 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.
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. 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.
Curious after other posts here regarding the downloadable Matrox digi-suite codecs, I installed the pack and ran a quick test or three. Hope this might prove helpful. First off a disclaimer: Doing my best to be objective, I none-the-less dislike Matrox wholeheartedly, so in case any bias does creep in - sorry. Package installation with XP Pro installs the Matrox mjpeg codec as well, setting it to primary, possibly (probably) overwriting &/or disabling whatever you're using now.
Best bet is to have your current mjpeg codec installation files & numbers handy, so you can reinstall as needed. As one example of what can happen in XP Pro, the Matrox install will make picvideo mjpg avi files not display in VV4c, picvideo mjpg will not show up with the other codecs in any dialog, and any picvideo mjpg encoded videos might play somewhat poorly in wmplayer, even though it says it's using the picvideo decoder. One thing that the Matrox pack does do is give you a more Video For Windows compatible DV codec, one that will allow DV encoded files to be opened in stuff like V/Dub. In a post a few days ago I was talking about this, and how (at least when I tried it then and there) avi files encoded with the SOFO DV codec would not open in V/Dub etc.
If you look at the file info in V/Dub, after opening any DV encoded avi file, it shows the Matrox decoder being used. A few cautions. Using one decoder and another encoder can be iffy - if you want/need VFW support, might be better off rendering to the Matrox codec to begin with, or at least run a short test file to make sure everything's cool with your planned work flow/path. The Matrox codec is also a bit older (C) 2000 - which might or might not mean a thing.
On an XP Pro system with later WMD drivers etc., VFW support is reduced already so I don't/can't know how this codec will work in all situations, and it will take the place of the MS decoder that natively plays/handles DV files or whatever codec windows currently uses, ie: whatever might have been installed with your camera/firewire card. That said, perhaps it will be useful to some folks not needing the other codecs that come in the package.
An XP Pro install includes the mjpg, DV, mpg2 I-frame, DVCPRO, & DVCPRO50 codecs.