They use now code identical to the AAC decoder.
The AC3 decoder previously did not check the data_size and
the dca decoder checked against and set wrong values for float.
Improve consistency with libavcodec.
This breaks libavfilter API/ABI.
The non-sequential 2.1.0 -> 2.4.0 bump is due to the mess previously
done with the lavfi minor number.
The sample aspect ratio is a per-frame property, so it makes sense to
define it in AVFrame rather than in the codec/stream context.
Simplify application-level sample aspect ratio information extraction,
and allow further simplifications.
This is similar to what was done with pkt_pts. This simplifies the
operation of extracting the pos information from the AVPacket, and
allows further simplifications.
One of the causes of this bug is that the h264 parser defaults low_delay
to 1, but the h264 codec defaults low_delay to 0. Really Ugly.
After many hours of looking at this, I'm still not sure how has_b_frames
is *intended* to behave, but to me the implementation appears way more
complicated than it ought to be.
My patch relies on the encoder to set an optional field in the SPS. This
works for libx264 streams, but I'm not sure that all h264 encoders will
set it.
* commit '85770f2a2651497861ed938efcd0df3696ff5e45':
AVOptions: make default_val a union, as proposed in AVOption2.
Move ff_dynarray_add to lavu and make it public.
lavf: remove duplicate assignment in avformat_alloc_context.
lavf: use designated initializers for AVClasses.
options: simplify av_find_opt by using av_next_option.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
I still don't fully understand the cause but the difference between
the samples that trigger the bug and the samples that don't is
that the former uses delay frames and the later uses drop frames
as placeholders for the packed frame. So, if we see the one type
of frame, we can assume the bug will or won't be present.
Right now, I'm detecting the frame types by size, which may not be
safe in general, but given the specific codec and file type, I
expect any scenario where we encounter these frames where they
aren't being used for b-frame packing won't care one way or
another whether the work around is in effect or not.
Signed-off-by: Philip Langdale <philipl@overt.org>
* qatar/master:
Duplicate AMV: disable DR1 and don't override EMU_EDGE
Duplicate lavf: inspect more frames for fps when container time base is coarse
Wrong and we have correct fix: Fix races in default av_log handler
vorbis: Replace sized int_fast integer types with plain int/unsigned.
Remove disabled non-optimized code variants.
NO bswap.h: Remove disabled code.
Remove some disabled printf debug cruft.
Replace more disabled printf() calls by av_dlog().
NO tests: Remove disabled code.
NO Replace some commented-out debug printf() / av_log() messages with av_dlog().
vorbisdec: Replace some sizeof(type) by sizeof(*variable).
NO vf_fieldorder: Replace FFmpeg by Libav in license boilerplate.
Conflicts:
libavcodec/h264.c
libavcodec/vorbisdec.c
libavutil/log.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This works around a possibly exploitable crash.
Appearently, vlc can be exploited with a malicous file. This should get
reverted as soon as a proper fix is found.
Reported-at: Thu, 21 Apr 2011 14:38:25 +0000
Reported-by: Dominic Chell <Dominic.Chell@ngssecure.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 89f903b3d5)
(cherry picked from commit 9b919571e5)
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>
int/unsigned is the natural memory access type for CPUs, using sized types
for temporary variables, counters and similar just increases code size and
can possibly cause a slowdown.
