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

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

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

Signed-off-by: Luca 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: Anton Khirnov <anton@khirnov.net>

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

Signed-off-by: Martin 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: 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.