The patch below provides exactly that to the MP3 muxer. A XING header
containing
* the numer of frames,
* the size, and
* a TOC
is generated.
It's based on an idea by Anton Khirnov (restricted to the number of
frames) found at
http://patches.ffmpeg.org/patch/1891/
The TOC is generated as found in lame's "VbrTag.c".
According to my tests the following reproduces the number of frames, the
size and the TOC in "c.mp3" from "b.mp3" (except a shift due to shorter
XING header generated by FFmpeg):
lame -V2 a.wav b.mp3
ffmpeg -i b.mp3 -acodec copy -y c.mp3
This fixes, for instance, the case that there is a track that has some samples with composition time offset and has a track run without sample-composition-time-offsets-present.
Add an extra size validity check in asf_read_frame_header(). Without
this asf->packet_size_left may become negative, which triggers an
assertion failure later.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
As per issue2629, most 23.976fps matroska H.264 files are incorrectly
detected as 24fps, as the matroska timestamps usually have only
millisecond precision.
Fix that by doubling the amount of timestamps inspected for frame rate
for streams that have coarse time base. This also fixes 29.970 detection
in matroska.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 78431098f9)
Tested with mplayer based on this report
http://thread.gmane.org/gmane.comp.video.mplayer.user/66043/focus=66063
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
No longer needed after martins change to the values.
Though this would have been nicer ABI wise but iam too lazy to maintain this difference
This reverts commit 183401b924.
While deprecated, they're totally useless as long as their values
are different from the AVIO_FLAG values that are used internally.
Currently, this leads to old libav applications still compiling
correctly (since we haven't removed the fallback wrappers), but
failing since the functions internally compare to the new AVIO_FLAG
values.
These should be removed at some point, but they aren't removed yet.
The intent is to be able to recompile an old application against
the new ABI without modifying the code, and this doesn't work
currently.
Signed-off-by: Martin Storsjö <martin@martin.st>