[FFmpeg-devel] [PATCH] libavcodec/qsvenc: add DisableDeblockingIdc support for qsv
From: Wenbinc-Bin
MediaSDK already has a flag to control deblocking (DisableDeblockingIdc). Add
dblk_idc parameter in ffmpeg to expose this flag to user.
Sigend-off-by: Wenbin Chen
---
libavcodec/qsvenc.c | 4
libavcodec/qsvenc.h | 3 +++
2 files changed, 7 insertions(+)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index aba98dd689..0d20d1968f 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -710,6 +710,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (q->max_slice_size >= 0)
q->extco2.MaxSliceSize = q->max_slice_size;
#endif
+#if QSV_HAVE_DISABLEDEBLOCKIDC
+if(q->dblk_idc >= 0)
+q->extco2.DisableDeblockingIdc = q->dblk_idc;
+#endif
#if QSV_HAVE_TRELLIS
if (avctx->trellis >= 0)
diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
index 6d305f87dd..3720320789 100644
--- a/libavcodec/qsvenc.h
+++ b/libavcodec/qsvenc.h
@@ -44,6 +44,7 @@
#define QSV_HAVE_TRELLIS QSV_VERSION_ATLEAST(1, 8)
#define QSV_HAVE_MAX_SLICE_SIZE QSV_VERSION_ATLEAST(1, 9)
+#define QSV_HAVE_DISABLEDEBLOCKIDC QSV_VERSION_ATLEAST(1, 9)
#define QSV_HAVE_BREF_TYPE QSV_VERSION_ATLEAST(1, 8)
#define QSV_HAVE_LA QSV_VERSION_ATLEAST(1, 7)
@@ -97,6 +98,7 @@
{ "b_strategy", "Strategy to choose between I/P/B-frames",
OFFSET(qsv.b_strategy),AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 1, VE
}, \
{ "forced_idr", "Forcing I frames as IDR frames",
OFFSET(qsv.forced_idr), AV_OPT_TYPE_BOOL,{ .i64 = 0 }, 0, 1, VE
}, \
{ "low_power", "enable low power mode(experimental: many limitations by mfx
version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, { .i64 =
0}, 0, 1, VE},\
+{ "dblk_idc", "value of DisableDeblockingIdc (default is 0), in range [0,2]",
OFFSET(qsv.dblk_idc), AV_OPT_TYPE_INT,{ .i64 = 0 }, 0, 2, VE},\
extern const AVCodecHWConfigInternal *const ff_qsv_enc_hw_configs[];
@@ -167,6 +169,7 @@ typedef struct QSVEncContext {
int rdo;
int max_frame_size;
int max_slice_size;
+int dblk_idc;
int tile_cols;
int tile_rows;
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] swscale/rgb2rgb_template: use shuffle macro on BE arches
On Tue, 01. Dec 00:45, Carl Eugen Hoyos wrote: > Am Mo., 30. Nov. 2020 um 06:48 Uhr schrieb Andriy Gelman > : > > > > From: Andriy Gelman > > > > Fixes fate-qtrle-32bit on PPC64 qemu > > I suspect your patch fixes colourspace conversion (and the fate > test) on big-endian. For this fate test it's currently doing the argb->bgra conversion in swscale() (libswscale/swscale.c). I saved some of the output images to .bmp and they seem fine. Looking at swscale() I think the conversion is done via argb->yuv->bgra. After the patch it's a permutation of the bytes. -- Andriy ___ 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/hls: Fixes overwriting existing #EXT-X-PROGRAM-DATE-TIME value in HLS playlist
> 2020年12月1日 下午6:10，Vignesh Ravichandran 写道：
>
> Bug ID: 8989
>
> This is is due to the following behavior in the current code:
> 1. The initial_prog_date_time gets set to the current local time
> 2. The existing playlist (.m3u8) file gets parsed and the segments present
> are added to the variant stream
> 3. The new segment is created and added
> 4. The existing segments and the new segment are written to the playlist
> file. The initial_prog_date_time from point 1 is used for calculating
> "#EXT-X-PROGRAM-DATE-TIME" for the segments, which results in incorrect
> "#EXT-X-PROGRAM-DATE-TIME" values for existing segments
>
> The following approach fixes this bug:
> 1. Add a new variable "discont_program_date_time" of type double to
> HLSSegment struct
> 2. Store the "EXT-X-PROGRAM-DATE-TIME" value from the existing segments in
> this variable
> 3. When writing to playlist file if "discont_program_date_time" is set, then
> use that value for "EXT-X-PROGRAM-DATE-TIME" else use the value present in
> vs->initial_prog_date_time
>
> Signed-off-by: Vignesh Ravichandran
> ---
> libavformat/hlsenc.c | 33 ++---
> 1 file changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index cbfd8f7c0d..9bce374605 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -88,6 +88,7 @@ typedef struct HLSSegment {
> char iv_string[KEYSIZE*2 + 1];
>
> struct HLSSegment *next;
> +double discont_program_date_time;
> } HLSSegment;
>
> typedef enum HLSFlags {
> @@ -1124,6 +1125,7 @@ static int hls_append_segment(struct AVFormatContext
> *s, HLSContext *hls,
> en->keyframe_size = vs->video_keyframe_size;
> en->next = NULL;
> en->discont = 0;
> +en->discont_program_date_time = 0;
>
> if (vs->discontinuity) {
> en->discont = 1;
> @@ -1148,7 +1150,8 @@ static int hls_append_segment(struct AVFormatContext
> *s, HLSContext *hls,
>
> if (hls->max_nb_segments && vs->nb_entries >= hls->max_nb_segments) {
> en = vs->segments;
> -vs->initial_prog_date_time += en->duration;
> +if (!en->next->discont_program_date_time &&
> !en->discont_program_date_time)
> +vs->initial_prog_date_time += en->duration;
> vs->segments = en->next;
> if (en && hls->flags & HLS_DELETE_SEGMENTS &&
> #if FF_API_HLS_WRAP
> @@ -1182,6 +1185,7 @@ static int parse_playlist(AVFormatContext *s, const
> char *url, VariantStream *vs
> char line[MAX_URL_SIZE];
> const char *ptr;
> const char *end;
> +double discont_program_date_time = 0;
>
> if ((ret = ffio_open_whitelist(&in, url, AVIO_FLAG_READ,
>&s->interrupt_callback, NULL,
> @@ -1236,7 +1240,25 @@ static int parse_playlist(AVFormatContext *s, const
> char *url, VariantStream *vs
> av_strlcpy(vs->iv_string, ptr, sizeof(vs->iv_string));
> }
> }
> +} else if (av_strstart(line, "#EXT-X-PROGRAM-DATE-TIME:", &ptr)) {
> +struct tm program_date_time;
> +int y,M,d,h,m,s;
> +double ms;
> +if (sscanf(ptr, "%d-%d-%dT%d:%d:%d.%lf", &y, &M, &d, &h, &m, &s,
> &ms) != 7) {
> +ret = AVERROR_INVALIDDATA;
> +goto fail;
> +}
> +
> +program_date_time.tm_year = y - 1900;
> +program_date_time.tm_mon = M - 1;
> +program_date_time.tm_mday = d;
> +program_date_time.tm_hour = h;
> +program_date_time.tm_min = m;
> +program_date_time.tm_sec = s;
> +program_date_time.tm_isdst = -1;
>
> +discont_program_date_time = mktime(&program_date_time);
> +discont_program_date_time += (double)(ms / 1000);
> } else if (av_strstart(line, "#", NULL)) {
> continue;
> } else if (line[0]) {
> @@ -1250,8 +1272,9 @@ static int parse_playlist(AVFormatContext *s, const
> char *url, VariantStream *vs
> is_segment = 0;
> new_start_pos = avio_tell(vs->avf->pb);
> vs->size = new_start_pos - vs->start_pos;
> -vs->initial_prog_date_time -= vs->duration; // this is a
> previously existing segment
> ret = hls_append_segment(s, hls, vs, vs->duration,
> vs->start_pos, vs->size);
> +vs->last_segment->discont_program_date_time =
> discont_program_date_time;
> +discont_program_date_time += vs->duration;
> if (ret < 0)
> goto fail;
> vs->start_pos = new_start_pos;
> @@ -1572,7 +1595,11 @@ static int hls_window(AVFormatContext *s, int last,
> VariantStream *vs)
> ret = ff_hls_write_file_entry(byterange_mode ? hls->m3u8_out :
> vs->out, en->discont, byterange_mode,
> en->duration, hls->flags &
> HLS_ROUND_DURATIONS,
>
[FFmpeg-devel] [PATCH 3/4] avformat/dhav: Check position for overflow
Fixes: signed integer overflow: 9223372036854775807 + 32768 cannot be
represented in type 'long'
Fixes:
27744/clusterfuzz-testcase-minimized-ffmpeg_dem_DHAV_fuzzer-5179319491756032
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/dhav.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/dhav.c b/libavformat/dhav.c
index 53deaff77e..00e0d8476e 100644
--- a/libavformat/dhav.c
+++ b/libavformat/dhav.c
@@ -173,12 +173,12 @@ 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 (avio_rl32(s->pb) != MKTAG('D','H','A','V') && dhav->last_good_pos <
INT64_MAX - 0x8000) {
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')) {
-if (avio_feof(s->pb))
+if (avio_feof(s->pb) || dhav->last_good_pos >= INT64_MAX - 0x8000)
return AVERROR_EOF;
dhav->last_good_pos += 0x8000;
ret = avio_skip(s->pb, 0x8000 - 4);
--
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/wmaprodec: Check packet size
Fixes: left shift of negative value -25824
Fixes:
27754/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_XMA2_fuzzer-5760255962906624
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/wmaprodec.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/wmaprodec.c b/libavcodec/wmaprodec.c
index 63e7680f9a..296970f561 100644
--- a/libavcodec/wmaprodec.c
+++ b/libavcodec/wmaprodec.c
@@ -1719,6 +1719,12 @@ static int decode_packet(AVCodecContext *avctx,
WMAProDecodeCtx *s,
}
} else {
int frame_size;
+
+if (avpkt->size < s->next_packet_start) {
+s->packet_loss = 1;
+return AVERROR_INVALIDDATA;
+}
+
s->buf_bit_size = (avpkt->size - s->next_packet_start) << 3;
init_get_bits(gb, avpkt->data, s->buf_bit_size);
skip_bits(gb, s->packet_offset);
--
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 1/4] avcodec/cdgraphics: Check frame before clearing
Fixes: null pointer dereference
Fixes:
27730/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CDGRAPHICS_fuzzer-6212402236096512
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cdgraphics.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/cdgraphics.c b/libavcodec/cdgraphics.c
index 965f43684a..263459d0f2 100644
--- a/libavcodec/cdgraphics.c
+++ b/libavcodec/cdgraphics.c
@@ -369,6 +369,9 @@ static void cdg_decode_flush(AVCodecContext *avctx)
{
CDGraphicsContext *cc = avctx->priv_data;
+if (!cc->frame->data[0])
+return;
+
memset(cc->frame->data[0], 0, cc->frame->linesize[0] * avctx->height);
if (!avctx->frame_number)
memset(cc->frame->data[1], 0, AVPALETTE_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 2/4] avcodec/rasc: Check frame before clearing
Fixes: null pointer dereference
Fixes:
27737/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RASC_fuzzer-5769028685266944
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/rasc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/rasc.c b/libavcodec/rasc.c
index cdf20a6db9..706940bf5f 100644
--- a/libavcodec/rasc.c
+++ b/libavcodec/rasc.c
@@ -70,6 +70,9 @@ static void clear_plane(AVCodecContext *avctx, AVFrame *frame)
RASCContext *s = avctx->priv_data;
uint8_t *dst = frame->data[0];
+if (!dst)
+return;
+
for (int y = 0; y < avctx->height; y++) {
memset(dst, 0, avctx->width * s->bpp);
dst += frame->linesize[0];
--
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] avformat/dv: fix timestamps of audio packets in case of dropped corrupt audio frames
> On Nov 14, 2020, at 7:14 PM, Marton Balint wrote: > > 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? Nudging on this, as this patch has been very helpful to avoid tedious workarounds. I’d love to see it merged. If any further test results would be useful, let me know. Dave ___ 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 wit
Re: [FFmpeg-devel] [PATCH] libavformat/mov.c: export vendor id as metadata
On Wed, Nov 18, 2020 at 12:09 PM Thierry Foucu wrote:
> ---
> libavformat/mov.c | 8 ++--
> tests/ref/fate/hapqa-extract-nosnappy-to-hapalphaonly-mov | 1 +
> tests/ref/fate/hapqa-extract-nosnappy-to-hapq-mov | 1 +
> tests/ref/fate/mov-zombie | 2 +-
> tests/ref/fate/rgb24-mkv | 4 ++--
> 5 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 2b90e31170..1ba1a748e8 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -2095,6 +2095,7 @@ static void mov_parse_stsd_video(MOVContext *c,
> AVIOContext *pb,
> uint8_t codec_name[32] = { 0 };
> int64_t stsd_start;
> unsigned int len;
> +uint32_t id = 0;
>
> /* The first 16 bytes of the video sample description are already
> * read in ff_mov_read_stsd_entries() */
> @@ -2102,7 +2103,8 @@ static void mov_parse_stsd_video(MOVContext *c,
> AVIOContext *pb,
>
> avio_rb16(pb); /* version */
> avio_rb16(pb); /* revision level */
> -avio_rb32(pb); /* vendor */
> +id = avio_rl32(pb); /* vendor */
> +av_dict_set(&st->metadata, "vendor_id", av_fourcc2str(id), 0);
> avio_rb32(pb); /* temporal quality */
> avio_rb32(pb); /* spatial quality */
>
> @@ -2150,10 +2152,12 @@ static void mov_parse_stsd_audio(MOVContext *c,
> AVIOContext *pb,
> {
> int bits_per_sample, flags;
> uint16_t version = avio_rb16(pb);
> +uint32_t id = 0;
> AVDictionaryEntry *compatible_brands = av_dict_get(c->fc->metadata,
> "compatible_brands", NULL, AV_DICT_MATCH_CASE);
>
> avio_rb16(pb); /* revision level */
> -avio_rb32(pb); /* vendor */
> +id = avio_rl32(pb); /* vendor */
> +av_dict_set(&st->metadata, "vendor_id", av_fourcc2str(id), 0);
>
> st->codecpar->channels = avio_rb16(pb); /* channel count
> */
> st->codecpar->bits_per_coded_sample = avio_rb16(pb); /* sample size */
> diff --git a/tests/ref/fate/hapqa-extract-nosnappy-to-hapalphaonly-mov
> b/tests/ref/fate/hapqa-extract-nosnappy-to-hapalphaonly-mov
> index 61af08aa23..04a965b12a 100644
> --- a/tests/ref/fate/hapqa-extract-nosnappy-to-hapalphaonly-mov
> +++ b/tests/ref/fate/hapqa-extract-nosnappy-to-hapalphaonly-mov
> @@ -69,5 +69,6 @@ DISPOSITION:attached_pic=0
> DISPOSITION:timed_thumbnails=0
> TAG:language=eng
> TAG:handler_name=Module de gestion video
> +TAG:vendor_id=FFMP
> TAG:encoder=HAPAlpha Only
> [/STREAM]
> diff --git a/tests/ref/fate/hapqa-extract-nosnappy-to-hapq-mov
> b/tests/ref/fate/hapqa-extract-nosnappy-to-hapq-mov
> index 1fb31ec7f0..d9e5c94ffb 100644
> --- a/tests/ref/fate/hapqa-extract-nosnappy-to-hapq-mov
> +++ b/tests/ref/fate/hapqa-extract-nosnappy-to-hapq-mov
> @@ -69,5 +69,6 @@ DISPOSITION:attached_pic=0
> DISPOSITION:timed_thumbnails=0
> TAG:language=eng
> TAG:handler_name=Module de gestion video
> +TAG:vendor_id=FFMP
> TAG:encoder=HAPQ
> [/STREAM]
> diff --git a/tests/ref/fate/mov-zombie b/tests/ref/fate/mov-zombie
> index 1a6625bc8f..c566b14d47 100644
> --- a/tests/ref/fate/mov-zombie
> +++ b/tests/ref/fate/mov-zombie
> @@ -194,5 +194,5 @@
> frame|media_type=video|stream_index=0|key_frame=0|pkt_pts=188623|pkt_pts_time=2.
>
>
> packet|codec_type=video|stream_index=0|pts=197632|pts_time=2.195911|dts=191625|dts_time=2.129167|duration=3003|duration_time=0.033367|convergence_duration=N/A|convergence_duration_time=N/A|size=580|pos=101820|flags=__
>
> frame|media_type=video|stream_index=0|key_frame=0|pkt_pts=191626|pkt_pts_time=2.129178|pkt_dts=N/A|pkt_dts_time=N/A|best_effort_timestamp=191626|best_effort_timestamp_time=2.129178|pkt_duration=3003|pkt_duration_time=0.033367|pkt_pos=99180|pkt_size=1666|width=160|height=240|pix_fmt=yuv420p|sample_aspect_ratio=2:1|pict_type=P|coded_picture_number=63|display_picture_number=0|interlaced_frame=0|top_field_first=0|repeat_pict=0|color_range=tv|color_space=smpte170m|color_primaries=smpte170m|color_transfer=bt709|chroma_location=topleftside_data|side_data_type=H.26[45]
> User Data Unregistered SEI message
>
> -stream|index=0|codec_name=h264|profile=77|codec_type=video|codec_time_base=212521/12744000|codec_tag_string=avc1|codec_tag=0x31637661|width=160|height=240|coded_width=160|coded_height=240|closed_captions=0|has_b_frames=1|sample_aspect_ratio=2:1|display_aspect_ratio=4:3|pix_fmt=yuv420p|level=12|color_range=tv|color_space=smpte170m|color_transfer=bt709|color_primaries=smpte170m|chroma_location=topleft|field_order=unknown|timecode=N/A|refs=2|is_avc=true|nal_length_size=4|id=N/A|r_frame_rate=3/1001|avg_frame_rate=6372000/212521|time_base=1/9|start_pts=0|start_time=0.00|duration_ts=2125200|duration=23.61|bit_rate=333874|max_bit_rate=N/A|bits_per_raw_sample=8|nb_frames=708|nb_read_frames=65|nb_read_packets=66|disposition:default=1|disposition:dub=0|disposition:original=0|disposition:comment=0|disposition:lyrics=0|disposition:karaoke=0|disposition:for
Re: [FFmpeg-devel] Next developer meeting
Hi, we haven't had a meeting for quite some time and are beyond schedule anyway. So I'd propose having another developer meeting before end of year. Please give your preferences for a date here: https://framadate.org/g1FPmOpfEz9mSLg9 one week later, we have settled for having the FFDev meeting on Saturday, Dec 5th. Based on last time, I told we aim for 17 UTC for the vote. Steven made some comments I don't fully understand... If someone want to shift it, please propose a better time. An overview might be: https://www.timeanddate.de/zeitzonen/konferenz?iso=20201205&p1=224&p2=37&p3=33 What about shift to 16 UTC? Because it’s 01:00:00 AM in Peking if aim 17 UTC. :D I've got it even worse, 1700 UTC is 3AM for me (Australia, UTC+10). Shifting back even further to 1300/1400 UTC (11pm/12am) would be greatly appreciated (if even possible). Not only no problem but also feel happy in Peking. Haha :D If there's no US comment about too early bird for them...? no more replies against, so we shift the time to 15:00 UTC (7:00 US West, 16:00 Berlin/London/Paris, 23:00 Peking). Happening at #ffmpeg-meeting. -Thilo ___ 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 1/6] avutil/timecode: allow drop frame timecodes for multiples of 30000/1001 fps
On Sat, 28 Nov 2020, Marton Balint wrote:
Signed-off-by: Marton Balint
---
libavutil/timecode.c | 17 +++--
libavutil/timecode.h | 4 ++--
2 files changed, 9 insertions(+), 12 deletions(-)
Applied the series.
Regards,
Marton
diff --git a/libavutil/timecode.c b/libavutil/timecode.c
index f2db21c52c..7caa6c64f5 100644
--- a/libavutil/timecode.c
+++ b/libavutil/timecode.c
@@ -33,16 +33,13 @@
int av_timecode_adjust_ntsc_framenum2(int framenum, int fps)
{
-/* only works for NTSC 29.97 and 59.94 */
+/* only works for multiples of NTSC 29.97 */
int drop_frames = 0;
int d, m, frames_per_10mins;
-if (fps == 30) {
-drop_frames = 2;
-frames_per_10mins = 17982;
-} else if (fps == 60) {
-drop_frames = 4;
-frames_per_10mins = 35964;
+if (fps && fps % 30 == 0) {
+drop_frames = fps / 30 * 2;
+frames_per_10mins = fps / 30 * 17982;
} else
return framenum;
@@ -196,8 +193,8 @@ static int check_timecode(void *log_ctx, AVTimecode *tc)
av_log(log_ctx, AV_LOG_ERROR, "Valid timecode frame rate must be specified.
Minimum value is 1\n");
return AVERROR(EINVAL);
}
-if ((tc->flags & AV_TIMECODE_FLAG_DROPFRAME) && tc->fps != 30 && tc->fps
!= 60) {
-av_log(log_ctx, AV_LOG_ERROR, "Drop frame is only allowed with 3/1001
or 6/1001 FPS\n");
+if ((tc->flags & AV_TIMECODE_FLAG_DROPFRAME) && tc->fps % 30 != 0) {
+av_log(log_ctx, AV_LOG_ERROR, "Drop frame is only allowed with multiples of
3/1001 FPS\n");
return AVERROR(EINVAL);
}
if (check_fps(tc->fps) < 0) {
@@ -252,7 +249,7 @@ int av_timecode_init_from_string(AVTimecode *tc, AVRational
rate, const char *st
tc->start = (hh*3600 + mm*60 + ss) * tc->fps + ff;
if (tc->flags & AV_TIMECODE_FLAG_DROPFRAME) { /* adjust frame number */
int tmins = 60*hh + mm;
-tc->start -= (tc->fps == 30 ? 2 : 4) * (tmins - tmins/10);
+tc->start -= (tc->fps / 30 * 2) * (tmins - tmins/10);
}
return 0;
}
diff --git a/libavutil/timecode.h b/libavutil/timecode.h
index f9471a6e38..697e61180b 100644
--- a/libavutil/timecode.h
+++ b/libavutil/timecode.h
@@ -49,9 +49,9 @@ typedef struct {
* Adjust frame number for NTSC drop frame time code.
*
* @param framenum frame number to adjust
- * @param fps frame per second, 30 or 60
+ * @param fps frame per second, multiples of 30
* @return adjusted frame number
- * @warningadjustment is only valid in NTSC 29.97 and 59.94
+ * @warningadjustment is only valid for multiples of NTSC 29.97
*/
int av_timecode_adjust_ntsc_framenum2(int framenum, int fps);
--
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".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/vaapi_av1: fill the remaining VAFilmGrainStructAV1 fields
On 11/30/2020 7:42 PM, James Almer wrote:
Signed-off-by: James Almer
---
libavcodec/vaapi_av1.c | 60 +++---
1 file changed, 51 insertions(+), 9 deletions(-)
diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
index 2763c1e866..b76e217daa 100644
--- a/libavcodec/vaapi_av1.c
+++ b/libavcodec/vaapi_av1.c
@@ -115,15 +115,27 @@ static int vaapi_av1_start_frame(AVCodecContext *avctx,
.temporal_update = frame_header->segmentation_temporal_update,
.update_data = frame_header->segmentation_update_data,
},
-.film_grain_info.film_grain_info_fields.bits = {
-.apply_grain = film_grain->apply_grain,
-.chroma_scaling_from_luma = film_grain->chroma_scaling_from_luma,
-.grain_scaling_minus_8= film_grain->grain_scaling_minus_8,
-.ar_coeff_lag = film_grain->ar_coeff_lag,
-.ar_coeff_shift_minus_6 = film_grain->ar_coeff_shift_minus_6,
-.grain_scale_shift= film_grain->grain_scale_shift,
-.overlap_flag = film_grain->overlap_flag,
-.clip_to_restricted_range = film_grain->clip_to_restricted_range,
+.film_grain_info = {
+.film_grain_info_fields.bits = {
+.apply_grain = film_grain->apply_grain,
+.chroma_scaling_from_luma =
film_grain->chroma_scaling_from_luma,
+.grain_scaling_minus_8= film_grain->grain_scaling_minus_8,
+.ar_coeff_lag = film_grain->ar_coeff_lag,
+.ar_coeff_shift_minus_6 = film_grain->ar_coeff_shift_minus_6,
+.grain_scale_shift= film_grain->grain_scale_shift,
+.overlap_flag = film_grain->overlap_flag,
+.clip_to_restricted_range =
film_grain->clip_to_restricted_range,
+},
+.grain_seed= film_grain->grain_seed,
+.num_y_points = film_grain->num_y_points,
+.num_cb_points = film_grain->num_cb_points,
+.num_cr_points = film_grain->num_cr_points,
+.cb_mult = film_grain->cb_mult,
+.cb_luma_mult = film_grain->cb_luma_mult,
+.cb_offset = film_grain->cb_offset,
+.cr_mult = film_grain->cr_mult,
+.cr_luma_mult = film_grain->cr_luma_mult,
+.cr_offset = film_grain->cr_offset,
},
.pic_info_fields.bits = {
.frame_type = frame_header->frame_type,
@@ -203,6 +215,36 @@ static int vaapi_av1_start_frame(AVCodecContext *avctx,
for (int j = 0; j < 6; j++)
pic_param.wm[i - 1].wmmat[j] = s->cur_frame.gm_params[i][j];
}
+if (film_grain->apply_grain) {
+for (int i = 0; i < film_grain->num_y_points; i++) {
+pic_param.film_grain_info.point_y_value[i] =
+film_grain->point_y_value[i];
+pic_param.film_grain_info.point_y_scaling[i] =
+film_grain->point_y_scaling[i];
+}
+for (int i = 0; i < film_grain->num_cb_points; i++) {
+pic_param.film_grain_info.point_cb_value[i] =
+film_grain->point_cb_value[i];
+pic_param.film_grain_info.point_cb_scaling[i] =
+film_grain->point_cb_scaling[i];
+}
+for (int i = 0; i < film_grain->num_cr_points; i++) {
+pic_param.film_grain_info.point_cr_value[i] =
+film_grain->point_cr_value[i];
+pic_param.film_grain_info.point_cr_scaling[i] =
+film_grain->point_cr_scaling[i];
+}
+for (int i = 0; i < 24; i++) {
+pic_param.film_grain_info.ar_coeffs_y[i] =
+film_grain->ar_coeffs_y_plus_128[i] - 128;
+}
+for (int i = 0; i < 25; i++) {
+pic_param.film_grain_info.ar_coeffs_cb[i] =
+film_grain->ar_coeffs_cb_plus_128[i] - 128;
+pic_param.film_grain_info.ar_coeffs_cr[i] =
+film_grain->ar_coeffs_cr_plus_128[i] - 128;
+}
+}
err = ff_vaapi_decode_make_param_buffer(avctx, pic,
VAPictureParameterBufferType,
&pic_param, sizeof(pic_param));
Ping.
___
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] avfilter/vf_hwupload_cuda: add transparent pix_fmts
Signed-off-by: Daniel Raniz Raneland --- libavfilter/vf_hwupload_cuda.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavfilter/vf_hwupload_cuda.c b/libavfilter/vf_hwupload_cuda.c index 33906f2515..83b7babeaa 100644 --- a/libavfilter/vf_hwupload_cuda.c +++ b/libavfilter/vf_hwupload_cuda.c @@ -60,6 +60,7 @@ static int cudaupload_query_formats(AVFilterContext *ctx) AV_PIX_FMT_NV12, AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV444P, AV_PIX_FMT_P010, AV_PIX_FMT_P016, AV_PIX_FMT_YUV444P16, AV_PIX_FMT_0RGB32, AV_PIX_FMT_0BGR32, +AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUVA444P, #if CONFIG_VULKAN AV_PIX_FMT_VULKAN, #endif -- 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] avformat/rmdec: Reorder operations to avoid overflow
Fixes: signed integer overflow: -2147483648 - 14 cannot be represented in type
'int'
Fixes:
27659/clusterfuzz-testcase-minimized-ffmpeg_dem_RM_fuzzer-5697250168406016
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/rmdec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
index 004c62086d..a82519987c 100644
--- a/libavformat/rmdec.c
+++ b/libavformat/rmdec.c
@@ -719,9 +719,9 @@ static int rm_sync(AVFormatContext *s, int64_t *timestamp,
int *flags, int *stre
av_log(s, AV_LOG_WARNING,
"Index size %d (%d pkts) is wrong, should be
%"PRId64".\n",
len, n_pkts, expected_len);
-len -= 14; // we already read part of the index header
-if(len<0)
+if(len < 14)
continue;
+len -= 14; // we already read part of the index header
goto skip;
} else if (state == MKBETAG('D','A','T','A')) {
av_log(s, AV_LOG_WARNING,
--
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/3] avcodec/mxpegdec: fix SOF counting
Fixes: Timeout (>10sec -> 15ms)
Fixes:
27652/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MXPEG_fuzzer-5125920868007936
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/mxpegdec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/mxpegdec.c b/libavcodec/mxpegdec.c
index 55ec6e928e..f89226fefa 100644
--- a/libavcodec/mxpegdec.c
+++ b/libavcodec/mxpegdec.c
@@ -247,16 +247,17 @@ static int mxpeg_decode_frame(AVCodecContext *avctx,
"Multiple SOF in a frame\n");
return AVERROR_INVALIDDATA;
}
-s->got_sof_data = 0;
ret = ff_mjpeg_decode_sof(jpg);
if (ret < 0) {
av_log(avctx, AV_LOG_ERROR,
"SOF data decode error\n");
+s->got_sof_data = 0;
return ret;
}
if (jpg->interlaced) {
av_log(avctx, AV_LOG_ERROR,
"Interlaced mode not supported in MxPEG\n");
+s->got_sof_data = 0;
return AVERROR(EINVAL);
}
s->got_sof_data ++;
--
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 1/3] avformat/id3v2: Sanity check tlen before alloc and uncompress
Fixes: Timeout (>20sec -> 65ms)
Fixes:
26896/clusterfuzz-testcase-minimized-ffmpeg_dem_DAUD_fuzzer-5691024049176576
Fixes:
27627/clusterfuzz-testcase-minimized-ffmpeg_dem_AEA_fuzzer-4907019324358656
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/id3v2.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
index cecd9b9f6d..336a3964de 100644
--- a/libavformat/id3v2.c
+++ b/libavformat/id3v2.c
@@ -993,6 +993,9 @@ static void id3v2_parse(AVIOContext *pb, AVDictionary
**metadata,
av_log(s, AV_LOG_DEBUG, "Compresssed frame %s tlen=%d
dlen=%ld\n", tag, tlen, dlen);
+if (tlen <= 0)
+goto seek;
+
av_fast_malloc(&uncompressed_buffer,
&uncompressed_buffer_size, dlen);
if (!uncompressed_buffer) {
av_log(s, AV_LOG_ERROR, "Failed to alloc %ld bytes\n",
dlen);
--
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] http: support retry on connection error
Hi Marton,
Thank you for the feedback, and sorry for my late reply :)
Please see my responses inline, updated patch attached.
Thanks
Eran
> -Original Message-
> From: ffmpeg-devel On Behalf Of Marton
> Balint
> Sent: Wednesday, November 18, 2020 10:46 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] http: support retry on connection error
>
>
> > - reconnect_on_status - a list of http status codes that should be
> > retried. the list can contain explicit status codes / the strings
> > 4xx/5xx.
>
> Maybe better name this option reconnect_on_http_error. Also this is a
> flags-like option, so use AV_OPT_TYPE_FLAGS with 4xx and 5xx as flags.
>
Rename - done.
Flags - the patch supports both explicit status codes (e.g. 503) and status
groups (e.g. 4xx).
For example, it is possible to specify -reconnect_on_http_error '4xx,503'.
In my understanding, AV_OPT_TYPE_FLAGS is a simple int, so the only to support
what I wrote above, is to assign bits
to specific status codes, and I don't think we want to go there... (because
every time someone will want to retry on a new status code,
we will need to update the code)
>
> > - reconnect_on_err - reconnects on arbitrary errors during connect, e.g.
> > ECONNRESET/ETIMEDOUT
>
> Maybe reconnect_on_network_error better reflects that this reconnects on
> underlying protocol (TCP/TLS) error.
>
> Anyhow, the new options should be added to docs/protocols.texi.
>
Rename & docs - done.
> >
> > +{ "reconnect_on_err", "auto reconnect in case of tcp/tls error during
> > connect", OFFSET(reconnect_on_err), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, D
> > },
> > +{ "reconnect_on_status", "list of http status codes to reconnect on.
> > the list can include specific status codes / 4xx / 5xx",
> > OFFSET(reconnect_on_status), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D },
>
> AV_OPT_TYPE_FLAGS, as I explained above.
>
Replied above
> >
> > location_changed = http_open_cnx_internal(h, options);
>
> Are you sure you get AVERROR_HTTP_* here? Also if you follow the code
> there is special handling of 401/407, that should be done first before
> your checks, no?
>
1. Yes, I tested the change before submitting, used some test PHP server to
simulate errors.
This is the call stack that propagates the AVERROR_HTTP_* codes -
http_open_cnx_internal
http_connect
http_read_header
process_line
check_http_code
2. In case of 401/407, check_http_code returns 0, and therefore
http_open_cnx_internal return 0 as well (assuming there is no other error...).
So, it doesn't enter 'if (location_changed < 0)' and it behaves the same
way it did before my changes.
>
> Another comment is that if you want to reconnect based on errors
> classified as 4xx or 5xx, then probably you should revisit
> ff_http_averror(400, xxx) calls and check if they are indeed caused by
> client behaviour. Because if the server is violating the protocol, then
> they should be ff_http_averror(500, xxx) IMHO.
>
Checked the code, I see 2 cases of ff_http_averror(400, xxx) -
1. HTTP server received an unexpected http method (would have been more correct
to use 405, but don't think it matters...)
2. HTTP server received an invalid http version string
So, I think it's fine.
> Regards,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmpeg-devel&data=04%7C01%7Ceran.kornblau%40kaltura.com%7C590db1ef6c4d484bb34508d88c030453%7C0c503748de3f4e2597e26819d53a42b6%7C0%7C0%7C637413291875784243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hemm499pmQQQEDOc4FXeq1EThvOT7FyfjWRsylFvdm0%3D&reserved=0
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
0001-http-support-retry-on-connection-error.patch
Description: 0001-http-support-retry-on-connection-error.patch
___
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] libavcodec/qsvenc: Adding support for HDR metadata to hevc qsv encode
On Wed, 2020-12-02 at 13:18 +, Fredrick Odhiambo wrote:
> This patch allows passing of HDR10 metadata through qsv_params for encoding
> with hevc_qsv similar to how HDR10 parameters are passed to x265-params in
> libx265 encoding. The HDR10 metadata parameters passed are master-display,
> max-cll, color primary, color matrix, transfer characteristics and color
> range.
>
> -qsv_params master-
> display=R(35399,14599)G(8500,39850)B(6550,2300)WP(15634,16450)L(1000,50):m
> ax-
> cll=1000,400:colorprim=bt2020:colormatrix=bt2020c:transfer=smpte2084:range=ful
> l -y hdr_vid_output.mp4
May we get the HDR parameters from input frame via
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA ?
avcodec has already provided options color_primaries / color_trc / colorspace /
color_range to set the corresponding parameters in avctx.
>
> Signed-off-by: Fredrick Odhiambo
> ---
> libavcodec/qsvenc.c | 425
> libavcodec/qsvenc.h | 110 +++-
> 2 files changed, 534 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 2bd2a56227..29faa59497 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -1102,6 +1102,7 @@ int ff_qsv_enc_init(AVCodecContext *avctx, QSVEncContext
> *q)
> int iopattern = 0;
> int opaque_alloc = 0;
> int ret;
> +AVContentLightMetadata light_meta;
>
> q->param.AsyncDepth = q->async_depth;
>
> @@ -1203,6 +1204,92 @@ int ff_qsv_enc_init(AVCodecContext *avctx,
> QSVEncContext *q)
> return ret;
> }
>
> +if (q->qsv_opts) {
> +AVDictionaryEntry *en = NULL;
> +AVMasteringDisplayMetadata hdr_meta;
> +memset(&hdr_meta, 0, sizeof(AVMasteringDisplayMetadata));
> +memset(&light_meta, 0, sizeof(AVContentLightMetadata));
> +if (!avctx) {
> +return ff_qsv_print_error(avctx, MFX_ERR_INVALID_VIDEO_PARAM,
> + "AVCodecContext no set");
> +}
Don't check avctx against NULL after the pointer has been dereferenced.
> +
> +while ((en = av_dict_get(q->qsv_opts, "", en,
> AV_DICT_IGNORE_SUFFIX))) {
> +int parse_ret = ff_qsv_validate_params(en->key, en->value);
> +switch (parse_ret) {
> +case QSV_PARAM_VALID:
> + if (!strcmp(en->key, "master-display")) {
Please use the same indentation style.
> +ff_qsv_extract_display_values(en->value, &hdr_meta);
> +break;
> +}
> +if (!strcmp(en->key, "range")) {
> +avctx->color_range = ff_qsv_extract_range_value(en-
> >value);
> +break;
> +}
> +if (!strcmp(en->key, "max-cll")) {
> + ff_qsv_get_content_light_level(en->value,
> &light_meta);
> + break;
> +}
> +if (!strcmp(en->key, "colorprim")) {
> +avctx->color_primaries =
> av_color_primaries_from_name(en->value);
> +break;
> +}
> +if (!strcmp(en->key, "colormatrix")) {
> +avctx->colorspace = av_color_space_from_name(en-
> >value);
> +break;
> +}
> +if (!strcmp(en->key, "transfer")) {
> +avctx->color_trc = av_color_transfer_from_name(en-
> >value);
> +break;
> +}
> +case QSV_PARAM_BAD_VALUE:
> +av_log(q, AV_LOG_ERROR,
> +"Invalid value for %s: %s.\n", en->key, en->value);
> +return ff_qsv_print_error(avctx,
> MFX_ERR_INVALID_VIDEO_PARAM,
> + "Invalid value");
> +case QSV_PARAM_BAD_NAME:
> +av_log(q, AV_LOG_ERROR,
> +"Invalid value for %s: %s.\n", en->key, en->value);
> +return ff_qsv_print_error(avctx,
> MFX_ERR_INVALID_VIDEO_PARAM,
> + "Invalid parameter name");
> +}
> +}
> +#if QSV_HAVE_HDR_METADATA
> +if (hdr_meta.has_primaries) {
> +q->master_display_volume_data.Header.BufferId =
> MFX_EXTBUFF_MASTERING_DISPLAY_COLOUR_VOLUME;
> +q->master_display_volume_data.Header.BufferSz = sizeof(q-
> >master_display_volume_data);
> +q->master_display_volume_data.InsertPayloadToggle =
> MFX_PAYLOAD_IDR;
> +q->master_display_volume_data.DisplayPrimariesX[0] =
> (int)av_q2d(hdr_meta.display_primaries[0][0]);
> +q->master_display_volume_data.DisplayPrimariesX[1] =
> (int)av_q2d(hdr_meta.display_primaries[0][1]);
> +q->master_display_volume_data.DisplayPrimariesX[2] =
> (int)av_q2d(hdr_meta.display_primaries[1][0]);
