[FFmpeg-user] Technical specification for FFv1?
pb at das-werkstatt.com
Thu Mar 8 14:52:38 CET 2012
Zitat von Tim Nicholson <nichot20 at yahoo.com>:
> I have never tried FFv1, in the past I have used Huffman YUV, for lossless.
> However I am always open to new ideas.
I think it greatly depends on the use case of "why lossless":
For mass digitization and serious long-term archival purposes, it
makes a difference whether you can:
a) encode in realtime during capture
b) work with your lossless format
c) preserve the original video data as good as possible: preserve
colorspace, use 10bit, ...
Since about 2 years, computers are fast enough to handle FFv1 for all
these requirements. Huffyuv does not. It only supports yuv422/rgb -
and it's waaaaay bigger in filesize than FFv1.
We (and NOA Audio Solutions) have done some tests while evaluating
FFv1, and compared its performance and filesize to JPEG2k, as well as
Huffyuv - and in most cases FFv1's filesize is equal to JPEG2k - but
with amazing performance: It's currently still single-threading, but
outperforms multithreading-JPEG2k implementations.
Additionally, thanks to the widespread usage of FFmpeg's libav, FFv1
can be encoded/decoded with many tools out-of-the-box. On a regular
Show me an archive that is actually able to work with its *lossless*
(!) archive copy for production purposes - as smooth as that? ;)
> Having not tried FFV1, because I new nothing about it,I am interested to know
> what wrapper/format you use around the codec, and therefore what
> other metadata
> can be kept. (comments, timecode etc)
== About the container:
We're currently using AVI as container (unfortunately), due to its
widespread support within applications (across operating systems and
vendors). This is not the case for MOV.
Let alone MXF: Ask BBC, why they had to write tools to convert
MXF-to-MXF . Cross vendor/tool support: in your dreams!
I'd love to go for MKV (which seems like a very good container for the
job, regarding its widespread, and increasing support among
applications and hardware devices) - but we're not there, yet.
Additionally, among "professional" video people, it's tainted with
"That's what those DVD-pirates use! Bah."
== About the metadata:
I know that within the archival domain, "one container to rule them
all" is often propagated as a good solution - for example: MXF
However, as I've been dealing with long-term archival for over 7 years
now, I can say that in practice it's better to keep it "slightly"
a) Some metadata is bound to change over time (coding history,
descriptive metadata, etc) - but if its stored together with the
content in one file, it's difficult to do checksum-validation of those
b) Having to extract/embed the metadata from/into the container adds
additional effort. With data quantities of medium-to-large archives,
this adds a tremendous I/O effort for handling metadata.
c) In practice, having a small (few kB),
well-documented-and-based-on-standards XML (e.g. METS ) next to
your actual A/V content, makes life easier.
d) Long-term archival means infinite migration.
That's a hard one, but it's necessary. Stuffing everything in one
container sounds nice, but it's quite a gamble to find tools that will
actually be able to extract-and-migrate *every* bit of data you've
stored in your container.
There's way more about this topic - and it's a hot topic among
archivists - but that's at least an overview.
More information about the ffmpeg-user