This change on its own is almost certainly not correct; however, in
testing, many samples show notable improvement.
Signed-off-by: J. Dekker <jdek@itanimul.li>
This allows users to specify an argument such as './configure
--enable-lto=thin' to use ThinLTO with Clang. The old functionality with
'./configure --enable-lto' is preserved.
Signed-off-by: J. Dekker <jdek@itanimul.li>
According to MXF specs the Stored Rectangle corresponds to the data which is
passed to the compressor and received from the decompressor, so they should
contain the width / height extended to the macroblock boundary.
In practice however width and height values rounded to the upper 16 multiples
are only seen when muxing MPEG formats. Therefore this patch changes stored
width and height values to unrounded for all non-MPEG formats, even macroblock
based ones.
For DNXHD the specs (ST 2019-4) explicitly indicates to use 1080 for 1088p.
For ProRes the specs (RDD 44) only refer to to ST 377-1 without precision but
no known commercial implementations are using rounded values.
DV is not using 16x16 macroblocks, so 16 rounding makes no sense.
The patch also fixes Sampled Width / Display Width to use unrounded values.
Signed-off-by: Marton Balint <cus@passwd.hu>
Add the appropriate descriptors to the MPEG-TS demux and mux to
ensure that SMPTE 2038 VANC streams are properly preserved
when using codec copy (including adding the appropriate PMT
descriptors).
The focus of this patch is TS input to TS output. A separate
patch adds support for output of 2038 VANC over decklink SDI.
Thanks to Marton Balint for feedback to preserve ABI compatibility.
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Add stack_internal.h to the list of skipped headers to fix
make checkheaders fail, it's introduced by commit 742dfa281
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
This way we can clean up separate definitions in functions with
just a single loop, as well as have no reuse between different
loops' counters in functions with multiple.
This is more correct, but was not possible before the recently-added
filtergraph parsing API.
Also, only pass hw devices to filters that are flagged as capable of
using them.
Tested-by: Niklas Haas
This reverts commit 9413bdc381.
That commit broke the fate HEVC tests - unfortunately I only
tested checkasm for that patch, and that function is still
lacking checkasm coverage.
Signed-off-by: Martin Storsjö <martin@martin.st>
pts may not be set on input packets, which could result in the entire stream
being discarded.
This reverts commit 8fc2dedfe6, reintroducing the
behavior it replaced but now allowing the caller to manually drop the preroll
samples by looking at the skip_samples side data at the start while ignoring it
on seek, by setting the skip_manual avctx flag.
Fixes ticket #10251.
Suggested-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: James Almer <jamrial@gmail.com>
These fields are supposed to store information about the packet the
frame was decoded from, specifically the byte offset it was stored at
and its size.
However,
- the fields are highly ad-hoc - there is no strong reason why
specifically those (and not any other) packet properties should have a
dedicated field in AVFrame; unlike e.g. the timestamps, there is no
fundamental link between coded packet offset/size and decoded frames
- they only make sense for frames produced by decoding demuxed packets,
and even then it is not always the case that the encoded data was
stored in the file as a contiguous sequence of bytes (in order for pos
to be well-defined)
- pkt_pos was added without much explanation, apparently to allow
passthrough of this information through lavfi in order to handle byte
seeking in ffplay. That is now implemented using arbitrary user data
passthrough in AVFrame.opaque_ref.
- several filters use pkt_pos as a variable available to user-supplied
expressions, but there seems to be no established motivation for using them.
- pkt_size was added for use in ffprobe, but that too is now handled
without using this field. Additonally, the values of this field
produced by libavcodec are flawed, as described in the previous
ffprobe conversion commit.
In summary - these fields are ill-defined and insufficiently motivated,
so deprecate them.