> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> myp...@gmail.com
> Sent: Monday, April 8, 2019 9:37 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] lavfi: add nlmeans_opencl filter
>
> On Mon,
The `opencl_get_plane_format` function was incorrectly determining the
value used to set the image channel order. This resulted in all RGB
pixel formats being set to the `CL_RGBA` pixel format, regardless of
whether or not they actually *were* RGBA.
This patch fixes the issue by using the
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Michael Niedermayer
> Sent: Friday, April 5, 2019 00:52
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v3 RFC 2/2] lavc/vaapi_decode:
On Mon, Apr 8, 2019 at 5:30 AM Carl Eugen Hoyos wrote:
>
> Hi!
>
> Attached patch is what git grep showed me after seeing ecdaa4b4 by Paul.
>
> Please comment, Carl Eugen
LGTM if pass the fate. Thanks
___
ffmpeg-devel mailing list
On Mon, Apr 8, 2019 at 9:33 AM Song, Ruiling wrote:
>
> > -Original Message-
> > From: Song, Ruiling
> > Sent: Monday, April 1, 2019 3:53 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Song, Ruiling
> > Subject: [PATCH] lavfi: add nlmeans_opencl filter
> >
> > Signed-off-by: Ruiling Song
>
> -Original Message-
> From: Song, Ruiling
> Sent: Monday, April 1, 2019 3:53 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Song, Ruiling
> Subject: [PATCH] lavfi: add nlmeans_opencl filter
>
> Signed-off-by: Ruiling Song
> ---
> This filter runs about 2x faster on integrated GPU than nlmeans
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Cld fire
> Sent: Monday, April 8, 2019 8:11 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] libavutil/hwcontext_opencl.c: fix bug in
>
On Wed, Apr 3, 2019 at 3:26 PM Jun Zhao wrote:
>
> From: Jun Zhao
>
> fix the example can't dump FLV metadata.
>
> Signed-off-by: Jun Zhao
> ---
> doc/examples/metadata.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/doc/examples/metadata.c
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Monday, April 8, 2019 7:27 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] libavutil/hwcontext_opencl.c: fix bug in
> `opencl_get_plane_format`
>
On Fri, Apr 5, 2019 at 12:38 AM Andreas Rheinhardt via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
>
> Jun Zhao:
> > From: Jun Zhao
> >
> > Fix memory leak after write trailer for #7827, only store a audio
> > packet whose buffer has size greater than zero in cur_audio_pkt.
> >
> > Thanks to
>
> For P010, I guess that division needs to round up?
>
Yep, rounding the division up did the trick; thanks!
One last observation before I submit a new patch: I actually missed
previously that the order number is still not lining up for the ARGB format
(the order number that maps to ARGB in the
On 07/04/2019 23:40, Cld fire wrote:
>>
>> Does anything go wrong if you unconditionally add comp->offset / (depth /
>> 8)?
>
>
> Yes. Occasionally there is a depth value less than 8:
>
> [opencl_get_plane_format] depth is 2 < 8 for format: rgb8 on plane: 0
> [AVHWDeviceContext @ _] Format
2019-04-03 1:19 GMT+02:00, Carl Eugen Hoyos :
> 2019-03-28 19:35 GMT+01:00, Carl Eugen Hoyos :
>
>> Attached patch fixes ticket #7816 for me.
>>
>> Please review, Carl Eugen
>
> Ping.
Please comment.
Carl Eugen
___
ffmpeg-devel mailing list
>
> Does anything go wrong if you unconditionally add comp->offset / (depth /
> 8)?
Yes. Occasionally there is a depth value less than 8:
[opencl_get_plane_format] depth is 2 < 8 for format: rgb8 on plane: 0
[AVHWDeviceContext @ _] Format yuva420p supported.
[opencl_get_plane_format] depth is 5
>+.long_name = NULL_IF_CONFIG_SMALL("Xunlie Video File"),
The this should
.long_name = NULL_IF_CONFIG_SMALL("Xunlei Video File”),
or
.long_name = NULL_IF_CONFIG_SMALL(“Xunlei(Thunder) Video File”),
Xunlei is Chinese PinYin[pi:n, yi:n]. Application is Thunder.app
> 在
2019-04-07 8:53 GMT+02:00, Shivam Goyal :
> This time i modified the initial buffer at the time of reading
> header instead of changing the IO layer.
>
> Suggest any changes required.
Please mention ticket #3720 in the commit message.
> +static int xv_probe(const AVProbeData *p)
> +{
> +
On 3/31/2019 6:05 PM, James Almer wrote:
> On 3/26/2019 9:25 PM, James Almer wrote:
>> This will be needed by the eventual native AV1 decoder.
>>
>> Signed-off-by: James Almer
>> ---
>> Now propagating the Temporal Unit unchanged if splitting can't be performed.
>
> Ping.
I'll push this soon.
Hi!
Attached patch is what git grep showed me after seeing ecdaa4b4 by Paul.
Please comment, Carl Eugen
From 564a27a19c930c73cb00b4ac013f26e9417a5a57 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sun, 7 Apr 2019 23:28:00 +0200
Subject: [PATCH] lavf/movenc: Pass correct pointer to
On 06/04/2019 00:05, Jarek Samic wrote:
> The `opencl_get_plane_format` function was incorrectly determining the
> value used to set the image channel order. This resulted in all RGB
> pixel formats being set to the `CL_RGBA` pixel format, regardless of
> whether or not they actually *were* RGBA.
On 4/7/2019 4:22 PM, Marton Balint wrote:
>
>
> On Sun, 7 Apr 2019, James Almer wrote:
>
>> On 4/7/2019 3:47 PM, Marton Balint wrote:
>>> framethread.c is put into libavutil, but is has to be included
>>> directly to
>>> avoid creating avpriv functions.
>>
>> If the reason behind this
On 3/26/19, Paul B Mahol wrote:
> On 3/26/19, Carl Eugen Hoyos wrote:
>> 2019-03-26 11:34 GMT+01:00, Paul B Mahol :
>>> On 3/26/19, Carl Eugen Hoyos wrote:
2019-03-26 11:13 GMT+01:00, Paul B Mahol :
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/get_bits.h | 82
>
On Sun, 7 Apr 2019, James Almer wrote:
On 4/7/2019 3:47 PM, Marton Balint wrote:
framethread.c is put into libavutil, but is has to be included directly to
avoid creating avpriv functions.
If the reason behind this factorization is sharing the code between
modules across several libraries
v2: Disallow positive override of seekability as requested by Hendrik Leppkes.
Signed-off-by: Marton Balint
---
doc/protocols.texi | 8
libavformat/file.c | 5 +
2 files changed, 13 insertions(+)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index e1caa049a5..3e4e7af3d4
On 4/7/2019 3:47 PM, Marton Balint wrote:
> framethread.c is put into libavutil, but is has to be included directly to
> avoid creating avpriv functions.
If the reason behind this factorization is sharing the code between
modules across several libraries and the function signatures are
unlikely
On Sun, 7 Apr 2019, Paul B Mahol wrote:
On 4/7/19, Marton Balint wrote:
framethread.c is put into libavutil, but is has to be included directly to
avoid creating avpriv functions.
Functionality should be identical, there is one slight difference: we close
the
per-thread avcodec contexts in
On 4/7/19, Marton Balint wrote:
> framethread.c is put into libavutil, but is has to be included directly to
> avoid creating avpriv functions.
>
> Functionality should be identical, there is one slight difference: we close
> the
> per-thread avcodec contexts in the main thread and not in the
Hello,
thanks for taking the time to review this. Much appreciated.
Steve Lhomme:
> Hi,
>
> On 3/27/2019 12:18 PM, Andreas Rheinhardt wrote:
>> This also changed the handling of unknown-sized elements: They are now
>> ended whenever an element not known to be allowed in them is
>> encountered.
framethread.c is put into libavutil, but is has to be included directly to
avoid creating avpriv functions.
Functionality should be identical, there is one slight difference: we close the
per-thread avcodec contexts in the main thread and not in the workers.
Signed-off-by: Marton Balint
---
Steve Lhomme:
> On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
>> By including SimpleBlocks and Blocksgroups twice in the same EbmlSyntax
>> array (with different semantics), one can reduce the duplication of the
>> other values.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
Steve Lhomme:
> On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
>> This commit changes how levels are handled: If the level used for
>> ebml_parse ends directly after an element that has been consumed, then
>> ebml_parse ends the level itself (and any finite-sized levels that end
It seems the specification does not limit the value to 32bit
Fixes: signed integer overflow: -109611143 * 24 cannot be represented in type
'int'
Fixes:
13477/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5648337460527104
Signed-off-by: Michael Niedermayer
---
On Sat, Apr 06, 2019 at 09:47:07AM +0200, Paul B Mahol wrote:
> On 4/6/19, Nikolas Bowe via ffmpeg-devel wrote:
> > When asetnsamples uses output samples < input samples, remaining samples
> > build up in the fifo over time.
> > Fix this by marking the filter as ready again if there are enough
On 4/7/2019 4:47 AM, Allan Cady via ffmpeg-devel wrote:
> [Second try submitting to the list. This patch now passes fate.]
>
> When the silencedetect filter is run against long files, the output
> timestamps gradually lose precision as the scan proceeds further into
> the file. This is because
Steve Lhomme:
> On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
>> The earlier code set the level to zero upon seeking and after a
>> discontinuity although in both cases parsing (re)starts at a level 1
>> element.
>>
>> Also set the segment's length to unkown if an error occured
Steve Lhomme:
> On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
>> The earlier code had three flaws:
>>
>> 1. The case of an unknown-sized element inside a finite-sized element
>> (which is against the specifications) was not caught.
>>
>> 2. The error message wasn't helpful: It
On Sun, Apr 07, 2019 at 10:00:09AM +0200, Paul B Mahol wrote:
> On 4/7/19, Peter Ross wrote:
> > On Wed, Mar 27, 2019 at 09:21:47PM +0100, Paul B Mahol wrote:
> >> Signed-off-by: Paul B Mahol
> >> ---
> >> Missing deblocking.
> >> ---
> >> configure |1 +
> >>
Steve Lhomme:
> On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
>> Before this commit, the Matroska muxer would read a block when required
>> to do so, parse the block, create and return the necessary AVPackets
>> and
>> yet keep the blocks (in a dynamically allocated list),
Steve Lhomme:
> On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
>> ebml_read_num had a number of flaws:
>>
>> 1. The check for read errors/EOF was totally wrong. E.g. an EBML number
>> beginning with the invalid 0x00 would be considered a read error,
>> although it is just
Steve Lhomme:
> On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
>> By default, the data_offset member of the AVFormatInternal of the
>> AVFormatContext associated with the MatroskaDemuxContext has not been
>> initialized explicitly by any Matroska-specific function, so that it
>>
On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
This is important as unknown-sized elements end upon encountering an
unknown EBML ID.
That's the problem with this approach. Noone is allowed to use their own
custom tags (RAWCooked for example) and the unknown length feature.
On 4/7/19, Peter Ross wrote:
> On Wed, Mar 27, 2019 at 09:21:47PM +0100, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol
>> ---
>> Missing deblocking.
>> ---
>> configure |1 +
>> libavcodec/Makefile |1 +
>> libavcodec/allcodecs.c |1 +
>> libavcodec/avcodec.h
On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
By including SimpleBlocks and Blocksgroups twice in the same EbmlSyntax
array (with different semantics), one can reduce the duplication of the
other values.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 13
On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
This commit changes how levels are handled: If the level used for
ebml_parse ends directly after an element that has been consumed, then
ebml_parse ends the level itself (and any finite-sized levels that end
there as well) and
On 4/7/19, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/pnm_parser.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/pnm_parser.c b/libavcodec/pnm_parser.c
> index 91a9edc016..95241c30b3 100644
> ---
On 4/7/19, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/pnm_parser.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libavcodec/pnm_parser.c b/libavcodec/pnm_parser.c
> index e3bfa3c490..91a9edc016 100644
> ---
[Second try submitting to the list. This patch now passes fate.]
When the silencedetect filter is run against long files, the output
timestamps gradually lose precision as the scan proceeds further into
the file. This is because the output is formatted (in
libavutil/timestamp.h) as "%.6g", which
On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
The earlier code set the level to zero upon seeking and after a
discontinuity although in both cases parsing (re)starts at a level 1
element.
Also set the segment's length to unkown if an error occured in order not
to drop any
On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
The earlier code had three flaws:
1. The case of an unknown-sized element inside a finite-sized element
(which is against the specifications) was not caught.
2. The error message wasn't helpful: It compared the length of the
On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
Before this commit, the Matroska muxer would read a block when required
to do so, parse the block, create and return the necessary AVPackets and
yet keep the blocks (in a dynamically allocated list), although they
aren't used at
On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
ebml_read_num had a number of flaws:
1. The check for read errors/EOF was totally wrong. E.g. an EBML number
beginning with the invalid 0x00 would be considered a read error,
although it is just invalid data.
2. The check for
This time i modified the initial buffer at the time of reading header
instead of changing the IO layer.
Suggest any changes required.
>From 277a4267f8cbb68c5fa57a0bddd215e04ca662bd Mon Sep 17 00:00:00 2001
From: Shivam Goyal
Date: Sun, 7 Apr 2019 12:13:21 +0530
Subject: [PATCH] Added XV
On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
By default, the data_offset member of the AVFormatInternal of the
AVFormatContext associated with the MatroskaDemuxContext has not been
initialized explicitly by any Matroska-specific function, so that it was
initialized by
On Mon, 1 Apr 2019 13:37:32 +0300
Lauri Kasanen wrote:
> ./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 \
> -s 1200x720 -f null -vframes 100 -pix_fmt $i -nostats \
> -cpuflags 0 -v error -
>
> 32-bit mul, power8 only.
>
> ~6.4x speedup:
>
> rgb24
>
On Mon, 1 Apr 2019 13:13:59 +0300
Lauri Kasanen wrote:
> ./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 -sws_flags area \
> -s 1200x720 -f null -vframes 100 -pix_fmt $i -nostats \
> -cpuflags 0 -v error -
>
> 32-bit mul, power8 only.
>
> ~4x speedup:
>
> rgb24
On Sun, 31 Mar 2019 17:18:47 +0300
Lauri Kasanen wrote:
> ./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 -sws_flags
> fast_bilinear \
> -s 1200x1440 -f null -vframes 100 -pix_fmt $i -nostats \
> -cpuflags 0 -v error -
>
> 32-bit mul, power8 only.
>
> 1.8-2.3x speedup:
Hi,
On 3/27/2019 12:18 PM, Andreas Rheinhardt wrote:
This also changed the handling of unknown-sized elements: They are now
ended whenever an element not known to be allowed in them is
encountered. If we are already on level 1 and encounter an element not
known to be allowed in an unknown-sized
56 matches
Mail list logo
