If a sequence of JXL images is encapsulated in a container that has PTS
information, we should use the PTS information from the container. At
this time there is no container that does this, but if JPEG XL support
is ever added to NUT, AVTransport, or some other container, this commit
should allow the PTS information those containers provide to work as
expected.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
These pixel formats have always been supported by libjxl, but at the
time this plugin was written, they were not in FFmpeg yet. Now that
they are in FFmpeg, we should support them.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Before this commit, the decoder erroneously assumes that the AVFrame
passed to the receive_frame is the same one each time. Now it keeps an
internal AVFrame to write into, and copies it over when it's done.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Fixes an error that's caused by decoding a grayscale JXL image after an
RGB image is decoded, with the same decoder instance.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Git master libjxl changed several function signatures, so this commit
adds some #ifdefs to handle the new signatures without breaking old
releases. Do note that old git master development versions of libjxl
will be broken, but no releases will be.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Migrate the libjxl decoder wrapper from the decode_frame method to the
receive_frame method, which allows sending more than one frame from a
single packet. This allows the libjxl decoder to decode JPEG XL files
that are animated, and emit every frame of the animation. Now, clients
that feed the libjxl decoder with an animated JPEG XL file will be able
to receieve the full animation.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Since many distributions ship libjxl 0.7.0 still, we'd still prefer to
compile against that, but don't want to lose the features that require
libjxl 0.8.0 or greater. For this reason I've added preprocessor #ifdef
guards around the features that aren't necessarily in libjxl 0.7.0.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
libjxl only accepts 16-bit buffers with its API, but it can
accept 9-bit to 15-bit input via a 16-bit buffer, provided the flag
is set declaring the buffer to be of the respective significant depth.
Likewise, it can only provide pixel data on decode as a 16-bit buffer
(if higher than 8) but does provide the metadata tagging the actual bit
depth.
This commit causes libjxlenc.c and libjxldec.c to respect this metadata
and tag/read it accordingly from AVCodecContext->bits_per_raw_sample.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Gamma 2.2 and Gamma 2.8 are tagged in the file as 0.45455 and 0.35714,
respectively (i.e. 1/2.2 and 1/2.8). Trying to identify them as 2.2 and
2.8 instead of these values will cause the transfer function to not
properly be recognized. This patch fixes this.
It reduces typing: Before this patch, there were 105 codecs
whose long_name-definition exceeded the 80 char line length
limit. Now there are only nine of them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Decoder-only, as the dimensions are set by the user when encoding.
Also fixup the other headers a bit while removing unnecessary internal.h
inclusions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only used by decoders (encoders have ff_encode_alloc_frame()).
Also clean up the other headers a bit while removing now redundant
internal.h inclusions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Codecs that can read/write ICC profiles deserve a special capability so
the common logic in encode.c/decode.c can decide whether or not there
needs to be any special handling for ICC profiles. The motivation here
is to be able to use it to decide whether or not an ICC profile needs to
be generated in the encode path, but it might as well get added to
decoders as well for purely informative reasons.
It's not entirely clear to me whether the "thp" and "smvjpeg" variants
of "mjpeg" should have this capability set or not, given that the code
technically supports it but I somehow doubt these files may contain
them. In either case, this cap is purely informative for decoders so it
doesn't matter too much either way.
It's also not entirely clear whether the "amv" encoder should signal ICC
profile support, but again erring on the side of caution, we probably
*shouldn't* be generating (and encoding!) ICC profiles for this type of
media file.
Signed-off-by: Niklas Haas <git@haasn.dev>
This is in preparation of switching the default init-thread-safety
to a codec being init-thread-safe.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These packets need not be writable, so we must not modify them.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Whether an ICC profile is present or not, the decoder
should now properly tag the colorspace of pixel data
received by the decoder.
Reviewed-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Leo Izen <leo.izen@gmail.com>
