In MPEG-2 user data, there can be different types of Closed Captions
formats embedded (A53, SCTE-20, or DVD). The current behavior of the
CC extraction code in the MPEG-2 decoder is to not be aware of
multiple formats if multiple exist, therefore allowing one format
to overwrite the other during the extraction process since the CC
extraction shares one output buffer for the normalized bytes.
This causes sources that have two CC formats to produce flawed output.
There exist real-world samples which contain both A53 and SCTE-20 captions
in the same MPEG-2 stream, and that manifest this problem. Example of symptom:
THANK YOU (expected) --> THTHANANK K YOYOUU (actual)
The solution is to pick only the first CC substream observed with valid bytes,
and ignore the other types. Additionally, provide an option for users
to manually "force" a type in the event that this matters for a particular
source.
Signed-off-by: Marth64 <marth64@proxyid.net>
PyTorch is an open source machine learning framework that accelerates
the path from research prototyping to production deployment. Official
website: https://pytorch.org/. We call the C++ library of PyTorch as
LibTorch, the same below.
To build FFmpeg with LibTorch, please take following steps as
reference:
1. download LibTorch C++ library in
https://pytorch.org/get-started/locally/,
please select C++/Java for language, and other options as your need.
Please download cxx11 ABI version:
(libtorch-cxx11-abi-shared-with-deps-*.zip).
2. unzip the file to your own dir, with command
unzip libtorch-shared-with-deps-latest.zip -d your_dir
3. export libtorch_root/libtorch/include and
libtorch_root/libtorch/include/torch/csrc/api/include to $PATH
export libtorch_root/libtorch/lib/ to $LD_LIBRARY_PATH
4. config FFmpeg with ../configure --enable-libtorch \
--extra-cflag=-I/libtorch_root/libtorch/include \
--extra-cflag=-I/libtorch_root/libtorch/include/torch/csrc/api/include \
--extra-ldflags=-L/libtorch_root/libtorch/lib/
5. make
To run FFmpeg DNN inference with LibTorch backend:
./ffmpeg -i input.jpg -vf \
dnn_processing=dnn_backend=torch:model=LibTorch_model.pt -y output.jpg
The LibTorch_model.pt can be generated by Python with torch.jit.script()
api. https://pytorch.org/tutorials/advanced/cpp_export.html. This is
pytorch official guide about how to convert and load torchscript model.
Please note, torch.jit.trace() is not recommanded, since it does
not support ambiguous input size.
Signed-off-by: Ting Fu <ting.fu@intel.com>
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Reviewed-by: Guo Yejun <yejun.guo@intel.com>
Otherwise the derived device and the source device might have different
PCI ID in a multiple-device system.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
At least on latest Win 11 and Visual Studio 2022, that DLL does not
exist anymore and can't be installed via any of the usual means.
However, debugging works just fine regardless, so this check makes
debugging impossible.
D3D11CreateDevice will fail anyway if debugging is not supported, so
let's rely on that instead.
When all cached frames are drained, the output mfxSyncPoint pointer is
NULL and MFX_ERR_MORE_DATA is returned, hence needn't print warning for
this expected behavior, otherwise the user might think the output from
qsv decoders are wrong.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
ff_aac_coder_init_mips() modifies a static const structure of
function pointers. This will crash if the binary uses relro
and is a data race in any case.
Furthermore it points to a maintainability issue: The
AACCoefficientsEncoder structures have been constified
in commit fd9212f2ed,
a Libav commit merged in 318778de9e.
Libav did not have the MIPS-specific AAC code and so this was
fine for them; yet FFmpeg had them, but this was not recognized.
Commit 75a099fc73 points to another
maintainability issue: Contrary to ordinary DSP code, this code
here is way more complex and needs to be constantly kept in sync
with the ordinary code which it mimicks and replaces. Said commit
is the only commit actually changing aaccoder.c in the last few
years and the same change has not been performed for the MIPS
clone; before that, it even happened several times that the mips
code was broken due to changes of the generic code (see commits
97437bd17a and
de262d018d or
860dbe0275 or
933309a6ca or
b65ffa316e). This might even lead
to scenarios where someone changing non-dsp aacenc code would
have to modify mips inline asm in order to keep them in sync.
This is obviously a significant burden (if the AAC encoder were
actively developed).
Finally, the code does not even compile here due to errors like
"Error: float register should be even, was 1".
Reviewed-by: Lynne <dev@lynne.ee>
Reviewed-by: Jean-Baptiste Kempf <jb@videolan.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These strings are so short (longest takes 11B) that using
pointers is wasteful. Avoiding them also moves hashdesc
into .rodata (from .data.rel.ro).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In particular, test writing tags with odd strlen.
(These tags are zero-padded to even size.)
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Both GCC and Clang create code that inlines the loops in
next_input() and next_output() at high optimization
levels (presumably when there are not too many devices)
and this code leads to the creation of .got entries:
e7: 48 3b 3d 00 00 00 00 cmp 0x0(%rip),%rdi # ee <av_input_video_device_next+0xe>
ea: R_X86_64_REX_GOTPCRELX ff_alsa_demuxer-0x4
ee: 74 43 je 133 <av_input_video_device_next+0x53>
f0: 48 3b 3d 00 00 00 00 cmp 0x0(%rip),%rdi # f7 <av_input_video_device_next+0x17>
f3: R_X86_64_REX_GOTPCRELX ff_fbdev_demuxer-0x4
f7: 74 41 je 13a <av_input_video_device_next+0x5a>
These relocations can't be fixed up lateron when it is known
that the symbols exist in the same DSO.
This commit therefore marks these symbols as hidden, leading
to code like this:
f7: 48 8d 05 00 00 00 00 lea 0x0(%rip),%rax # fe <av_input_video_device_next+0xe>
fa: R_X86_64_PC32 ff_alsa_demuxer-0x4
fe: 48 39 c7 cmp %rax,%rdi
101: 74 55 je 158 <av_input_video_device_next+0x68>
103: 48 8d 05 00 00 00 00 lea 0x0(%rip),%rax # 10a <av_input_video_device_next+0x1a>
106: R_X86_64_PC32 ff_fbdev_demuxer-0x4
10a: 48 39 c7 cmp %rax,%rdi
10d: 74 50 je 15f <av_input_video_device_next+0x6f>
(Note: It is actually strange that the compiler creates code
that tries to read the addresses from the .got given that the
addresses can be read directly from indev_list/outdev_list.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Avoids .got entries for ff_iamf_scalable_ch_layouts and
ff_iamf_sound_system_map (whether they would have been
created otherwise depends upon the compiler and compiler
options).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
OptionDef.u is only an offset (i.e. its off member) iff OPT_FLAG_OFFSET
is true. Otherwise, the pointer arithmetic can be undefined behaviour.
UBSan warns about this (on 32bit arches):
src/fftools/ffmpeg_opt.c:102:15: runtime error: pointer index expression with base 0xffa4db10 overflowed to 0x56059a50
This commit fixes this by checking for OPT_FLAG_OFFSET first.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
