From: Jun Zhao
Before this change, the command:
ffmpeg -y -i bear-av1.mp4 -c:v copy bear-av1.ivf -loglevel 99
always dump the log message like:
AVBSFContext @ 0x55ff99e78e00] Frame 4: size 320x240 upscaled 320 render
320x240 subsample 2x2 bitdepth 8 tiles 1x1.
Last message repeated
On 15-12-2019 06:46 am, Marton Balint wrote:
Unfortunately the ld() and st() operations store the variables in the AVExpr
context and not in the parser in order to keep the stored values between
evaluations (which is a rarely(?) used undocumented(?) feature of AVExpr).
This causes data race is
On Sun, Dec 15, 2019 at 4:48 AM Marton Balint wrote:
>
>
> On Wed, 4 Dec 2019, Jun Zhao wrote:
>
> > From: Jun Zhao
> >
> > Enable the SRTO_ENFORCEDENCRYPTION/SRTO_KMREFRESHRATE/
> > SRTO_KMPREANNOUNCE for srt encryption control.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > doc/protocols.texi |
Hi,
> -Original Message-
> From: Fu, Linjie
> Sent: Wednesday, December 11, 2019 16:46
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie ; Xu, Guangxin
> Subject: [PATCH 1/4] tests/checkasm: add overflow test for hevc_add_res
>
> Add overflow test for hevc_add_res when int16_t coeff = -327
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Thilo Borgmann
> Sent: Thursday, December 12, 2019 22:15
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/hevc_cabac: fix cbf_cb and cbf_cr
> for transform depth 4
>
> Hi,
>
> Am 12.12.19 um 08:27 schrieb Fu
Unfortunately the ld() and st() operations store the variables in the AVExpr
context and not in the parser in order to keep the stored values between
evaluations (which is a rarely(?) used undocumented(?) feature of AVExpr).
This causes data race issues when the same expression is evaluated from
m
> +static av_cold void braw_static_init(void)
> +{
> +INIT_VLC_STATIC(&dc_vlc, 13, 16, dc_bits, 1, 1, dc_codes, 2, 2, 8192);
> +INIT_VLC_STATIC(&ac_vlc, 18, 194, ac_bits, 1, 1, ac_codes, 4, 4, 262144);
> +}
> +
> +.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
> +
On Sat, 14 Dec 2019, Alexandre Heitor Schmidt wrote:
avfilter/drawtext: Added two special metadata tags which can, be used by
'drawtext' filter and others to have access to source file path, and its
basename.
The new field AVPacket->source_file will contain a path to its corresponding
filenam
On Fri, 13 Dec 2019, James Almer wrote:
On 12/13/2019 8:07 PM, Martin Storsjö wrote:
I intentionally meant to use a different variable for that, to
differentiate between the configure-generated CONFIG_LARGE_TESTS from
config.mak and the one that is set to pick up a potential user-supplied
value
On Sat, 14 Dec 2019, James Almer wrote:
On 12/14/2019 7:50 PM, Marton Balint wrote:
On Sat, 14 Dec 2019, James Almer wrote:
On 12/7/2019 6:57 PM, Marton Balint wrote:
In order to access the original opaque parameter of a buffer in the
buffer
pool. (The buffer pool implementation override
avfilter/drawtext: Added two special metadata tags which can, be used by
'drawtext' filter and others to have access to source file path, and its
basename.
The new field AVPacket->source_file will contain a path to its corresponding
filename everytime the packet corresponds to a single file. This
On 12/14/2019 7:50 PM, Marton Balint wrote:
>
>
> On Sat, 14 Dec 2019, James Almer wrote:
>
>> On 12/7/2019 6:57 PM, Marton Balint wrote:
>>> In order to access the original opaque parameter of a buffer in the
>>> buffer
>>> pool. (The buffer pool implementation overrides the normal opaque
>>> p
On Sat, 14 Dec 2019, James Almer wrote:
On 12/7/2019 6:57 PM, Marton Balint wrote:
In order to access the original opaque parameter of a buffer in the buffer
pool. (The buffer pool implementation overrides the normal opaque parameter but
also saves it so it is accessible).
Signed-off-by: Mar
Mainly reindentation, but some variables were also put into a smaller
scope.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h264_mp4toannexb_bsf.c | 50 +++
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/libavcodec/h264_mp4toannexb_bsf.c
b/libavcod
According to the H.264 specifications, the only NAL units that need to
have four byte startcodes in H.264 Annex B format are SPS/PPS units and
units that start a new access unit. Before af7e953a, the first of these
conditions wasn't upheld as already existing in-band parameter sets
would not automa
bytestream2_get_bytes_left returns an unsigned int; as a result,
it returns big positive numbers if an overread already happened,
making it unsuitable for scenarios where one wants to allow this
in a controlled way (because the buffer is actually padded so that
no segfaults can happen). So change i
Before reading a 16bit size field during parsing of extradata, no check
is performed to make sure that said length field is actually contained
in the extradata. Given that this overread is not dangerous (the extradata
is supposed to be padded), only a comment for it has been added; the error
itself
This is done in order to improve readability. No functional change is
intended with this commit at all; in particular, the unsafe read
functions are used throughout as h264_extradata_to_annexb already
performs its own checks. (These checks will nevertheless be improved
in further commits.)
Signed-
If processing an input NAL unit triggers the insertion of data from
extradata in front of said NAL unit, the output packet is grown (i.e.
reallocated) once to accomodate both the new extradata as well as the
input NAL unit itself; this has been changed: In such a situation, the
packet is now grown
Up until now, h264_mp4toannexb would grow the output packet's buffer by
the desired amount every time another NAL unit of the input packet has
been read; this commit changes this: The input buffer is now essentially
parsed twice, once to determine the final size of the output packet and
once to wri
There can be at most 31 SPS and 255 PPS in the mp4/Matroska extradata.
Given that each has a size of at most 2^16-1, the length of the output
derived from these parameter sets can never overflow an ordinary 32 bit
integer. So use a simple uint32_t instead of uint64_t and replace the
unnecessary che
h264_mp4toannexb_filter currently uses both indices/offsets as well as
direct pointers comparisons for the checks whether one has reached or
even surpassed the end. This commit removes the offsets.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h264_mp4toannexb_bsf.c | 6 +-
1 file changed
1. Left shifts of signed values are undefined as soon as the result is
no longer representable in the target type. Therefore make nal_size
an uint32_t and drop the check for whether it is < 0.
2. The two checks for overreads (whether the length field is contained
in the packet and whether the actua
3469cfab added a check for whether the extradata coincided with the
beginning of the packet's data in order not to add extradata to packets
that already have it. But the check used was buggy for packets whose
size is smaller than the extradata's size. This commit fixes this.
Signed-off-by: Andreas
The format of an AVCDecoderConfigurationRecord, the out-of-band
extradata of H.264 in mp4, is as follows: First four bytes containing
version, profile and level, one byte for the length size and one byte
each for the number of SPS, followed by the SPS (each with its own size
field), followed by a b
Currently during parsing the extradata, h264_mp4toannexb checks for
overreads by adding the size of the current unit to the current position
pointer and comparing this to the end position of the extradata. But
pointer comparisons and pointer arithmetic are only defined if it does not
exceed the obj
Up until now, h264_mp4toannexb stored the offset of the first SPS and
the first PPS in the (output) extradata in its context and used these
two numbers together with the size of the extradata and the pointer to
the extradata to determine what to insert when inserting extradata. This
led to some ver
On 12/7/2019 6:57 PM, Marton Balint wrote:
> In order to access the original opaque parameter of a buffer in the buffer
> pool. (The buffer pool implementation overrides the normal opaque parameter
> but
> also saves it so it is accessible).
>
> Signed-off-by: Marton Balint
> ---
> doc/APIchang
On Thu, Nov 21, 2019 at 11:26:11PM +0100, Michael Niedermayer wrote:
> Fixes: Timeout (37sec -> 52ms)
> Fixes:
> 18892/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TARGA_fuzzer-5739537854889984
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/project
On Sat, Nov 23, 2019 at 06:21:16PM +0100, Michael Niedermayer wrote:
> Fixes: Infinite loop
> Fixes:
> 18914/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMAVOICE_fuzzer-5731902946541568
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpe
On Wed, Nov 20, 2019 at 11:23:27PM +0100, Michael Niedermayer wrote:
> Fixes: left shift of negative value -1
> Fixes:
> 18859/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ADPCM_XA_fuzzer-5748474213040128
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/mas
On Mon, Nov 18, 2019 at 05:30:10PM +0100, Michael Niedermayer wrote:
> Fixes: Timeout (unknown -> 15sec)
> Fixes:
> 18808/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5677586072207360
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projec
On Sat, Dec 14, 2019 at 01:23:04PM +0100, Paul B Mahol wrote:
> lgtm
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The smallest minority on earth is the individual. Those who deny
individual rights cannot claim to be defenders of minorities. -
On Sat, Dec 14, 2019 at 08:58:55PM +0100, Paul B Mahol wrote:
> lgtm
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
On Wed, 4 Dec 2019, Jun Zhao wrote:
From: Jun Zhao
Enable the SRTO_ENFORCEDENCRYPTION/SRTO_KMREFRESHRATE/
SRTO_KMPREANNOUNCE for srt encryption control.
Signed-off-by: Jun Zhao
---
doc/protocols.texi | 20
libavformat/libsrt.c | 18 ++
2 files change
On Sat, 14 Dec 2019, James Almer wrote:
On 12/7/2019 6:57 PM, Marton Balint wrote:
Also by wrapping the SHM buffer in an AVBufferRef we eliminate yet another
possible memcpy improving performance.
Signed-off-by: Marton Balint
---
libavdevice/xcbgrab.c | 79 ++
lgtm
On 12/14/19, Michael Niedermayer wrote:
> Fixes: Ticket8430
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/pnm.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/libavcodec/pnm.c b/libavcodec/pnm.c
> index b4e5d3076b..b5c2881948 100644
> --- a/libavcodec/pnm.c
> +
On 12/7/2019 6:57 PM, Marton Balint wrote:
> Also by wrapping the SHM buffer in an AVBufferRef we eliminate yet another
> possible memcpy improving performance.
>
> Signed-off-by: Marton Balint
> ---
> libavdevice/xcbgrab.c | 79
> ++-
> 1 file ch
On Sat, 7 Dec 2019, Marton Balint wrote:
In order to access the original opaque parameter of a buffer in the buffer
pool. (The buffer pool implementation overrides the normal opaque parameter but
also saves it so it is accessible).
Ping. Will apply soon.
Thanks,
Marton
Signed-off-by: Mar
Fixes: Ticket8430
Signed-off-by: Michael Niedermayer
---
libavcodec/pnm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavcodec/pnm.c b/libavcodec/pnm.c
index b4e5d3076b..b5c2881948 100644
--- a/libavcodec/pnm.c
+++ b/libavcodec/pnm.c
@@ -117,6 +117,9 @@ int ff_pnm_decode_header(
On 12/14/2019 9:08 AM, Michael Niedermayer wrote:
> Fixes: out of array read
> Fixes:
> 19300/clusterfuzz-testcase-minimized-ffmpeg_BSF_VP9_METADATA_fuzzer-5653911730126848
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by:
On 12/14/2019 2:43 PM, Michael Niedermayer wrote:
> Fixes: assertion failure
> Fixes:
> 19301/clusterfuzz-testcase-minimized-ffmpeg_BSF_AV1_FRAME_MERGE_fuzzer-5743212006473728
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-b
Fixes: assertion failure
Fixes:
19301/clusterfuzz-testcase-minimized-ffmpeg_BSF_AV1_FRAME_MERGE_fuzzer-5743212006473728
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cbs_av1_syntax_template.
Fixes: out of array access
Fixes: inf is outside the range of representable values of type 'int'
Fixes: signed integer overflow: -9223372036854775808 - 1 cannot be represented
in type 'long'
Fixes:
19316/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMAVOICE_fuzzer-5677369365102592
Found-by:
On 12/14/2019 1:36 PM, Carl Eugen Hoyos wrote:
> Am Sa., 14. Dez. 2019 um 00:02 Uhr schrieb James Almer :
>
>> BIG is too generic
>
> Within fate?
>
> Carl Eugen
For a make option. It could be anything. Big tests? Big binaries?
I already said i'm fine with it if no other option is ok for other
Am Sa., 14. Dez. 2019 um 00:02 Uhr schrieb James Almer :
> BIG is too generic
Within fate?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffm
Am Sa., 14. Dez. 2019 um 08:28 Uhr schrieb zhilizhao :
> > On Dec 13, 2019, at 10:00 PM, Paul B Mahol wrote:
> >
> > Please provide some explanation.
>
> No functional changes, just use temporary variables to make code more
> readable,
> and may improve a little bit of performance.
Such a clai
On Thu, Oct 17, 2019 at 10:29:41AM +0200, Andreas Rheinhardt wrote:
> Up until now, h264_mp4toannexb would grow the output packet's buffer by
> the desired amount every time another NAL unit of the input packet has
> been read; this commit changes this: The input buffer is now essentially
> parsed
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/bsf.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c
index c1653cd..a5a5a03 100644
--- a/libavcodec/bsf.c
+++ b/libavcodec/bsf.c
@@ -175,9 +175,11
lgtm
On 12/14/19, Michael Niedermayer wrote:
> Fixes: out of array read
> Fixes:
> 19309/clusterfuzz-testcase-minimized-ffmpeg_BSF_MP3_HEADER_DECOMPRESS_fuzzer-5651002950942720
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-b
Fixes: out of array read
Fixes:
19309/clusterfuzz-testcase-minimized-ffmpeg_BSF_MP3_HEADER_DECOMPRESS_fuzzer-5651002950942720
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/mp3_header_decompr
Fixes: out of array read
Fixes:
19300/clusterfuzz-testcase-minimized-ffmpeg_BSF_VP9_METADATA_fuzzer-5653911730126848
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cbs_vp9.c | 3 +++
1 file c
Signed-off-by: Paul B Mahol
---
Does not use optimized 8x8 idct as its buggy and give errors around high
contrast borders.
Sending to receive general feedback and useful comments.
Still probabbly missing additional post processing.
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c
Am Fr., 13. Dez. 2019 um 23:06 Uhr schrieb Michael Niedermayer
:
>
> On Fri, Dec 13, 2019 at 07:13:20PM +0100, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached patch fixes decoding a sample provided on irc.
> >
> > Please comment, Carl Eugen
>
> > pnmdec.c |2 +-
> > 1 file changed, 1 insertio
54 matches
Mail list logo
