Fix the AV1 RTP depacketizer for instances where the OBU elements
did not have their OBU size fields removed according to the
recommendation (SHOULD) of the AV1 RTP specification.
Roger Hardiman courteously reported that the depacketizer doesn't
work correctly for fragmented OBU elements with their OBU size
fields still present and will incorrectly state that the
continuation of such a fragment was unexpected, because the
frag_obu_size field was used as a state and only incremented
when the size field needed to be updated on OBU size field
restoration. This patch solves the slip.
Change-Id: I95af8cc89862e8ecf79aabcf029dd95a20dfd7ad
There seem to be samples with no Video element on video tracks in the wild,
which even if not spec compliant, can be demuxed fine after lavf probes the
stream with a decoder/parser.
Relax the check to allow tracks with no dimensions to work, and also add a
check for strict spec compliance to maintain the current behavior if desired.
Fixes issue #20649.
Signed-off-by: James Almer <jamrial@gmail.com>
Add a shader-based Apple ProRes decoder.
It supports all codec features for profiles up to
the 4444 XQ profile, ie.:
- 4:2:2 and 4:4:4 chroma subsampling
- 10- and 12-bit component depth
- Interlacing
- Alpha
The implementation consists in two shaders: the
VLD kernel does entropy decoding for color/alpha,
and the IDCT kernel performs the inverse transform
on color components.
Benchmarks for a 4k yuv422p10 sample:
- AMD Radeon 6700XT: 178 fps
- Intel i7 Tiger Lake: 37 fps
- NVidia Orin Nano: 70 fps
In preparation for the Vulkan hwaccel.
The existing hwaccel code was designed around
videotoolbox, which ingests the whole frame
bitstream including picture headers.
This adapts the code to accomodate lower-level,
slice-based hwaccels.
The code that attempted to extract origin (4B.02) was put in the wrong
metadata handler and was also read as the wrong integer type. According
ST 377-1 Origin is of type "Position" (Int64) in the Timeline Track, not
a 8 bit unsigned integer in the Sequence.
The drawvg filter can draw vector graphics on top of a video, using libcairo. It
is enabled if FFmpeg is configured with `--enable-cairo`.
The language for drawvg scripts is documented in `doc/drawvg-reference.texi`.
There are two new tests:
- `fate-filter-drawvg-interpreter` launch a script with most commands, and
verify which libcairo functions are executed.
- `fate-filter-drawvg-video` render a very simple image, just to verify that
libcairo is working as expected.
Signed-off-by: Ayose <ayosec@gmail.com>
fate-lavf-flv is dependency of fate-api-seek, but the fate-api-seek is
setting CMP = null, which affects fate-lavf-flv. Reset CMP value to
expected by the flv test and use default diff compare.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The last 3dnow functions have been removed in commit
5ef613bcb0. So remove 3dnow
from configure; the only thing kept is that --disable-amd3dnow
is still accepted, but no longer advertised by --help.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Supresses:
warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
Also drop L, as shift will never exceed 31.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This is how images encoded with specific transfer function should be
viewed. Image viewers that doesn't support named trc metadata, will
fallback to simple gAMA value and both of those cases should produce the
same image apperance for the viewer.
Fixes: https://github.com/mpv-player/mpv/issues/13438
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The mismatch between neon and C functions can be reproduced
using the following bitstream and command line on aarch64 devices.
wget https://streams.videolan.org/ffmpeg/incoming/replay_intra_pred_16x16.h264
./ffmpeg -cpuflags 0 -threads 1 -i replay_intra_pred_16x16.h264 -f framemd5 -y md5_ref
./ffmpeg -threads 1 -i replay_intra_pred_16x16.h264 -f framemd5 -y md5_neon
Signed-off-by: Bin Peng <pengbin@visionular.com>
