The lossless JPEG encoder allocates one buffer in its init function
and freeing said buffer is the only thing done in its close function.
Despite this the init function called the close function if allocating
said buffer fails, although there is nothing to free in this case.
This commit stops doing this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Both are codec properties and not encoder capabilities. The relevant
AVCodecDescriptor.props flags exist for this purpose.
Signed-off-by: James Almer <jamrial@gmail.com>
This options is only used by huffyuv, ffvhuv, jpegls, mjpeg,
mpegvideoenc, png, utvideo.
It is a very codec-specific options, so deprecate the global variant.
Set proper limits to the maximum allowed values, and update utvideoenc
tests to use the new option name.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This parameter can be used to inform the allocation code about how much
downsizing might occur, and can be used to optimize how to allocate the
packet
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The rationale is that coded_frame was only used to communicate key_frame,
pict_type and quality to the caller, as well as a few other random fields,
in a non predictable, let alone consistent way.
There was agreement that there was no use case for coded_frame, as it is
a full-sized AVFrame container used for just 2-3 int-sized properties,
which shouldn't even belong into the AVCodecContext in the first place.
The appropriate AVPacket flag can be used instead of key_frame, while
quality is exported with the new AVPacketSideData quality factor.
There is no replacement for the other fields as they were unreliable,
mishandled or just not used at all.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Allocating coded_frame is what most encoders do anyway, so it makes
sense to always allocate and free it in a single place. Moreover a lot
of encoders freed the frame with av_freep() instead of the correct API
av_frame_free().
This bring uniformity to encoder behaviour and prevents applications
from erroneusly accessing this field when not allocated. Additionally
this helps isolating encoders that export information with coded_frame,
and heavily simplifies its deprecation.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
* commit '4978850ca2cb1ec6908f5bc79cc592ca454d11e8':
build: Split JPEG-related tables off into a separate component
Conflicts:
configure
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'adcb8392c9b185fd8a91a95fa256d15ab1432a30':
mjpeg: Split off bits shared by MJPEG and LJPEG encoders
Conflicts:
libavcodec/mjpegenc.c
libavcodec/mjpegenc.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b73a8922d818c7f909855557718d4c3bfacbd92d':
ljpegenc: split yuv encoding into a separate function
Conflicts:
libavcodec/ljpegenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'fa4476815d0d27996eb199452f2cdbfccdd244a5':
ljpegenc: split bgr encoding into a separate function
Conflicts:
libavcodec/ljpegenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'daffed3b173c59d64907747bf3309e98a8974f4e':
ljpegenc: accept bgr24 instead of bgra
Conflicts:
libavcodec/ljpegenc.c
libavcodec/mjpegenc.c
Only whitespace merged, we continue to support both formats
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '86eb2eaac629909d6ee4067c6f1e485a4e70473d':
mjpegenc: do not pass MpegEncContext to ff_mjpeg_encode_dc()
Conflicts:
libavcodec/mjpegenc.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '3360ad995530ea6967b1e83981b4aa8240fbb0ed':
mjpegenc: do not pass MpegEncContext to ff_mjpeg_encode_picture_trailer()
Conflicts:
libavcodec/ljpegenc.c
libavcodec/mjpegenc.c
libavcodec/mjpegenc.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '058d5f2feb730846f22c1812e433f92f670ad751':
mjpegenc: do not pass MpegEncContext to ff_mjpeg_encode_picture_header()
Conflicts:
libavcodec/mjpegenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The encoder uses almost none of the mpegvideo infrastructure, only some
fields from MpegEncContext.
The FATE results change because now an all-zero quant matrix is written
into the file. Since it is not used for anything for ljpeg, this should
not be a problem.
