Do we support these float formats in swscale?
If not, than patch is IMHO pointless.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
Some real-world sites use an authorization header with a bearer token; when
combined with lengthy request parameters to identify the video segment,
it's rather trivial these days to have a request body of more than 4k bytes.
Because MAX_URL_SIZE is hard-coded to 4k bytes in
On Sun, 10 May 2020, Joey Smith wrote:
Some real-world sites use an authorization header with a bearer token; when
combined with lengthy request parameters to identify the video segment,
it's rather trivial these days to have a request body of more than 4k bytes.
Because MAX_URL_SIZE is
On Sat., May 9, 2020, 11:59 p.m. Paul B Mahol, wrote:
> Do we support these float formats in swscale?
> If not, than patch is IMHO pointless.
>
Yes, my patches for swscale float support was merged a few days ago. I also
plan to try and add floating point support to some vf filters, namely
What's next?
Decoders?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
On Sun, 10 May 2020, Martin Storsjö wrote:
From: wm4
This contains encoder wrappers for H264, HEVC, AAC, AC3 and MP3.
This is based on top of an original patch by wm4
. The original patch supported both encoding
and decoding, but this patch only includes encoding.
The patch contains
Actually, that seems like a more rational fix all around - I just saw the
BUFFER_SIZE in
http.c being limited to MAX_URL_SIZE and jumped straight to expanding that,
but in
looking at your suggestion, I see now there's an HTTP_HEADERS_SIZE that
appears
to be defined but then never used. Do you want
On 5/10/20, Mark Reid wrote:
> On Sat., May 9, 2020, 11:59 p.m. Paul B Mahol, wrote:
>
>> Do we support these float formats in swscale?
>> If not, than patch is IMHO pointless.
>>
>
> Yes, my patches for swscale float support was merged a few days ago. I also
> plan to try and add floating point
On Fri, Feb 14, 2020 at 04:37:32PM +0100, Paul B Mahol wrote:
> Actually I'm pretty sure log message is not needed as not power of 8
> is simply not possible.
ok, will apply without the log message
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
He who
The fixed point integer reference specifies the multiplication used
to have 16bit input and clips so we need to clip the input
The floating point implementation does not seem to do that.
Fixes: signed integer overflow: 6317568 * 410 cannot be represented in type
'int'
Fixes:
Fixes: negation of -2147483648 cannot be represented in type 'int32_t' (aka
'int'); cast to an unsigned type to negate this value to itself
Fixes: signed integer overflow: -2147483648 - 1 cannot be represented in type
'int32_t' (aka 'int')
Fixes:
Fixes: signed integer overflow: 1020048 * 4096 cannot be represented in type
'int'
Fixes:
20492/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALAC_fuzzer-5753877751660544
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by:
Fixes: signed integer overflow: -2147483647 - 61436 cannot be represented in
type 'int'
Fixes:
20492/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ADPCM_IMA_APM_fuzzer-5092176004644864
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
On 5/9/2020 6:41 PM, Martin Storsjö wrote:
> +#define MF_ENCODER(MEDIATYPE, NAME, ID, OPTS, EXTRA) \
> +static const AVClass ff_ ## NAME ## _mf_encoder_class = {
> \
> +.class_name = #NAME "_mf",
> \
> +.item_name
Also documents all options supported by the hwdevice.
This lets users enable all extensions they need without writing their own
instance initialization code.
Patch attached.
>From cf91acc2a907a5ff7af753bf3b2ab495dbc37db0 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Sun, 10 May 2020 11:26:40
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/mpegvideo.c | 48
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 49fd1c9..561062f 100644
---
On Sun, 10 May 2020, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/mpegvideo.c | 48
1 file changed, 24 insertions(+), 24 deletions(-)
If you find these cosmetics interesting, then I suggest you
On 10/05/2020 11:51, Lynne wrote:
> Also documents all options supported by the hwdevice.
> This lets users enable all extensions they need without writing their own
> instance initialization code.
>
> Patch attached.
>
>
> From cf91acc2a907a5ff7af753bf3b2ab495dbc37db0 Mon Sep 17 00:00:00 2001
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/mpegvideo.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 561062f..b993813 100644
--- a/libavcodec/mpegvideo.c
+++
On 10/05/2020 11:54, Lynne wrote:
> This solves a huge oversight - it lets users reliably use their own
> AVVulkanDeviceContext. Otherwise, the extensions supplied and enabled
> are not discoverable by anything outside of hwcontext_vulkan.
>
> Patch attached.
>
> This, and the previous patch to
This solves a huge oversight - it lets users reliably use their own
AVVulkanDeviceContext. Otherwise, the extensions supplied and enabled
are not discoverable by anything outside of hwcontext_vulkan.
Patch attached.
This, and the previous patch to enable extensions through the options are
This is similar to field 1 (effd2e72)
---
libavcodec/speedhq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c
index 890b8253cd..b834b79f28 100644
--- a/libavcodec/speedhq.c
+++ b/libavcodec/speedhq.c
@@ -447,7 +447,7 @@ static int
On Sun, 10 May 2020, Joey Smith wrote:
Actually, that seems like a more rational fix all around - I just saw the
BUFFER_SIZE in
http.c being limited to MAX_URL_SIZE and jumped straight to expanding that,
but in
looking at your suggestion, I see now there's an HTTP_HEADERS_SIZE that
appears
to
Please see new version of the patch with the changes addressed.
Thanks
Tom
From f91f5931fcc381cbcddb8abc03dde3f81c33a085 Mon Sep 17 00:00:00 2001
From: Tom Needham <06needh...@gmail.com>
Date: Sun, 10 May 2020 16:42:00 +0100
Subject: [PATCH] avformat: Add Dynacolor MVC Demuxer
This demuxer
Quoting Marton Balint (2020-05-10 19:45:04)
>
>
> On Sun, 10 May 2020, Anton Khirnov wrote:
>
> > Quoting Andreas Rheinhardt (2020-05-08 00:55:00)
> >> This commit fixes two recent regressions both of which are about using
> >> pkt->stream_index as index in an AVFormatContext's streams array
On Sun, May 10, 2020 at 06:30:41PM +0200, Marton Balint wrote:
>
>
> On Sun, 10 May 2020, lance.lmw...@gmail.com wrote:
>
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/mpegvideo.c | 48
> > 1 file changed, 24
From: Mark Reid
upon more floating point testing, looks like I missed adding this bit.
---
libswscale/utils.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 15c0a19afa..111062e915 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@
Signed-off-by: James Almer
---
libavformat/ivfenc.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index 45e5b238dc..0ce4a85171 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -26,10 +26,9 @@ typedef
James Almer:
> Signed-off-by: James Almer
> ---
AVCodec? What AVCodec?
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
On 10/05/2020 15:02, Lynne wrote:
> May 10, 2020, 14:14 by s...@jkqxz.net:
>> On 10/05/2020 11:51, Lynne wrote:
>>> ...
>
> New version attached.
>
> > From a4741ed92aecc43e64ca424206c3989008a222fd Mon Sep 17 00:00:00 2001
> From: Lynne
> Date: Sun, 10 May 2020 11:26:40 +0100
> Subject: [PATCH
On 10/05/2020 15:23, Lynne wrote:
> May 10, 2020, 14:33 by s...@jkqxz.net:
>> On 10/05/2020 11:54, Lynne wrote:
>>> ...
>
> From 6ecc3547bcfcc450c8ffe8d93a3040fd863f6288 Mon Sep 17 00:00:00 2001
> From: Lynne
> Date: Sun, 10 May 2020 11:47:50 +0100
> Subject: [PATCH 2/3] hwcontext_vulkan:
On 5/10/2020 6:29 PM, Andreas Rheinhardt wrote:
> James Almer:
>> Signed-off-by: James Almer
>> ---
> AVCodec? What AVCodec?
Right, changed locally to AVOutputFormat. Sorry about that.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Signed-off-by: James Almer
---
libavformat/ivfenc.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index 0ce4a85171..0951f56c92 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -43,6 +43,16
Quoting Andreas Rheinhardt (2020-05-08 00:55:00)
> This commit fixes two recent regressions both of which are about using
> pkt->stream_index as index in an AVFormatContext's streams array before
> actually comparing the value with the count of streams in said array.
>
From: Andriy Gelman
Signed-off-by: Andriy Gelman
---
Same as commit d1e52e396b8aa778bd8d12bf25864beca0937d0a
doc/developer.texi | 2 +-
fftools/cmdutils.c | 2 +-
fftools/ffmpeg.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/developer.texi b/doc/developer.texi
On Sun, May 10, 2020 at 09:20:13PM +0200, Michael Niedermayer wrote:
> This uses lrintf() which is not ideal as it still can raise an error
> but it is not undefined behavior. So a better solution should ideally be found
>
> Fixes: -2.4187e+09 is outside the range of representable values of type
NAK
please remove this code fully.
On 5/10/20, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -234 * -14797801 cannot be represented in
> type 'int'
> Fixes:
> 20492/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SONIC_fuzzer-5695924975435776
>
> Found-by: continuous fuzzing
On Sat, May 9, 2020, at 1:41 PM, Martin Storsjö wrote:
> + --enable-mf enable decoding via MediaFoundation [auto]
encoding/decoding typo I presume.
I would prefer --enable-mediafoundation as it is more descriptive.
___
ffmpeg-devel
May 10, 2020, 14:14 by s...@jkqxz.net:
> On 10/05/2020 11:51, Lynne wrote:
>
>> Also documents all options supported by the hwdevice.
>> This lets users enable all extensions they need without writing their own
>> instance initialization code.
>>
>> Patch attached.
>>
>>
>> From
May 10, 2020, 14:33 by s...@jkqxz.net:
> On 10/05/2020 11:54, Lynne wrote:
>
>> */
>> VkInstance inst;
>> +/**
>> + * Enabled instance extensions. By default, VK_KHR_surface is enabled
>> if found.
>> + */
>>
>
> Clarify how this should be set by the user if they are supplying the
This uses lrintf() which is not ideal as it still can raise an error
but it is not undefined behavior. So a better solution should ideally be found
Fixes: -2.4187e+09 is outside the range of representable values of type 'int'
Fixes: signed integer overflow: -14512205 + -2147483648 cannot be
Fixes: signed integer overflow: 2129689466 + 2129689466 cannot be represented
in type 'int'
Fixes:
20715/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SONIC_fuzzer-5155263109922816
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Fixes: signed integer overflow: -234 * -14797801 cannot be represented in type
'int'
Fixes:
20492/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SONIC_fuzzer-5695924975435776
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by:
Fixes: signed integer overflow: 65312 * 65312 cannot be represented in type
'int'
Fixes:
20492/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NUV_fuzzer-5740176118906880
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by:
Fixes: signed integer overflow: 289082077 - -200314 cannot be represented
in type 'int'
Fixes:
20492/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RALF_fuzzer-5196077752123392
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Fixes: signed integer overflow: 1931744255 + 252497024 cannot be represented in
type 'int'
Fixes:
20492/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TTA_fuzzer-5763348114440192
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Fixes: signed integer overflow: 2147483594 + 142 cannot be represented in type
'int'
Fixes:
20492/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_UTVIDEO_fuzzer-5658568101724160
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by:
Anton Khirnov:
> Quoting Marton Balint (2020-05-10 19:45:04)
>>
>>
>> On Sun, 10 May 2020, Anton Khirnov wrote:
>>
>>> Quoting Andreas Rheinhardt (2020-05-08 00:55:00)
This commit fixes two recent regressions both of which are about using
pkt->stream_index as index in an
On Sun, 10 May 2020, Anton Khirnov wrote:
Quoting Andreas Rheinhardt (2020-05-08 00:55:00)
This commit fixes two recent regressions both of which are about using
pkt->stream_index as index in an AVFormatContext's streams array before
actually comparing the value with the count of streams in
Quoting lance.lmw...@gmail.com (2020-04-18 06:52:49)
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/libx264.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index edd343e..3fa2311 100644
> ---
Hi Marton/all,
I've re-uploaded the firefox send link (expired) with some sample
capture at 60 FPS:
https://send.firefox.com/download/51b45decae720c08/#r5o4J2SgCJZndRdMOxxRBg
Please note I have integrated usage of OpenGL's Pixel Buffer Objects -
now the memory management of the captured
On Sun, 10 May 2020, Paul B Mahol wrote:
What's next?
Decoders?
I probably won't put in effort in getting the MediaFoundation decoder
support merged myself, but if this is merged, I can at least try to make a
WIP patch somewhere that adds the rest of the decoding support from the
original
On Mon, 11 May 2020, lance.lmw...@gmail.com wrote:
On Sun, May 10, 2020 at 06:30:41PM +0200, Marton Balint wrote:
On Sun, 10 May 2020, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/mpegvideo.c | 48
Updated patch attached
On Sun, May 10, 2020 at 3:19 AM Marton Balint wrote:
>
>
> On Sun, 10 May 2020, Joey Smith wrote:
>
> > Actually, that seems like a more rational fix all around - I just saw the
> > BUFFER_SIZE in
> > http.c being limited to MAX_URL_SIZE and jumped straight to expanding
>
On Mon, May 11, 2020 at 01:22:24AM +0200, Marton Balint wrote:
>
>
> On Mon, 11 May 2020, lance.lmw...@gmail.com wrote:
>
> > On Sun, May 10, 2020 at 06:30:41PM +0200, Marton Balint wrote:
> > >
> > >
> > > On Sun, 10 May 2020, lance.lmw...@gmail.com wrote:
> > >
> > > > From: Limin Wang
>
May 10, 2020, 22:39 by s...@jkqxz.net:
> On 10/05/2020 15:23, Lynne wrote:
>
>> May 10, 2020, 14:33 by s...@jkqxz.net:
>>
>>> On 10/05/2020 11:54, Lynne wrote:
>>>
...
>>
>> From 6ecc3547bcfcc450c8ffe8d93a3040fd863f6288 Mon Sep 17 00:00:00 2001
>> From: Lynne
>> Date: Sun, 10 May 2020
May 10, 2020, 22:23 by s...@jkqxz.net:
>>
>> +for (int i = 0; i < dev_info.enabledExtensionCount; i++)
>> +av_free((void *)dev_info.ppEnabledExtensionNames[i]);
>> av_free((void *)dev_info.ppEnabledExtensionNames);
>>
>> if (ret != VK_SUCCESS) {
>> --
>> 2.26.2
>>
>
> LGTM with
On Mon, May 11, 2020 at 01:22:24AM +0200, Marton Balint wrote:
>
>
> On Mon, 11 May 2020, lance.lmw...@gmail.com wrote:
>
> > On Sun, May 10, 2020 at 06:30:41PM +0200, Marton Balint wrote:
> > >
> > >
> > > On Sun, 10 May 2020, lance.lmw...@gmail.com wrote:
> > >
> > > > From: Limin Wang
>
58 matches
Mail list logo
