On Tue, Aug 13, 2019 at 10:56:03AM +0200, Jean-Baptiste Kempf wrote:
> Are those values even acceptable according to spec?
Which spec ?
SMPTE 421M ?
no, i think not
wmv3image (which is what the fuzzer tested)
iam not sure if we have a spec about it.
> Shouldn't 16k*16K be the maximum allowed?
ons 2019-08-14 klockan 19:42 +0200 skrev Michael Niedermayer:
> On Wed, Aug 14, 2019 at 05:21:49PM +0200, Tomas Härdin wrote:
> > mån 2019-08-12 klockan 21:17 +0200 skrev Michael Niedermayer:
> > > Fixes: Timeout (31sec -> 22sec)
> >
> > Is this a large test case? 22sec still sounds excessive
>
On Wed, Aug 14, 2019 at 10:11 PM Reimar Döffinger
wrote:
> On 14.08.2019, at 11:45, Paul B Mahol wrote:
> > I strongly disagree with you. Why some people have subscription to
> security
> > mailing list and I'm not allowed also?
>
> Long version, explaining to the best of my knowledge and
Hi
Attached patch detects when the cinepak encoder has generated a
keyframe on its own, and pushes the generation of forced keyframes into
the future. This is similar to what msvideo1enc.c does.
Example:
$ ./ffmpeg -i fate-suite/zmbv/zmbv_32bit.avi -keyint_min 20 -vcodec
cinepak out-before.avi
ons 2019-08-14 klockan 12:32 +0200 skrev Tomas Härdin:
> mån 2019-08-12 klockan 21:17 +0200 skrev Michael Niedermayer:
> > Fixes: Timeout (12sec -> 32ms)
> > Fixes: 16078/clusterfuzz-testcase-minimized-
> > ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5695832885559296
> >
> > Found-by: continuous fuzzing
Am Do., 15. Aug. 2019 um 11:01 Uhr schrieb Tomas Härdin :
> ons 2019-08-14 klockan 22:18 +0200 skrev Thomas Mundt:
> > Hi Tomas,
> >
> > Am Mi., 14. Aug. 2019 um 12:42 Uhr schrieb Tomas Härdin <
> tjop...@acc.umu.se
> > > :
> > > tis 2019-08-13 klockan 22:03 +0200 skrev Thomas Mundt:
> > > > Hi,
Hi,
On Wed, Aug 14, 2019 at 11:50 PM Michael Niedermayer
wrote:
>
> On Wed, Aug 14, 2019 at 08:44:11PM +0200, Stanislav Ionascu wrote:
> > On Tue, Aug 13, 2019 at 10:22 PM Andreas Rheinhardt
> > wrote:
> > >
> > > Stanislav Ionascu:
> > > > Per matroska spec, v_quicktime contains the complete
Fix tiket#8065
Signed-off-by: Zhong Li
---
libavfilter/vf_vpp_qsv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
index f18513359a..858587411d 100644
--- a/libavfilter/vf_vpp_qsv.c
+++ b/libavfilter/vf_vpp_qsv.c
@@
ons 2019-08-14 klockan 22:18 +0200 skrev Thomas Mundt:
> Hi Tomas,
>
> Am Mi., 14. Aug. 2019 um 12:42 Uhr schrieb Tomas Härdin > :
> > tis 2019-08-13 klockan 22:03 +0200 skrev Thomas Mundt:
> > > Hi,
> > >
> > > attached patch fixes ticket #8077.
> > > Please comment.
> >
> > Probably OK,
The C and asm versions behaved differently _outside_ of the codec.
The C version returned pre-multiplied 'state' for the next execution
to use right away, while the assembly version outputted non-multiplied
'state' for the next execution to multiply to save instructions.
Since the initial state
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Zhong Li
> Sent: Tuesday, August 13, 2019 2:11 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Li, Zhong ; Rogozhkin, Dmitry V
>
> Subject: [FFmpeg-devel] [PATCH 3/6] lavc/qsvdec: Replace current parser
> with
Patch attached.
>From 399dd39c2e99ee3aa3d284019eb8c01abbdedcc0 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Thu, 15 Aug 2019 11:42:19 +0100
Subject: [PATCH 2/2] checkasm: add opusdsp tests
---
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c | 3 ++
tests/checkasm/checkasm.h | 1
On Thu, Aug 15, 2019 at 12:49 PM Jun Li wrote:
>
> On Thu, Jun 20, 2019 at 2:02 AM Jun Li wrote:
>
> >
> >
> > On Tue, May 21, 2019 at 1:05 AM Jun Li wrote:
> >
> >>
> >>
> >> On Thu, May 16, 2019 at 1:00 AM Jun Li wrote:
> >>
> >>>
> >>>
> >>> On Sun, May 12, 2019 at 7:44 PM Jun Li wrote:
>
On Thu, Aug 15, 2019 at 7:20 PM Reimar Döffinger
wrote:
> On 15.08.2019, at 13:15, Vittorio Giovara
> wrote:
> > I think being on the security list may have some professional
> implications
> > too: if you use ffmpeg in your $dayjob, being notified of security
> problem
> > in ffmpeg, and
Pushed.
Em qua, 14 de ago de 2019 às 03:37, Guo, Yejun escreveu:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Pedro Arthur
> > Sent: Wednesday, August 14, 2019 12:09 AM
> > To: FFmpeg development discussions and patches
>
On 8/15/2019 11:34 AM, Tomas Härdin wrote:
> Hi
>
> Attached patch detects when the cinepak encoder has generated a
> keyframe on its own, and pushes the generation of forced keyframes into
> the future. This is similar to what msvideo1enc.c does.
>
> Example:
>
> $ ./ffmpeg -i
On 8/15/2019 2:13 PM, Tomas Härdin wrote:
> tor 2019-08-15 klockan 12:54 -0300 skrev James Almer:
>> On 8/15/2019 11:34 AM, Tomas Härdin wrote:
>>> Hi
>>>
>>> Attached patch detects when the cinepak encoder has generated a
>>> keyframe on its own, and pushes the generation of forced keyframes into
On 15.08.2019, at 13:15, Vittorio Giovara wrote:
> I think being on the security list may have some professional implications
> too: if you use ffmpeg in your $dayjob, being notified of security problem
> in ffmpeg, and acting upon it before the fix lands in the tree, may be
> crucial. I think
On Thu, Aug 15, 2019 at 7:43 PM Juan De León <
juandl-at-google@ffmpeg.org> wrote:
> On Wed, Aug 14, 2019 at 12:11 PM Juan De León wrote:
>
> > AVEncodeInfoFrame data structure to store as AVFrameSideData of type
> > AV_FRAME_DATA_ENCODE_INFO.
> > The structure stores quantization index for
On Wed, Aug 14, 2019 at 5:35 PM James Zern
wrote:
>
> Hi,
>
> On Tue, Aug 13, 2019 at 8:23 PM elliottk
> wrote:
> >
> > Current default is 256kbps, which produces inconsistent
> > results (too high for low-res, too low for hi-res).
> > Use CRF instead, which will adapt.
> > ---
> >
Juan De León (12019-08-14):
> In that case, I believe documenting the size of the array and behaviour of
> undefined indexes should be enough. Have the pointers return NULL,
> and let the user handle the result, instead of stopping the execution.
I disagree. Either drop the check altogether or
On 8/12/2019 4:17 PM, Michael Niedermayer wrote:
> Fixes: Timeout (14sec -> 133ms)
> Fixes:
> 14843/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NUV_fuzzer-5661969614372864
> Fixes:
> 16257/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NUV_fuzzer-5769175464673280
> (35sec ->0.5sec)
>
tor 2019-08-15 klockan 12:54 -0300 skrev James Almer:
> On 8/15/2019 11:34 AM, Tomas Härdin wrote:
> > Hi
> >
> > Attached patch detects when the cinepak encoder has generated a
> > keyframe on its own, and pushes the generation of forced keyframes into
> > the future. This is similar to what
Lynne (12019-08-14):
> I can't find a single hint of aggression in my email. I'm being direct and
> factual.
> If you see this as aggression you shouldn't read any specifications or
> reports, you'll find yourself very offended.
Was this supposed to be not aggressive either?
> I couldn't help
As of LLVM r368102, Clang will set a pointer tag in bits 56-63 of the
address of a global when compiling with -fsanitize=hwaddress. This requires
an adjustment to assembly code that takes the address of such globals: the
code cannot use the regular R_AARCH64_ADR_PREL_PG_HI21 relocation to refer
to
Juan De León (12019-08-15):
> Ping. Does anyone have any more feedback?
> If not, can anyone review this for pushing.
Less than 24 hours feel a bit short to get impatient.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
On Wed, Aug 14, 2019 at 12:11 PM Juan De León wrote:
> AVEncodeInfoFrame data structure to store as AVFrameSideData of type
> AV_FRAME_DATA_ENCODE_INFO.
> The structure stores quantization index for each plane, DC/AC deltas
> for luma and chroma planes, and an array of AVEncodeInfoBlock type
>
Fixes: left shift of negative value -1
Fixes:
16424/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV3_fuzzer-5656579055026176
Fixes:
16358/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1IMAGE_fuzzer-5714436358144000
Found-by: continuous fuzzing process
Fixes: overflow in aspect ratio calculation
Fixes: signed integer overflow: 393215 * 14594 cannot be represented in type
'int'
Fixes:
15728/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV3IMAGE_fuzzer-5661588893204480
Found-by: continuous fuzzing process
Fixes: signed integer overflow: 1795032576 + 598344192 cannot be represented in
type 'int'
Fixes:
16196/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEMOTION2_fuzzer-5636723419119616
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Fixes: Timeout (11sec -> 6sec)
Fixes:
16344/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ANM_fuzzer-5673032000995328
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/anm.c | 3 +++
1 file
Fixes: out of array read
Fixes:
16331/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV3IMAGE_fuzzer-5672735195267072
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/vc1_block.c | 2 +-
1
Fixes: Timeout (137sec -> 6sec)
Fixes:
16090/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEMOTION2_fuzzer-5674245178261504
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
non res_sprite leads to decoder delay which leads to assertion failure
Fixes: Assertion failure
Fixes:
16402/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV3IMAGE_fuzzer-5704510034411520
Fixes: left shift of 1073741824 by 1 places cannot be represented in type 'int'
Fixes:
On Thu, Aug 15, 2019 at 04:43:19PM +0200, Tomas Härdin wrote:
> ons 2019-08-14 klockan 12:32 +0200 skrev Tomas Härdin:
> > mån 2019-08-12 klockan 21:17 +0200 skrev Michael Niedermayer:
> > > Fixes: Timeout (12sec -> 32ms)
> > > Fixes: 16078/clusterfuzz-testcase-minimized-
> > >
Hi,
Sorry Moritz, I somehow missed your feedback. Here's an updated patch with
the fixed formatting. I also set up a server that you can test with. Try:
ffmpeg -i test.mp4 -hls_flags +append_list -hls_time 6 -method PUT
-http_persistent 1 http://45.33.124.115/stream.m3u8
The server has
Juan De León (12019-08-15):
> AVEncodeInfoFrame data structure to store as AVFrameSideData of type
> AV_FRAME_DATA_ENCODE_INFO.
> The structure stores quantization index for each plane, DC/AC deltas
> for luma and chroma planes, and an array of AVEncodeInfoBlock type
> denoting position, size, and
AVEncodeInfoFrame data structure to store as AVFrameSideData of type
AV_FRAME_DATA_ENCODE_INFO.
The structure stores quantization index for each plane, DC/AC deltas
for luma and chroma planes, and an array of AVEncodeInfoBlock type
denoting position, size, and delta quantizer for each block in the
tor 2019-08-15 klockan 14:20 -0300 skrev James Almer:
> On 8/15/2019 2:13 PM, Tomas Härdin wrote:
> > tor 2019-08-15 klockan 12:54 -0300 skrev James Almer:
> > > On 8/15/2019 11:34 AM, Tomas Härdin wrote:
> > > >
> > > > Aside: what is -keyint_min for exactly? It seems to be used as a max in
> >
On 8/15/2019 3:47 PM, Nicolas George wrote:
> Alex Sukhanov (12019-08-15):
>> Time is important here. Juan's internship is ending soon. Juan has been
>> working with Lynne on this design. Since there is back and forth emails in
>> this thread, it would be very helpful for Juan if Nicolas and Lynne
Alex Sukhanov (12019-08-15):
> Time is important here. Juan's internship is ending soon. Juan has been
> working with Lynne on this design. Since there is back and forth emails in
> this thread, it would be very helpful for Juan if Nicolas and Lynne get to
> some agreement, rather than have intern
Aug 15, 2019, 19:47 by geo...@nsup.org:
> Alex Sukhanov (12019-08-15):
>
>> Time is important here. Juan's internship is ending soon. Juan has been
>> working with Lynne on this design. Since there is back and forth emails in
>> this thread, it would be very helpful for Juan if Nicolas and Lynne
Current default is 256kbps, which produces inconsistent
results (too high for low-res, too low for hi-res).
Use CRF instead, which will adapt.
---
libavcodec/libaomenc.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
On Thu, Aug 15, 2019 at 11:07 AM Nicolas George wrote:
> Juan De León (12019-08-15):
> > Ping. Does anyone have any more feedback?
> > If not, can anyone review this for pushing.
>
> Less than 24 hours feel a bit short to get impatient.
>
> Regards,
>
> --
> Nicolas George
>
Aug 15, 2019, 19:15 by geo...@nsup.org:
> Lynne (12019-08-14):
>
>> I can't find a single hint of aggression in my email. I'm being direct and
>> factual.
>> If you see this as aggression you shouldn't read any specifications or
>> reports, you'll find yourself very offended.
>>
>
> Was this
On 15.08.2019, at 19:38, Paul B Mahol wrote:
> On Thu, Aug 15, 2019 at 7:20 PM Reimar Döffinger
> wrote:
>
>> On 15.08.2019, at 13:15, Vittorio Giovara
>> wrote:
>>> I think being on the security list may have some professional
>> implications
>>> too: if you use ffmpeg in your $dayjob,
On 15.08.2019, at 13:15, Vittorio Giovara wrote:
> if you use ffmpeg in your $dayjob, being notified of security problem
> in ffmpeg, and acting upon it before the fix lands in the tree, may be
> crucial.
I realize I only responded to this specific part only in the context of this
discussion.
> -Original Message-
> From: Guo, Yejun
> Sent: Wednesday, August 14, 2019 3:06 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Guo, Yejun
> Subject: [PATCH 2/2] libavfilter/dnn/dnn_backend_tf: add tf.pad support for
> tensorflow backend with native model.
>
> Signed-off-by: Guo, Yejun
> ---
>
if it is initialized randomly, the tensorflow lib will report
error message such as:
Attempt to add output -7920 of depth_to_space4 not in range [0, 1) to node with
type Identity
Signed-off-by: Guo, Yejun
---
libavfilter/dnn/dnn_backend_tf.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Signed-off-by: Guo, Yejun
---
libavfilter/dnn/dnn_backend_tf.c | 48
1 file changed, 19 insertions(+), 29 deletions(-)
diff --git a/libavfilter/dnn/dnn_backend_tf.c b/libavfilter/dnn/dnn_backend_tf.c
index ca7434a..626fba9 100644
---
From section 7.4.3.3 ("Decoded reference picture marking semantics")
of the H.264 specifications:
"The content of the decoded reference picture marking syntax structure
shall be the same in all slice headers of the primary coded picture.
When one or more redundant coded pictures are present, the
Up until now, the H.264 parser has allocated a new buffer for every
frame in order to store the unescaped RBSP in case the part of the RBSP
that will be unescaped contains 0x03 escape bytes. This is expensive
and this commit changes this: The buffer is now kept and reused.
For an AVC file with an
The effective lifetime of the packet does not extend beyond the
extract_extradata in libavformat/utils.c, so the packet can simply be
put on the stack there. This allows to remove the allocation and the
corresponding frees.
Signed-off-by: Andreas Rheinhardt
---
libavformat/internal.h | 1 -
When parsing the sizes of the frames in a lace fails, sometimes no
error message was raised (e.g. when using xiph or fixed-size lacing).
Only EBML lacing generated error messages (which were wrongly declared
as AV_LOG_INFO), but even here not all errors resulted in an error
message. So add a
On Fri, 16 Aug 2019 at 04:20, Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Up until now, the H.264 parser has allocated a new buffer for every
> frame in order to store the unescaped RBSP in case the part of the RBSP
> that will be unescaped contains 0x03 escape bytes. This is
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h264_parser.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index 188ba41c0b..669a9a5ff7 100644
--- a/libavcodec/h264_parser.c
+++
Up until now, when an error happened in one of the inner loops in
matroska_parse_laces, a variable designated for the return value has
been set to an error value and break has been used to exit the
current loop/case. This was done so that the end of matroska_parse_laces
is reached, because said
We only need the function to search for start codes from it.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h264_parser.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index 604cddada5..68eb5939db 100644
---
870e7552 introduced validating the lace sizes when they are parsed and
removed the old check; yet when merging this libav commit in 6902c3ac,
the old check for whether the frame extends beyond the frame has been kept.
It is unnecessary and has been removed.
Signed-off-by: Andreas Rheinhardt
---
On 8/15/2019 3:55 PM, Tomas Härdin wrote:
> tor 2019-08-15 klockan 14:20 -0300 skrev James Almer:
>> On 8/15/2019 2:13 PM, Tomas Härdin wrote:
>>> tor 2019-08-15 klockan 12:54 -0300 skrev James Almer:
On 8/15/2019 11:34 AM, Tomas Härdin wrote:
> Aside: what is -keyint_min for exactly? It
When a slice is encountered, the H.264 parser up until now always
unreferenced and reset the currently active SPS and PPS; immediately
afterwards, the currently active parameter sets are set which includes
referencing them. Given that it is not uncommon for the active parameter
sets to change only
The H.264 parser currently allocates a buffer of the size of the input
frame for every input frame to store the unescaped RBSP of a NAL unit
(it is actually only used if a 0x03 escape is encountered at all).
For performance reasons only a small part of slices is actually
unescaped; and given that
In case the parser flag PARSER_FLAG_COMPLETE_FRAMES is set, it is common
that every input packet generates exactly one output packet whose
underlying data coincides with the data of the input packet. If in this
situation the input packet buffer is reference counted (as it usually is),
the current
Kieran Kunhya:
> On Fri, 16 Aug 2019 at 04:20, Andreas Rheinhardt <
> andreas.rheinha...@gmail.com> wrote:
>
>> Up until now, the H.264 parser has allocated a new buffer for every
>> frame in order to store the unescaped RBSP in case the part of the RBSP
>> that will be unescaped contains 0x03
64 matches
Mail list logo
