[FFmpeg-devel] [PATCH] Matroska Muxer

David Conrad umovimus
Thu Sep 6 07:14:31 CEST 2007


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.

Applied.



More information about the ffmpeg-devel mailing list