[Ffmpeg-cvslog] Re: ffmpeg-cvslog Digest, Vol 20, Issue 23

[Steve Lhomme]

> >>> It can take very little code to actually handle basic matroska files,
> >>> once you have the EBML layer working. (MOV and AVI hide this code in
> >>> riff.c in lavf).
> >> The rather large size of all known matroska demuxers seems to
> >> contradict that statement.
> >
> > Can you give examples instead of just waving things in the air ?
>
> Sure:
>
> $ cd ~/src/tcvp/src/demuxer
> $ wc -l avi/*.c
> 1094 avi/avi.c
>
> $ wc -l matroska/*.c
>   285 matroska/ebml.c
>  1269 matroska/matroska.c
>  1554 total
>
> $ wc -l mpeg/mpegps.c
> 697 mpeg/mpegps.c
>
> $ wc -l mpeg/mpegts.c
> 842 mpeg/mpegts.c
>
> $ wc -l ogg/*.c
>    66 ogg/flac.c
>   603 ogg/oggread.c
>   162 ogg/ogm.c
>   111 ogg/theora.c
>   146 ogg/vorbis.c
>  1088 total
>
> $ cd ~/src/ffmpeg/libavformat
> $ wc -l avidec.c gxf.c matroska.c mov.c mpeg.c mpegts.c mxf.c
>    984 avidec.c
>    516 gxf.c
>   2720 matroska.c
>   1794 mov.c
>   1824 mpeg.c      # includes muxer
>   1527 mpegts.c
>   1078 mxf.c

Again, you're comparing pears and apples. None of these formats allow the amount
of stuff matroska does. Either by design or by lack of standard way to do it.

I also forgot the flexibility of matroska (the basic reason the overhead is so
small) meaning you can remove/add elements wherever you want without breaking
playback on previous demuxers (as long as they comply to the specs). RIFF
formats can probably do that too, at the expense of large overhead and
ugliness.

I'm not saying that matroska is the smallest container in term of code size. But
everything comes as a compromise between code size/file size/upgradability. And
the only thing that was done for code size is to have as many elements as
possible not mandatory.

> >> And people say that matroska "just works", LOL. Maybe, but at what cost.
> >
> >
> > You must be right and people must be wrong then.
>
>
> I didn't say it doesn't work: I said that in order to make matroska
> "just" work
> the cost (in terms of development) is _huge_

Well, AFAIK you can play matroska on cellphones and PDAs and they have quite
limited resources. So I consider this a not so important point when considering
matroska as a choice.

(playback via http://www.coreplayer.com/)

> >> From: Nico Sabbi <nicola_sabbi at fastwebnet.it>
> >>
> >> Steve Lhomme wrote:
> >>
> >>> Let me see, Matroska handles more formats than any other format,
> >>> handles attachment,
> >>
> >>
> >> attachments? external files look much more attractive to me
> >
> >
> > Album/DVD covers ? Fonts ? These are all in use today and for good
> > reasons.
>
> ah, I forgot to ask: what's the advantage of replicating a whole dvd
> (including
> the navigation structure) in a mkv file when you can have exactly the same
> content and functions in the udf image? embedding the cover maybe?
> add a mydvd.png image in the same directory and the job is done

Maybe store a DVD on a CD ? Studios are about to sell movies as downloads to
own. And space is an important factor. I think people will be interrested to
get the same in their downloads as if they bought the physical medium.

You could also transcode a DVD to be played on a QVGA screen (PMPs), without
losing the DVD features.

An album cover (and possible booklet) could be handled as a separate file. But
it would mean extra work when synchronising with devices/computers.

--