All decode_channel_map calls together can easily read
more data than the amount of padding available.
Thus below patch adds an input length check before reading them.
Fixes some invalid reads with sample from
http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1138
This is required specifically for setting frame->format to -1,
otherwise it will be set to 0 = PIX_FMT_YUV420P and code reading
the format from the output decoded frame will get misled.
In particular fix regressions occurring with the pending vsrc_buffer
patch.
The check and the corresponding message in do_video_out() are
unnecessary in the libavfilter path, as a similar check and message
are performed within the buffer source.
Implement lazy initialization of the image resample context, so that
the initialization code does not need to be duplicated.
Also manage the case in which resample/size change mid-stream. For
each packet the code computes if resampling is needed.
Previously the resample check was done only at the initialization, in
case size/format changed and no resample was detected at the init
stage ffmpeg was silently exiting.
avfilter_copy_frame_props() avoids code duplication and increases
robustness.
The added files libavfilter/avcodec.[ch] are used for containing
utilities useful for gluing togheter libavfilter and libavcodec.
The format is a per-frame property, having it in AVFrame simplify the
operation of extraction of that information, since avoids the need to
access the codec/stream context.
width and height are per-frame properties, setting these values in
AVFrame simplify the operation of extraction of that information,
since avoids the need to check the codec/stream context.
With the following additions:
* support to anti-aliased glyph rendering
* support to UTF-8 text and Unicode chars rendering
* support for RGB packed formats
* fix minor errors and typos in the filter description
* extend/clarify examples in the filter description
Signed-off-by: Anton Khirnov <anton@khirnov.net>
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
Reimar Döffinger
Michael Niedermayer
jan gerber
Stefano Sabatini
Peter Belkner