[FFmpeg-devel] [PATCH] avformat: add a concat protocol that takes a line break delimited list of resources
Suggested-by: ffm...@fb.com
Signed-off-by: James Almer
---
doc/protocols.texi | 30 +++
libavformat/Makefile| 1 +
libavformat/concat.c| 111
libavformat/protocols.c | 1 +
4 files changed, 143 insertions(+)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index ccdfb6e439..2b8ce1b7d5 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -215,6 +215,36 @@ ffplay concat:split1.mpeg\|split2.mpeg\|split3.mpeg
Note that you may need to escape the character "|" which is special for
many shells.
+@section concatf
+
+Physical concatenation protocol using a line break delimited list of
+resources.
+
+Read and seek from many resources in sequence as if they were
+a unique resource.
+
+A URL accepted by this protocol has the syntax:
+@example
+concatf:@var{URL}
+@end example
+
+where @var{URL} is the url containing a line break delimited list of
+resources to be concatenated, each one possibly specifying a distinct
+protocol.
+
+For example to read a sequence of files @file{split1.mpeg},
+@file{split2.mpeg}, @file{split3.mpeg} listed in separate lines within
+a file @file{split.txt} with @command{ffplay} use the command:
+@example
+ffplay concatf:split.txt
+@end example
+Where @file{split.txt} contains the lines:
+@example
+split1.mpeg
+split2.mpeg
+split3.mpeg
+@end example
+
@section crypto
AES-encrypted stream reading protocol.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index c9ef564523..caca95802a 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -616,6 +616,7 @@ OBJS-$(CONFIG_APPLEHTTP_PROTOCOL)+= hlsproto.o
OBJS-$(CONFIG_BLURAY_PROTOCOL) += bluray.o
OBJS-$(CONFIG_CACHE_PROTOCOL)+= cache.o
OBJS-$(CONFIG_CONCAT_PROTOCOL) += concat.o
+OBJS-$(CONFIG_CONCATF_PROTOCOL) += concat.o
OBJS-$(CONFIG_CRYPTO_PROTOCOL) += crypto.o
OBJS-$(CONFIG_DATA_PROTOCOL) += data_uri.o
OBJS-$(CONFIG_FFRTMPCRYPT_PROTOCOL) += rtmpcrypt.o rtmpdigest.o rtmpdh.o
diff --git a/libavformat/concat.c b/libavformat/concat.c
index 278afd997d..d224b51db0 100644
--- a/libavformat/concat.c
+++ b/libavformat/concat.c
@@ -22,9 +22,12 @@
*/
#include "libavutil/avstring.h"
+#include "libavutil/bprint.h"
#include "libavutil/mem.h"
#include "avformat.h"
+#include "avio_internal.h"
+#include "internal.h"
#include "url.h"
#define AV_CAT_SEPARATOR "|"
@@ -56,6 +59,7 @@ static av_cold int concat_close(URLContext *h)
return err < 0 ? -1 : 0;
}
+#if CONFIG_CONCAT_PROTOCOL
static av_cold int concat_open(URLContext *h, const char *uri, int flags)
{
char *node_uri = NULL;
@@ -124,6 +128,7 @@ static av_cold int concat_open(URLContext *h, const char
*uri, int flags)
data->total_size = total_size;
return err;
}
+#endif
static int concat_read(URLContext *h, unsigned char *buf, int size)
{
@@ -188,6 +193,7 @@ static int64_t concat_seek(URLContext *h, int64_t pos, int
whence)
return result;
}
+#if CONFIG_CONCAT_PROTOCOL
const URLProtocol ff_concat_protocol = {
.name = "concat",
.url_open = concat_open,
@@ -197,3 +203,108 @@ const URLProtocol ff_concat_protocol = {
.priv_data_size = sizeof(struct concat_data),
.default_whitelist = "concat,file,subfile",
};
+#endif
+
+#if CONFIG_CONCATF_PROTOCOL
+static av_cold int concatf_open(URLContext *h, const char *uri, int flags)
+{
+AVBPrint bp;
+struct concat_data *data = h->priv_data;
+struct concat_nodes *nodes = NULL;
+AVIOContext *in = NULL;
+URLContext *uc;
+char *node_uri = NULL;
+int64_t size, total_size = 0;
+unsigned int nodes_size = 0;
+size_t i = 0;
+int err = 0;
+
+if (!av_strstart(uri, "concatf:", &uri)) {
+av_log(h, AV_LOG_ERROR, "URL %s lacks prefix\n", uri);
+return AVERROR(EINVAL);
+}
+
+/* handle input */
+if (!*uri)
+return AVERROR(ENOENT);
+
+err = ffio_open_whitelist(&in, uri, AVIO_FLAG_READ, &h->interrupt_callback,
+ NULL, h->protocol_whitelist,
h->protocol_blacklist);
+if (err < 0)
+return err;
+
+av_bprint_init(&bp, 0, AV_BPRINT_SIZE_UNLIMITED);
+
+for (i = 0; !avio_feof(in); i++) {
+uint8_t *cursor;
+size_t len = i;
+
+if ((err = ff_read_line_to_bprint_overwrite(in, &bp)) <= 0) {
+if (err == 0 && i == 0)
+err = AVERROR_INVALIDDATA;
+else if (err == AVERROR_EOF)
+err = 0;
+break;
+}
+
+cursor = bp.str;
+node_uri = av_get_token((const char **)&cursor, "\t\r\n");
+if (!node_uri) {
+err = AVERROR(ENOMEM);
+break;
+}
+
+if (++len == SIZE_MAX / sizeof(*nodes)) {
+av_freep(&node_uri);
+err = AVERROR(ENAMETOOLONG);
+break;
+}
+
+/* creating URLContext */
+err = ffurl_open_whiteli
Re: [FFmpeg-devel] [PATCH 1/2] qsvdec: add support for HW_DEVICE_CTX method
-Original Message- From: ffmpeg-devel On Behalf Of Haihao Xiang Sent: Mittwoch, 23. Juni 2021 05:04 To: ffmpeg-devel@ffmpeg.org Cc: Haihao Xiang Subject: [FFmpeg-devel] [PATCH 1/2] qsvdec: add support for HW_DEVICE_CTX method This allows user set hw_device_ctx instead of hw_frames_ctx for QSV decoders, hence we may remove the ad-hoc libmfx setup code from FFmpeg. "-hwaccel_output_format format" is applied to QSV decoders after removing the ad-hoc libmfx code. In order to keep compatibility with old commandlines, the default format is set to AV_PIX_FMT_QSV, but this behavior will be removed in the future. Please set "-hwaccel_output_format qsv" explicitly if AV_PIX_FMT_QSV is expected. The normal device stuff works for QSV decoders now, user may use "-init_hw_device args" to initialise device and "-hwaccel_device devicename" to select a device for QSV decoders. "-qsv_device device" which was added for workarounding device selection in the ad-hoc libmfx code is deprecated and will be removed from FFmpeg. For example: $> ffmpeg -init_hw_device vaapi=va:/dev/dri/card0 -init_hw_device qsv=hw@va -hwaccel qsv -c:v h264_qsv -i input.h264 -f null - /dev/dri/renderD128 is actually open for h264_qsv decoder in the above command without this patch. After applying this patch, /dev/dri/card0 is used. $> ffmpeg -init_hw_device vaapi=va:/dev/dri/card0 -init_hw_device qsv=hw@va -hwaccel_device hw -hwaccel qsv -c:v h264_qsv -i input.h264 -f null - device hw of type qsv is not usable in the above command without this patch. After applying this patch, this command works as expected. --- Haihao, I think, from all the not-yet-merged QSV patches, this is the most important one. I'll try to find some time to review shortly. Is this patch independent of your other submitted patches? softworkz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/h264_metadata_bsf: Allow zeroing constraint_set4_flag and constraint_set5_flag
These bits are reserved in earlie versions of the H.264 spec, and
some poor hardware decoders require they are zero. Thus, it is useful
to be able to zero these on streams that may have them set. The result
is still a valid H.264 bitstream.
Signed-off-by: Derek Buitenhuis
---
e.g. x264 wrote these bits for several months before reverting that
functionality, since it broke several hardware decoders.
---
doc/bitstream_filters.texi | 5 +
libavcodec/h264_metadata_bsf.c | 8
2 files changed, 13 insertions(+)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 60e729484d..81220638d4 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -253,6 +253,11 @@ Set whether the stream has fixed framerate - typically
this indicates
that the framerate is exactly half the tick rate, but the exact
meaning is dependent on interlacing and the picture structure (see
H.264 section E.2.1 and table E-6).
+@item zero_new_constraint_set_flags
+Zero constraint_set4_flag and constraint_set5_flag in the SPS. These
+bits were reserved in a previous version of the H.264 spec, and thus
+some hardware encoders require these to be zero. The result of zeroing
+this is still a valid bitstream.
@item crop_left
@item crop_right
diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index ef74cba560..452a8ec5dc 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -61,6 +61,7 @@ typedef struct H264MetadataContext {
AVRational tick_rate;
int fixed_frame_rate_flag;
+int zero_new_constraint_set_flags;
int crop_left;
int crop_right;
@@ -228,6 +229,10 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
need_vui = 1;
}
SET_VUI_FIELD(fixed_frame_rate_flag);
+if (ctx->zero_new_constraint_set_flags) {
+sps->constraint_set4_flag = 0;
+sps->constraint_set5_flag = 0;
+}
if (sps->separate_colour_plane_flag || sps->chroma_format_idc == 0) {
crop_unit_x = 1;
@@ -618,6 +623,9 @@ static const AVOption h264_metadata_options[] = {
{ "fixed_frame_rate_flag", "Set VUI fixed frame rate flag",
OFFSET(fixed_frame_rate_flag), AV_OPT_TYPE_INT,
{ .i64 = -1 }, -1, 1, FLAGS },
+{ "zero_new_constraint_set_flags", "Set constraint_set4_flag /
constraint_set5_flag to zero",
+OFFSET(zero_new_constraint_set_flags), AV_OPT_TYPE_BOOL,
+{ .i64 = 0 }, 0, 1, FLAGS },
{ "crop_left", "Set left border crop offset",
OFFSET(crop_left), AV_OPT_TYPE_INT,
--
2.32.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/select: add metadata detection function
On 18.06.2021 14:50, Timo Rothenpieler wrote:
> [...]
>
> +@item detected(kind)
> +Evaluates the metadata added to frames by various detection filters.
> +Returns -1 if the respective filter has detected what it was looking
for,
> +0 otherwise.
> +
> +Possible values for the @var{kind} parameter:
> +@table @option
> +@item SILENCE (audio only)
> +Looks for metadata added by @ref{silencedetect}.
> +@item FREEZE (video only)
> +Looks for metadata added by @ref{freezedetect}.
> +@item BLACK (video only)
> +Looks for metadata added by @ref{blackdetect}.
> +@end table
> +
> @end table
If I understand that description correctly a filter line like
"aselect=detected(SILENCE)" kill keep the silence and remove the rest?
So for most use cases a wrapping not() shall be used? Adding an example
in the docs might clarify this.
I think it is a bit unfortunate that the new syntax differs from the
existing "concatdec_select" which is similar in concept. In my very
personal opinion using variables like "silence_detected" would have been
more consistent, but take this as a suggestion - not objection.
Regards,
Tobias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/f_metadata: do not return the frame early if there is no metadata
On Wed, 23 Jun 2021, Gyan Doshi wrote: On 2021-06-23 06:11, Marton Balint wrote: The early return caused isses for the "add" mode (got fixed in c95dfe5cce98cde3e7fb14fbd04b3897f3927cec) and the "select" mode needs a similar fix. It is probably better to fully remove the check, since all modes work correctly with NULL metadata. Doesn't select mode imply the presence of a dictionary? Select mode selects frames with metadata, if there is no metadata the frame should NOT be selected, but currently it is. Regards, Marton Signed-off-by: Marton Balint --- libavfilter/f_metadata.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/libavfilter/f_metadata.c b/libavfilter/f_metadata.c index e7c7b00118..d0a78b00d0 100644 --- a/libavfilter/f_metadata.c +++ b/libavfilter/f_metadata.c @@ -308,9 +308,6 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *frame) AVDictionary **metadata = &frame->metadata; AVDictionaryEntry *e; -if (!*metadata && s->mode != METADATA_ADD) -return ff_filter_frame(outlink, frame); - e = av_dict_get(*metadata, !s->key ? "" : s->key, NULL, !s->key ? AV_DICT_IGNORE_SUFFIX: 0); ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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 v5 1/2] avcodec/libx264: Add support for Sony XAVC Class 300 and 480
On 6/22/2021 7:56 AM, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/libx264.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 36fdb56..d0608e7 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -749,6 +749,18 @@ static av_cold int X264_init(AVCodecContext *avctx)
av_log(avctx, AV_LOG_ERROR,
"x264 too old for AVC Intra, at least version 142 needed\n");
#endif
+
+if (x4->avcintra_class > 200) {
+#if X264_BUILD < 164
+av_log(avctx, AV_LOG_ERROR,
+"x264 too old for AVC Intra 300/480, at least version 164
needed\n");
+return AVERROR(EINVAL);
+#else
+/* AVC-Intra 300/480 only supported by Sony XAVC flavor */
+x4->params.i_avcintra_flavor = X264_AVCINTRA_FLAVOR_SONY;
+#endif
+}
+
if (x4->b_bias != INT_MIN)
x4->params.i_bframe_bias = x4->b_bias;
if (x4->b_pyramid >= 0)
@@ -1082,7 +1094,7 @@ static const AVOption options[] = {
{ "none", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = X264_NAL_HRD_NONE}, INT_MIN,
INT_MAX, VE, "nal-hrd" },
{ "vbr", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = X264_NAL_HRD_VBR}, INT_MIN,
INT_MAX, VE, "nal-hrd" },
{ "cbr", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = X264_NAL_HRD_CBR}, INT_MIN,
INT_MAX, VE, "nal-hrd" },
-{ "avcintra-class","AVC-Intra class 50/100/200",
OFFSET(avcintra_class),AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 200 , VE},
+{ "avcintra-class","AVC-Intra class 50/100/200/300/480",
OFFSET(avcintra_class),AV_OPT_TYPE_INT,{ .i64 = -1 }, -1, 480 , VE},
{ "me_method","Set motion estimation method",
OFFSET(motion_est),AV_OPT_TYPE_INT,{ .i64 = -1 }, -1, X264_ME_TESA, VE, "motion-est"},
{ "motion-est", "Set motion estimation method",
OFFSET(motion_est),AV_OPT_TYPE_INT,{ .i64 = -1 }, -1, X264_ME_TESA, VE, "motion-est"},
{ "dia", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = X264_ME_DIA }, INT_MIN,
INT_MAX, VE, "motion-est" },
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/h264_metadata_bsf: Allow zeroing constraint_set4_flag and constraint_set5_flag
On 6/23/2021 1:12 PM, Derek Buitenhuis wrote:
These bits are reserved in earlie versions of the H.264 spec, and
some poor hardware decoders require they are zero. Thus, it is useful
to be able to zero these on streams that may have them set. The result
is still a valid H.264 bitstream.
Signed-off-by: Derek Buitenhuis
---
e.g. x264 wrote these bits for several months before reverting that
functionality, since it broke several hardware decoders.
---
doc/bitstream_filters.texi | 5 +
libavcodec/h264_metadata_bsf.c | 8
2 files changed, 13 insertions(+)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 60e729484d..81220638d4 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -253,6 +253,11 @@ Set whether the stream has fixed framerate - typically
this indicates
that the framerate is exactly half the tick rate, but the exact
meaning is dependent on interlacing and the picture structure (see
H.264 section E.2.1 and table E-6).
+@item zero_new_constraint_set_flags
+Zero constraint_set4_flag and constraint_set5_flag in the SPS. These
+bits were reserved in a previous version of the H.264 spec, and thus
+some hardware encoders require these to be zero. The result of zeroing
Decoders.
+this is still a valid bitstream.
@item crop_left
@item crop_right
diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index ef74cba560..452a8ec5dc 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -61,6 +61,7 @@ typedef struct H264MetadataContext {
AVRational tick_rate;
int fixed_frame_rate_flag;
+int zero_new_constraint_set_flags;
int crop_left;
int crop_right;
@@ -228,6 +229,10 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
need_vui = 1;
}
SET_VUI_FIELD(fixed_frame_rate_flag);
+if (ctx->zero_new_constraint_set_flags) {
+sps->constraint_set4_flag = 0;
+sps->constraint_set5_flag = 0;
+}
if (sps->separate_colour_plane_flag || sps->chroma_format_idc == 0) {
crop_unit_x = 1;
@@ -618,6 +623,9 @@ static const AVOption h264_metadata_options[] = {
{ "fixed_frame_rate_flag", "Set VUI fixed frame rate flag",
OFFSET(fixed_frame_rate_flag), AV_OPT_TYPE_INT,
{ .i64 = -1 }, -1, 1, FLAGS },
+{ "zero_new_constraint_set_flags", "Set constraint_set4_flag /
constraint_set5_flag to zero",
+OFFSET(zero_new_constraint_set_flags), AV_OPT_TYPE_BOOL,
+{ .i64 = 0 }, 0, 1, FLAGS },
{ "crop_left", "Set left border crop offset",
OFFSET(crop_left), AV_OPT_TYPE_INT,
I guess it's fine, but Mark may have some comments about 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 1/2] qsvdec: add support for HW_DEVICE_CTX method
On Wed, 2021-06-23 at 16:41 +, Soft Works wrote: > > -Original Message- > From: ffmpeg-devel On Behalf Of Haihao Xiang > Sent: Mittwoch, 23. Juni 2021 05:04 > To: ffmpeg-devel@ffmpeg.org > Cc: Haihao Xiang > Subject: [FFmpeg-devel] [PATCH 1/2] qsvdec: add support for HW_DEVICE_CTX > method > > This allows user set hw_device_ctx instead of hw_frames_ctx for QSV decoders, > hence we may remove the ad-hoc libmfx setup code from FFmpeg. > > "-hwaccel_output_format format" is applied to QSV decoders after removing the > ad-hoc libmfx code. In order to keep compatibility with old commandlines, the > default format is set to AV_PIX_FMT_QSV, but this behavior will be removed in > the future. Please set "-hwaccel_output_format qsv" > explicitly if AV_PIX_FMT_QSV is expected. > > The normal device stuff works for QSV decoders now, user may use "- > init_hw_device args" to initialise device and "-hwaccel_device devicename" to > select a device for QSV decoders. "-qsv_device device" > which was added for workarounding device selection in the ad-hoc libmfx code > is deprecated and will be removed from FFmpeg. > > For example: > > $> ffmpeg -init_hw_device vaapi=va:/dev/dri/card0 -init_hw_device qsv=hw@va > -hwaccel qsv -c:v h264_qsv -i input.h264 -f null - > > /dev/dri/renderD128 is actually open for h264_qsv decoder in the above command > without this patch. After applying this patch, /dev/dri/card0 is used. > > $> ffmpeg -init_hw_device vaapi=va:/dev/dri/card0 -init_hw_device qsv=hw@va > -hwaccel_device hw -hwaccel qsv -c:v h264_qsv -i input.h264 -f null - > > device hw of type qsv is not usable in the above command without this patch. > After applying this patch, this command works as expected. > --- > > Haihao, > > I think, from all the not-yet-merged QSV patches, this is the most important > one. > I'll try to find some time to review shortly. Thanks for helping to review this patch, and any comment is welcome. > > Is this patch independent of your other submitted patches? Yes, this patch is independent of other patches and you may apply it to the latest master branch directly. BTW the fix in http://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/276695.html is no longer needed after applying this patch. The command works for me if using -init_hw_device qsv=qsv@intel to create the connection between vaapi and QSVdevices. Regards Haihao > > softworkz > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec: Pass the HDR10+ metadata to the packet side data in VP9 encoder
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing it
to the AVPacket side data.
---
doc/APIchanges | 2 +
libavcodec/avpacket.c | 1 +
libavcodec/decode.c| 1 +
libavcodec/libvpxenc.c | 91 ++
libavcodec/packet.h| 8
libavcodec/version.h | 4 +-
6 files changed, 105 insertions(+), 2 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 06493763b3..162b4db050 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -13,6 +13,8 @@ libavutil: 2021-04-27
API changes, most recent first:
+2021-05-25 - xx - lavc 59.2.100 - packet.h
+ Add AV_PKT_DATA_DYNAMIC_HDR10_PLUS
2021-06-09 - xx - lavf 59.3.100 - avformat.h
Add pts_wrap_bits to AVStream
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 7383d12d3e..800bee3489 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -289,6 +289,7 @@ const char *av_packet_side_data_name(enum
AVPacketSideDataType type)
case AV_PKT_DATA_ICC_PROFILE:return "ICC Profile";
case AV_PKT_DATA_DOVI_CONF: return "DOVI configuration
record";
case AV_PKT_DATA_S12M_TIMECODE: return "SMPTE ST 12-1:2014
timecode";
+case AV_PKT_DATA_DYNAMIC_HDR10_PLUS: return "HDR10+ Dynamic
Metadata (SMPTE 2094-40)";
}
return NULL;
}
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index e5e4256871..568710cf4a 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1497,6 +1497,7 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame
*frame)
{ AV_PKT_DATA_A53_CC, AV_FRAME_DATA_A53_CC },
{ AV_PKT_DATA_ICC_PROFILE,AV_FRAME_DATA_ICC_PROFILE },
{ AV_PKT_DATA_S12M_TIMECODE, AV_FRAME_DATA_S12M_TIMECODE
},
+{ AV_PKT_DATA_DYNAMIC_HDR10_PLUS,
AV_FRAME_DATA_DYNAMIC_HDR_PLUS },
};
if (!(avctx->codec->caps_internal & FF_CODEC_CAP_SETS_FRAME_PROPS)) {
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 94932a48da..a7de6b5321 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -64,6 +64,11 @@ struct FrameListData {
struct FrameListData *next;
};
+typedef struct FrameHDR10Plus {
+int64_t pts;
+AVBufferRef *hdr10_plus;
+} FrameHDR10Plus;
+
typedef struct VPxEncoderContext {
AVClass *class;
struct vpx_codec_ctx encoder;
@@ -121,6 +126,8 @@ typedef struct VPxEncoderContext {
int tune_content;
int corpus_complexity;
int tpl_model;
+int discard_hdr10_plus;
+AVFifoBuffer *hdr10_plus_fifo;
/**
* If the driver does not support ROI then warn the first time we
* encounter a frame with ROI side data.
@@ -316,6 +323,51 @@ static av_cold void free_frame_list(struct FrameListData
*list)
}
}
+static av_cold int add_hdr10_plus(AVFifoBuffer *fifo, struct FrameHDR10Plus
*data)
+{
+int err = av_fifo_grow(fifo, sizeof(*data));
+if (err < 0)
+return err;
+av_fifo_generic_write(fifo, data, sizeof(*data), NULL);
+return 0;
+}
+
+static av_cold void free_hdr10_plus_fifo(AVFifoBuffer **fifo)
+{
+FrameHDR10Plus frame_hdr10_plus;
+while (av_fifo_size(*fifo) >= sizeof(frame_hdr10_plus)) {
+av_fifo_generic_read(*fifo, &frame_hdr10_plus,
sizeof(frame_hdr10_plus), NULL);
+av_buffer_unref(&frame_hdr10_plus.hdr10_plus);
+}
+av_fifo_freep(fifo);
+}
+
+static int copy_hdr10_plus_to_pkt(AVFifoBuffer *fifo, AVPacket *pkt)
+{
+FrameHDR10Plus frame_hdr10_plus;
+uint8_t *data;
+if (!pkt)
+return 0;
+if (av_fifo_size(fifo) < sizeof(frame_hdr10_plus))
+return 0;
+av_fifo_generic_peek(fifo, &frame_hdr10_plus, sizeof(frame_hdr10_plus),
NULL);
+if (!frame_hdr10_plus.hdr10_plus || frame_hdr10_plus.pts != pkt->pts)
+return 0;
+av_fifo_generic_read(fifo, &frame_hdr10_plus, sizeof(frame_hdr10_plus),
NULL);
+if (!frame_hdr10_plus.hdr10_plus)
+return 0;
+
+data = av_packet_new_side_data(pkt, AV_PKT_DATA_DYNAMIC_HDR10_PLUS,
frame_hdr10_plus.hdr10_plus->size);
+if (!data) {
+av_buffer_unref(&frame_hdr10_plus.hdr10_plus);
+return AVERROR(ENOMEM);
+}
+
+memcpy(data, frame_hdr10_plus.hdr10_plus->data,
frame_hdr10_plus.hdr10_plus->size);
+av_buffer_unref(&frame_hdr10_plus.hdr10_plus);
+return 0;
+}
+
static av_cold int codecctl_int(AVCodecContext *avctx,
enum vp8e_enc_control_id id, int val)
{
@@ -384,6 +436,8 @@ static av_cold int vpx_free(AVCodecContext *avctx)
av_freep(&ctx->twopass_stats.buf);
av_freep(&avctx->stats_out);
free_frame_list(ctx->coded_frame_list);
+if (ctx->
Re: [FFmpeg-devel] [PATCH] avcodec: Pass the HDR10+ metadata to the packet side data in VP9 encoder
On Tue, Jun 22, 2021 at 1:47 PM James Zern wrote: > On Thu, Jun 17, 2021 at 10:21 PM Mohammad Izadi > wrote: > > > > HDR10+ metadata is stored in the bit stream for HEVC. The story is > different for VP9 and cannot store the metadata in the bit stream. HDR10+ > should be passed to packet side data an stored in the container (mkv) for > VP9. > > > > This CL is taking HDR10+ from AVFrame side data in libvpxenc and is > passing it to the AVPacket side data. > > --- > > doc/APIchanges | 2 + > > libavcodec/avpacket.c | 1 + > > libavcodec/decode.c| 1 + > > libavcodec/libvpxenc.c | 91 ++ > > libavcodec/packet.h| 8 > > libavcodec/version.h | 4 +- > > 6 files changed, 105 insertions(+), 2 deletions(-) > > > > lgtm with updates for version.h and doc/APIchanges locally. I'll > submit this soon if there aren't any additional comments. > Rebased. Great, thanks! > > > diff --git a/doc/APIchanges b/doc/APIchanges > > index 06493763b3..ee7881e1e9 100644 > > --- a/doc/APIchanges > > +++ b/doc/APIchanges > > @@ -13,6 +13,8 @@ libavutil: 2021-04-27 > > > > > > API changes, most recent first: > > +2021-05-25 - 8c88a66d3c - lavc 59.2.100 - packet.h > > 8c88a66d3c should be xx to start with since the commit hash will > change. > Done. > ___ > 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".
