CineForm Goes Open Source
cineform.blogspot.comThis is very exciting news. I've been a huge proponent of CineForm in the production pipeline for several years now. Glad this finally happened.
Aren't the files too big ?
For distribution, yes. But for production and post-production that's fine.
I understand it's an intermediate codec. It seems that it's even heavier than ProRes XQ so I'm wondering but yeah, hard drive are cheap now
Generally CineForm is lower bit-rate for the same quality as ProRES. See https://blog.frame.io/2017/02/13/50-intermediate-codecs-comp... for an independent analysis.
I am interested to see how the patent side of this shakes out, it seems to be a minefield for video codecs. Is there some scenario where going open source exposes the authors/companies involved to potential trouble?
Releasing under Apache License Version 2.0 seems to cover the normal bases with its Grant of Patent License. What are the compelling reasons to choose to use the MIT alternative?
It would seem that CineForm is inherently simple, so perhaps it does not infringe on any of the "more clever" codec's inventions (AKA patents). I imagine GoPro ran it through legal before doing this.
Was the idea. CineForm was developed to avoid patents in 2001, by using technology that patents had already expired: 2-6 blockless wavelets, RLE and Huffman entropy encoding -- this is about that is used to make CineForm. Simplicity is what drove performance, wavelets over DCT is what helps in quality.The patent mind-field is in distribution codecs that strive for the lowest possible bit-rate, which was not a design goal for CineForm. Declaimer: I'm the author of the linked article.
That you can do whatever you want with it as long as you give proper credit to the authors when distributing work based on the licensed code:
"Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."
MIT license is acceptable in GPLed projects, so potentially FFmpeg could inline the encoder.
160k LOC ? Sounds a lot...
Great news anyway. Can't wait to see this in FFmpeg !
ffmpeg has had a CineForm decoder since Jan 2016: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/cfhd...
Yes, but not an encoder, and that's the piece preventing it from being used to its potential. It's also nice when you no longer have to reverse-engineer the decoder. FFmpeg is one of my favorite things on earth, but minor differences between its implementations of closed-source codecs unfortunately prevent it from being a viable alternative in high-end post-production in many situations. ProRes encoding in FFmpeg for instance, although it certainly "works" as far as one can tell, still usually fails a few tests during the QC processes the bigger media companies use, and that generally means you can't use it, full-stop.
Can we find thoses quality control tests online ? I'm very interested in knowing what's wrong.
Anyone have any thoughts on whether this could be implemented on the GPU? (e.g. CUDA) Especially encoding.
The 2-6 integer wavelets would be very fast on a GPU, although they are almost too simple. GPUs struggle more this the entropy encoding/decoding, which is what a prevented a GPU port in the past. Do any GPUs have generic Huffman cores now?
What would be the use case for GPU encoding? Aren't the CPU encoders fast enough on 8-core or higher ?
Could gopros in the future be configured to save in cineform directly from the device? I have a 128gb SD card and have always wanted to get a compression with less loss than protune.