Implement support for including AFD in decklink output when putting
out 10-bit VANC data.
Updated to reflect feedback in 2018 from Marton Balint <cus@passwd.hu>,
Carl Eugen Hoyos <ceffmpeg@gmail.com> and Aaron Levinson
<alevinsn_dev@levland.net>. Also includes fixes to set the AR field
based on the SAR, as well as now sending the AFD info in both fields
for interlaced formats.
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
RIP, if exists is the last KLV item in the MXF files therefore we can stop
parsing the file if it is encountered. This allows us to support files created by
broken muxers such as OpenCube MXFTk Advanced 2.8.0.0.1. which dumps some extra
garbage after the RIP.
Signed-off-by: Marton Balint <cus@passwd.hu>
The function now accepts an existing buffer to avoid unnecessary allocations,
as well as only reporting the needed amount of bytes if you pass a NULL pointer
as input for data.
For this, both parameters become input and output, as well as making data
optional. This is backwards compatible, and as such not breaking any existing
use of the function in external code (if there's any).
Signed-off-by: James Almer <jamrial@gmail.com>
Current log messages talk about 'suitable' output formats. This is
confusing, because it suggests that some formats are suitable, while
others are not, which is not the case.
Also, suggest possible user actions when format cannot be guessed from a
filename.
An uninitialized AVFormatContext instance with neither iformat nor
oformat set will currently log as 'NULL', which is confusing and
unhelpful. Print 'AVFormatContext' instead, which provides more
information.
This happens e.g. if choosing an output format fails in
avformat_alloc_output_context2().
E.g. with the following commandline:
ffmpeg -i <input> -f foobar -y /dev/null
before: [NULL @ 0x5580377834c0] Requested output format 'foobar' is not a suitable output format
after: [AVFormatContext @ 0x55fa15bb34c0] Requested output format 'foobar' is not a suitable output format
When using fractional framerates (or any fraction with a numerator != 1),
DTS values for packets would be calculated incorrectly.
Signed-off-by: Kyle Manning <tt2468@irltoolkit.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
3GPP TS 26.244 Table 8.10 specifies that longitude is written before
latitude. The MOV demuxer already expects the correct order. So, write
them in that order.
However, the user supplied string may also be used in MOV mode which
requires ISO 6709 format which specifies latitude first. The demuxer
also exports the loci value in that format. So parser adjusted as well.
Fixes: shift exponent 34 is too large for 32-bit type 'int'
Fixes: 57389/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ACELP_KELVIN_fuzzer-6229522659016704
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -532410125 + -1759642300 cannot be represented in type 'int'
Fixes: 57045/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVARC_fuzzer-637023665297817
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When writing a subtitle SSA/ASS subtitle file, the AVCodecParameters::extradata
buffer is written directly to the output. In the case where the buffer is
filled from a matroska source file produced by some older versions of
Handbrake, this buffer ends with a null terminating character, which is then
erroneously copied into the middle of the output file. The change here avoids
this problem by treating it as a string rather than a raw buffer. This way it
is agnostic as to whether the source buffer was null terminated or not.
Fixes ticket #10203.
Reported-by: Tim Angus <tim at ngus.net>
Signed-off-by: Marton Balint <cus@passwd.hu>
When including the header in decklink_enc.cpp it would be fed
through the C++ compiler rather than the C compiler, which has
more strict warnings when comparing signed/unsigned values.
Make the local variables unsigned to match the arguments they are
being passed for those functions.
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Clarify failure in case of x/y building a too big matrix.
Example:
$ ffmpeg -hide_banner -f lavfi -i color=c=white:size=640x360,unsharp=lx=5:ly=23 -f null -t 1 -
[Parsed_unsharp_1 @ 0x5650e1c30240] luma matrix size (lx/2+ly/2)*2=26 greater than maximum value 25
color=c=white:size=640x360,unsharp=lx=5:ly=23: Invalid argument
Fix trac issue:
http://trac.ffmpeg.org/ticket/6033
In particular, add a sentence to introduce the example, and add a
simpler starting example with no options.
Also use different format for input.avi and output.mp4, to convey
that the conversion also works on the container format.
Address issue:
http://trac.ffmpeg.org/ticket/8730
Document metadata entries set by the filter, extend and clarify
options, add additional example showing how to extract the generated
data.
Address issue:
http://trac.ffmpeg.org/ticket/8766
This patch will add MPEG4 encoder using Android Mediacodec
Signed-off-by: Samuel Mira <samuel.mira@qt.io<mailto:samuel.mira@qt.io>>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The only encoders avaliable using mediacodec were h264 and hevc. This
patch adds the vp9 encoder.
Signed-off-by: Samuel Mira <samuel.mira@qt.io<mailto:samuel.mira@qt.io>>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Previously, the ff_configure_buffers_for_index function had
upper sanity limits of 16 MB (1<<24) for buffer_size and
8 MB (1<<23) for short_seek_threshold.
However, if the index contained entries with a much larger
delta, setting pos_delta to a value larger than the sanity
limit, we would end up not increasing the buffer size at all.
Instead, ignore the individual deltas that are excessive, but
increase the buffer size based on the deltas that are below the
sanity limit.
Only count deltas that are below 1<<23, 8 MB; pos_delta gets doubled
before setting the buffer size - this matches the previous maximum
buffer size of 1<<24, 16 MB.
This can happen e.g. with a mov file with some tracks containing
some samples that belong in the start of the file, at the end of
the mdat, while the rest of the file is mostly reasonably interleaved;
previously those samples caused the maximum pos_delta to skyrocket,
skipping any buffer size enlargement.
Signed-off-by: Martin Storsjö <martin@martin.st>
J. Dekker
Jerome Martinez
Michael Niedermayer
Devin Heitmueller
Marton Balint
James Almer
Anton Khirnov
Kyle Manning
Gyan Doshi
Stefano Sabatini
Samuel Raposo Vieira Mira
Martin Storsjö