On Sat, May 9, 2020 at 10:26 PM Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Max Dmitrichenko
> > Sent: Saturday, May 9, 2020 10:13 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH v4
On Tue, 05. May 17:29, Andriy Gelman wrote:
> On Thu, 30. Apr 01:39, Ming Qian wrote:
> > > From: Andriy Gelman
> > >
> > > v4l2_m2m devices may send an empty packet/frame while draining to indicate
> > > that all capture buffers have been flushed.
> > >
> > > Currently, the empty packet/frame
From: Mark Reid
changes since v1
- default behavior, no longer hidden behind decoder parameter
- updated tests to reflect change
---
libavcodec/exr.c | 244 +-
tests/fate/image.mak | 120 -
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Max Dmitrichenko
> Sent: Saturday, May 9, 2020 10:13 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va:
> adding more texture
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Max Dmitrichenko
> Sent: Saturday, May 9, 2020 10:16 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va:
> adding more texture
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Max Dmitrichenko
> Sent: Saturday, May 9, 2020 10:42 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va:
> adding more texture
On Sat, May 9, 2020 at 10:32 PM Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Max Dmitrichenko
> > Sent: Saturday, May 9, 2020 10:16 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH v4
> 2020年5月10日 上午3:15，Andreas Rheinhardt 写道：
>
> For every variantstream vs, vs->packets_written is set to one, only to be
> set to zero a few lines below. Given that the relevant structure has
> been zeroed during the allocation, this commit removes both assignments.
> A redundant
> 2020年5月10日 上午3:15，Andreas Rheinhardt 写道：
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/hlsenc.c | 43 ++-
> 1 file changed, 14 insertions(+), 29 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index
On Sat, 9 May 2020 at 22:29, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Max Dmitrichenko
> > Sent: Saturday, May 9, 2020 10:42 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH v4
On 3/9/2020 9:09 AM, James Almer wrote:
> On 3/9/2020 6:09 AM, Hendrik Leppkes wrote:
>> On Mon, Mar 9, 2020 at 3:20 AM James Almer wrote:
>>>
>>> Signed-off-by: James Almer
>>> ---
>>> libavcodec/decode.c | 1 -
>>> libavcodec/internal.h | 1 -
>>> 2 files changed, 2 deletions(-)
>>>
>>>
On Mon, Dec 30, 2019 at 07:09:58PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/vf_signalstats.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libavfilter/vf_signalstats.c
On Sat, May 9, 2020 at 5:09 PM Mark Thompson wrote:
> On 08/05/2020 21:26, Hendrik Leppkes wrote:
> > On Fri, May 8, 2020 at 5:51 PM wrote:
> >>
> >> From: Artem Galin
> >>
> >> Added AVD3D11FrameDescriptors array to store array of single textures
> in case if there is no way
> >> to allocate
> 2020年5月10日 上午3:21，Andreas Rheinhardt 写道：
>
> Steven Liu:
>> Signed-off-by: Steven Liu
>> ---
>> libavformat/hlsenc.c | 37 -
>> 1 file changed, 20 insertions(+), 17 deletions(-)
>>
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Artem Galin
> Sent: Sunday, May 10, 2020 1:19 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va:
> adding more texture information to
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 further changes by Paweł Wegner
(primarily for
On Sat, Apr 18, 2020 at 12:19:30PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> By the av_strtok() description:
> * On the first call to av_strtok(), s should point to the string to
> * parse, and the value of saveptr is ignored. In subsequent calls, s
> * should be NULL, and
On Tue, Apr 07, 2020 at 10:53:52PM +0200, Michael Niedermayer wrote:
> Fixes:
> 21089/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APNG_fuzzer-5135981419429888
> Fixes: out of array read
>
> Found-by: continuous fuzzing process
>
On Tue, Apr 14, 2020 at 02:15:45AM +0200, Michael Niedermayer wrote:
> Fixes: 8233/PPY6574574605_cut.mp3
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mpeg.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
will apply
[...]
--
Michael GnuPG fingerprint:
On Wed, Apr 15, 2020 at 09:18:41PM +0200, Michael Niedermayer wrote:
> The demuxer code assumes the existence of a video stream
>
> Fixes: assertion failure
> Fixes:
> 21512/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5699660783288320
>
> Found-by: continuous fuzzing process
>
> 2020年5月10日 上午3:15，Andreas Rheinhardt 写道：
>
> ff_format_io_close() already does it for us.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/hlsenc.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 7b289c060f..a796c124dd
> 2020年5月10日 上午3:15，Andreas Rheinhardt 写道：
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/hlsenc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index afb4d2a0c0..2a0d17baea 100644
> ---
> 2020年5月10日 上午3:15，Andreas Rheinhardt 写道：
>
> Signed-off-by: Andreas Rheinhardt
> ---
> The usage of fmp4_init_filename_len is weird: It is basically used for
> two different purposes: The length of vs->fmp4_init_filename_len and the
> length of vs->base_output_dirname (this name is btw
On Tue, Apr 28, 2020 at 11:49:16AM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> note it'll cause a small difference in accuracy for the pts, please see the
> testing result below:
> $ wget
>
On Sun, Apr 05, 2020 at 11:10:44PM +0200, Michael Niedermayer wrote:
> Fixes: OOM
> Fixes:
> 20774/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HAP_fuzzer-5678608951803904
> Fixes:
> 20956/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HAP_fuzzer-5713643025203200
>
> Found-by:
> 2020年5月10日 上午3:15，Andreas Rheinhardt 写道：
>
> Signed-off-by: Andreas Rheinhardt
> ---
> This patch is designed not to change the output at all. Yet I wonder if
> instead of p = strrchr(vs->m3u8_name, '.') it should not better be p =
> strrchr(av_basename(vs->m3u8_name), '.'). Otherwise in a
On Sat, May 9, 2020 at 9:18 AM Hendrik Leppkes wrote:
> On Sat, May 9, 2020 at 9:07 AM Hendrik Leppkes
> wrote:
> >
> > On Sat, May 9, 2020 at 2:12 AM Soft Works wrote:
> > >
> > > > From: ffmpeg-devel On Behalf Of
> > > > Hendrik Leppkes
> > > > Sent: Friday, May 8, 2020 10:27 PM
> > > > To:
On 04/05/2020 15:19, Jan Ekström wrote:
> On Sun, Apr 26, 2020 at 11:26 PM David Manouchehri
> wrote:
>>
>> Resubmit of a previous patch, not sure why the diff didn't come through.
>> ___
>>
>> @@ -56,7 +55,13 @@ static av_cold int
On Sat, May 09, 2020 at 06:52:35AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Mon, May 04, 2020 at 08:22:50PM +0200, Andreas Rheinhardt wrote:
> >> Allocating an array with zero entries is both unnecessary as well as
> >> potentially troublesome because the behaviour in this
On 08/05/2020 21:26, Hendrik Leppkes wrote:
> On Fri, May 8, 2020 at 5:51 PM wrote:
>>
>> From: Artem Galin
>>
>> Added AVD3D11FrameDescriptors array to store array of single textures in
>> case if there is no way
>> to allocate array texture with BindFlags = D3D11_BIND_RENDER_TARGET.
>>
>>
Signed-off-by: Andreas Rheinhardt
---
This patch is designed not to change the output at all. Yet I wonder if
instead of p = strrchr(vs->m3u8_name, '.') it should not better be p =
strrchr(av_basename(vs->m3u8_name), '.'). Otherwise in a path like
"./hlsstream/master" everything after '.' will be
For every variantstream vs, vs->packets_written is set to one, only to be
set to zero a few lines below. Given that the relevant structure has
been zeroed during the allocation, this commit removes both assignments.
A redundant initialization for vs->init_range_length has been removed as
well a
Signed-off-by: Andreas Rheinhardt
---
libavformat/hlsenc.c | 43 ++-
1 file changed, 14 insertions(+), 29 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 5517cb4354..d80852739e 100644
--- a/libavformat/hlsenc.c
+++
ff_format_io_close() already does it for us.
Signed-off-by: Andreas Rheinhardt
---
libavformat/hlsenc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 7b289c060f..a796c124dd 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@
Signed-off-by: Andreas Rheinhardt
---
libavformat/hlsenc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index afb4d2a0c0..2a0d17baea 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -525,10 +525,10 @@
Signed-off-by: Andreas Rheinhardt
---
The usage of fmp4_init_filename_len is weird: It is basically used for
two different purposes: The length of vs->fmp4_init_filename_len and the
length of vs->base_output_dirname (this name is btw misleading because
it is not a dirname at all). And given that
Steven Liu:
> Signed-off-by: Steven Liu
> ---
> libavformat/hlsenc.c | 37 -
> 1 file changed, 20 insertions(+), 17 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 5695c6cc95..a1eddade7b 100644
> --- a/libavformat/hlsenc.c
>
On Sat, May 9, 2020 at 8:31 PM Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Hendrik Leppkes
> > Sent: Saturday, May 9, 2020 7:54 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH v4
On Sat, May 9, 2020 at 8:13 PM Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Hendrik Leppkes
> > > >
> > >
> > > Of course there is a choice. Only support the new stuff. Afterall we
> > > havent supported it at all for years now, so only supporting it
Since commit c5324d92c5f206dcdc2cf93ae237eaa7c1ad0a40 all custom
interleave_packet() functions always return clean packets (even on
error), so that unreferencing manually can be removed.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mux.c | 5 +
1 file changed, 1 insertion(+), 4
On 25.03.2020 10:55, Pestov Vyacheslav wrote:
> On 25.03.2020 1:12, Carl Eugen Hoyos wrote:
>
>> Am Di., 24. März 2020 um 14:28 Uhr schrieb Pestov Vyacheslav
>> :
>>> yuy2ToY_c: 10157
>>> yuy2ToY_c_vsx: 2353
>>>
>>> yuy2ToUV_c: 4907
>>> yuy2ToUV_c_vsx: 1357
>>>
>>> rgb24ToY_c: 21172
>>>
On Sat, May 09, 2020 at 06:04:13AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Mon, May 04, 2020 at 08:22:45PM +0200, Andreas Rheinhardt wrote:
> >> It allows to add analogous functions using e.g. the bytestream API
> >> instead of using an AVIOContext.
> >>
> >> Signed-off-by:
From: Andriy Gelman
v4l2_receive_frame() uses two packets s->buf_pkt and avpkt. If avpkt
cannot be enqueued, the packet is buffered in s->buf_pkt and enqueued in
the next call. Currently the ownership transfer between the two packets
is not properly handled. A double free occurs if
On Sat, May 9, 2020 at 5:09 PM Mark Thompson wrote:
>
> On 08/05/2020 21:26, Hendrik Leppkes wrote:
> > On Fri, May 8, 2020 at 5:51 PM wrote:
> >>
> >> From: Artem Galin
> >>
> >> Added AVD3D11FrameDescriptors array to store array of single textures in
> >> case if there is no way
> >> to
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Hendrik Leppkes
> Sent: Saturday, May 9, 2020 9:08 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va:
> adding more texture information
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Hendrik Leppkes
> > >
> >
> > Of course there is a choice. Only support the new stuff. Afterall we
> > havent supported it at all for years now, so only supporting it on
> > newer drivers isn't the end of the world.
> >
>
> To give
On Sat, May 9, 2020 at 7:48 PM Hendrik Leppkes wrote:
> On Sat, May 9, 2020 at 7:18 PM Max Dmitrichenko
> wrote:
> >
> > On Sat, May 9, 2020 at 3:18 PM Hendrik Leppkes
> wrote:
> >
> > > On Sat, May 9, 2020 at 2:11 PM Max Dmitrichenko
> > > wrote:
> > > >
> > > > Question about
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Hendrik Leppkes
> Sent: Saturday, May 9, 2020 7:54 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va:
> adding more texture information
Hi.
https://crbug.com/aomedia/2545
This bug is resolved and we no longer need these lines to avoid crash in
libaom.
> -rawimg->planes[AOM_PLANE_U] = frame->data[1];
> -rawimg->planes[AOM_PLANE_V] = frame->data[2];
> -rawimg->stride[AOM_PLANE_U] = frame->linesize[1];
> -
Sorry,
Resolved bug is this:
https://bugs.chromium.org/p/aomedia/issues/detail?id=2639
and we no longer need these lines:
+rawimg->planes[AOM_PLANE_U] = frame->data[0];
+rawimg->planes[AOM_PLANE_V] = frame->data[0];
+rawimg->stride[AOM_PLANE_U] =
On Sat, May 9, 2020 at 3:18 PM Hendrik Leppkes wrote:
> On Sat, May 9, 2020 at 2:11 PM Max Dmitrichenko
> wrote:
> >
> > Question about array-textures: are there any confirmation that with any
> > BindFlags combination it is should be possible to create such texture?
> > Most importantly
From: Andriy Gelman
v4l2_receive_frame() uses two packets s->buf_pkt and avpkt. If avpkt
cannot be enqueued, the packet is buffered in s->buf_pkt and enqueued in
the next call. Currently the ownership transfer between the two packets
is not properly handled. A double free occurs if
On Sat, May 9, 2020 at 7:18 PM Max Dmitrichenko wrote:
>
> On Sat, May 9, 2020 at 3:18 PM Hendrik Leppkes wrote:
>
> > On Sat, May 9, 2020 at 2:11 PM Max Dmitrichenko
> > wrote:
> > >
> > > Question about array-textures: are there any confirmation that with any
> > > BindFlags combination it is
On Sat, May 9, 2020 at 7:41 PM Soft Works wrote:
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Hendrik Leppkes
> > Sent: Saturday, May 9, 2020 9:08 AM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH v4
On Sat, May 9, 2020 at 2:11 PM Max Dmitrichenko wrote:
>
> Question about array-textures: are there any confirmation that with any
> BindFlags combination it is should be possible to create such texture?
> Most importantly D3D11_BIND_RENDER_TARGET.
>
More interestingly, is there any evidence
single: Single-track
track{0,1}: Dual-track
trunc-t1: Truncated track 1
trunc-t2-track{0,1}: Fully-truncated track 2
trunc-t2a-track{0,1}: Partially-truncated track 2
trunc-h2: Truncated track 2 header
Signed-off-by: Zane van Iperen
---
Andreas Rheinhardt:
> Andreas Rheinhardt:
>> When the Ogg muxer writes a page, it has to do three things: It needs to
>> write a page header, then it has to actually copy the page data and then
>> it has to calculate and write a CRC checksum of both header as well as
>> data at a certain position
On Thu, 07. May 09:18, Lukas Rusak wrote:
> There is no reason to enforce a high minimum. In the context
> of streaming only a few output buffers and capture buffers
> are even needed for continuous playback. This also helps
> alleviate memory pressure when decoding 4K media.
> ---
>
On Sat, May 9, 2020 at 2:12 AM Soft Works wrote:
>
> > From: ffmpeg-devel On Behalf Of
> > Hendrik Leppkes
> > Sent: Friday, May 8, 2020 10:27 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va:
On Sat, May 9, 2020 at 9:07 AM Hendrik Leppkes wrote:
>
> On Sat, May 9, 2020 at 2:12 AM Soft Works wrote:
> >
> > > From: ffmpeg-devel On Behalf Of
> > > Hendrik Leppkes
> > > Sent: Friday, May 8, 2020 10:27 PM
> > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org>
> > >
On Tue, Mar 31, 2020 at 10:03:08AM +0200, Matthieu Bouron wrote:
> ---
> libavcodec/mediacodecdec_common.c | 100 ++
> 1 file changed, 100 insertions(+)
>
> diff --git a/libavcodec/mediacodecdec_common.c
> b/libavcodec/mediacodecdec_common.c
> index
Signed-off-by: Zhao, Gang
---
libavdevice/avdevice.c | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git libavdevice/avdevice.c libavdevice/avdevice.c
index 3d03d89f04..8c1b296d71 100644
--- libavdevice/avdevice.c
+++ libavdevice/avdevice.c
@@
Signed-off-by: Zhao, Gang
---
libavformat/allformats.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git libavformat/allformats.c libavformat/allformats.c
index 3919c9e4c1..47cf885699 100644
--- libavformat/allformats.c
+++ libavformat/allformats.c
@@ -520,7 +520,7 @@ const
Signed-off-by: Zhao, Gang
---
libavformat/options.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git libavformat/options.c libavformat/options.c
index e14510504f..cec6ee3621 100644
--- libavformat/options.c
+++ libavformat/options.c
@@ -55,26 +55,28 @@ static void
Disable deprecation declarations compile warning when we really need
to call these deprecated functions.
Signed-off-by: Zhao, Gang
---
Changes from v1:
Removed unnecessary #if check
libavcodec/encode.c | 2 ++
libavcodec/frame_thread_encoder.c | 2 ++
2 files changed, 4
65 matches
Mail list logo
