This fixes crashes in chromium on win64 on machines with AVX
(crashes that apparently aren't triggered by fate).
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 311443f6c7)
Signed-off-by: Martin Storsjö <martin@martin.st>
REBASE_PICTURE (more specifically, this half of it) takes a Picture
pointer that points into one larger struct, finds the offset of
that Picture within the struct and finds the corresponding field
within another instance of a similar struct.
The pointer difference "pic - (Picture*)old_ctx" is a value given
in sizeof(Picture) units, and when applied back on
(Picture*)new_ctx gets multiplied back with sizeof(Picture). Many
compilers seem to optimize out this division/multiplication, but
not all do.
GCC 4.2 on OS X doesn't seem to remove the division/multiplication,
therefore the new pointer didn't turn out to point to exactly
the right place in the new struct since it only had sizeof(Picture)
granularity (and the Picture is not aligned on a sizeof(Picture)
boundary within the encompassing struct). This bug has been present
before 47318953d as well - with H264, pointers to h->ref_list[0][0]
pointed to 88 bytes before h->ref_list[0][0] after the rebase. After
shrinking Picture, the difference ended up even larger, making
writes via such a Picture pointer overwrite other fields at random
in H264Context, ending up in crashes later.
This fixes H264 multithreaded decoding on OS X with GCC 4.2.
Fixes Bug: #439
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit a65f965c04)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
The library might provide an encoder in the future, so it's better to
check for the presence of the decoder rather than just the library.
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit ed89cad6aa04bbd692b3eb21c0e0bb56aca77130)
Duplicate the last one or two chroma lines.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
CC:libav-stable@libav.org
(cherry picked from commit 685e6f2e39)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Do not assume that frame dimensions are mod16 (or that height is mod32
for interlaced).
CC:libav-stable@libav.org
(cherry picked from commit 69c25c9284)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Also stop storing the channel arrangement in the header info, as it's unused outside of ff_mlp_read_major_sync.
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
CC:libav-stable@libav.org
(cherry picked from commit 99ccd2ba10)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
This makes the plain-armv6 version use the same registers as the
armv6t2 version above.
This fixes fate-vp8 on plain-armv6 devices.
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 2026eb1408)
Signed-off-by: Martin Storsjö <martin@martin.st>
libavutil/arm/asm.S sets '.arch' depending on HAVE_ARMV5TE so that
assembling armv5te code will always succeed even if the default -march
flag does not support it. HAVE_ARMV5TE_EXTERNAL tests assembling code
with the default arch.
Fixes the missing symbol ff_prefetch_arm with --cpu= not including
armv5te.
CC: libav-stable@libav.org
Too much code relies in having init_get_bits fed with a valid
buffer and set its dimension to 0.
Check for NULL buffer instead.
(cherry picked from commit 4603ec85ed)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The loop condition `x = ex' is incorrect. It should be `x <= ex'.
This bug was introduced in commit c65dfac4 "mpegvideo.c: K&R formatting
and cosmetics."
CC:libav-stable@libav.org
(cherry picked from commit 992b031838)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The mask `x && (1 << y)' is incorrect and always yields true.
The correct form should be `x & (1 << y)'.
CC: libav-stable@libav.org
Signed-off-by: Xi Wang <xi.wang@gmail.com>
(cherry picked from commit 783e37f7ef)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This fixes a regression since d9cf5f51/7a2ee770f5 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>
(cherry picked from commit e33db35b4a)
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
(cherry picked from commit fb845ffdd3)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
It's been returning an error value since
bad446e251
Also check for the errors it returns.
(cherry picked from commit ea382767ad)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
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.
(cherry picked from commit bad446e251)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
By default libav sets it to 3/4 while x264 sets it to 9/10.
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit 47812070a2)
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>
(cherry picked from commit bff3607547)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Accept the buffer size in bytes and check for overflow before passing
the value in bits to init_get_bits.
(cherry picked from commit e28ac6e5e2)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Fix an undefined behaviour and make the function return a proper
error in case of overflow.
CC: libav-stable@libav.org
(cherry picked from commit d9cf5f5169)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Handle pred_flag parameter not given to get_mvdata_interlaced()
Signed-off-by: Vladimir Pantelic <vladoman@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit 7b8c5b263b)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The function find_things() in configure is confused by component
registration calls as part of multiline macros defining combined
component registration. Coalesce those macros into one line to
work around the issue.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Signed-off-by: Martin Storsjö <martin@martin.st>
Comparing AVCodecContext.pix_fmt against the get_pixel_format() return
value has the side effect of calling the get_format() callback on each
slice. Users of the callback will probably handle hardware accelerator
initialization in the callback.
It does not use any of the mpegvideo infrastructure, just a few fields
from the context.
Fixes a segfault with the emu edge flag, since emu edge buffer is now
allocated as a part of the frame buffer allocation and cavs calls
ff_get_buffer() directly, it does not use mpegvideo buffer management.
Fixes a memleak of the last frame.
