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 al
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 chil
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 val
[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 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
> --- a/libavcodec/pnm_par
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
> --- a/libavcode
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 info
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 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:
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. Y
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
>>
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 invalid
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), altho
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 +
> >> libavcodec/Makefi
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 c
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
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 the
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 sam
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
---
libavcodec/dirac
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
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
>> ---
>>
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
---
lib
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. I
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 work
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/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 to
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 1006
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 a
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 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 factorizat
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.
>
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 av_log(
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.
__
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)
> +{
> +const
>+.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年4月7日，1
>
> 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
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
ffmpeg-devel
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 yuva4
>
> 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 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 An
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 b/doc/examples/met
> -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`
>
> -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
> `opencl_get_p
> -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 o
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
> >
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
ffmpeg-devel@ffmpeg.org
> -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:
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 `offset`
> -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, Ap
> -Original Message-
> From: Fu, Linjie
> Sent: Tuesday, March 26, 2019 13:38
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie ; ChaoX A Liu
> Subject: [PATCH 1/3] lavc/qsvdec: add support for gpu_copy
>
> Add support for GPU copy when QSV decoders works in system memory
> mode.
> However,
On Mon, 8 Apr 2019 06:39:27 +0800
Steven Liu wrote:
> >+.long_name = NULL_IF_CONFIG_SMALL("Xunlie Video File"),
XV is a video output format, so please make the title something like
"flv: Add XV (Xunlie Video) support".
- Lauri
___
ffmpeg-deve
> On April 7, 2019 at 11:24 AM Andreas Rheinhardt via ffmpeg-devel
> wrote:
>
>
> 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
> >>
> On April 7, 2019 at 11:38 AM Andreas Rheinhardt via ffmpeg-devel
> wrote:
>
>
> 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 th
> On April 7, 2019 at 12:54 PM Andreas Rheinhardt via ffmpeg-devel
> wrote:
>
>
> 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
> >> (whi
54 matches
Mail list logo
