[FFmpeg-devel] [PATCH] Lost VBR header

Reimar Döffinger Reimar.Doeffinger at gmx.de
Sun Apr 17 16:04:30 CEST 2011

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.
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.
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.

More information about the ffmpeg-devel mailing list