[FFmpeg-devel] [PATCH] Matroska Muxer

[Aurelien Jacobs]

On Thu, 6 Sep 2007 01:14:31 -0400
David Conrad <umovimus at gmail.com> wrote:

> On Sep 5, 2007, at 3:59 PM, Aurelien Jacobs wrote:
> 
> > On Wed, 5 Sep 2007 15:24:09 -0400
> > Alexander Strange <astrange at ithinksw.com> wrote:
> >
> >>
> >> On Sep 5, 2007, at 1:52 PM, Michael Niedermayer wrote:
> >>
> >>> Hi
> >>>
> >>> On Wed, Sep 05, 2007 at 07:37:18PM +0200, Reimar D?ffinger wrote:
> >>>> Hello,
> >>>> On Wed, Sep 05, 2007 at 01:13:30PM -0400, Alexander Strange wrote:
> >>>>> On Sep 5, 2007, at 9:33 AM, Reimar D?ffinger wrote:
> >>>>>> On Wed, Sep 05, 2007 at 03:15:06AM -0400, David Conrad wrote:
> >>>>>> [...]
> >>>>>>> As for using it, pretty much any valid command line that starts
> >>>>>>> with
> >>>>>>> ffmpeg and ends with .mkv should work, e.g. "ffmpeg -i  
> >>>>>>> blah.ogg -
> >>>>>>> vcodec mpeg2video -acodec ac3 blah.mkv" It can also be used from
> >>>>>>> mencoder, e.g. "mencoder blah2.avi -ovc lavc -oac faac -of  
> >>>>>>> lavf -o
> >>>>>>> blah2.mkv" but it's possible to produce invalid files that way.
> >>>>>>
> >>>>>> Could you give details how and under which circumstances this
> >>>>>> produces
> >>>>>> invalid files?
> >>>>>
> >>>>> It creates native-order H264/MPEG4 streams for -ovc x264 and -ovc
> >>>>> xvid, but stores avi-style streams.
> >>>>
> >>>> Well, I somehow feel this is a bit of a design problem with mkv,
> >>>> requiring special handling for each supported format (though at  
> >>>> least
> >>>> the handling is much more sane than ogm and possibly more sane
> >>>> (but less
> >>>> consistent) than for AVI).
> >>>> I'm not sure there is a really good fix (beyond special cases  
> >>>> for the
> >>>> most common codecs), since mencoder is supposed to
> >>>> handle e.g. binary codecs nobody ever heard of and are not in SVN
> >>>> - so
> >>>> for these cases avi-style seems to be the only option.
> >>>>
> >>>>> There's no extradata and all frames have increasing pts even if b-
> >>>>> frames are on. (like the big warning says, I guess)
> >>>>
> >>>> That's exactly why I asked, because the warning is gone since
> >>>> quite some
> >>>> time I thought...
> >>>
> >>> vglobal=1:aglobal=1 are needed to get the proper extradata
> >>> this should be automated yes and a patch is welcome (the muxer say
> >>> through
> >>> a flag if it needs global stuff and that should be passed to te
> >>> encoder
> >>> somehow ...
> >>>
> >>> and the monotone PTS are odd, it was working properly when i
> >>> disabled the
> >>> warning though that was with mpeg4 encoding IIRC
> >>>
> >>> can someone check where the pts go wrong?
> >>>
> >>
> >> The pts/frames are actually in the right order with -ovc lavc,
> >> but with -ofps 120000 the video goes 4x as fast as it should (as if
> >> it was -fps 120000),
> >> and without it the a/v goes out of sync since it's VFR.
> >> Anyway, these are architectural failings in mencoder, so this is
> >> isn't really the right thread.
> >>
> >> The only problem I see in the muxer so far is it sets "V_MPEG4/ISO/
> >> SP" instead of ASP when I have b-frames on.
> >> This is because it's listed first in matroska.c, and matroskaenc.c:
> >> 548 just takes the first string with the right codec ID.
> >> With this it always sets ASP instead of SP, which isn't really right
> >> either but is what mkvmerge does:
> >
> > Patch OK (but I'm not mkv muxer maintainer, so let's David approve  
> > it's
> > first patch on code he maintains ;-).
> 
> Yep, it's good; I doubt that not using SP when possible matters  
> except perhaps for hardware devices which may or may not be  
> manufactured sometime in the future.

Right, and I doubt that there is or will be any hardware which
supports mkv but doesn't support ASP...

Aurel