Also remove AV_LOG_SIMULATE from the list as it is not used directly, and do
not use panic level on unknown loglevel, but make them warn. Also fix mapping of
NOTICE/INFO/VERBOSE and add documentation about when the option should actually
be used.
Signed-off-by: Marton Balint <cus@passwd.hu>
Maximum packet size is 10000 (RIST_MAX_PACKET_SIZE, which is unfortunately
private) minus the RIST protocol overhead which is 28 bytes for the unencrypted
case, 36 for the encrypted case.
Signed-off-by: Marton Balint <cus@passwd.hu>
Queue tracking makes no difference so remove it, return EAGAIN of no data is
available and rist data block needs to be freed even for zero sized packets.
Signed-off-by: Marton Balint <cus@passwd.hu>
av_get_packet() already makes sure that the packet size is accurate
and that the packet data is zero-padded even when one could not read as
much as desired.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This commit adds a "gophers" handler to the gopher protocol. gophers
is a community-adopted protocol that acts the same way like normal
gopher with the added TLS encapsulation.
The gophers protocol is supported by gopher servers like geomydae(8),
and clients like curl(1), clic(1), and hurl(1).
This commit also adds compilation guards to both gopher and gophers,
since now there are two protocols in the file it makes sense to
have this addition.
Signed-off-by: parazyd <parazyd@dyne.org>
Signed-off-by: Marton Balint <cus@passwd.hu>
AviSynth+ outputs audio in the same format as the
OS, so assuming little endian formats as input
on big endian OSes results in nothing but static.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
avs_is_color_space provides a generic way of checking whether the
video is RGB, and has been available through AVSC_API since 2.6.
This means that GetProcAddress doesn't have to run on every frame.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
av_stream_add_side_data() already defines size as a size_t, so this makes it
consistent across all side data functions.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: -2.21166e+304 is outside the range of representable values of type 'long'
Fixes: 29169/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5725452796821504
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Timeout (too long -> 241ms)
Fixes: 29083/clusterfuzz-testcase-minimized-ffmpeg_dem_SWF_fuzzer-6273684478230528
The source of the magic number is
A very quick simulation of the best case compression for "compress"
below is not nice written code as i did not expect I or anyone else
would ever see it again
I would have preferred some nicer expression or course, but thats
what it seems to be asymptotically. For smaller amounts of data a
tighter bound is possible but i saw no nice way to consider that
and it seems also overkill to try to do it more fine grained for
just this
main(){
int64_t bits = 0;
int bank = 256;
int bitbank = 8;
for(unsigned i = 0; i<1024*1024*1024*4U-100000;) {
int word_size = bank-255;
i += word_size;
bits += bitbank;
if (!(bank & (bank-1)))
bitbank ++;
bank++;
if (bitbank > 16) {
printf("BEST %f \n", 8.0 * i / bits );
bank = 256;
bitbank = 8;
}
}
}
above assumes i remembered correctly how the algorithm works but the
value was close to what actual compession of zeros gave
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The Mobiclip related code was based on Mobius (https://github.com/adibsurani/Mobius),
which was based on my original reverse engineering efforts (https://github.com/Gericom/MobiclipDecoder).
This commit adds the appropriate copyright headers on the related files.
Signed-off-by: Florian Nouwt <fnouwt2@gmail.com>
When the deprecated option "user-agent" was set to something different
than its default value, said option would always precede and overwrite
the ordinary user_agent option (regardless of whether it was explicitly
set) which leads to a leak of the user_agent option (which has a default
value, so the leak happens always).
Fix this by setting the same destination for both options; the last
option applied wins then.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Enables writing TTML documents or encoded TTML paragraphs as such
documents.
Additionally, a test for the combined TTML encoder and muxer has
been added to validate that the components still work.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
While this usage of strncpy is correct, said function nevertheless has
the disadvantage of not automatically ensuring that the destination
string is zero-terminated. So av_strlcpy should be preferred.
This also removes a -Wstringop-truncation warning from GCC (it doesn't
matter whether the buffer is truncated, as long as it can fit all
the names of the supported codecs).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It only got added recently, and the new name makes it consistent with
product_version_num in the next patch.
Signed-off-by: Marton Balint <cus@passwd.hu>
Fixes: signed integer overflow: 538976288 * 8 cannot be represented in type 'int'
Fixes: 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_LXF_fuzzer-6634030636335104
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: -9223372036854775808 + -242 cannot be represented in type 'long'
Fixes: 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_MCC_fuzzer-6723018395090944
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: OOM
Fixes: 28348/clusterfuzz-testcase-minimized-ffmpeg_dem_MSP_fuzzer-4612055872831488
Fixes: 28360/clusterfuzz-testcase-minimized-ffmpeg_dem_MSP_fuzzer-6245230626078720
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Infinite loop
Fixes: 30874/clusterfuzz-testcase-minimized-ffmpeg_dem_AIFF_fuzzer-5933710488764416
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -1300248894420254720 * 16 cannot be represented in type 'long'
Fixes: 30879/clusterfuzz-testcase-minimized-ffmpeg_dem_DCSTR_fuzzer-5094464215449600
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The fourccs used by the Megalux Frame format to determine the pixel
format are actually no fourccs at all as they are a single byte.
Furthermore, their range is continuous (1-5), so they are actually
ordinary indices. So treat them as such and don't use PixelFormatTags
for them.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This flag was added in 492026209b
in conjunction with av_demuxer_open() to allow to pass private
options to demuxers. It worked as follows: av_open_input_stream()
(the predecessor of avformat_open_input()) would not call the
read_header function if this flag is set. Instead the user could set
private options of the demuxer via the format's private class after
avformat_open_input() and then call av_demuxer_open() which called
the format's read_header function.
This approach was abandoned in e37f161e66
and av_demuxer_open() deprecated; instead the AVDictionary based way of
passing private options to the demuxer was choosen. Yet
AVFMT_FLAG_PRIV_OPT has never been deprecated and av_demuxer_open()
never removed. This commit implements the deprecation of the flag and
schedules av_demuxer_open for removal on the next major bump.
Given that av_demuxer_open() has been deprecated in 2012 and that this
flag is useless without it, the flag will be ignored after the next
major version bump.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
strncpy only ensures that one does not write beyond the end of the
destination buffer; in case of truncation it does not zero-terminate
the destination buffer. This makes using it the way it is now in the
DASH demuxer dangerous. So use av_strlcpy instead.
Also don't write anything if there is no id: The buffer has already been
zeroed initially.
The DASH testset from the Universität Klagenfurt contains samples with
ids that are too long. E.g.
http://ftp.itec.aau.at/datasets/DASHDataset2014/TearsOfSteel/1sec/TearsOfSteel_1s_simple_2014_05_09.mpd
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Needs a CountedElement in order to distinguish the case of the element
not being present and the element being present with a value of zero.
(It has been argued by Ridley Combs that one should only ever use the
AV_DISPOSITION_DUB field for audio tracks. Yet given that there is no
definition for the disposition flags, one can also interpret it to mean
that e.g. a subtitle track is meant to be used with the dubbed audio
track or the original audio track. This commit interprets this flag in
this sense, which also allows to maintain it on remuxing.)
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: -2147483634 - 16 cannot be represented in type 'int'
Fixes: 28322/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5711888402612224
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: -2147483648 - 4 cannot be represented in type 'int'
Fixes: 28127/clusterfuzz-testcase-minimized-ffmpeg_dem_VOC_fuzzer-4880586455646208
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also make the macro used for the demuxers spec-compliant. The earlier
macro was not, because the ... argument of a variadic macro must not be
left out. GCC and Clang warn about this when using -pedantic.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Memory for auxillary_info was not freed after usage.
Leak can be reproduced with following commands:
Optionally, generate input video:
ffmpeg -f lavfi -i testsrc=duration=10:size=1280x720:rate=30 input.mp4
Run ffmpeg with valgrind:
valgrind --leak-check=full --show-leak-kinds=all \
ffmpeg -y -i input.mp4 -vcodec copy -acodec copy \
-encryption_scheme cenc-aes-ctr \
-encryption_key 00000000000000000000000000000000 \
-encryption_kid 00000000000000000000000000000000 \
ffmpeg_encrypted.mp4
For test video which has duration of 10 sec, leak is 4 Kb.
For 100 sec video, leak will be 33 Kb. Most likely,
leaked memory will grow linearly to the number of input frames.
Signed-off-by: Vadym Bezdushnyi <vadim.bezdush@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
This code was written when the allocation functions used parameters of
type unsigned. This is no longer true today and therefore we only need
to check whether the multiplication of the array's size stays within
a size_t -- and this can be offloaded to av_realloc_array.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the wav muxer used a reallocation of the form ptr =
av_realloc(ptr, size); that leaks upon error. Furthermore, if a
failed reallocation happened when writing the trailer, a segfault
would occur due to avio_write(NULL, size) because the muxer only
prints an error message upon allocation error, but does not return
the error.
Moreover setting the pointer to the buffer to NULL on error seems to
be done on purpose in order to record that an error has occured so that
outputting the peak values is no longer attempted. This behaviour has
been retained by simply disabling whether peak data should be written
if an error occurs.
Finally, the reallocation is now done once per peak block and not once
per peak block per channel; it is also done with av_fast_realloc and not
with a linear size increase.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
1582e306a4 scheduled it for removal with
libavformat major version 58, but it was never removed.
Reviewed-by: Paul B Mahol <onemda@gmail.com
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
AVID streams - currently handled by the AVRN decoder - can be (depending
on extradata contents) either MJPEG or raw video. To decode the MJPEG
variant, the AVRN decoder currently instantiates a MJPEG decoder
internally and forwards decoded frames to the caller (possibly after
cropping them).
This is suboptimal, because the AVRN decoder does not forward all the
features of the internal MJPEG decoder, such as direct rendering.
Handling such forwarding in a full and generic manner would be quite
hard, so it is simpler to just handle those streams in the MJPEG decoder
directly.
The AVRN decoder, which now handles only the raw streams, can now be
marked as supporting direct rendering.
This also removes the last remaining internal use of the obsolete
decoding API.
Commit 0d1229f1d2 factored the main part
of the voc demuxer's read_packet function out; yet when this Libav
commit was merged in f99195d56f, the
dependency of the other users of this function on vocdec.o was
unnecessarily kept. This commit fixes this.
While just at it, also disable the data only used by the voc demuxer
and muxer in voc.c if both of them are disabled.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The options of the w64 demuxer are a proper subset of the options for
the wav demuxer, making it possible to reuse a part of the options for
the wav demuxer for the w64 demuxer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The NUT and avi demuxers only need ff_codec_movvideo_tags and so this
removes a dependency on the rest of isom.c as well as on mpeg4audio.c
(which isom depends on); it is similar for the Matroska demuxer and
muxers, except that the mpeg4audio.c dependency can't be avoided.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is a result of the mov channel parsing stuff being factored out
of mov.c twice: Once in 91b782720f
to isom.c and later in 3bab7cd128.
Also remove the isom.h header; and while just at it, remove an unused
mathematics.h inclusion.
(isom.c actually depends upon mpeg4audio from libavcodec for
avpriv_mpeg4audio_get_config2 and avpriv_mpa_freq_tab; yet there is
no configure dependency for iso_media which leads to failure of shared
builds.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Neither the feature, public fields, or AVOptions were ever truly deprecated,
nor will have been removed if this FF_API_ define was left in place, so
get rid of it as it's misleading.
Signed-off-by: James Almer <jamrial@gmail.com>
The current behaviour ends up squaring the avg_frame_rate if the conter mode flag is set.
This messes up the timecode calculation, and looks to me as a regression that
seems to have been introduced 428b4aac.
Upon further testing is seems that no special case is need for having the counter flag set.
av_timecode_init appears to handles the timecode correctly, at least in the sample files
I have.
Here is a sample mov file with the counter flag set
https://www.dropbox.com/s/5l4fucb9lhq523s/timecode_counter_mode.mov
before the patch ffmpeg will report the timecode as:
00:37:11:97 and warns that the timecode framerate is 576000000/1002001
after patch:
14:50:55:02
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This is the Matroska equivalent of D_WEBVTT_DESCRIPTIONS and is
therefore only enabled for subtitles.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is the equivalent of the WebM "D_WEBVTT/DESCRIPTIONS" and is
therefore only exported for subtitles.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Given that our disposition flags provide no way to distinguish the
cases of "track is unsuitable for hearing impaired users" and "it is
unknown whether the track is suitable for hearing impaired users" we do
not need to use a CountedElement for these flags.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Hint: Matroska actually provides a way to distinguish the cases of
"track is no commentary track" and "it is unknown whether the track
is a commentary track", but our disposition flags do not. Therefore
we need not use a CountedElement.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
For a very long time, the payload of integer and float elements had to
have a length > 0. Our parser treated such invalid elements as having a
value zero. But now it has been defined what an EBML element with length
zero means: It is a shorthand for the default value. This has also been
defined for strings (both ASCII and UTF-8). This commit modifies our
parser to support this.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This has been done in order to find out whether this element is present
at all; but this can now be done in a cleaner way by using a CountedElement
for it.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
According to the new EBML specifications, a string element of length
zero would be read as the default value by a compliant parser.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
In the absence of an explicitly coded minimal luminance, the current
code inferred it to be -1, an invalid value. Yet it did not check the
value lateron at all, so that if a valid maximum luminance is
encountered, but no minimal luminance, an invalid minimal luminance of
-1 is exported. If an minimal luminance element with a negative value is
present, it is exported, too. This can be simply fixed by adding a check
for the value of the element.
Yet given that a minimal luminance of zero Cd/m² is legal and can be
coded with a length of zero, we must not use a fake default value to
find out whether the element is present or not. Therefore this patch
uses an explicit counter for it.
While just at it, also check for max_luminance > min_luminance.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
