Signed-off-by: Anton Khirnov <anton@khirnov.net>
CC:libav-stable@libav.org

Duplicate the last one or two chroma lines.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
CC:libav-stable@libav.org

CC:libav-stable@libav.org

The bottom line was invalid before.

CC:libav-stable@libav.org

CC:libav-stable@libav.org

It's not relying on get_buffer() initializing the frame since
99e36ddd.

Setting it to zero (instead of 128, as the default get_buffer() does)
also produces more correctly-looking output.

It is used as an array in svq1enc, so this is more correct.

clang says:
libavfilter/vf_yadif.c:192:28: warning: incompatible pointer types assigning to
'void (*)(uint8_t *, uint8_t *, uint8_t *, uint8_t *, int, int, int, int, int)'
from 'void (uint16_t *, uint16_t *, uint16_t *, uint16_t *, int, int, int, int, int)'

the rest of the code is using codec_id everywhere already
Signed-off-by: Vladimir Pantelic <vladoman@gmail.com>
Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>

{avg,put}_pixels4_c are not used.

This avoids SIMD-optimized functions having to sign-extend their
line size argument manually to be able to do pointer arithmetic.

Always evaluate to NULL when the source Picture is not located in the
MpegEncContext.picture array. That will only happen for
next/last_picture_ptr when updating the thread context during h264 frame
threaded decoding, where they will point to elements of ref_list. Since
ref_list is not copied during updating the context and is invalid until
it is constructed for the current slice, there is no point in doing
anything complicated with next/last_picture_ptr, as they will get
updated when the ref_list is filled.

Packet pts is a very unreliable indicator, use
AVCodecContext.frame_number instead.

On Cygwin systems MinGW headers can be present if the corresponding
packages have been installed. Since the MinGW libc is checked for
first, this results in newlib getting misdetected as MinGW libc.

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 47318953 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.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Added a missing header file.

CC:libav-stable@libav.org

CC:libav-stable@libav.org

That field will be deprecated.