On Tue, Oct 19, 2021 at 7:07 AM Soft Works wrote:
>
>
> > -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 whe
> -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 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: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, S
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
O
> -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 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 | 2
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
> >>> thi
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 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
>
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, &cupkt)
failed -> CUDA_ERROR_UNKNOWN: unknown error
Error while decoding stream #0:0: Generic error in a
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
+++ b/fftools
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 w
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
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 l
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
^ presumably
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 envir
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(-)
d
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 +-
libavformat/avide
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
---
libavcodec/libaomenc.c | 2 +-
libavcodec/libvpxenc.c | 4 ++--
libavcodec/libx264.c | 2 +-
libavcodec/libx265.c | 2 +-
libavcodec/mjpegdec.c | 2 +-
5 files chang
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
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 0604
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(-)
d
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 +-
libavformat/avide
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
---
libavcodec/libaomenc.c | 2 +-
libavcodec/libvpxenc.c | 4 ++--
libavcodec/libx264.c | 2 +-
libavcodec/libx265.c | 2 +-
libavcodec/mjpegdec.c | 2 +-
5 files chang
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
---
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 b6cfa6bd36..7c44009a24
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
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".
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 clos
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".
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 ++
---
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
@@ -5
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 t
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
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 ++
liba
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 pr
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 u
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 t
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
--- a/libavcode
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 accordanc
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
ffmpeg-devel-requ...@ffmpeg.o
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:
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 AVPixelForm
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 ins
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
50 matches
Mail list logo
