When a JACOsub subtitle has two timestamps, they represent its start and
end times (http://unicorn.us.com/jacosub/jscripts.html#l_times); the
duration is the difference between the two, not the sum of the two.
The subtitle end times in the FATE test for this were wrong as a result;
fix them too. (This test is based on JACOsub's demo.txt, and the end
time computed for the last line using @ now matches what the comments
there say it should be.)
Also tested in practice using MPV, a LaserDisc, and some authentic 1993
JACOsub files.
Signed-off-by: Adam Sampson <ats@offog.org>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '156ea66c91b1986a87916f187216978d686725f6':
h264/x86: sign extend int stride in deblock functions
This commit is a noop, see d5d699ab6e
Merged-by: James Almer <jamrial@gmail.com>
* commit 'eec93e57096aa4804862d62760442380c70d489b':
libopenh264dec: Use a newer decoding entry point function
Merged-by: James Almer <jamrial@gmail.com>
* commit 'ca44fa5d7fda7e954f3ebfeb5b0d6d1be55fcaa3':
avcodec/libdav1d: properly free all output picture references
This commit is a noop, see 10931a0661
Merged-by: James Almer <jamrial@gmail.com>
* commit '70ab2778be9c83dab84340af7e3ba83fa0f98576':
libdav1d: update API usage to the first stable release
libdav1d: fix build after a recent API break
qsvenc: Add VDENC support for H264 and HEVC
avcodec: libdav1d AV1 decoder wrapper.
swscale: Add GRAY10
pixfmt: Add GRAY10
libx264: Pass the reordered_opaque field through the encoder
libavutil: Undeprecate the AVFrame reordered_opaque field
libaom: remove references to yuva444p pixfmt
Revert "decode: copy the output parameters from the last bsf in the chain back to the AVCodecContext"
This commit is a noop, see
87588caf8c4e9cff2824882ae091d43f1b5ca22eb5177c7051beaa350e24e92ce340e6
Merged-by: James Almer <jamrial@gmail.com>
* commit '1ff6cb2ca6652e7d2a929afd33d8ed6268c45568':
lavc/qsvenc_jpeg: set a default quality
lavc/qsvenc_jpeg: add async_depth support
This commit is a noop, see
0e3d7d845d92c25963e8
Merged-by: James Almer <jamrial@gmail.com>
* commit '04e8b8b0530e2aa33010faba3d0b6b6c9c5b704e':
avcodec/libaomenc: export the Sequence Header OBU as extradata
This commit is a noop. aom_codec_get_global_headers() is buggy at the moment.
See https://bugs.chromium.org/p/aomedia/issues/detail?id=2208
Merged-by: James Almer <jamrial@gmail.com>
* commit '97c9a5084479eeb66f4beb100cc7589a2c8bfe81':
avcodec/libaomenc: remove AVOption related to frame partitions
avcodec/extract_extradata: don't uninitialize the H2645Packet on every processed packet
avcodec/extract_extradata: Move the reference in the bsf internal buffer
avcodec/extract_extradata: Do not allocate more space than needed when removing NALUs in h264/hevc
avcodec/extract_extradata: Zero-initialize the padding bytes in all allocated buffers
avcodec/extract_extradata_bsf: Fix leak discovered via fuzzing
avcodec/bsf: Add ff_bsf_get_packet_ref() function
This commit is a noop, see
7ae52f8a6b5a412a5c3cd168e78eff2536bd86329c6dd9d624016d40011ab69ea742ab
Merged-by: James Almer <jamrial@gmail.com>
Even if NEON would be disabled, the init functions should be built
as they are called as long as ARCH_AARCH64 is set.
These functions are part of a generic DSP subsytem, not tied directly
to one decoder. (They should be built if the vp7 decoder is enabled,
even if the vp8 decoder is disabled.)
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit b4b27dce95)
This also partially fixes assembling with MS armasm64 (via
gas-preprocessor).
The movrel macro invocations need to pass the offset via a separate
parameter. Mach-o and COFF relocations don't allow a negative
offset to a symbol, which is handled properly if the offset is passed
via the parameter. If no offset parameter is given, the macro
evaluates to something like "adrp x17, subpel_filters-16+(0)", which
older clang versions also fail to parse (the older clang versions
only support one single offset term, although it can be a parenthesis.
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 26d7af4c38)
If we fill with black then the generated palette will have one color more
than what the user requested. This also resulted in unwanted black specks in
the output of paletteuse, especially when generating small palettes.
- Clamp ME range to -64..63 (prevents corruption when me_range is too high)
- Allow MV's up to *and including* the positive range limit
- Allow out-of-edge ME by padding the prev buffer with a border of 0's
- Try previous MV before checking the rest (improves speed in some cases)
- More robust logic in code - ensure *mx,*my,*xored are updated together
- Improve block choices by counting 0-bytes in the entropy score
- Make histogram use uint16_t type, to allow byte counts from 16*16
(current block size) up to 255*255 (maximum allowed 8bpp block size)
- Make sure score table is big enough for a full block's worth of bytes
- Calculate *xored without using code in inner loop
This was found through the Hacker One program on VLC but is not a security issue in libavformat
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Out of array access
Fixes: 13090/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-5408668986638336
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Kieran Kunhya <kierank@obe.tv>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is the equivalent change for cuviddec after the previous change
for nvdec. I made similar changes to the copying routines to handle
pixel formats in a more generic way.
Note that unlike with nvdec, there is no confusion about the ability
of a codec to output 444 formats. This is because the cuvid parser is
used, meaning that 444 JPEG content is still indicated as using a 420
output format.
With the introduction of HEVC 444 support, we technically have two
codecs that can handle 444 - HEVC and MJPEG. In the case of MJPEG,
it can decode, but can only output one of the semi-planar formats.
That means we need additional logic to decide whether to use a
444 output format or not.
The latest generation video decoder on the Turing chips supports
decoding HEVC 4:4:4. Supporting this is relatively straight-forward;
we need to account for the different chroma format and pick the
right output and sw formats at the right times.
There was one bug which was the hard-coded assumption that the
first chroma plane would be half-height; I fixed this to use the
actual shift value on the plane.
We also need to pass the SPS and PPS range extension flags.
We need all the flags to be exposed to be able to pass them on to
HW decoders. I did not attempt to nuance any of the warnings about
flags being unsupported as there's no way, at the point we extract
flags, to say whether an HW decoder is being used.
Adam Sampson
James Almer
Martin Storsjö
Tomas Härdin
Matthew Fearnley
hwren
Xiaofeng Wang
Steve Lhomme
Michael Niedermayer
Wenxiang Qian
Kevin Backhouse via RT
Gyan Doshi
Reto Kromer
Carl Eugen Hoyos
gxw
Philip Langdale
Timo Rothenpieler
Roman Arzumanyan