Re: [FFmpeg-devel] [PATCH 2/2] dnn_backend_native: check operand index

[Guo, Yejun]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> myp...@gmail.com
> Sent: 2020年6月16日 14:18
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] dnn_backend_native: check operand
> index
> 
> On Wed, Jun 10, 2020 at 10:04 PM Guo Yejun  wrote:
> >
> > it fixed the issue in https://trac.ffmpeg.org/ticket/8716
> >
> > Signed-off-by: Guo Yejun 
> >
> > +if (operand_index >= network->operands_num) {
> > +goto fail;
> > +}
> > +
> I prefer
> if (expr)
> statements();
> without the braces if only a single statement.

thanks for the review. 

I personally like to always add '{}' to avoid possible mistakes when we change 
code in the future. Some coding styles also recommend this method.

I checked at http://ffmpeg.org/developer.html#Coding-Rules and do not find an 
explicit description. But I just remembered that someone also mentioned this 
some time ago. I'll change to this style in v2 if no support from others for my 
style.
___
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 v5 3/3] fate: add yuv420p10 and yuv422p10 tests for overlay filter

[lance . lmwang]

From: Limin Wang 

Signed-off-by: Limin Wang 
---
tested on x86_64, x86_32, qemu mips 32bit

 tests/fate/filter-video.mak | 8 
 tests/filtergraphs/overlay_yuv420p10| 5 +
 tests/filtergraphs/overlay_yuv422p10| 5 +
 tests/ref/fate/filter-overlay_yuv420p10 | 8 
 tests/ref/fate/filter-overlay_yuv422p10 | 8 
 5 files changed, 34 insertions(+)
 create mode 100644 tests/filtergraphs/overlay_yuv420p10
 create mode 100644 tests/filtergraphs/overlay_yuv422p10
 create mode 100644 tests/ref/fate/filter-overlay_yuv420p10
 create mode 100644 tests/ref/fate/filter-overlay_yuv422p10

diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index cfeb53e..18fe4f7 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -223,6 +223,10 @@ FATE_FILTER_VSYNTH-$(call ALLYES, SPLIT_FILTER 
SCALE_FILTER PAD_FILTER OVERLAY_F
 fate-filter-overlay_yuv420: tests/data/filtergraphs/overlay_yuv420
 fate-filter-overlay_yuv420: CMD = framecrc -c:v pgmyuv -i $(SRC) 
-filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/overlay_yuv420
 
+FATE_FILTER_VSYNTH-$(call ALLYES, SPLIT_FILTER SCALE_FILTER PAD_FILTER 
OVERLAY_FILTER) += fate-filter-overlay_yuv420p10
+fate-filter-overlay_yuv420p10: tests/data/filtergraphs/overlay_yuv420p10
+fate-filter-overlay_yuv420p10: CMD = framecrc -c:v pgmyuv -i $(SRC) 
-filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/overlay_yuv420p10 
-pix_fmt yuv420p10le -frames:v 3
+
 FATE_FILTER_VSYNTH-$(call ALLYES, SPLIT_FILTER SCALE_FILTER PAD_FILTER 
OVERLAY_FILTER) += fate-filter-overlay_nv12
 fate-filter-overlay_nv12: tests/data/filtergraphs/overlay_nv12
 fate-filter-overlay_nv12: CMD = framecrc -c:v pgmyuv -i $(SRC) 
-filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/overlay_nv12
@@ -237,6 +241,10 @@ FATE_FILTER_VSYNTH-$(call ALLYES, SPLIT_FILTER 
SCALE_FILTER PAD_FILTER OVERLAY_F
 fate-filter-overlay_yuv422: tests/data/filtergraphs/overlay_yuv422
 fate-filter-overlay_yuv422: CMD = framecrc -c:v pgmyuv -i $(SRC) 
-filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/overlay_yuv422
 
+FATE_FILTER_VSYNTH-$(call ALLYES, SPLIT_FILTER SCALE_FILTER PAD_FILTER 
OVERLAY_FILTER) += fate-filter-overlay_yuv422p10
+fate-filter-overlay_yuv422p10: tests/data/filtergraphs/overlay_yuv422p10
+fate-filter-overlay_yuv422p10: CMD = framecrc -c:v pgmyuv -i $(SRC) 
-filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/overlay_yuv422p10 
-pix_fmt yuv422p10le -frames:v 3
+
 FATE_FILTER_VSYNTH-$(call ALLYES, SPLIT_FILTER SCALE_FILTER PAD_FILTER 
OVERLAY_FILTER) += fate-filter-overlay_yuv444
 fate-filter-overlay_yuv444: tests/data/filtergraphs/overlay_yuv444
 fate-filter-overlay_yuv444: CMD = framecrc -c:v pgmyuv -i $(SRC) 
-filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/overlay_yuv444
diff --git a/tests/filtergraphs/overlay_yuv420p10 
b/tests/filtergraphs/overlay_yuv420p10
new file mode 100644
index 000..d946d3c
--- /dev/null
+++ b/tests/filtergraphs/overlay_yuv420p10
@@ -0,0 +1,5 @@
+sws_flags=+accurate_rnd+bitexact;
+split [main][over];
+[over] scale=88:72, format=yuv420p10, pad=96:80:4:4 [overf];
+[main] format=yuv420p10 [mainf];
+[mainf][overf] overlay=240:16:format=yuv420p10
diff --git a/tests/filtergraphs/overlay_yuv422p10 
b/tests/filtergraphs/overlay_yuv422p10
new file mode 100644
index 000..5753ba6
--- /dev/null
+++ b/tests/filtergraphs/overlay_yuv422p10
@@ -0,0 +1,5 @@
+sws_flags=+accurate_rnd+bitexact;
+split [main][over];
+[over] scale=88:72, format=yuv420p10, pad=96:80:4:4 [overf];
+[main] format=yuv420p10 [mainf];
+[mainf][overf] overlay=240:16:format=yuv422p10
diff --git a/tests/ref/fate/filter-overlay_yuv420p10 
b/tests/ref/fate/filter-overlay_yuv420p10
new file mode 100644
index 000..b431dc6
--- /dev/null
+++ b/tests/ref/fate/filter-overlay_yuv420p10
@@ -0,0 +1,8 @@
+#tb 0: 1/25
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 352x288
+#sar 0: 0/1
+0,  0,  0,1,   304128, 0x29a6ca86
+0,  1,  1,1,   304128, 0x82950e6f
+0,  2,  2,1,   304128, 0x8363d1d8
diff --git a/tests/ref/fate/filter-overlay_yuv422p10 
b/tests/ref/fate/filter-overlay_yuv422p10
new file mode 100644
index 000..c0a58f9
--- /dev/null
+++ b/tests/ref/fate/filter-overlay_yuv422p10
@@ -0,0 +1,8 @@
+#tb 0: 1/25
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 352x288
+#sar 0: 0/1
+0,  0,  0,1,   405504, 0x11108b36
+0,  1,  1,1,   405504, 0x9d5f7c2a
+0,  2,  2,1,   405504, 0x25373098
-- 
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/7] avfilter: add ff_inlink_peek_samples and ff_inlink_skip samples

[Nicolas George]

Paul B Mahol (12020-06-12):
> How so? Its purely random.

+ret = ff_inlink_peek_samples(inlink, s->win_size, &fin);

+ret = ff_inlink_peek_samples(inlink, s->window_size, &in);

They seem constant in both cases. Can you elaborate about this
randomness?

-- 
  Nicolas George


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 v2 4/5] fftools/ffmpeg: flush and recreate encoder instance if resolution changes

[Nicolas George]

Fu, Linjie (12020-06-12):
> IIRC, the global header in extra data is optional in codec level.

Where did you take that?

The way I understand it, people who design codec will decide if they use
global extradata or not, but if they decide to, it is necessary to
decode the data. Otherwise, it would not be there!

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] dnn_backend_native: check operand index

[Carl Eugen Hoyos]

> Am 16.06.2020 um 10:18 schrieb Guo, Yejun :
> 
> I personally like to always add '{}' to avoid possible mistakes when we 
> change code in the future. Some coding styles also recommend this method.
> 
> I checked at http://ffmpeg.org/developer.html#Coding-Rules and do not find an 
> explicit description. But I just remembered that someone also mentioned this 
> some time ago. I'll change to this style in v2 if no support from others for 
> my style.

I support your style but it is only the file maintainer‘s decision.

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 2/2] avformat/mxfdec: Error out on duplicated utf16 strings

[Tomas Härdin]

mån 2020-06-15 klockan 21:45 +0200 skrev Marton Balint:
> 
> On Mon, 15 Jun 2020, Tomas Härdin wrote:
> 
> > sön 2020-06-14 klockan 20:19 +0200 skrev Marton Balint:
> > > On Sun, 14 Jun 2020, Michael Niedermayer wrote:
> > > 
> > > > Alternatively we could free the already allocated element
> > > 
> > > Yeah, I kind of prefer that, we potentially allow non-string values to 
> > > occur multiple times, so I'd say let's allow string values as well, even 
> > > if that is not common. (I am not sure if it is strictly invalid or just 
> > > uncommon).
> > 
> > Are there files in the wild that do this? Being stricter is often the
> > better option when it comes to MXF. A muxer that outputs metadata more
> > than once might be doing something wrong.
> 
> I am not sure, but I wanted to be safe rather than sorry, because it is 
> not unusual in MXF to repeat certain metadata in the footer partition 
> which is already present in the header, and I did not want to take the 
> risk of rejecting a valid file.

True, that is not unheard of. Maybe we could warn if the strings don't
match?

/Tomas

___
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/dashenc: Calculate average bitrate for adaptation sets in static manifest

[Przemysław Sobala]

If stream's bitrate is not specified:
- for static manifest: an average bitrate will be calculated and used,
- for dynamic manifest: first segment's bitrate will be calculated and used, as 
before,
for bandwidth setting in adaptation sets.

For dynamic manifest
---
 libavformat/dashenc.c | 28 +---
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 05deb5c1b5..6e1a6dbf3a 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -115,6 +115,8 @@ typedef struct OutputStream {
 int64_t last_dts, last_pts;
 int last_flags;
 int bit_rate;
+int first_segment_bit_rate;
+double average_bit_rate;
 SegmentType segment_type;  /* segment type selected for this particular 
stream */
 const char *format_name;
 const char *extension_name;
@@ -840,8 +842,11 @@ static int write_adaptation_set(AVFormatContext *s, 
AVIOContext *out, int as_ind
 continue;
 
 if (os->bit_rate > 0)
-snprintf(bandwidth_str, sizeof(bandwidth_str), " bandwidth=\"%d\"",
- os->bit_rate);
+snprintf(bandwidth_str, sizeof(bandwidth_str), " 
bandwidth=\"%d\"", os->bit_rate);
+else if (final && os->average_bit_rate > 0)
+snprintf(bandwidth_str, sizeof(bandwidth_str), " 
bandwidth=\"%d\"", (int) os->average_bit_rate);
+else if (os->first_segment_bit_rate > 0)
+snprintf(bandwidth_str, sizeof(bandwidth_str), " 
bandwidth=\"%d\"", os->first_segment_bit_rate);
 
 if (as->media_type == AVMEDIA_TYPE_VIDEO) {
 avio_printf(out, "\t\t\tstreams[i];
 char *agroup = NULL;
 char *codec_str_ptr = NULL;
-int stream_bitrate = st->codecpar->bit_rate + os->muxer_overhead;
+int stream_bitrate = os->muxer_overhead;
+if (os->bit_rate > 0)
+stream_bitrate += os->bit_rate;
+else if (final && os->average_bit_rate > 0)
+stream_bitrate += os->average_bit_rate;
+else if (os->first_segment_bit_rate > 0)
+stream_bitrate += os->first_segment_bit_rate;
 if (st->codecpar->codec_type != AVMEDIA_TYPE_VIDEO)
 continue;
 if (os->segment_type != SEGMENT_TYPE_MP4)
@@ -1959,10 +1970,13 @@ static int dash_flush(AVFormatContext *s, int final, 
int stream)
 os->total_pkt_duration = 0;
 
 if (!os->bit_rate) {
-// calculate average bitrate of first segment
-int64_t bitrate = (int64_t) range_length * 8 * AV_TIME_BASE / 
duration;
-if (bitrate >= 0)
-os->bit_rate = bitrate;
+// calculate average bitrate
+int64_t segment_bitrate = (int64_t) range_length * 8 * 
AV_TIME_BASE / duration;
+if (!os->first_segment_bit_rate)
+os->first_segment_bit_rate = segment_bitrate;
+os->average_bit_rate = (os->average_bit_rate * (os->segment_index 
- 1) + segment_bitrate) / os->segment_index;
+av_log(s, AV_LOG_INFO, "segment_bitrate: %"PRId64", 
os->first_segment_bit_rate: %i, os->average_bit_rate: %f\n",
+segment_bitrate, os->first_segment_bit_rate, 
os->average_bit_rate);
 }
 add_segment(os, os->filename, os->start_pts, os->max_pts - 
os->start_pts, os->pos, range_length, index_length, next_exp_index);
 av_log(s, AV_LOG_VERBOSE, "Representation %d media segment %d written 
to: %s\n", i, os->segment_index, os->full_path);
-- 
2.25.4

___
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] Revert "avformat/dashenc: use AVStream timebase when computing missing bitrate"

[Przemysław Sobala]

This reverts commit 2a9ffd89fcb09bd69b2130da039ad2caba79cf33 as duration is 
always in AV_TIME_BASE units
---
 libavformat/dashenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 3e587acdff..05deb5c1b5 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1960,7 +1960,7 @@ static int dash_flush(AVFormatContext *s, int final, int 
stream)
 
 if (!os->bit_rate) {
 // calculate average bitrate of first segment
-int64_t bitrate = (int64_t) range_length * 8 * (c->use_timeline ? 
os->ctx->streams[0]->time_base.den : AV_TIME_BASE) / duration;
+int64_t bitrate = (int64_t) range_length * 8 * AV_TIME_BASE / 
duration;
 if (bitrate >= 0)
 os->bit_rate = bitrate;
 }
-- 
2.25.4

___
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 4/5] fftools/ffmpeg: flush and recreate encoder instance if resolution changes

[Fu, Linjie]

> From: ffmpeg-devel  On Behalf Of
> Nicolas George
> Sent: Tuesday, June 16, 2020 18:55
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2 4/5] fftools/ffmpeg: flush and
> recreate encoder instance if resolution changes
> 
> Fu, Linjie (12020-06-12):
> > IIRC, the global header in extra data is optional in codec level.
> 
> Where did you take that?

Chapter 2.3 Parameter Sets in < High Efficiency Video Coding (HEVC)
Algorithms and Architectures> [1]:

"Reusing parameter sets is bit rate efficient because it avoids the
necessity to send shared information multiple times. It is also loss
robust because it allows parameter set content to be carried by some
more reliable external communication link or to be repeated frequently
within the bitstream to ensure that it will not get lost."

> The way I understand it, people who design codec will decide if they use
> global extradata or not, but if they decide to, it is necessary to
> decode the data. Otherwise, it would not be there!

Indeed, the definition in spec is just the conformance, and how an encoder is
implemented in Libavcodec (and external library if any) is the thing really 
matters.

For encoders like libx264[2], libx265[3], libopenh264[4], if 
AV_CODEC_FLAG_GLOBAL_HEADER
flag is declared, the parameter Sets would be copied to extra data as the 
global header.
If not, parameter sets would be kept in the original bitstream, since it's 
fundamentally
supported in the encoder.
(BTW, librav1e seems to be identical, but I didn't check all the encoder and 
details for now)

And for encoders like libvpx-vp9, they don't implement the global header 
support, neither does
the libavformat(container) like ivf or webm.

(Please correct me if I missed anything or understood something wrongly, thx)

- Linjie

[1] https://link.springer.com/content/pdf/10.1007%2F978-3-319-06895-4.pdf
[2] https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx264.c#L924
[3] https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx265.c#L384
[4] 
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libopenh264enc.c#L338

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3 0/7] adpcm_ima_apm encoder + apm muxer

[Zane van Iperen]

On Fri, 12 Jun 2020 11:46:08 +
"Zane van Iperen"  wrote:

> 
> Add support for encoding adpcm_ima_apm and muxing to apm.
> 
> If possible, I would like to get this functionality into the 4.3
> release.
> 
Ping 2.

Also, I noticed that patches 3 and 4 should probably be swapped.

Zane

___
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 4/5] fftools/ffmpeg: flush and recreate encoder instance if resolution changes

[Nicolas George]

Fu, Linjie (12020-06-16):
> Chapter 2.3 Parameter Sets in < High Efficiency Video Coding (HEVC)
> Algorithms and Architectures> [1]:

That is ONE codec. Not all of them.

> Indeed, the definition in spec is just the conformance, and how an encoder is
> implemented in Libavcodec (and external library if any) is the thing really 
> matters.
> 
> For encoders like libx264[2], libx265[3], libopenh264[4], if 
> AV_CODEC_FLAG_GLOBAL_HEADER
> flag is declared, the parameter Sets would be copied to extra data as the 
> global header.
> If not, parameter sets would be kept in the original bitstream, since it's 
> fundamentally
> supported in the encoder.

IIRC, encapsulation standards mandate one or the other for their
respective formats. We cannot choose.

Fact is, you cannot concatenate two packet streams and expect it to
work.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avformat/dashenc: Calculate average bitrate for adaptation sets in static manifest

[Przemysław Sobala]

>
> +av_log(s, AV_LOG_INFO, "segment_bitrate: %"PRId64",
> os->first_segment_bit_rate: %i, os->average_bit_rate: %f\n",
> +segment_bitrate, os->first_segment_bit_rate,
> os->average_bit_rate);
>

Just found this redundant av_log. Will fix if the overall solution is
accepted.

--
regards
Przemysław Sobala
___
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] area changed: hevc_amf set default gops_per_idr 1

[Lu Jiao]

Previously gops_per_idr default 60 would make amd gpu encoding hevc
has erratic seek bar behaviour as descripted in this ticket:
https://trac.ffmpeg.org/ticket/7272
---
 libavcodec/amfenc_hevc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/amfenc_hevc.c b/libavcodec/amfenc_hevc.c
index 77e57d2461..b0cb57cb96 100644
--- a/libavcodec/amfenc_hevc.c
+++ b/libavcodec/amfenc_hevc.c
@@ -69,7 +69,7 @@ static const AVOption options[] = {
 { "gop","", 0, AV_OPT_TYPE_CONST, { .i64 = 
AMF_VIDEO_ENCODER_HEVC_HEADER_INSERTION_MODE_GOP_ALIGNED }, 0, 0, VE, "hdrmode" 
},
 { "idr","", 0, AV_OPT_TYPE_CONST, { .i64 = 
AMF_VIDEO_ENCODER_HEVC_HEADER_INSERTION_MODE_IDR_ALIGNED }, 0, 0, VE, "hdrmode" 
},
 
-{ "gops_per_idr","GOPs per IDR 0-no IDR will be inserted",  
OFFSET(gops_per_idr),  AV_OPT_TYPE_INT,  { .i64 = 60 },  0, INT_MAX, VE },
+{ "gops_per_idr","GOPs per IDR 0-no IDR will be inserted",  
OFFSET(gops_per_idr),  AV_OPT_TYPE_INT,  { .i64 = 1 },  0, INT_MAX, VE },
 { "preanalysis","Enable preanalysis",   
OFFSET(preanalysis),   AV_OPT_TYPE_BOOL, { .i64 = 0  },  0, 1, VE},
 { "vbaq",   "Enable VBAQ",  
OFFSET(enable_vbaq),   AV_OPT_TYPE_BOOL, { .i64 = 0  },  0, 1, VE},
 { "enforce_hrd","Enforce HRD",  
OFFSET(enforce_hrd),   AV_OPT_TYPE_BOOL, { .i64 = 0  },  0, 1, VE},
-- 
2.27.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 4/5] fftools/ffmpeg: flush and recreate encoder instance if resolution changes

[Fu, Linjie]

> From: ffmpeg-devel  On Behalf Of
> Nicolas George
> Sent: Tuesday, June 16, 2020 21:40
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2 4/5] fftools/ffmpeg: flush and
> recreate encoder instance if resolution changes
> 
> Fu, Linjie (12020-06-16):
> > Chapter 2.3 Parameter Sets in < High Efficiency Video Coding (HEVC)
> > Algorithms and Architectures> [1]:
> 
> That is ONE codec. Not all of them.
> 
> > Indeed, the definition in spec is just the conformance, and how an encoder
> is
> > implemented in Libavcodec (and external library if any) is the thing really
> matters.
> >
> > For encoders like libx264[2], libx265[3], libopenh264[4], if
> AV_CODEC_FLAG_GLOBAL_HEADER
> > flag is declared, the parameter Sets would be copied to extra data as the
> global header.
> > If not, parameter sets would be kept in the original bitstream, since it's
> fundamentally
> > supported in the encoder.
> 
> IIRC, encapsulation standards mandate one or the other for their
> respective formats. We cannot choose.
> 
> Fact is, you cannot concatenate two packet streams and expect it to
> work.
> 
Okay, there are also some discussions on IRC yesterday about this, and one
Idea from Anton is to provide some bigger-picture solutions for concatenating
streams, maybe a bitstream filter to accommodate streamcopy.

Hence, I'd like to keep it open for now until we reach the concensus.

And I'd like to apply the patch set [1] soon for auto scale if no objections, 
as the first step
and touches raw video only for restricted usage for now (which is documented 
clearly).
This is already being waited for some time.

- Linjie

[1] https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=1434

___
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] area changed: hevc_amf set default gops_per_idr 1

[Lu Jiao]

Previously gops_per_idr default 60 would make amd gpu encoding hevc
has erratic seek bar behaviour as descripted in this ticket:
https://trac.ffmpeg.org/ticket/7272
---
 libavcodec/amfenc_hevc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/amfenc_hevc.c b/libavcodec/amfenc_hevc.c
index 77e57d2461..b0cb57cb96 100644
--- a/libavcodec/amfenc_hevc.c
+++ b/libavcodec/amfenc_hevc.c
@@ -69,7 +69,7 @@ static const AVOption options[] = {
 { "gop","", 0, AV_OPT_TYPE_CONST, { .i64 = 
AMF_VIDEO_ENCODER_HEVC_HEADER_INSERTION_MODE_GOP_ALIGNED }, 0, 0, VE, "hdrmode" 
},
 { "idr","", 0, AV_OPT_TYPE_CONST, { .i64 = 
AMF_VIDEO_ENCODER_HEVC_HEADER_INSERTION_MODE_IDR_ALIGNED }, 0, 0, VE, "hdrmode" 
},
 
-{ "gops_per_idr","GOPs per IDR 0-no IDR will be inserted",  
OFFSET(gops_per_idr),  AV_OPT_TYPE_INT,  { .i64 = 60 },  0, INT_MAX, VE },
+{ "gops_per_idr","GOPs per IDR 0-no IDR will be inserted",  
OFFSET(gops_per_idr),  AV_OPT_TYPE_INT,  { .i64 = 1 },  0, INT_MAX, VE },
 { "preanalysis","Enable preanalysis",   
OFFSET(preanalysis),   AV_OPT_TYPE_BOOL, { .i64 = 0  },  0, 1, VE},
 { "vbaq",   "Enable VBAQ",  
OFFSET(enable_vbaq),   AV_OPT_TYPE_BOOL, { .i64 = 0  },  0, 1, VE},
 { "enforce_hrd","Enforce HRD",  
OFFSET(enforce_hrd),   AV_OPT_TYPE_BOOL, { .i64 = 0  },  0, 1, VE},
-- 
2.27.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] area changed: hevc_amf set default gops_per_idr 1

[Carl Eugen Hoyos]

Am Di., 16. Juni 2020 um 16:10 Uhr schrieb Lu Jiao :
>
> Previously gops_per_idr default 60 would make amd gpu encoding hevc
> has erratic seek bar behaviour as descripted in this ticket:
> https://trac.ffmpeg.org/ticket/7272

Is this patch working around a defect in FFmpeg (that the hevc
decoder seeks to non-keyframes) or is it generally desirable?

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 2/2] avformat/dashenc: Calculate average bitrate for adaptation sets in static manifest

[Jeyapal, Karthick]

On 6/16/20 6:02 PM, Przemysław Sobala wrote:
> If stream's bitrate is not specified:
> - for static manifest: an average bitrate will be calculated and used,
> - for dynamic manifest: first segment's bitrate will be calculated and used, 
> as before,
> for bandwidth setting in adaptation sets.
>
> For dynamic manifest
> ---
>  libavformat/dashenc.c | 28 +---
>  1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 05deb5c1b5..6e1a6dbf3a 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -115,6 +115,8 @@ typedef struct OutputStream {
>  int64_t last_dts, last_pts;
>  int last_flags;
>  int bit_rate;
> +int first_segment_bit_rate;
> +double average_bit_rate;
>  SegmentType segment_type;  /* segment type selected for this particular 
> stream */
>  const char *format_name;
>  const char *extension_name;
> @@ -840,8 +842,11 @@ static int write_adaptation_set(AVFormatContext *s, 
> AVIOContext *out, int as_ind
>  continue;
>  
>  if (os->bit_rate > 0)
> -snprintf(bandwidth_str, sizeof(bandwidth_str), " 
> bandwidth=\"%d\"",
> - os->bit_rate);
> +snprintf(bandwidth_str, sizeof(bandwidth_str), " 
> bandwidth=\"%d\"", os->bit_rate);
> +else if (final && os->average_bit_rate > 0)
> +snprintf(bandwidth_str, sizeof(bandwidth_str), " 
> bandwidth=\"%d\"", (int) os->average_bit_rate);
> +else if (os->first_segment_bit_rate > 0)
> +snprintf(bandwidth_str, sizeof(bandwidth_str), " 
> bandwidth=\"%d\"", os->first_segment_bit_rate);
>  
>  if (as->media_type == AVMEDIA_TYPE_VIDEO) {
>  avio_printf(out, "\t\t\t mimeType=\"video/%s\" codecs=\"%s\"%s width=\"%d\" height=\"%d\"",
> @@ -1305,7 +1310,13 @@ static int write_manifest(AVFormatContext *s, int 
> final)
>  OutputStream *os = &c->streams[i];
>  char *agroup = NULL;
>  char *codec_str_ptr = NULL;
> -int stream_bitrate = st->codecpar->bit_rate + os->muxer_overhead;
> +int stream_bitrate = os->muxer_overhead;
> +if (os->bit_rate > 0)
> +stream_bitrate += os->bit_rate;
> +else if (final && os->average_bit_rate > 0)
> +stream_bitrate += os->average_bit_rate;
> +else if (os->first_segment_bit_rate > 0)
> +stream_bitrate += os->first_segment_bit_rate;
>  if (st->codecpar->codec_type != AVMEDIA_TYPE_VIDEO)
>  continue;
>  if (os->segment_type != SEGMENT_TYPE_MP4)
> @@ -1959,10 +1970,13 @@ static int dash_flush(AVFormatContext *s, int final, 
> int stream)
>  os->total_pkt_duration = 0;
>  
>  if (!os->bit_rate) {
> -// calculate average bitrate of first segment
> -int64_t bitrate = (int64_t) range_length * 8 * AV_TIME_BASE / 
> duration;
> -if (bitrate >= 0)
> -os->bit_rate = bitrate;
> +// calculate average bitrate
> +int64_t segment_bitrate = (int64_t) range_length * 8 * 
> AV_TIME_BASE / duration;
> +if (!os->first_segment_bit_rate)
> +os->first_segment_bit_rate = segment_bitrate;
> +os->average_bit_rate = (os->average_bit_rate * 
> (os->segment_index - 1) + segment_bitrate) / os->segment_index;
This method of calculating average bitrate may not be accurate in all cases.
Could you just add all "range_length" values and divide it total duration 
finally to get the average bitrate value.
Otherwise, the overall idea LGTM.
> +av_log(s, AV_LOG_INFO, "segment_bitrate: %"PRId64", 
> os->first_segment_bit_rate: %i, os->average_bit_rate: %f\n",
> +segment_bitrate, os->first_segment_bit_rate, 
> os->average_bit_rate);
>  }
>  add_segment(os, os->filename, os->start_pts, os->max_pts - 
> os->start_pts, os->pos, range_length, index_length, next_exp_index);
>  av_log(s, AV_LOG_VERBOSE, "Representation %d media segment %d 
> written to: %s\n", i, os->segment_index, os->full_path);

___
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] avformat/mxfdec: Error out on duplicated utf16 strings

[Michael Niedermayer]

On Tue, Jun 16, 2020 at 02:05:04PM +0200, Tomas Härdin wrote:
> mån 2020-06-15 klockan 21:45 +0200 skrev Marton Balint:
> > 
> > On Mon, 15 Jun 2020, Tomas Härdin wrote:
> > 
> > > sön 2020-06-14 klockan 20:19 +0200 skrev Marton Balint:
> > > > On Sun, 14 Jun 2020, Michael Niedermayer wrote:
> > > > 
> > > > > Alternatively we could free the already allocated element
> > > > 
> > > > Yeah, I kind of prefer that, we potentially allow non-string values to 
> > > > occur multiple times, so I'd say let's allow string values as well, 
> > > > even 
> > > > if that is not common. (I am not sure if it is strictly invalid or just 
> > > > uncommon).
> > > 
> > > Are there files in the wild that do this? Being stricter is often the
> > > better option when it comes to MXF. A muxer that outputs metadata more
> > > than once might be doing something wrong.
> > 
> > I am not sure, but I wanted to be safe rather than sorry, because it is 
> > not unusual in MXF to repeat certain metadata in the footer partition 
> > which is already present in the header, and I did not want to take the 
> > risk of rejecting a valid file.
> 
> True, that is not unheard of. Maybe we could warn if the strings don't
> match?

such a warning seem like a good idea to me

thx

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/5] avcodec/aacdectab: add mapping for 22.2

[Jan Ekström]

Utilizes the newly added 22.2 channel layout for channel_layout 13.
---
 libavcodec/aacdectab.h | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/libavcodec/aacdectab.h b/libavcodec/aacdectab.h
index baf51a74bf..c54a3eb943 100644
--- a/libavcodec/aacdectab.h
+++ b/libavcodec/aacdectab.h
@@ -35,9 +35,9 @@
 
 #include 
 
-static const int8_t tags_per_config[16] = { 0, 1, 1, 2, 3, 3, 4, 5, 0, 0, 0, 
4, 5, 0, 5, 0 };
+static const int8_t tags_per_config[16] = { 0, 1, 1, 2, 3, 3, 4, 5, 0, 0, 0, 
4, 5, 16, 5, 0 };
 
-static const uint8_t aac_channel_layout_map[16][5][3] = {
+static const uint8_t aac_channel_layout_map[16][16][3] = {
 { { TYPE_SCE, 0, AAC_CHANNEL_FRONT }, },
 { { TYPE_CPE, 0, AAC_CHANNEL_FRONT }, },
 { { TYPE_SCE, 0, AAC_CHANNEL_FRONT }, { TYPE_CPE, 0, AAC_CHANNEL_FRONT }, 
},
@@ -50,6 +50,24 @@ static const uint8_t aac_channel_layout_map[16][5][3] = {
 { { 0, } },
 { { TYPE_SCE, 0, AAC_CHANNEL_FRONT }, { TYPE_CPE, 0, AAC_CHANNEL_FRONT }, 
{ TYPE_CPE, 1, AAC_CHANNEL_BACK }, { TYPE_SCE, 1, AAC_CHANNEL_BACK }, { 
TYPE_LFE, 0, AAC_CHANNEL_LFE  }, },
 { { TYPE_SCE, 0, AAC_CHANNEL_FRONT }, { TYPE_CPE, 0, AAC_CHANNEL_FRONT }, 
{ TYPE_CPE, 1, AAC_CHANNEL_SIDE }, { TYPE_CPE, 2, AAC_CHANNEL_BACK }, { 
TYPE_LFE, 0, AAC_CHANNEL_LFE  }, },
+{
+  { TYPE_SCE, 0, AAC_CHANNEL_FRONT }, // SCE1 = FC,
+  { TYPE_CPE, 0, AAC_CHANNEL_FRONT }, // CPE1 = FLc and FRc,
+  { TYPE_CPE, 1, AAC_CHANNEL_FRONT }, // CPE2 = FL and FR,
+  { TYPE_CPE, 2, AAC_CHANNEL_SIDE  }, // CPE3 = SiL and SiR,
+  { TYPE_CPE, 3, AAC_CHANNEL_BACK  }, // CPE4 = BL and BR,
+  { TYPE_SCE, 1, AAC_CHANNEL_BACK  }, // SCE2 = BC,
+  { TYPE_LFE, 0, AAC_CHANNEL_LFE   }, // LFE1 = LFE1,
+  { TYPE_LFE, 1, AAC_CHANNEL_LFE   }, // LFE2 = LFE2,
+  { TYPE_SCE, 2, AAC_CHANNEL_FRONT }, // SCE3 = TpFC,
+  { TYPE_CPE, 4, AAC_CHANNEL_FRONT }, // CPE5 = TpFL and TpFR,
+  { TYPE_CPE, 5, AAC_CHANNEL_SIDE  }, // CPE6 = TpSiL and TpSiR,
+  { TYPE_SCE, 3, AAC_CHANNEL_FRONT }, // SCE4 = TpC,
+  { TYPE_CPE, 6, AAC_CHANNEL_BACK  }, // CPE7 = TpBL and TpBR,
+  { TYPE_SCE, 4, AAC_CHANNEL_BACK  }, // SCE5 = TpBC,
+  { TYPE_SCE, 5, AAC_CHANNEL_FRONT }, // SCE6 = BtFC,
+  { TYPE_CPE, 7, AAC_CHANNEL_FRONT }, // CPE8 = BtFL and BtFR
+},
 { { 0, } },
 /* TODO: Add 7+1 TOP configuration */
 };
@@ -67,6 +85,7 @@ static const uint64_t aac_channel_layout[16] = {
 0,
 AV_CH_LAYOUT_6POINT1,
 AV_CH_LAYOUT_7POINT1,
+AV_CH_LAYOUT_22POINT2,
 0,
 /* AV_CH_LAYOUT_7POINT1_TOP, */
 };
-- 
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] [PATCH 0/5] 22.2 channel layout support for AAC decoding

[Jan Ekström]

Now that we actually have sample(s) for channel_config 13, it was possible
to see at which various points the AAC decoder fails attempting to parse
the bit stream.

I have not yet found or generated a channel layout test sample so I could
fully validate the channel map output by the AAC decoder, but at least
7/24 seem to be correct looking at the decoded WAV output in Audacity 
(front left/right, center, top and bottom front left/right seem to be
correct based on the sample linked in #8714).

Fixes #8714

Jan Ekström (5):
  avutil/channel_layout: add 22.2 layout
  avcodec/mpeg4audio: add newer channel_coding mappings
  avcodec/aacdectab: add mapping for 22.2
  avcodec/aacdec_template: mark second LFE element as LFE2
  avcodec/aacdec_template: add support for 22.2 / channel_config 13

 doc/APIchanges   |  5 
 libavcodec/aacdec_template.c | 55 ++--
 libavcodec/aacdectab.h   | 23 +--
 libavcodec/mpeg4audio.c  | 17 +--
 libavcodec/mpeg4audio.h  |  2 +-
 libavutil/channel_layout.c   |  6 
 libavutil/channel_layout.h   |  6 
 libavutil/version.h  |  2 +-
 8 files changed, 108 insertions(+), 8 deletions(-)

-- 
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] [PATCH 5/5] avcodec/aacdec_template: add support for 22.2 / channel_config 13

[Jan Ekström]

---
 libavcodec/aacdec_template.c | 53 +++-
 1 file changed, 52 insertions(+), 1 deletion(-)

diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 0590e77d75..0be0ad6566 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -378,6 +378,50 @@ static uint64_t sniff_channel_order(uint8_t 
(*layout_map)[3], int tags)
 i++;
 }
 
+// The previous checks would end up at 8 at this point for 22.2
+if (tags == 16 && i == 8) {
+e2c_vec[i] = (struct elem_to_channel) {
+.av_position  = AV_CH_TOP_FRONT_CENTER,
+.syn_ele  = layout_map[i][0],
+.elem_id  = layout_map[i][1],
+.aac_position = layout_map[i][2]
+}; i++;
+i += assign_pair(e2c_vec, layout_map, i,
+ AV_CH_TOP_FRONT_LEFT,
+ AV_CH_TOP_FRONT_RIGHT,
+ AAC_CHANNEL_FRONT);
+i += assign_pair(e2c_vec, layout_map, i,
+ AV_CH_TOP_SIDE_LEFT,
+ AV_CH_TOP_SIDE_RIGHT,
+ AAC_CHANNEL_SIDE);
+e2c_vec[i] = (struct elem_to_channel) {
+.av_position  = AV_CH_TOP_CENTER,
+.syn_ele  = layout_map[i][0],
+.elem_id  = layout_map[i][1],
+.aac_position = layout_map[i][2]
+}; i++;
+i += assign_pair(e2c_vec, layout_map, i,
+ AV_CH_TOP_BACK_LEFT,
+ AV_CH_TOP_BACK_RIGHT,
+ AAC_CHANNEL_BACK);
+e2c_vec[i] = (struct elem_to_channel) {
+.av_position  = AV_CH_TOP_BACK_CENTER,
+.syn_ele  = layout_map[i][0],
+.elem_id  = layout_map[i][1],
+.aac_position = layout_map[i][2]
+}; i++;
+e2c_vec[i] = (struct elem_to_channel) {
+.av_position  = AV_CH_BOTTOM_FRONT_CENTER,
+.syn_ele  = layout_map[i][0],
+.elem_id  = layout_map[i][1],
+.aac_position = layout_map[i][2]
+}; i++;
+i += assign_pair(e2c_vec, layout_map, i,
+ AV_CH_BOTTOM_FRONT_LEFT,
+ AV_CH_BOTTOM_FRONT_RIGHT,
+ AAC_CHANNEL_FRONT);
+}
+
 // Must choose a stable sort
 total_non_cc_elements = n = i;
 do {
@@ -526,7 +570,7 @@ static int set_default_channel_config(AACContext *ac, 
AVCodecContext *avctx,
   int channel_config)
 {
 if (channel_config < 1 || (channel_config > 7 && channel_config < 11) ||
-channel_config > 12) {
+channel_config > 13) {
 av_log(avctx, AV_LOG_ERROR,
"invalid default channel configuration (%d)\n",
channel_config);
@@ -606,6 +650,13 @@ static ChannelElement *get_che(AACContext *ac, int type, 
int elem_id)
 /* For indexed channel configurations map the channels solely based
  * on position. */
 switch (ac->oc[1].m4ac.chan_config) {
+case 13:
+if (ac->tags_mapped > 3 && ((type == TYPE_CPE && elem_id < 8) ||
+(type == TYPE_SCE && elem_id < 6) ||
+(type == TYPE_LFE && elem_id < 2))) {
+ac->tags_mapped++;
+return ac->tag_che_map[type][elem_id] = ac->che[type][elem_id];
+}
 case 12:
 case 7:
 if (ac->tags_mapped == 3 && type == TYPE_CPE) {
-- 
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] [PATCH 1/5] avutil/channel_layout: add 22.2 layout

[Jan Ekström]

Requires some extraneous top side and bottom front channels to be
defined.

According to STD-B59v2, the defined channel layout is:
- FL
- FR
- FC
- LFE1
- BL
- BR
- FLc
- FRc
- BC
- LFE2
- SiL
- SiR
- TpFL
- TpFR
- TpFC
- TpC
- TpBL
- TpBR
- TpSiL
- TpSiR
- TpBC
- BtFC
- BtFL
- BtFR
---
 doc/APIchanges | 5 +
 libavutil/channel_layout.c | 6 ++
 libavutil/channel_layout.h | 6 ++
 libavutil/version.h| 2 +-
 4 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 1d6cc36b8c..84fe736454 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,11 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2020-06-16 - xx - lavu 56.56.100 - channel_layout.h
+  Add AV_CH_LAYOUT_22POINT2 together with its newly required pieces:
+  AV_CH_TOP_SIDE_LEFT, AV_CH_TOP_SIDE_RIGHT, AV_CH_BOTTOM_FRONT_LEFT,
+  AV_CH_BOTTOM_FRONT_CENTER, AV_CH_BOTTOM_FRONT_RIGHT.
+
 2020-06-12 - b09fb030c1 - lavu 56.55.100 - pixdesc.h
   Add AV_PIX_FMT_X2RGB10.
 
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 3bd5ee29b7..d6bfc74927 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -62,6 +62,11 @@ static const struct channel_name channel_names[] = {
 [33] = { "SDL",   "surround direct left"  },
 [34] = { "SDR",   "surround direct right" },
 [35] = { "LFE2",  "low frequency 2"   },
+[36] = { "TSL",   "top side left" },
+[37] = { "TSR",   "top side right"},
+[38] = { "BFL",   "bottom front left" },
+[39] = { "BFC",   "bottom front center"   },
+[40] = { "BFR",   "bottom front right"},
 };
 
 static const char *get_channel_name(int channel_id)
@@ -104,6 +109,7 @@ static const struct {
 { "octagonal",   8,  AV_CH_LAYOUT_OCTAGONAL },
 { "hexadecagonal", 16, AV_CH_LAYOUT_HEXADECAGONAL },
 { "downmix", 2,  AV_CH_LAYOUT_STEREO_DOWNMIX, },
+{ "22.2",  24, AV_CH_LAYOUT_22POINT2, },
 };
 
 static uint64_t get_channel_layout_single(const char *name, int name_len)
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index 50bb8f03c5..43297505cb 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -71,6 +71,11 @@
 #define AV_CH_SURROUND_DIRECT_LEFT   0x0002ULL
 #define AV_CH_SURROUND_DIRECT_RIGHT  0x0004ULL
 #define AV_CH_LOW_FREQUENCY_20x0008ULL
+#define AV_CH_TOP_SIDE_LEFT  0x0010ULL
+#define AV_CH_TOP_SIDE_RIGHT 0x0020ULL
+#define AV_CH_BOTTOM_FRONT_LEFT  0x0040ULL
+#define AV_CH_BOTTOM_FRONT_CENTER0x0080ULL
+#define AV_CH_BOTTOM_FRONT_RIGHT 0x0100ULL
 
 /** Channel mask value used for AVCodecContext.request_channel_layout
 to indicate that the user requests the channel order of the decoder output
@@ -110,6 +115,7 @@
 #define AV_CH_LAYOUT_OCTAGONAL 
(AV_CH_LAYOUT_5POINT0|AV_CH_BACK_LEFT|AV_CH_BACK_CENTER|AV_CH_BACK_RIGHT)
 #define AV_CH_LAYOUT_HEXADECAGONAL 
(AV_CH_LAYOUT_OCTAGONAL|AV_CH_WIDE_LEFT|AV_CH_WIDE_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT|AV_CH_TOP_BACK_CENTER|AV_CH_TOP_FRONT_CENTER|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
 #define AV_CH_LAYOUT_STEREO_DOWNMIX(AV_CH_STEREO_LEFT|AV_CH_STEREO_RIGHT)
+#define AV_CH_LAYOUT_22POINT2  
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER|AV_CH_BACK_CENTER|AV_CH_LOW_FREQUENCY_2|AV_CH_SIDE_LEFT|AV_CH_SIDE_RIGHT|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT|AV_CH_TOP_FRONT_CENTER|AV_CH_TOP_CENTER|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT|AV_CH_TOP_SIDE_LEFT|AV_CH_TOP_SIDE_RIGHT|AV_CH_TOP_BACK_CENTER|AV_CH_BOTTOM_FRONT_CENTER|AV_CH_BOTTOM_FRONT_LEFT|AV_CH_BOTTOM_FRONT_RIGHT)
 
 enum AVMatrixEncoding {
 AV_MATRIX_ENCODING_NONE,
diff --git a/libavutil/version.h b/libavutil/version.h
index 3ce9b1831e..a63f79feb1 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  56
-#define LIBAVUTIL_VERSION_MINOR  55
+#define LIBAVUTIL_VERSION_MINOR  56
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
-- 
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] [PATCH 2/5] avcodec/mpeg4audio: add newer channel_coding mappings

[Jan Ekström]

Additionally, add comments regarding their definitions. Based on
ARIB STD-B32, which bases on 14496-3:2009 and 14496-3:2009/AMD4.
---
 libavcodec/mpeg4audio.c | 17 +++--
 libavcodec/mpeg4audio.h |  2 +-
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/libavcodec/mpeg4audio.c b/libavcodec/mpeg4audio.c
index 0d83fb8d25..77cf2fb61c 100644
--- a/libavcodec/mpeg4audio.c
+++ b/libavcodec/mpeg4audio.c
@@ -64,8 +64,21 @@ const int avpriv_mpeg4audio_sample_rates[16] = {
 24000, 22050, 16000, 12000, 11025, 8000, 7350
 };
 
-const uint8_t ff_mpeg4audio_channels[8] = {
-0, 1, 2, 3, 4, 5, 6, 8
+const uint8_t ff_mpeg4audio_channels[14] = {
+0,
+1, // mono (1/0)
+2, // stereo (2/0)
+3, // 3/0
+4, // 3/1
+5, // 3/2
+6, // 3/2.1
+8, // 5/2.1
+0,
+0,
+0,
+7, // 3/3.1
+8, // 3/2/2.1
+24 // 3/3/3 - 5/2/3 - 3/0/0.2
 };
 
 static inline int get_object_type(GetBitContext *gb)
diff --git a/libavcodec/mpeg4audio.h b/libavcodec/mpeg4audio.h
index 4b390e0f42..c4cdc1508c 100644
--- a/libavcodec/mpeg4audio.h
+++ b/libavcodec/mpeg4audio.h
@@ -46,7 +46,7 @@ typedef struct MPEG4AudioConfig {
 } MPEG4AudioConfig;
 
 extern av_export_avcodec const int avpriv_mpeg4audio_sample_rates[16];
-extern const uint8_t ff_mpeg4audio_channels[8];
+extern const uint8_t ff_mpeg4audio_channels[14];
 
 /**
  * Parse MPEG-4 systems extradata from a potentially unaligned GetBitContext 
to retrieve audio configuration.
-- 
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] [PATCH 4/5] avcodec/aacdec_template: mark second LFE element as LFE2

[Jan Ekström]

We now have the capability to do this.
---
 libavcodec/aacdec_template.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index a473e1bad7..0590e77d75 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -370,7 +370,7 @@ static uint64_t sniff_channel_order(uint8_t 
(*layout_map)[3], int tags)
 }
 while (i < tags && layout_map[i][2] == AAC_CHANNEL_LFE) {
 e2c_vec[i] = (struct elem_to_channel) {
-.av_position  = UINT64_MAX,
+.av_position  = AV_CH_LOW_FREQUENCY_2,
 .syn_ele  = TYPE_LFE,
 .elem_id  = layout_map[i][1],
 .aac_position = AAC_CHANNEL_LFE
-- 
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] area changed: hevc_amf set default gops_per_idr 1

[2rd bunji]

I think it is desirable as AMD HEVC encoder frequency of IDR frames is needed 
to be 1 to indicate key frames used in seek , and it is not defect in ffmpeg 
decoder.

Jiao lu


From: Carl Eugen Hoyos
Sent: 2020年6月17日 0:21
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] area changed: hevc_amf set default 
gops_per_idr 1

Am Di., 16. Juni 2020 um 16:10 Uhr schrieb Lu Jiao :
>
> Previously gops_per_idr default 60 would make amd gpu encoding hevc
> has erratic seek bar behaviour as descripted in this ticket:
> https://trac.ffmpeg.org/ticket/7272

Is this patch working around a defect in FFmpeg (that the hevc
decoder seeks to non-keyframes) or is it generally desirable?

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

___
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] dnn_backend_native: check operand index

[Guo, Yejun]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Carl
> Eugen Hoyos
> Sent: 2020年6月16日 18:57
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] dnn_backend_native: check operand
> index
> 
> 
> 
> > Am 16.06.2020 um 10:18 schrieb Guo, Yejun :
> >
> > I personally like to always add '{}' to avoid possible mistakes when we 
> > change
> code in the future. Some coding styles also recommend this method.
> >
> > I checked at http://ffmpeg.org/developer.html#Coding-Rules and do not find
> an explicit description. But I just remembered that someone also mentioned 
> this
> some time ago. I'll change to this style in v2 if no support from others for 
> my
> style.
> 
> I support your style but it is only the file maintainer‘s decision.

thanks, I'll keep the V1 patch and push soon.

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