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>
