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>
When scanning through the index, account for the fact that the
compared samples may be located in an unexpected order in the file;
this function is mainly interested in the absolute difference between
file locations.
Signed-off-by: Martin Storsjö <martin@martin.st>
While the inline cabac assembly has worked correctly in i386 builds
historically, modern compiler updates has started showing issues
with it, when the function gets inlined into larger contexts that
fail to provide the amount of free registers as this function
requires.
This was an issue with Clang on Windows on i386, which was fixed
in c6d284b945324a7bc70ea8b9056040c8148aa835. However, recently
the same issues also have started showing up with GCC (both for
Windows and Linux). Whether the issue appears seems dependent on
a lot of optimizer tuning (e.g. the issue appears or goes away
depenent on the combinaton of -march= and -mtune= options),
potentially due to the compiler making different decisions on
how much to inline.
Fixes: https://trac.ffmpeg.org/ticket/8903
Signed-off-by: Martin Storsjö <martin@martin.st>
Add support for writing sBIT chunks, which mark the significant
bit depth of the PNG file. This obtains the metadata using the field
bits_per_raw_sample of AVCodecContext.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Add support for reading sBIT chunks, which mark the significant
bit depth of the PNG file. This passes the metadata using the field
bits_per_raw_sample of AVCodecContext.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Some specifications require the size of ld/eld frames to be 480 samples
instead of the default 512. libfdk_aac provides an option to set an alternative
frame size, but it's not exposed via the ffmpeg interface.
This patch adds a frame_length option to solve this problem.
Signed-off-by: Raphael Schlarb <info@raphael.schlarb.one>
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: James Almer <jamrial@gmail.com>
Otherwise the output format is not changed when output is in system
memory. For example, the output format is still p010le in the following
case:
$ ffmpeg -qsv_device /dev/dri/renderD128 -f lavfi -i testsrc -vf
"format=p010le,vpp_qsv=extra_hw_frames=8:format=nv12" -f null -
...
Output #0, null, to 'pipe:':
Metadata:
encoder : Lavf60.4.100
Stream #0:0: Video: wrapped_avframe, p010le(tv, progressive), 320x240
[SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
