This fixes a regression since d9cf5f51 with theora over RTP
(possibly with other variants of theora as well).
In theora over RTP, the second of the 3 headers turns out to be
0 bytes long, which prior to d9cf5f51 worked just fine. After
d9cf5f51, reading from the bitstream reader fails (since the reader
wasn't initialized but returned an error if initialized with 0 bits).
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
If the motion vector is at a subpixel position, we need 3 pixels below
the motion vector's wholepel position available, not 2, since the MC
filter is a sixtap filter for the hpel position, and then a bilin filter
for the qpel position.
This patch fixes highly irreproducible (0.1%) fate failures in frame 2
and 4 of h264-conformance-cama2_vtc_b (e.g. first P-frame, first field,
last line of MB x=40,y=2 and second field and last lines of MBs x=39-40,
y=3). These used pre-loopfilter instead of post-loopfilter data because
the await_progress() waited for one line too little in that field, and
the motion vector of these particular MBs happened to align exactly to a
position where that demonstrates the bug.
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Matroska stores palette information as plain text in extradata.
Signed-off-by: Alexandra Khirnova <alexandra.khirnova@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
rc_buffer_size is not set before.
Solve the initial the rate control underflow issue reported in
bug 222.
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The floating point version of av_clip has to be used when
converting the quality level.
Signed-off-by: Maximilian Seesslen <mes@seesslen.net>
Signed-off-by: Martin Storsjö <martin@martin.st>
Clobbering these tables will temporarily clobber the template used
as a basis for other threads to start decoding from. If the other
decoding thread updates from the template right at that moment,
subsequent threads will get invalid (or, usually, none at all) mmco
tables. This leads to invalid reference lists and subsequent decode
failures.
Therefore, instead, decode the mmco tables only for the first slice in
a field or frame. For other slices, decode the bits and ensure they
are identical to the mmco tables in the first slice, but don't ever
clobber the context state. This prevents other threads from using a
clobbered/invalid template as starting point for decoding, and thus
fixes decoding in these cases.
This fixes occasional (~1%) failures of h264-conformance-mr1_bt_a with
frame-multithreading enabled.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Fixes null pointer dereference later, since if this function failed,
a positive return value was returned to the caller.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Martin Storsjö <martin@martin.st>
Freeing it in av_destruct_packet(), as is done currently, would mean
that we allow it to be allocated with other means. But that would make
av_packet_new_side_data() unsafe.
Side data is not expected to be large, so copying it if required
shouldn't be a problem.