It's never been touched or used in any way since it was added in 2003
and only works for PIX_FMT_PAL8, which makes me conclude that nobody's
ever used it.
avpicture_get_size() returns the size of buffer required for avpicture_layout.
For pseudo-paletted formats (gray8...) this size does not include the palette.
However, avpicture_layout doesn't know this and still writes the palette. Consequently,
avpicture_layout writes passed the length of the buffer. This fixes it
by fixing avpicture_layout so that it doesn't write the palette for these formats.
Signed-off-by: Matthew Einhorn <moiein2000@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Similar to avcodec_find_best_pix_fmt(), but instead only compares two destination
pix fmts and selects one of these fmts as the best dest format when converting from
a given source format. Also, as opposed to avcodec_find_best_pix_fmt() which supports
only the first 64 defined pixel formats, this supports as input any of the defined
pixel formats.
Also replaces the old function to rely on the new function.
Signed-off-by: Matthew Einhorn <moiein2000@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixed the problem where if there's more than 64 pixel formats
defined avcodec_find_best_pix_fmt() returns the wrong pixel format.
Signed-off-by: Matthew Einhorn <moiein2000@gmail.com>
Signed-off-by: Stefano Sabatini <stefano.sabatini-lala@poste.it>
Avoid the use of the brittle/inconsistent information in
PixFmtInfo.depth, and implement a possibly more robust logic which
exposes the information in pixdesc.
Also allow the removal of PixFmtInfo.depth, since this is the only use
of it.
The field is only used for checking if a format is YUV planar
and if the format is paletted.
This patch replaces the current is_planar_yuv() code with a function
which uses the pixdesc information. The new implementation is less
efficient, but this should not be an issue as the functions which use
it (av_picture_crop/pad()) are deprecated and currently never used in
the codebase.
Prefer data-driven over procedural logic in avg_bits_per_pixel(),
simplify and improve robustness, as it is easy to miss a function
update when a new format is added.
It is pretty hopeless that other considerable projects will adopt
libavutil alone in other projects. Projects that need small footprint
are better off with more specialized libraries such as gnulib or rather
just copy the necessary parts that they need. With this in mind, nobody
is helped by having libavutil and libavcore split. In order to ease
maintenance inside and around FFmpeg and to reduce confusion where to
put common code, avcore's functionality is merged (back) to avutil.
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
The new implementation is more compact, more correct and doesn't hurt
the eyes.
Originally committed as revision 25792 to svn://svn.ffmpeg.org/ffmpeg/trunk
descriptors for printing the number of channels/components.
Also replace the term "nb_channels" with "nb_components" which is more
consistent with the FFmpeg internal terminology, and is somehow
different with respect to the current definition of nb_channels in
PixFmtInfo.
See thread:
Subject: [FFmpeg-devel] [PATCH 6/8] Make avcodec_pix_fmt_string() use the
information in the pixel format descriptors for printing the
number of planes. Also replace the term "nb_channels" with
"nb_planes" which is more correct.
Date: Fri, 5 Nov 2010 12:01:38 +0100
Originally committed as revision 25717 to svn://svn.ffmpeg.org/ffmpeg/trunk
Carl Eugen Hoyos
Michael Niedermayer
Stefano Sabatini
Anton Khirnov
Alex Converse
Diego Biurrun
Matthew Einhorn
Jean First
Clément Bœsch
Stefano Sabatini
Mans Rullgard
Reinhard Tartler
Ramiro Polla