Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Black isn't always just memset(ptr, 0, size). Limited YUV in particular
requires relatively non-obvious values, and filling a frame with
repeating 0 bytes is disallowed in some contexts. With component sizes
larger than 8 or packed YUV, this can become relatively complicated. So
having a generic function for this seems helpful.

In order to handle the complex cases in a generic way without destroying
performance, this code attempts to compute a black pixel, and then uses
that value to clear the image data quickly by using a function like
memset.

Common cases like yuv410p10 or rgba can't be handled with a simple
memset, so there is some code to fill memory with 2/4/8 byte patterns.
For the remaining cases, a generic slow fallback is used.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Merged from Libav commit 45df7adc.

Black isn't always just memset(ptr, 0, size). Limited YUV in particular
requires relatively non-obvious values, and filling a frame with
repeating 0 bytes is disallowed in some contexts. With component sizes
larger than 8 or packed YUV, this can become relatively complicated. So
having a generic function for this seems helpful.

In order to handle the complex cases in a generic way without destroying
performance, this code attempts to compute a black pixel, and then uses
that value to clear the image data quickly by using a function like
memset.

Common cases like yuv410p10 or rgba can't be handled with a simple
memset, so there is some code to fill memory with 2/4/8 byte patterns.
For the remaining cases, a generic slow fallback is used.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

See https://software.intel.com/en-us/articles/copying-accelerated-video-decode-frame-buffers

avutil/imgutils: Assert that the 2nd av_image_fill_linesizes() call in av_image_fill_linesizes() still succeeds

Fixes CID1271742
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This was suggested by wm4 and stefano.
After this patch using align=1 the size used by various functions would not
contain padding, while the palette would be aligned at align>1

This patch makes it required to use align>=4 if the palette is to be accessed
as uint32

As a side-effect It fixes storing pal8 in nut with odd with&height
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This allows disabling the alignment by using a compact buffer
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Libav, for some reason, merged this as a public API function. This will
aid in future merges.

A define is left for backwards compat, just in case some person
used it, since it is in a public header.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

More readable and less breakable.

The new fields can be accessed directly and are more intelligible.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Found-by: Daemon404
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

av_image_fill_pointers always aligns the palette, but the padding
bytes don't (and can't) get initialized in av_image_copy.

Thus initialize them in av_image_alloc.

This fixes 'Syscall param write(buf) points to uninitialised byte(s)'
valgrind warnings.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

These could trigger assert failures previously
Found-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Move the lavc/imgconvert functions and rename them as follows:
  avpicture_get_size -> av_image_get_buffer_size()
  avpicture_fill     -> av_image_fill_arrays()
  avpicture_layout   -> av_image_copy_to_buffer()

The new functions have an align parameter, which allows to define the
linesize alignment assumed in the buffer (which is set or read).

The names of the functions are consistent with the lavu/samples API
(av_samples_get_buffer_size(), av_samples_fill_arrays()).

A redundant check has been dropped from av_image_fill_arrays().
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Add assertions and abort in case of invalid |dst_linesize| < bytewidth or
|src_linesize| < bytewidth.

Avoid to silently corrupt memory.

The first parameter is a pointer and NULL is more correct
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fixes CID703722
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

missed these in my previous search and replace
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Functions used across libraries should have avpriv_ and not ff_ prefixes.

Signed-off-by: Paul B Mahol <onemda@gmail.com>

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

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Move the lavc/imgconvert functions and rename them as follows:
avpicture_get_size -> av_image_get_buffer_size()
avpicture_fill     -> av_image_fill_arrays()
avpicture_layout   -> av_image_copy_to_buffer()

The new functions have an align parameter, which allows to define the
linesize alignment assumed in the buffer (which is set or read).

The names of the functions are consistent with the lavu/samples API
(av_samples_get_buffer_size(), av_samples_fill_arrays()).

This allows simd optimized routines to work in steps of 8 pixels
without going over the linesize. (this matters for yuv->rgb24 for example)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Also remove one pointless zero initialization in rangecoder.c.

This makes it possible to dintinguish them from PAL8.

Fixes an invalid write in avpicture_layout().

Found with address sanitizer.
Signed-off-by: Alex Converse <alex.converse@gmail.com>