[FFmpeg-devel] [PATCH] Lost VBR header

[Peter Belkner]

On 17.04.2011 16:04, Reimar Döffinger wrote:
> On Sun, Apr 17, 2011 at 03:36:12PM +0200, Peter Belkner wrote:
>    
>> On 17.04.2011 14:32, Reimar Döffinger wrote:
>>      
>>> On Sun, Apr 17, 2011 at 02:02:56PM +0200, Peter Belkner wrote:
>>>        
>>>>     * As a better way to skip the VBR header seems to me to let it the
>>>>       MP3 decoder do. That's not only the place where it belongs to from
>>>>       a theoretical point of view (see above), but also MP3 streams
>>>>       coming from other formats than MP3 (as e.g. MKV, generated using
>>>>       lame/mkvmerge as above) will profit from it.
>>>>          
>>> And as far as I can tell if you concatenate two MP3 files with
>>> -acodec copy you end up with a VBR header in the middle.
>>>        
>> If you take this argument serious than you have to check for the VBR
>> header and possible skip it in /each/ demuxer for each
>> format/container possibly wrapping a MP3 stream, e.g. MKV too. Also
>> you have to introduce VBR header calculation into each muxer
>> potentially writing MP3, not only the MP3 muxer.
>>      
> What format are you thinking of where a VBR header would make sense?
> I may be missing some details, but having a VBR header in MKV seems
> really stupid to me, at best it is a source of contradicting information.
> It certainly isn't necessary for seeking or getting the overall time.
>    

The concept of the VBR header seems to me a hack by design. Not how 
FFmpeg deals with it, but the whole design. (Not only) FFmpeg just 
inherits the whole mess.

As long as third party tools store the VBR header with an MP3 stream 
contained in MKV FFmpeg should be able to deal with it.

As far as I can see mkvmerge 
(http://www.bunkus.org/videotools/mkvtoolnix/) is a kind of a reference 
implementation for a MKV muxer, and it does.

> Also your approach has yet more issues, e.g. copying the first 10 seconds
> of a 5 hour MP3 will result in a file that still claims to be 5 hours long.
>    

That's of course true. But again,

    * this happens now with /each/ MP3 processed by FFmpeg because
      that's exactly the effect from simply removing the VBR header (who
      thesese days deals with CBR?), and
    * the same will happen with MP3s wrapped in MKV (and other formats).


> Now, no first implementation has to be perfect, but certainly it is a very
> good idea if the design allows for doing it correctly.
> There is also the point that doing it in the muxer allows adding a VBR
> header to file ffmpeg broke previously.
>    

I'm certain that the best place is the muxer (as also hinted by 
Michael). But I don't agree that this should be the default behaviour. 
It should be done only on request of the client code (and not silently) 
because only the client code knows whether MP3s will be cut or added. By 
default the muxer should just mux all frames as given to it.

Peter