[FFmpeg-soc] [soc]: r208 - matroska/split-mkv-demuxer.diff

[Aurelien Jacobs]

On Wed, 13 Jun 2007 18:31:58 -0400
David Conrad <umovimus at gmail.com> wrote:

> On Jun 4, 2007, at 6:19 PM, Aurelien Jacobs wrote:
> 
> > On Fri,  1 Jun 2007 06:43:00 +0200 (CEST)
> > conrad <subversion at mplayerhq.hu> wrote:
> >
> >> Author: conrad
> >> Date: Fri Jun  1 06:43:00 2007
> >> New Revision: 208
> >>
> >> Log:
> >> Preliminary patch to split some common code that will likely be  
> >> used in the mkv muxer from the demuxer
> >
> > Ok, that's something needed.
> > As I had some pending changes for the matroska demuxer, and that I  
> > didn't
> > wanted to break your patch, I first applied your patch to ffmpeg.
> > I guess it can only ease your work, and you can now svn rm that  
> > diff file.
> > If you have more code to split later, this can be done directly in
> > ffmpeg repository.
> >
> > BTW: It's nice to see you already seriously started working on your  
> > SoC
> > project. I will carefully follow and review your progression.
> > Don't forget I'm available to reply any question you may have or to
> > help you if you have a problem.
> 
> And then I disappear for two weeks, sorry about that.

:-)   No problem.

> I now have the  
> muxer working with some video under a minute long, I'll commit the  
> changes shortly.

Great !

> Anyways some questions:
> 
> 1. Currently, for EBML master elements, I reserve the maximum 8 bytes  
> for the size in start_ebml_master(), which is obviously wasteful  
> since it's used for each frame which doesn't need the full 8 bytes.  
> I'm not sure how best to only use the needed number of bytes for  
> writing the size. I was thinking maybe passing an estimate of large  
> the master is going to be as a parameter to start_ebml_master(), but  
> I'm not sure how accurate I could make all the estimates, especially  
> for larger elements like clusters and segments.

I think giving an estimate to start_ebml_master() will be good enough.
It should be quite precise in most cases.
The only problematic cases are indeed clusters and segments but they
appear very rarely in the stream so it won't cause much overhead to
attribute them maximum size (full 8 bytes).

> 2. Since Matroska only allows one timescale per segment, how should I  
> choose this? Right now I always use 1/1000, which is what just about  
> every mkv file that I've seen uses, but should I select something  
> else based on the framerate of a track?

Most files uses 1/1000 but I've already seen mkv files with other values.
I guess the best thing to do is to use the biggest common denominator
between all the streams, but this won't work for VFR streams.
Thus, using 1/1000 seems to be a good compromise.

> 3. Currently, I only write SimpleBlocks instead of the more complex  
> BlockGroup.

That's fine.

> The main disadvantage I see with this is that older  
> parsers don't support it (lavf has only had support for 3 months,  
> since r8180),

lavf demuxer is lagging behind other mkv implementations in quite
some respect. So don't take it as a reference. Other demuxers
support this for long enough.

> so is it worth it to add an option to force Matroska v1  
> files to be written? And if so, how should that be done?

As long as no one complains that he can't play the mkv files produced
by ffmpeg, it's not worth to add support for Matroska v1.

Aurel