The destination is sufficiently aligned for put_pixels here.
Signed-off-by: NMans Rullgard <mans@mansr.com>

Signed-off-by: NMans Rullgard <mans@mansr.com>

Accidentally prefixed ff_ with cextern.
Signed-off-by: NMartin Storsjö <martin@martin.st>

Signed-off-by: NLuca Barbato <lu_zero@gentoo.org>

Check slice count and input buffer size before constructing a possibly
invalid pointer, not after.

pp_time is never set for h264

They serve no useful purpose and wreak all kind of havoc when h264.h is
included elsewhere.

They were added to the latest FLAC specification:
https://git.xiph.org/?p=flac-website.git;a=commit;h=65c199a2Signed-off-by: NAnton Khirnov <anton@khirnov.net>

This is unnecessary, as ff_flac_set_channel_layout can handle any number of channels.
Signed-off-by: NAnton Khirnov <anton@khirnov.net>

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

Do not rely on get_buffer initializing them.

Changes yadif tests (off by one in one border pixel), because yadif
reads from those uninitialized lines.

The FATE sample contains some pixels with value 0, but the palette
stored in the file contains only values from 16 up. Because the default
and cmdutils get_buffer() initialize the data to 0x80, they appear as
gray dots.
After this commit they change to black dots, which is probably still
incorrect but less visible and doesn't rely on get_buffer() initializing
the data.

CC:libav-stable@libav.org

CC:libav-stable@libav.org

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

Duplicate the last one or two chroma lines.
Signed-off-by: NAnton 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: NVladimir Pantelic <vladoman@gmail.com>
Signed-off-by: NKostya 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.