[FFmpeg-devel] [PATCH 1/3] avformat/dashenc: enabling streaming automatically for ldash

2021-10-21 Thread Zhao Zhili 
There is a little chance that user specified contradicted options
like -streaming 0 -ldash 1, however, it's more likely that user
didn't know or forgot to enable streaming for ldash. So enabling
streaming automatically to make the feature easier to use, similar
like enable FF_MOV_FLAG_FRAGMENT/EMPTY_MOOV/DEFAULT_BASE_MOOF and
so on for FF_MOV_FLAG_CMAF.
---
 libavformat/dashenc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 06bbf36c95..0370a482fb 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1406,8 +1406,8 @@ static int dash_init(AVFormatContext *s)
 }
 
 if (c->ldash && !c->streaming) {
-av_log(s, AV_LOG_WARNING, "LDash option will be ignored as streaming 
is not enabled\n");
-c->ldash = 0;
+av_log(s, AV_LOG_WARNING, "Enabling streaming as LDash is enabled\n");
+c->streaming = 1;
 }
 
 if (c->target_latency && !c->streaming) {
-- 
2.31.1

___
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".

[FFmpeg-devel] [PATCH 2/3] avformat/dashenc: enabling streaming and hls_playlist for lhls

2021-10-21 Thread Zhao Zhili 
Try to make the feature easier to use, especially since the user
have enabled -strict experimental manually. The user shouldn't
be surprised that hls_playlist is enabled for lhls automatically,
so change the log level from warning to info for that.
---
 doc/muxers.texi   | 2 +-
 libavformat/dashenc.c | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 7338e8d5d3..67c281d171 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -365,7 +365,7 @@ Enable Low-latency HLS(LHLS). Adds #EXT-X-PREFETCH tag with 
current segment's UR
 Apple doesn't have an official spec for LHLS. Meanwhile hls.js player folks are
 trying to standardize a open LHLS spec. The draft spec is available in 
https://github.com/video-dev/hlsjs-rfcs/blob/lhls-spec/proposals/0001-lhls.md
 This option will also try to comply with the above open spec, till Apple's 
spec officially supports it.
-Applicable only when @var{streaming} and @var{hls_playlist} options are 
enabled.
+Enabling @var{streaming} and @var{hls_playlist} options automatically.
 This is an experimental feature.
 
 @item ldash @var{ldash}
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 0370a482fb..0c5aaa7b5b 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1396,13 +1396,13 @@ static int dash_init(AVFormatContext *s)
 }
 
 if (c->lhls && !c->streaming) {
-av_log(s, AV_LOG_WARNING, "LHLS option will be ignored as streaming is 
not enabled\n");
-c->lhls = 0;
+av_log(s, AV_LOG_WARNING, "Enabling streaming as LHLS is enabled\n");
+c->streaming = 1;
 }
 
 if (c->lhls && !c->hls_playlist) {
-av_log(s, AV_LOG_WARNING, "LHLS option will be ignored as hls_playlist 
is not enabled\n");
-c->lhls = 0;
+av_log(s, AV_LOG_INFO, "Enabling hls_playlist as LHLS is enabled\n");
+c->hls_playlist = 1;
 }
 
 if (c->ldash && !c->streaming) {
-- 
2.31.1

___
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".

[FFmpeg-devel] [PATCH 3/3] doc/muxers: note on Apple's version LHLS for lhls option

2021-10-21 Thread Zhao Zhili 
---
 doc/muxers.texi | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 67c281d171..a24b09a387 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -362,12 +362,13 @@ Ignore IO errors during open and write. Useful for 
long-duration runs with netwo
 
 @item lhls @var{lhls}
 Enable Low-latency HLS(LHLS). Adds #EXT-X-PREFETCH tag with current segment's 
URI.
-Apple doesn't have an official spec for LHLS. Meanwhile hls.js player folks are
-trying to standardize a open LHLS spec. The draft spec is available in 
https://github.com/video-dev/hlsjs-rfcs/blob/lhls-spec/proposals/0001-lhls.md
-This option will also try to comply with the above open spec, till Apple's 
spec officially supports it.
+hls.js player folks are trying to standardize an open LHLS spec. The draft 
spec is available in 
https://github.com/video-dev/hlsjs-rfcs/blob/lhls-spec/proposals/0001-lhls.md
+This option try to comply with the above open spec.
 Enabling @var{streaming} and @var{hls_playlist} options automatically.
 This is an experimental feature.
 
+Note: This is not Apple's version LHLS. See 
@url{https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis}
+
 @item ldash @var{ldash}
 Enable Low-latency Dash by constraining the presence and values of some 
elements.
 
-- 
2.31.1

___
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".

Re: [FFmpeg-devel] [PATCH v1] libavcodec/flac_parser: Validate subframe zero bit and type

2021-10-21 Thread Mattias Wadman 
On Wed, Oct 20, 2021 at 11:07 PM Michael Niedermayer 
wrote:

> On Wed, Oct 13, 2021 at 06:15:26PM +0200, 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 --
> >  1 file changed, 28 insertions(+), 2 deletions(-)
>
> After this was applied out of array accesses appeared
>
> tools/target_dem_flac_fuzzer: Running 1 inputs 1 time(s) each.
> Running:
> libfuzz-repro/40109/clusterfuzz-testcase-minimized-ffmpeg_dem_FLAC_fuzzer-4805686811295744
> =
> ==30399==ERROR: AddressSanitizer: heap-buffer-overflow on address
> 0x63352800 at pc 0x01734048 bp 0x7ffd3598d090 sp 0x7ffd3598d088
> READ of size 4 at 0x63352800 thread T0
> #0 0x1734047 in get_bits libavcodec/get_bits.h:404:5
> #1 0x1734047 in frame_header_is_valid libavcodec/flac_parser.c:118
> #2 0x173ac77 in find_headers_search_validate
> libavcodec/flac_parser.c:202:9
> #3 0x173a851 in find_headers_search libavcodec/flac_parser.c:248:31
> #4 0x172f29b in find_new_headers libavcodec/flac_parser.c:268:18
> #5 0x172f29b in flac_parse libavcodec/flac_parser.c:666
> #6 0x13fb138 in av_parser_parse2 libavcodec/parser.c:165:13
> #7 0x6f1dba in parse_packet libavformat/demux.c:1127:15
> #8 0x6befe7 in read_frame_internal libavformat/demux.c:1322:24
> #9 0x6bafca in av_read_frame libavformat/demux.c:1426:17
> #10 0x4c7832 in LLVMFuzzerTestOneInput tools/target_dem_fuzzer.c:197:15
> #11 0x27055bd in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*,
> unsigned long) Fuzzer/build/../FuzzerLoop.cpp:495:13
> #12 0x26fa192 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*,
> unsigned long) Fuzzer/build/../FuzzerDriver.cpp:273:6
> #13 0x26ff391 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned
> char const*, unsigned long)) Fuzzer/build/../FuzzerDriver.cpp:690:9
> #14 0x26f9e70 in main Fuzzer/build/../FuzzerMain.cpp:20:10
> #15 0x7f5d338b8bf6 in __libc_start_main
> /build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:310
> #16 0x41fb79 in _start (tools/target_dem_flac_fuzzer+0x41fb79)
>
> 0x63352800 is located 0 bytes to the right of 106496-byte region
> [0x63338800,0x63352800)
> allocated by thread T0 here:
> #0 0x498597 in posix_memalign
> /b/swarming/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/asan/asan_malloc_linux.cc:226:3
> #1 0x26112c8 in av_malloc libavutil/mem.c:104:9
> #2 0x25a67b3 in av_fifo_alloc_array libavutil/fifo.c:51:20
> #3 0x172c9b6 in flac_parse_init libavcodec/flac_parser.c:747:21
> #4 0x13f7d67 in av_parser_init libavcodec/parser.c:67:15
> #5 0x6ce0b8 in avformat_find_stream_info libavformat/demux.c:2453:27
> #6 0x4c77d0 in LLVMFuzzerTestOneInput tools/target_dem_fuzzer.c:192:11
> #7 0x27055bd in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*,
> unsigned long) Fuzzer/build/../FuzzerLoop.cpp:495:13
> #8 0x26fa192 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*,
> unsigned long) Fuzzer/build/../FuzzerDriver.cpp:273:6
> #9 0x26ff391 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned
> char const*, unsigned long)) Fuzzer/build/../FuzzerDriver.cpp:690:9
> #10 0x26f9e70 in main Fuzzer/build/../FuzzerMain.cpp:20:10
> #11 0x7f5d338b8bf6 in __libc_start_main
> /build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:310
>
> SUMMARY: AddressSanitizer: heap-buffer-overflow
> libavcodec/get_bits.h:404:5 in get_bits
> Shadow bytes around the buggy address:
>   0x0c66800024b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c66800024c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c66800024d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c66800024e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c66800024f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x0c6680002500:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c6680002510: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c6680002520: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c6680002530: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c6680002540: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c6680002550: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:   00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:   fa
>   Freed heap region:   fd
>   Stack left redzone:  f1
>   Stack mid redzone:   f2
>   Stack right redzone: f3
>   Stack after return:  f5
>   Stack use after scope:   f8
>   Global redzone:  f9
>   Global init order:   f6
>   Poisoned by user:f7
>   Container overflow:  fc
>   Ar

[FFmpeg-devel] [PATCH] avutil: deprecate AVRational field inside AVOption::default_val

2021-10-21 Thread Zhao Zhili 
It's not being used. For backward compatibility, AV_OPT_TYPE_RATIONAL
cannot be changed to use it.
---
 libavutil/opt.h | 2 ++
 libavutil/version.h | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/libavutil/opt.h b/libavutil/opt.h
index 2820435eec..bf1a8b84fa 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -267,8 +267,10 @@ typedef struct AVOption {
 int64_t i64;
 double dbl;
 const char *str;
+#if FF_API_AVOPTION_AVRATIONAL
 /* TODO those are unused now */
 AVRational q;
+#endif
 } default_val;
 double min; ///< minimum valid value for the option
 double max; ///< maximum valid value for the option
diff --git a/libavutil/version.h b/libavutil/version.h
index 896e348d80..4faea0cfcb 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -117,6 +117,9 @@
 #ifndef FF_API_AV_MALLOCZ_ARRAY
 #define FF_API_AV_MALLOCZ_ARRAY (LIBAVUTIL_VERSION_MAJOR < 58)
 #endif
+#ifndef FF_API_AVOPTION_AVRATIONAL
+#define FF_API_AVOPTION_AVRATIONAL  (LIBAVUTIL_VERSION_MAJOR < 58)
+#endif
 
 /**
  * @}
-- 
2.31.1

___
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".

Re: [FFmpeg-devel] [PATCH v1] libavcodec/flac_parser: Validate subframe zero bit and type

2021-10-21 Thread Michael Niedermayer 
On Thu, Oct 21, 2021 at 10:46:18AM +0200, Mattias Wadman wrote:
> On Wed, Oct 20, 2021 at 11:07 PM Michael Niedermayer 
> wrote:
> 
> > On Wed, Oct 13, 2021 at 06:15:26PM +0200, 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 --
> > >  1 file changed, 28 insertions(+), 2 deletions(-)
> >
> > After this was applied out of array accesses appeared
> >
> > tools/target_dem_flac_fuzzer: Running 1 inputs 1 time(s) each.
> > Running:
> > libfuzz-repro/40109/clusterfuzz-testcase-minimized-ffmpeg_dem_FLAC_fuzzer-4805686811295744
> > =
> > ==30399==ERROR: AddressSanitizer: heap-buffer-overflow on address
> > 0x63352800 at pc 0x01734048 bp 0x7ffd3598d090 sp 0x7ffd3598d088
> > READ of size 4 at 0x63352800 thread T0
> > #0 0x1734047 in get_bits libavcodec/get_bits.h:404:5
> > #1 0x1734047 in frame_header_is_valid libavcodec/flac_parser.c:118
> > #2 0x173ac77 in find_headers_search_validate
> > libavcodec/flac_parser.c:202:9
> > #3 0x173a851 in find_headers_search libavcodec/flac_parser.c:248:31
> > #4 0x172f29b in find_new_headers libavcodec/flac_parser.c:268:18
> > #5 0x172f29b in flac_parse libavcodec/flac_parser.c:666
> > #6 0x13fb138 in av_parser_parse2 libavcodec/parser.c:165:13
> > #7 0x6f1dba in parse_packet libavformat/demux.c:1127:15
> > #8 0x6befe7 in read_frame_internal libavformat/demux.c:1322:24
> > #9 0x6bafca in av_read_frame libavformat/demux.c:1426:17
> > #10 0x4c7832 in LLVMFuzzerTestOneInput tools/target_dem_fuzzer.c:197:15
> > #11 0x27055bd in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*,
> > unsigned long) Fuzzer/build/../FuzzerLoop.cpp:495:13
> > #12 0x26fa192 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*,
> > unsigned long) Fuzzer/build/../FuzzerDriver.cpp:273:6
> > #13 0x26ff391 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned
> > char const*, unsigned long)) Fuzzer/build/../FuzzerDriver.cpp:690:9
> > #14 0x26f9e70 in main Fuzzer/build/../FuzzerMain.cpp:20:10
> > #15 0x7f5d338b8bf6 in __libc_start_main
> > /build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:310
> > #16 0x41fb79 in _start (tools/target_dem_flac_fuzzer+0x41fb79)
> >
> > 0x63352800 is located 0 bytes to the right of 106496-byte region
> > [0x63338800,0x63352800)
> > allocated by thread T0 here:
> > #0 0x498597 in posix_memalign
> > /b/swarming/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/asan/asan_malloc_linux.cc:226:3
> > #1 0x26112c8 in av_malloc libavutil/mem.c:104:9
> > #2 0x25a67b3 in av_fifo_alloc_array libavutil/fifo.c:51:20
> > #3 0x172c9b6 in flac_parse_init libavcodec/flac_parser.c:747:21
> > #4 0x13f7d67 in av_parser_init libavcodec/parser.c:67:15
> > #5 0x6ce0b8 in avformat_find_stream_info libavformat/demux.c:2453:27
> > #6 0x4c77d0 in LLVMFuzzerTestOneInput tools/target_dem_fuzzer.c:192:11
> > #7 0x27055bd in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*,
> > unsigned long) Fuzzer/build/../FuzzerLoop.cpp:495:13
> > #8 0x26fa192 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*,
> > unsigned long) Fuzzer/build/../FuzzerDriver.cpp:273:6
> > #9 0x26ff391 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned
> > char const*, unsigned long)) Fuzzer/build/../FuzzerDriver.cpp:690:9
> > #10 0x26f9e70 in main Fuzzer/build/../FuzzerMain.cpp:20:10
> > #11 0x7f5d338b8bf6 in __libc_start_main
> > /build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:310
> >
> > SUMMARY: AddressSanitizer: heap-buffer-overflow
> > libavcodec/get_bits.h:404:5 in get_bits
> > Shadow bytes around the buggy address:
> >   0x0c66800024b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >   0x0c66800024c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >   0x0c66800024d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >   0x0c66800024e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >   0x0c66800024f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > =>0x0c6680002500:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> >   0x0c6680002510: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> >   0x0c6680002520: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> >   0x0c6680002530: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> >   0x0c6680002540: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> >   0x0c6680002550: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> > Shadow byte legend (one shadow byte represents 8 application bytes):
> >   Addressable:   00
> >   Partially addressable: 01 02 03 04 05 06 07
> >   Heap left redzone:   fa
> >   Freed heap region:   fd
> >   Stack left redzone:  f1
> >   Stack mid redzone:

Re: [FFmpeg-devel] [PATCH v1] libavcodec/flac_parser: Validate subframe zero bit and type

2021-10-21 Thread Michael Niedermayer 
On Thu, Oct 21, 2021 at 01:00:20PM +0200, Michael Niedermayer wrote:
> On Thu, Oct 21, 2021 at 10:46:18AM +0200, Mattias Wadman wrote:
> > On Wed, Oct 20, 2021 at 11:07 PM Michael Niedermayer 
> > 
> > wrote:
> > 
> > > On Wed, Oct 13, 2021 at 06:15:26PM +0200, 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 --
> > > >  1 file changed, 28 insertions(+), 2 deletions(-)
> > >
> > > After this was applied out of array accesses appeared
> > >
> > > tools/target_dem_flac_fuzzer: Running 1 inputs 1 time(s) each.
> > > Running:
> > > libfuzz-repro/40109/clusterfuzz-testcase-minimized-ffmpeg_dem_FLAC_fuzzer-4805686811295744
> > > =
> > > ==30399==ERROR: AddressSanitizer: heap-buffer-overflow on address
> > > 0x63352800 at pc 0x01734048 bp 0x7ffd3598d090 sp 0x7ffd3598d088
> > > READ of size 4 at 0x63352800 thread T0
> > > #0 0x1734047 in get_bits libavcodec/get_bits.h:404:5
> > > #1 0x1734047 in frame_header_is_valid libavcodec/flac_parser.c:118
> > > #2 0x173ac77 in find_headers_search_validate
> > > libavcodec/flac_parser.c:202:9
> > > #3 0x173a851 in find_headers_search libavcodec/flac_parser.c:248:31
> > > #4 0x172f29b in find_new_headers libavcodec/flac_parser.c:268:18
> > > #5 0x172f29b in flac_parse libavcodec/flac_parser.c:666
> > > #6 0x13fb138 in av_parser_parse2 libavcodec/parser.c:165:13
> > > #7 0x6f1dba in parse_packet libavformat/demux.c:1127:15
> > > #8 0x6befe7 in read_frame_internal libavformat/demux.c:1322:24
> > > #9 0x6bafca in av_read_frame libavformat/demux.c:1426:17
> > > #10 0x4c7832 in LLVMFuzzerTestOneInput 
> > > tools/target_dem_fuzzer.c:197:15
> > > #11 0x27055bd in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*,
> > > unsigned long) Fuzzer/build/../FuzzerLoop.cpp:495:13
> > > #12 0x26fa192 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*,
> > > unsigned long) Fuzzer/build/../FuzzerDriver.cpp:273:6
> > > #13 0x26ff391 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned
> > > char const*, unsigned long)) Fuzzer/build/../FuzzerDriver.cpp:690:9
> > > #14 0x26f9e70 in main Fuzzer/build/../FuzzerMain.cpp:20:10
> > > #15 0x7f5d338b8bf6 in __libc_start_main
> > > /build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:310
> > > #16 0x41fb79 in _start (tools/target_dem_flac_fuzzer+0x41fb79)
> > >
> > > 0x63352800 is located 0 bytes to the right of 106496-byte region
> > > [0x63338800,0x63352800)
> > > allocated by thread T0 here:
> > > #0 0x498597 in posix_memalign
> > > /b/swarming/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/asan/asan_malloc_linux.cc:226:3
> > > #1 0x26112c8 in av_malloc libavutil/mem.c:104:9
> > > #2 0x25a67b3 in av_fifo_alloc_array libavutil/fifo.c:51:20
> > > #3 0x172c9b6 in flac_parse_init libavcodec/flac_parser.c:747:21
> > > #4 0x13f7d67 in av_parser_init libavcodec/parser.c:67:15
> > > #5 0x6ce0b8 in avformat_find_stream_info libavformat/demux.c:2453:27
> > > #6 0x4c77d0 in LLVMFuzzerTestOneInput tools/target_dem_fuzzer.c:192:11
> > > #7 0x27055bd in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*,
> > > unsigned long) Fuzzer/build/../FuzzerLoop.cpp:495:13
> > > #8 0x26fa192 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*,
> > > unsigned long) Fuzzer/build/../FuzzerDriver.cpp:273:6
> > > #9 0x26ff391 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned
> > > char const*, unsigned long)) Fuzzer/build/../FuzzerDriver.cpp:690:9
> > > #10 0x26f9e70 in main Fuzzer/build/../FuzzerMain.cpp:20:10
> > > #11 0x7f5d338b8bf6 in __libc_start_main
> > > /build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:310
> > >
> > > SUMMARY: AddressSanitizer: heap-buffer-overflow
> > > libavcodec/get_bits.h:404:5 in get_bits
> > > Shadow bytes around the buggy address:
> > >   0x0c66800024b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > >   0x0c66800024c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > >   0x0c66800024d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > >   0x0c66800024e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > >   0x0c66800024f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > =>0x0c6680002500:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> > >   0x0c6680002510: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> > >   0x0c6680002520: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> > >   0x0c6680002530: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> > >   0x0c6680002540: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> > >   0x0c6680002550: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> > > Shadow byte legend (one shadow byt

Re: [FFmpeg-devel] [PATCH] avfilter/vf_eq: add support for alpha channel

2021-10-21 Thread Konstantin Mamalakis 
Thanks, I'd rather _not_ have my real name on it

On Wed, 20 Oct 2021 at 15:19, Michael Niedermayer 
wrote:

> On Mon, Oct 18, 2021 at 02:29:48PM +0300, konstan...@boffins.se wrote:
> > 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 AVPixelFormat pixel_fmts_eq[] = {
> >  AV_PIX_FMT_GRAY8,
> >  AV_PIX_FMT_YUV410P,
> >  AV_PIX_FMT_YUV411P,
> > -AV_PIX_FMT_YUV420P,
> > -AV_PIX_FMT_YUV422P,
> > -AV_PIX_FMT_YUV444P,
> > +AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUVA420P,
> > +AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUVA422P,
> > +AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUVA444P,
> >  AV_PIX_FMT_NONE
> >  };
> >
> > @@ -281,12 +281,13 @@ static int filter_frame(AVFilterLink *inlink,
> AVFrame *in)
> >  h = AV_CEIL_RSHIFT(h, desc->log2_chroma_h);
> >  }
> >
> > -if (eq->param[i].adjust)
> > -eq->param[i].adjust(&eq->param[i], out->data[i],
> out->linesize[i],
> > - in->data[i], in->linesize[i], w, h);
> > -else
> > +if (i == 3 || !eq->param[i].adjust)
> >  av_image_copy_plane(out->data[i], out->linesize[i],
> >  in->data[i], in->linesize[i], w, h);
> > +
> > +else
> > +eq->param[i].adjust(&eq->param[i], out->data[i],
> out->linesize[i],
> > + in->data[i], in->linesize[i], w, h);
> >  }
>
> change LGTM
> not sure you want or dont want a real name in the author field but iam
> asking
> as it cannot be changed later ?
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who are best at talking, realize last or never when they are wrong.
> ___
> 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".
>
___
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".

[FFmpeg-devel] [PATCH] avcodec/flac_parser: Consider AV_INPUT_BUFFER_PADDING_SIZE

2021-10-21 Thread Michael Niedermayer 
Fixes: out if array read
Fixes: 
40109/clusterfuzz-testcase-minimized-ffmpeg_dem_FLAC_fuzzer-4805686811295744

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
CC: Mattias Wadman 
Signed-off-by: Michael Niedermayer 
---
 libavcodec/flac_parser.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/flac_parser.c b/libavcodec/flac_parser.c
index 2c550507fc8..61232eed829 100644
--- a/libavcodec/flac_parser.c
+++ b/libavcodec/flac_parser.c
@@ -196,7 +196,7 @@ static int find_headers_search_validate(FLACParseContext 
*fpc, int offset)
 uint8_t *header_buf;
 int size = 0;
 header_buf = flac_fifo_read_wrap(fpc, offset,
- MAX_FRAME_HEADER_SIZE,
+ MAX_FRAME_HEADER_SIZE + 
AV_INPUT_BUFFER_PADDING_SIZE,
  &fpc->wrap_buf,
  &fpc->wrap_buf_allocated_size);
 if (frame_header_is_valid(fpc->avctx, header_buf, &fi)) {
-- 
2.17.1

___
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".

Re: [FFmpeg-devel] [PATCH] avcodec/flac_parser: Consider AV_INPUT_BUFFER_PADDING_SIZE

2021-10-21 Thread Michael Niedermayer 
On Thu, Oct 21, 2021 at 02:00:01PM +0200, Michael Niedermayer wrote:
> Fixes: out if array read
> Fixes: 
> 40109/clusterfuzz-testcase-minimized-ffmpeg_dem_FLAC_fuzzer-4805686811295744
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> CC: Mattias Wadman 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/flac_parser.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Note, iam not sure this is enough, but it fixes this specific sample

a more complete audit/review of the flac parser is maybe not a bad idea
if someone has time

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.


signature.asc
Description: PGP signature
___
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".

Re: [FFmpeg-devel] [PATCH 1/2 v2] avformat/mov: Use av_rescale when calculating bit rate

2021-10-21 Thread Michael Niedermayer 
On Wed, Oct 20, 2021 at 07:43:30PM +0100, Derek Buitenhuis wrote:
> It is less susceptible to overflows.
> 
> Signed-off-by: Derek Buitenhuis 
> ---
>  libavformat/mov.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)

LGTM

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


signature.asc
Description: PGP signature
___
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".

Re: [FFmpeg-devel] [PATCH 2/2] tools/target_dec_fuzzer: Adjust threshold for MXPEG

2021-10-21 Thread Michael Niedermayer 
On Tue, Oct 12, 2021 at 03:07:34PM +0200, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes: 
> 39813/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MXPEG_fuzzer-6010298067189760
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  tools/target_dec_fuzzer.c | 1 +
>  1 file changed, 1 insertion(+)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.


signature.asc
Description: PGP signature
___
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".

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/ttadsp: Fix integer overflows in tta_filter_process_c()

2021-10-21 Thread Michael Niedermayer 
On Fri, Oct 15, 2021 at 12:13:23AM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 822841647 + 1647055738 cannot be represented 
> in type 'int'
> Fixes: 
> 39935/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TTA_fuzzer-4592657142251520
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/ttadsp.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


signature.asc
Description: PGP signature
___
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".

Re: [FFmpeg-devel] [PATCH] avutil/mathematics: Document av_rescale_rnd() behavior on non int64 results

2021-10-21 Thread Michael Niedermayer 
On Wed, Oct 20, 2021 at 07:44:52PM +0100, Derek Buitenhuis wrote:
> On 10/20/2021 7:24 PM, Michael Niedermayer wrote:
> >   * The operation is mathematically equivalent to `a * b / c`, but writing 
> > that
> >   * directly can overflow, and does not support different rounding methods.
> > + * If the result is not representable then INT64_MIN is returned.
> 
> Seems reasonable to me.

will apply

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


signature.asc
Description: PGP signature
___
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".

Re: [FFmpeg-devel] [PATCH] avfilter/vf_eq: add support for alpha channel

2021-10-21 Thread Michael Niedermayer 
On Thu, Oct 21, 2021 at 02:23:37PM +0300, Konstantin Mamalakis wrote:
> Thanks, I'd rather _not_ have my real name on it

ok ill apply the patch as is then

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


signature.asc
Description: PGP signature
___
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".

Re: [FFmpeg-devel] [FFmpeg-cvslog] libavcodec/libx264: add user data unregistered SEI encoding

2021-10-21 Thread Brad Hards 
On Tuesday, 19 October 2021 9:53:50 AM AEDT James Almer wrote:
> > The problem i guess is in the following line:
> > 
> > sei_payload->payload = side_data->data;
> > 
> > Which should be an av_memdup() or similar, because side_data->data is
> > the frame's side data, and by the time the encoder tries to do something
> > with it, it may have been freed.
> > Also, this code should set x4->pic.extra_sei.sei_free to av_free().
> 
> The following should fix it


I've tried to do a similar fix for libx265, but I don't know how to handle
the cleanup.  This is what I have so far:

diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 7dd70a3450..ee27e67af1 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -52,9 +52,6 @@ typedef struct libx265Context {
 char *profile;
 AVDictionary *x265_opts;
 
-void *sei_data;
-int sei_data_size;
-
 /**
  * If the encoder does not support ROI then warn the first time we
  * encounter a frame with ROI side data.
@@ -82,7 +79,6 @@ static av_cold int libx265_encode_close(AVCodecContext *avctx)
 libx265Context *ctx = avctx->priv_data;
 
 ctx->api->param_free(ctx->params);
-av_freep(&ctx->sei_data);
 
 if (ctx->encoder)
 ctx->api->encoder_close(ctx->encoder);
@@ -545,24 +541,30 @@ static int libx265_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt,
 
 for (i = 0; i < pic->nb_side_data; i++) {
 AVFrameSideData *side_data = pic->side_data[i];
+unsigned int sei_data_size = 0;
 void *tmp;
 x265_sei_payload *sei_payload;
 
 if (side_data->type != AV_FRAME_DATA_SEI_UNREGISTERED)
 continue;
 
-tmp = av_fast_realloc(ctx->sei_data,
-  &ctx->sei_data_size,
+tmp = av_fast_realloc(sei->payloads, 
+  &sei_data_size,
   (sei->numPayloads + 1) * 
sizeof(*sei_payload));
 if (!tmp) {
 av_freep(&x265pic.userData);
 av_freep(&x265pic.quantOffsets);
 return AVERROR(ENOMEM);
 }
-ctx->sei_data = tmp;
-sei->payloads = ctx->sei_data;
+sei->payloads = tmp;
+// Don't know how to av_free() sei here...
 sei_payload = &sei->payloads[sei->numPayloads];
-sei_payload->payload = side_data->data;
+sei_payload->payload = av_memdup(side_data->data, side_data->size);
+if (!sei_payload->payload) {
+av_freep(&x265pic.userData);
+av_freep(&x265pic.quantOffsets);
+return AVERROR(ENOMEM);
+}
 sei_payload->payloadSize = side_data->size;
 /* Equal to libx265 USER_DATA_UNREGISTERED */
 sei_payload->payloadType = SEI_TYPE_USER_DATA_UNREGISTERED;
@@ -573,6 +575,7 @@ static int libx265_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt,
 ret = ctx->api->encoder_encode(ctx->encoder, &nal, &nnal,
pic ? &x265pic : NULL, &x265pic_out);
 
+av_freep(&x265pic.userData);
 av_freep(&x265pic.quantOffsets);
 
 if (ret < 0)

Would appreciate any suggestions (or a fix).

Brad


___
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".

[FFmpeg-devel] [PATCH 1/3] avutil: Add Dolby Vision RPU side data type

2021-10-21 Thread Derek Buitenhuis 
Signed-off-by: Derek Buitenhuis 
---
All known encoders, etc. expect RPUs in this format, to my knowledge.
(There is no spec for parsing the RPUs, even privately, and not a single
piece of software that would benefit from that - and it is a legal minefield
which I am not going to touch.)

The comment says "with emulation bytes intact" but technically, RPUs
do not have emulation bytes, since they are not actually NALs, but just
masquerade as them, and as such, encoder APIs expect them to be there.
---
 doc/APIchanges  | 3 +++
 libavutil/frame.c   | 1 +
 libavutil/frame.h   | 7 +++
 libavutil/version.h | 2 +-
 4 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 7b267a79ac..8bc9c7eb6e 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -14,6 +14,9 @@ libavutil: 2021-04-27
 
 API changes, most recent first:
 
+2021-XX-XX - xx - lavf 57.8.100 - frame.h
+  Add AV_FRAME_DATA_DOVI_RPU.
+
 2021-09-21 - xx - lavu 57.7.100 - pixfmt.h
   Add AV_PIX_FMT_X2BGR10.
 
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 2617cda2b5..23b52f7b66 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -728,6 +728,7 @@ const char *av_frame_side_data_name(enum 
AVFrameSideDataType type)
 case AV_FRAME_DATA_SEI_UNREGISTERED:return "H.26[45] User Data 
Unregistered SEI message";
 case AV_FRAME_DATA_FILM_GRAIN_PARAMS:   return "Film grain 
parameters";
 case AV_FRAME_DATA_DETECTION_BBOXES:return "Bounding boxes for 
object detection and classification";
+case AV_FRAME_DATA_DOVI_RPU:return "Dolby Vision RPU 
Data";
 }
 return NULL;
 }
diff --git a/libavutil/frame.h b/libavutil/frame.h
index ff2540a20f..29839211ca 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -187,6 +187,13 @@ enum AVFrameSideDataType {
  * as described by AVDetectionBBoxHeader.
  */
 AV_FRAME_DATA_DETECTION_BBOXES,
+
+/**
+ * Dolby Vision RPU data, suitable for passing to x265
+ * or other libraries. Array of uint8_t, with NAL emulation
+ * bytes intact.
+ */
+AV_FRAME_DATA_DOVI_RPU,
 };
 
 enum AVActiveFormatDescription {
diff --git a/libavutil/version.h b/libavutil/version.h
index 896e348d80..eeb33b388c 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  57
-#define LIBAVUTIL_VERSION_MINOR   7
+#define LIBAVUTIL_VERSION_MINOR   8
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
-- 
2.32.0

___
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".

[FFmpeg-devel] [PATCH 2/3] avcodec/hevcdec: Export Dolby Vision RPUs as side data

2021-10-21 Thread Derek Buitenhuis 
Signed-off-by: Derek Buitenhuis 
---
* The NAL reordering approach is a result of discussions with Anton and James
  a few months ago.
* I've put the NAL reordering in ff_h2645_packet_split, rather than a bitstream
  filter for a few reasons:
* I don't think having a decoder's behavior rely on the presence of a 
bitstream
  filter is good architecture / design.
* This spliting is only usd or useful to decoding.
---
 libavcodec/h2645_parse.c | 28 
 libavcodec/hevcdec.c | 32 
 libavcodec/hevcdec.h |  3 +++
 libavcodec/version.h |  2 +-
 4 files changed, 64 insertions(+), 1 deletion(-)

diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 6fbe97ad4a..04348c3a73 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -517,6 +517,34 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
 pkt->nb_nals++;
 }
 
+/*
+ * Due to limitions in avcodec's current frame threading code, it cannot
+ * handle adding frame side data in any place except before the slice has
+ * started decoding. Since Dolby Vision RPUs (which appear as NAL type 62)
+ * are appended to the AU, this is a poblematic. As a hack around this, we
+ * move any RPUs to before the first slice NAL.
+ */
+if (codec_id == AV_CODEC_ID_HEVC && pkt->nb_nals > 1 && 
pkt->nals[pkt->nb_nals - 1].type == HEVC_NAL_UNSPEC62 &&
+pkt->nals[pkt->nb_nals - 1].data[0] == 0x7C && pkt->nals[pkt->nb_nals 
- 1].data[1] == 0x01) {
+
+int first_non_slice = 0;
+H2645NAL *tmp = av_malloc(pkt->nb_nals * sizeof(H2645NAL));
+if (!tmp)
+return AVERROR(ENOMEM);
+
+for (int i = pkt->nb_nals - 1; i >= 0; i--) {
+if (pkt->nals[i].type < HEVC_NAL_VPS)
+first_non_slice = i;
+tmp[i] = pkt->nals[i];
+}
+
+pkt->nals[first_non_slice] = pkt->nals[pkt->nb_nals - 1];
+for (int i = first_non_slice + 1; i < pkt->nb_nals; i++)
+pkt->nals[i] = tmp[i - 1];
+
+av_free(tmp);
+}
+
 return 0;
 }
 
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 246ffd7d80..5ccee2aa4e 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2950,6 +2950,17 @@ static int set_side_data(HEVCContext *s)
 }
 }
 
+if (s->rpu_buf) {
+AVFrameSideData *rpu = av_frame_new_side_data(out, 
AV_FRAME_DATA_DOVI_RPU, s->rpu_buf_size);
+if (!rpu)
+return AVERROR(ENOMEM);
+
+memcpy(rpu->data, s->rpu_buf, s->rpu_buf_size);
+
+av_freep(&s->rpu_buf);
+s->rpu_buf_size = 0;
+}
+
 return 0;
 }
 
@@ -3224,6 +3235,23 @@ static int decode_nal_unit(HEVCContext *s, const 
H2645NAL *nal)
 case HEVC_NAL_AUD:
 case HEVC_NAL_FD_NUT:
 break;
+case HEVC_NAL_UNSPEC62:
+/*
+ * Check for RPU delimiter.
+ *
+ * Dolby Vision RPUs masquerade as unregistered NALs of type 62 and 
start with
+ * 0x7C01.
+ */
+if (nal->size > 2 && nal->data[0] == 0x7C && nal->data[1] == 0x01) {
+s->rpu_buf = av_malloc(nal->raw_size - 2);
+if (!s->rpu_buf)
+return AVERROR(ENOMEM);
+
+memcpy(s->rpu_buf, nal->raw_data + 2, nal->raw_size - 2);
+
+s->rpu_buf_size = nal->raw_size - 2;
+}
+break;
 default:
 av_log(s->avctx, AV_LOG_INFO,
"Skipping NAL unit %d\n", s->nal_unit_type);
@@ -3512,6 +3540,8 @@ static av_cold int hevc_decode_free(AVCodecContext *avctx)
 
 pic_arrays_free(s);
 
+av_freep(&s->rpu_buf);
+
 av_freep(&s->md5_ctx);
 
 av_freep(&s->cabac_state);
@@ -3754,6 +3784,8 @@ static void hevc_decode_flush(AVCodecContext *avctx)
 HEVCContext *s = avctx->priv_data;
 ff_hevc_flush_dpb(s);
 ff_hevc_reset_sei(&s->sei);
+av_freep(&s->rpu_buf);
+s->rpu_buf_size = 0;
 s->max_ra = INT_MAX;
 s->eos = 1;
 }
diff --git a/libavcodec/hevcdec.h b/libavcodec/hevcdec.h
index 77fdf90da1..8a9b516759 100644
--- a/libavcodec/hevcdec.h
+++ b/libavcodec/hevcdec.h
@@ -572,6 +572,9 @@ typedef struct HEVCContext {
 
 int nal_length_size;///< Number of bytes used for nal length (1, 2 or 
4)
 int nuh_layer_id;
+
+uint8_t *rpu_buf;   ///< 0 or 1 Dolby Vision RPUs.
+size_t rpu_buf_size;
 } HEVCContext;
 
 /**
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 74b8baa5f3..76af066d32 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,7 +28,7 @@
 #include "libavutil/version.h"
 
 #define LIBAVCODEC_VERSION_MAJOR  59
-#define LIBAVCODEC_VERSION_MINOR  12
+#define LIBAVCODEC_VERSION_MINOR  13
 #define LIBAVCODEC_VERSION_MICRO 100
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
-- 
2.32.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
ht

[FFmpeg-devel] [PATCH 3/3] fate: Add test for Dolby Vision RPU side data

2021-10-21 Thread Derek Buitenhuis 
Signed-off-by: Derek Buitenhuis 
---
File: https://www.dropbox.com/s/tjnm3vggdc6s7v3/dv84.mov?dl=0

We generated this file ourselves with an iPhone; there is no copyright issue.
---
 tests/fate/hevc.mak|   3 +
 tests/ref/fate/hevc-dv-rpu | 512 +
 2 files changed, 515 insertions(+)
 create mode 100644 tests/ref/fate/hevc-dv-rpu

diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
index f6ea1df9a5..2a88eb4690 100644
--- a/tests/fate/hevc.mak
+++ b/tests/fate/hevc.mak
@@ -273,6 +273,9 @@ FATE_HEVC_FFPROBE-$(call DEMDEC, HEVC, HEVC) += 
fate-hevc-monochrome-crop
 fate-hevc-hdr10-plus-metadata: CMD = probeframes -show_entries 
frame=side_data_list $(TARGET_SAMPLES)/hevc/hdr10_plus_h265_sample.hevc
 FATE_HEVC_FFPROBE-$(call DEMDEC, HEVC, HEVC) += fate-hevc-hdr10-plus-metadata
 
+fate-hevc-dv-rpu: CMD = probeframes -show_entries frame=side_data_list 
-select_streams 0 $(TARGET_SAMPLES)/hevc/dv84.mov
+FATE_HEVC_FFPROBE-$(call DEMDEC, HEVC, HEVC) += fate-hevc-dv-rpu
+
 fate-hevc-two-first-slice: CMD = threads=2 framemd5 -i 
$(TARGET_SAMPLES)/hevc/two_first_slice.mp4 -sws_flags bitexact -t 00:02.00 -an
 FATE_HEVC-$(call DEMDEC, MOV, HEVC) += fate-hevc-two-first-slice
 
diff --git a/tests/ref/fate/hevc-dv-rpu b/tests/ref/fate/hevc-dv-rpu
new file mode 100644
index 00..37ad9ffec2
--- /dev/null
+++ b/tests/ref/fate/hevc-dv-rpu
@@ -0,0 +1,512 @@
+[FRAME]
+[SIDE_DATA]
+side_data_type=H.26[45] User Data Unregistered SEI message
+[/SIDE_DATA]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=H.26[45] User Data Unregistered SEI message
+[/SIDE_DATA]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU Data
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+[SIDE_DATA]
+side_data_type=Dolby Vision RPU D

[FFmpeg-devel] [PATCH 0/3] Dolby Vision RPU Side Data

2021-10-21 Thread Derek Buitenhuis 
This patch set allows exporting Dolby Vision RPUs as side data,
allowing them to be used in transcoding, etc.

There are notes in each inividual patch.

Derek Buitenhuis (3):
  avutil: Add Dolby Vision RPU side data type
  avcodec/hevcdec: Export Dolby Vision RPUs as side data
  fate: Add test for Dolby Vision RPU side data

 doc/APIchanges |   3 +
 libavcodec/h2645_parse.c   |  28 ++
 libavcodec/hevcdec.c   |  32 +++
 libavcodec/hevcdec.h   |   3 +
 libavcodec/version.h   |   2 +-
 libavutil/frame.c  |   1 +
 libavutil/frame.h  |   7 +
 libavutil/version.h|   2 +-
 tests/fate/hevc.mak|   3 +
 tests/ref/fate/hevc-dv-rpu | 512 +
 10 files changed, 591 insertions(+), 2 deletions(-)
 create mode 100644 tests/ref/fate/hevc-dv-rpu

-- 
2.32.0

___
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".

[FFmpeg-devel] (no subject)

2021-10-21 Thread ekibun 
Hi. I'm investigating in custom IO for HLS playing, and got errors while 
calling segments.
I've compiled libav with `--disable-network` configure and tried custom IO by 
overriding `io_open` and `io_close` for `AVFormatContext`. Everything goes well 
until open segments urls.
In the function `open_url` of `hls.c`, demuxer checks the protocol name before 
calling io_open.
The protocol name is obtained by `avio_find_protocol_name` that always return 
`NULL` since no network protocol exists.
And after I commented out all the protocol checks in `hls.c`, it functions 
properly.
Curious to hear if you think it's a good solution or is there a better way 
around.
Thanks! 


___
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".

[FFmpeg-devel] [PATCH] avformat/hls: Do not check protocol on hls without network.

2021-10-21 Thread ekibun 
---
 libavformat/hls.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 52a031ed..55fa831b 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -637,6 +637,7 @@ static int open_url(AVFormatContext *s, AVIOContext **pb, 
const char *url,
 int ret;
 int is_http = 0;
 
+#if CONFIG_HTTP_PROTOCOL
 if (av_strstart(url, "crypto", NULL)) {
 if (url[6] == '+' || url[6] == ':')
 proto_name = avio_find_protocol_name(url + 7);
@@ -675,6 +676,7 @@ static int open_url(AVFormatContext *s, AVIOContext **pb, 
const char *url,
 ;
 else if (strcmp(proto_name, "file") || !strncmp(url, "file,", 5))
 return AVERROR_INVALIDDATA;
+#endif
 
 av_dict_copy(&tmp, *opts, 0);
 av_dict_copy(&tmp, opts2, 0);
-- 
2.25.1

___
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".

[FFmpeg-devel] [PATCH] avformat/mpegtsenc: Dont include adaptation field in teletext TS packets.

2021-10-21 Thread Alex Shumsky 
>From ETSI EN 300 472 V1.3.1 (2003-05) Specification for conveying ITU-R System 
>B Teletext in DVB bitstreams:
4.1 Transport Stream (TS) packet format
The standard TS packet syntax and semantics are followed, noting the following 
constraint:
- adaptation_field_control only the values "01" and "10" are permitted.

Some set top boxes (Motorola, Arris, Zyxel) refuse non-conforming packets.

Signed-off-by: Alex Shumsky 
---
 libavformat/mpegtsenc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 184bb52f75..3d630e2500 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -1564,7 +1564,8 @@ static void mpegts_write_pes(AVFormatContext *s, AVStream 
*st,
 q = get_ts_payload_start(buf);
 ts_st->discontinuity = 0;
 }
-if (key && is_start && pts != AV_NOPTS_VALUE) {
+if (key && is_start && pts != AV_NOPTS_VALUE
+&& !is_dvb_teletext /* adaptation+payload forbidden for teletext 
(ETSI EN 300 472 V1.3.1 4.1) */ ) {
 // set Random Access for key frames
 if (ts_st->pcr_period)
 write_pcr = 1;
-- 
2.25.1

___
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".

[FFmpeg-devel] [PATCH] avformat/demux: preserve AV_PKT_FLAG_CORRUPT in parse_packet

2021-10-21 Thread Alex Shumsky 
If original packet is corrupted, then parsed packet is probably corrupted too.
Let the application decide what to do.

Signed-off-by: Alex Shumsky 
---
 libavformat/demux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/demux.c b/libavformat/demux.c
index 6a4b687bf1..71a1a9bf03 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -1179,7 +1179,7 @@ static int parse_packet(AVFormatContext *s, AVPacket *pkt,
 out_pkt->pts  = sti->parser->pts;
 out_pkt->dts  = sti->parser->dts;
 out_pkt->pos  = sti->parser->pos;
-out_pkt->flags   |= pkt->flags & AV_PKT_FLAG_DISCARD;
+out_pkt->flags   |= pkt->flags & (AV_PKT_FLAG_DISCARD | 
AV_PKT_FLAG_CORRUPT);
 
 if (sti->need_parsing == AVSTREAM_PARSE_FULL_RAW)
 out_pkt->pos = sti->parser->frame_offset;
-- 
2.25.1

___
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".

Re: [FFmpeg-devel] [PATCH v3 2/3] avformat/avio{, buf}: deprecate AVIOContext::written

2021-10-21 Thread Michael Niedermayer 
On Wed, Oct 20, 2021 at 12:02:13AM +0300, Jan Ekström wrote:
> On Mon, Oct 18, 2021 at 3:47 PM Jan Ekström  wrote:
> >
> > 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).
> > ---

Its a public struct in a public header so deprecate

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


signature.asc
Description: PGP signature
___
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".

Re: [FFmpeg-devel] [PATCH v3 2/3] avformat/avio{, buf}: deprecate AVIOContext::written

2021-10-21 Thread Jan Ekström 
On Thu, Oct 21, 2021 at 8:26 PM Michael Niedermayer
 wrote:
>
> On Wed, Oct 20, 2021 at 12:02:13AM +0300, Jan Ekström wrote:
> > On Mon, Oct 18, 2021 at 3:47 PM Jan Ekström  wrote:
> > >
> > > 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).
> > > ---
>
> Its a public struct in a public header so deprecate
>
> thx
>

OK, just confirming but so you don't consider this to be of the same
type as these 
http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=libavformat/avio.h;h=a7b56ab6674f0a25be3b480df314e2d1292f397b;hp=0b35409787c925d681a121aa8d8715c3921fddf2;hb=45bfe8b838275235412777dd430206d9a24eb3ee;hpb=530ac6aa305aeda631c77f8a17e96c14c7ab1a1c
?

The field was brought in with
http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=libavformat/avio.h;h=7bf7985c5e04a551e3a2841decc6b32ded7c0799;hp=49721aa1315fc44bf46d73d343ace4e7c3dc785e;hb=3f75e5116b900f1428aa13041fc7d6301bf1988a;hpb=fc85646ad495f3418042468da415af73a7a07334
(you can see the comment noting its private state on the top of the context)

which then was merged as
http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=libavformat/avio.h;h=525eb7129eb5b5a5a2a8dc015275526b9b25a0cb;hp=6f4ed8440d684e03e70fd296849b76d216d6fbbb;hb=34d7f337c1608c72be8c36355018dc894f0560ce;hpb=c5fd47fa8a300fc51489a47da94041609545803c
(it went just under another private struct member from the FFmpeg side)

Jan
___
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".

Re: [FFmpeg-devel] [PATCH 1/1] libavformat/rtmp: Implements RTMP reconnect feature

2021-10-21 Thread Alex Converse 
> Nowadays when you are streaming to a live platform if the RTMP(s)
> server needs to restarted for any reason (ex: deploy new version)
> the RTMP connection is interrupted (probably after some draining time).
> Facebook will publish a proposal to avoid that by sending a
> GoAway message in the RTMP protocol.
> This code is the reference client implementation of that proposal.
> AFAIK other big live platforms showed their interest in implementing
> this mechanism.
> This can be already tested against Facebook live production using
> the querystring parameter ?ccr_sec=120 (that indicates the backend
> to send a disconnect signal after those seconds)

It seems like this approach is operating from the assumption that the
time to setup a new connection and process all RPCs necessary to send
media is on the order of normal jitter. Or am I misunderstanding?

For many services I don't really think that's the case.

And even with a very fast publish response we are looking at like 1.5
RTTs for TCP, another 1.5 for TLS, another 1.5 for RTMP handshake,
another 1 RTT for RTMP connect, an RTT on createStream, and an RTT on
publish. That's like 7.5 RTTs (or 300 ms at 40ms RTT) where we are
leaving the media flow on pause while we are re-building the connection.

This also seems to conflate rebootstrapping a media decode session vs
re-bootstrapping an RMTP session. The cost of doing this seems to be
sending your biggest frame after a pause to resolve a bunch of
synchronous RPCs on a relatively fresh TCP connection.

> ---
>  libavformat/rtmppkt.c   |  19 +++
>  libavformat/rtmppkt.h   |  10 ++
>  libavformat/rtmpproto.c | 356 +---
>  3 files changed, 359 insertions(+), 26 deletions(-)
>
>[...]
> diff --git a/libavformat/rtmppkt.h b/libavformat/rtmppkt.h
> index a15d2a5773..cdb901df89 100644
> --- a/libavformat/rtmppkt.h
> +++ b/libavformat/rtmppkt.h
> @@ -59,6 +59,7 @@ typedef enum RTMPPacketType {
>  RTMP_PT_SHARED_OBJ, ///< shared object
>  RTMP_PT_INVOKE, ///< invoke some stream action
>  RTMP_PT_METADATA = 22,  ///< FLV metadata
> +RTMP_PT_GO_AWAY  = 32,  ///< Indicates please reconnect ASAP, server 
> is about to go down
>  } RTMPPacketType;
>

I'm curious as to why this is a new top level message rather than just another
type 20 command message. Message types have a small address space while
commands have a large address space and a well chosen command name is unlikely
to conflict with (and therefore can be used in concert with) any other protocol
extensions.

> [snip]


On Sun, Sep 26, 2021 at 1:52 PM Jordi Cenzano  wrote:
>
> Nowadays when you are streaming to a live platform if the RTMP(s)
> server needs to restarted for any reason (ex: deploy new version)
> the RTMP connection is interrupted (probably after some draining time).
> Facebook will publish a proposal to avoid that by sending a
> GoAway message in the RTMP protocol.
> This code is the reference client implementation of that proposal.
> AFAIK other big live platforms showed their interest in implementing
> this mechanism.
> This can be already tested against Facebook live production using
> the querystring parameter ?ccr_sec=120 (that indicates the backend
> to send a disconnect signal after those seconds)
> ---
>  libavformat/rtmppkt.c   |  19 +++
>  libavformat/rtmppkt.h   |  10 ++
>  libavformat/rtmpproto.c | 356 +---
>  3 files changed, 359 insertions(+), 26 deletions(-)
>
> diff --git a/libavformat/rtmppkt.c b/libavformat/rtmppkt.c
> index 4b97c0833f..84ec72740d 100644
> --- a/libavformat/rtmppkt.c
> +++ b/libavformat/rtmppkt.c
> @@ -405,6 +405,25 @@ int ff_rtmp_packet_write(URLContext *h, RTMPPacket *pkt,
>  return written;
>  }
>
> +int ff_rtmp_packet_clone(RTMPPacket *pkt_dst, const RTMPPacket *pkt_src)
> +{
> +if (pkt_src->size) {
> +pkt_dst->data = av_realloc(NULL, pkt_src->size);
> +if (!pkt_dst->data)
> +return AVERROR(ENOMEM);
> +else
> +memcpy(pkt_dst->data, pkt_src->data, pkt_src->size);
> +}
> +pkt_dst->size   = pkt_src->size;
> +pkt_dst->channel_id = pkt_src->channel_id;
> +pkt_dst->type   = pkt_src->type;
> +pkt_dst->timestamp  = pkt_src->timestamp;
> +pkt_dst->extra  = pkt_src->extra;
> +pkt_dst->ts_field   = pkt_src->ts_field;
> +
> +return 0;
> +}
> +
>  int ff_rtmp_packet_create(RTMPPacket *pkt, int channel_id, RTMPPacketType 
> type,
>int timestamp, int size)
>  {
> diff --git a/libavformat/rtmppkt.h b/libavformat/rtmppkt.h
> index a15d2a5773..cdb901df89 100644
> --- a/libavformat/rtmppkt.h
> +++ b/libavformat/rtmppkt.h
> @@ -59,6 +59,7 @@ typedef enum RTMPPacketType {
>  RTMP_PT_SHARED_OBJ, ///< shared object
>  RTMP_PT_INVOKE, ///< invoke some stream action
>  RTMP_PT_METADATA = 22,  ///< FLV metadata
> +RTMP_PT_GO_AWAY  = 32,  ///< Indicates

Re: [FFmpeg-devel] [PATCH] avcodec/flac_parser: Consider AV_INPUT_BUFFER_PADDING_SIZE

2021-10-21 Thread Paul B Mahol 
LGTM for now
___
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".

Re: [FFmpeg-devel] [PATCH] avcodec/flac_parser: Consider AV_INPUT_BUFFER_PADDING_SIZE

2021-10-21 Thread Michael Niedermayer 
On Thu, Oct 21, 2021 at 10:17:25PM +0200, Paul B Mahol wrote:
> LGTM for now

will apply the improved variant below

diff --git a/libavcodec/flac_parser.c b/libavcodec/flac_parser.c
index 2c550507fc8..3b27b152fc5 100644
--- a/libavcodec/flac_parser.c
+++ b/libavcodec/flac_parser.c
@@ -55,6 +55,7 @@
 
 /** largest possible size of flac header */
 #define MAX_FRAME_HEADER_SIZE 16
+#define MAX_FRAME_VERIFY_SIZE (MAX_FRAME_HEADER_SIZE + 1)
 
 typedef struct FLACHeaderMarker {
 int offset;   /**< byte offset from start of FLACParseContext->buffer 
*/
@@ -99,7 +100,7 @@ static int frame_header_is_valid(AVCodecContext *avctx, 
const uint8_t *buf,
 uint8_t subframe_type;
 
 // header plus one byte from first subframe
-init_get_bits(&gb, buf, MAX_FRAME_HEADER_SIZE * 8 + 8);
+init_get_bits(&gb, buf, MAX_FRAME_VERIFY_SIZE * 8);
 if (ff_flac_decode_frame_header(avctx, &gb, fi, 127)) {
 return 0;
 }
@@ -196,7 +197,7 @@ static int find_headers_search_validate(FLACParseContext 
*fpc, int offset)
 uint8_t *header_buf;
 int size = 0;
 header_buf = flac_fifo_read_wrap(fpc, offset,
- MAX_FRAME_HEADER_SIZE,
+ MAX_FRAME_VERIFY_SIZE + 
AV_INPUT_BUFFER_PADDING_SIZE,
  &fpc->wrap_buf,
  &fpc->wrap_buf_allocated_size);
 if (frame_header_is_valid(fpc->avctx, header_buf, &fi)) {


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


signature.asc
Description: PGP signature
___
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".

Re: [FFmpeg-devel] [PATCH v3 2/3] avformat/avio{, buf}: deprecate AVIOContext::written

2021-10-21 Thread Michael Niedermayer 
On Thu, Oct 21, 2021 at 08:48:35PM +0300, Jan Ekström wrote:
> On Thu, Oct 21, 2021 at 8:26 PM Michael Niedermayer
>  wrote:
> >
> > On Wed, Oct 20, 2021 at 12:02:13AM +0300, Jan Ekström wrote:
> > > On Mon, Oct 18, 2021 at 3:47 PM Jan Ekström  wrote:
> > > >
> > > > 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).
> > > > ---
> >
> > Its a public struct in a public header so deprecate
> >
> > thx
> >
> 
> OK, just confirming but so you don't consider this to be of the same
> type as these 
> http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=libavformat/avio.h;h=a7b56ab6674f0a25be3b480df314e2d1292f397b;hp=0b35409787c925d681a121aa8d8715c3921fddf2;hb=45bfe8b838275235412777dd430206d9a24eb3ee;hpb=530ac6aa305aeda631c77f8a17e96c14c7ab1a1c
> ?

i assume this was during ABI bumping, 
when the major version numbers change then ABI/API breaking changes can be
done.

Try to write an application which links to a shared lib and then change the
public structs of that lib by removing a field. 
the ABI/API major numbers have to be bumped when incompatible changes are
done. That way they can co exist on a machiene, application build against
the old continue working and so on ...

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


signature.asc
Description: PGP signature
___
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".

Re: [FFmpeg-devel] [PATCH v3 2/3] avformat/avio{, buf}: deprecate AVIOContext::written

2021-10-21 Thread Jan Ekström 
On Thu, Oct 21, 2021 at 11:49 PM Michael Niedermayer
 wrote:
>
> On Thu, Oct 21, 2021 at 08:48:35PM +0300, Jan Ekström wrote:
> > On Thu, Oct 21, 2021 at 8:26 PM Michael Niedermayer
> >  wrote:
> > >
> > > On Wed, Oct 20, 2021 at 12:02:13AM +0300, Jan Ekström wrote:
> > > > On Mon, Oct 18, 2021 at 3:47 PM Jan Ekström  wrote:
> > > > >
> > > > > 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).
> > > > > ---
> > >
> > > Its a public struct in a public header so deprecate
> > >
> > > thx
> > >
> >
> > OK, just confirming but so you don't consider this to be of the same
> > type as these 
> > http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=libavformat/avio.h;h=a7b56ab6674f0a25be3b480df314e2d1292f397b;hp=0b35409787c925d681a121aa8d8715c3921fddf2;hb=45bfe8b838275235412777dd430206d9a24eb3ee;hpb=530ac6aa305aeda631c77f8a17e96c14c7ab1a1c
> > ?
>
> i assume this was during ABI bumping,
> when the major version numbers change then ABI/API breaking changes can be
> done.
>

IIRC ABI breakage after bumping was supposed to be a ~month but then
IIRC people posted such things much later. Was there a message or note
when this period ended?

> Try to write an application which links to a shared lib and then change the
> public structs of that lib by removing a field.
> the ABI/API major numbers have to be bumped when incompatible changes are
> done. That way they can co exist on a machiene, application build against
> the old continue working and so on ...
>

For the record, I know what ABI bumping is. I was just unclear whether
we were already past ABI instability period or not due to
4.5/5.0/whatever not still being made and due to there (as far as I
know) there being no clear message on when the ABI instability period
would end.

Jan
___
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".

Re: [FFmpeg-devel] [PATCH v3 2/3] avformat/avio{, buf}: deprecate AVIOContext::written

2021-10-21 Thread Jan Ekström 
On Fri, Oct 22, 2021 at 12:21 AM Jan Ekström  wrote:
>
> On Thu, Oct 21, 2021 at 11:49 PM Michael Niedermayer
>  wrote:
> >
> > On Thu, Oct 21, 2021 at 08:48:35PM +0300, Jan Ekström wrote:
> > > On Thu, Oct 21, 2021 at 8:26 PM Michael Niedermayer
> > >  wrote:
> > > >
> > > > On Wed, Oct 20, 2021 at 12:02:13AM +0300, Jan Ekström wrote:
> > > > > On Mon, Oct 18, 2021 at 3:47 PM Jan Ekström  wrote:
> > > > > >
> > > > > > 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).
> > > > > > ---
> > > >
> > > > Its a public struct in a public header so deprecate
> > > >
> > > > thx
> > > >
> > >
> > > OK, just confirming but so you don't consider this to be of the same
> > > type as these 
> > > http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=libavformat/avio.h;h=a7b56ab6674f0a25be3b480df314e2d1292f397b;hp=0b35409787c925d681a121aa8d8715c3921fddf2;hb=45bfe8b838275235412777dd430206d9a24eb3ee;hpb=530ac6aa305aeda631c77f8a17e96c14c7ab1a1c
> > > ?
> >
> > i assume this was during ABI bumping,
> > when the major version numbers change then ABI/API breaking changes can be
> > done.
> >
>
> IIRC ABI breakage after bumping was supposed to be a ~month but then
> IIRC people posted such things much later. Was there a message or note
> when this period ended?
>

This commit 
(http://git.videolan.org/?p=ffmpeg.git;a=commit;h=45bfe8b838275235412777dd430206d9a24eb3ee)
was applied in late August (as the entries were private - kind of like
this one remaining entry), and I can find Anton noting in May that the
project is in ABI instability period. So do excuse me for not knowing
which mode we are in right now if it went on for at least four months
:D

Jan
___
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".

Re: [FFmpeg-devel] [PATCH] avcodec/flac_parser: Consider AV_INPUT_BUFFER_PADDING_SIZE

2021-10-21 Thread Mattias Wadman 
On Thu, Oct 21, 2021 at 10:35 PM Michael Niedermayer 
wrote:

> On Thu, Oct 21, 2021 at 10:17:25PM +0200, Paul B Mahol wrote:
> > LGTM for now
>
> will apply the improved variant below
>
> diff --git a/libavcodec/flac_parser.c b/libavcodec/flac_parser.c
> index 2c550507fc8..3b27b152fc5 100644
> --- a/libavcodec/flac_parser.c
> +++ b/libavcodec/flac_parser.c
> @@ -55,6 +55,7 @@
>
>  /** largest possible size of flac header */
>  #define MAX_FRAME_HEADER_SIZE 16
> +#define MAX_FRAME_VERIFY_SIZE (MAX_FRAME_HEADER_SIZE + 1)
>
>  typedef struct FLACHeaderMarker {
>  int offset;   /**< byte offset from start of
> FLACParseContext->buffer */
> @@ -99,7 +100,7 @@ static int frame_header_is_valid(AVCodecContext *avctx,
> const uint8_t *buf,
>  uint8_t subframe_type;
>
>  // header plus one byte from first subframe
> -init_get_bits(&gb, buf, MAX_FRAME_HEADER_SIZE * 8 + 8);
> +init_get_bits(&gb, buf, MAX_FRAME_VERIFY_SIZE * 8);
>  if (ff_flac_decode_frame_header(avctx, &gb, fi, 127)) {
>  return 0;
>  }
> @@ -196,7 +197,7 @@ static int
> find_headers_search_validate(FLACParseContext *fpc, int offset)
>  uint8_t *header_buf;
>  int size = 0;
>  header_buf = flac_fifo_read_wrap(fpc, offset,
> - MAX_FRAME_HEADER_SIZE,
> + MAX_FRAME_VERIFY_SIZE +
> AV_INPUT_BUFFER_PADDING_SIZE,
>   &fpc->wrap_buf,
>   &fpc->wrap_buf_allocated_size);
>  if (frame_header_is_valid(fpc->avctx, header_buf, &fi)) {
>
>
LGTM

But i'm not sure about the PARSER_FLAG_COMPLETE_FRAMES case, hard to tell
if those code paths will always have
MAX_FRAME_VERIFY_SIZE+AV_INPUT_BUFFER_PADDING_SIZE buf size.

Thanks for helping to fix this.

BTW, yesterday a FLAC file showed up with a "false" frame that even this
patch failed to ignore. Strange enough it is a FLAC file with no encoder
metadata at all and the frame that it failed on is a verbatim frame. It's a
perfectly valid file with correct md5 but the audio is heavily distorted
which explains the verbatim frames. Hopefully they should be very rare.
___
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".

Re: [FFmpeg-devel] [PATCH v3 2/3] avformat/avio{, buf}: deprecate AVIOContext::written

2021-10-21 Thread Michael Niedermayer 
On Fri, Oct 22, 2021 at 12:32:18AM +0300, Jan Ekström wrote:
> On Fri, Oct 22, 2021 at 12:21 AM Jan Ekström  wrote:
> >
> > On Thu, Oct 21, 2021 at 11:49 PM Michael Niedermayer
> >  wrote:
> > >
> > > On Thu, Oct 21, 2021 at 08:48:35PM +0300, Jan Ekström wrote:
> > > > On Thu, Oct 21, 2021 at 8:26 PM Michael Niedermayer
> > > >  wrote:
> > > > >
> > > > > On Wed, Oct 20, 2021 at 12:02:13AM +0300, Jan Ekström wrote:
> > > > > > On Mon, Oct 18, 2021 at 3:47 PM Jan Ekström  
> > > > > > wrote:
> > > > > > >
> > > > > > > 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).
> > > > > > > ---
> > > > >
> > > > > Its a public struct in a public header so deprecate
> > > > >
> > > > > thx
> > > > >
> > > >
> > > > OK, just confirming but so you don't consider this to be of the same
> > > > type as these 
> > > > http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=libavformat/avio.h;h=a7b56ab6674f0a25be3b480df314e2d1292f397b;hp=0b35409787c925d681a121aa8d8715c3921fddf2;hb=45bfe8b838275235412777dd430206d9a24eb3ee;hpb=530ac6aa305aeda631c77f8a17e96c14c7ab1a1c
> > > > ?
> > >
> > > i assume this was during ABI bumping,
> > > when the major version numbers change then ABI/API breaking changes can be
> > > done.
> > >
> >
> > IIRC ABI breakage after bumping was supposed to be a ~month but then
> > IIRC people posted such things much later. Was there a message or note
> > when this period ended?

Maybe someone assumed that everyone agreed what "a ~month" is ?


> >
> 
> This commit 
> (http://git.videolan.org/?p=ffmpeg.git;a=commit;h=45bfe8b838275235412777dd430206d9a24eb3ee)
> was applied in late August (as the entries were private - kind of like
> this one remaining entry), and I can find Anton noting in May that the
> project is in ABI instability period. So do excuse me for not knowing
> which mode we are in right now if it went on for at least four months
> :D

I think you should really implement a full statistics API instead of
this as you clearly have alot of time.
you can leave the field, you can deprecate it you can also suggest to
bump major. What you cannot do is break ABI/API. If Iam missing something
and this is not breaking ABI/API then you can also explain how that would
not break it

thx


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


signature.asc
Description: PGP signature
___
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".

[FFmpeg-devel] [PATCH v3] avcodec/libjxl: add JPEG XL decoding via libjxl

2021-10-21 Thread Leo Izen 
Use the external libjxl library to add decoding for JPEG XL
images, and add the appropriate image2 muxers and demuxers
to read/write JPEG XL image files.
---
 MAINTAINERS   |   2 +
 configure |   5 +
 doc/general_contents.texi |   7 +
 libavcodec/Makefile   |   1 +
 libavcodec/allcodecs.c|   1 +
 libavcodec/codec_desc.c   |   9 ++
 libavcodec/codec_id.h |   1 +
 libavcodec/libjxl.c   |  72 +
 libavcodec/libjxl.h   |  44 ++
 libavcodec/libjxldec.c| 301 ++
 libavcodec/version.h  |   2 +-
 libavformat/allformats.c  |   1 +
 libavformat/img2.c|   1 +
 libavformat/img2dec.c |  91 
 libavformat/img2enc.c |   6 +-
 libavformat/mov.c |   1 +
 16 files changed, 541 insertions(+), 4 deletions(-)
 create mode 100644 libavcodec/libjxl.c
 create mode 100644 libavcodec/libjxl.h
 create mode 100644 libavcodec/libjxldec.c

diff --git a/MAINTAINERS b/MAINTAINERS
index dcac46003e..2e34ebbad7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -193,6 +193,7 @@ Codecs:
   libcodec2.c   Tomas Härdin
   libdirac* David Conrad
   libdavs2.cHuiwen Ren
+  libjxl*.c, libjxl.h   Leo Izen
   libgsm.c  Michel Bardiaux
   libkvazaar.c  Arttu Ylä-Outinen
   libopenh264enc.c  Martin Storsjo, Linjie Fu
@@ -614,6 +615,7 @@ Gwenole Beauchesne2E63 B3A6 3E44 37E2 017D 2704 
53C7 6266 B153 99C4
 Jaikrishnan Menon 61A1 F09F 01C9 2D45 78E1 C862 25DC 8831 AF70 D368
 James Almer   7751 2E8C FD94 A169 57E6 9A7A 1463 01AD 7376 59E0
 Jean Delvare  7CA6 9F44 60F1 BDC4 1FD2 C858 A552 6B9B B3CD 4E6A
+Leo Izen (thebombzen) B6FD 3CFC 7ACF 83FC 9137 6945 5A71 C331 FD2F A19A
 Loren Merritt ABD9 08F4 C920 3F65 D8BE 35D7 1540 DAA7 060F 56DE
 Lynne FE50 139C 6805 72CA FD52 1F8D A2FE A5F0 3F03 4464
 Michael Niedermayer   9FF2 128B 147E F673 0BAD F133 611E C787 040B 0FAB
diff --git a/configure b/configure
index 92610c7edc..b5fadebbb1 100755
--- a/configure
+++ b/configure
@@ -241,6 +241,7 @@ External library support:
   --enable-libiec61883 enable iec61883 via libiec61883 [no]
   --enable-libilbc enable iLBC de/encoding via libilbc [no]
   --enable-libjack enable JACK audio sound server [no]
+  --enable-libjxl  enable JPEG XL decoding via libjxl [no]
   --enable-libklvanc   enable Kernel Labs VANC processing [no]
   --enable-libkvazaar  enable HEVC encoding via libkvazaar [no]
   --enable-liblensfun  enable lensfun lens correction [no]
@@ -1816,6 +1817,7 @@ EXTERNAL_LIBRARY_LIST="
 libiec61883
 libilbc
 libjack
+libjxl
 libklvanc
 libkvazaar
 libmodplug
@@ -3281,6 +3283,7 @@ libgsm_ms_decoder_deps="libgsm"
 libgsm_ms_encoder_deps="libgsm"
 libilbc_decoder_deps="libilbc"
 libilbc_encoder_deps="libilbc"
+libjxl_decoder_deps="libjxl libjxl_threads"
 libkvazaar_encoder_deps="libkvazaar"
 libmodplug_demuxer_deps="libmodplug"
 libmp3lame_encoder_deps="libmp3lame"
@@ -6429,6 +6432,8 @@ enabled libgsm&& { for gsm_hdr in "gsm.h" 
"gsm/gsm.h"; do
check_lib libgsm "${gsm_hdr}" gsm_create 
-lgsm && break;
done || die "ERROR: libgsm not found"; }
 enabled libilbc   && require libilbc ilbc.h WebRtcIlbcfix_InitDecode 
-lilbc $pthreads_extralibs
+enabled libjxl&& require_pkg_config libjxl "libjxl >= 0.7.0" 
jxl/decode.h JxlDecoderVersion &&
+ require_pkg_config libjxl_threads "libjxl_threads 
>= 0.7.0" jxl/thread_parallel_runner.h JxlThreadParallelRunner
 enabled libklvanc && require libklvanc libklvanc/vanc.h 
klvanc_context_create -lklvanc
 enabled libkvazaar&& require_pkg_config libkvazaar "kvazaar >= 0.8.1" 
kvazaar.h kvz_api_get
 enabled liblensfun&& require_pkg_config liblensfun lensfun lensfun.h 
lf_db_new
diff --git a/doc/general_contents.texi b/doc/general_contents.texi
index df1692c8df..2778e20091 100644
--- a/doc/general_contents.texi
+++ b/doc/general_contents.texi
@@ -171,6 +171,13 @@ Go to @url{https://github.com/TimothyGu/libilbc} and 
follow the instructions for
 installing the library. Then pass @code{--enable-libilbc} to configure to
 enable it.
 
+@section libjxl
+
+JPEG XL is an image format intended to fully replace legacy JPEG for an 
extended
+period of life. See @url{https://jpegxl.info/} for more information, and see
+@url{https://github.com/libjxl/libjxl} for the library source. You can pass
+@code{--enable-libjxl} to configure in order enable the libjxl wrapper.
+
 @section libvpx
 
 FFmpeg can make use of the libvpx library for VP8/VP9 decoding and encoding.
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 14fbd2ecbc