On 7/21/19 11:23 PM, Paul B Mahol wrote:
> On 7/22/19, David Bryant wrote:
>> Hi,
>>
>> As I promised late last year, here is a patch to add a WavPack DSD decoder.
>>
>> Thanks!
>>
>> -David Bryant
>>
>>
> Please correct me if I'm wrong, but why this uses new codec id?
> Apparently is also copies
On 23-07-2019 02:43 AM, Marton Balint wrote:
On Sun, 21 Jul 2019, lance.lmw...@gmail.com wrote:
From: Limin Wang
This patch haven't make other pixel format usable yet to make sure
the test
result is same with rgb32 format.
Reviewed-by: Marton Balint
You should only add this if you
Jul 23, 2019, 12:23 AM by juandl-at-google@ffmpeg.org:
>> On Mon, Jul 22, 2019 at 12:17 PM Lynne wrote:
>> You can't hack a decoder in any nice and performant way for it to output
>>
> data to an analyzer.
> Hi, Lynne
> I hear your concern about the decoder performance.
> I believe that the
Jul 22, 2019, 11:24 PM by ceffm...@gmail.com:
> Am Di., 23. Juli 2019 um 00:14 Uhr schrieb Lynne :
>
>> If the size somehow gets lost between lavf and lavc then the problem is
>> there, and should be solved by not fudging the decoder.
>>
>
> (Using libavformat is no condition for using
Jul 23, 2019, 12:00 AM by mich...@niedermayer.cc:
> On Tue, Jul 23, 2019 at 12:13:51AM +0200, Lynne wrote:
>
>> Jul 22, 2019, 10:57 PM by mich...@niedermayer.cc:
>>
>> > The dimensions are always 320x200 they are hardcoded in the demuxer.
>> > Hardcode them instead in the decoder.
>> >
>> >
On Mon, Jul 22, 2019 at 11:13:46PM +0200, Marton Balint wrote:
>
> On Sun, 21 Jul 2019, lance.lmw...@gmail.com wrote:
>
> >From: Limin Wang
> >
> >This patch haven't make other pixel format usable yet to make sure the test
> >result is same with rgb32 format.
> >
> >Reviewed-by: Marton Balint
> On Mon, Jul 22, 2019 at 12:17 PM Lynne wrote:
> You can't hack a decoder in any nice and performant way for it to output
data to an analyzer.
Hi, Lynne
I hear your concern about the decoder performance.
I believe that the way we would like to modify the decoder should not
affect its
On Mon, Jul 22, 2019 at 08:20:54AM +0200, Paul B Mahol wrote:
> On 7/21/19, Michael Niedermayer wrote:
> > On Sun, Jul 21, 2019 at 10:48:26AM +0200, Paul B Mahol wrote:
> >> On 7/21/19, Michael Niedermayer wrote:
> >> > Fixes: Timeout (22 -> 7 sec)
> >> > Fixes:
> >> >
On Mon, Jul 22, 2019 at 09:58:58AM +0200, Olivier MAIGNIAL wrote:
> You are right, some values are expected to be <= 32.
> However, it doesn't add a bug: Without my patch fail will occur at parsing
> time; With my patch it will occur a bit later on check performed by
> get_bits_long().
On Mon, Jul 22, 2019 at 09:02:15AM +0200, Matthieu Bouron wrote:
> On Fri, Jul 19, 2019 at 09:40:52AM +0200, Matthieu Bouron wrote:
> > On Sun, Jul 14, 2019 at 08:17:03PM +0200, Matthieu Bouron wrote:
> > > On Thu, Jul 04, 2019 at 03:43:48PM +0200, Matthieu Bouron wrote:
> > > > ---
> > > >
On Tue, Jul 23, 2019 at 12:13:51AM +0200, Lynne wrote:
> Jul 22, 2019, 10:57 PM by mich...@niedermayer.cc:
>
> > The dimensions are always 320x200 they are hardcoded in the demuxer.
> > Hardcode them instead in the decoder.
> >
> > Fixes: Timeout (16sec -> 400ms)
> > Fixes:
> >
Am Di., 23. Juli 2019 um 00:14 Uhr schrieb Lynne :
> If the size somehow gets lost between lavf and lavc then the problem is
> there, and should be solved by not fudging the decoder.
(Using libavformat is no condition for using libavcodec)
> Moreover, if neither the codec, nor container can
Jul 22, 2019, 10:57 PM by mich...@niedermayer.cc:
> The dimensions are always 320x200 they are hardcoded in the demuxer.
> Hardcode them instead in the decoder.
>
> Fixes: Timeout (16sec -> 400ms)
> Fixes:
> 15574/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RL2_fuzzer-5158614072819712
>
>
The dimensions are always 320x200 they are hardcoded in the demuxer.
Hardcode them instead in the decoder.
Fixes: Timeout (16sec -> 400ms)
Fixes:
15574/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RL2_fuzzer-5158614072819712
Found-by: continuous fuzzing process
On Sun, 21 Jul 2019, lance.lmw...@gmail.com wrote:
From: Limin Wang
This patch haven't make other pixel format usable yet to make sure the test
result is same with rgb32 format.
Reviewed-by: Marton Balint
You should only add this if you got an explicit LGTM for a patch.
Signed-off-by:
Hi Tomas,
> On Jul 22, 2019, at 2:45 AM, Tomas Härdin wrote:
>
> fre 2019-07-19 klockan 09:51 -0700 skrev Baptiste Coudurier:
>> Hi Tomas
>>
>>> On Jul 19, 2019, at 8:48 AM, Tomas Härdin
>>> wrote:
>>>
>>> tor 2019-07-18 klockan 11:39 -0700 skrev Baptiste Coudurier:
---
On Sat, 13 Jul 2019, hwren wrote:
At 2019-07-13 01:38:55, "Marton Balint" wrote:
On Fri, 12 Jul 2019, hwrenx wrote:
Can effectivly improved decoding speed when memcpy becomes a limitation
for proccessing high resolution source.
Tested under i7-8700k with `ffmpeg -i 7680x4320.avs2
Hi,
Patch attached.
0001-avfilter-vf_ciescope-add-DCI-P3.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
Jul 22, 2019, 8:03 PM by juandl-at-google@ffmpeg.org:
> On Fri, Jul 19, 2019 at 12:47 PM Moritz Barsnick wrote:
>
>> On Fri, Jul 19, 2019 at 10:00:52 +0200, Nicolas George wrote:
>> > I do not judge whether this filter would be useful and should be
>> > included, but if so, then I would
On Fri, Jul 19, 2019 at 12:47 PM Moritz Barsnick wrote:
> On Fri, Jul 19, 2019 at 10:00:52 +0200, Nicolas George wrote:
> > I do not judge whether this filter would be useful and should be
> > included, but if so, then I would appreciate that the output be done
> > using AVIO, so that it can go
From: Carl Eugen Hoyos
Subject: Re: [FFmpeg-devel] Patch for IPC SHM
Date: Mon, 22 Jul 2019 19:23:35 +0200
>
>
>
>> Am 22.07.2019 um 18:10 schrieb :
>>
>> All,
>>
>> I have encountered an error in libavdevice/xcbgrab.c that prevents NetBSD
>> from
>> using X11grab. When xcbgrab_frame_shm
> Am 22.07.2019 um 18:10 schrieb :
>
> All,
>
> I have encountered an error in libavdevice/xcbgrab.c that prevents NetBSD from
> using X11grab. When xcbgrab_frame_shm calls allocate_shm, it creates a
> private
> shared memory region, attaches to that memory, sends the id to the server, but
On 22-07-2019 12:50 PM, Paul B Mahol wrote:
On 7/21/19, Gyan wrote:
On 21-07-2019 02:21 PM, Paul B Mahol wrote:
On 7/20/19, Gyan wrote:
Affected files can now be demuxed. Verified with John Stebbins. FATE
passes.
Gyan
You removed negative check, so not ok.
entries is unsigned (in the
All,
I have encountered an error in libavdevice/xcbgrab.c that prevents NetBSD from
using X11grab. When xcbgrab_frame_shm calls allocate_shm, it creates a private
shared memory region, attaches to that memory, sends the id to the server, but
then removes the shared memory ID. On NetBSD with
Hi Paul, Marton and Andriy,
I have updated the patch following the comments.
The first part that solves only the PCR bug with multiple programs
is already published:
https://patchwork.ffmpeg.org/patch/14036/
I hope it will soon be accepted.
Regards.
A.H.
---
Hi,
Based on the discussion of my previous patch
https://patchwork.ffmpeg.org/patch/13487/
Here I publish a first part of the patch that only addresses the PCR problem.
This supersedes too: https://patchwork.ffmpeg.org/patch/13745/
Regards.
A.H.
---From
This will use the default priority for gnutls.
When supported, the priority will be set to @SYSTEM which allows to
adapt the ciphers list at runtime according to the policy set.
See also:
https://fedoraproject.org/wiki/Packaging:CryptoPolicies
https://wiki.debian.org/CryptoPolicy
Signed-off-by:
fre 2019-07-19 klockan 09:51 -0700 skrev Baptiste Coudurier:
> Hi Tomas
>
> > On Jul 19, 2019, at 8:48 AM, Tomas Härdin
> > wrote:
> >
> > tor 2019-07-18 klockan 11:39 -0700 skrev Baptiste Coudurier:
> > > ---
> > > libavformat/mxfenc.c | 3 +--
> > > 1 file changed, 1 insertion(+), 2
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Gyan
> Sent: Saturday, July 20, 2019 13:29
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> autoscale to disable/enable the default scale
You are right, some values are expected to be <= 32.
However, it doesn't add a bug: Without my patch fail will occur at parsing
time; With my patch it will occur a bit later on check performed by
get_bits_long().
Maybe we can add a specific max value to each parameter to make logs more
accurate on
On 7/21/19, Gyan wrote:
>
>
> On 21-07-2019 02:21 PM, Paul B Mahol wrote:
>> On 7/20/19, Gyan wrote:
>>> Affected files can now be demuxed. Verified with John Stebbins. FATE
>>> passes.
>>>
>>> Gyan
>>>
>> You removed negative check, so not ok.
>
> entries is unsigned (in the code as well as in
Can effectivly improved decoding speed when memcpy becomes a limitation
for proccessing high resolution source.
Tested under i7-8700k with `ffmpeg -i 7680x4320.avs2 -vsync 0 -f null -`
got performance 23fps => 42fps
Signed-off-by: hwrenx
---
libavcodec/libdavs2.c | 52
Signed-off-by: hwrenx
---
libavcodec/avs2_parser.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/avs2_parser.c b/libavcodec/avs2_parser.c
index 1c9b342..dc2fa16 100644
--- a/libavcodec/avs2_parser.c
+++ b/libavcodec/avs2_parser.c
@@ -23,8 +23,10 @@
#define
Version 5:
1. Using ifs for log level instead of expressions.
Version 4:
1. Change info level setting.
2. Remove `Decoder not found` condition.
The previous version 2 patches were deprecated for using
pointer to itself can be unsafe when release frames.
This patch set is
Signed-off-by: hwrenx
---
libavcodec/libdavs2.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
index 218f3ec..6d66209 100644
--- a/libavcodec/libdavs2.c
+++ b/libavcodec/libdavs2.c
@@ -37,14 +37,29 @@ typedef
On Fri, Jul 19, 2019 at 09:40:52AM +0200, Matthieu Bouron wrote:
> On Sun, Jul 14, 2019 at 08:17:03PM +0200, Matthieu Bouron wrote:
> > On Thu, Jul 04, 2019 at 03:43:48PM +0200, Matthieu Bouron wrote:
> > > ---
> > > libavcodec/mediacodec_wrapper.c | 10 --
> > > 1 file changed, 10
On 7/22/19, David Bryant wrote:
> Hi,
>
> As I promised late last year, here is a patch to add a WavPack DSD decoder.
>
> Thanks!
>
> -David Bryant
>
>
Please correct me if I'm wrong, but why this uses new codec id?
Apparently is also copies some logic from other files.
On 7/21/19, Michael Niedermayer wrote:
> On Sun, Jul 21, 2019 at 10:48:26AM +0200, Paul B Mahol wrote:
>> On 7/21/19, Michael Niedermayer wrote:
>> > Fixes: Timeout (22 -> 7 sec)
>> > Fixes:
>> > 15173/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HQX_fuzzer-5662556846292992
>> >
>> >
38 matches
Mail list logo
