Will apply soon.
___
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".
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Gyan Doshi
> Sent: Tuesday, October 19, 2021 6:01 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg: exit
> application when decoding returns AVERROR_EXIT
>
>
>
> On 2021-10-19 04:54 am,
On 2021-10-19 09:38 am, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Gyan Doshi
Sent: Tuesday, October 19, 2021 6:01 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg: exit
application when decoding returns AVERROR_EXIT
On 2021-10-19 04:54 am, Soft Works wrote:
Introduce a way for decoders to request application exit via error return
Why? The ffmpeg app may be processing multiple inputs and outputs. At
most, you can close the codec and end the stream.
Signed-off-by: softworkz
---
fftools/ffmpeg.c |
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Gyan Doshi
> Sent: Tuesday, October 19, 2021 6:21 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg: exit
> application when decoding returns AVERROR_EXIT
>
>
>
> On 2021-10-19 09:38 am,
On 2021-10-19 10:11 am, Soft Works wrote:
Maybe there's a better way than my patch, but what happens is
a bug IMO, and I wouldn't say that it would be a fix to say that
a certain option needs to be set by the user to "fix it".
What's ideally required is for user to designate essential and
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Gyan Doshi
> Sent: Tuesday, October 19, 2021 6:51 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg: exit
> application when decoding returns AVERROR_EXIT
>
>
>
> On 2021-10-19 10:11 am,
On Mon, Oct 18, 2021 at 6:58 AM Brad Hards wrote:
> If possible, I'd like a review on
>
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210806091633.2083-1-br...@frogmouth.net/[1]
>
> Its been a couple of months, and I haven't got any feedback.
>
> The patch isn't very invasive, and is
On Tuesday, 19 October 2021 9:53:50 AM AEDT James Almer wrote:
> On 10/18/2021 7:38 PM, James Almer wrote:
> > On 10/18/2021 7:34 PM, Derek Buitenhuis wrote:
> >> On 10/18/2021 11:05 PM, Michael Niedermayer wrote:
> >>> This code breaks bitexact mode for some files, i have not looked into
> >>>
Signed-off-by: softworkz
---
doc/ffprobe.xsd | 3 +++
fftools/ffprobe.c | 4
2 files changed, 7 insertions(+)
diff --git a/doc/ffprobe.xsd b/doc/ffprobe.xsd
index b65e54dbef..d0cddd6130 100644
--- a/doc/ffprobe.xsd
+++ b/doc/ffprobe.xsd
@@ -258,6 +258,9 @@
+
+
On Tuesday, 19 October 2021 3:29:20 AM AEDT Paul B Mahol wrote:
> On Mon, Oct 18, 2021 at 6:58 AM Brad Hards wrote:
> > The patch isn't very invasive, and is closely based on previous nv and
> > x265 patches.
>
> You mean the one LGTMed by Derek?
Derek previously LGTM'd the x265 one, and has now
Treat values returned from av_dict_get() as const, since they are internal to
AVDictionary.
Signed-off-by: Chad Fraleigh
---
libavformat/aiffenc.c | 2 +-
libavformat/apetag.c| 2 +-
libavformat/asfenc.c| 8 +++
libavformat/au.c| 2 +-
Treat values returned from av_dict_get() as const, since they are internal to
AVDictionary.
Signed-off-by: Chad Fraleigh
---
libavfilter/avfilter.c | 2 +-
libavfilter/f_bench.c | 2 +-
libavfilter/f_drawgraph.c | 2 +-
libavfilter/f_metadata.c| 2 +-
libavfilter/f_select.c
Treat values returned from av_dict_get() as const, since they are internal to
AVDictionary.
Signed-off-by: Chad Fraleigh
---
libavutil/hwcontext_qsv.c| 2 +-
libavutil/hwcontext_vulkan.c | 6 +++---
libavutil/opt.c | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
Treat values returned from av_dict_get() as const, since they are internal to
AVDictionary.
Signed-off-by: Chad Fraleigh
---
libavcodec/libaomenc.c | 2 +-
libavcodec/libvpxenc.c | 4 ++--
libavcodec/libx264.c | 2 +-
libavcodec/libx265.c | 2 +-
libavcodec/mjpegdec.c | 2 +-
5 files
Without this patch, the full build path gets embedded into various
binaries shipped in the package, for example, libavfilter.a contains
a reference to:
#line 1 "/build/1st/ffmpeg-4.3.2/libavfilter/opencl/avgblur.cl"
By not embedding the build path, it makes it easier to recreate the
build
Treat values returned from av_dict_get() as const, since they are internal to
AVDictionary.
Signed-off-by: Chad Fraleigh
---
libavformat/aiffenc.c | 2 +-
libavformat/apetag.c| 2 +-
libavformat/asfenc.c| 8 +++
libavformat/au.c| 2 +-
Treat values returned from av_dict_get() as const, since they are internal to
AVDictionary.
Signed-off-by: Chad Fraleigh
---
fftools/cmdutils.c | 2 +-
fftools/ffmpeg.c| 6 +++---
fftools/ffmpeg_filter.c | 6 +++---
fftools/ffmpeg_opt.c| 8
fftools/ffplay.c| 8
Treat values returned from av_dict_get() as const, since they are internal to
AVDictionary.
Signed-off-by: Chad Fraleigh
---
libavfilter/avfilter.c | 2 +-
libavfilter/f_bench.c | 2 +-
libavfilter/f_drawgraph.c | 2 +-
libavfilter/f_metadata.c| 2 +-
libavfilter/f_select.c
Treat values returned from av_dict_get() as const, since they are internal to
AVDictionary.
Signed-off-by: Chad Fraleigh
---
doc/examples/metadata.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/examples/metadata.c b/doc/examples/metadata.c
index
Treat values returned from av_dict_get() as const, since they are internal to
AVDictionary.
Signed-off-by: Chad Fraleigh
---
libavutil/hwcontext_qsv.c| 2 +-
libavutil/hwcontext_vulkan.c | 6 +++---
libavutil/opt.c | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
Treat values returned from av_dict_get() as const, since they are internal to
AVDictionary.
Signed-off-by: Chad Fraleigh
---
libavcodec/libaomenc.c | 2 +-
libavcodec/libvpxenc.c | 4 ++--
libavcodec/libx264.c | 2 +-
libavcodec/libx265.c | 2 +-
libavcodec/mjpegdec.c | 2 +-
5 files
Treat values returned from av_dict_get() as const, since they are internal to
AVDictionary.
Signed-off-by: Chad Fraleigh
---
fftools/cmdutils.c | 2 +-
fftools/ffmpeg.c| 6 +++---
fftools/ffmpeg_filter.c | 6 +++---
fftools/ffmpeg_opt.c| 8
fftools/ffplay.c| 8
On 10/18/2021 11:05 PM, Michael Niedermayer wrote:
> This code breaks bitexact mode for some files, i have not looked into this
> any deeper yet.
[23:18] <@jamrial_> Daemon404: that libx264 patch conflicts with the closed
caption code. it overwrites the extra_sei struct and leaks it
^
Thanks for taking your time to review
On Mon, Oct 18, 2021 at 5:16 PM Paul B Mahol wrote:
> LGTM, will apply soon
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit
On 10/18/2021 7:34 PM, Derek Buitenhuis wrote:
On 10/18/2021 11:05 PM, Michael Niedermayer wrote:
This code breaks bitexact mode for some files, i have not looked into this
any deeper yet.
[23:18] <@jamrial_> Daemon404: that libx264 patch conflicts with the closed
caption code. it overwrites
Introduce a way for decoders to request application exit via error return
Signed-off-by: softworkz
---
fftools/ffmpeg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 9d4f9d7a2b..dbbe670a0a 100644
--- a/fftools/ffmpeg.c
+++
We've seen a case where an error from cuvid api is ending up in
an endless loop, creating a log file of > 10 GB like this:
[h264_cuvid @ 0xda1b40] ctx->cvdl->cuvidParseVideoData(ctx->cuparser, )
failed -> CUDA_ERROR_UNKNOWN: unknown error
Error while decoding stream #0:0: Generic error in an
Hi
On Mon, Oct 18, 2021 at 12:15:11PM +, Brad Hards wrote:
> ffmpeg | branch: master | Brad Hards | Fri Aug 6
> 19:16:33 2021 +1000| [7c08cad280a16b346c0a5e0efdfd8333ec54f095] | committer:
> Derek Buitenhuis
>
> libavcodec/libx264: add user data unregistered SEI encoding
>
> MISB ST
On 10/18/2021 7:38 PM, James Almer wrote:
On 10/18/2021 7:34 PM, Derek Buitenhuis wrote:
On 10/18/2021 11:05 PM, Michael Niedermayer wrote:
This code breaks bitexact mode for some files, i have not looked into
this
any deeper yet.
[23:18] <@jamrial_> Daemon404: that libx264 patch conflicts
On Tue, Oct 19, 2021 at 12:05:19AM +0200, Michael Niedermayer wrote:
> Hi
>
> On Mon, Oct 18, 2021 at 12:15:11PM +, Brad Hards wrote:
> > ffmpeg | branch: master | Brad Hards | Fri Aug 6
> > 19:16:33 2021 +1000| [7c08cad280a16b346c0a5e0efdfd8333ec54f095] |
> > committer: Derek Buitenhuis
From: KM
---
libavfilter/vf_eq.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/libavfilter/vf_eq.c b/libavfilter/vf_eq.c
index 4a0d85e8e5..80ab21efb3 100644
--- a/libavfilter/vf_eq.c
+++ b/libavfilter/vf_eq.c
@@ -236,9 +236,9 @@ static const enum
On Fri, 3 Sep 2021, Martin Storsjö wrote:
This gives rather big speedups on these functions:
Before:
put_h264_qpel_8_mc01_8_neon: 241.0 131.5 138.7
put_h264_qpel_8_mc02_8_neon: 214.7 121.2 127.5
put_h264_qpel_8_mc03_8_neon: 242.5 131.2 135.7
put_h264_qpel_8_mc11_8_neon:
On Mon, 18 Oct 2021, Paul B Mahol wrote:
lgtm
Thanks, pushed.
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
On Sat, 16 Oct 2021, J. Dekker wrote:
This reverts commit 2589060b92eeeb944c6e2b50e38412c0c5fabcf4.
Signed-off-by: J. Dekker
---
libavcodec/arm/hevcdsp_qpel_neon.S | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
Ok, once commit 1/2 is finalized. But it would be good
Such fields can be seen as generally useful in cases where the
API user is not implementing custom AVIO callbacks, but still would
like to know if data is being read or written out, such as in case
data is being read from input but no AVPacket has been received yet.
---
doc/APIchanges
Originally added as a private entry in commit
3f75e5116b900f1428aa13041fc7d6301bf1988a, but its grouping with
the comment noting its private state was missed during merging of
the field from Libav (most likely due to an already existing field
in between).
---
doc/APIchanges| 6 ++
Looking at 3f75e5116b900f1428aa13041fc7d6301bf1988a, the field
was supposed to be private, but during merging the field and the
group that had the comment about it got separated.
Thus, move the actual privately utilized state of this variable
into the private FFIOContext. Additionally, name the
Changes compared to v2:
* Written was actually written_size, so it did not take into account any
writes after a seek-back. Thus an initial attempt at implementing
bytes_written was made.
After a brief discussion with Michael on IRC, this seems to be the idea of a
path forward that was agreed
On 8/6/2021 10:16 AM, Brad Hards wrote:
> MISB ST 0604 and ST 2101 require user data unregistered SEI messages
> (precision timestamps and sensor identifiers) to be included. That
> currently isn't supported for libx264. This patch adds support
> for user data unregistered SEI messages in
On Sat, 16 Oct 2021, J. Dekker wrote:
Signed-off-by: J. Dekker
---
libavcodec/arm/hevcdsp_init_neon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/arm/hevcdsp_init_neon.c
b/libavcodec/arm/hevcdsp_init_neon.c
index 201a088dac..112edb5edd 100644
---
lgtm
___
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".
Passing an uninitialized variable as argument to a function is
undefined behaviour (UB). The compiler can assume that UB does not
happen.
Hence, the compiler can assume that the variables are never
uninitialized when passed as argument, which means that the codepaths
that initializes them must be
Signed-off-by: Paul B Mahol
---
libavfilter/Makefile | 2 +
libavfilter/allfilters.c | 1 +
libavfilter/opencl/v360.cl | 375 +
libavfilter/opencl_source.h | 1 +
libavfilter/vf_v360_opencl.c | 762 +++
5 files changed, 1141
On Sun, Oct 17, 2021 at 05:48:40PM -0300, James Almer wrote:
> On 10/17/2021 5:03 PM, Michael Niedermayer wrote:
> > It seems no actively maintained distribution is using 4.0 anymore
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > src/download| 37
Hi,
Sorry for the slow reply.
On 10/12/2021 8:18 PM, Michael Niedermayer wrote:
> i was thinking of something like
> st->codecpar->bit_rate = av_rescale(sc->data_size, c->time_scale * 8LL,
> st->duration);
>
> because i thought that would fix the overflow
> but i didnt look beyond the code in
---
libavformat/mxf.h| 1 +
libavformat/mxfdec.c | 283 ++-
2 files changed, 278 insertions(+), 6 deletions(-)
diff --git a/libavformat/mxf.h b/libavformat/mxf.h
index fe9c52732c..cddbcb13c9 100644
--- a/libavformat/mxf.h
+++ b/libavformat/mxf.h
@@
On Wed, Oct 13, 2021 at 6:15 PM Mattias Wadman
wrote:
> Reduces the risk of finding false frames that happens to have valid values
> and CRC.
>
> Fixes ticket #9185 ffmpeg flac decoder incorrectly finds junk frame
> https://trac.ffmpeg.org/ticket/9185
> ---
> libavcodec/flac_parser.c | 30
LGTM, will apply soon
___
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".
49 matches
Mail list logo
