| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
|
|
| |
match the behavior of SvtAv1EncApp to ensure pic_type is always set
before passing it to the library.
The other options for pic_type aren't currently used inside the library,
so they aren't introduced in this patch.
Signed-off-by: Christopher Degawa <ccom@randomderp.com>
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Monterey needs mBytesPerFrame and mBytesPerPacket to be set, and I'm
surprised this didn't break any previous system versions.
Fixes bug #9564: Cannot decode xHE-AAC with audiotoolbox (aac_at) on
Mac OS Monterey. Fixes likely bug that none of the AudioToolbox
decoders work on Monterey.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
|
|
|
|
| |
Other values are forbidden by specification.
|
|
|
|
|
|
|
|
|
| |
ff_hevc_put_hevc_qpel_h64_8_sse4 56782981
ff_hevc_put_hevc_qpel_h64_8_avx2 40097816
ff_hevc_put_hevc_qpel_h64_8_avx512icl 25488576
Reviewed-by: Henrik Gramner <henrik@gramner.com>
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
|
|
|
|
|
|
|
|
|
| |
ff_hevc_put_hevc_qpel_h32_8_sse4 14122151
ff_hevc_put_hevc_qpel_h32_8_avx2 9337675
ff_hevc_put_hevc_qpel_h32_8_avx512icl 6424654
Reviewed-by: Henrik Gramner <henrik@gramner.com>
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
|
|
|
|
|
|
|
|
| |
ff_hevc_put_hevc_qpel_h4_8_sse4 993694
ff_hevc_put_hevc_qpel_h4_8_avx512icl 686647
Reviewed-by: Henrik Gramner <henrik@gramner.com>
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
|
|
|
|
|
|
|
|
| |
ff_hevc_put_hevc_qpel_h16_8_sse4 3290870
ff_hevc_put_hevc_qpel_h16_8_avx512icl 1730033
Reviewed-by: Henrik Gramner <henrik@gramner.com>
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit uses the instruction `vpdpbusd` introduced by AVX512 VNNI
to calculate the horizontal filter.
ff_hevc_put_hevc_qpel_h8_8_sse4 1039169
ff_hevc_put_hevc_qpel_h8_8_avx512icl 677153
ff_hevc_put_hevc_qpel_hv8_8_sse4 3603511
ff_hevc_put_hevc_qpel_hv8_8_avx512icl 2995354
Reviewed-by: Henrik Gramner <henrik@gramner.com>
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
|
|
|
|
|
| |
The version.h bump got missed with the Jpeg XL patchset. This should
bump the minor version in accordance with the contributing guidelines.
|
|
|
|
|
| |
This commit adds encoding support to libavcodec
for Jpeg XL images via the external library libjxl.
|
|
|
|
|
| |
This commit adds decoding support to libavcodec
for Jpeg XL images via the external library libjxl.
|
|
|
|
|
|
| |
This commit adds support to libavcodec to read
encoded Jpeg XL images. Jpeg XL is intended to be an
extended-life replacement to legacy mjpeg.
|
|
|
|
|
|
|
|
|
| |
The size of the ICC chunk has already been accounted for when
the packet's buffer was initially set in ff_mpv_encode_picture()
and the header (including the ICC chunk) has already been written
at this point.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
|
|
|
| |
It is a remnant of the old way for user-supplied buffers;
it is always-true since 93016f5d1d280f9cb7856883af287fa66affc04c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
|
|
|
|
|
|
|
| |
If one encodes MJPEG with a single slice and uses input with
AV_FRAME_DATA_ICC_PROFILE side data, the current allocation code
in ff_mpv_encode_picture() will always increase the size of the
temporary buffer used for allocating packets by the size needed
for to write the ICC chunk even when the current buffer is actually
large enough. This commit fixes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
|
|
|
|
| |
MJPEG is the only mpegvideo-based encoder making use of it.
Fixes linking failures in case mpegvideo_enc.c is compiled
with AMV, LJPEG and MJPEG encoders disabled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
|
| |
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
|
| |
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
|
|
|
| |
It works, but it is not documented to work.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
|
|
|
| |
FFCodec.cb is a union.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
|
| |
This happened when major header needed to be written
after input EOF.
|
|
|
|
| |
Fixes #9563.
|
| |
|
| |
|
|
|
|
|
| |
It is also used by some encoders, so decode.c is not the right place for
it.
|
|
|
|
| |
It has only a single member.
|
|
|
|
| |
And only when needed, i.e. for encoders using the simple API.
|
|
|
|
|
| |
On entry to avcodec_open2(), the AVCodecContext type and id either have
to be UNKNOWN/NONE or have to match the codec to be used.
|
|
|
|
|
| |
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
|
|
|
| |
This encoder uses ff_get_encode_buffer().
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
|
|
|
|
|
|
| |
Do this by switching to bytestream2_(get|put)_le32u() from
bytestream2_(get|put)_le32(); it has after all already been checked
that the packet contains at least a full header, making all
the implicit checks in bytestream2_(get|put)_le32() dead code.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
|
|
|
|
| |
Therefore move the (Get|Put)ByteContext from the context to the stack.
It is transient anyway.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
|
|
| |
Reviewed-by: Marton Balint <cus@passwd.hu>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Instead use the bytestream2-API.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SEI messages are naturally byte-aligned by adding padding bits
to achieve byte-alignment. The parsing code in libavcodec/hevc_sei.c
nevertheless uses a GetBitContext to read it. When doing so, parsing
the next SEI message starts exactly at the position where reading
the last message (if any) ended.
This means that one would have to handle both the payload extension data
(which makes most SEI messages extensible structs) as well as the
padding bits for byte-alignment. Yet our SEI parsing code in
libavcodec/hevc_sei.c does not read these at all. Instead several of
the functions used for parsing specific SEI messages use
skip_bits_long(); some don't use it at all, in which case it is possible
for the GetBitContext to not be byte-aligned at the start of the next
SEI message (the parsing code for several types of SEI messages relies
on byte-alignment).
Fix this by always using a dedicated GetBitContext per SEI message;
skipping the necessary amount of bytes in the NALU context
is done at a higher level. This also allows to remove unnecessary
parsing code that only existed in order to skip enough bytes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is mostly straightforward. The major complication is that, as a
result of the 16-bit chunk size limitation, ICC profiles may need to be
split up into multiple chunks.
We also need to make sure to allocate enough extra space in the packet
to fit the ICC profile, so modify both mpegvideo_enc.c and ljpegenc.c to
take into account this extra overhead, failing cleanly if necessary.
Also add a FATE transcode test to ensure that the ICC profile gets
written (and read) correctly. Note that this ICC profile is smaller than
64 kB, so this doesn't test the APP2 chunk re-arranging code at all.
Signed-off-by: Niklas Haas <git@haasn.dev>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We re-use the PNGEncContext.zstream for deflate-related operations.
Other than that, the code is pretty straightforward. Special care needs
to be taken to avoid writing more than 79 characters of the profile
description (the maximum supported).
To write the (dynamically sized) deflate-encoded data, we allocate extra
space in the packet and use that directly as a scratch buffer. Modify
png_write_chunk slightly to allow pre-writing the chunk contents like
this.
Also add a FATE transcode test to ensure that the ICC profile gets
encoded correctly.
Signed-off-by: Niklas Haas <git@haasn.dev>
|
|
|
|
| |
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
max_14bit_constraint_flag should be set if the bit depth is not greater than
14 (currently always true).
one_picture_only_flag should not be set because we don't support the still
picture profiles.
general_profile_compatibility_flag should be set according to general_profile_idc
instead of bit depth.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
|
|
|
|
|
|
|
|
| |
The block size can be dependent on the profile and entrypoint selected.
It defaults to 16x16, with codecs able to override this choice with their
own function.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use GPB frames to replace regular P/B frames if backend driver does not
support it.
- GPB:
Generalized P and B picture. Regular P/B frames replaced by B
frames with previous-predict only, L0 == L1. Normal B frames
still have 2 different ref_lists and allow bi-prediction
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
|
|
|
|
| |
Signed-off-by: Marton Balint <cus@passwd.hu>
|
|
|
|
|
|
|
|
| |
Add support for decoding Vizrt Binary Image (VBN) files.
LZW-compressed data is not supported yet.
Signed-off-by: Marton Balint <cus@passwd.hu>
|
|
|
|
|
|
| |
And add slice thread capabilities.
Signed-off-by: Marton Balint <cus@passwd.hu>
|
|
|
|
| |
Signed-off-by: Marton Balint <cus@passwd.hu>
|
|
|
|
| |
Signed-off-by: Marton Balint <cus@passwd.hu>
|
|
|
|
|
|
|
|
|
| |
function
This will allow using a common threaded decode or encode function from most
codecs using texture DSP functions.
Signed-off-by: Marton Balint <cus@passwd.hu>
|