> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Linjie Fu
> Sent: Monday, April 15, 2019 9:24 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie
> Subject: [FFmpeg-devel] [PATCH, v3] lavu/hwcontext_qsv: Fix the realign
> check for hwupload
>
> Fix the aligned check in
On 29-04-2019 05:37 AM, Marton Balint wrote:
On Sun, 28 Apr 2019, Marton Balint wrote:
Hi All,
There has been discussion on the mailing list several times about the
inclusion of support for closed source components (codecs, formats,
filters, etc) in the main ffmpeg codebase.
Also the
> -原始邮件-
> 发件人: "Pedro Arthur"
> 发送时间: 2019-04-29 10:42:42 (星期一)
> 收件人: "FFmpeg development discussions and patches"
> 抄送:
> 主题: Re: [FFmpeg-devel] [PATCH] libavfilter: Add more operation supports in
> FFmpeg dnn native mode.
>
> Em dom, 28 de abr de 2019 às 23:07, Guo, Yejun
Em dom, 28 de abr de 2019 às 23:07, Guo, Yejun escreveu:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > xwm...@pku.edu.cn
> > Sent: Sunday, April 28, 2019 5:27 PM
> > To: ffmpeg development discussions and patches
> >
> -原始邮件-
> 发件人: "Guo, Yejun"
> 发送时间: 2019-04-29 10:03:43 (星期一)
> 收件人: "FFmpeg development discussions and patches"
> 抄送:
> 主题: Re: [FFmpeg-devel] [PATCH] libavfilter: Add more operation supports in
> FFmpeg dnn native mode.
>
>
>
> > -Original Message-
> > From:
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> xwm...@pku.edu.cn
> Sent: Sunday, April 28, 2019 5:27 PM
> To: ffmpeg development discussions and patches
> Subject: [FFmpeg-devel] [PATCH] libavfilter: Add more operation supports in
>
> -Original Message-
> From: Song, Ruiling
> Sent: Tuesday, April 23, 2019 4:52 PM
> To: 'FFmpeg development discussions and patches' de...@ffmpeg.org>
> Subject: RE: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add
> nlmeans_opencl filter
>
>
>
> > -Original Message-
> >
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Alexander Strasser
> Sent: Sunday, April 28, 2019 11:29 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH V5 1/2] configure: sort
>
Hi,
On Sun, Apr 28, 2019 at 8:14 PM Marton Balint wrote:
> On Sun, 28 Apr 2019, Jean-Baptiste Kempf wrote:
> > On Mon, 29 Apr 2019, at 00:23, Marton Balint wrote:
> >> >> On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote:
> >> >>> 2) Should patches using closed source libraries which are not
>
On Sun, 28 Apr 2019, Jean-Baptiste Kempf wrote:
On Mon, 29 Apr 2019, at 00:23, Marton Balint wrote:
>> On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote:
>>> 2) Should patches using closed source libraries which are not considered
>>> "System Libraries" according to the GPL be rejected?
On Sun, 28 Apr 2019, Marton Balint wrote:
Hi All,
There has been discussion on the mailing list several times about the
inclusion of support for closed source components (codecs, formats,
filters, etc) in the main ffmpeg codebase.
Also the removal of libNDI happened without general
On 4/28/2019 8:00 PM, Mark Thompson wrote:
> On 17/04/2019 03:56, James Almer wrote:
>> This follows the spec definition, and removes a field from the relevant
>> structs.
>>
>> Signed-off-by: James Almer
>> ---
>> libavcodec/cbs_h264.h | 1 -
>>
On 4/28/2019 8:19 PM, Mark Thompson wrote:
> On 17/04/2019 03:56, James Almer wrote:
>> These are more in line with the new ones introduced in the previous commit.
>>
>> Signed-off-by: James Almer
>> ---
>> No more i() macro :p
>>
>> Figured I'd leave all the byte and checksum fields using the
On 4/28/2019 7:59 PM, Mark Thompson wrote:
> On 17/04/2019 03:56, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> Better macro names welcome. I used the same convention as in cbs_av1.
>>
>> fate-cbs passes, but i'm sure a bunch of these are not tested by it,
>> so help double checking
On 17/04/2019 03:56, James Almer wrote:
> These are more in line with the new ones introduced in the previous commit.
>
> Signed-off-by: James Almer
> ---
> No more i() macro :p
>
> Figured I'd leave all the byte and checksum fields using the custom range
> macro, to have the explicit hex
On Mon, 29 Apr 2019, Carl Eugen Hoyos wrote:
2019-04-28 22:02 GMT+02:00, Marton Balint :
1) Should libNDI support be removed from the ffmpeg codebase?
This sounds to me as if you know of an alternative to not endorsing
a company that profits from FFmpeg while at the same time
violating
On 17/04/2019 03:56, James Almer wrote:
> This follows the spec definition, and removes a field from the relevant
> structs.
>
> Signed-off-by: James Almer
> ---
> libavcodec/cbs_h264.h | 1 -
> libavcodec/cbs_h264_syntax_template.c | 2 +-
> libavcodec/cbs_h265.h
On 17/04/2019 03:56, James Almer wrote:
> Signed-off-by: James Almer
> ---
> Better macro names welcome. I used the same convention as in cbs_av1.
>
> fate-cbs passes, but i'm sure a bunch of these are not tested by it,
> so help double checking i didn't screw up is welcome.
>
>
On 4/28/2019 7:28 PM, Mark Thompson wrote:
> On 17/04/2019 16:48, James Almer wrote:
>> Also infer the value time_offset_length as 0 when it's not present.
>>
>> Signed-off-by: James Almer
>> ---
>> Fun thing, this metadata OBU is clearly based on the H264/5 timecode SEI, yet
>>
2019-04-29 0:32 GMT+02:00, fumoboy007 :
Could you add a sentence to the commit message that
explains what this commit fixes?
Maybe "h263 decoding with videotoolbox"?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
2019-04-28 22:02 GMT+02:00, Marton Balint :
> 1) Should libNDI support be removed from the ffmpeg codebase?
This sounds to me as if you know of an alternative to not endorsing
a company that profits from FFmpeg while at the same time
violating the copyright of the FFmpeg developers?
What could
---
libavcodec/h263dec.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index 8385ddfe2e..6f001f6d47 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -743,6 +743,19 @@ const enum
On Mon, 29 Apr 2019, at 00:23, Marton Balint wrote:
> >> On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote:
> >>> 2) Should patches using closed source libraries which are not considered
> >>> "System Libraries" according to the GPL be rejected?
> >>
> >> You mean "major components"?
> >> (at no
2019-04-28 14:35 GMT+02:00, Zhong Li :
> Currenntly there is no any function of CO3 appled to mpeg2,
> and enabling for mpeg2 it will cause regression with some old
> libmfx libaries (see tiket #7839), so disable CO3 for mpeg2.
>
> Also add runtime version check for CO3.
>
> Signed-off-by: Zhong
On 17/04/2019 16:48, James Almer wrote:
> Also infer the value time_offset_length as 0 when it's not present.
>
> Signed-off-by: James Almer
> ---
> Fun thing, this metadata OBU is clearly based on the H264/5 timecode SEI, yet
> time_offset_length is unsigned here :p
>
>
On Sun, 28 Apr 2019, Marton Balint wrote:
On Sun, 28 Apr 2019, Jean-Baptiste Kempf wrote:
On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote:
2) Should patches using closed source libraries which are not considered
"System Libraries" according to the GPL be rejected?
You mean "major
Mark Thompson:
> On 23/04/2019 23:55, Andreas Rheinhardt wrote:
>> horizontal/vertical_size_value (containing the twelve least significant
>> bits of the frame size) mustn't be zero according to the specifications;
>> and the value 0 is forbidden for the colour_description elements.
>>
>>
On Sun, 28 Apr 2019, Mark Thompson wrote:
On 28/04/2019 21:02, Marton Balint wrote:
... closed source libraries which are not considered "System Libraries"
according to the GPL ...
Please can you define this in a precise way which does not rely upon
interpreting the GPL? There are
On 23/04/2019 23:55, Andreas Rheinhardt wrote:
> horizontal/vertical_size_value (containing the twelve least significant
> bits of the frame size) mustn't be zero according to the specifications;
> and the value 0 is forbidden for the colour_description elements.
>
> Signed-off-by: Andreas
2019-04-28 23:34 GMT+02:00, Marton Balint :
>
> On Sun, 28 Apr 2019, Carl Eugen Hoyos wrote:
>
>> 2019-04-28 22:02 GMT+02:00, Marton Balint :
>>> 2) Should patches using closed source libraries which are not
>>> considered "System Libraries" according to the GPL be rejected?
>>
>> Do I understand
On Sun, 28 Apr 2019, Jean-Baptiste Kempf wrote:
On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote:
2) Should patches using closed source libraries which are not considered
"System Libraries" according to the GPL be rejected?
You mean "major components"?
(at no point does the GPLv2
On Sun, 28 Apr 2019, Carl Eugen Hoyos wrote:
2019-04-28 22:02 GMT+02:00, Marton Balint :
2) Should patches using closed source libraries which are not
considered "System Libraries" according to the GPL be rejected?
Do I understand correctly that this question is equivalent to
requesting
2019-04-28 23:29 GMT+02:00, Jean-Baptiste Kempf :
> On Sun, 28 Apr 2019, at 22:44, Carl Eugen Hoyos wrote:
>> 2019-04-28 22:02 GMT+02:00, Marton Balint :
>> > 2) Should patches using closed source libraries which are not
>> > considered "System Libraries" according to the GPL be rejected?
>>
>> Do
On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote:
> 2) Should patches using closed source libraries which are not considered
> "System Libraries" according to the GPL be rejected?
You mean "major components"?
(at no point does the GPLv2 mention "System Libraries".
--
Jean-Baptiste Kempf -
On 28/04/2019 21:02, Marton Balint wrote:
> ... closed source libraries which are not considered "System Libraries"
> according to the GPL ...
Please can you define this in a precise way which does not rely upon
interpreting the GPL? There are certainly differing opinions about exactly
what
On Sun, 28 Apr 2019, at 22:44, Carl Eugen Hoyos wrote:
> 2019-04-28 22:02 GMT+02:00, Marton Balint :
> > 2) Should patches using closed source libraries which are not
> > considered "System Libraries" according to the GPL be rejected?
>
> Do I understand correctly that this question is equivalent
>
> [1] http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242574.html
There are numerous inactive people in the voting committee, some for years.
Why are they arbitrarily allowed to vote on this?
Kieran
___
ffmpeg-devel mailing list
On Sun, 28 Apr 2019, James Almer wrote:
On 4/28/2019 5:02 PM, Marton Balint wrote:
Hi All,
There has been discussion on the mailing list several times about the
inclusion of support for closed source components (codecs, formats,
filters, etc) in the main ffmpeg codebase.
Also the removal
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 26
libavfilter/avf_showspectrum.c | 239 -
2 files changed, 200 insertions(+), 65 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 14c33ecf90..7cc3937b40 100644
---
2019-04-28 22:02 GMT+02:00, Marton Balint :
> 2) Should patches using closed source libraries which are not
> considered "System Libraries" according to the GPL be rejected?
Do I understand correctly that this question is equivalent to
requesting the removal of the decklink wrapper?
Carl Eugen
On Sun, 14 Apr 2019, Tomas Härdin wrote:
fre 2019-04-12 klockan 01:09 +0200 skrev Marton Balint:
> Signed-off-by: Marton Balint
---
libavformat/mxfdec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index
On Sun, 14 Apr 2019, Tomas Härdin wrote:
fre 2019-04-12 klockan 01:09 +0200 skrev Marton Balint:
KLV length is BER encoded (variable size), but the code assumed the encoding to
always use 4 bytes.
Fixes parsing Random Index Pack in
samples/MXF/issue2160/PW0805A0V01.4C5B5636.EFA330.mxf.
>
On Sun, 14 Apr 2019, Tomas Härdin wrote:
fre 2019-04-12 klockan 01:09 +0200 skrev Marton Balint:
We find the last essence container much faster if we go through the partitions
backwards...
Good catch
> Signed-off-by: Marton Balint
---
libavformat/mxfdec.c | 9 +++--
1 file
On 4/28/2019 5:02 PM, Marton Balint wrote:
> Hi All,
>
> There has been discussion on the mailing list several times about the
> inclusion of support for closed source components (codecs, formats,
> filters, etc) in the main ffmpeg codebase.
>
> Also the removal of libNDI happened without
On Fri, 26 Apr 2019, Tomas Härdin wrote:
ons 2019-04-24 klockan 22:31 +0200 skrev Marton Balint:
On Wed, 24 Apr 2019, Tomas Härdin wrote:
> mån 2019-04-22 klockan 19:15 +0200 skrev Marton Balint:
> > This affects the following samples:
> >
> >
Hi All,
There has been discussion on the mailing list several times about the
inclusion of support for closed source components (codecs, formats,
filters, etc) in the main ffmpeg codebase.
Also the removal of libNDI happened without general consensus, so a vote
is necessary to justify the
2019-04-26 17:31 GMT+02:00, James Almer :
> Fixes ticket #7866.
>
> Signed-off-by: James Almer
> ---
> libavcodec/scpr3.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/scpr3.c b/libavcodec/scpr3.c
> index f92ccfa902..5cfad9f4d2 100644
> --- a/libavcodec/scpr3.c
> +++
On 2019-04-28 07:42 +, Guo, Yejun wrote:
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Alexander Strasser
> > Sent: Sunday, April 28, 2019 9:18 AM
> > To: FFmpeg development discussions and patches
> > Subject: Re:
sön 2019-04-28 klockan 11:42 +0200 skrev Michael Niedermayer:
> Fixes: Timeout (16sec -> 125msec)
> Fixes:
> 14283/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5742851457024000
>
> Found-by: continuous fuzzing process
>
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 25
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_gblur.c | 257 ++-
4 files changed, 280 insertions(+), 4 deletions(-)
diff --git a/doc/filters.texi
On 2019-04-28 03:11 +, avih wrote:
> > What do you think about using awk instead of shell?
>
> No objection here, especially if it's more robust in some ways than this
> or other shell code (though personally I'm not fluent in awk).
>
> My only concern was preventing a considerable performance
On 28-04-2019 04:15 PM, Nicolas George wrote:
Gyan (12019-04-28):
Corrupt streams in sufficiently intact containers (MP4, TS) so they can be
demuxed but decoder context fields are incomplete/invalid, so ffmpeg won't
streamcopy-mux them.
Depending on the exact situation, I would use a repair
Currenntly there is no any function of CO3 appled to mpeg2,
and enabling for mpeg2 it will cause regression with some old
libmfx libaries (see tiket #7839), so disable CO3 for mpeg2.
Also add runtime version check for CO3.
Signed-off-by: Zhong Li
---
libavcodec/qsvenc.c | 13 -
1
> -原始邮件-
> 发件人: "myp...@gmail.com"
> 发送时间: 2019-04-28 18:28:21 (星期日)
> 收件人: "FFmpeg development discussions and patches"
> 抄送:
> 主题: Re: [FFmpeg-devel] [PATCH] libavfilter: Add more operation supports in
> FFmpeg dnn native mode.
>
> On Sun, Apr 28, 2019 at 5:27 PM wrote:
> >
> >
On Sun, Apr 28, 2019 at 5:30 PM Gyan wrote:
>
>
>
> On 28-04-2019 07:19 AM, myp...@gmail.com wrote:
> > On Sat, Apr 27, 2019 at 8:22 PM Gyan wrote:
> >>
> >>
> >> On 27-04-2019 05:25 PM, Carl Eugen Hoyos wrote:
> >>> 2019-04-27 13:17 GMT+02:00, Jun Zhao :
> perfer avctx->framerate first
On 4/28/19, Gyan wrote:
>
>
> On 28-04-2019 03:52 PM, Nicolas George wrote:
>> Gyan (12019-04-26):
>>> From 5ec154870d9c559037598b41736bf5b216a756e0 Mon Sep 17 00:00:00 2001
>>> From: Gyan Doshi
>>> Date: Fri, 26 Apr 2019 18:31:33 +0530
>>> Subject: [PATCH] avformat/mux: skip parameter and pts
Gyan (12019-04-28):
> Corrupt streams in sufficiently intact containers (MP4, TS) so they can be
> demuxed but decoder context fields are incomplete/invalid, so ffmpeg won't
> streamcopy-mux them.
>
> Depending on the exact situation, I would use a repair or analysis tool to
> check them or
On 28-04-2019 03:52 PM, Nicolas George wrote:
Gyan (12019-04-26):
From 5ec154870d9c559037598b41736bf5b216a756e0 Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Fri, 26 Apr 2019 18:31:33 +0530
Subject: [PATCH] avformat/mux: skip parameter and pts checks for data muxer
Allows to dump a
On 4/28/19, Michael Niedermayer wrote:
> Fixes: Timeout (23sec -> 0.5sec)
> Fixes:
> 14329/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LSCR_fuzzer-5679252923482112
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by:
On 28-04-2019 03:40 PM, Hendrik Leppkes wrote:
On Sun, Apr 28, 2019 at 11:57 AM Michael Niedermayer
wrote:
On Sat, Apr 27, 2019 at 10:01:53AM +0530, Gyan wrote:
On 27-04-2019 01:32 AM, Michael Niedermayer wrote:
On Fri, Apr 26, 2019 at 06:38:37PM +0530, Gyan wrote:
mux.c |9
On Sun, Apr 28, 2019 at 5:27 PM wrote:
>
> This patch is for the support of derain filter project in GSoC. It adds
> supports for the following operations:
>
>
>
>
> (1) Conv padding method: "SAME" and "VALID"
>
> (2) Dilation
>
> (3) Activation: "NONE" and "LEAKY_RELU"
>
>
>
>
> These
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Tuesday, April 2, 2019 7:40 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2 4/9] vp9_parser: Return stream
> properties
>
> Rewrites the parser entirely, using CBS for header
Gyan (12019-04-26):
> From 5ec154870d9c559037598b41736bf5b216a756e0 Mon Sep 17 00:00:00 2001
> From: Gyan Doshi
> Date: Fri, 26 Apr 2019 18:31:33 +0530
> Subject: [PATCH] avformat/mux: skip parameter and pts checks for data muxer
>
> Allows to dump a malformed stream for external inspection or
On 28-04-2019 03:26 PM, Michael Niedermayer wrote:
On Sat, Apr 27, 2019 at 10:01:53AM +0530, Gyan wrote:
On 27-04-2019 01:32 AM, Michael Niedermayer wrote:
On Fri, Apr 26, 2019 at 06:38:37PM +0530, Gyan wrote:
mux.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
On Sun, Apr 28, 2019 at 11:57 AM Michael Niedermayer
wrote:
>
> On Sat, Apr 27, 2019 at 10:01:53AM +0530, Gyan wrote:
> >
> >
> > On 27-04-2019 01:32 AM, Michael Niedermayer wrote:
> > >On Fri, Apr 26, 2019 at 06:38:37PM +0530, Gyan wrote:
> > >> mux.c |9 -
> > >> 1 file changed, 8
On 4/28/19, Nicolas George wrote:
> Paul B Mahol (12019-04-27):
>> Considering that some filtergraphs needs 64GB of RAM I consider that
>> non-issue.
>
> Why was this pushed without leaving Clément time to reply?
He replied on IRC.
___
ffmpeg-devel
On Sat, Apr 27, 2019 at 10:01:53AM +0530, Gyan wrote:
>
>
> On 27-04-2019 01:32 AM, Michael Niedermayer wrote:
> >On Fri, Apr 26, 2019 at 06:38:37PM +0530, Gyan wrote:
> >> mux.c |9 -
> >> 1 file changed, 8 insertions(+), 1 deletion(-)
> >>d94a699f5dbc31a8ee8b7d1bdb33004d9cd95d46
Add function pointer field in vaapi_profile_map[], set profile_parser
for HEVC_REXT to find the exact va_profile.
Signed-off-by: Linjie Fu
---
SPS range extension fields should be passed to decoder, will use
VAPictureParameterBufferHEVCExtension consist of base and rext.
Add vaapi_parse_rext_profile and use profile constraint flags to
determine the exact va_profile for HEVC_REXT.
Add build object in Makefile for h265_profile_level dependency.
Signed-off-by: Linjie Fu
---
libavcodec/Makefile | 2 +-
libavcodec/vaapi_hevc.c | 69
Add support for max frame size:
- max_frame_size (bytes) to indicate the allowed max frame size, set
with default 4 passes and delata_qp = 1 per pass;
Customized pass_num and delta_qp per pass is also available:
- pass_num to indicate number of passes.
- delta_qp to indicate qp
Parse all the constraint flags according to ITU-T Rec. H.265 (02/2018).
It can be passed to hw decoders to determine the exact profile for Range
Extension HEVC.
Signed-off-by: Linjie Fu
---
This is the same patch with previous one, send again to be wrapped in
the patch set.
add docs.
Signed-off-by: Linjie Fu
---
doc/encoders.texi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index ef12c73ed5..e9887e13a6 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2940,6 +2940,17 @@ Use CAVLC.
@item aud
Fixes: Timeout (16sec -> 125msec)
Fixes:
14283/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5742851457024000
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cinepak.c | 7
Fixes: Timeout (23sec -> 0.5sec)
Fixes:
14329/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LSCR_fuzzer-5679252923482112
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/pngdec.c | 2 ++
1
Paul B Mahol (12019-04-27):
> Considering that some filtergraphs needs 64GB of RAM I consider that
> non-issue.
Why was this pushed without leaving Clément time to reply?
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel
On 28-04-2019 07:19 AM, myp...@gmail.com wrote:
On Sat, Apr 27, 2019 at 8:22 PM Gyan wrote:
On 27-04-2019 05:25 PM, Carl Eugen Hoyos wrote:
2019-04-27 13:17 GMT+02:00, Jun Zhao :
perfer avctx->framerate first than use avctx->time_base when
setting the frame rate to encoder. 1/time_base
This patch is for the support of derain filter project in GSoC. It adds
supports for the following operations:
(1) Conv padding method: "SAME" and "VALID"
(2) Dilation
(3) Activation: "NONE" and "LEAKY_RELU"
These operations are all needed in derain filter. And if modify the dnn
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Alexander Strasser
> Sent: Sunday, April 28, 2019 9:18 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH V5 1/2] configure: sort
>
78 matches
Mail list logo
