[FFmpeg-user] Technical specification for FFv1?

[Peter B.]

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  
office computer!

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 [1]. 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."
Sad :(


== 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"  
separated.

Why?

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

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 [2]) 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.

Regards,
Pb

== References:
[1] http://ingex.sourceforge.net/
[2] http://www.loc.gov/standards/mets/mets-schemadocs.html