Re: [FFmpeg-devel] [PATCH 100/114] avcodec/vp3: Use symbols table for VP3 motion vectors
On Tue, Nov 10, 2020 at 11:58:22AM +0100, Andreas Rheinhardt wrote: > Expressions like array[get_vlc2()] can be optimized by using a symbols > table if the array is always the same for a given VLC. This requirement > is fulfilled for the VLC used for VP3 motion vectors. The reason it > hasn't been done before is probably that the array in this case > contained entries in the range -31..31; but this is no problem with > ff_init_vlc_from_lengths(): Just apply an offset of 31 to the symbols > before storing them in the table used to initialize VP3 motion vectors > and apply an offset of -31 when initializing the actual VLC. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/vp3.c | 20 --- > libavcodec/vp3data.h | 46 +++- > 2 files changed, 24 insertions(+), 42 deletions(-) > > diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c > index 7037d03a98..f288a53fe1 100644 > --- a/libavcodec/vp3.c > +++ b/libavcodec/vp3.c > @@ -48,6 +48,7 @@ > #include "vp3dsp.h" > #include "xiph.h" > > +#define VP3_MV_VLC_BITS 6 > #define VP4_MV_VLC_BITS 6 > #define SUPERBLOCK_VLC_BITS 6 or just use '#define MV_VLC_BITS 6' -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) 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 001/114] avcodec/bitstream: Add second function to create VLCs
Quoting Andreas Rheinhardt (2020-11-12 21:51:28)
> Derek Buitenhuis:
> > On 10/11/2020 10:46, Andreas Rheinhardt wrote:
> >>
> >> +#define INIT_VLC_STATIC_FROM_LENGTHS(vlc, bits, nb_codes, lens, len_wrap,
> >> \
> >> + symbols, symbols_wrap, symbols_size,
> >> \
> >> + offset, flags, static_size)
> >> \
> >> +do {
> >> \
> >> +static VLC_TYPE table[static_size][2];
> >> \
> >> +(vlc)->table = table;
> >> \
> >> +(vlc)->table_allocated = static_size;
> >> \
> >> +ff_init_vlc_from_lengths(vlc, bits, nb_codes, lens, len_wrap,
> >> \
> >> + symbols, symbols_wrap, symbols_size,
> >> \
> >> + offset, flags |
> >> INIT_VLC_USE_NEW_STATIC); \
> >> +} while (0)
> >
> > If I am reading correctly, wherever you add/use this, you are adding
> > non-thread
> > safe global init code to a decoder. This is a huge step back and not
> > acceptable.
> >
> > It should be made to properly use ff_thread_once if possible, or reworked.
> >
> The ff_init_vlc_... functions are inherently thread-safe: Everything is
> modified only once and directly set to its final value; so it's no
> problem if two threads are initializing the same static VLC at the same
> time.
Strictly speaking it's still a race (and therefore UB), even if you
store the same values. I suspect tools like tsan will not like it
either.
--
Anton Khirnov
___
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 001/114] avcodec/bitstream: Add second function to create VLCs
Quoting Andreas Rheinhardt (2020-11-10 11:46:58)
> +int ff_init_vlc_from_lengths(VLC *vlc_arg, int nb_bits, int nb_codes,
> + const int8_t *lens, int lens_wrap,
> + const void *symbols, int symbols_wrap, int
> symbols_size,
> + int offset, int flags)
> +{
> +VLCcode localbuf[LOCALBUF_ELEMS], *buf = localbuf;
> +VLC localvlc, *vlc;
> +uint64_t code;
> +int ret, j, len_max = FFMIN(32, 3 * nb_bits);
> +
> +ret = vlc_common_init(vlc_arg, nb_bits, nb_codes, &vlc, &localvlc,
> + &buf, flags);
> +if (ret < 0)
> +return ret;
> +
> +j = code = 0;
> +for (int i = 0; i < nb_codes; i++, lens += lens_wrap) {
> +int len = *lens;
> +if (len > 0) {
> +unsigned sym;
> +
> +buf[j].bits = len;
> +if (symbols)
> +GET_DATA(sym, symbols, i, symbols_wrap, symbols_size)
> +else
> +sym = i;
> +buf[j].symbol = sym + offset;
> +buf[j++].code = code;
> +} else if (len < 0) {
> +len = -len;
> +} else
> +continue;
> +if (len > len_max || code & ((1U << (32 - len)) - 1)) {
> +av_log(NULL, AV_LOG_ERROR, "Invalid VLC (length %u)\n", len);
Can you use a proper logging context here?
--
Anton Khirnov
___
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 5/7] avformat/wavdec: Avoid zeroing written to array
Quoting Michael Niedermayer (2020-11-10 00:04:54) > Fixes: OOM > Fixes: > 26934/clusterfuzz-testcase-minimized-ffmpeg_dem_W64_fuzzer-5996784213819392 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/wavdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c > index a81f2c7a67..6e5f4ccc12 100644 > --- a/libavformat/wavdec.c > +++ b/libavformat/wavdec.c > @@ -920,7 +920,7 @@ static int w64_read_header(AVFormatContext *s) > if (chunk_size == UINT32_MAX || (filesize >= 0 && chunk_size > > filesize)) > return AVERROR_INVALIDDATA; > > -value = av_mallocz(chunk_size + 1); > +value = av_malloc(chunk_size + 1); This looks highly suspicious as a fix for anything other than performance. -- Anton Khirnov ___ 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 6/7] avcodec/utils: USe 64bit in get_audio_frame_duration() for ADPCM_DTK
Quoting Michael Niedermayer (2020-11-04 01:06:48) > Fixes: signed integer overflow: 131203586 * 28 cannot be represented in type > 'int' > Fixes: > 26817/clusterfuzz-testcase-minimized-ffmpeg_dem_MSF_fuzzer-6296902548848640 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/utils.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/utils.c b/libavcodec/utils.c > index 110496cc44..82506ea69c 100644 > --- a/libavcodec/utils.c > +++ b/libavcodec/utils.c > @@ -1687,7 +1687,7 @@ static int get_audio_frame_duration(enum AVCodecID id, > int sr, int ch, int ba, > return frame_bytes / (9 * ch) * 16; > case AV_CODEC_ID_ADPCM_PSX: > case AV_CODEC_ID_ADPCM_DTK: > -return frame_bytes / (16 * ch) * 28; > +return frame_bytes / ((int64_t)16 * ch) * 28; This assumes int is strictly smaller than int64. Why not just test whether 16 * ch fits in an int and return zero if it does not? -- Anton Khirnov ___ 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 v2 2/3] libavcodec: add a new AV_CODEC_EXPORT_DATA_FILM_GRAIN flag and option
Quoting Lynne (2020-11-12 18:42:22)
> This introduces a new field to allow decoders to export their film grain
> parameters.
> Will be used by the next patch.
>
> Patch attached.
> From d5d5e1e5f90938ac5cfa462efc13658ab411246b Mon Sep 17 00:00:00 2001
> From: Lynne
> Date: Thu, 12 Nov 2020 17:46:09 +0100
> Subject: [PATCH v2 2/3] libavcodec: add a new AV_CODEC_EXPORT_DATA_FILM_GRAIN
> flag and option
>
> This introduces a new field to allow decoders to export their film grain
> parameters.
> Will be used by the next patch.
> ---
> doc/APIchanges | 3 +++
> libavcodec/avcodec.h | 5 +
> libavcodec/options_table.h | 1 +
> libavcodec/version.h | 4 ++--
> 4 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 41248724d9..9d0ddb4ff6 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>
> API changes, most recent first:
>
> +2020-xx-xx - xx - lavc 58.113.100 - avcodec.h
> + Adds a new flag AV_CODEC_EXPORT_DATA_FILM_GRAIN for export_side_data.
> +
> 2020-xx-xx - xx - lavu 56.61.100 - film_grain_params.h
>Adds a new API for extracting codec film grain parameters as side data.
>Adds a new AVFrameSideDataType entry AV_FRAME_DATA_FILM_GRAIN_PARAMS for
> it.
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 20af3ef00d..5047da0f6a 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -410,6 +410,11 @@ typedef struct RcOverride{
> * Export the AVVideoEncParams structure through frame side data.
> */
> #define AV_CODEC_EXPORT_DATA_VIDEO_ENC_PARAMS (1 << 2)
> +/**
> + * Decoding only.
> + * Do not apply film grain, export it instead.
Could someone want to both apply AND export it?
--
Anton Khirnov
___
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/2] avcodec/cbs_h265_syntax_template: Better check for num_long_term_sps
Fixes: index 26 out of bounds for type 'uint8_t [16]' Fixes: 24913/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-6261760693370880 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/cbs_h265_syntax_template.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/cbs_h265_syntax_template.c b/libavcodec/cbs_h265_syntax_template.c index 48fae82d04..8eb6e159f4 100644 --- a/libavcodec/cbs_h265_syntax_template.c +++ b/libavcodec/cbs_h265_syntax_template.c @@ -1405,6 +1405,8 @@ static int FUNC(slice_segment_header)(CodedBitstreamContext *ctx, RWContext *rw, infer(num_long_term_sps, 0); idx_size = 0; } +if (HEVC_MAX_REFS < current->num_long_term_sps) +return AVERROR_INVALIDDATA; ue(num_long_term_pics, 0, HEVC_MAX_REFS - current->num_long_term_sps); for (i = 0; i < current->num_long_term_sps + -- 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".
[FFmpeg-devel] [PATCH 2/2] avformat/rmdec: Check for EOF in index packet reading
Fixes: Timeout(>10sec -> 1ms)
Fixes:
27284/clusterfuzz-testcase-minimized-ffmpeg_dem_RM_fuzzer-630420985728
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/rmdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
index 0c3ac4e47f..004c62086d 100644
--- a/libavformat/rmdec.c
+++ b/libavformat/rmdec.c
@@ -458,6 +458,8 @@ static int rm_read_index(AVFormatContext *s)
}
for (n = 0; n < n_pkts; n++) {
+if (avio_feof(pb))
+return AVERROR_INVALIDDATA;
avio_skip(pb, 2);
pts = avio_rb32(pb);
pos = avio_rb32(pb);
--
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 v2] avformat/dhav: also support ZLAV packets
Ping :-)
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Michael Keeley
> Sent: Sunday, 8 November 2020 10:42 pm
> To: ffmpeg-devel@ffmpeg.org
> Cc: Michael Keeley
> Subject: [FFmpeg-devel] [PATCH v2] avformat/dhav: also support ZLAV
> packets
>
> Some DVRs (e.g. D7008FH made by iSmart Cities (Zhuhai) Limited) output
> the same format .dav file,
> but use ZLAV/zlav tags to delimit the packets instead of DHAV/dhav.
>
> Signed-off-by: Michael Keeley
> ---
> Changelog | 1 +
> libavformat/dhav.c| 31 ++-
> libavformat/version.h | 2 +-
> 3 files changed, 24 insertions(+), 10 deletions(-)
>
> diff --git a/Changelog b/Changelog
> index 0ea1901bbe..a56216543d 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -41,6 +41,7 @@ version :
> - LEGO Racers ALP (.tun & .pcm) muxer
> - AV1 VAAPI decoder
> - adenorm filter
> +- Add ZLAV format to DHAV demuxer
>
>
> version 4.3:
> diff --git a/libavformat/dhav.c b/libavformat/dhav.c
> index 53deaff77e..40c2cc78b0 100644
> --- a/libavformat/dhav.c
> +++ b/libavformat/dhav.c
> @@ -1,5 +1,5 @@
> /*
> - * DHAV demuxer
> + * DHAV/ZLAV demuxer
> *
> * Copyright (c) 2018 Paul B Mahol
> *
> @@ -57,7 +57,7 @@ static int dhav_probe(const AVProbeData *p)
> if (!memcmp(p->buf, "DAHUA", 5))
> return AVPROBE_SCORE_MAX;
>
> -if (memcmp(p->buf, "DHAV", 4))
> +if (memcmp(p->buf, "DHAV", 4) && memcmp(p->buf, "ZLAV", 4))
> return 0;
>
> if (p->buf[4] == 0xf0 ||
> @@ -163,6 +163,19 @@ static int parse_ext(AVFormatContext *s, int
> length)
> return 0;
> }
>
> +static int read_start_tag(AVIOContext *pb)
> +{
> +unsigned int start_tag = avio_rl32(pb);
> +return start_tag == MKTAG('D','H','A','V') || start_tag ==
> MKTAG('Z','L','A','V');
> +}
> +
> +static int read_end_tag(AVIOContext *pb)
> +{
> +unsigned int end_tag = avio_rl32(pb);
> +return end_tag == MKTAG('d','h','a','v') || end_tag ==
> MKTAG('z','l','a','v');
> +}
> +
> +
> static int read_chunk(AVFormatContext *s)
> {
> DHAVContext *dhav = s->priv_data;
> @@ -173,11 +186,11 @@ static int read_chunk(AVFormatContext *s)
> if (avio_feof(s->pb))
> return AVERROR_EOF;
>
> -if (avio_rl32(s->pb) != MKTAG('D','H','A','V')) {
> +if (!read_start_tag(s->pb)) {
> dhav->last_good_pos += 0x8000;
> avio_seek(s->pb, dhav->last_good_pos, SEEK_SET);
>
> -while (avio_rl32(s->pb) != MKTAG('D','H','A','V')) {
> +while (!read_start_tag(s->pb)) {
> if (avio_feof(s->pb))
> return AVERROR_EOF;
> dhav->last_good_pos += 0x8000;
> @@ -247,7 +260,7 @@ static int64_t get_duration(AVFormatContext *s)
> return 0;
>
> avio_seek(s->pb, avio_size(s->pb) - 8, SEEK_SET);
> -if (avio_rl32(s->pb) == MKTAG('d','h','a','v')) {
> +if (read_end_tag(s->pb)) {
> int seek_back = avio_rl32(s->pb);
>
> avio_seek(s->pb, -seek_back, SEEK_CUR);
> @@ -281,12 +294,12 @@ static int dhav_read_header(AVFormatContext *s)
> avio_skip(s->pb, 0x400 - 5);
> dhav->last_good_pos = avio_tell(s->pb);
> } else {
> -if (!memcmp(signature, "DHAV", 4)) {
> +if (!memcmp(signature, "DHAV", 4) || !memcmp(signature,
> "ZLAV", 4)) {
> avio_seek(s->pb, -5, SEEK_CUR);
> dhav->last_good_pos = avio_tell(s->pb);
> } else if (s->pb->seekable) {
> avio_seek(s->pb, avio_size(s->pb) - 8, SEEK_SET);
> -while (avio_rl32(s->pb) == MKTAG('d','h','a','v')) {
> +while (read_end_tag(s->pb)) {
> int seek_back;
>
> seek_back = avio_rl32(s->pb) + 8;
> @@ -409,7 +422,7 @@ retry:
> stream_index = dhav->type == 0xf0 ? dhav->audio_stream_index :
> dhav->video_stream_index;
> if (stream_index < 0) {
> avio_skip(s->pb, ret);
> -if (avio_rl32(s->pb) == MKTAG('d','h','a','v'))
> +if (read_end_tag(s->pb))
> avio_skip(s->pb, 4);
> goto retry;
> }
> @@ -425,7 +438,7 @@ retry:
> if (pkt->stream_index >= 0)
> pkt->pts = get_pts(s, pkt->stream_index);
> pkt->pos = dhav->last_good_pos;
> -if (avio_rl32(s->pb) == MKTAG('d','h','a','v'))
> +if (read_end_tag(s->pb))
> avio_skip(s->pb, 4);
>
> return ret;
> diff --git a/libavformat/version.h b/libavformat/version.h
> index ddcca9ae50..b43193bcb1 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@ -32,7 +32,7 @@
> // Major bumping may affect Ticket5467, 5421, 5451(compatibility with
> Chromium)
> // Also please add any ticket numbers that you believe might be
> affected here
> #define LIBAVFORMAT_VERSION_MAJOR 58
> -#define LIBAVFORMAT_VERSION_MINOR 64
> +#define LIBAVFORMAT_VERSION_MINOR 65
> #define LIBAVFORMAT_VERSION_MICRO 100
>
> #define LIBAVFORMAT_VERSION_INT
> AV_VERSION_INT(LIBAVFORMAT_VERS
Re: [FFmpeg-devel] [PATCH v2] avformat/dhav: also support ZLAV packets
On 8/11/20 7:41 pm, Michael Keeley wrote:
Some DVRs (e.g. D7008FH made by iSmart Cities (Zhuhai) Limited) output the same
format .dav file,
but use ZLAV/zlav tags to delimit the packets instead of DHAV/dhav.
Signed-off-by: Michael Keeley
---
Changelog | 1 +
libavformat/dhav.c| 31 ++-
libavformat/version.h | 2 +-
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/Changelog b/Changelog
index 0ea1901bbe..a56216543d 100644
--- a/Changelog
+++ b/Changelog
@@ -41,6 +41,7 @@ version :
- LEGO Racers ALP (.tun & .pcm) muxer
- AV1 VAAPI decoder
- adenorm filter
+- Add ZLAV format to DHAV demuxer
Just make this "ZLAV demuxer" or something similar.
version 4.3:
diff --git a/libavformat/dhav.c b/libavformat/dhav.c
index 53deaff77e..40c2cc78b0 100644
--- a/libavformat/dhav.c
+++ b/libavformat/dhav.c
@@ -1,5 +1,5 @@
/*
- * DHAV demuxer
+ * DHAV/ZLAV demuxer
*
* Copyright (c) 2018 Paul B Mahol
*
@@ -57,7 +57,7 @@ static int dhav_probe(const AVProbeData *p)
if (!memcmp(p->buf, "DAHUA", 5))
return AVPROBE_SCORE_MAX;
-if (memcmp(p->buf, "DHAV", 4))
+if (memcmp(p->buf, "DHAV", 4) && memcmp(p->buf, "ZLAV", 4))
return 0;
if (p->buf[4] == 0xf0 ||
@@ -163,6 +163,19 @@ static int parse_ext(AVFormatContext *s, int length)
return 0;
}
+static int read_start_tag(AVIOContext *pb)
+{
+unsigned int start_tag = avio_rl32(pb);
+return start_tag == MKTAG('D','H','A','V') || start_tag ==
MKTAG('Z','L','A','V');
+}
+
+static int read_end_tag(AVIOContext *pb)
+{
+unsigned int end_tag = avio_rl32(pb);
+return end_tag == MKTAG('d','h','a','v') || end_tag ==
MKTAG('z','l','a','v');
+}
+
+
static int read_chunk(AVFormatContext *s)
{
DHAVContext *dhav = s->priv_data;
@@ -173,11 +186,11 @@ static int read_chunk(AVFormatContext *s)
if (avio_feof(s->pb))
return AVERROR_EOF;
-if (avio_rl32(s->pb) != MKTAG('D','H','A','V')) {
+if (!read_start_tag(s->pb)) {
dhav->last_good_pos += 0x8000;
avio_seek(s->pb, dhav->last_good_pos, SEEK_SET);
-while (avio_rl32(s->pb) != MKTAG('D','H','A','V')) {
+while (!read_start_tag(s->pb)) {
if (avio_feof(s->pb))
return AVERROR_EOF;
dhav->last_good_pos += 0x8000;
@@ -247,7 +260,7 @@ static int64_t get_duration(AVFormatContext *s)
return 0;
avio_seek(s->pb, avio_size(s->pb) - 8, SEEK_SET);
-if (avio_rl32(s->pb) == MKTAG('d','h','a','v')) {
+if (read_end_tag(s->pb)) {
int seek_back = avio_rl32(s->pb);
avio_seek(s->pb, -seek_back, SEEK_CUR);
@@ -281,12 +294,12 @@ static int dhav_read_header(AVFormatContext *s)
avio_skip(s->pb, 0x400 - 5);
dhav->last_good_pos = avio_tell(s->pb);
} else {
-if (!memcmp(signature, "DHAV", 4)) {
+if (!memcmp(signature, "DHAV", 4) || !memcmp(signature, "ZLAV", 4)) {
avio_seek(s->pb, -5, SEEK_CUR);
dhav->last_good_pos = avio_tell(s->pb);
} else if (s->pb->seekable) {
avio_seek(s->pb, avio_size(s->pb) - 8, SEEK_SET);
-while (avio_rl32(s->pb) == MKTAG('d','h','a','v')) {
+while (read_end_tag(s->pb)) {
int seek_back;
seek_back = avio_rl32(s->pb) + 8;
@@ -409,7 +422,7 @@ retry:
stream_index = dhav->type == 0xf0 ? dhav->audio_stream_index :
dhav->video_stream_index;
if (stream_index < 0) {
avio_skip(s->pb, ret);
-if (avio_rl32(s->pb) == MKTAG('d','h','a','v'))
+if (read_end_tag(s->pb))
avio_skip(s->pb, 4);
goto retry;
}
@@ -425,7 +438,7 @@ retry:
if (pkt->stream_index >= 0)
pkt->pts = get_pts(s, pkt->stream_index);
pkt->pos = dhav->last_good_pos;
-if (avio_rl32(s->pb) == MKTAG('d','h','a','v'))
+if (read_end_tag(s->pb))
avio_skip(s->pb, 4);
return ret;
diff --git a/libavformat/version.h b/libavformat/version.h
index ddcca9ae50..b43193bcb1 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
// Major bumping may affect Ticket5467, 5421, 5451(compatibility with
Chromium)
// Also please add any ticket numbers that you believe might be affected here
#define LIBAVFORMAT_VERSION_MAJOR 58
-#define LIBAVFORMAT_VERSION_MINOR 64
+#define LIBAVFORMAT_VERSION_MINOR 65
#define LIBAVFORMAT_VERSION_MICRO 100
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
This looks mostly alright to me at a glance.
One thing to note, this would accept packets starting with "DHAV" and ending
with "zlav" (and vice versa).
Could this be a problem? If so, might it be worth storing the current "type"
and ensuring you get the correct delimiter?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.or
[FFmpeg-devel] [PATCH 2/2] avcodec/av1dec: derive skip_mode_frame_idx only where it's used
No hwaccel other than nvdec cares about this field
Signed-off-by: James Almer
---
libavcodec/av1dec.c| 78 --
libavcodec/av1dec.h| 2 --
libavcodec/nvdec_av1.c | 72 +++---
3 files changed, 68 insertions(+), 84 deletions(-)
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index c8f9152451..7999ff6692 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -145,78 +145,6 @@ static void global_motion_params(AV1DecContext *s)
}
}
-static int get_relative_dist(const AV1RawSequenceHeader *seq,
- unsigned int a, unsigned int b)
-{
-unsigned int diff = a - b;
-unsigned int m = 1 << seq->order_hint_bits_minus_1;
-return (diff & (m - 1)) - (diff & m);
-}
-
-static void skip_mode_params(AV1DecContext *s)
-{
-const AV1RawFrameHeader *header = s->raw_frame_header;
-const AV1RawSequenceHeader *seq = s->raw_seq;
-
-int forward_idx, backward_idx;
-int forward_hint, backward_hint;
-int second_forward_idx, second_forward_hint;
-int ref_hint, dist, i;
-
-if (!header->skip_mode_present)
-return;
-
-forward_idx = -1;
-backward_idx = -1;
-for (i = 0; i < AV1_REFS_PER_FRAME; i++) {
-ref_hint =
s->ref[header->ref_frame_idx[i]].raw_frame_header->order_hint;
-dist = get_relative_dist(seq, ref_hint, header->order_hint);
-if (dist < 0) {
-if (forward_idx < 0 ||
-get_relative_dist(seq, ref_hint, forward_hint) > 0) {
-forward_idx = i;
-forward_hint = ref_hint;
-}
-} else if (dist > 0) {
-if (backward_idx < 0 ||
-get_relative_dist(seq, ref_hint, backward_hint) < 0) {
-backward_idx = i;
-backward_hint = ref_hint;
-}
-}
-}
-
-if (forward_idx < 0) {
-return;
-} else if (backward_idx >= 0) {
-s->cur_frame.skip_mode_frame_idx[0] =
-AV1_REF_FRAME_LAST + FFMIN(forward_idx, backward_idx);
-s->cur_frame.skip_mode_frame_idx[1] =
-AV1_REF_FRAME_LAST + FFMAX(forward_idx, backward_idx);
-return;
-}
-
-second_forward_idx = -1;
-for (i = 0; i < AV1_REFS_PER_FRAME; i++) {
-ref_hint =
s->ref[header->ref_frame_idx[i]].raw_frame_header->order_hint;
-if (get_relative_dist(seq, ref_hint, forward_hint) < 0) {
-if (second_forward_idx < 0 ||
-get_relative_dist(seq, ref_hint, second_forward_hint) > 0) {
-second_forward_idx = i;
-second_forward_hint = ref_hint;
-}
-}
-}
-
-if (second_forward_idx < 0)
-return;
-
-s->cur_frame.skip_mode_frame_idx[0] =
-AV1_REF_FRAME_LAST + FFMIN(forward_idx, second_forward_idx);
-s->cur_frame.skip_mode_frame_idx[1] =
-AV1_REF_FRAME_LAST + FFMAX(forward_idx, second_forward_idx);
-}
-
static int init_tile_data(AV1DecContext *s)
{
@@ -415,8 +343,6 @@ static void av1_frame_unref(AVCodecContext *avctx, AV1Frame
*f)
av_buffer_unref(&f->header_ref);
f->raw_frame_header = NULL;
f->spatial_id = f->temporal_id = 0;
-memset(f->skip_mode_frame_idx, 0,
- 2 * sizeof(uint8_t));
}
static int av1_frame_ref(AVCodecContext *avctx, AV1Frame *dst, const AV1Frame
*src)
@@ -448,9 +374,6 @@ static int av1_frame_ref(AVCodecContext *avctx, AV1Frame
*dst, const AV1Frame *s
memcpy(dst->gm_params,
src->gm_params,
AV1_NUM_REF_FRAMES * 6 * sizeof(int32_t));
-memcpy(dst->skip_mode_frame_idx,
- src->skip_mode_frame_idx,
- 2 * sizeof(uint8_t));
return 0;
@@ -727,7 +650,6 @@ static int get_current_frame(AVCodecContext *avctx)
}
global_motion_params(s);
-skip_mode_params(s);
return ret;
}
diff --git a/libavcodec/av1dec.h b/libavcodec/av1dec.h
index bc6ae68d1a..7f07aa9f7a 100644
--- a/libavcodec/av1dec.h
+++ b/libavcodec/av1dec.h
@@ -44,8 +44,6 @@ typedef struct AV1Frame {
uint8_t gm_type[AV1_NUM_REF_FRAMES];
int32_t gm_params[AV1_NUM_REF_FRAMES][6];
-
-uint8_t skip_mode_frame_idx[2];
} AV1Frame;
typedef struct TileGroupInfo {
diff --git a/libavcodec/nvdec_av1.c b/libavcodec/nvdec_av1.c
index 1a553902bc..d1161dd258 100644
--- a/libavcodec/nvdec_av1.c
+++ b/libavcodec/nvdec_av1.c
@@ -64,6 +64,68 @@ static int get_coded_lossless_param(const AV1DecContext *s)
return 1;
}
+static int get_relative_dist(const AV1RawSequenceHeader *seq,
+ unsigned int a, unsigned int b)
+{
+unsigned int diff = a - b;
+unsigned int m = 1 << seq->order_hint_bits_minus_1;
+return (diff & (m - 1)) - (diff & m);
+}
+
+static void skip_mode_params(const AV1DecContext *s, uint8_t
*skip_mode_frame_idx)
+{
+const AV1RawFrameHeader *frame_header = s->raw_frame_header;
+const AV1RawSequenceHeader *seq = s->raw_se
[FFmpeg-devel] [PATCH 1/2] avcodec/av1dec: derive coded_lossless only where it's used
No hwaccel other than nvdec cares about this field
Signed-off-by: James Almer
---
libavcodec/av1dec.c| 33 -
libavcodec/av1dec.h| 2 --
libavcodec/nvdec_av1.c | 29 -
3 files changed, 28 insertions(+), 36 deletions(-)
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index c1967f03bd..c8f9152451 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -217,36 +217,6 @@ static void skip_mode_params(AV1DecContext *s)
AV1_REF_FRAME_LAST + FFMAX(forward_idx, second_forward_idx);
}
-static void coded_lossless_param(AV1DecContext *s)
-{
-const AV1RawFrameHeader *header = s->raw_frame_header;
-int i;
-
-if (header->delta_q_y_dc || header->delta_q_u_ac ||
-header->delta_q_u_dc || header->delta_q_v_ac ||
-header->delta_q_v_dc) {
-s->cur_frame.coded_lossless = 0;
-return;
-}
-
-s->cur_frame.coded_lossless = 1;
-for (i = 0; i < AV1_MAX_SEGMENTS; i++) {
-int qindex;
-if (header->feature_enabled[i][AV1_SEG_LVL_ALT_Q]) {
-qindex = (header->base_q_idx +
- header->feature_value[i][AV1_SEG_LVL_ALT_Q]);
-} else {
-qindex = header->base_q_idx;
-}
-qindex = av_clip_uintp2(qindex, 8);
-
-if (qindex) {
-s->cur_frame.coded_lossless = 0;
-return;
-}
-}
-}
-
static int init_tile_data(AV1DecContext *s)
{
@@ -447,7 +417,6 @@ static void av1_frame_unref(AVCodecContext *avctx, AV1Frame
*f)
f->spatial_id = f->temporal_id = 0;
memset(f->skip_mode_frame_idx, 0,
2 * sizeof(uint8_t));
-f->coded_lossless = 0;
}
static int av1_frame_ref(AVCodecContext *avctx, AV1Frame *dst, const AV1Frame
*src)
@@ -482,7 +451,6 @@ static int av1_frame_ref(AVCodecContext *avctx, AV1Frame
*dst, const AV1Frame *s
memcpy(dst->skip_mode_frame_idx,
src->skip_mode_frame_idx,
2 * sizeof(uint8_t));
-dst->coded_lossless = src->coded_lossless;
return 0;
@@ -760,7 +728,6 @@ static int get_current_frame(AVCodecContext *avctx)
global_motion_params(s);
skip_mode_params(s);
-coded_lossless_param(s);
return ret;
}
diff --git a/libavcodec/av1dec.h b/libavcodec/av1dec.h
index 4b218f64bb..bc6ae68d1a 100644
--- a/libavcodec/av1dec.h
+++ b/libavcodec/av1dec.h
@@ -46,8 +46,6 @@ typedef struct AV1Frame {
int32_t gm_params[AV1_NUM_REF_FRAMES][6];
uint8_t skip_mode_frame_idx[2];
-
-uint8_t coded_lossless;
} AV1Frame;
typedef struct TileGroupInfo {
diff --git a/libavcodec/nvdec_av1.c b/libavcodec/nvdec_av1.c
index f6267b1d96..1a553902bc 100644
--- a/libavcodec/nvdec_av1.c
+++ b/libavcodec/nvdec_av1.c
@@ -37,6 +37,33 @@ static int get_bit_depth_from_seq(const AV1RawSequenceHeader
*seq)
return 8;
}
+static int get_coded_lossless_param(const AV1DecContext *s)
+{
+const AV1RawFrameHeader *frame_header = s->raw_frame_header;
+
+if (frame_header->delta_q_y_dc || frame_header->delta_q_u_ac ||
+frame_header->delta_q_u_dc || frame_header->delta_q_v_ac ||
+frame_header->delta_q_v_dc) {
+return 0;
+}
+
+for (int i = 0; i < AV1_MAX_SEGMENTS; i++) {
+int qindex;
+if (frame_header->feature_enabled[i][AV1_SEG_LVL_ALT_Q]) {
+qindex = (frame_header->base_q_idx +
+ frame_header->feature_value[i][AV1_SEG_LVL_ALT_Q]);
+} else {
+qindex = frame_header->base_q_idx;
+}
+qindex = av_clip_uintp2(qindex, 8);
+
+if (qindex)
+return 0;
+}
+
+return 1;
+}
+
static int nvdec_av1_start_frame(AVCodecContext *avctx, const uint8_t *buffer,
uint32_t size)
{
const AV1DecContext *s = avctx->priv_data;
@@ -119,7 +146,7 @@ static int nvdec_av1_start_frame(AVCodecContext *avctx,
const uint8_t *buffer, u
.delta_q_present = frame_header->delta_q_present,
.delta_q_res = frame_header->delta_q_res,
.using_qmatrix= frame_header->using_qmatrix,
-.coded_lossless = s->cur_frame.coded_lossless,
+.coded_lossless = get_coded_lossless_param(s),
.use_superres = frame_header->use_superres,
.tx_mode = frame_header->tx_mode,
.reference_mode = frame_header->reference_select,
--
2.29.2
___
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 v2] avdevice/decklink_dec: map the raw_format instead of hardcode
From: Limin Wang
Signed-off-by: Limin Wang
---
libavdevice/decklink_common.h | 9 +
libavdevice/decklink_dec.cpp | 3 ++-
libavdevice/decklink_dec_c.c | 12 ++--
3 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index f35bd9a..ac15488 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -162,6 +162,15 @@ IDeckLinkIterator *CreateDeckLinkIteratorInstance(void);
typedef uint32_t buffercount_type;
#endif
+static const BMDPixelFormat decklink_raw_format_map[] = {
+BMDPixelFormat(0),
+bmdFormat8BitYUV,
+bmdFormat10BitYUV,
+bmdFormat8BitARGB,
+bmdFormat8BitBGRA,
+bmdFormat10BitRGB,
+};
+
static const BMDAudioConnection decklink_audio_connection_map[] = {
(BMDAudioConnection)0,
bmdAudioConnectionEmbedded,
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 6517b9d..049e133 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -1152,7 +1152,8 @@ av_cold int ff_decklink_read_header(AVFormatContext
*avctx)
ctx->video_pts_source = cctx->video_pts_source;
ctx->draw_bars = cctx->draw_bars;
ctx->audio_depth = cctx->audio_depth;
-ctx->raw_format = (BMDPixelFormat)cctx->raw_format;
+if (cctx->raw_format > 0 && (unsigned int)cctx->raw_format <
FF_ARRAY_ELEMS(decklink_raw_format_map))
+ctx->raw_format = decklink_raw_format_map[cctx->raw_format];
cctx->ctx = ctx;
/* Check audio channel option for valid values: 2, 8 or 16 */
diff --git a/libavdevice/decklink_dec_c.c b/libavdevice/decklink_dec_c.c
index f3fdcd3..66786db 100644
--- a/libavdevice/decklink_dec_c.c
+++ b/libavdevice/decklink_dec_c.c
@@ -34,12 +34,12 @@ static const AVOption options[] = {
{ "list_formats", "list supported formats" , OFFSET(list_formats),
AV_OPT_TYPE_INT , { .i64 = 0 }, 0, 1, DEC },
{ "format_code", "set format by fourcc", OFFSET(format_code),
AV_OPT_TYPE_STRING, { .str = NULL}, 0, 0, DEC },
{ "raw_format", "pixel format to be returned by the card when capturing"
, OFFSET(raw_format), AV_OPT_TYPE_INT, { .i64 = 0}, 0, UINT_MAX, DEC,
"raw_format" },
-{ "auto", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 0
}, 0, 0, DEC, "raw_format"},
-{ "uyvy422", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
MKBETAG('2','v','u','y') }, 0, 0, DEC, "raw_format"},
-{ "yuv422p10", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
MKBETAG('v','2','1','0') }, 0, 0, DEC, "raw_format"},
-{ "argb", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 32
}, 0, 0, DEC, "raw_format"},
-{ "bgra", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
MKBETAG('B','G','R','A') }, 0, 0, DEC, "raw_format"},
-{ "rgb10", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
MKBETAG('r','2','1','0') }, 0, 0, DEC, "raw_format"},
+{ "auto", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 0 }, 0, 0, DEC,
"raw_format"},
+{ "uyvy422", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 1 }, 0, 0, DEC,
"raw_format"},
+{ "yuv422p10", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 2 }, 0, 0, DEC,
"raw_format"},
+{ "argb", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 3 }, 0, 0, DEC,
"raw_format"},
+{ "bgra", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 4 }, 0, 0, DEC,
"raw_format"},
+{ "rgb10", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 5 }, 0, 0, DEC,
"raw_format"},
{ "enable_klv","output klv if present in vanc", OFFSET(enable_klv),
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, DEC },
{ "teletext_lines", "teletext lines bitmask", OFFSET(teletext_lines),
AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, 0x7LL, DEC, "teletext_lines"},
{ "standard", NULL, 0,
AV_OPT_TYPE_CONST, { .i64 = 0x7fff9fffeLL}, 0, 0,DEC, "teletext_lines"},
--
1.8.3.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 v2] avdevice/decklink_dec: map the raw_format instead of
From: Limin Wang
Signed-off-by: Limin Wang
---
libavdevice/decklink_common.h | 9 +
libavdevice/decklink_dec.cpp | 3 ++-
libavdevice/decklink_dec_c.c | 12 ++--
3 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index f35bd9a..ac15488 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -162,6 +162,15 @@ IDeckLinkIterator *CreateDeckLinkIteratorInstance(void);
typedef uint32_t buffercount_type;
#endif
+static const BMDPixelFormat decklink_raw_format_map[] = {
+BMDPixelFormat(0),
+bmdFormat8BitYUV,
+bmdFormat10BitYUV,
+bmdFormat8BitARGB,
+bmdFormat8BitBGRA,
+bmdFormat10BitRGB,
+};
+
static const BMDAudioConnection decklink_audio_connection_map[] = {
(BMDAudioConnection)0,
bmdAudioConnectionEmbedded,
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 6517b9d..049e133 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -1152,7 +1152,8 @@ av_cold int ff_decklink_read_header(AVFormatContext
*avctx)
ctx->video_pts_source = cctx->video_pts_source;
ctx->draw_bars = cctx->draw_bars;
ctx->audio_depth = cctx->audio_depth;
-ctx->raw_format = (BMDPixelFormat)cctx->raw_format;
+if (cctx->raw_format > 0 && (unsigned int)cctx->raw_format <
FF_ARRAY_ELEMS(decklink_raw_format_map))
+ctx->raw_format = decklink_raw_format_map[cctx->raw_format];
cctx->ctx = ctx;
/* Check audio channel option for valid values: 2, 8 or 16 */
diff --git a/libavdevice/decklink_dec_c.c b/libavdevice/decklink_dec_c.c
index f3fdcd3..66786db 100644
--- a/libavdevice/decklink_dec_c.c
+++ b/libavdevice/decklink_dec_c.c
@@ -34,12 +34,12 @@ static const AVOption options[] = {
{ "list_formats", "list supported formats" , OFFSET(list_formats),
AV_OPT_TYPE_INT , { .i64 = 0 }, 0, 1, DEC },
{ "format_code", "set format by fourcc", OFFSET(format_code),
AV_OPT_TYPE_STRING, { .str = NULL}, 0, 0, DEC },
{ "raw_format", "pixel format to be returned by the card when capturing"
, OFFSET(raw_format), AV_OPT_TYPE_INT, { .i64 = 0}, 0, UINT_MAX, DEC,
"raw_format" },
-{ "auto", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 0
}, 0, 0, DEC, "raw_format"},
-{ "uyvy422", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
MKBETAG('2','v','u','y') }, 0, 0, DEC, "raw_format"},
-{ "yuv422p10", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
MKBETAG('v','2','1','0') }, 0, 0, DEC, "raw_format"},
-{ "argb", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 32
}, 0, 0, DEC, "raw_format"},
-{ "bgra", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
MKBETAG('B','G','R','A') }, 0, 0, DEC, "raw_format"},
-{ "rgb10", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
MKBETAG('r','2','1','0') }, 0, 0, DEC, "raw_format"},
+{ "auto", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 0 }, 0, 0, DEC,
"raw_format"},
+{ "uyvy422", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 1 }, 0, 0, DEC,
"raw_format"},
+{ "yuv422p10", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 2 }, 0, 0, DEC,
"raw_format"},
+{ "argb", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 3 }, 0, 0, DEC,
"raw_format"},
+{ "bgra", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 4 }, 0, 0, DEC,
"raw_format"},
+{ "rgb10", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 5 }, 0, 0, DEC,
"raw_format"},
{ "enable_klv","output klv if present in vanc", OFFSET(enable_klv),
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, DEC },
{ "teletext_lines", "teletext lines bitmask", OFFSET(teletext_lines),
AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, 0x7LL, DEC, "teletext_lines"},
{ "standard", NULL, 0,
AV_OPT_TYPE_CONST, { .i64 = 0x7fff9fffeLL}, 0, 0,DEC, "teletext_lines"},
--
1.8.3.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 2/2] avcodec/av1dec: derive skip_mode_frame_idx only where it's used
I still strongly dislike this whole thing. The same logic is ran essentially twice. But I also really don't like putting all this stuff into the hwaccel. That's way more logic than a hwaccel integration should have to do. ___ 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/av1dec: derive skip_mode_frame_idx only where it's used
On 11/14/2020 12:01 PM, Timo Rothenpieler wrote: I still strongly dislike this whole thing. The same logic is ran essentially twice. But I also really don't like putting all this stuff into the hwaccel. That's way more logic than a hwaccel integration should have to do. Atm, only nvdec cares about these fields, and since all reference AV1RawFrameHeader are now available in hwaccel->start_frame(), it seemed proper to have it there. Eventually, a software implementation will be added to av1dec, and this code will have to be moved back. But if you are really against this set, then I'll withdraw it. ___ 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 v7 1/8] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair
On Tue, Nov 3, 2020 at 7:47 PM Artem Galin wrote: > Adding DX11 relevant device type checks and adjusting callbacks with > proper MediaSDK pair type support. > > Extending structure for proper MediaSDK pair type support. > > Signed-off-by: Artem Galin > . Patchset obviously closes the gap of DirectX 11 support and already checked with several apps that use FFMPEG. Any particular review comments should be yet expected? Changes seem to be straight forward and incorporate prev. comments. thank in advance regards Max ___ 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 v2] configure: fix the bigendian test
There are two issues:
When build systems enable LTO in CFLAGS, the unused global integer
does not make it into the compiled object file. As a workaround,
check if the compiler understands -fno-lto and append it after
CFLAGS while building the endianness test.
The hexdump output is line-wrapped, so the expected value will not
be matched when its four bytes are split across two lines. Use the
POSIX "-A n" option to disable printing input offsets and delete
all newline characters to output continuous hex values to grep.
Signed-off-by: David Michael
---
configure | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 51e43fbf66..47160b4bbc 100755
--- a/configure
+++ b/configure
@@ -5756,10 +5756,11 @@ done
check_cc pragma_deprecated "" '_Pragma("GCC diagnostic ignored
\"-Wdeprecated-declarations\"")'
# The global variable ensures the bits appear unchanged in the object file.
-test_cc
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/av1dec: derive skip_mode_frame_idx only where it's used
On 14.11.2020 16:08, James Almer wrote: On 11/14/2020 12:01 PM, Timo Rothenpieler wrote: I still strongly dislike this whole thing. The same logic is ran essentially twice. But I also really don't like putting all this stuff into the hwaccel. That's way more logic than a hwaccel integration should have to do. Atm, only nvdec cares about these fields, and since all reference AV1RawFrameHeader are now available in hwaccel->start_frame(), it seemed proper to have it there. Eventually, a software implementation will be added to av1dec, and this code will have to be moved back. But if you are really against this set, then I'll withdraw it. An ideal solution would would only run this logic once, in the AV1 decoder/parser. Which right now is in a bit of temporary not-really-a-decoder limbo, so of course it's not perfect. So if this will likely be needed for the software decoder in the future, leaving it there in the first place seems better? Or would it get in the way for decoder development? I don't want to hold up development on that front. ___ 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/av1dec: derive skip_mode_frame_idx only where it's used
On 11/14/2020 2:32 PM, Timo Rothenpieler wrote: On 14.11.2020 16:08, James Almer wrote: On 11/14/2020 12:01 PM, Timo Rothenpieler wrote: I still strongly dislike this whole thing. The same logic is ran essentially twice. But I also really don't like putting all this stuff into the hwaccel. That's way more logic than a hwaccel integration should have to do. Atm, only nvdec cares about these fields, and since all reference AV1RawFrameHeader are now available in hwaccel->start_frame(), it seemed proper to have it there. Eventually, a software implementation will be added to av1dec, and this code will have to be moved back. But if you are really against this set, then I'll withdraw it. An ideal solution would would only run this logic once, in the AV1 decoder/parser. Which right now is in a bit of temporary not-really-a-decoder limbo, so of course it's not perfect. So if this will likely be needed for the software decoder in the future, leaving it there in the first place seems better? Or would it get in the way for decoder development? Best case scenario, it's used. Worst case scenario, it's replaced. So yes, in the long run it may be better to leave it here. My intention with moving it to the only hwaccel uses it was to ensure it's not run for those that don't. Since you want to keep nvdec_av1.c as clean as possible, I'm withdrawing this set. I don't want to hold up development on that front. ___ 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".
Re: [FFmpeg-devel] [PATCH v2 2/3] libavcodec: add a new AV_CODEC_EXPORT_DATA_FILM_GRAIN flag and option
Nov 14, 2020, 11:23 by an...@khirnov.net:
> Quoting Lynne (2020-11-12 18:42:22)
>
>> This introduces a new field to allow decoders to export their film grain
>> parameters.
>> Will be used by the next patch.
>>
>> Patch attached.
>> From d5d5e1e5f90938ac5cfa462efc13658ab411246b Mon Sep 17 00:00:00 2001
>> From: Lynne
>> Date: Thu, 12 Nov 2020 17:46:09 +0100
>> Subject: [PATCH v2 2/3] libavcodec: add a new AV_CODEC_EXPORT_DATA_FILM_GRAIN
>> flag and option
>>
>> This introduces a new field to allow decoders to export their film grain
>> parameters.
>> Will be used by the next patch.
>> ---
>> doc/APIchanges | 3 +++
>> libavcodec/avcodec.h | 5 +
>> libavcodec/options_table.h | 1 +
>> libavcodec/version.h | 4 ++--
>> 4 files changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index 41248724d9..9d0ddb4ff6 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>>
>> API changes, most recent first:
>>
>> +2020-xx-xx - xx - lavc 58.113.100 - avcodec.h
>> + Adds a new flag AV_CODEC_EXPORT_DATA_FILM_GRAIN for export_side_data.
>> +
>> 2020-xx-xx - xx - lavu 56.61.100 - film_grain_params.h
>> Adds a new API for extracting codec film grain parameters as side data.
>> Adds a new AVFrameSideDataType entry AV_FRAME_DATA_FILM_GRAIN_PARAMS for it.
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index 20af3ef00d..5047da0f6a 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -410,6 +410,11 @@ typedef struct RcOverride{
>> * Export the AVVideoEncParams structure through frame side data.
>> */
>> #define AV_CODEC_EXPORT_DATA_VIDEO_ENC_PARAMS (1 << 2)
>> +/**
>> + * Decoding only.
>> + * Do not apply film grain, export it instead.
>>
>
> Could someone want to both apply AND export it?
>
Analyzers. In which case they could use a film grain filter to apply it. But
that's a fringe
use-case for this flag, this mainly targets video players and transcoding,
where the
bandwidth/frames savings can be significant.
There's a WIP Vulkan filter to apply it, and if there's popular demand, the
libdav1d code
could be ported as a software filter.
___
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/av1dec: derive skip_mode_frame_idx only where it's used
On 14/11/2020 17:32, Timo Rothenpieler wrote: On 14.11.2020 16:08, James Almer wrote: On 11/14/2020 12:01 PM, Timo Rothenpieler wrote: I still strongly dislike this whole thing. The same logic is ran essentially twice. While it's applying the same method it is not doing the same thing, because different inputs are being used. An ideal solution would would only run this logic once, in the AV1 decoder/parser. No it wouldn't. You can't do it in the parser, because the parser doesn't know which frames have been successfully decoded. The parser still has to run the standard-dictated logic, though, because it needs to know whether the skip_mode_present syntax element is present. The other hwaccel implementations have made the decision to push it into the driver, which definitely knows which frames have decoded successfully - I'm pretty sure that's the right answer for a correct result. Nvdec forcing us to guess in the wrapper layer which doesn't have complete information is a problem, but we can at least make a better guess than the parser did. - Mark ___ 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 v2] configure: fix the bigendian test
Am Sa., 14. Nov. 2020 um 18:22 Uhr schrieb David Michael : > > There are two issues: > > When build systems enable LTO in CFLAGS, the unused global integer > does not make it into the compiled object file. As a workaround, > check if the compiler understands -fno-lto and append it after > CFLAGS while building the endianness test. > > The hexdump output is line-wrapped, so the expected value will not > be matched when its four bytes are split across two lines. Use the > POSIX "-A n" option to disable printing input offsets and delete > all newline characters to output continuous hex values to grep. Please explain how we can reproduce the issue (configure line, compiler, os). Carl Eugen ___ 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 v2] configure: fix the bigendian test
On Sat, Nov 14, 2020 at 2:06 PM Carl Eugen Hoyos wrote: > Am Sa., 14. Nov. 2020 um 18:22 Uhr schrieb David Michael > : > > > > There are two issues: > > > > When build systems enable LTO in CFLAGS, the unused global integer > > does not make it into the compiled object file. As a workaround, > > check if the compiler understands -fno-lto and append it after > > CFLAGS while building the endianness test. > > > > The hexdump output is line-wrapped, so the expected value will not > > be matched when its four bytes are split across two lines. Use the > > POSIX "-A n" option to disable printing input offsets and delete > > all newline characters to output continuous hex values to grep. > > Please explain how we can reproduce the issue (configure line, > compiler, os). It's the same command I sent you for the v1 patch. Just configure it to cross-compile to a big-endian target with CFLAGS=-flto in the environment: CFLAGS=-flto ./configure --enable-cross-compile --host-cc=gcc --arch=powerpc --target-os=linux --cross-prefix=powerpc-unknown-linux-gnu- Thanks. David ___ 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] tools/target_dem_fuzzer: use avio_context_free() to free the fuzzer's AVIOContext
The doxy for avio_alloc_context() states it must be used for this.
Signed-off-by: James Almer
---
tools/target_dem_fuzzer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/target_dem_fuzzer.c b/tools/target_dem_fuzzer.c
index e4f41765d6..e5c41eea01 100644
--- a/tools/target_dem_fuzzer.c
+++ b/tools/target_dem_fuzzer.c
@@ -202,7 +202,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
}
end:
av_freep(&fuzzed_pb->buffer);
-av_freep(&fuzzed_pb);
+avio_context_free(&fuzzed_pb);
avformat_close_input(&avfmt);
return 0;
--
2.29.2
___
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/4] avformat/iff: Check size before skip
Fixes: Infinite loop
Fixes:
27292/clusterfuzz-testcase-minimized-ffmpeg_dem_IFF_fuzzer-5731168991051776
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/iff.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/iff.c b/libavformat/iff.c
index a70184f105..f017684620 100644
--- a/libavformat/iff.c
+++ b/libavformat/iff.c
@@ -259,6 +259,9 @@ static int parse_dsd_prop(AVFormatContext *s, AVStream *st,
uint64_t eof)
uint64_t size = avio_rb64(pb);
uint64_t orig_pos = avio_tell(pb);
+if (size >= INT64_MAX)
+return AVERROR_INVALIDDATA;
+
switch(tag) {
case MKTAG('A','B','S','S'):
if (size < 8)
--
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".
[FFmpeg-devel] [PATCH 2/4] avcodec/mv30: Use unsigned in idct_1d()
Fixes: signed integer overflow: 2110302399 + 39074947 cannot be represented in
type 'int'
Fixes:
27330/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MV30_fuzzer-5664923153334272
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/mv30.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mv30.c b/libavcodec/mv30.c
index 9f28199478..59088d84f8 100644
--- a/libavcodec/mv30.c
+++ b/libavcodec/mv30.c
@@ -102,7 +102,7 @@ static void get_qtable(int16_t *table, int quant, const
uint8_t *quant_tab)
}
}
-static inline void idct_1d(int *blk, int step)
+static inline void idct_1d(unsigned *blk, int step)
{
const unsigned t0 = blk[0 * step] + blk[4 * step];
const unsigned t1 = blk[0 * step] - blk[4 * step];
--
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".
[FFmpeg-devel] [PATCH 3/4] avformat/wavdec: More complete size check in find_guid()
Fixes: signed integer overflow: 9223372036854775807 + 8 cannot be represented
in type 'long'
Fixes:
27341/clusterfuzz-testcase-minimized-ffmpeg_dem_W64_fuzzer-5442833206738944
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/wavdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index a81f2c7a67..df6030a42d 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -666,7 +666,7 @@ static int64_t find_guid(AVIOContext *pb, const uint8_t
guid1[16])
while (!avio_feof(pb)) {
avio_read(pb, guid, 16);
size = avio_rl64(pb);
-if (size <= 24)
+if (size <= 24 || size > INT64_MAX - 8)
return AVERROR_INVALIDDATA;
if (!memcmp(guid, guid1, 16))
return size;
--
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".
[FFmpeg-devel] [PATCH 4/4] avcodec/mobiclip: Check mv against INT_MAX
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int' Fixes: 27369/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOBICLIP_fuzzer-5083469356728320 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/mobiclip.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/mobiclip.c b/libavcodec/mobiclip.c index 9fa88e84a0..8504959b22 100644 --- a/libavcodec/mobiclip.c +++ b/libavcodec/mobiclip.c @@ -1146,6 +1146,8 @@ static int predict_motion(AVCodecContext *avctx, mv.x = mv.x + get_se_golomb(gb); mv.y = mv.y + get_se_golomb(gb); } +if (mv.x >= INT_MAX || mv.y >= INT_MAX) +return AVERROR_INVALIDDATA; motion[offsetm].x = mv.x; motion[offsetm].y = mv.y; -- 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".
[FFmpeg-devel] [PATCH] avformat/mpegts: make sure mpegts_read_header always stops at the first pmt
mpegts_read_header stops parsing the file at the first PMT. However the check that ensured this was wrong because streams can also be added before the first PMT is received (e.g. EIT). So let's make sure we are in the header reading phase by checking if ts->pkt is unset instead of checking if the number of streams found so far is 0. Signed-off-by: Marton Balint --- libavformat/mpegts.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c index 80d010db6c..a2003c6632 100644 --- a/libavformat/mpegts.c +++ b/libavformat/mpegts.c @@ -2355,7 +2355,7 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t *section, int section_len goto out; // stop parsing after pmt, we found header -if (!ts->stream->nb_streams) +if (!ts->pkt) ts->stop_parse = 2; set_pmt_found(ts, h->id); -- 2.26.2 ___ 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 v2] configure: fix the bigendian test
Am Sa., 14. Nov. 2020 um 20:16 Uhr schrieb David Michael : > > On Sat, Nov 14, 2020 at 2:06 PM Carl Eugen Hoyos wrote: > > Am Sa., 14. Nov. 2020 um 18:22 Uhr schrieb David Michael > > : > > > > > > There are two issues: > > > > > > When build systems enable LTO in CFLAGS, the unused global integer > > > does not make it into the compiled object file. As a workaround, > > > check if the compiler understands -fno-lto and append it after > > > CFLAGS while building the endianness test. > > > > > > The hexdump output is line-wrapped, so the expected value will not > > > be matched when its four bytes are split across two lines. Use the > > > POSIX "-A n" option to disable printing input offsets and delete > > > all newline characters to output continuous hex values to grep. > > > > Please explain how we can reproduce the issue (configure line, > > compiler, os). > > It's the same command I sent you for the v1 patch. Just configure it > to cross-compile to a big-endian target with CFLAGS=-flto in the > environment: > > CFLAGS=-flto ./configure --enable-cross-compile --host-cc=gcc > --arch=powerpc --target-os=linux > --cross-prefix=powerpc-unknown-linux-gnu- Is the issue reproducible if you configure with "--enable-lto" instead of CFLAGS (I suspect FFmpeg does not support CFLAGS in general)? Carl Eugen ___ 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] avformat/dv: fix timestamps of audio packets in case of dropped corrupt audio frames
On Fri, 6 Nov 2020, Michael Niedermayer wrote: On Wed, Nov 04, 2020 at 10:44:56PM +0100, Marton Balint wrote: On Wed, 4 Nov 2020, Michael Niedermayer wrote: we have "millisecond" based formats, rounded timestamps we have "exact" cases, maybe the timebase being 1 packet/frame per tick we have "high precission" where the timebase is so precisse it doesnt matter This here though is a bit an oddball, the size if 1 PCM frame is 1 sample The timebase is not a millisecond based one, its not 1 frame either nor is it exact nor high precission. Its 1 video frame, and whatever amount of audio there is in the container which IIUC can differ from 1 video frame even rounded. maybe this just doesnt occur and each frame has a count of samples always rounded to the closes integer count for the video frame. The difference between the audio timestamp and the video timestamp for packets from the same DV frame is at most 0.3929636797*frame_duration as the specification says, as Dave quoted, so I don't see how the error can be bigger than this. It looks to me you are mixing timestamps coming from a demuxer, and timestamps you calculate by counting the number of demuxed/decoded audio samples or video frames. Synchronization is done using the former. But if for example some hardware was using internally a 16 sample buffer and only put multiplies of 16 samples in frames this would introduce a considerable amount of jitter in the timestamps in relation to the actual duration. And using async to fix this without introducing more problems might require some care. I still don't see why timestamp or duration jitter is a problem as long as the error is below frame_duration/2. You can safely use async with min_hard_comp set to frame_duration/2. Thats exactly what i meant. an async like filter which behaves differently or async with a different value there can mess this up. IMHO such mess up is ok when the input is corrupted or invalid. OTOH here it is valid and correct data. In general, don't you find it problematic that the dv demuxer can return different timestamps if you read packets sequentially and if you seek to the end of a file? It looks like a huge bug yes, this is not great but even with your patch you still have this effect when seeking to some point in time a player has to output video and audio to the user at an exact time and that will differ even with async from linear playbacks presentation which is not fixable if you insist on sample counting... I think you misunderstood me, or maybe i didnt state my opinion well, iam not saying that i consider what dv in git does good. Rather that there is a problem beyond what these patches fix. Some concept of timestamp accuracy independant of the distance of representable values would be usefull. if you take teh 1/25 or whatever they are based on dv timestamps and convert that to teh mpeg 90khz based ones thats not making it that accurate. OTOH if you take 1/25 based audio where each packet is 1/25sec worth of samples that very well might be sample accurate or even beyond. knowing this accuracy is usefull for configuring a async like filter or also in knowing how to deal with inconsistencies, is that timestamp jtter ? or the sample rate jittering / some droped samples ? Its important to know as in one instance its the timestamps that need adjustment while in the other the samples need adjustment ATM its down to the user to figure out on a file by file base how to deal or ignore this. Instead it should be possible for an automated system to compensate such issues ... OK, but the automated solution is far from trivial, e.g. it should start with a analysis of the file to check if the sample rate is accurate or not... And if it is not, is the difference constant througout the file? Then there are several methods to fix it and the user might have a preference. E.g consider audio clock "master" and duplicate/drop video frames. Or keep all video frames, but stretch audio (with or without pitch correction - and which filter you want for pitch correction? atempo? rubberband?). So making it automated is not trivial at all. Anyhow, is it OK to apply this patch then? Thanks, Marton ___ 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 v2] configure: fix the bigendian test
On Sat, Nov 14, 2020 at 6:57 PM Carl Eugen Hoyos wrote: > Am Sa., 14. Nov. 2020 um 20:16 Uhr schrieb David Michael > : > > On Sat, Nov 14, 2020 at 2:06 PM Carl Eugen Hoyos wrote: > > > Am Sa., 14. Nov. 2020 um 18:22 Uhr schrieb David Michael > > > : > > > > > > > > There are two issues: > > > > > > > > When build systems enable LTO in CFLAGS, the unused global integer > > > > does not make it into the compiled object file. As a workaround, > > > > check if the compiler understands -fno-lto and append it after > > > > CFLAGS while building the endianness test. > > > > > > > > The hexdump output is line-wrapped, so the expected value will not > > > > be matched when its four bytes are split across two lines. Use the > > > > POSIX "-A n" option to disable printing input offsets and delete > > > > all newline characters to output continuous hex values to grep. > > > > > > Please explain how we can reproduce the issue (configure line, > > > compiler, os). > > > > It's the same command I sent you for the v1 patch. Just configure it > > to cross-compile to a big-endian target with CFLAGS=-flto in the > > environment: > > > > CFLAGS=-flto ./configure --enable-cross-compile --host-cc=gcc > > --arch=powerpc --target-os=linux > > --cross-prefix=powerpc-unknown-linux-gnu- > > Is the issue reproducible if you configure with "--enable-lto" instead > of CFLAGS (I suspect FFmpeg does not support CFLAGS in general)? There is no failure when it has empty CFLAGS and --enable-lto since that adds -flto after the endianness test. If it is expected that ffmpeg will break from CFLAGS, then I guess I can pursue this at the distro packaging level. Thanks. David ___ 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 v2] configure: fix the bigendian test
On Sat, Nov 14, 2020 at 8:21 PM David Michael wrote: > On Sat, Nov 14, 2020 at 6:57 PM Carl Eugen Hoyos wrote: > > Am Sa., 14. Nov. 2020 um 20:16 Uhr schrieb David Michael > > : > > > On Sat, Nov 14, 2020 at 2:06 PM Carl Eugen Hoyos > > > wrote: > > > > Am Sa., 14. Nov. 2020 um 18:22 Uhr schrieb David Michael > > > > : > > > > > > > > > > There are two issues: > > > > > > > > > > When build systems enable LTO in CFLAGS, the unused global integer > > > > > does not make it into the compiled object file. As a workaround, > > > > > check if the compiler understands -fno-lto and append it after > > > > > CFLAGS while building the endianness test. > > > > > > > > > > The hexdump output is line-wrapped, so the expected value will not > > > > > be matched when its four bytes are split across two lines. Use the > > > > > POSIX "-A n" option to disable printing input offsets and delete > > > > > all newline characters to output continuous hex values to grep. > > > > > > > > Please explain how we can reproduce the issue (configure line, > > > > compiler, os). > > > > > > It's the same command I sent you for the v1 patch. Just configure it > > > to cross-compile to a big-endian target with CFLAGS=-flto in the > > > environment: > > > > > > CFLAGS=-flto ./configure --enable-cross-compile --host-cc=gcc > > > --arch=powerpc --target-os=linux > > > --cross-prefix=powerpc-unknown-linux-gnu- > > > > Is the issue reproducible if you configure with "--enable-lto" instead > > of CFLAGS (I suspect FFmpeg does not support CFLAGS in general)? > > There is no failure when it has empty CFLAGS and --enable-lto since > that adds -flto after the endianness test. If it is expected that > ffmpeg will break from CFLAGS, then I guess I can pursue this at the > distro packaging level. Oh, but ffmpeg should still probably apply the second half of the patch to work with split lines. I did encounter a failure from that a couple days ago. Thanks. David ___ 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] tools/target_bsf_fuzzer: Call av_bsf_flush() in a fuzzer choosen pattern
This should increase coverage.
Based on a commit by Michael Niedermayer
Signed-off-by: James Almer
---
tools/target_bsf_fuzzer.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/target_bsf_fuzzer.c b/tools/target_bsf_fuzzer.c
index 5d9f90075d..da8d62dd0b 100644
--- a/tools/target_bsf_fuzzer.c
+++ b/tools/target_bsf_fuzzer.c
@@ -43,6 +43,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
AVBSFContext *bsf = NULL;
AVPacket in, out;
uint64_t keyframes = 0;
+uint64_t flushpattern = -1;
int res;
if (!f) {
@@ -86,6 +87,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
bsf->par_in->channels =
(unsigned)bytestream2_get_le32(&gbc) % FF_SANE_NB_CHANNELS;
bsf->par_in->block_align= bytestream2_get_le32(&gbc);
keyframes = bytestream2_get_le64(&gbc);
+flushpattern= bytestream2_get_le64(&gbc);
if (extradata_size < size) {
bsf->par_in->extradata = av_mallocz(extradata_size +
AV_INPUT_BUFFER_PADDING_SIZE);
@@ -128,6 +130,10 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
data += sizeof(fuzz_tag);
last = data;
+if (!(flushpattern & 7))
+av_bsf_flush(bsf);
+flushpattern = (flushpattern >> 3) + (flushpattern << 61);
+
while (in.size) {
res = av_bsf_send_packet(bsf, &in);
if (res < 0 && res != AVERROR(EAGAIN))
--
2.29.2
___
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] tools/target_bsf_fuzzer: set bitstream filter options
Should increase coverage with some bitstream filters
Signed-off-by: James Almer
---
tools/target_bsf_fuzzer.c | 12
1 file changed, 12 insertions(+)
diff --git a/tools/target_bsf_fuzzer.c b/tools/target_bsf_fuzzer.c
index da8d62dd0b..16300037ca 100644
--- a/tools/target_bsf_fuzzer.c
+++ b/tools/target_bsf_fuzzer.c
@@ -18,6 +18,7 @@
#include "config.h"
#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
#include "libavcodec/avcodec.h"
#include "libavcodec/bsf_internal.h"
@@ -66,6 +67,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
if (size > 1024) {
GetByteContext gbc;
int extradata_size;
+int flags;
size -= 1024;
bytestream2_init(&gbc, data + size, 1024);
bsf->par_in->width = bytestream2_get_le32(&gbc);
@@ -88,6 +90,16 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size)
{
bsf->par_in->block_align= bytestream2_get_le32(&gbc);
keyframes = bytestream2_get_le64(&gbc);
flushpattern= bytestream2_get_le64(&gbc);
+flags = bytestream2_get_byte(&gbc);
+
+if (flags & 0x20) {
+if (!strcmp(f->name, "av1_metadata"))
+av_opt_set_int(bsf->priv_data, "td",
bytestream2_get_byte(&gbc) & 3, 0);
+else if (!strcmp(f->name, "h264_metadata"))
+av_opt_set_int(bsf->priv_data, "aud",
bytestream2_get_byte(&gbc) & 3, 0);
+else if (!strcmp(f->name, "extract_extradata"))
+av_opt_set_int(bsf->priv_data, "remove",
bytestream2_get_byte(&gbc) & 1, 0);
+}
if (extradata_size < size) {
bsf->par_in->extradata = av_mallocz(extradata_size +
AV_INPUT_BUFFER_PADDING_SIZE);
--
2.29.2
___
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] tools/target_dec_fuzzer: Call avcodec_flush_buffers() in a fuzzer choosen pattern
From: Michael Niedermayer
This should increase coverage
Signed-off-by: Michael Niedermayer
Signed-off-by: James Almer
---
tools/target_dec_fuzzer.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 4eb59bd296..11530cbf79 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -110,6 +110,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
const AVPacket *avpkt) = NULL;
AVCodecParserContext *parser = NULL;
uint64_t keyframes = 0;
+uint64_t flushpattern = -1;
AVDictionary *opts = NULL;
if (!c) {
@@ -239,6 +240,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
ctx->request_channel_layout = bytestream2_get_le64(&gbc);
ctx->idct_algo = bytestream2_get_byte(&gbc) %
25;
+flushpattern= bytestream2_get_le64(&gbc);
if (flags & 0x20) {
switch (ctx->codec_id) {
@@ -332,6 +334,10 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
av_packet_move_ref(&avpkt, &parsepkt);
}
+ if (!(flushpattern & 7))
+ avcodec_flush_buffers(ctx);
+ flushpattern = (flushpattern >> 3) + (flushpattern << 61);
+
// Iterate through all data
while (avpkt.size > 0 && it++ < maxiteration) {
av_frame_unref(frame);
--
2.29.2
___
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 v2] avcodec/hevcdec: fix stat_coeff save/load for persistent_rice_adaptation_enabled_flag
It's required by the 9.3.1 TableStatCoeff* section.
Following clips have this feature:
WPP_HIGH_TP_444_8BIT_RExt_Apple_2.bit
Bitdepth_A_RExt_Sony_1.bin
Bitdepth_B_RExt_Sony_1.bin
EXTPREC_HIGHTHROUGHPUT_444_16_INTRA_10BIT_RExt_Sony_1.bit
EXTPREC_HIGHTHROUGHPUT_444_16_INTRA_12BIT_RExt_Sony_1.bit
EXTPREC_HIGHTHROUGHPUT_444_16_INTRA_8BIT_RExt_Sony_1.bit
EXTPREC_MAIN_444_16_INTRA_10BIT_RExt_Sony_1.bit
EXTPREC_MAIN_444_16_INTRA_12BIT_RExt_Sony_1.bit
EXTPREC_MAIN_444_16_INTRA_8BIT_RExt_Sony_1.bit
WPP_AND_TILE_10Bit422Test_HIGH_TP_444_10BIT_RExt_Apple_2.bit
WPP_AND_TILE_AND_CABAC_BYPASS_ALIGN_0_HIGH_TP_444_14BIT_RExt_Apple_2.bit
WPP_AND_TILE_AND_CABAC_BYPASS_ALIGN_1_HIGH_TP_444_14BIT_RExt_Apple_2.bit
WPP_AND_TILE_HIGH_TP_444_8BIT_RExt_Apple_2.bit
you can download them from:
https://www.itu.int/wftp3/av-arch/jctvc-site/bitstream_exchange/draft_conformance/RExt/
Signed-off-by: Xu Guangxin
---
libavcodec/hevc_cabac.c | 15 +++
libavcodec/hevcdec.c| 4 ++--
libavcodec/hevcdec.h| 6 --
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/libavcodec/hevc_cabac.c b/libavcodec/hevc_cabac.c
index 3dc0987dad..93fc1ec795 100644
--- a/libavcodec/hevc_cabac.c
+++ b/libavcodec/hevc_cabac.c
@@ -454,12 +454,19 @@ void ff_hevc_save_states(HEVCContext *s, int ctb_addr_ts)
(s->ps.sps->ctb_width == 2 &&
ctb_addr_ts % s->ps.sps->ctb_width == 0))) {
memcpy(s->cabac_state, s->HEVClc->cabac_state, HEVC_CONTEXTS);
+if (s->ps.sps->persistent_rice_adaptation_enabled_flag) {
+memcpy(s->stat_coeff, s->HEVClc->stat_coeff, HEVC_STAT_COEFFS);
+}
}
}
-static void load_states(HEVCContext *s)
+static void load_states(HEVCContext *s, int thread)
{
memcpy(s->HEVClc->cabac_state, s->cabac_state, HEVC_CONTEXTS);
+if (s->ps.sps->persistent_rice_adaptation_enabled_flag) {
+const HEVCContext *prev = s->sList[(thread + s->threads_number - 1) %
s->threads_number];
+memcpy(s->HEVClc->stat_coeff, prev->stat_coeff, HEVC_STAT_COEFFS);
+}
}
static int cabac_reinit(HEVCLocalContext *lc)
@@ -501,7 +508,7 @@ static void cabac_init_state(HEVCContext *s)
s->HEVClc->stat_coeff[i] = 0;
}
-int ff_hevc_cabac_init(HEVCContext *s, int ctb_addr_ts)
+int ff_hevc_cabac_init(HEVCContext *s, int ctb_addr_ts, int thread)
{
if (ctb_addr_ts == s->ps.pps->ctb_addr_rs_to_ts[s->sh.slice_ctb_addr_rs]) {
int ret = cabac_init_decoder(s);
@@ -518,7 +525,7 @@ int ff_hevc_cabac_init(HEVCContext *s, int ctb_addr_ts)
if (s->ps.sps->ctb_width == 1)
cabac_init_state(s);
else if (s->sh.dependent_slice_segment_flag == 1)
-load_states(s);
+load_states(s, thread);
}
}
} else {
@@ -549,7 +556,7 @@ int ff_hevc_cabac_init(HEVCContext *s, int ctb_addr_ts)
if (s->ps.sps->ctb_width == 1)
cabac_init_state(s);
else
-load_states(s);
+load_states(s, thread);
}
}
}
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 699c13bbcc..7191fcf542 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2473,7 +2473,7 @@ static int hls_decode_entry(AVCodecContext *avctxt, void
*isFilterThread)
y_ctb = (ctb_addr_rs / ((s->ps.sps->width + ctb_size - 1) >>
s->ps.sps->log2_ctb_size)) << s->ps.sps->log2_ctb_size;
hls_decode_neighbour(s, x_ctb, y_ctb, ctb_addr_ts);
-ret = ff_hevc_cabac_init(s, ctb_addr_ts);
+ret = ff_hevc_cabac_init(s, ctb_addr_ts, 0);
if (ret < 0) {
s->tab_slice_address[ctb_addr_rs] = -1;
return ret;
@@ -2551,7 +2551,7 @@ static int hls_decode_entry_wpp(AVCodecContext *avctxt,
void *input_ctb_row, int
return 0;
}
-ret = ff_hevc_cabac_init(s, ctb_addr_ts);
+ret = ff_hevc_cabac_init(s, ctb_addr_ts, thread);
if (ret < 0)
goto error;
hls_sao_param(s, x_ctb >> s->ps.sps->log2_ctb_size, y_ctb >>
s->ps.sps->log2_ctb_size);
diff --git a/libavcodec/hevcdec.h b/libavcodec/hevcdec.h
index 39c5c7f89f..5b49384aea 100644
--- a/libavcodec/hevcdec.h
+++ b/libavcodec/hevcdec.h
@@ -53,6 +53,7 @@
#define DEFAULT_INTRA_TC_OFFSET 2
#define HEVC_CONTEXTS 199
+#define HEVC_STAT_COEFFS 4
#define MRG_MAX_NUM_CANDS 5
@@ -424,7 +425,7 @@ typedef struct HEVCFrame {
typedef struct HEVCLocalContext {
uint8_t cabac_state[HEVC_CONTEXTS];
-uint8_t stat_coeff[4];
+uint8_t stat_coeff[HEVC_STAT_COEFFS];
uint8_t first_qp_group;
@@ -480,6 +481,7 @@ typedef struct HEVCContext {
int height;
uint8_t *cabac_state;
+uint8_t stat_coeff[HEVC_STAT_COEFFS];
/** 1 if the independent slice segment header was successfully parsed */
uint8_t slice_initialized;
@@ -594,7 +596,7 @@ int ff_hevc_frame_rps(HEVCCo
[FFmpeg-devel] [PATCH v2] fate/hevc-conformance: add clip for persistent_rice_adaptation_enabled_flag
you can download it from: https://www.itu.int/wftp3/av-arch/jctvc-site/bitstream_exchange/draft_conformance/RExt/WPP_HIGH_TP_444_8BIT_RExt_Apple_2.zip Signed-off-by: Xu Guangxin --- tests/fate/hevc.mak | 1 + .../hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2| 8 2 files changed, 9 insertions(+) create mode 100644 tests/ref/fate/hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2 diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak index 9a32a7d74c..97edb49781 100644 --- a/tests/fate/hevc.mak +++ b/tests/fate/hevc.mak @@ -141,6 +141,7 @@ HEVC_SAMPLES = \ WPP_D_ericsson_MAIN_2 \ WPP_E_ericsson_MAIN_2 \ WPP_F_ericsson_MAIN_2 \ +WPP_HIGH_TP_444_8BIT_RExt_Apple_2 \ HEVC_SAMPLES_10BIT =\ DBLK_A_MAIN10_VIXS_3\ diff --git a/tests/ref/fate/hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2 b/tests/ref/fate/hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2 new file mode 100644 index 00..fcb1d2894a --- /dev/null +++ b/tests/ref/fate/hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2 @@ -0,0 +1,8 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 1024x768 +#sar 0: 0/1 +0, 0, 0,1, 1179648, 0x78e55a69 +0, 1, 1,1, 1179648, 0x5babb3cb +0, 2, 2,1, 1179648, 0x65935648 -- 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".
[FFmpeg-devel] [PATCH v2] fate/hevc-conformance: add clip for persistent_rice_adaptation_enabled_flag
you can download it from: https://www.itu.int/wftp3/av-arch/jctvc-site/bitstream_exchange/draft_conformance/RExt/WPP_HIGH_TP_444_8BIT_RExt_Apple_2.zip Signed-off-by: Xu Guangxin --- tests/fate/hevc.mak | 1 + .../hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2| 8 2 files changed, 9 insertions(+) create mode 100644 tests/ref/fate/hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2 diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak index 9a32a7d74c..97edb49781 100644 --- a/tests/fate/hevc.mak +++ b/tests/fate/hevc.mak @@ -141,6 +141,7 @@ HEVC_SAMPLES = \ WPP_D_ericsson_MAIN_2 \ WPP_E_ericsson_MAIN_2 \ WPP_F_ericsson_MAIN_2 \ +WPP_HIGH_TP_444_8BIT_RExt_Apple_2 \ HEVC_SAMPLES_10BIT =\ DBLK_A_MAIN10_VIXS_3\ diff --git a/tests/ref/fate/hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2 b/tests/ref/fate/hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2 new file mode 100644 index 00..fcb1d2894a --- /dev/null +++ b/tests/ref/fate/hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2 @@ -0,0 +1,8 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 1024x768 +#sar 0: 0/1 +0, 0, 0,1, 1179648, 0x78e55a69 +0, 1, 1,1, 1179648, 0x5babb3cb +0, 2, 2,1, 1179648, 0x65935648 -- 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 v2] avcodec/hevcdec: fix stat_coeff save/load for persistent_rice_adaptation_enabled_flag
Hi Christophe,
Thanks for the test. You are right, It's a wpp decode issue.
Please help review it again.
I have test it with
make fate-hevc THREADS=12 THREAD_TYPE=slice
make fate-hevc THREADS=12
make fate-hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2 THREADS=12
THREAD_TYPE=slice
thanks
On Sun, Nov 15, 2020 at 10:36 AM Xu Guangxin wrote:
> It's required by the 9.3.1 TableStatCoeff* section.
>
> Following clips have this feature:
> WPP_HIGH_TP_444_8BIT_RExt_Apple_2.bit
> Bitdepth_A_RExt_Sony_1.bin
> Bitdepth_B_RExt_Sony_1.bin
> EXTPREC_HIGHTHROUGHPUT_444_16_INTRA_10BIT_RExt_Sony_1.bit
> EXTPREC_HIGHTHROUGHPUT_444_16_INTRA_12BIT_RExt_Sony_1.bit
> EXTPREC_HIGHTHROUGHPUT_444_16_INTRA_8BIT_RExt_Sony_1.bit
> EXTPREC_MAIN_444_16_INTRA_10BIT_RExt_Sony_1.bit
> EXTPREC_MAIN_444_16_INTRA_12BIT_RExt_Sony_1.bit
> EXTPREC_MAIN_444_16_INTRA_8BIT_RExt_Sony_1.bit
> WPP_AND_TILE_10Bit422Test_HIGH_TP_444_10BIT_RExt_Apple_2.bit
> WPP_AND_TILE_AND_CABAC_BYPASS_ALIGN_0_HIGH_TP_444_14BIT_RExt_Apple_2.bit
> WPP_AND_TILE_AND_CABAC_BYPASS_ALIGN_1_HIGH_TP_444_14BIT_RExt_Apple_2.bit
> WPP_AND_TILE_HIGH_TP_444_8BIT_RExt_Apple_2.bit
>
> you can download them from:
>
> https://www.itu.int/wftp3/av-arch/jctvc-site/bitstream_exchange/draft_conformance/RExt/
>
> Signed-off-by: Xu Guangxin
> ---
> libavcodec/hevc_cabac.c | 15 +++
> libavcodec/hevcdec.c| 4 ++--
> libavcodec/hevcdec.h| 6 --
> 3 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/libavcodec/hevc_cabac.c b/libavcodec/hevc_cabac.c
> index 3dc0987dad..93fc1ec795 100644
> --- a/libavcodec/hevc_cabac.c
> +++ b/libavcodec/hevc_cabac.c
> @@ -454,12 +454,19 @@ void ff_hevc_save_states(HEVCContext *s, int
> ctb_addr_ts)
> (s->ps.sps->ctb_width == 2 &&
>ctb_addr_ts % s->ps.sps->ctb_width == 0))) {
> memcpy(s->cabac_state, s->HEVClc->cabac_state, HEVC_CONTEXTS);
> +if (s->ps.sps->persistent_rice_adaptation_enabled_flag) {
> +memcpy(s->stat_coeff, s->HEVClc->stat_coeff,
> HEVC_STAT_COEFFS);
> +}
> }
> }
>
> -static void load_states(HEVCContext *s)
> +static void load_states(HEVCContext *s, int thread)
> {
> memcpy(s->HEVClc->cabac_state, s->cabac_state, HEVC_CONTEXTS);
> +if (s->ps.sps->persistent_rice_adaptation_enabled_flag) {
> +const HEVCContext *prev = s->sList[(thread + s->threads_number -
> 1) % s->threads_number];
> +memcpy(s->HEVClc->stat_coeff, prev->stat_coeff, HEVC_STAT_COEFFS);
> +}
> }
>
> static int cabac_reinit(HEVCLocalContext *lc)
> @@ -501,7 +508,7 @@ static void cabac_init_state(HEVCContext *s)
> s->HEVClc->stat_coeff[i] = 0;
> }
>
> -int ff_hevc_cabac_init(HEVCContext *s, int ctb_addr_ts)
> +int ff_hevc_cabac_init(HEVCContext *s, int ctb_addr_ts, int thread)
> {
> if (ctb_addr_ts ==
> s->ps.pps->ctb_addr_rs_to_ts[s->sh.slice_ctb_addr_rs]) {
> int ret = cabac_init_decoder(s);
> @@ -518,7 +525,7 @@ int ff_hevc_cabac_init(HEVCContext *s, int ctb_addr_ts)
> if (s->ps.sps->ctb_width == 1)
> cabac_init_state(s);
> else if (s->sh.dependent_slice_segment_flag == 1)
> -load_states(s);
> +load_states(s, thread);
> }
> }
> } else {
> @@ -549,7 +556,7 @@ int ff_hevc_cabac_init(HEVCContext *s, int ctb_addr_ts)
> if (s->ps.sps->ctb_width == 1)
> cabac_init_state(s);
> else
> -load_states(s);
> +load_states(s, thread);
> }
> }
> }
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index 699c13bbcc..7191fcf542 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -2473,7 +2473,7 @@ static int hls_decode_entry(AVCodecContext *avctxt,
> void *isFilterThread)
> y_ctb = (ctb_addr_rs / ((s->ps.sps->width + ctb_size - 1) >>
> s->ps.sps->log2_ctb_size)) << s->ps.sps->log2_ctb_size;
> hls_decode_neighbour(s, x_ctb, y_ctb, ctb_addr_ts);
>
> -ret = ff_hevc_cabac_init(s, ctb_addr_ts);
> +ret = ff_hevc_cabac_init(s, ctb_addr_ts, 0);
> if (ret < 0) {
> s->tab_slice_address[ctb_addr_rs] = -1;
> return ret;
> @@ -2551,7 +2551,7 @@ static int hls_decode_entry_wpp(AVCodecContext
> *avctxt, void *input_ctb_row, int
> return 0;
> }
>
> -ret = ff_hevc_cabac_init(s, ctb_addr_ts);
> +ret = ff_hevc_cabac_init(s, ctb_addr_ts, thread);
> if (ret < 0)
> goto error;
> hls_sao_param(s, x_ctb >> s->ps.sps->log2_ctb_size, y_ctb >>
> s->ps.sps->log2_ctb_size);
> diff --git a/libavcodec/hevcdec.h b/libavcodec/hevcdec.h
> index 39c5c7f89f..5b49384aea 100644
> --- a/libavcodec/hevcdec.h
> +++ b/libavcodec/hevcdec.h
> @@ -53,6 +53,7 @@
> #define DEFAULT_INTRA_TC_OFFSET 2
>
> #define HEVC_CONTEXTS 199
> +#define HEVC_STAT_COEFFS 4
>
> #define
Re: [FFmpeg-devel] [PATCH 001/114] avcodec/bitstream: Add second function to create VLCs
Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-11-10 11:46:58)
>> +int ff_init_vlc_from_lengths(VLC *vlc_arg, int nb_bits, int nb_codes,
>> + const int8_t *lens, int lens_wrap,
>> + const void *symbols, int symbols_wrap, int
>> symbols_size,
>> + int offset, int flags)
>> +{
>> +VLCcode localbuf[LOCALBUF_ELEMS], *buf = localbuf;
>> +VLC localvlc, *vlc;
>> +uint64_t code;
>> +int ret, j, len_max = FFMIN(32, 3 * nb_bits);
>> +
>> +ret = vlc_common_init(vlc_arg, nb_bits, nb_codes, &vlc, &localvlc,
>> + &buf, flags);
>> +if (ret < 0)
>> +return ret;
>> +
>> +j = code = 0;
>> +for (int i = 0; i < nb_codes; i++, lens += lens_wrap) {
>> +int len = *lens;
>> +if (len > 0) {
>> +unsigned sym;
>> +
>> +buf[j].bits = len;
>> +if (symbols)
>> +GET_DATA(sym, symbols, i, symbols_wrap, symbols_size)
>> +else
>> +sym = i;
>> +buf[j].symbol = sym + offset;
>> +buf[j++].code = code;
>> +} else if (len < 0) {
>> +len = -len;
>> +} else
>> +continue;
>> +if (len > len_max || code & ((1U << (32 - len)) - 1)) {
>> +av_log(NULL, AV_LOG_ERROR, "Invalid VLC (length %u)\n", len);
>
> Can you use a proper logging context here?
>
Yes. This will of course mean that I will have to go with the flag in
patch four.
- Andreas
___
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/4] avformat/asfdec_o: Don't segfault with lots of attached pics
Andreas Rheinhardt:
> The ASF file format has a limit of 127 streams and the "asf_o" demuxer
> (the ASF demuxer from Libav) has an array of pointers for a structure
> called ASFStream that is allocated on demand for every stream. Attached
> pictures are not streams in the sense of the ASF specification, yet the
> demuxer created an ASFStream for them; and in one codepath it also
> forgot to check whether the array of ASFStreams is already full. The
> result is a write beyond the end of the array and a segfault lateron.
>
> Fixing this is easy: Don't create ASFStreams for attached picture
> streams.
>
> (Other results of the current state of affairs are unnecessary allocations
> (of ASFStreams structures), the misparsing of valid files (there might not
> be enough ASFStreams left for the valid streams if attached pictures take
> up too many); furthermore, the ASFStreams created for attached pictures all
> have the stream number 0, an invalid stream number (the valid range is
> 1-127). This means that invalid data (packets for a stream with stream
> number 0) won't get rejected lateron.)
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/asfdec_o.c | 14 ++
> 1 file changed, 2 insertions(+), 12 deletions(-)
>
> diff --git a/libavformat/asfdec_o.c b/libavformat/asfdec_o.c
> index b142f83541..0a7e47d8cc 100644
> --- a/libavformat/asfdec_o.c
> +++ b/libavformat/asfdec_o.c
> @@ -357,7 +357,6 @@ static int asf_set_metadata(AVFormatContext *s, const
> uint8_t *name,
> * but in reality this is only loosely similar */
> static int asf_read_picture(AVFormatContext *s, int len)
> {
> -ASFContext *asf = s->priv_data;
> AVPacket pkt = { 0 };
> const CodecMime *mime = ff_id3v2_mime_tags;
> enum AVCodecID id= AV_CODEC_ID_NONE;
> @@ -365,7 +364,6 @@ static int asf_read_picture(AVFormatContext *s, int len)
> uint8_t *desc = NULL;
> AVStream *st = NULL;
> int ret, type, picsize, desc_len;
> -ASFStream *asf_st;
>
> /* type + picsize + mime + desc */
> if (len < 1 + 4 + 2 + 2) {
> @@ -422,22 +420,14 @@ static int asf_read_picture(AVFormatContext *s, int len)
> ret = AVERROR(ENOMEM);
> goto fail;
> }
> -asf->asf_st[asf->nb_streams] = av_mallocz(sizeof(*asf_st));
> -asf_st = asf->asf_st[asf->nb_streams];
> -if (!asf_st) {
> -ret = AVERROR(ENOMEM);
> -goto fail;
> -}
>
> st->disposition |= AV_DISPOSITION_ATTACHED_PIC;
> -st->codecpar->codec_type = asf_st->type = AVMEDIA_TYPE_VIDEO;
> +st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
> st->codecpar->codec_id= id;
> st->attached_pic = pkt;
> -st->attached_pic.stream_index = asf_st->index = st->index;
> +st->attached_pic.stream_index = st->index;
> st->attached_pic.flags |= AV_PKT_FLAG_KEY;
>
> -asf->nb_streams++;
> -
> if (*desc) {
> if (av_dict_set(&st->metadata, "title", desc,
> AV_DICT_DONT_STRDUP_VAL) < 0)
> av_log(s, AV_LOG_WARNING, "av_dict_set failed.\n");
>
Will apply this patchset later today unless there are objections.
- Andreas
___
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 001/114] avcodec/bitstream: Add second function to create VLCs
Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-11-12 21:51:28)
>> Derek Buitenhuis:
>>> On 10/11/2020 10:46, Andreas Rheinhardt wrote:
+#define INIT_VLC_STATIC_FROM_LENGTHS(vlc, bits, nb_codes, lens, len_wrap,
\
+ symbols, symbols_wrap, symbols_size,
\
+ offset, flags, static_size)
\
+do {
\
+static VLC_TYPE table[static_size][2];
\
+(vlc)->table = table;
\
+(vlc)->table_allocated = static_size;
\
+ff_init_vlc_from_lengths(vlc, bits, nb_codes, lens, len_wrap,
\
+ symbols, symbols_wrap, symbols_size,
\
+ offset, flags |
INIT_VLC_USE_NEW_STATIC); \
+} while (0)
>>>
>>> If I am reading correctly, wherever you add/use this, you are adding
>>> non-thread
>>> safe global init code to a decoder. This is a huge step back and not
>>> acceptable.
>>>
>>> It should be made to properly use ff_thread_once if possible, or reworked.
>>>
>> The ff_init_vlc_... functions are inherently thread-safe: Everything is
>> modified only once and directly set to its final value; so it's no
>> problem if two threads are initializing the same static VLC at the same
>> time.
>
> Strictly speaking it's still a race (and therefore UB), even if you
> store the same values. I suspect tools like tsan will not like it
> either.
>
I at first thought it was not so, because the definition of data races
in C11 speaks of conflicting actions in different threads; but you are
right: It is conflicting according to the definition: "Two expression
evaluations conflict if one of them modifies a memory location and the
other one reads or modifies the same memory location."
Furthermore, the current code has the problem of not using atomic
operations to modify the VLC table. So I'll use ff_thread_once() for the
cases affected by this patchset; a later patchset will then fix the
other ones and also implement the simplifications that will be possible
once this is done (no volatile!). This will also improve performance in
general.
- Andreas
___
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/mobiclip: Use get_ue_golomb_31() where possible
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/mobiclip.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/mobiclip.c b/libavcodec/mobiclip.c
> index 9fa88e84a0..42d33cf6a5 100644
> --- a/libavcodec/mobiclip.c
> +++ b/libavcodec/mobiclip.c
> @@ -539,11 +539,11 @@ static int add_pframe_coefficients(AVCodecContext
> *avctx, AVFrame *frame,
> {
> MobiClipContext *s = avctx->priv_data;
> GetBitContext *gb = &s->gb;
> -int ret, idx = get_ue_golomb(gb);
> +int ret, idx = get_ue_golomb_31(gb);
>
> if (idx == 0) {
> ret = add_coefficients(avctx, frame, bx, by, size, plane);
> -} else if (idx < FF_ARRAY_ELEMS(pframe_block4x4_coefficients_tab)) {
> +} else if ((unsigned)idx <
> FF_ARRAY_ELEMS(pframe_block4x4_coefficients_tab)) {
> int flags = pframe_block4x4_coefficients_tab[idx];
>
> for (int y = by; y < by + 8; y += 4) {
> @@ -1012,8 +1012,8 @@ static int process_block(AVCodecContext *avctx, AVFrame
> *frame,
> return predict_intra(avctx, frame, x, y, pmode, 0, 8, plane);
> }
>
> -tmp = get_ue_golomb(gb);
> -if (tmp < 0 || tmp > FF_ARRAY_ELEMS(block4x4_coefficients_tab))
> +tmp = get_ue_golomb_31(gb);
> +if ((unsigned)tmp > FF_ARRAY_ELEMS(block4x4_coefficients_tab))
> return AVERROR_INVALIDDATA;
>
> if (tmp == 0) {
>
Will apply this later today unless there are objections.
- Andreas
___
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 100/114] avcodec/vp3: Use symbols table for VP3 motion vectors
Peter Ross: > On Tue, Nov 10, 2020 at 11:58:22AM +0100, Andreas Rheinhardt wrote: >> Expressions like array[get_vlc2()] can be optimized by using a symbols >> table if the array is always the same for a given VLC. This requirement >> is fulfilled for the VLC used for VP3 motion vectors. The reason it >> hasn't been done before is probably that the array in this case >> contained entries in the range -31..31; but this is no problem with >> ff_init_vlc_from_lengths(): Just apply an offset of 31 to the symbols >> before storing them in the table used to initialize VP3 motion vectors >> and apply an offset of -31 when initializing the actual VLC. >> >> Signed-off-by: Andreas Rheinhardt >> --- >> libavcodec/vp3.c | 20 --- >> libavcodec/vp3data.h | 46 +++- >> 2 files changed, 24 insertions(+), 42 deletions(-) >> >> diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c >> index 7037d03a98..f288a53fe1 100644 >> --- a/libavcodec/vp3.c >> +++ b/libavcodec/vp3.c >> @@ -48,6 +48,7 @@ >> #include "vp3dsp.h" >> #include "xiph.h" >> >> +#define VP3_MV_VLC_BITS 6 >> #define VP4_MV_VLC_BITS 6 >> #define SUPERBLOCK_VLC_BITS 6 > > or just use '#define MV_VLC_BITS 6' > This patch has to modify all the lines that use the motion_vector_vlc VLC table, so using a named constant can be easily done while at it; this is no longer true when also changing VP4. Furthermore, there is no a-priori reason why it should forever be so that both of these are six (the longest VP3 MV code is only eight bits long, which is not excessive; I pondered changing it, but decided that it is outside the remit of this patchset). But if you want to, I can use one constant for both. - Andreas ___ 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] Support HDR10+ metadata for HEVC.
Thank you Ian for your great detailed comments.
Thanks,
Mohammad
On Wed, Nov 11, 2020 at 5:10 PM Jan Ekström wrote:
> On 14.10.2020 2:53, Mohammad Izadi wrote:
> > From: Mohammad Izadi
> >
> > HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs
> to be decoded from ITU-T T.35 in HEVC bitstream. The HDR10+ is transferred
> to side data packet to be used or passed through.
> >
> > The fate test file can be found here:
> https://drive.google.com/file/d/1Hadzc24-RsgnRqS-B0bxLmzDeTwEOhtE/view?usp=sharing
> >
> > The video file needs to be copied to fate-suite/mov/
> > ---
>
> Long overdue initial attempt at a review follows...
>
> > fftools/ffprobe.c | 16 +++
> > libavcodec/avpacket.c | 1 +
> > libavcodec/decode.c| 1 +
> > libavcodec/hevc_sei.c | 39 --
> > libavcodec/hevc_sei.h | 5 +
> > libavcodec/hevcdec.c | 16 +++
> > libavcodec/internal.h | 9 ++
> > libavcodec/packet.h| 8 ++
> > libavcodec/utils.c | 180 +
> > libavcodec/version.h | 2 +-
> > libavfilter/vf_showinfo.c | 28
> > tests/fate/mov.mak | 3 +
> > tests/ref/fate/mov-hdr10-plus-metadata | 55
> > 13 files changed, 350 insertions(+), 13 deletions(-)
> > create mode 100644 tests/ref/fate/mov-hdr10-plus-metadata
> >
> > diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> > index d4e494f11f..0b80edf842 100644
> > --- a/fftools/ffprobe.c
> > +++ b/fftools/ffprobe.c
> > @@ -35,6 +35,7 @@
> > #include "libavutil/bprint.h"
> > #include "libavutil/display.h"
> > #include "libavutil/hash.h"
> > +#include "libavutil/hdr_dynamic_metadata.h"
> > #include "libavutil/mastering_display_metadata.h"
> > #include "libavutil/dovi_meta.h"
> > #include "libavutil/opt.h"
> > @@ -1925,6 +1926,13 @@ static void print_pkt_side_data(WriterContext *w,
> > print_q("min_luminance", metadata->min_luminance, '/');
> > print_q("max_luminance", metadata->max_luminance, '/');
> > }
> > +} else if (sd->type == AV_PKT_DATA_DYNAMIC_HDR_PLUS) {
> > +AVDynamicHDRPlus *metadata = (AVDynamicHDRPlus *)sd->data;
> > +// Partially print HDR10+ metadata.
> > +print_int("num_windows", metadata->num_windows);
> > +print_q("targeted_system_display_maximum_luminance",
> metadata->targeted_system_display_maximum_luminance, '/');
> > +
> print_int("targeted_system_display_actual_peak_luminance_flag",
> metadata->targeted_system_display_actual_peak_luminance_flag);
> > +print_int("mastering_display_actual_peak_luminance_flag",
> metadata->mastering_display_actual_peak_luminance_flag);
> > } else if (sd->type == AV_PKT_DATA_CONTENT_LIGHT_LEVEL) {
> > AVContentLightMetadata *metadata = (AVContentLightMetadata
> *)sd->data;
> > print_int("max_content", metadata->MaxCLL);
> > @@ -2250,6 +2258,14 @@ static void show_frame(WriterContext *w, AVFrame
> *frame, AVStream *stream,
> > print_q("min_luminance", metadata->min_luminance,
> '/');
> > print_q("max_luminance", metadata->max_luminance,
> '/');
> > }
> > +} else if (sd->type == AV_FRAME_DATA_DYNAMIC_HDR_PLUS) {
> > +AVDynamicHDRPlus *metadata = (AVDynamicHDRPlus
> *)sd->data;
> > +// Partially print HDR10+ metadata.
> > + print_int("num_windows", metadata->num_windows);
> > + print_q("targeted_system_display_maximum_luminance",
> metadata->targeted_system_display_maximum_luminance, '/');
> > +
> print_int("targeted_system_display_actual_peak_luminance_flag",
> metadata->targeted_system_display_actual_peak_luminance_flag);
> > + print_int("mastering_display_actual_peak_luminance_flag",
> metadata->mastering_display_actual_peak_luminance_flag);
> > +
>
> Some really minor stuff:
> - Empty line at the end
> - Tabs vs space, seemingly some tabs ended up here. Copy and paste can
> make that happen. I know this has been done in this duplicated fashion so
> far, but maybe this should just be in a static function that takes in a
> AVDynamicHDRPlus pointer and could just be called from two places?
>
fixed.
> - I am not sure of the whole history of this patch set, but was there any
> explanation on why these specific values should be the ones from which
> printing should be started since we are not printing the whole
> (complicated) structure? I think so far our practice has been to dump all
> values from the structures, except for the flags for whether a thing exists
> or not (see the example with "has_primaries"/"has_luminance" for mastering
> display metadata, and the loop within S12M timecode printing for lists of
> things), so even if we limit initial printi
[FFmpeg-devel] [PATCH] Support HDR10+ metadata for HEVC.
From: Mohammad Izadi
HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs to be
decoded from ITU-T T.35 in HEVC bitstream. The HDR10+ is transferred to side
data packet to be used or passed through.
The fate test file can be found here:
https://drive.google.com/file/d/1Hadzc24-RsgnRqS-B0bxLmzDeTwEOhtE/view?usp=sharing
The video file needs to be copied to fate-suite/mov/
---
configure | 1 +
fftools/ffprobe.c | 106 +
libavcodec/Makefile | 3 +
libavcodec/avpacket.c | 1 +
libavcodec/decode.c | 1 +
libavcodec/dynamic_hdr10_plus.c | 223 ++
.../dynamic_hdr10_plus.h | 22 +-
libavcodec/hevc_sei.c | 62 -
libavcodec/hevc_sei.h | 5 +
libavcodec/hevcdec.c | 18 ++
libavcodec/packet.h | 8 +
libavcodec/version.h | 2 +-
libavfilter/vf_showinfo.c | 106 -
libavutil/Makefile| 2 -
libavutil/hdr_dynamic_metadata.c | 47
tests/fate/mov.mak| 3 +
tests/ref/fate/mov-hdr10-plus-metadata| 90 +++
17 files changed, 629 insertions(+), 71 deletions(-)
create mode 100644 libavcodec/dynamic_hdr10_plus.c
rename libavutil/hdr_dynamic_metadata.h => libavcodec/dynamic_hdr10_plus.h
(95%)
delete mode 100644 libavutil/hdr_dynamic_metadata.c
create mode 100644 tests/ref/fate/mov-hdr10-plus-metadata
diff --git a/configure b/configure
index 51e43fbf66..a9f12a421e 100755
--- a/configure
+++ b/configure
@@ -2360,6 +2360,7 @@ CONFIG_EXTRA="
dirac_parse
dnn
dvprofile
+dynamic_hdr10_plus
exif
faandct
faanidct
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 86bd23d36d..4cee4e8ec3 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -35,6 +35,7 @@
#include "libavutil/bprint.h"
#include "libavutil/display.h"
#include "libavutil/hash.h"
+#include "libavutil/hdr_dynamic_metadata.h"
#include "libavutil/mastering_display_metadata.h"
#include "libavutil/dovi_meta.h"
#include "libavutil/opt.h"
@@ -1860,6 +1861,105 @@ static inline int show_tags(WriterContext *w,
AVDictionary *tags, int section_id
return ret;
}
+static void print_dynamic_hdr10_plus(WriterContext *w, AVDynamicHDRPlus
*metadata)
+{
+if (!metadata)
+return;
+print_int("application version", metadata->application_version);
+print_int("num_windows", metadata->num_windows);
+for (int n = 1; n < metadata->num_windows; n++) {
+AVHDRPlusColorTransformParams *params = &metadata->params[n];
+print_q("window_upper_left_corner_x",
+params->window_upper_left_corner_x,'/');
+print_q("window_upper_left_corner_y",
+params->window_upper_left_corner_y,'/');
+print_q("window_lower_right_corner_x",
+params->window_lower_right_corner_x,'/');
+print_q("window_lower_right_corner_y",
+params->window_lower_right_corner_y,'/');
+print_q("window_upper_left_corner_x",
+params->window_upper_left_corner_x,'/');
+print_q("window_upper_left_corner_y",
+params->window_upper_left_corner_y,'/');
+print_int("center_of_ellipse_x",
+ params->center_of_ellipse_x ) ;
+print_int("center_of_ellipse_y",
+ params->center_of_ellipse_y );
+print_int("rotation_angle",
+ params->rotation_angle);
+print_int("semimajor_axis_internal_ellipse",
+ params->semimajor_axis_internal_ellipse);
+print_int("semimajor_axis_external_ellipse",
+ params->semimajor_axis_external_ellipse);
+print_int("semiminor_axis_external_ellipse",
+ params->semiminor_axis_external_ellipse);
+print_int("overlap_process_option",
+ params->overlap_process_option);
+}
+print_q("targeted_system_display_maximum_luminance",
+metadata->targeted_system_display_maximum_luminance,'/');
+if (metadata->targeted_system_display_actual_peak_luminance_flag) {
+print_int("num_rows_targeted_system_display_actual_peak_luminance",
+
metadata->num_rows_targeted_system_display_actual_peak_luminance);
+print_int("num_cols_targeted_system_display_actual_peak_luminance",
+
metadata->num_cols_targeted_system_display_actual_peak_luminance);
+for (int i = 0; i <
metadata->num_rows_targeted_system_display_actual_peak_luminance; i++) {
+for (int j = 0; j <
metadata->num_cols_targeted_system_display_actual_peak_luminance; j++) {
+print_q("targeted_system_display_actual_peak_luminance",
