Possible since 222127418b.
Reviewed-by: Kacper Michajłow <kasper93@gmail.com>
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is no longer necessary now that the IDCTDSP is always ABI-compliant
(and free of MMX).
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Hint: The parts of this patch in decode_block_progressive()
and decode_block_refinement() rely on the fact that GET_VLC
returns -1 on error, so that it enters the codepaths for
actually coded block coefficients.
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only the mxpeg sets reference at all.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is quite big and we only need one function from it.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only the mxpeg decoder uses it (and the reference/bitmask feature
of ff_mjpeg_decode_sos()). So only initialize it for mxpeg which
allows to remove the mjpeg->hpeldsp dependency.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
mjpeg_decode_dc() currently has a special return value (0xfffff)
for the case of invalid data; this value does not overlap with
the ordinary return values, yet the compiler can't prove this
(at least on x86 where an asm version of NEG_USR32 is used
inside get_xbits()), so the non-error return value has to be checked
for being the special value even if mjpeg_decode_dc() is inlined.
This commit avoids this by separating error code and ordinary return
value. It also means that the ljpeg functions return the proper
error code and not -1 in case of invalid data.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, a DC error in decode_block() or decode_dc_progressive()
would lead to a warning from mjpeg_decode_dc() and a (less verbose)
error from the caller. Upgrade the former to an error status (all
callers treat is an error) and remove the latter.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There is no reason to add the address of an element of
MJpegDecodeContext (which makes logmessage nonreproducible).
Also avoid always printing a zero.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Consider APPx fields that are too short to contain an id field (32-bit)
as stubs, and ignore them if AV_EF_EXPLODE is not set.
This has been seen in the MJPEG output from some webcams (such as the
Logitech C270 and C920) and the JPEG images embedded in DNG images
from the Pentax K-1 camera.
The loop to skip the remaining bytes was off by one for all markers
except for Adob.
This patch uses post-decrement instead of pre-decrement in the while
loop to make the len value easier to understand, and updates the len
value to reflect this change for the Adob marker.
Otherwise, the user requested priority of packet side data will be ignored.
For this, move the relevant functions to decode.c, as they need access to an
AVCodecContext.
Signed-off-by: James Almer <jamrial@gmail.com>
This commit adds a structure to contain parsed EXIF metadata, as well
as code to read and write that struct from/to binary EXIF buffers. Some
internal functions have been moved to exif_internal.h. Code to read
from this new struct and write to an AVDictionary **dict has been added
as well in order to preserve interoperability with existing callers.
The only codec changes so far as of this commit are to call these
interop functions, but in future commits there will be codec changes to
use the new parsing routines instead.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
When called from avformat_find_stream_info(), we are only interested in
decoding SOF fields.
This patch makes the decoder skip all other fields (including SOI, SOS,
and EOI). This also prevents the decoder from incorrectly printing the
warning "EOI missing, emulating" (which is the case since 2ae82788).
Fixes: #20119
This commit adds a reference to the buffer as an argument to
start_frame, and adapts all existing code.
This allows for asynchronous hardware accelerators to skip
copying packet data by referencing it.
These properties are unreliable because they depend on the frames decoded so
far, users should check directly the presence of the decoded AVFrame side data
or AVFrame flags.
Signed-off-by: Marton Balint <cus@passwd.hu>
Fixes: Null pointer dereference
Fixes: sample1.dng
Found-by: South East <8billion.people@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Perform av_clip_int16(val) _after_ copying the value to last_dc.
This change ensures that clipping is applied only within the context of
the current block, preventing the propagation of clipped values to
subsequent DC components.
Related commits: c28f648b19 and dffae122d0
Related ticket: 4683
There are lots of files that don't need it: The number of object
files that actually need it went down from 2011 to 884 here.
Keep it for external users in order to not cause breakages.
Also improve the other headers a bit while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Unnecessary since acf63d5350;
also avoids relocations.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Therefore use a proper prefix for this API, e.g.
ff_init_vlc_sparse -> ff_vlc_init_sparse
ff_free_vlc -> ff_vlc_free
INIT_VLC_LE -> VLC_INIT_LE
INIT_VLC_USE_NEW_STATIC -> VLC_INIT_USE_STATIC
(The ancient INIT_VLC_USE_STATIC has been removed
in 595324e143, so that
the NEW has been dropped.)
Finally, reorder the flags and change their values
accordingly.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These defines are also used in other contexts than just AVCodecContext
ones, e.g. in libavformat. Furthermore, given that these defines are
public, the AV-prefix is the right one, so deprecate (and not just move)
the FF-macros.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit is the AVHWAccel analogue of commit
20f9727018: It moves the private fields
of AVHWAccel to a new struct FFHWAccel extending AVHWAccel
in an internal header (namely hwaccel_internal.h).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Support pixel formats 0x11412100, 0x11311100, and 0x41211100, and add
logic to perform 4x horizontal upsampling. This should fix various JPEG
files found in Ticket #8930.
Co-authored-by: <leo.izen@gmail.com>
The change introduced in b18a9c2971
created a regression for non-subsampled progressive RGB jpegs. This
should fix that.
Additionally, this should fix other RGB JPEGs broken before the recent
patches, such as those in Trac issue #10190.
A single smvjpeg packet decodes into one large mjpeg frame, slices of
which are then returned as output frames. Packet duration covers all of
these slices.
Commit b18a9c2971 introduced a regression
that broke some baseline RGB jpegs. (See Trac issue #4045). This fixes
that.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
This allows weird subsampling with progressive JPEGs to be decoded,
such as full-RG and only B subsampled.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Frame counters can overflow relatively easily (INT_MAX number of frames is
slightly more than 1 year for 60 fps content), so make sure we use 64 bit
values for them.
Also deprecate the old 32 bit frame_number attribute.
Signed-off-by: Marton Balint <cus@passwd.hu>
Only one codec using mjpegdec.c actually creates multiple
frames from a single packet, namely SMVJPEG. The other can
use the ordinary decode callback just fine. This e.g. has
the advantage of confining the special SP5X/AMV code to sp5xdec.c.
This reverts most of commit e9a2a87773;
of course it is not a simple revert: Way too much has changed;
furthermore, outright reverting the sp5xdec.c changes would readd
a stack packet to sp5x_decode_frame() which is not desired.
In order to avoid this without modifying the given AVPacket,
a variant of ff_mjpeg_decode_frame() with explicit buf and size
parameters has been added.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
