Re: [FFmpeg-devel] [PATCH] ffprobe: add decode_error_flags
On 25.05.2021 13:27, Nicolas George wrote:
Michael Niedermayer (12021-05-25):
Signed-off-by: Michael Niedermayer
---
doc/ffprobe.xsd| 1 +
fftools/ffprobe.c | 2 +
tests/ref/fate/exif-image-embedded | 22 ++
tests/ref/fate/exif-image-jpg | 1 +
tests/ref/fate/exif-image-tiff | 1 +
tests/ref/fate/exif-image-webp | 1 +
tests/ref/fate/ffprobe_compact | 28 +--
tests/ref/fate/ffprobe_csv | 28 +--
tests/ref/fate/ffprobe_default | 14 ++
tests/ref/fate/ffprobe_flat| 14 ++
tests/ref/fate/ffprobe_ini | 14 ++
tests/ref/fate/flcl1905| 352 ++---
tests/ref/fate/h264-dts_5frames| 5 +
tests/ref/fate/mov-zombie | 130 +--
tests/ref/fate/png-side-data | 1 +
15 files changed, 345 insertions(+), 269 deletions(-)
diff --git a/doc/ffprobe.xsd b/doc/ffprobe.xsd
index 250de8cd5c..370d68374c 100644
--- a/doc/ffprobe.xsd
+++ b/doc/ffprobe.xsd
@@ -96,6 +96,7 @@
+
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 88e82a4195..37aec0564a 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2259,6 +2259,8 @@ static void show_frame(WriterContext *w, AVFrame *frame,
AVStream *stream,
else print_str_opt("pkt_pos", "N/A");
if (frame->pkt_size != -1) print_val("pkt_size", frame->pkt_size,
unit_byte_str);
else print_str_opt("pkt_size", "N/A");
+if (frame->decode_error_flags) print_fmt("decode_error_flags", "0x%x",
frame->decode_error_flags);
+else print_str_opt("decode_error_flags", "0");
Since the value is an int, I think it would be better to have it
declared as a number, even if it cannot be in hex.
IMHO for bit-fields an hexadecimal number may be more readable. My
improvement suggestion would be to use some zero-padded formatting like
"0x%02x" and also use a hexadecimal value "0x00" for the default case
for consistency.
Just my 2ct,
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".
[FFmpeg-devel] [PATCH] avutil/mem: use GCC builtins to check for overflow in av_size_mult()
Signed-off-by: James Almer
---
libavutil/mem.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavutil/mem.h b/libavutil/mem.h
index e21a1feaae..c876111afb 100644
--- a/libavutil/mem.h
+++ b/libavutil/mem.h
@@ -674,11 +674,18 @@ void *av_dynarray2_add(void **tab_ptr, int *nb_ptr,
size_t elem_size,
*/
static inline int av_size_mult(size_t a, size_t b, size_t *r)
{
-size_t t = a * b;
+size_t t;
+
+#if (!defined(__INTEL_COMPILER) && AV_GCC_VERSION_AT_LEAST(5,1)) ||
AV_HAS_BUILTIN(__builtin_mul_overflow)
+if (__builtin_mul_overflow(a, b, &t))
+return AVERROR(EINVAL);
+#else
+t = a * b;
/* Hack inspired from glibc: don't try the division if nelem and elsize
* are both less than sqrt(SIZE_MAX). */
if ((a | b) >= ((size_t)1 << (sizeof(size_t) * 4)) && a && t / a != b)
return AVERROR(EINVAL);
+#endif
*r = t;
return 0;
}
--
2.31.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/libsrt: log streamid in listener mode
It's useful for test client which pass streamid to ffmpeg/ffplay.
For example, use ffmpeg to test streamid support in VLC:
./ffmpeg -v info -re -i foo.mp4 -c copy -f mpegts -mode listener
srt://127.0.0.1:9000
./vlc srt://127.0.0.1:9000?streamid=foobar
---
libavformat/libsrt.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index c1e96f700e..6ea6c35c53 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -143,6 +143,8 @@ static const AVOption libsrt_options[] = {
{ NULL }
};
+static int libsrt_getsockopt(URLContext *h, int fd, SRT_SOCKOPT optname, const
char * optnamestr, void * optval, int * optlen);
+
static int libsrt_neterrno(URLContext *h)
{
int os_errno;
@@ -224,6 +226,8 @@ static int libsrt_listen(int eid, int fd, const struct
sockaddr *addr, socklen_t
{
int ret;
int reuse = 1;
+char streamid[512] = {};
+int streamid_len = sizeof(streamid);
if (srt_setsockopt(fd, SOL_SOCKET, SRTO_REUSEADDR, &reuse, sizeof(reuse)))
{
av_log(h, AV_LOG_WARNING, "setsockopt(SRTO_REUSEADDR) failed\n");
}
@@ -242,6 +246,8 @@ static int libsrt_listen(int eid, int fd, const struct
sockaddr *addr, socklen_t
return libsrt_neterrno(h);
if (libsrt_socket_nonblock(ret, 1) < 0)
av_log(h, AV_LOG_DEBUG, "libsrt_socket_nonblock failed\n");
+if (!libsrt_getsockopt(h, ret, SRTO_STREAMID, "SRTO_STREAMID", streamid,
&streamid_len))
+av_log(h, AV_LOG_INFO, "accept streamid [%s], length %d\n", streamid,
streamid_len);
return ret;
}
--
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".
Re: [FFmpeg-devel] [PATCH 3/3] avformat/avio: Check av_opt_copy() for failure
On Thu, May 20, 2021 at 11:25:49PM +0200, Michael Niedermayer wrote: > Fixes: CID1477416 Unchecked return value > > Signed-off-by: Michael Niedermayer > --- > libavformat/avio.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway 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/3] Remove format (Alternative solution for CID1477423)
On Thu, May 20, 2021 at 11:25:48PM +0200, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavformat/moflex.c | 3 --- > 1 file changed, 3 deletions(-) will combine with patch 1 and apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Nations do behave wisely once they have exhausted all other alternatives. -- Abba Eban signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/error_resilience: cleanup mpeg2 handling
On Mon, May 24, 2021 at 10:43:54PM +0200, Michael Niedermayer wrote: > After this, the loop for the mpeg2 case is only executed when needed > > Signed-off-by: Michael Niedermayer > --- > libavcodec/error_resilience.c | 23 --- > 1 file changed, 12 insertions(+), 11 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/exr: x/ymax cannot be INT_MAX
On Wed, Apr 21, 2021 at 02:31:18PM +0200, Michael Niedermayer wrote: > The code uses x/ymax + 1 so the maximum is INT_MAX-1 > > Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type > 'int' > Fixes: > 33158/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5545462457303040 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/exr.c | 1 + > 1 file changed, 1 insertion(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle 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] avcodec/exr: More strictly check dc_count
On Tue, May 25, 2021 at 10:22:02PM +0200, Michael Niedermayer wrote: > Fixes: out of array access > Fixes: exr/deneme > > Found-by: Burak Çarıkçı > Signed-off-by: Michael Niedermayer > --- > libavcodec/exr.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/yadif: Fix time base for large denominators
On Tue, May 25, 2021 at 11:57:08AM -0400, Tom Boshoven wrote: > This fixes an issue where the yadif filter could cause the timebase > denominator to overflow. > > Signed-off-by: Tom Boshoven > --- > libavfilter/vf_yadif.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The smallest minority on earth is the individual. Those who deny individual rights cannot claim to be defenders of minorities. - Ayn Rand 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] avcodec: Pass the HDR10+ metadata to the packet side data in VP9 encoder
All done.
On Wed, May 26, 2021 at 2:42 PM Lynne wrote:
> May 26, 2021, 20:43 by izadi-at-google@ffmpeg.org:
>
> > 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 | 89 +-
> > libavcodec/packet.h| 8
> > libavcodec/version.h | 2 +-
> > 6 files changed, 100 insertions(+), 3 deletions(-)
> >
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index c46f4d5304..60995579e5 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
> > + Add AV_PKT_DATA_DYNAMIC_HDR10_PLUS
> >
> > 2021-04-27 - cb3ac722f4 - lavc 59.0.100 - avcodec.h
> > Constified AVCodecParserContext.parser.
> > 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 75bc7ad98e..40f688e40c 100644
> > --- a/libavcodec/decode.c
> > +++ b/libavcodec/decode.c
> > @@ -1488,6 +1488,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 (IS_EMPTY(pkt) && av_fifo_size(avctx->internal->pkt_props) >=
> sizeof(*pkt))
> > diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> > index 66bad444d0..44ac90cafe 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,49 @@ static av_cold void free_frame_list(struct
> FrameListData *list)
> > }
> > }
> >
> > +static void add_hdr10_plus(AVFifoBuffer *fifo, struct FrameHDR10Plus
> *data)
> > +{
> > +av_fifo_grow(fifo, sizeof(FrameHDR10Plus));
> > +av_fifo_generic_write(fifo, data, sizeof(FrameHDR10Plus), NULL);
> > +}
> > +
> > +static av_cold void free_hdr10_plus(struct FrameHDR10Plus *p)
> > +{
> > +if (!p) return;
> >
>
> Put the returns on a newline.
>
>
> > +av_buffer_unref(&p->hdr10_plus);
> > +av_free(p);
> > +}
> > +
> > +static av_cold void free_hdr10_plus_fifo(AVFifoBuffer **fifo)
> > +{
> > +FrameHDR10Plus *frame_hdr10_plus = NULL;
> > +while (av_fifo_generic_read(*fifo, frame_hdr10_plus,
> sizeof(*frame_hdr10_plus), NULL) > 0) {
> > +free_hdr10_plus(frame_hdr10_plus);
> > +}
> >
>
> No brackets around one-line expressions.
> Fix the coding style nits and it looks good to me.
>
> ___
> 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 | 92 ++
libavcodec/packet.h| 8
libavcodec/version.h | 2 +-
6 files changed, 105 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index c46f4d5304..60995579e5 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
+ Add AV_PKT_DATA_DYNAMIC_HDR10_PLUS
2021-04-27 - cb3ac722f4 - lavc 59.0.100 - avcodec.h
Constified AVCodecParserContext.parser.
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 75bc7ad98e..40f688e40c 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1488,6 +1488,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 (IS_EMPTY(pkt) && av_fifo_size(avctx->internal->pkt_props) >=
sizeof(*pkt))
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 66bad444d0..6265e64668 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,53 @@ 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(FrameHDR10Plus));
+if (err < 0)
+return err;
+av_fifo_generic_write(fifo, data, sizeof(FrameHDR10Plus), NULL);
+return 0;
+}
+
+static av_cold void free_hdr10_plus(struct FrameHDR10Plus *p)
+{
+if (!p)
+return;
+av_buffer_unref(&p->hdr10_plus);
+av_free(p);
+}
+
+static av_cold void free_hdr10_plus_fifo(AVFifoBuffer **fifo)
+{
+FrameHDR10Plus *frame_hdr10_plus = NULL;
+while (av_fifo_generic_read(*fifo, frame_hdr10_plus,
sizeof(*frame_hdr10_plus), NULL) > 0)
+free_hdr10_plus(frame_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 (av_fifo_size(fifo) < 1)
+return 0;
+
+av_fifo_generic_read(fifo, frame_hdr10_plus, sizeof(*frame_hdr10_plus),
NULL);
+if (!frame_hdr10_plus || !pkt || !frame_hdr10_plus->hdr10_plus ||
frame_hdr10_plus->pts != pkt->pts)
+return 0;
+
+data = av_packet_new_side_data(pkt, AV_PKT_DATA_DYNAMIC_HDR10_PLUS,
frame_hdr10_plus->hdr10_plus->size);
+if (!data) {
+free_hdr10_plus(frame_hdr10_plus);
+return AVERROR(ENOMEM);
+}
+memcpy(data, frame_hdr10_plus->hdr10_plus->data,
frame_hdr10_plus->hdr10_plus->size);
+free_hdr10_plus(frame_hdr10_plus);
+
+return 0;
+}
+
static av_cold int codecctl_int(AVCodecContext *avctx,
enum vp8e_enc_control_id id, int val)
{
@@ -384,6 +438,7 @@ 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);
+free_hdr10_plus_fifo(&ctx->hdr10_plus_fifo);
return 0;
}
@@ -8
Re: [FFmpeg-devel] [PATCH] avcodec: Pass the HDR10+ metadata to the packet side data in VP9 encoder
On Wed, May 26, 2021 at 9:17 PM James Zern
wrote:
> On Wed, May 26, 2021 at 6:35 PM Mohammad Izadi
> wrote:
> > [...]
> > +static void add_hdr10_plus(AVFifoBuffer *fifo, struct FrameHDR10Plus
> *data)
> > +{
> > +av_fifo_grow(fifo, sizeof(FrameHDR10Plus));
>
> This return should be checked.
>
Done
>
> > +av_fifo_generic_write(fifo, data, sizeof(FrameHDR10Plus), NULL);
> > +}
> >
> > [...]
> > +static int copy_hdr10_plus_to_pkt(AVFifoBuffer *fifo, AVPacket *pkt)
> > +{
> > +FrameHDR10Plus *frame_hdr10_plus;
> > +uint8_t *data;
> > +if (av_fifo_size(fifo) < 1)
> > +return 0;
> > +
> > +av_fifo_generic_read(fifo, frame_hdr10_plus,
> sizeof(*frame_hdr10_plus), NULL);
> > +if (!frame_hdr10_plus || !pkt || !(frame_hdr10_plus->hdr10_plus) ||
> frame_hdr10_plus->pts != pkt->pts)
>
> The inner ()s can be remove in the hdr10_plus check
>
Done
>
>
> > -if(!avctx->bit_rate)
> > -if(avctx->rc_max_rate || avctx->rc_buffer_size ||
> avctx->rc_initial_buffer_occupancy) {
> > +if (!avctx->bit_rate)
> > +if (avctx->rc_max_rate || avctx->rc_buffer_size ||
> avctx->rc_initial_buffer_occupancy) {
>
> Let's leave the cosmetic change to a separate commit.
>
Done
>
>
> > +/**
> > + * HDR10+ dynamic metadata associated with a video frame. The
> metadata is in
> > + * the form of the AVDynamicHDRPlus struct and contains
> > + * information for color volume transform - application 4 of
> > + * SPMTE 2094-40:2016 standard.
>
> SMPTE
>
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".
Re: [FFmpeg-devel] [PATCH] ffprobe: add decode_error_flags
On Thu, 27 May 2021, Tobias Rapp wrote:
On 25.05.2021 13:27, Nicolas George wrote:
Michael Niedermayer (12021-05-25):
Signed-off-by: Michael Niedermayer
---
doc/ffprobe.xsd| 1 +
fftools/ffprobe.c | 2 +
tests/ref/fate/exif-image-embedded | 22 ++
tests/ref/fate/exif-image-jpg | 1 +
tests/ref/fate/exif-image-tiff | 1 +
tests/ref/fate/exif-image-webp | 1 +
tests/ref/fate/ffprobe_compact | 28 +--
tests/ref/fate/ffprobe_csv | 28 +--
tests/ref/fate/ffprobe_default | 14 ++
tests/ref/fate/ffprobe_flat| 14 ++
tests/ref/fate/ffprobe_ini | 14 ++
tests/ref/fate/flcl1905| 352 ++---
tests/ref/fate/h264-dts_5frames| 5 +
tests/ref/fate/mov-zombie | 130 +--
tests/ref/fate/png-side-data | 1 +
15 files changed, 345 insertions(+), 269 deletions(-)
diff --git a/doc/ffprobe.xsd b/doc/ffprobe.xsd
index 250de8cd5c..370d68374c 100644
--- a/doc/ffprobe.xsd
+++ b/doc/ffprobe.xsd
@@ -96,6 +96,7 @@
+
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 88e82a4195..37aec0564a 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2259,6 +2259,8 @@ static void show_frame(WriterContext *w, AVFrame
*frame, AVStream *stream,
else print_str_opt("pkt_pos", "N/A");
if (frame->pkt_size != -1) print_val("pkt_size",
frame->pkt_size, unit_byte_str);
else print_str_opt("pkt_size", "N/A");
+if (frame->decode_error_flags) print_fmt("decode_error_flags",
"0x%x", frame->decode_error_flags);
+else print_str_opt("decode_error_flags",
"0");
Since the value is an int, I think it would be better to have it
declared as a number, even if it cannot be in hex.
IMHO for bit-fields an hexadecimal number may be more readable. My
improvement suggestion would be to use some zero-padded formatting like
"0x%02x" and also use a hexadecimal value "0x00" for the default case for
consistency.
If xsd:int could be hex, then sure. But since xsd:int is regular integer
only, then I'd prefer the number. After all, not many decode error flags
exists and reading 4 bits in decimal is easy.
An alternative approach is to print the meaning of the actually used
flags:
This is the most readable, but maybe too verbose for the default use?
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavfi/dnn_backend_openvino.c: Correct Pointer Type while Freeing
This commit corrects the type of pointer of elements from the
inference queue in ff_dnn_free_model_ov.
Signed-off-by: Shubhanshu Saxena
---
libavfilter/dnn/dnn_backend_openvino.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/dnn/dnn_backend_openvino.c
b/libavfilter/dnn/dnn_backend_openvino.c
index e0781e854a..58c4ec9c9b 100644
--- a/libavfilter/dnn/dnn_backend_openvino.c
+++ b/libavfilter/dnn/dnn_backend_openvino.c
@@ -963,7 +963,7 @@ void ff_dnn_free_model_ov(DNNModel **model)
ff_safe_queue_destroy(ov_model->request_queue);
while (ff_queue_size(ov_model->inference_queue) != 0) {
-TaskItem *item = ff_queue_pop_front(ov_model->inference_queue);
+InferenceItem *item =
ff_queue_pop_front(ov_model->inference_queue);
av_freep(&item);
}
ff_queue_destroy(ov_model->inference_queue);
--
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] avisynth.c corrected interlace detection
On 5/24/2021 11:03 AM, emcodem wrote:
Sorry for the delay on this, should have corrected it much earlier.
There was some confusion in the interlaced analysis. From 3rdparty decoders
perspective, a clip
can only be interlaced when it is NOT field_based. This is because in a
field_based clip, the fields
are separate images, so it is actually progressive. In that case, avisynth
still shows is_tff or bff because those
values are needed in case the script decides to weave the separated fields
later on.
---
libavformat/avisynth.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 350ac6d11d..ff6e6e1bfa 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -250,15 +250,12 @@ static int avisynth_create_stream_video(AVFormatContext
*s, AVStream *st)
st->nb_frames = avs->vi->num_frames;
avpriv_set_pts_info(st, 32, avs->vi->fps_denominator,
avs->vi->fps_numerator);
-av_log(s, AV_LOG_TRACE, "avs_is_field_based: %d\n", avs_is_field_based(avs->vi));
-av_log(s, AV_LOG_TRACE, "avs_is_parity_known: %d\n",
avs_is_parity_known(avs->vi));
-/* The following typically only works when assumetff (-bff) and
- * assumefieldbased is used in-script. Additional
- * logic using GetParity() could deliver more accurate results
- * but also decodes a frame which we want to avoid. */
st->codecpar->field_order = AV_FIELD_UNKNOWN;
-if (avs_is_field_based(avs->vi)) {
+/* separatefields makes field_based==true, weave makes field_based==false
+ * only non field_based clips can therefore be interlaced */
+av_log(s, AV_LOG_TRACE, "avs_is_field_based: %d\n",
avs_is_field_based(avs->vi));
+if (avs_is_field_based(avs->vi) == 0) {
if (avs_is_tff(avs->vi)) {
st->codecpar->field_order = AV_FIELD_TT;
}
The change seems okay, but the comment and commit message need to
explain what's going on better, because the confusion that's erupted
over this seems to derive from the rather poor way the AviSynth
documentation describes the difference between field-based and
frame-based clips, and how to access this information through the API.
After having read through all of this a bit more, the situation appears to
be as follows:
AviSynth works on Frame-based video. Full stop. 'Frame-based',
despite the name, is not a synonym for 'progressive', merely that
it's being processed as a single frame rather than as a half-height
field. This is the single point from which all the rest of this
got confused.
Using SeparateFields(), you can break the frame into its constituent
half-height fields so that certain filters which don't like processing
interlaced footage can filter the fields as a sort of 'fake
progressive', before using Weave() to combine the fields again into
a singular full height frame. That's its intention, rather than to
signal to a client program that something is interlaced. The
AssumeFieldBased() function and avs_is_field_based API check are
there to allow other functions to understand this situation
where the fields have been broken apart (or to override the
field-based setting in cases that it didn't get set properly).
The confusion seems to have arisen from mistaking these as ways
that AviSynth indicates something is interlaced or not, and it
isn't. For that purpose, you have to look at frame properties,
something that was introduced in AviSynth+ as a flag that a source
plugin can set to indicate whether the frame is interlaced (either
tff or bff) or progressive. Adding frame property detection to
the demuxer here would require larger changes that need to be
guarded from 2.6, but it would accomplish the goal I *think*
this is ultimately intended to address.
The in-code comment should probably be something closer to:
/* AviSynth works on frame-based video by default, which can
/* be either progressive or interlaced. Some filters can break
/* frames into half-height fields, at which point it considers
/* the clip to be field-based (avs_is_field_based can be used
/* to check for this situation).
/* To properly detect the field order of a typical video clip,
/* the frame needs to have been weaved back together already,
/* so avs_is_field_based should actually report 'false' when
/* checked. */
___
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] lavfi/dnn_backend_openvino.c: Correct Pointer Type while Freeing
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Shubhanshu Saxena
> Sent: 2021年5月28日 2:06
> To: ffmpeg-devel@ffmpeg.org
> Cc: Shubhanshu Saxena
> Subject: [FFmpeg-devel] [PATCH] lavfi/dnn_backend_openvino.c: Correct
> Pointer Type while Freeing
>
> This commit corrects the type of pointer of elements from the
> inference queue in ff_dnn_free_model_ov.
>
> Signed-off-by: Shubhanshu Saxena
> ---
> libavfilter/dnn/dnn_backend_openvino.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/dnn/dnn_backend_openvino.c
> b/libavfilter/dnn/dnn_backend_openvino.c
> index e0781e854a..58c4ec9c9b 100644
> --- a/libavfilter/dnn/dnn_backend_openvino.c
> +++ b/libavfilter/dnn/dnn_backend_openvino.c
> @@ -963,7 +963,7 @@ void ff_dnn_free_model_ov(DNNModel **model)
> ff_safe_queue_destroy(ov_model->request_queue);
>
> while (ff_queue_size(ov_model->inference_queue) != 0) {
> -TaskItem *item =
> ff_queue_pop_front(ov_model->inference_queue);
> +InferenceItem *item =
> ff_queue_pop_front(ov_model->inference_queue);
> av_freep(&item);
> }
> ff_queue_destroy(ov_model->inference_queue);
thanks for the catch, will push soon.
___
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] libavcodec/mips: Fix build errors reported by clang
Clang is more strict on the type of asm operands, float or double
type variable should use constraint 'f', integer variable should
use constraint 'r'.
Signed-off-by: Jin Bo
---
libavcodec/mips/constants.c | 89 +++--
libavcodec/mips/constants.h | 88 +++--
libavcodec/mips/h264chroma_mmi.c | 157 +++
libavcodec/mips/h264dsp_mmi.c| 20 +--
libavcodec/mips/h264pred_mmi.c | 23 ++--
libavcodec/mips/h264qpel_mmi.c | 34 ++---
libavcodec/mips/hevcdsp_mmi.c| 59 +
libavcodec/mips/idctdsp_mmi.c| 2 +-
libavcodec/mips/mpegvideo_mmi.c | 20 +--
libavcodec/mips/vc1dsp_mmi.c | 176 +-
libavcodec/mips/vp8dsp_mmi.c | 263 +--
libavutil/mips/asmdefs.h | 8 ++
12 files changed, 536 insertions(+), 403 deletions(-)
diff --git a/libavcodec/mips/constants.c b/libavcodec/mips/constants.c
index 8c990b6..6a8f1a5 100644
--- a/libavcodec/mips/constants.c
+++ b/libavcodec/mips/constants.c
@@ -19,50 +19,49 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
-#include "config.h"
-#include "libavutil/mem_internal.h"
+#include "libavutil/intfloat.h"
#include "constants.h"
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_1) = {0x0001000100010001ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_2) = {0x0002000200020002ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_3) = {0x0003000300030003ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_4) = {0x0004000400040004ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_5) = {0x0005000500050005ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_6) = {0x0006000600060006ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_8) = {0x0008000800080008ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_9) = {0x0009000900090009ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_10) = {0x000A000A000A000AULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_12) = {0x000C000C000C000CULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_15) = {0x000F000F000F000FULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_16) = {0x0010001000100010ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_17) = {0x0011001100110011ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_18) = {0x0012001200120012ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_20) = {0x0014001400140014ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_22) = {0x0016001600160016ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_28) = {0x001C001C001C001CULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_32) = {0x0020002000200020ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_53) = {0x0035003500350035ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_64) = {0x0040004000400040ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_128) = {0x0080008000800080ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_512) = {0x0200020002000200ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_m8tom5) = {0xFFFBFFFAFFF9FFF8ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_m4tom1) = {0xFFFEFFFDFFFCULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_1to4) ={0x0004000300020001ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_5to8) ={0x0008000700060005ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_0to3) ={0x000300020001ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_4to7) ={0x0007000600050004ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_8tob) ={0x000b000a00090008ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pw_ctof) ={0x000f000e000d000cULL};
-
-DECLARE_ALIGNED(8, const uint64_t, ff_pb_1) = {0x0101010101010101ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pb_3) = {0x0303030303030303ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pb_80) = {0x8080808080808080ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pb_A1) = {0xA1A1A1A1A1A1A1A1ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_pb_FE) = {0xFEFEFEFEFEFEFEFEULL};
-
-DECLARE_ALIGNED(8, const uint64_t, ff_rnd) ={0x0004000400040004ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_rnd2) = {0x0040004000400040ULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_rnd3) = {0x0020002000200020ULL};
-
-DECLARE_ALIGNED(8, const uint64_t, ff_wm1010) = {0xULL};
-DECLARE_ALIGNED(8, const uint64_t, ff_d4) = {0x0004ULL};
+union av_intfloat64 ff_pw_1 = {0x0001000100010001ULL};
+union av_intfloat64 ff_pw_2 = {0x0002000200020002ULL};
+union av_intfloat64 ff_pw_3 = {0x0003000300030003ULL};
+union av_intfloat64 ff_pw_4 = {0x0004000400040004ULL};
+union av_intfloat64 ff_pw_5 = {0x0005000500050005ULL};
+union av_intfloat64 ff_pw_6 = {0x0006000600060006ULL};
+union av_intfloat64 ff_pw_8 = {0x0008000800080008ULL};
+union av_intfloat64 ff_pw_9 = {0x0009000900090009ULL};
+union av_intfloat64 ff_pw_10 = {0x000A000A000A000AULL};
+union av_intfloat64 ff_pw_12 = {0x000C000C000C000CULL};
[FFmpeg-devel] [PATCH 3/3] libavcodec/mips: Fix fate errors reported by clang
The data width of gsldrc1/gsldlc1 should be 8 bytes wide. Signed-off-by: Jin Bo --- libavcodec/mips/vp9_mc_mmi.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/libavcodec/mips/vp9_mc_mmi.c b/libavcodec/mips/vp9_mc_mmi.c index fa65ff5..812f7a6 100644 --- a/libavcodec/mips/vp9_mc_mmi.c +++ b/libavcodec/mips/vp9_mc_mmi.c @@ -83,9 +83,9 @@ static void convolve_horiz_mmi(const uint8_t *src, int32_t src_stride, __asm__ volatile ( "move %[tmp1],%[width] \n\t" "pxor %[ftmp0], %[ftmp0],%[ftmp0] \n\t" -"gsldlc1%[filter1], 0x03(%[filter])\n\t" +"gsldlc1%[filter1], 0x07(%[filter])\n\t" "gsldrc1%[filter1], 0x00(%[filter])\n\t" -"gsldlc1%[filter2], 0x0b(%[filter])\n\t" +"gsldlc1%[filter2], 0x0f(%[filter])\n\t" "gsldrc1%[filter2], 0x08(%[filter])\n\t" "li %[tmp0],0x07 \n\t" "dmtc1 %[tmp0],%[ftmp13] \n\t" @@ -158,9 +158,9 @@ static void convolve_vert_mmi(const uint8_t *src, int32_t src_stride, __asm__ volatile ( "pxor %[ftmp0],%[ftmp0], %[ftmp0] \n\t" -"gsldlc1%[ftmp4],0x03(%[filter]) \n\t" +"gsldlc1%[ftmp4],0x07(%[filter]) \n\t" "gsldrc1%[ftmp4],0x00(%[filter]) \n\t" -"gsldlc1%[ftmp5],0x0b(%[filter]) \n\t" +"gsldlc1%[ftmp5],0x0f(%[filter]) \n\t" "gsldrc1%[ftmp5],0x08(%[filter]) \n\t" "punpcklwd %[filter10], %[ftmp4], %[ftmp4] \n\t" "punpckhwd %[filter32], %[ftmp4], %[ftmp4] \n\t" @@ -254,9 +254,9 @@ static void convolve_avg_horiz_mmi(const uint8_t *src, int32_t src_stride, __asm__ volatile ( "move %[tmp1],%[width] \n\t" "pxor %[ftmp0], %[ftmp0],%[ftmp0] \n\t" -"gsldlc1%[filter1], 0x03(%[filter])\n\t" +"gsldlc1%[filter1], 0x07(%[filter])\n\t" "gsldrc1%[filter1], 0x00(%[filter])\n\t" -"gsldlc1%[filter2], 0x0b(%[filter])\n\t" +"gsldlc1%[filter2], 0x0f(%[filter])\n\t" "gsldrc1%[filter2], 0x08(%[filter])\n\t" "li %[tmp0],0x07 \n\t" "dmtc1 %[tmp0],%[ftmp13] \n\t" @@ -340,9 +340,9 @@ static void convolve_avg_vert_mmi(const uint8_t *src, int32_t src_stride, __asm__ volatile ( "pxor %[ftmp0],%[ftmp0], %[ftmp0] \n\t" -"gsldlc1%[ftmp4],0x03(%[filter]) \n\t" +"gsldlc1%[ftmp4],0x07(%[filter]) \n\t" "gsldrc1%[ftmp4],0x00(%[filter]) \n\t" -"gsldlc1%[ftmp5],0x0b(%[filter]) \n\t" +"gsldlc1%[ftmp5],0x0f(%[filter]) \n\t" "gsldrc1%[ftmp5],0x08(%[filter]) \n\t" "punpcklwd %[filter10], %[ftmp4], %[ftmp4] \n\t" "punpckhwd %[filter32], %[ftmp4], %[ftmp4] \n\t" -- 2.1.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 00/27] Metadata handling in CBS
Hi,
Are there any plans to get this (or even a similar patch) merged? I was
excited to see this initially, but it has been six months now without a word
about it.
Thanks,
Kenny
> On Jan 1, 2021, at 2:35 PM, Mark Thompson wrote:
>
> Happy New Year!
>
> The fun part here is:
>
> AVMasteringDisplayMetadata mdm = { ... };
> AVContentLightMetadata clm = { ... };
> ff_cbs_insert_metadata(cbc, fragment, CBS_METADATA_MASTERING_DISPLAY, &mdm);
> ff_cbs_insert_metadata(cbc, fragment, CBS_METADATA_CONTENT_LIGHT_LEVEL, &clm);
>
> which does whatever is needed to splice that metadata into the given
> bitstream fragment.
>
> It's implemented for H.264, H.265 and AV1 here. Extension to the common
> parts of H.266 is trivial (just add to the type table).
>
> The metadata bitstream filters are extended to support that as well from side
> data. That's only library-usable, though - there is no ffmpeg-the-program
> interface for including the side data in the first place. (From discussion
> on IRC a few days ago there was interest in adding ffmpeg support for that
> along with automatic BSF insertion?)
>
> Not particularly well tested, since much of this was written in the last few
> days (though some parts like the common BSF implementation have been sent
> before).
>
> - Mark
>
>
> Mark Thompson (27):
> cbs_h2645: Merge SEI messages in common between codecs
> h264_metadata_bsf: Move SEI user data parsing to init time
> cbs_h2645: Merge SEI message handling in common between codecs
> cbs_sei: Remove restrictions on MDCV values
> h264_metadata_bsf: Refactor the filter function into smaller parts
> h264_metadata_bsf: Improve interpretation of input display matrices
> cbs: Implement common parts of cbs-based bitstream filters separately
> h264_metadata_bsf: Use common cbs bsf implementation
> h265_metadata_bsf: Use common cbs bsf implementation
> mpeg2_metadata_bsf: Use common cbs bsf implementation
> vp9_metadata_bsf: Use common cbs bsf implementation
> av1_metadata_bsf: Use common cbs bsf implementation
> h264_redundant_pps_bsf: Use common cbs bsf implementation
> cbs: Add interface for manipulating metadata in fragments
> cbs_sei: Implement metadata manipulation for SEI codecs
> cbs_sei: Implement fill and extract for HDR SEI messages
> cbs_h264: Implement fill and extract for display orientation SEI
>message
> cbs_av1: Implement metadata manipulation
> cbs_av1: Support manipulating HDR CLL and MDCV metadata
> cbs: Add interface to allow BSFs easy access to metadata manipulation
> h264_metadata_bsf: Simplify display orientation handling
> h264_metadata_bsf: Support HDR metadata
> h265_metadata_bsf: Support HDR metadata
> av1_metadata_bsf: Support HDR metadata
> vaapi_encode: Unify SEI option mask enum
> vaapi_encode_h265: Ensure that HDR metadata is included with seek
>points
> vaapi_encode_h264: Support HDR metadata
>
> doc/bitstream_filters.texi| 51 +++
> libavcodec/Makefile | 6 +-
> libavcodec/av1_metadata_bsf.c | 198 ++---
> libavcodec/cbs_av1.c | 233 +++
> libavcodec/cbs_bsf.c | 234 +++
> libavcodec/cbs_bsf.h | 106 +
> libavcodec/cbs_h264.h | 79 +---
> libavcodec/cbs_h2645.c| 494 --
> libavcodec/cbs_h264_syntax_template.c | 271 +---
> libavcodec/cbs_h265.h | 66 +--
> libavcodec/cbs_h265_syntax_template.c | 370 ++---
> libavcodec/cbs_internal.h | 17 +
> libavcodec/cbs_metadata.c | 107 +
> libavcodec/cbs_metadata.h | 94 +
> libavcodec/cbs_sei.c | 469 +
> libavcodec/cbs_sei.h | 350
> libavcodec/cbs_sei_syntax_template.c | 307 ++
> libavcodec/h264_metadata_bsf.c| 569 ++
> libavcodec/h264_redundant_pps_bsf.c | 99 +
> libavcodec/h265_metadata_bsf.c| 213 +++---
> libavcodec/mpeg2_metadata_bsf.c | 94 +
> libavcodec/vaapi_encode.h | 8 +
> libavcodec/vaapi_encode_h264.c| 125 --
> libavcodec/vaapi_encode_h265.c| 123 ++
> libavcodec/vp9_metadata_bsf.c | 61 +--
> 25 files changed, 2859 insertions(+), 1885 deletions(-)
> create mode 100644 libavcodec/cbs_bsf.c
> create mode 100644 libavcodec/cbs_bsf.h
> create mode 100644 libavcodec/cbs_metadata.c
> create mode 100644 libavcodec/cbs_metadata.h
> create mode 100644 libavcodec/cbs_sei.c
> create mode 100644 libavcodec/cbs_sei.h
> create mode 100644 libavcodec/cbs_sei_syntax_template.c
>
> --
> 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".
_
