Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It's often not obvious how option constants relate to numerical values.
Defaults are sometimes printed as numbers and from/to are always printed as numbers.
Printing the numeric values of options constants avoids this confusion.
It also allows to see which constants are equivalent.
Before this patch:
-segment_list_type <int> E........ set the segment list type (from -1 to 4) (default -1)
flat E........ flat format
csv E........ csv format
ext E........ extended format
ffconcat E........ ffconcat format
m3u8 E........ M3U8 format
hls E........ Apple HTTP Live Streaming compatible
Afterwards:
-segment_list_type <int> E........ set the segment list type (from -1 to 4) (default -1)
flat 0 E........ flat format
csv 1 E........ csv format
ext 3 E........ extended format
ffconcat 4 E........ ffconcat format
m3u8 2 E........ M3U8 format
hls 2 E........ Apple HTTP Live Streaming compatible
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Integer values should not be printed using format specifier '%g' which leads to inexact display in case of higher values.
Before this patch:
-trans_color <int> .D.V..... color value [...] (default 1.67772e+07)
Afterwards:
-trans_color <int> .D.V..... color value [...] (default 16777215)
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes the FATE-tests unknown_layout-ac3, ac3-fixed-encode, ac3-encode
and eac3-encode. It furthermore fixes the ac3-encoder bugs mentioned in
tickets #7994, #8144 and #8159.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes the FATE-tests g723_1-dec-1, g723_1-dec-2 and g723_1-dec-4.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The reason to add this layer is that it is used by srcnn in vf_sr.
This layer is currently ignored in native mode. After this patch,
we can add multiple outputs support for native mode.
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Pedro Arthur <bygrandao@gmail.com>
the logic is that one layer in one separated source file to make
the source files simple for maintaining.
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Pedro Arthur <bygrandao@gmail.com>
the logic is that one layer in one separated source file to make
the source files simple for maintaining.
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Pedro Arthur <bygrandao@gmail.com>
av_mod_uintp2_c uses a bitwise AND with (1 << p) - 1 to clear the high
bits of an unsigned int. But this is undefined if p == 31, because 1 is
an int and 2^31 is not representable in an int. So make 1 unsigned.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
av_mallocz + av_init_packet leads to the same result as av_mallocz +
av_packet_unref, but faster.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This has been forgotten in d5a3a20d.
Found via PVS-Studio (see ticket #8156).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
1. Instead of relying on ff_packet_list_get to get the oldest element in
an AVPacketList, ff_read_packet used its own ad-hoc code. Said code
forgot to set the end of the list to NULL if the last element of the
list has been removed, thereby leaving the list in an inconsistent state.
2. Furthermore, if the list was not empty, the oldest element of the
list would always be copied into another packet structure before it was
known whether the oldest entry of the list would be removed. This makes
the ownership confusing and potentially copies unnecessarily.
Both of these issues have been fixed. ff_packet_list_get is used now.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The documentation of ff_packet_list_get currently didn't match the
actual usage:
1. It said that the destination packet is supposed to be initialized.
But this makes no sense given that it will be overwritten completely and
flacenc, mp3enc and ttaenc ignored this.
2. ff_packet_list_get returns an int, although it can't fail in case the
packet list is not empty (for which there is an assert). Again, several
callers didn't check for any return value.
In both cases, the documentation has been adapted to match actual usage.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Timeout (89sec -> 7sec)
Fixes: 17035/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BINK_fuzzer-5737222422134784
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When the mov/mp4 demuxer encounters an error during decrypting a packet,
it returns the error, yet doesn't free the packet, so that the packet
leaks. This has been fixed in this commit.
Fixes the memleaks from ticket #8150.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ttaenc contained (1 << unary) - 1 as an argument for a function
expecting an unsigned int. unary can be as big as 31 in this case.
The type of the shift and the whole expression is int, because 1 fits
into an integer, so that the behaviour is undefined if unary == 31
as the result of the shift can't be represented in an int §. Subtraction
by 1 (which makes the result of the whole expression representable in
an int) doesn't change that this is undefined (it usually leads to
signed integer overflow which is undefined, too).
The solution is simple: Make 1 unsigned to change the type of the
whole expression to unsigned int (as the function expects anyway).
Fixes ticket #8153.
§: This of course presupposes the common int range of -2^31..2^31-1
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Michael Niedermayer
Moritz Barsnick
Soft Works
Andreas Rheinhardt
Paul B Mahol
Guo, Yejun
elliottk
James Almer
Carl Eugen Hoyos
Anthony Delannoy
Marton Balint
Limin Wang
hwrenx