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>
> > > Su
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 f0752fa6261..404ed
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 AV
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 insertions
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
@@ -83,16
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 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 that
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
---
tests/fate
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 i
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 write_header(AVFormat
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 cas
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.
>>
>> Sign
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];
> -
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
>>> rgb24ToY_c
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: A
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] = frame->linesi
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
ff_v4l2_contex
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 D3D11_B
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
ff_v4l2_contex
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 alloc
> -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 t
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 03/11
> -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 array-textures:
> -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 t
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 few
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
+++ b/libavformat
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
@@ -249
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 @@ static
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 i
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 03/11]
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 o
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 deletion
> -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 information
> -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 information
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 03/
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 03/
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 a
> -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 information
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 splitt
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: continuous
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
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpe
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: 9FF2128B147EF67
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
> https://
> 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 5695c6
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 03/11]
> -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 the
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(-)
>>>
>>> diff
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 i
> 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 100
> 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
> --- a/libavformat/h
> 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 initialization
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 -
tests/ref/fate/exr-rgb-b44a
> 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 misle
> 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 p
> 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 5517cb4354..d
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 b/libavfilter/vf_sign
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
> http://samples.ffmpeg.org/archive/all/unknown+unknown+unknown+unknown+5029_paramount_en_
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 sa
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".
65 matches
Mail list logo