Re: [FFmpeg-devel] GitHub Integration
Topic name is deeply misleading. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] avformat/mov: validate box size for stts
On 2021-12-23 03:04 am, Michael Niedermayer wrote:
On Wed, Dec 22, 2021 at 06:17:28PM +0530, Gyan Doshi wrote:
---
libavformat/mov.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7de95b7ab0..1e44c74944 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2969,6 +2969,12 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
avio_rb24(pb); /* flags */
entries = avio_rb32(pb);
+if (validate_box_size(c, atom, pb, avio_tell(pb)-8, 8+(int64_t)entries*8, 0)) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid or incomplete %s box in stream
%d\n",
+ av_fourcc2str(atom.type), c->fc->nb_streams-1);
+ return AVERROR_INVALIDDATA;
+}
+
av_log(c->fc, AV_LOG_TRACE, "track[%u].stts.entries = %u\n",
c->fc->nb_streams-1, entries);
this breaks playback of
./ffplay H263_NM_f.mp4
Sent revised set.
However, do we need to allow this?
The file has multiple invalid boxes. gpac refuses to import it. vlc
using its default mp4 demuxer does not open it, neither does wmp or firefox.
Seems only avformat users can open the file.
Regards,
Gyan
___
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 v3 2/2] avformat/mov: validate box size for stts
---
libavformat/mov.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index e223e95e2e..71404ba07a 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2968,6 +2968,12 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
avio_rb24(pb); /* flags */
entries = avio_rb32(pb);
+if (validate_box_size(c, atom, pb, avio_tell(pb)-8, 8+(int64_t)entries*8,
1)) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid or incomplete %s box in stream
%d\n",
+ av_fourcc2str(atom.type), c->fc->nb_streams-1);
+ return AVERROR_INVALIDDATA;
+}
+
av_log(c->fc, AV_LOG_TRACE, "track[%u].stts.entries = %u\n",
c->fc->nb_streams-1, entries);
--
2.33.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] [PATCH v3 1/2] avformat/mov: add validate_box_size
Helper function to check if stored box size is correct and looks
to be fully available.
---
libavformat/mov.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2aed6e80ef..e223e95e2e 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -80,6 +80,39 @@ static int mov_read_mfra(MOVContext *c, AVIOContext *f);
static int64_t add_ctts_entry(MOVCtts** ctts_data, unsigned int* ctts_count,
unsigned int* allocated_size,
int count, int duration);
+/** Check if the box size meets the requirements passed in limit and
constraint_type.
+ * If input avio_size is valid, it checks if box size appears to be
available.
+ *
+ * constraint_type may be
+ * 0 if the box size has to be exactly equal to limit
+ * -1 if the box size has to be at most limit
+ * 1 if the box size has to be at least limit
+ *
+ * Returns 0 if size meets requirements.
+ */
+static int validate_box_size(MOVContext *c, MOVAtom atom, AVIOContext *pb,
+ int64_t pos, int64_t limit, int constraint_type)
+{
+int size_fit;
+int64_t input_size = avio_size(pb);
+
+if (input_size > 0 &&
+input_size - pos < atom.size) {
+av_log(c->fc, AV_LOG_ERROR, "Box %s is truncated\n",
av_fourcc2str(atom.type));
+return AVERROR_INVALIDDATA;
+}
+
+av_assert0(FFABS(constraint_type) <= 1);
+
+switch(constraint_type) {
+case 0: size_fit = atom.size == limit; break;
+case -1: size_fit = atom.size <= limit; break;
+case 1: size_fit = atom.size >= limit; break;
+}
+
+ return !size_fit;
+}
+
static int mov_metadata_track_or_disc_number(MOVContext *c, AVIOContext *pb,
unsigned len, const char *key)
{
--
2.33.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] [PATCH] avformat/mov: add ignore_hoov option to ignore hoov atom
Try to get context from the moov atom when the hoov before moov atom,
because the streams info get a possible incorrect when there have both
hoov and moov atom. So add and ignore_hoov option for try to get
moov context by user.
Signed-off-by: Steven Liu
---
doc/demuxers.texi | 6 ++
libavformat/isom.h | 2 ++
libavformat/mov.c | 14 --
3 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index cab8a7072c..d23c118210 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -660,6 +660,11 @@ to demuxing linearly from the beginning. Default is true.
Ignore any edit list atoms. The demuxer, by default, modifies the stream index
to reflect the
timeline described by the edit list. Default is false.
+@item ignore_hoov
+Ignore hoov atom. The demuxer, by default, use hoov atom when there have hoov
before moov atom.
+You can try ignore hoov atom try the moov atom.
+Default is false.
+
@item advanced_editlist
Modify the stream index to reflect the timeline described by the edit list.
@code{ignore_editlist}
must be set to false for this option to be effective.
diff --git a/libavformat/isom.h b/libavformat/isom.h
index ef8f19b18c..6aa2b40c94 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -255,6 +255,7 @@ typedef struct MOVContext {
AVFormatContext *fc;
int time_scale;
int64_t duration; ///< duration of the longest track
+int found_hoov; ///< 'hoov' atom has been found
int found_moov; ///< 'moov' atom has been found
int found_mdat; ///< 'mdat' atom has been found
int found_hdlr_mdta; ///< 'hdlr' atom with type 'mdta' has been found
@@ -273,6 +274,7 @@ typedef struct MOVContext {
unsigned int nb_chapter_tracks;
int use_absolute_path;
int ignore_editlist;
+int ignore_hoov;
int advanced_editlist;
int ignore_chapters;
int seek_individually;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2aed6e80ef..cd775b219f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1159,8 +1159,11 @@ static int mov_read_moov(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
if (c->found_moov) {
av_log(c->fc, AV_LOG_WARNING, "Found duplicated MOOV Atom. Skipped
it\n");
-avio_skip(pb, atom.size);
-return 0;
+if (!c->found_hoov) {
+avio_skip(pb, atom.size);
+return 0;
+}
+c->found_hoov = 0;
}
if ((ret = mov_read_default(c, pb, atom)) < 0)
@@ -4239,6 +4242,9 @@ static int mov_read_trak(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
MOVStreamContext *sc;
int ret;
+if (c->found_hoov)
+return 0;
+
st = avformat_new_stream(c->fc, NULL);
if (!st) return AVERROR(ENOMEM);
st->id = -1;
@@ -7329,6 +7335,8 @@ static int mov_read_default(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
a.size >= 8 &&
c->fc->strict_std_compliance < FF_COMPLIANCE_STRICT) {
uint32_t type;
+if (c->ignore_hoov)
+c->found_hoov = 1;
avio_skip(pb, 4);
type = avio_rl32(pb);
if (avio_feof(pb))
@@ -8541,6 +8549,8 @@ static const AVOption mov_options[] = {
0, 1, FLAGS},
{"ignore_editlist", "Ignore the edit list atom.", OFFSET(ignore_editlist),
AV_OPT_TYPE_BOOL, {.i64 = 0},
0, 1, FLAGS},
+{"ignore_hoov", "Ignore the hoov atom.", OFFSET(ignore_hoov),
AV_OPT_TYPE_BOOL, {.i64 = 0},
+0, 1, FLAGS},
{"advanced_editlist",
"Modify the AVIndex according to the editlists. Use this option to
decode in the order specified by the edits.",
OFFSET(advanced_editlist), AV_OPT_TYPE_BOOL, {.i64 = 1},
--
2.25.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] FATE failures due to 88d804b7ffa
Multiple FATE tests are failing due to 88d804b7ffa20caab2e8e2809da974c41f7fd8fc swscale: add P210/P410/P216/P416 output See https://patchwork.ffmpeg.org/project/ffmpeg/patch/20211217001215.75135-10-rco...@rcombs.me/ Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v7 01/12] avdevice/dshow: prevent NULL access
On 2021-12-23 10:39 am, Roger Pack wrote:
These LGTM, could someone apply them for me?
Thanks!
Tomorrow, if no else does, or objects.
On Tue, Dec 21, 2021 at 6:54 AM Diederick Niehorster wrote:
list_options true would crash when both a video and an audio device were
specified as input. Crash would occur on line 784 because
ctx->device_unique_name[otherDevType] would be NULL
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index ef78781865..cc0bef0474 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -708,9 +708,9 @@ dshow_list_device_options(AVFormatContext *avctx,
ICreateDevEnum *devenum,
if ((r = dshow_cycle_devices(avctx, devenum, devtype, sourcetype,
_filter, _unique_name)) < 0)
return r;
ctx->device_filter[devtype] = device_filter;
+ctx->device_unique_name[devtype] = device_unique_name;
if ((r = dshow_cycle_pins(avctx, devtype, sourcetype, device_filter, NULL))
< 0)
return r;
-av_freep(_unique_name);
return 0;
}
@@ -1143,6 +1143,7 @@ static int dshow_read_header(AVFormatContext *avctx)
}
}
}
+// don't exit yet, allow it to list crossbar options in
dshow_open_device
}
if (ctx->device_name[VideoDevice]) {
if ((r = dshow_open_device(avctx, devenum, VideoDevice,
VideoSourceDevice)) < 0 ||
--
2.28.0.windows.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 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 v7 01/12] avdevice/dshow: prevent NULL access
These LGTM, could someone apply them for me?
Thanks!
On Tue, Dec 21, 2021 at 6:54 AM Diederick Niehorster wrote:
>
> list_options true would crash when both a video and an audio device were
> specified as input. Crash would occur on line 784 because
> ctx->device_unique_name[otherDevType] would be NULL
>
> Signed-off-by: Diederick Niehorster
> ---
> libavdevice/dshow.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
> index ef78781865..cc0bef0474 100644
> --- a/libavdevice/dshow.c
> +++ b/libavdevice/dshow.c
> @@ -708,9 +708,9 @@ dshow_list_device_options(AVFormatContext *avctx,
> ICreateDevEnum *devenum,
> if ((r = dshow_cycle_devices(avctx, devenum, devtype, sourcetype,
> _filter, _unique_name)) < 0)
> return r;
> ctx->device_filter[devtype] = device_filter;
> +ctx->device_unique_name[devtype] = device_unique_name;
> if ((r = dshow_cycle_pins(avctx, devtype, sourcetype, device_filter,
> NULL)) < 0)
> return r;
> -av_freep(_unique_name);
> return 0;
> }
>
> @@ -1143,6 +1143,7 @@ static int dshow_read_header(AVFormatContext *avctx)
> }
> }
> }
> +// don't exit yet, allow it to list crossbar options in
> dshow_open_device
> }
> if (ctx->device_name[VideoDevice]) {
> if ((r = dshow_open_device(avctx, devenum, VideoDevice,
> VideoSourceDevice)) < 0 ||
> --
> 2.28.0.windows.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 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] [RFC PATCH] vf_fps: Requantize pts of CFR videos
On Wed, 2021-12-22 at 21:57 -0500, Calvin Walton wrote: > > If you could provide the logs from the fps filter at 'verbose' log > level for the initial segment of the file (first ~1 second of so) > that > would provide helpful information. I said "verbose", but I meant "debug" here :/ -- Calvin Walton ___ 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] [RFC PATCH] vf_fps: Requantize pts of CFR videos
On Wed, 2021-12-22 at 23:04 +0100, Michael Niedermayer wrote: > On Wed, Dec 22, 2021 at 11:20:26AM -0500, Calvin Walton wrote: > > This is mostly to avoid oddities in small framerate adjustments > > when you > > have input videos from containers such as matroska, where the pts > > values > > are quantized with a large enough error to cause issues. > > > > breaks a 60fps 1/6 timebase input downconverted with -vf fps=30:- > 0.01 > the expected result is identical to -vf fps=30 but > > -i 60fps.mov -bitexact -vf fps=30:-0.01 -t 2 -v 99 fps.flv > the expected output is that either all odd or all even frames are > returned but > its a mix after this patch > I cannot share the input file but this should reproduce with any > 60fps > input i hope. If not say so and ill try to find some other file that > shows this I'll take a look at this. Hopefully I can reproduce it with an artificially created file (if so, I'll make a test). If you could provide the logs from the fps filter at 'verbose' log level for the initial segment of the file (first ~1 second of so) that would provide helpful information. It's possible that the reason you're having a problem with fps=30:-0.01 is that I'm applying the start offset in the wrong position in the conversion; I'll try moving it around. -- Calvin Walton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V2] libavutil/hwcontext_qsv: clean padding when upload qsv frames
Fix #7830
When we upload a frame that is not padded as MSDK requires, we create a
new AVFrame to copy data. The frame's padding data is uninitialized so
it brings run to run problem. For example, If we run the following
command serveral times we will get different outputs.
ffmpeg -init_hw_device qsv=qsv:hw -qsv_device /dev/dri/renderD128 \
-filter_hw_device qsv -f rawvideo -s 192x200 -pix_fmt p010 \
-i 192x200_P010.yuv -vf "format=nv12,hwupload=extra_hw_frames=16" \
-c:v hevc_qsv output.265
According to
https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.md#encoding-procedures
"Note: It is the application's responsibility to fill pixels outside
of crop window when it is smaller than frame to be encoded. Especially
in cases when crops are not aligned to minimum coding block size (16
for AVC, 8 for HEVC and VP9)"
I add a function to fill padding area with border pixel to fix this
run2run problem, and also move the new AVFrame to global structure
to reduce redundant allocation operation to increase preformance.
Signed-off-by: Wenbin Chen
---
libavutil/hwcontext_qsv.c | 96 +--
1 file changed, 83 insertions(+), 13 deletions(-)
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index a5d154a24d..853fb7f60d 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -47,6 +47,7 @@
#include "pixfmt.h"
#include "pixdesc.h"
#include "time.h"
+#include "imgutils.h"
#define QSV_VERSION_ATLEAST(MAJOR, MINOR) \
(MFX_VERSION_MAJOR > (MAJOR) || \
@@ -90,6 +91,7 @@ typedef struct QSVFramesContext {
mfxExtOpaqueSurfaceAlloc opaque_alloc;
mfxExtBuffer *ext_buffers[1];
+AVFrame realigned_tmp_frame;
} QSVFramesContext;
static const struct {
@@ -137,6 +139,54 @@ static uint32_t qsv_get_d3d11va_bind_flags(int mem_type)
}
#endif
+static int qsv_fill_border(AVFrame *dst, const AVFrame *src)
+{
+const AVPixFmtDescriptor *desc;
+int i, planes_nb = 0;
+if (dst->format != src->format)
+return AVERROR(EINVAL);
+
+desc = av_pix_fmt_desc_get(dst->format);
+
+for (i = 0; i < desc->nb_components; i++)
+planes_nb = FFMAX(planes_nb, desc->comp[i].plane + 1);
+
+for (i = 0; i < planes_nb; i++) {
+int sheight, dheight, y;
+ptrdiff_t swidth = av_image_get_linesize(src->format,
+ src->width,
+ i);
+ptrdiff_t dwidth = av_image_get_linesize(dst->format,
+ dst->width,
+ i);
+const AVComponentDescriptor comp = desc->comp[i];
+if (swidth < 0 || dwidth < 0) {
+av_log(NULL, AV_LOG_ERROR, "av_image_get_linesize failed\n");
+return AVERROR(EINVAL);
+}
+sheight = src->height;
+dheight = dst->height;
+if (i) {
+sheight = AV_CEIL_RSHIFT(src->height, desc->log2_chroma_h);
+dheight = AV_CEIL_RSHIFT(dst->height, desc->log2_chroma_h);
+}
+//fill right padding
+for (y = 0; y < sheight; y++) {
+void *line_ptr = dst->data[i] + y*dst->linesize[i] + swidth;
+av_memcpy_backptr(line_ptr,
+ comp.depth > 8 ? 2 : 1,
+ dwidth - swidth);
+}
+//fill bottom padding
+for (y = sheight; y < dheight; y++) {
+memcpy(dst->data[i]+y*dst->linesize[i],
+ dst->data[i]+(sheight-1)*dst->linesize[i],
+ dwidth);
+}
+}
+return 0;
+}
+
static int qsv_device_init(AVHWDeviceContext *ctx)
{
AVQSVDeviceContext *hwctx = ctx->hwctx;
@@ -220,6 +270,7 @@ static void qsv_frames_uninit(AVHWFramesContext *ctx)
av_freep(>surface_ptrs);
av_freep(>surfaces_internal);
av_freep(>handle_pairs_internal);
+av_frame_unref(>realigned_tmp_frame);
av_buffer_unref(>child_frames_ref);
}
@@ -1014,12 +1065,13 @@ static int qsv_transfer_data_to(AVHWFramesContext *ctx,
AVFrame *dst,
QSVFramesContext *s = ctx->internal->priv;
mfxFrameSurface1 in = {{ 0 }};
mfxFrameSurface1 *out = (mfxFrameSurface1*)dst->data[3];
+mfxFrameInfo tmp_info;
mfxSyncPoint sync = NULL;
mfxStatus err;
int ret = 0;
/* make a copy if the input is not padded as libmfx requires */
-AVFrame tmp_frame;
+AVFrame *tmp_frame = >realigned_tmp_frame;
const AVFrame *src_frame;
int realigned = 0;
@@ -1048,24 +1100,40 @@ static int qsv_transfer_data_to(AVHWFramesContext *ctx,
AVFrame *dst,
if (ret < 0)
return ret;
+/* According to MSDK spec for mfxframeinfo, "Width must be a multiple of
16.
+ * Height must be a multiple of 16 for progressive frame sequence and a
+ * multiple of 32 otherwise.", so allign all frames to 16 before
uploading. */
if (src->height
Re: [FFmpeg-devel] [PATCH] libavutil/hwcontext_qsv: clean padding when upload qsv frames
On Tue, 2021-12-14 at 05:53 +, Eoff, Ullysses A wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Chen,
> > Wenbin
> > Sent: Monday, December 13, 2021 6:24 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH] libavutil/hwcontext_qsv: clean padding
> > when upload qsv frames
> >
> > > On Thu, 2021-12-02 at 15:40 +0800, Wenbin Chen wrote:
> > > > When we upload a frame that is not padded as MSDK requires, we create a
> > > > new AVFrame to copy data. The frame's padding data is uninitialized so
> > > > it brings run to run problem. For example, If we run the following
> > > > command serveral times we will get different outputs.
> > > >
> > > > ffmpeg -init_hw_device qsv=qsv:hw -qsv_device /dev/dri/renderD128
> > > > -filter_hw_device qsv -f rawvideo -s 192x200 -pix_fmt p010
> > > > -i 192x200_P010.yuv -vf "format=nv12,hwupload=extra_hw_frames=16"
> > > > -c:v hevc_qsv output.265
> > > >
> > > > According to
> > > > https://github.com/Intel-Media-
> > >
> > > SDK/MediaSDK/blob/master/doc/mediasdk-man.md#encoding-procedures
> > > > "Note: It is the application's responsibility to fill pixels outside
> > > > of crop window when it is smaller than frame to be encoded. Especially
> > > > in cases when crops are not aligned to minimum coding block size (16
> > > > for AVC, 8 for HEVC and VP9)"
> > > >
> > > > I add a function to fill padding area with border pixel to fix this
> > > > run2run problem, and also move the new AVFrame to global structure
> > > > to reduce redundant allocation operation to increase preformance.
> > > >
> > > > Signed-off-by: Wenbin Chen
> > > > ---
> > > > libavutil/hwcontext_qsv.c | 96 +-
> > >
> > > -
> > > > 1 file changed, 83 insertions(+), 13 deletions(-)
> > > >
> > > > diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> > > > index 268be9f8a1..983494666b 100644
> > > > --- a/libavutil/hwcontext_qsv.c
> > > > +++ b/libavutil/hwcontext_qsv.c
> > > > @@ -47,6 +47,7 @@
> > > > #include "pixfmt.h"
> > > > #include "pixdesc.h"
> > > > #include "time.h"
> > > > +#include "imgutils.h"
> > > >
> > > > #define QSV_VERSION_ATLEAST(MAJOR, MINOR) \
> > > > (MFX_VERSION_MAJOR > (MAJOR) || \
> > > > @@ -90,6 +91,7 @@ typedef struct QSVFramesContext {
> > > >
> > > > mfxExtOpaqueSurfaceAlloc opaque_alloc;
> > > > mfxExtBuffer *ext_buffers[1];
> > > > +AVFrame realigned_tmp_frame;
> > > > } QSVFramesContext;
> > > >
> > > > static const struct {
> > > > @@ -137,6 +139,54 @@ static uint32_t qsv_get_d3d11va_bind_flags(int
> > >
> > > mem_type)
> > > > }
> > > > #endif
> > > >
> > > > +static int qsv_fill_border(AVFrame *dst, const AVFrame *src)
> > > > +{
> > > > +const AVPixFmtDescriptor *desc;
> > > > +int i, planes_nb = 0;
> > > > +if (dst->format != src->format)
> > > > +return AVERROR(EINVAL);
> > > > +
> > > > +desc = av_pix_fmt_desc_get(dst->format);
> > > > +
> > > > +for (i = 0; i < desc->nb_components; i++)
> > > > +planes_nb = FFMAX(planes_nb, desc->comp[i].plane + 1);
> > > > +
> > > > +for (i = 0; i < planes_nb; i++) {
> > > > +int sheight, dheight, y;
> > > > +ptrdiff_t swidth = av_image_get_linesize(src->format,
> > > > + src->width,
> > > > + i);
> > > > +ptrdiff_t dwidth = av_image_get_linesize(dst->format,
> > > > + dst->width,
> > > > + i);
> > > > +const AVComponentDescriptor comp = desc->comp[i];
> > > > +if (swidth < 0 || dwidth < 0) {
> > > > +av_log(NULL, AV_LOG_ERROR, "av_image_get_linesize
> > > > failed\n");
> > > > +return AVERROR(EINVAL);
> > > > +}
> > > > +sheight = src->height;
> > > > +dheight = dst->height;
> > > > +if (i) {
> > > > +sheight = AV_CEIL_RSHIFT(src->height, desc->log2_chroma_h);
> > > > +dheight = AV_CEIL_RSHIFT(dst->height, desc->log2_chroma_h);
> > > > +}
> > > > +//fill right padding
> > > > +for (y = 0; y < sheight; y++) {
> > > > +void *line_ptr = dst->data[i] + y*dst->linesize[i] +
> > > > swidth;
> > > > +av_memcpy_backptr(line_ptr,
> > > > + comp.depth > 8 ? 2 : 1,
> > > > + dwidth - swidth);
> > > > +}
> > > > +//fill bottom padding
> > > > +for (y = sheight; y < dheight; y++) {
> > > > +memcpy(dst->data[i]+y*dst->linesize[i],
> > > > + dst->data[i]+(sheight-1)*dst->linesize[i],
> > > > + dwidth);
> > > > +}
> > > > +}
> > > > +return 0;
> > > > +}
> > > > +
> > > > static int qsv_device_init(AVHWDeviceContext *ctx)
> > > > {
> > > >
[FFmpeg-devel] GitHub Integration
Hi, holidays are approaching and I got a little present for all of you even though it won’t be something for everybody. A while ago I had committed to prepare a test setup for integrating GitHub in a similar way as the Git developers are doing. For those who missed it or don’t remember the outcome: https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123329.html https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123288.html Before someone’s temperature might start rising, I want to repeat some important corner points: - it's not a migration nor the start of a migration - nothing changes, it doesn't affect anybody's way of working it doesn't replace anything - it's an add-on that one could use or not Basic functionality is that it allows to submit patches to the ML through GitHub pull requests. Right now must features are working, but e-mails are not sent to the ML yet, just to one's own e-mail address. I don't want to post the repository location publicly at this time, but for anybody who would be interested in taking a look at this, please send me an e-mail or PM me on IRC. Kind regards, 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 v2 3/3] avformat: remove unused v210.c
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/v210.c | 123 -
1 file changed, 123 deletions(-)
delete mode 100644 libavformat/v210.c
diff --git a/libavformat/v210.c b/libavformat/v210.c
deleted file mode 100644
index 24f71d4..000
--- a/libavformat/v210.c
+++ /dev/null
@@ -1,123 +0,0 @@
-/*
- * Raw v210 video demuxer
- * Copyright (c) 2015 Tiancheng "Timothy" Gu
- *
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * FFmpeg is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with FFmpeg; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
- */
-
-#include "libavutil/imgutils.h"
-#include "libavutil/parseutils.h"
-#include "libavutil/pixdesc.h"
-#include "libavutil/opt.h"
-#include "internal.h"
-#include "avformat.h"
-
-typedef struct V210DemuxerContext {
-const AVClass *class; /**< Class for private options. */
-int width, height;/**< Integers describing video size, set by a
private option. */
-AVRational framerate; /**< AVRational describing framerate, set by a
private option. */
-} V210DemuxerContext;
-
-// v210 frame width is padded to multiples of 48
-#define GET_PACKET_SIZE(w, h) (((w + 47) / 48) * 48 * h * 8 / 3)
-
-static int v210_read_header(AVFormatContext *ctx)
-{
-V210DemuxerContext *s = ctx->priv_data;
-AVStream *st;
-int ret;
-
-st = avformat_new_stream(ctx, NULL);
-if (!st)
-return AVERROR(ENOMEM);
-
-st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
-
-st->codecpar->codec_id = ctx->iformat->raw_codec_id;
-
-avpriv_set_pts_info(st, 64, s->framerate.den, s->framerate.num);
-
-ret = av_image_check_size(s->width, s->height, 0, ctx);
-if (ret < 0)
-return ret;
-st->codecpar->width= s->width;
-st->codecpar->height = s->height;
-st->codecpar->format = ctx->iformat->raw_codec_id == AV_CODEC_ID_V210 ?
- AV_PIX_FMT_YUV422P10 : AV_PIX_FMT_YUV422P16;
-ctx->packet_size = GET_PACKET_SIZE(s->width, s->height);
-st->codecpar->bit_rate = av_rescale_q(ctx->packet_size,
- (AVRational){8,1}, st->time_base);
-
-return 0;
-}
-
-
-static int v210_read_packet(AVFormatContext *s, AVPacket *pkt)
-{
-int ret;
-
-ret = av_get_packet(s->pb, pkt, s->packet_size);
-pkt->pts = pkt->dts = pkt->pos / s->packet_size;
-
-pkt->stream_index = 0;
-if (ret < 0)
-return ret;
-return 0;
-}
-
-#define OFFSET(x) offsetof(V210DemuxerContext, x)
-#define DEC AV_OPT_FLAG_DECODING_PARAM
-static const AVOption v210_options[] = {
-{ "video_size", "set frame size", OFFSET(width), AV_OPT_TYPE_IMAGE_SIZE,
{.str = NULL}, 0, 0, DEC },
-{ "framerate", "set frame rate", OFFSET(framerate),
AV_OPT_TYPE_VIDEO_RATE, {.str = "25"}, 0, INT_MAX, DEC },
-{ NULL },
-};
-
-static const AVClass v210_demuxer_class = {
-.class_name = "v210(x) demuxer",
-.item_name = av_default_item_name,
-.option = v210_options,
-.version= LIBAVUTIL_VERSION_INT,
-};
-
-#if CONFIG_V210_DEMUXER
-const AVInputFormat ff_v210_demuxer = {
-.name = "v210",
-.long_name = NULL_IF_CONFIG_SMALL("Uncompressed 4:2:2 10-bit"),
-.priv_data_size = sizeof(V210DemuxerContext),
-.read_header= v210_read_header,
-.read_packet= v210_read_packet,
-.flags = AVFMT_GENERIC_INDEX,
-.extensions = "v210",
-.raw_codec_id = AV_CODEC_ID_V210,
-.priv_class = _demuxer_class,
-};
-#endif // CONFIG_V210_DEMUXER
-
-#if CONFIG_V210X_DEMUXER
-const AVInputFormat ff_v210x_demuxer = {
-.name = "v210x",
-.long_name = NULL_IF_CONFIG_SMALL("Uncompressed 4:2:2 10-bit"),
-.priv_data_size = sizeof(V210DemuxerContext),
-.read_header= v210_read_header,
-.read_packet= v210_read_packet,
-.flags = AVFMT_GENERIC_INDEX,
-.extensions = "yuv10",
-.raw_codec_id = AV_CODEC_ID_V210X,
-.priv_class = _demuxer_class,
-};
-#endif // CONFIG_V210X_DEMUXER
--
1.8.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 2/3] avformat: reuse the common code for v210/v210x
From: Limin Wang
As suggested by Andreas Rheinhardt, most code of v210 demuxer is common code
which is duplicated from rawvideodec, so it's better to move v210/v210x
demuxer code to rawvideodec.c and reuse the common code.
Signed-off-by: Limin Wang
---
libavformat/Makefile | 4 ++--
libavformat/rawvideodec.c | 43 +++
2 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 65fb789..14b66e4 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -559,8 +559,8 @@ OBJS-$(CONFIG_TTY_DEMUXER) += tty.o sauce.o
OBJS-$(CONFIG_TY_DEMUXER)+= ty.o
OBJS-$(CONFIG_TXD_DEMUXER) += txd.o
OBJS-$(CONFIG_UNCODEDFRAMECRC_MUXER) += uncodedframecrcenc.o framehash.o
-OBJS-$(CONFIG_V210_DEMUXER) += v210.o
-OBJS-$(CONFIG_V210X_DEMUXER) += v210.o
+OBJS-$(CONFIG_V210_DEMUXER) += rawvideodec.o
+OBJS-$(CONFIG_V210X_DEMUXER) += rawvideodec.o
OBJS-$(CONFIG_VAG_DEMUXER) += vag.o
OBJS-$(CONFIG_VC1_DEMUXER) += rawdec.o vc1dec.o
OBJS-$(CONFIG_VC1_MUXER) += rawenc.o
diff --git a/libavformat/rawvideodec.c b/libavformat/rawvideodec.c
index a2ce423..6ff87a8 100644
--- a/libavformat/rawvideodec.c
+++ b/libavformat/rawvideodec.c
@@ -33,6 +33,8 @@ typedef struct RawVideoDemuxerContext {
AVRational framerate; /**< AVRational describing framerate, set by a
private option. */
} RawVideoDemuxerContext;
+// v210 frame width is padded to multiples of 48
+#define GET_PACKET_SIZE(w, h) (((w + 47) / 48) * 48 * h * 8 / 3)
static int rawvideo_read_header(AVFormatContext *ctx)
{
@@ -85,6 +87,12 @@ static int rawvideo_read_header(AVFormatContext *ctx)
}
st->codecpar->codec_tag = tag;
packet_size = s->width * s->height * pgroup / xinc;
+} else if ((ctx->iformat->raw_codec_id == AV_CODEC_ID_V210) ||
+ (ctx->iformat->raw_codec_id == AV_CODEC_ID_V210X)) {
+pix_fmt = ctx->iformat->raw_codec_id == AV_CODEC_ID_V210 ?
+ AV_PIX_FMT_YUV422P10 : AV_PIX_FMT_YUV422P16;
+
+packet_size = GET_PACKET_SIZE(s->width, s->height);
} else {
packet_size = av_image_get_buffer_size(pix_fmt, s->width, s->height,
1);
if (packet_size < 0)
@@ -161,3 +169,38 @@ const AVInputFormat ff_bitpacked_demuxer = {
.priv_class = _demuxer_class,
};
#endif // CONFIG_BITPACKED_DEMUXER
+
+static const AVClass v210_demuxer_class = {
+.class_name = "v210(x) demuxer",
+.item_name = av_default_item_name,
+.option = rawvideo_options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
+#if CONFIG_V210_DEMUXER
+const AVInputFormat ff_v210_demuxer = {
+.name = "v210",
+.long_name = NULL_IF_CONFIG_SMALL("Uncompressed 4:2:2 10-bit"),
+.priv_data_size = sizeof(RawVideoDemuxerContext),
+.read_header= rawvideo_read_header,
+.read_packet= rawvideo_read_packet,
+.flags = AVFMT_GENERIC_INDEX,
+.extensions = "v210",
+.raw_codec_id = AV_CODEC_ID_V210,
+.priv_class = _demuxer_class,
+};
+#endif // CONFIG_V210_DEMUXER
+
+#if CONFIG_V210X_DEMUXER
+const AVInputFormat ff_v210x_demuxer = {
+.name = "v210x",
+.long_name = NULL_IF_CONFIG_SMALL("Uncompressed 4:2:2 10-bit"),
+.priv_data_size = sizeof(RawVideoDemuxerContext),
+.read_header= rawvideo_read_header,
+.read_packet= rawvideo_read_packet,
+.flags = AVFMT_GENERIC_INDEX,
+.extensions = "yuv10",
+.raw_codec_id = AV_CODEC_ID_V210X,
+.priv_class = _demuxer_class,
+};
+#endif // CONFIG_V210X_DEMUXER
--
1.8.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 1/3] avformat: add bitpacked demuxer
From: Limin Wang
Allows user can playback bitpacked pixel format directly:
ffplay -video_size 1280x720 -pixel_format yuv422p10 test.bitpacked
ffplay -f bitpacked -video_size 1280x720 -pixel_format uyvy422 test.yuv
Signed-off-by: Limin Wang
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/rawvideodec.c | 56 ---
3 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 2b5caf9..65fb789 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -138,6 +138,7 @@ OBJS-$(CONFIG_BINKA_DEMUXER) += binka.o
OBJS-$(CONFIG_BINTEXT_DEMUXER) += bintext.o sauce.o
OBJS-$(CONFIG_BIT_DEMUXER) += bit.o
OBJS-$(CONFIG_BIT_MUXER) += bit.o
+OBJS-$(CONFIG_BITPACKED_DEMUXER) += rawvideodec.o
OBJS-$(CONFIG_BMV_DEMUXER) += bmv.o
OBJS-$(CONFIG_BOA_DEMUXER) += boadec.o
OBJS-$(CONFIG_BFSTM_DEMUXER) += brstm.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 1054ac9..a100639 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -96,6 +96,7 @@ extern const AVInputFormat ff_bink_demuxer;
extern const AVInputFormat ff_binka_demuxer;
extern const AVInputFormat ff_bit_demuxer;
extern const AVOutputFormat ff_bit_muxer;
+extern const AVInputFormat ff_bitpacked_demuxer;
extern const AVInputFormat ff_bmv_demuxer;
extern const AVInputFormat ff_bfstm_demuxer;
extern const AVInputFormat ff_brstm_demuxer;
diff --git a/libavformat/rawvideodec.c b/libavformat/rawvideodec.c
index 5049a29..a2ce423 100644
--- a/libavformat/rawvideodec.c
+++ b/libavformat/rawvideodec.c
@@ -59,10 +59,39 @@ static int rawvideo_read_header(AVFormatContext *ctx)
st->codecpar->width = s->width;
st->codecpar->height = s->height;
+
+if (ctx->iformat->raw_codec_id == AV_CODEC_ID_BITPACKED) {
+unsigned int pgroup; /* size of the pixel group in bytes */
+unsigned int xinc;
+const AVPixFmtDescriptor *desc;
+int tag;
+
+desc = av_pix_fmt_desc_get(pix_fmt);
+st->codecpar->bits_per_coded_sample = av_get_bits_per_pixel(desc);
+if (pix_fmt == AV_PIX_FMT_YUV422P10) {
+tag = MKTAG('U', 'Y', 'V', 'Y');
+pgroup = 5;
+xinc = 2;
+} else if (pix_fmt == AV_PIX_FMT_UYVY422) {
+tag = MKTAG('U', 'Y', 'V', 'Y');
+pgroup = 4;
+xinc = 2;
+pix_fmt = AV_PIX_FMT_UYVY422;
+st->codecpar->codec_id = AV_CODEC_ID_RAWVIDEO;
+} else {
+av_log(ctx, AV_LOG_ERROR, "unsupported format: %s for
bitpacked.\n",
+s->pixel_format);
+return AVERROR(EINVAL);
+}
+st->codecpar->codec_tag = tag;
+packet_size = s->width * s->height * pgroup / xinc;
+} else {
+packet_size = av_image_get_buffer_size(pix_fmt, s->width, s->height,
1);
+if (packet_size < 0)
+return packet_size;
+}
+
st->codecpar->format = pix_fmt;
-packet_size = av_image_get_buffer_size(st->codecpar->format, s->width,
s->height, 1);
-if (packet_size < 0)
-return packet_size;
ctx->packet_size = packet_size;
st->codecpar->bit_rate = av_rescale_q(ctx->packet_size,
(AVRational){8,1}, st->time_base);
@@ -111,3 +140,24 @@ const AVInputFormat ff_rawvideo_demuxer = {
.raw_codec_id = AV_CODEC_ID_RAWVIDEO,
.priv_class = _demuxer_class,
};
+
+static const AVClass bitpacked_demuxer_class = {
+.class_name = "bitpacked demuxer",
+.item_name = av_default_item_name,
+.option = rawvideo_options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
+#if CONFIG_BITPACKED_DEMUXER
+const AVInputFormat ff_bitpacked_demuxer = {
+.name = "bitpacked",
+.long_name = NULL_IF_CONFIG_SMALL("Bitpacked"),
+.priv_data_size = sizeof(RawVideoDemuxerContext),
+.read_header= rawvideo_read_header,
+.read_packet= rawvideo_read_packet,
+.flags = AVFMT_GENERIC_INDEX,
+.extensions = "bitpacked",
+.raw_codec_id = AV_CODEC_ID_BITPACKED,
+.priv_class = _demuxer_class,
+};
+#endif // CONFIG_BITPACKED_DEMUXER
--
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] [RFC PATCH] vf_fps: Requantize pts of CFR videos
On Wed, Dec 22, 2021 at 11:20:26AM -0500, Calvin Walton wrote: > This is mostly to avoid oddities in small framerate adjustments when you > have input videos from containers such as matroska, where the pts values > are quantized with a large enough error to cause issues. > > An example, when converting from 24/1.001 fps to 24 fps with round=down > from an mkv source (inlink time base is 1/1000, outlink is 1001/24000): > > In PTS | Out PTS | Rounded Out PTS > 69292 | 1663.008 | 1663 > 69333 | 1663.992 | 1663 > 69375 | 1665.000 | 1665 > > In this example, the fps filter would drop the frame with pts 69292, > then duplicate the frame with pts 69333, an undesirable result. > > By first requantizing the input pts to the inlink frame rate, the result > looks much nicer: > > In PTS | Req. PTS | Out PTS > 69292| 1661 | 1662 > 69333 | 1662 | 1663 > 69375 | 1663 | 1664 > > (Note that the same rounding mode is used for both conversions, > resulting in the final out pts being a bit lower in this case. With the > normal nearest mode, it would be closer.) > > I've verified that in conversions of longer mkv files to "close" > framerates that previously had issues due to quantization, this > significantly reduces the number of incorrectly dropped or duplicated > frames. > > The potential downside of this change is that if an input file is > probed as CFR but is actually VFR, then the results will be poor > (you'll get unnecessarily dropped frames or added judder). A new > option, "requantize", is added to allow disabling this behaviour in > those cases. > > Signed-off-by: Calvin Walton > > --- > libavfilter/vf_fps.c | 48 +--- > 1 file changed, 41 insertions(+), 7 deletions(-) breaks a 60fps 1/6 timebase input downconverted with -vf fps=30:-0.01 the expected result is identical to -vf fps=30 but -i 60fps.mov -bitexact -vf fps=30:-0.01 -t 2 -v 99 fps.flv the expected output is that either all odd or all even frames are returned but its a mix after this patch I cannot share the input file but this should reproduce with any 60fps input i hope. If not say so and ill try to find some other file that shows this thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- 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 v2 2/2] avformat/mov: validate box size for stts
On Wed, Dec 22, 2021 at 06:17:28PM +0530, Gyan Doshi wrote:
> ---
> libavformat/mov.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 7de95b7ab0..1e44c74944 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -2969,6 +2969,12 @@ static int mov_read_stts(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> avio_rb24(pb); /* flags */
> entries = avio_rb32(pb);
>
> +if (validate_box_size(c, atom, pb, avio_tell(pb)-8,
> 8+(int64_t)entries*8, 0)) {
> +av_log(c->fc, AV_LOG_ERROR, "Invalid or incomplete %s box in stream
> %d\n",
> + av_fourcc2str(atom.type), c->fc->nb_streams-1);
> + return AVERROR_INVALIDDATA;
> +}
> +
> av_log(c->fc, AV_LOG_TRACE, "track[%u].stts.entries = %u\n",
> c->fc->nb_streams-1, entries);
>
this breaks playback of
./ffplay H263_NM_f.mp4
i presume its this file here:
https://samples.ffmpeg.org/F4V/H263_NM_f.mp4
thx
[...]
--
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] Politics
> -Original Message- > From: ffmpeg-devel On Behalf Of Michael > Niedermayer > Sent: Wednesday, December 22, 2021 8:54 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] Politics > > On Wed, Dec 22, 2021 at 01:29:04PM +, Soft Works wrote: > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of Michael > > > Niedermayer > > > Sent: Monday, December 20, 2021 4:24 PM > > > To: FFmpeg development discussions and patches > > > Subject: Re: [FFmpeg-devel] Politics > > > > > > I am not sure the direction from which you approuch this is going to > > > increase the chances this patch has. > > > > > > All stream types in libavformat/codec are timebase based, that was > > > done because its exact (for some definition of exact at least) > > > > > > I think you should argue why this is the best way forward not why its > > > not too bad > > > > > > also in a few places where a fixed timebase is used ffmpeg uses > > > AV_TIME_BASE_Q which is micro not milli seconds. That suddenly > > > allows exactly addressing individual frames and audio samples. > > > And it should be easy to change to from ms, its just a *1000 > > > it would weaken the precission argument > > > > For the final chapter of this story, let us return to the original > > subject which I would summarize like: > > > > [...] > > > I think I know better and therefore insist > > on having a higher precision and/or flexible timebase for subtitle > > timings, otherwise I won't accept the patchset" > > I didnt say any of this And you weren't meant at all. (you're actually one of the persons I'm respecting the most) Sorry for the misunderstanding. I should have replied to one of the earlier messages. I thought the fictional quote would make it clear who is meant. > > Let's look at the concern first: The concern is about that with > > a subtitle precision of milliseconds (let's say milli, even > > though we actually have microseconds), it would not be possible > > Not sure i understand you but the code you add to AVFrame says "ms" and > thats milli not micro, > the prefix for micro is the SI system is μ or u if you want ASCII subtitle_pts is AV_TIMEBASE_Q. I had recently suggested to change the other fields (subtitle_start_time and subtitle_end_time to AV_TIMEBASE_Q as well, to have all subtitle timing fields at the same base. Kind regards, 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".
Re: [FFmpeg-devel] [PATCH v9 6/6] lavc/hevcdec: Parse DOVI RPU NALs
Niklas Haas:
> From: Niklas Haas
>
> And expose the parsed values as frame side data. Update FATE results to
> match.
>
> It's worth documenting that this relies on the dovi configuration record
> being present on the first AVPacket fed to the decoder, which in
> practice is the case if if the API user has called something like
> av_format_inject_global_side_data, which is unfortunately not the
> default.
>
> This commit is not the time and place to change that behavior, though.
>
> Signed-off-by: Niklas Haas
> ---
> configure | 2 +-
> libavcodec/hevcdec.c | 63 +--
> libavcodec/hevcdec.h | 3 +
> tests/ref/fate/hevc-dv-rpu | 224 +
> 4 files changed, 283 insertions(+), 9 deletions(-)
>
> diff --git a/configure b/configure
> index 68658a847f..7803aa47af 100755
> --- a/configure
> +++ b/configure
> @@ -2826,7 +2826,7 @@ h264_decoder_suggest="error_resilience"
> hap_decoder_select="snappy texturedsp"
> hap_encoder_deps="libsnappy"
> hap_encoder_select="texturedspenc"
> -hevc_decoder_select="atsc_a53 bswapdsp cabac golomb hevcparse videodsp"
> +hevc_decoder_select="atsc_a53 bswapdsp cabac dovi_rpu golomb hevcparse
> videodsp"
> huffyuv_decoder_select="bswapdsp huffyuvdsp llviddsp"
> huffyuv_encoder_select="bswapdsp huffman huffyuvencdsp llvidencdsp"
> hymt_decoder_select="huffyuv_decoder"
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index 46d9edf8eb..298d89fea6 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -2723,6 +2723,7 @@ error:
> static int set_side_data(HEVCContext *s)
> {
> AVFrame *out = s->ref->frame;
> +int ret;
>
> if (s->sei.frame_packing.present &&
> s->sei.frame_packing.arrangement_type >= 3 &&
> @@ -2967,6 +2968,9 @@ static int set_side_data(HEVCContext *s)
> s->rpu_buf = NULL;
> }
>
> +if ((ret = ff_dovi_attach_side_data(>dovi_ctx, out)) < 0)
> +return ret;
> +
> return 0;
> }
>
> @@ -3298,16 +3302,24 @@ static int decode_nal_units(HEVCContext *s, const
> uint8_t *buf, int length)
> if (s->pkt.nb_nals > 1 && s->pkt.nals[s->pkt.nb_nals - 1].type ==
> HEVC_NAL_UNSPEC62 &&
> s->pkt.nals[s->pkt.nb_nals - 1].size > 2 &&
> !s->pkt.nals[s->pkt.nb_nals - 1].nuh_layer_id
> && !s->pkt.nals[s->pkt.nb_nals - 1].temporal_id) {
> +H2645NAL *nal = >pkt.nals[s->pkt.nb_nals - 1];
> if (s->rpu_buf) {
> av_buffer_unref(>rpu_buf);
> av_log(s->avctx, AV_LOG_WARNING, "Multiple Dolby Vision RPUs
> found in one AU. Skipping previous.\n");
> }
>
> -s->rpu_buf = av_buffer_alloc(s->pkt.nals[s->pkt.nb_nals -
> 1].raw_size - 2);
> +s->rpu_buf = av_buffer_alloc(nal->raw_size - 2);
> if (!s->rpu_buf)
> return AVERROR(ENOMEM);
> +memcpy(s->rpu_buf->data, nal->raw_data + 2, nal->raw_size - 2);
>
> -memcpy(s->rpu_buf->data, s->pkt.nals[s->pkt.nb_nals - 1].raw_data +
> 2, s->pkt.nals[s->pkt.nb_nals - 1].raw_size - 2);
> +s->dovi_ctx.config = s->dovi_cfg ? (void *) s->dovi_cfg->data : NULL;
> +ret = ff_dovi_rpu_parse(>dovi_ctx, nal->data + 2, nal->size - 2);
> +if (ret < 0) {
> +av_buffer_unref(>rpu_buf);
> +av_log(s->avctx, AV_LOG_WARNING, "Error parsing DOVI NAL
> unit.\n");
> +/* ignore */
> +}
> }
>
> /* decode the NAL units */
> @@ -3440,8 +3452,8 @@ static int hevc_decode_frame(AVCodecContext *avctx,
> void *data, int *got_output,
> AVPacket *avpkt)
> {
> int ret;
> -size_t new_extradata_size;
> -uint8_t *new_extradata;
> +uint8_t *sd;
> +size_t sd_size;
> HEVCContext *s = avctx->priv_data;
>
> if (!avpkt->size) {
> @@ -3453,14 +3465,37 @@ static int hevc_decode_frame(AVCodecContext *avctx,
> void *data, int *got_output,
> return 0;
> }
>
> -new_extradata = av_packet_get_side_data(avpkt, AV_PKT_DATA_NEW_EXTRADATA,
> -_extradata_size);
> -if (new_extradata && new_extradata_size > 0) {
> -ret = hevc_decode_extradata(s, new_extradata, new_extradata_size, 0);
> +sd = av_packet_get_side_data(avpkt, AV_PKT_DATA_NEW_EXTRADATA, _size);
> +if (sd && sd_size > 0) {
> +ret = hevc_decode_extradata(s, sd, sd_size, 0);
> if (ret < 0)
> return ret;
> }
>
> +sd = av_packet_get_side_data(avpkt, AV_PKT_DATA_DOVI_CONF, _size);
> +if (sd && sd_size > 0) {
> +if (s->dovi_cfg) {
> +/* Reuse existing buffer */
> +if ((ret = av_buffer_make_writable(>dovi_cfg)) < 0)
> +return ret;
> +} else {
> +/* Allocate new buffer */
> +AVDOVIDecoderConfigurationRecord *cfg;
> +size_t cfg_size;
> +cfg = av_dovi_alloc(_size);
> +if (!cfg)
> +
Re: [FFmpeg-devel] Politics
On Wed, Dec 22, 2021 at 01:29:04PM +, Soft Works wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of Michael > > Niedermayer > > Sent: Monday, December 20, 2021 4:24 PM > > To: FFmpeg development discussions and patches > > Subject: Re: [FFmpeg-devel] Politics > > > > I am not sure the direction from which you approuch this is going to > > increase the chances this patch has. > > > > All stream types in libavformat/codec are timebase based, that was > > done because its exact (for some definition of exact at least) > > > > I think you should argue why this is the best way forward not why its > > not too bad > > > > also in a few places where a fixed timebase is used ffmpeg uses > > AV_TIME_BASE_Q which is micro not milli seconds. That suddenly > > allows exactly addressing individual frames and audio samples. > > And it should be easy to change to from ms, its just a *1000 > > it would weaken the precission argument > > For the final chapter of this story, let us return to the original > subject which I would summarize like: > [...] > I think I know better and therefore insist > on having a higher precision and/or flexible timebase for subtitle > timings, otherwise I won't accept the patchset" I didnt say any of this what is the case is that FFmpeg tries to use flexible timebases for everything. And also we try to be exact I have said nothing about accepting or rejecting this patchset, nor have i really made my mind up on how i would vote if it comes to a vote. What i have made my mind up on is that if someone replaces these timestamps with higher precission or exact ones i would support it. Also i do want someone to work on and improve subtitles in FFmpeg. iam not your oponent here. I do want you to stay and continue to contribute. But the area you picked certainly is one where people have strong oppinions and its a big change as well. I would suggest to keep a cool head and not give up yet. Find out exatly what the people who objected want and if you can find some compromise that makes everyone ok with it > > Let's look at the concern first: The concern is about that with > a subtitle precision of milliseconds (let's say milli, even > though we actually have microseconds), it would not be possible Not sure i understand you but the code you add to AVFrame says "ms" and thats milli not micro, the prefix for micro is the SI system is μ or u if you want ASCII [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA 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] 5.0 release
On Wed, 22 Dec 2021, at 15:05, James Almer wrote: > Is the December target to get into the feature freeze schedule from > distros? No, it was set by me, in order to get the distro freezes from January. We can miss the target a bit this year, and then make it better for 2022. BEst,. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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] [RFC PATCH] vf_fps: Requantize pts of CFR videos
This is mostly to avoid oddities in small framerate adjustments when you
have input videos from containers such as matroska, where the pts values
are quantized with a large enough error to cause issues.
An example, when converting from 24/1.001 fps to 24 fps with round=down
from an mkv source (inlink time base is 1/1000, outlink is 1001/24000):
In PTS | Out PTS | Rounded Out PTS
69292 | 1663.008 | 1663
69333 | 1663.992 | 1663
69375 | 1665.000 | 1665
In this example, the fps filter would drop the frame with pts 69292,
then duplicate the frame with pts 69333, an undesirable result.
By first requantizing the input pts to the inlink frame rate, the result
looks much nicer:
In PTS | Req. PTS | Out PTS
69292 | 1661 | 1662
69333 | 1662 | 1663
69375 | 1663 | 1664
(Note that the same rounding mode is used for both conversions,
resulting in the final out pts being a bit lower in this case. With the
normal nearest mode, it would be closer.)
I've verified that in conversions of longer mkv files to "close"
framerates that previously had issues due to quantization, this
significantly reduces the number of incorrectly dropped or duplicated
frames.
The potential downside of this change is that if an input file is
probed as CFR but is actually VFR, then the results will be poor
(you'll get unnecessarily dropped frames or added judder). A new
option, "requantize", is added to allow disabling this behaviour in
those cases.
Signed-off-by: Calvin Walton
---
libavfilter/vf_fps.c | 48 +---
1 file changed, 41 insertions(+), 7 deletions(-)
diff --git a/libavfilter/vf_fps.c b/libavfilter/vf_fps.c
index 99e679441e..d010083a35 100644
--- a/libavfilter/vf_fps.c
+++ b/libavfilter/vf_fps.c
@@ -74,6 +74,7 @@ typedef struct FPSContext {
char *framerate;///< expression that defines the target framerate
int rounding; ///< AVRounding method for timestamps
int eof_action; ///< action performed for last frame in FIFO
+int requantize; ///< whether to requantize timestamps of cfr inputs
/* Set during outlink configuration */
int64_t in_pts_off;///< input frame pts offset for start_time handling
@@ -111,6 +112,8 @@ static const AVOption fps_options[] = {
{ "eof_action", "action performed for last frame", OFFSET(eof_action),
AV_OPT_TYPE_INT, { .i64 = EOF_ACTION_ROUND }, 0, EOF_ACTION_NB-1, V|F,
"eof_action" },
{ "round", "round similar to other frames", 0, AV_OPT_TYPE_CONST, {
.i64 = EOF_ACTION_ROUND }, 0, 0, V|F, "eof_action" },
{ "pass", "pass through last frame",0, AV_OPT_TYPE_CONST, {
.i64 = EOF_ACTION_PASS }, 0, 0, V|F, "eof_action" },
+{ "requantize", "requantize input timestamps in CFR video based on
framerate",
+ OFFSET(requantize), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, V|F },
{ NULL }
};
@@ -177,6 +180,7 @@ static int config_props(AVFilterLink* outlink)
FPSContext *s = ctx->priv;
double var_values[VARS_NB], res;
+AVRational in_time_base;
int ret;
var_values[VAR_SOURCE_FPS]= av_q2d(inlink->frame_rate);
@@ -193,6 +197,18 @@ static int config_props(AVFilterLink* outlink)
outlink->frame_rate = av_d2q(res, INT_MAX);
outlink->time_base = av_inv_q(outlink->frame_rate);
+/* Disable requantization if input video is VFR */
+if (s->requantize && inlink->frame_rate.num == 1 && inlink->frame_rate.den
== 0) {
+av_log(ctx, AV_LOG_INFO, "Not requantizing input timestamps; video is
VFR\n");
+s->requantize = 0;
+}
+
+in_time_base = inlink->time_base;
+if (s->requantize) {
+in_time_base = av_inv_q(inlink->frame_rate);
+av_log(ctx, AV_LOG_VERBOSE, "Requantizing input timestamps to
time_base=%d/%d\n", in_time_base.num, in_time_base.den);
+}
+
/* Calculate the input and output pts offsets for start_time */
if (s->start_time != DBL_MAX && s->start_time != AV_NOPTS_VALUE) {
double first_pts = s->start_time * AV_TIME_BASE;
@@ -201,7 +217,7 @@ static int config_props(AVFilterLink* outlink)
s->start_time);
return AVERROR(EINVAL);
}
-s->in_pts_off = av_rescale_q_rnd(first_pts, AV_TIME_BASE_Q,
inlink->time_base,
+s->in_pts_off = av_rescale_q_rnd(first_pts, AV_TIME_BASE_Q,
in_time_base,
s->rounding | AV_ROUND_PASS_MINMAX);
s->out_pts_off = av_rescale_q_rnd(first_pts, AV_TIME_BASE_Q,
outlink->time_base,
s->rounding | AV_ROUND_PASS_MINMAX);
@@ -220,7 +236,8 @@ static int read_frame(AVFilterContext *ctx, FPSContext *s,
AVFilterLink *inlink,
{
AVFrame *frame;
int ret;
-int64_t in_pts;
+AVRational in_time_base;
+int64_t orig_pts, in_pts;
/* Must only be called when we have buffer room available */
av_assert1(s->frames_count < 2);
@@ -231,16
[FFmpeg-devel] The case for a good string API
Hi. I will try again proposing a good string API for the project. But this time, instead of showing the implementation code, I will ask about the principle. So, please, read the argument, and give your opinion on the principle. If we agree on the principle, we can discuss the code then. * Why we need a better string API Strings are not the bulk of what we do, but for the user interface of things we have a LOT of functions that return strings: to describe a color space or a channel layout or a set of options. When the returned string is short, we use the good old “char *buf, size_t buf_size”. When it is long, we return a dynamically-allocated buffer. When the string is almost always short but can actually be very long, and the conversion is used in speed-critical code, we are screwed. With a good string API, we could use the same API everywhere, it would automatically use the most efficient memory scheme. Furthermore, if all our object→string functions have the same prototype, it makes it easier to use these functions as standardized callbacks and opens a whole lot of new possibilities of serialization features. Moreover, a good string API would bring quite a few extra benefits, with a few examples: easier to build strings from parts, less verbose and more robust error checking, the ability to use directly the string or buffering API of another library or language. So, even though strings are not the core of our thing, I think we should have a good string API, just like we have an API for efficient FFTs (which is the core of our thing). But let us discuss it further: * Objections and counter-objections - A string API adds complexity. Indeed, that is true. But the added complexity is clearly isolated in one or a few source files. In the rest of the code, it removes complexity (see less verbose error checking, easier to build strings from parts above). String conversion functions can happen once per short frame, for example in the ashowinfo filter. We have pools for frames and for buffers: we already consider that avoid once-per-frame memory allocations is worth the added complexity. A string API is just a step in the same direction. - An unusual API is annoying for people who will use it. Unless we messed up, if they use strings more than just a little, the benefits of the API is way worth the cost of learning. But some people use strings just a little. For them, who would be happy with a plain C string, we should make sure the required learning is very very limited. And we can: “instead of ‘buf, sizeof(buf)’, write ‘string_from_buffer(buf)”. That is all, in one short line I have documented how to use the API with the old patterns. There is a little more to write for people who want a dynamic buffer for an unlimited string (error checks are always annoying), but we can keep it under three minutes. * What string API we should use We have AVBprint, but the API is ugly, and it only brings a few of the benefits I promised. I have a proposal: AVWriter. I posted it last spring, here is an introduction on how to use it (with the implementation in the same thread): https://ffmpeg.org/pipermail/ffmpeg-devel/2021-April/279383.html * Conclusion Well, I am convinced, but what about you? 1. Do you think FFmpeg needs a good string API? If not, please explain why? 2. Assuming we agree ‘yes’ on the previous question, do you think AVWriter is a good candidate? If not, what else would you propose? 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 1/2] avformat/mxf: support MCA audio information
On Wed, Dec 22, 2021 at 4:38 AM Tomas Härdin wrote: > > tis 2021-12-21 klockan 21:24 +0100 skrev Marton Balint: > > > > > > On Tue, 21 Dec 2021, Tomas Härdin wrote: > > > > > tis 2021-12-21 klockan 11:44 +0100 skrev Marc-Antoine ARNAUD: > > > > Le ven. 17 déc. 2021 à 19:12, Marton Balint a > > > > écrit : > > > > > > > > > > > > > > > > > > > On Fri, 17 Dec 2021, Marc-Antoine ARNAUD wrote: > > > > > > > > > > > Hi all, > > > > > > > > > > > > Can I have an update on this patch submission ? > > > > > > Is something required to be done before it can be merged ? > > > > > > > > > > New channel layout API is on its way, which makes in-demuxer > > > > > channel > > > > > reordering uneeded. Therefore the reordering option should not > > > > > be > > > > > added > > > > > as it is in this patch. I can rework the patch after the > > > > > channel > > > > > layout > > > > > API is in. (should happen in a couple of weeks at most). > > > > > > > > > > Regards, > > > > > Marton > > > > > > > > > > > > > So it will happen only after the release 5 of FFMpeg right ? > > > > Not sure. There were people who wanted the merge the channel layout > > api > > before the release. > > > > > > > > > > Is it possible to merge it, and we can rework it after the new > > > > API is > > > > released ? > > > > Patches are related to IMF (new format) patches, and if FFmpeg > > > > can > > > > accept > > > > IMF without MCA support it will generate a lot of errors in audio > > > > mapping. > > > > So even if it's not performant for now, is it possible to imagine > > > > to > > > > merge > > > > patches and rework after ? > > > > > > I suspect this might create problems for the people writing the > > > reordering API > > > > It is not matter of performance, we should not introduce a hack such > > as > > reordering PCM channels in a demuxer if there is a better solution on > > the > > horizon. Yes, it feels like channel reordering should be a framework-level feature and not a per-demuxer feature. What about a roadmap where the channel-reordering-in-MXF patch is scheduled to be merged after some reasonable time (1 month?) if the channel API has not landed by then? This would allow contributors and users to plan ahead. > > > > If this is urgent, we could merge it without reordering support. > > I think we can trust our users to maintain their own forks if they need > special hacks > > /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 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 v9 5/6] fate: Limit Dolby Vision RPU test frame count
From: Niklas Haas To avoid the ref for this growing to a very large size when attaching the parsed RPU side data. Since this sample does not have any dynamic metadata, two frames will serve just as well as 100. Signed-off-by: Niklas Haas --- tests/fate/hevc.mak| 2 +- tests/ref/fate/hevc-dv-rpu | 499 - 2 files changed, 1 insertion(+), 500 deletions(-) diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak index abe4264662..95dcf5bfc5 100644 --- a/tests/fate/hevc.mak +++ b/tests/fate/hevc.mak @@ -273,7 +273,7 @@ FATE_HEVC_FFPROBE-$(call DEMDEC, HEVC, HEVC) += fate-hevc-monochrome-crop fate-hevc-hdr10-plus-metadata: CMD = probeframes -show_entries frame=side_data_list $(TARGET_SAMPLES)/hevc/hdr10_plus_h265_sample.hevc FATE_HEVC_FFPROBE-$(call DEMDEC, HEVC, HEVC) += fate-hevc-hdr10-plus-metadata -fate-hevc-dv-rpu: CMD = probeframes -show_entries frame=side_data_list -select_streams 0 $(TARGET_SAMPLES)/hevc/dv84.mov +fate-hevc-dv-rpu: CMD = probeframes -show_entries frame=side_data_list -select_streams 0 -read_intervals "%+\#2" $(TARGET_SAMPLES)/hevc/dv84.mov FATE_HEVC_FFPROBE-$(call DEMDEC, HEVC, HEVC) += fate-hevc-dv-rpu fate-hevc-two-first-slice: CMD = threads=2 framemd5 -i $(TARGET_SAMPLES)/hevc/two_first_slice.mp4 -sws_flags bitexact -t 00:02.00 -an diff --git a/tests/ref/fate/hevc-dv-rpu b/tests/ref/fate/hevc-dv-rpu index 37ad9ffec2..416d9c51a6 100644 --- a/tests/ref/fate/hevc-dv-rpu +++ b/tests/ref/fate/hevc-dv-rpu @@ -11,502 +11,3 @@ side_data_type=Dolby Vision RPU Data side_data_type=Dolby Vision RPU Data [/SIDE_DATA] [/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=H.26[45] User Data Unregistered SEI message -[/SIDE_DATA] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME] -[SIDE_DATA] -side_data_type=Dolby Vision RPU Data -[/SIDE_DATA] -[/FRAME] -[FRAME]
[FFmpeg-devel] [PATCH v9 6/6] lavc/hevcdec: Parse DOVI RPU NALs
From: Niklas Haas
And expose the parsed values as frame side data. Update FATE results to
match.
It's worth documenting that this relies on the dovi configuration record
being present on the first AVPacket fed to the decoder, which in
practice is the case if if the API user has called something like
av_format_inject_global_side_data, which is unfortunately not the
default.
This commit is not the time and place to change that behavior, though.
Signed-off-by: Niklas Haas
---
configure | 2 +-
libavcodec/hevcdec.c | 63 +--
libavcodec/hevcdec.h | 3 +
tests/ref/fate/hevc-dv-rpu | 224 +
4 files changed, 283 insertions(+), 9 deletions(-)
diff --git a/configure b/configure
index 68658a847f..7803aa47af 100755
--- a/configure
+++ b/configure
@@ -2826,7 +2826,7 @@ h264_decoder_suggest="error_resilience"
hap_decoder_select="snappy texturedsp"
hap_encoder_deps="libsnappy"
hap_encoder_select="texturedspenc"
-hevc_decoder_select="atsc_a53 bswapdsp cabac golomb hevcparse videodsp"
+hevc_decoder_select="atsc_a53 bswapdsp cabac dovi_rpu golomb hevcparse
videodsp"
huffyuv_decoder_select="bswapdsp huffyuvdsp llviddsp"
huffyuv_encoder_select="bswapdsp huffman huffyuvencdsp llvidencdsp"
hymt_decoder_select="huffyuv_decoder"
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 46d9edf8eb..298d89fea6 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2723,6 +2723,7 @@ error:
static int set_side_data(HEVCContext *s)
{
AVFrame *out = s->ref->frame;
+int ret;
if (s->sei.frame_packing.present &&
s->sei.frame_packing.arrangement_type >= 3 &&
@@ -2967,6 +2968,9 @@ static int set_side_data(HEVCContext *s)
s->rpu_buf = NULL;
}
+if ((ret = ff_dovi_attach_side_data(>dovi_ctx, out)) < 0)
+return ret;
+
return 0;
}
@@ -3298,16 +3302,24 @@ static int decode_nal_units(HEVCContext *s, const
uint8_t *buf, int length)
if (s->pkt.nb_nals > 1 && s->pkt.nals[s->pkt.nb_nals - 1].type ==
HEVC_NAL_UNSPEC62 &&
s->pkt.nals[s->pkt.nb_nals - 1].size > 2 &&
!s->pkt.nals[s->pkt.nb_nals - 1].nuh_layer_id
&& !s->pkt.nals[s->pkt.nb_nals - 1].temporal_id) {
+H2645NAL *nal = >pkt.nals[s->pkt.nb_nals - 1];
if (s->rpu_buf) {
av_buffer_unref(>rpu_buf);
av_log(s->avctx, AV_LOG_WARNING, "Multiple Dolby Vision RPUs found
in one AU. Skipping previous.\n");
}
-s->rpu_buf = av_buffer_alloc(s->pkt.nals[s->pkt.nb_nals - 1].raw_size
- 2);
+s->rpu_buf = av_buffer_alloc(nal->raw_size - 2);
if (!s->rpu_buf)
return AVERROR(ENOMEM);
+memcpy(s->rpu_buf->data, nal->raw_data + 2, nal->raw_size - 2);
-memcpy(s->rpu_buf->data, s->pkt.nals[s->pkt.nb_nals - 1].raw_data + 2,
s->pkt.nals[s->pkt.nb_nals - 1].raw_size - 2);
+s->dovi_ctx.config = s->dovi_cfg ? (void *) s->dovi_cfg->data : NULL;
+ret = ff_dovi_rpu_parse(>dovi_ctx, nal->data + 2, nal->size - 2);
+if (ret < 0) {
+av_buffer_unref(>rpu_buf);
+av_log(s->avctx, AV_LOG_WARNING, "Error parsing DOVI NAL unit.\n");
+/* ignore */
+}
}
/* decode the NAL units */
@@ -3440,8 +3452,8 @@ static int hevc_decode_frame(AVCodecContext *avctx, void
*data, int *got_output,
AVPacket *avpkt)
{
int ret;
-size_t new_extradata_size;
-uint8_t *new_extradata;
+uint8_t *sd;
+size_t sd_size;
HEVCContext *s = avctx->priv_data;
if (!avpkt->size) {
@@ -3453,14 +3465,37 @@ static int hevc_decode_frame(AVCodecContext *avctx,
void *data, int *got_output,
return 0;
}
-new_extradata = av_packet_get_side_data(avpkt, AV_PKT_DATA_NEW_EXTRADATA,
-_extradata_size);
-if (new_extradata && new_extradata_size > 0) {
-ret = hevc_decode_extradata(s, new_extradata, new_extradata_size, 0);
+sd = av_packet_get_side_data(avpkt, AV_PKT_DATA_NEW_EXTRADATA, _size);
+if (sd && sd_size > 0) {
+ret = hevc_decode_extradata(s, sd, sd_size, 0);
if (ret < 0)
return ret;
}
+sd = av_packet_get_side_data(avpkt, AV_PKT_DATA_DOVI_CONF, _size);
+if (sd && sd_size > 0) {
+if (s->dovi_cfg) {
+/* Reuse existing buffer */
+if ((ret = av_buffer_make_writable(>dovi_cfg)) < 0)
+return ret;
+} else {
+/* Allocate new buffer */
+AVDOVIDecoderConfigurationRecord *cfg;
+size_t cfg_size;
+cfg = av_dovi_alloc(_size);
+if (!cfg)
+return AVERROR(ENOMEM);
+s->dovi_cfg = av_buffer_create((uint8_t *) cfg, cfg_size, NULL,
NULL, 0);
+if (!s->dovi_cfg) {
+av_free(cfg);
+return AVERROR(ENOMEM);
+}
+}
+
+
[FFmpeg-devel] [PATCH v9 4/6] lavc: Implement Dolby Vision RPU parsing
From: Niklas Haas
Based on a mixture of guesswork, partial documentation in patents, and
reverse engineering of real-world samples. Confirmed working for all the
samples I've thrown at it.
Contains some annoying machinery to persist these values in between
frames, which is needed in theory even though I've never actually seen a
sample that relies on it in practice. May or may not work.
Since the distinction matters greatly for parsing the color matrix
values, this includes a small helper function to guess the right profile
from the RPU itself in case the user has forgotten to forward the dovi
configuration record to the decoder. (Which in practice, only ffmpeg.c
and ffplay do..)
Notable omissions / deviations:
- CRC32 verification. This is based on the MPEG2 CRC32 type, which does
not seem to be implemented in lavu. (And I don't care enough to do so)
- Linear interpolation support. Nothing documents this (beyond its
existence) and no samples use it, so impossible to implement.
- All of the extension metadata blocks, but these contain values that
seem largely congruent with ST2094, HDR10, or other existing forms of
side data, so I will defer parsing/attaching them to a future commit.
- The patent describes a mechanism for predicting coefficients from
previous RPUs, but the bit for the flag whether to use the
prediction deltas or signal entirely new coefficients does not seem to
be present in actual RPUs, so we ignore this subsystem entirely.
- In the patent's spec, the NLQ subsystem also loops over
num_nlq_pivots, but even in the patent the number is hard-coded to one
iteration rather than signalled. So we only store one set of coefs.
Heavily influenced by https://github.com/quietvoid/dovi_tool
Documentation drawn from US Patent 10,701,399 B2 and ETSI GS CCM 001
Signed-off-by: Niklas Haas
---
configure | 2 +
libavcodec/Makefile | 1 +
libavcodec/dovi_rpu.c | 430 ++
libavcodec/dovi_rpu.h | 71 +++
4 files changed, 504 insertions(+)
create mode 100644 libavcodec/dovi_rpu.c
create mode 100644 libavcodec/dovi_rpu.h
diff --git a/configure b/configure
index 0ccd3bda11..68658a847f 100755
--- a/configure
+++ b/configure
@@ -2434,6 +2434,7 @@ CONFIG_EXTRA="
cbs_vp9
dirac_parse
dnn
+dovi_rpu
dvprofile
exif
faandct
@@ -2706,6 +2707,7 @@ cbs_mpeg2_select="cbs"
cbs_vp9_select="cbs"
dct_select="rdft"
dirac_parse_select="golomb"
+dovi_rpu_select="golomb"
dnn_suggest="libtensorflow libopenvino"
dnn_deps="avformat swscale"
error_resilience_select="me_cmp"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index fb90ecea84..7364c7a91f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -77,6 +77,7 @@ OBJS-$(CONFIG_CBS_MPEG2) += cbs_mpeg2.o
OBJS-$(CONFIG_CBS_VP9) += cbs_vp9.o
OBJS-$(CONFIG_CRYSTALHD) += crystalhd.o
OBJS-$(CONFIG_DCT) += dct.o dct32_fixed.o dct32_float.o
+OBJS-$(CONFIG_DOVI_RPU)+= dovi_rpu.o
OBJS-$(CONFIG_ERROR_RESILIENCE)+= error_resilience.o
OBJS-$(CONFIG_EXIF)+= exif.o tiff_common.o
OBJS-$(CONFIG_FAANDCT) += faandct.o
diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
new file mode 100644
index 00..fc2e1fb2a1
--- /dev/null
+++ b/libavcodec/dovi_rpu.c
@@ -0,0 +1,430 @@
+/*
+ * Dolby Vision RPU decoder
+ *
+ * Copyright (C) 2021 Jan Ekström
+ * Copyright (C) 2021 Niklas Haas
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/buffer.h"
+
+#include "dovi_rpu.h"
+#include "golomb.h"
+#include "get_bits.h"
+
+enum {
+RPU_COEFF_FIXED = 0,
+RPU_COEFF_FLOAT = 1,
+};
+
+/**
+ * Private contents of vdr_ref.
+ */
+typedef struct DOVIVdrRef {
+AVDOVIDataMapping mapping;
+AVDOVIColorMetadata color;
+} DOVIVdrRef;
+
+void ff_dovi_ctx_unref(DOVIContext *s)
+{
+for (int i = 0; i < FF_ARRAY_ELEMS(s->vdr_ref); i++)
+av_buffer_unref(>vdr_ref[i]);
+
+/* Preserve the user-provided fields explicitly, reset everything else */
+*s = (DOVIContext) {
+.logctx = s->logctx,
+.config = s->config,
+};
+}
+
+int ff_dovi_ctx_replace(DOVIContext *s, const
[FFmpeg-devel] [PATCH v9 3/6] ffprobe: Support AV_FRAME_DATA_DOVI_METADATA
From: Jan Ekström
Co-authored-by: Niklas Haas
---
fftools/ffprobe.c | 173 +-
1 file changed, 170 insertions(+), 3 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 906bb03b16..20582ca7ac 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -175,6 +175,10 @@ typedef enum {
SECTION_ID_FRAME_SIDE_DATA,
SECTION_ID_FRAME_SIDE_DATA_TIMECODE_LIST,
SECTION_ID_FRAME_SIDE_DATA_TIMECODE,
+SECTION_ID_FRAME_SIDE_DATA_COMPONENT_LIST,
+SECTION_ID_FRAME_SIDE_DATA_COMPONENT,
+SECTION_ID_FRAME_SIDE_DATA_PIECE_LIST,
+SECTION_ID_FRAME_SIDE_DATA_PIECE,
SECTION_ID_FRAME_LOG,
SECTION_ID_FRAME_LOGS,
SECTION_ID_LIBRARY_VERSION,
@@ -219,9 +223,13 @@ static struct section sections[] = {
[SECTION_ID_FRAME] = { SECTION_ID_FRAME, "frame", 0, {
SECTION_ID_FRAME_TAGS, SECTION_ID_FRAME_SIDE_DATA_LIST, SECTION_ID_FRAME_LOGS,
-1 } },
[SECTION_ID_FRAME_TAGS] = { SECTION_ID_FRAME_TAGS, "tags",
SECTION_FLAG_HAS_VARIABLE_FIELDS, { -1 }, .element_name = "tag", .unique_name =
"frame_tags" },
[SECTION_ID_FRAME_SIDE_DATA_LIST] ={ SECTION_ID_FRAME_SIDE_DATA_LIST,
"side_data_list", SECTION_FLAG_IS_ARRAY, { SECTION_ID_FRAME_SIDE_DATA, -1 },
.element_name = "side_data", .unique_name = "frame_side_data_list" },
-[SECTION_ID_FRAME_SIDE_DATA] = { SECTION_ID_FRAME_SIDE_DATA,
"side_data", 0, { SECTION_ID_FRAME_SIDE_DATA_TIMECODE_LIST, -1 } },
-[SECTION_ID_FRAME_SIDE_DATA_TIMECODE_LIST] = {
SECTION_ID_FRAME_SIDE_DATA_TIMECODE_LIST, "timecodes", SECTION_FLAG_IS_ARRAY, {
SECTION_ID_FRAME_SIDE_DATA_TIMECODE, -1 } },
-[SECTION_ID_FRAME_SIDE_DATA_TIMECODE] = {
SECTION_ID_FRAME_SIDE_DATA_TIMECODE, "timecode", 0, { -1 } },
+[SECTION_ID_FRAME_SIDE_DATA] = { SECTION_ID_FRAME_SIDE_DATA,
"side_data", 0, { SECTION_ID_FRAME_SIDE_DATA_TIMECODE_LIST,
SECTION_ID_FRAME_SIDE_DATA_COMPONENT_LIST, -1 } },
+[SECTION_ID_FRAME_SIDE_DATA_TIMECODE_LIST] = {
SECTION_ID_FRAME_SIDE_DATA_TIMECODE_LIST, "timecodes", SECTION_FLAG_IS_ARRAY, {
SECTION_ID_FRAME_SIDE_DATA_TIMECODE, -1 } },
+[SECTION_ID_FRAME_SIDE_DATA_TIMECODE] = {
SECTION_ID_FRAME_SIDE_DATA_TIMECODE, "timecode", 0, { -1 } },
+[SECTION_ID_FRAME_SIDE_DATA_COMPONENT_LIST] = {
SECTION_ID_FRAME_SIDE_DATA_COMPONENT_LIST, "components", SECTION_FLAG_IS_ARRAY,
{ SECTION_ID_FRAME_SIDE_DATA_COMPONENT, -1 } },
+[SECTION_ID_FRAME_SIDE_DATA_COMPONENT] = {
SECTION_ID_FRAME_SIDE_DATA_COMPONENT, "component", 0, {
SECTION_ID_FRAME_SIDE_DATA_PIECE_LIST, -1 } },
+[SECTION_ID_FRAME_SIDE_DATA_PIECE_LIST] = {
SECTION_ID_FRAME_SIDE_DATA_PIECE_LIST, "pieces", SECTION_FLAG_IS_ARRAY, {
SECTION_ID_FRAME_SIDE_DATA_PIECE, -1 } },
+[SECTION_ID_FRAME_SIDE_DATA_PIECE] ={
SECTION_ID_FRAME_SIDE_DATA_PIECE, "section", 0, { -1 } },
[SECTION_ID_FRAME_LOGS] = { SECTION_ID_FRAME_LOGS, "logs",
SECTION_FLAG_IS_ARRAY, { SECTION_ID_FRAME_LOG, -1 } },
[SECTION_ID_FRAME_LOG] = { SECTION_ID_FRAME_LOG, "log", 0, { -1
}, },
[SECTION_ID_LIBRARY_VERSIONS] = { SECTION_ID_LIBRARY_VERSIONS,
"library_versions", SECTION_FLAG_IS_ARRAY, { SECTION_ID_LIBRARY_VERSION, -1 } },
@@ -1809,6 +1817,16 @@ static void writer_register_all(void)
writer_print_string(w, k, pbuf.str, 0);\
} while (0)
+#define print_list_fmt(k, f, n, ...) do { \
+av_bprint_clear(); \
+for (int idx = 0; idx < n; idx++) { \
+if (idx > 0)\
+av_bprint_chars(, ' ', 1); \
+av_bprintf(, f, __VA_ARGS__); \
+} \
+writer_print_string(w, k, pbuf.str, 0); \
+} while (0)
+
#define print_int(k, v) writer_print_integer(w, k, v)
#define print_q(k, v, s)writer_print_rational(w, k, v, s)
#define print_str(k, v) writer_print_string(w, k, v, 0)
@@ -1854,6 +1872,153 @@ static inline int show_tags(WriterContext *w,
AVDictionary *tags, int section_id
return ret;
}
+static void print_dovi_metadata(WriterContext *w, const AVDOVIMetadata *dovi)
+{
+if (!dovi)
+return;
+
+{
+const AVDOVIRpuDataHeader *hdr = av_dovi_get_header(dovi);
+const AVDOVIDataMapping *mapping = av_dovi_get_mapping(dovi);
+const AVDOVIColorMetadata *color = av_dovi_get_color(dovi);
+AVBPrint pbuf;
+
+av_bprint_init(, 1, AV_BPRINT_SIZE_UNLIMITED);
+
+// header
+print_int("rpu_type",hdr->rpu_type);
+print_int("rpu_format", hdr->rpu_format);
+print_int("vdr_rpu_profile", hdr->vdr_rpu_profile);
+print_int("vdr_rpu_level", hdr->vdr_rpu_level);
+print_int("chroma_resampling_explicit_filter_flag",
+ hdr->chroma_resampling_explicit_filter_flag);
+print_int("coef_data_type", hdr->coef_data_type);
+
[FFmpeg-devel] [PATCH v9 2/6] lavfi/showinfo: Support AV_FRAME_DATA_DOVI_METADATA
From: Niklas Haas
Signed-off-by: Niklas Haas
---
libavfilter/vf_showinfo.c | 108 ++
1 file changed, 108 insertions(+)
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 62c7833247..909ad4f8d7 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -27,6 +27,7 @@
#include "libavutil/bswap.h"
#include "libavutil/adler32.h"
#include "libavutil/display.h"
+#include "libavutil/dovi_meta.h"
#include "libavutil/imgutils.h"
#include "libavutil/internal.h"
#include "libavutil/film_grain_params.h"
@@ -429,6 +430,110 @@ static void
dump_sei_film_grain_params_metadata(AVFilterContext *ctx, const AVFr
}
}
+static void dump_dovi_metadata(AVFilterContext *ctx, const AVFrameSideData *sd)
+{
+const AVDOVIMetadata *dovi = (AVDOVIMetadata *) sd->data;
+const AVDOVIRpuDataHeader *hdr = av_dovi_get_header(dovi);
+const AVDOVIDataMapping *mapping = av_dovi_get_mapping(dovi);
+const AVDOVIColorMetadata *color = av_dovi_get_color(dovi);
+
+av_log(ctx, AV_LOG_INFO, "Dolby Vision Metadata:\n");
+av_log(ctx, AV_LOG_INFO, "rpu_type=%"PRIu8"; ", hdr->rpu_type);
+av_log(ctx, AV_LOG_INFO, "rpu_format=%"PRIu16"; ", hdr->rpu_format);
+av_log(ctx, AV_LOG_INFO, "vdr_rpu_profile=%"PRIu8"; ",
hdr->vdr_rpu_profile);
+av_log(ctx, AV_LOG_INFO, "vdr_rpu_level=%"PRIu8"; ", hdr->vdr_rpu_level);
+av_log(ctx, AV_LOG_INFO, "chroma_resampling_explicit_filter_flag=%"PRIu8";
", hdr->chroma_resampling_explicit_filter_flag);
+av_log(ctx, AV_LOG_INFO, "coef_data_type=%"PRIu8"; ", hdr->coef_data_type);
+av_log(ctx, AV_LOG_INFO, "coef_log2_denom=%"PRIu8"; ",
hdr->coef_log2_denom);
+av_log(ctx, AV_LOG_INFO, "vdr_rpu_normalized_idc=%"PRIu8"; ",
hdr->vdr_rpu_normalized_idc);
+av_log(ctx, AV_LOG_INFO, "bl_video_full_range_flag=%"PRIu8"; ",
hdr->bl_video_full_range_flag);
+av_log(ctx, AV_LOG_INFO, "bl_bit_depth=%"PRIu8"; ", hdr->bl_bit_depth);
+av_log(ctx, AV_LOG_INFO, "el_bit_depth=%"PRIu8"; ", hdr->el_bit_depth);
+av_log(ctx, AV_LOG_INFO, "vdr_bit_depth=%"PRIu8"; ", hdr->vdr_bit_depth);
+av_log(ctx, AV_LOG_INFO, "spatial_resampling_filter_flag=%"PRIu8"; ",
hdr->spatial_resampling_filter_flag);
+av_log(ctx, AV_LOG_INFO, "el_spatial_resampling_filter_flag=%"PRIu8"; ",
hdr->el_spatial_resampling_filter_flag);
+av_log(ctx, AV_LOG_INFO, "disable_residual_flag=%"PRIu8"\n",
hdr->disable_residual_flag);
+
+av_log(ctx, AV_LOG_INFO, "data mapping: ");
+av_log(ctx, AV_LOG_INFO, "vdr_rpu_id=%"PRIu8"; ", mapping->vdr_rpu_id);
+av_log(ctx, AV_LOG_INFO, "mapping_color_space=%"PRIu8"; ",
mapping->mapping_color_space);
+av_log(ctx, AV_LOG_INFO, "mapping_chroma_format_idc=%"PRIu8"; ",
mapping->mapping_chroma_format_idc);
+av_log(ctx, AV_LOG_INFO, "nlq_method_idc=%d; ", (int)
mapping->nlq_method_idc);
+av_log(ctx, AV_LOG_INFO, "num_x_partitions=%"PRIu32"; ",
mapping->num_x_partitions);
+av_log(ctx, AV_LOG_INFO, "num_y_partitions=%"PRIu32"\n",
mapping->num_y_partitions);
+
+for (int c = 0; c < 3; c++) {
+const AVDOVIReshapingCurve *curve = >curves[c];
+const AVDOVINLQParams *nlq = >nlq[c];
+av_log(ctx, AV_LOG_INFO, " channel %d: ", c);
+av_log(ctx, AV_LOG_INFO, "pivots={ ");
+for (int i = 0; i < curve->num_pivots; i++)
+av_log(ctx, AV_LOG_INFO, "%"PRIu16" ", curve->pivots[i]);
+av_log(ctx, AV_LOG_INFO, "}; mapping_idc={ ");
+for (int i = 0; i < curve->num_pivots - 1; i++)
+av_log(ctx, AV_LOG_INFO, "%d ", (int) curve->mapping_idc[i]);
+av_log(ctx, AV_LOG_INFO, "}; poly_order={ ");
+for (int i = 0; i < curve->num_pivots - 1; i++)
+av_log(ctx, AV_LOG_INFO, "%"PRIu8" ", curve->poly_order[i]);
+av_log(ctx, AV_LOG_INFO, "}; poly_coef={ ");
+for (int i = 0; i < curve->num_pivots - 1; i++) {
+av_log(ctx, AV_LOG_INFO, "{%"PRIi64", %"PRIi64", %"PRIi64"} ",
+ curve->poly_coef[i][0],
+ curve->poly_coef[i][1],
+ curve->poly_coef[i][2]);
+}
+
+av_log(ctx, AV_LOG_INFO, "}; mmr_order={ ");
+for (int i = 0; i < curve->num_pivots - 1; i++)
+av_log(ctx, AV_LOG_INFO, "%"PRIu8" ", curve->mmr_order[i]);
+av_log(ctx, AV_LOG_INFO, "}; mmr_constant={ ");
+for (int i = 0; i < curve->num_pivots - 1; i++)
+av_log(ctx, AV_LOG_INFO, "%"PRIi64" ", curve->mmr_constant[i]);
+av_log(ctx, AV_LOG_INFO, "}; mmr_coef={ ");
+for (int i = 0; i < curve->num_pivots - 1; i++) {
+av_log(ctx, AV_LOG_INFO, "{");
+for (int j = 0; j < curve->mmr_order[i]; j++) {
+for (int k = 0; k < 7; k++)
+av_log(ctx, AV_LOG_INFO, "%"PRIi64" ",
curve->mmr_coef[i][j][k]);
+}
+av_log(ctx, AV_LOG_INFO, "} ");
+}
+
+av_log(ctx, AV_LOG_INFO, "};
[FFmpeg-devel] [PATCH v9 1/6] lavu/frame: Add Dolby Vision metadata side data type
From: Niklas Haas
In order to be able to extend this struct later (as the Dolby Vision RPU
evolves), all of the structs are considered extensible, and the
individual constituent fields must instead be accessed via offsets. The
precedent for this style of access is set in
Signed-off-by: Niklas Haas
---
doc/APIchanges| 3 +
libavutil/dovi_meta.c | 25 +++
libavutil/dovi_meta.h | 165 ++
libavutil/frame.c | 1 +
libavutil/frame.h | 9 ++-
libavutil/version.h | 2 +-
6 files changed, 203 insertions(+), 2 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index ac75040274..f692b8ad80 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -14,6 +14,9 @@ libavutil: 2021-04-27
API changes, most recent first:
+2021-12-xx - xx - lavu 57.13.100 - frame.h
+ Add AV_FRAME_DATA_DOVI_METADATA.
+
2021-12-21 - xx - lavu 57.12.100 - cpu.h
Add AV_CPU_FLAG_SLOW_GATHER.
diff --git a/libavutil/dovi_meta.c b/libavutil/dovi_meta.c
index 7bd08f6c54..9c50da561e 100644
--- a/libavutil/dovi_meta.c
+++ b/libavutil/dovi_meta.c
@@ -33,3 +33,28 @@ AVDOVIDecoderConfigurationRecord *av_dovi_alloc(size_t *size)
return dovi;
}
+
+typedef struct AVDOVIMetadataInternal {
+AVDOVIMetadata metadata;
+AVDOVIRpuDataHeader header;
+AVDOVIDataMapping mapping;
+AVDOVIColorMetadata color;
+} AVDOVIMetadataInternal;
+
+AVDOVIMetadata *av_dovi_metadata_alloc(size_t *size)
+{
+AVDOVIMetadataInternal *dovi = av_mallocz(sizeof(AVDOVIMetadataInternal));
+if (!dovi)
+return NULL;
+
+if (size)
+*size = sizeof(*dovi);
+
+dovi->metadata = (struct AVDOVIMetadata) {
+.header_offset = offsetof(AVDOVIMetadataInternal, header),
+.mapping_offset = offsetof(AVDOVIMetadataInternal, mapping),
+.color_offset = offsetof(AVDOVIMetadataInternal, color),
+};
+
+return >metadata;
+}
diff --git a/libavutil/dovi_meta.h b/libavutil/dovi_meta.h
index 299911d434..5bd67e1d49 100644
--- a/libavutil/dovi_meta.h
+++ b/libavutil/dovi_meta.h
@@ -29,6 +29,7 @@
#include
#include
+#include "rational.h"
/*
* DOVI configuration
@@ -67,4 +68,168 @@ typedef struct AVDOVIDecoderConfigurationRecord {
*/
AVDOVIDecoderConfigurationRecord *av_dovi_alloc(size_t *size);
+/**
+ * Dolby Vision RPU data header.
+ *
+ * @note sizeof(AVDOVIRpuDataHeader) is not part of the public ABI.
+ */
+typedef struct AVDOVIRpuDataHeader {
+uint8_t rpu_type;
+uint16_t rpu_format;
+uint8_t vdr_rpu_profile;
+uint8_t vdr_rpu_level;
+uint8_t chroma_resampling_explicit_filter_flag;
+uint8_t coef_data_type; /* informative, lavc always converts to fixed */
+uint8_t coef_log2_denom;
+uint8_t vdr_rpu_normalized_idc;
+uint8_t bl_video_full_range_flag;
+uint8_t bl_bit_depth; /* [8, 16] */
+uint8_t el_bit_depth; /* [8, 16] */
+uint8_t vdr_bit_depth; /* [8, 16] */
+uint8_t spatial_resampling_filter_flag;
+uint8_t el_spatial_resampling_filter_flag;
+uint8_t disable_residual_flag;
+} AVDOVIRpuDataHeader;
+
+enum AVDOVIMappingMethod {
+AV_DOVI_MAPPING_POLYNOMIAL = 0,
+AV_DOVI_MAPPING_MMR = 1,
+};
+
+/**
+ * Coefficients of a piece-wise function. The pieces of the function span the
+ * value ranges between two adjacent pivot values.
+ *
+ * @note sizeof(AVDOVIReshapingCurve) is not part of the public ABI.
+ */
+#define AV_DOVI_MAX_PIECES 8
+typedef struct AVDOVIReshapingCurve {
+uint8_t num_pivots; /* [2, 9] */
+uint16_t pivots[AV_DOVI_MAX_PIECES + 1];/* sorted ascending */
+enum AVDOVIMappingMethod mapping_idc[AV_DOVI_MAX_PIECES];
+/* AV_DOVI_MAPPING_POLYNOMIAL */
+uint8_t poly_order[AV_DOVI_MAX_PIECES]; /* [1, 2] */
+int64_t poly_coef[AV_DOVI_MAX_PIECES][3]; /* x^0, x^1, x^2 */
+/* AV_DOVI_MAPPING_MMR */
+uint8_t mmr_order[AV_DOVI_MAX_PIECES]; /* [1, 3] */
+int64_t mmr_constant[AV_DOVI_MAX_PIECES];
+int64_t mmr_coef[AV_DOVI_MAX_PIECES][3/* order - 1 */][7];
+} AVDOVIReshapingCurve;
+
+enum AVDOVINLQMethod {
+AV_DOVI_NLQ_NONE = -1,
+AV_DOVI_NLQ_LINEAR_DZ = 0,
+};
+
+/**
+ * Coefficients of the non-linear inverse quantization. For the interpretation
+ * of these, see ETSI GS CCM 001.
+ *
+ * @note sizeof(AVDOVINLQParams) is not part of the public ABI.
+ */
+typedef struct AVDOVINLQParams {
+uint64_t nlq_offset;
+uint64_t vdr_in_max;
+/* AV_DOVI_NLQ_LINEAR_DZ */
+uint64_t linear_deadzone_slope;
+uint64_t linear_deadzone_threshold;
+} AVDOVINLQParams;
+
+/**
+ * Dolby Vision RPU data mapping parameters.
+ *
+ * @note sizeof(AVDOVIDataMapping) is not part of the public ABI.
+ */
+typedef struct AVDOVIDataMapping {
+uint8_t vdr_rpu_id;
+uint8_t mapping_color_space;
+uint8_t mapping_chroma_format_idc;
+AVDOVIReshapingCurve curves[3]; /* per component */
+
+/* Non-linear inverse quantization */
+enum AVDOVINLQMethod
Re: [FFmpeg-devel] [PATCH] configure: use pkg-config for sndio
On 29.10.2021 22:41, Brad Smith wrote:
---
configure | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index ede8f9777b..605a317df1 100755
--- a/configure
+++ b/configure
@@ -6718,7 +6718,8 @@ enabled alsa && { check_pkg_config alsa alsa
"alsa/asoundlib.h" snd_pcm_htimesta
enabled libjack &&
require_pkg_config libjack jack jack/jack.h jack_port_get_latency_range
-enabled sndio && check_lib sndio sndio.h sio_open -lsndio
+enabled sndio && { check_pkg_config sndio sndio "sndio.h" sio_open ||
+ check_lib sndio sndio.h sio_open -lsndio; }
if enabled libcdio; then
check_pkg_config libcdio libcdio_paranoia "cdio/cdda.h cdio/paranoia.h"
cdio_cddap_open ||
patch looks simple enough and good to me.
Will push if nobody objects.
smime.p7s
Description: S/MIME Cryptographic 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 v8 1/6] lavu/frame: Add Dolby Vision metadata side data type
Hendrik Leppkes:
> On Wed, Dec 22, 2021 at 2:33 PM Andreas Rheinhardt
> wrote:
>>
>> Hendrik Leppkes:
>>> On Wed, Dec 22, 2021 at 2:00 PM Lynne wrote:
20 Dec 2021, 16:31 by ffm...@haasn.xyz:
> From: Niklas Haas
>
> Signed-off-by: Niklas Haas
> ---
> doc/APIchanges| 3 +
> libavutil/dovi_meta.c | 12
> libavutil/dovi_meta.h | 143 ++
> libavutil/frame.c | 1 +
> libavutil/frame.h | 9 ++-
> libavutil/version.h | 2 +-
> 6 files changed, 168 insertions(+), 2 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 17aa664ca3..ff78edec88 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -14,6 +14,9 @@ libavutil: 2021-04-27
>
> API changes, most recent first:
>
> +2021-12-xx - xx - lavu 57.12.100 - frame.h
> + Add AV_FRAME_DATA_DOVI_METADATA.
> +
> 2021-12-xx - xx - lavf 59.10.100 - avformat.h
> Add AVFormatContext io_close2 which returns an int
>
> diff --git a/libavutil/dovi_meta.c b/libavutil/dovi_meta.c
> index 7bd08f6c54..60b4cb2376 100644
> --- a/libavutil/dovi_meta.c
> +++ b/libavutil/dovi_meta.c
> @@ -33,3 +33,15 @@ AVDOVIDecoderConfigurationRecord *av_dovi_alloc(size_t
> *size)
>
> return dovi;
> }
> +
> +AVDOVIMetadata *av_dovi_metadata_alloc(size_t *size)
> +{
> +AVDOVIMetadata *dovi = av_mallocz(sizeof(AVDOVIMetadata));
> +if (!dovi)
> +return NULL;
> +
> +if (size)
> +*size = sizeof(*dovi);
> +
> +return dovi;
> +}
> diff --git a/libavutil/dovi_meta.h b/libavutil/dovi_meta.h
> index 299911d434..25e6d7b42f 100644
> --- a/libavutil/dovi_meta.h
> +++ b/libavutil/dovi_meta.h
> @@ -29,6 +29,7 @@
>
> #include
> #include
> +#include "rational.h"
>
> /*
> * DOVI configuration
> @@ -67,4 +68,146 @@ typedef struct AVDOVIDecoderConfigurationRecord {
> */
> AVDOVIDecoderConfigurationRecord *av_dovi_alloc(size_t *size);
>
> +/**
> + * Dolby Vision RPU data header.
> + *
> + * @note Cannot be extended without an ABI bump.
> + */
> +typedef struct AVDOVIRpuDataHeader {
> +uint8_t rpu_type;
> +uint16_t rpu_format;
> +uint8_t vdr_rpu_profile;
> +uint8_t vdr_rpu_level;
> +uint8_t chroma_resampling_explicit_filter_flag;
> +uint8_t coef_data_type; /* informative, lavc always converts to
> fixed */
> +uint8_t coef_log2_denom;
> +uint8_t vdr_rpu_normalized_idc;
> +uint8_t bl_video_full_range_flag;
> +uint8_t bl_bit_depth; /* [8, 16] */
> +uint8_t el_bit_depth; /* [8, 16] */
> +uint8_t vdr_bit_depth; /* [8, 16] */
> +uint8_t spatial_resampling_filter_flag;
> +uint8_t el_spatial_resampling_filter_flag;
> +uint8_t disable_residual_flag;
> +} AVDOVIRpuDataHeader;
> +
> +enum AVDOVIMappingMethod {
> +AV_DOVI_MAPPING_POLYNOMIAL = 0,
> +AV_DOVI_MAPPING_MMR = 1,
> +};
> +
> +/**
> + * Coefficients of a piece-wise function. The pieces of the function
> span the
> + * value ranges between two adjacent pivot values.
> + *
> + * @note Cannot be extended without an ABI bump.
> + */
> +#define AV_DOVI_MAX_PIECES 8
> +typedef struct AVDOVIReshapingCurve {
> +uint8_t num_pivots; /* [2, 9] */
> +uint16_t pivots[AV_DOVI_MAX_PIECES + 1];/* sorted ascending */
> +enum AVDOVIMappingMethod mapping_idc[AV_DOVI_MAX_PIECES];
> +/* AV_DOVI_MAPPING_POLYNOMIAL */
> +uint8_t poly_order[AV_DOVI_MAX_PIECES]; /* [1, 2] */
> +int64_t poly_coef[AV_DOVI_MAX_PIECES][3]; /* x^0, x^1, x^2 */
> +/* AV_DOVI_MAPPING_MMR */
> +uint8_t mmr_order[AV_DOVI_MAX_PIECES]; /* [1, 3] */
> +int64_t mmr_constant[AV_DOVI_MAX_PIECES];
> +int64_t mmr_coef[AV_DOVI_MAX_PIECES][3/* order - 1 */][7];
> +} AVDOVIReshapingCurve;
> +
> +enum AVDOVINLQMethod {
> +AV_DOVI_NLQ_NONE = -1,
> +AV_DOVI_NLQ_LINEAR_DZ = 0,
> +};
> +
> +/**
> + * Coefficients of the non-linear inverse quantization. For the
> interpretation
> + * of these, see ETSI GS CCM 001.
> + *
> + * @note Cannot be extended without an ABI bump.
> + */
> +typedef struct AVDOVINLQParams {
> +uint64_t nlq_offset;
> +uint64_t vdr_in_max;
> +/* AV_DOVI_NLQ_LINEAR_DZ */
> +uint64_t linear_deadzone_slope;
> +uint64_t linear_deadzone_threshold;
> +} AVDOVINLQParams;
> +
> +/**
> + * Dolby Vision RPU data mapping parameters.
> + *
> + * @note Cannot be extended without an ABI bump.
> + */
> +typedef struct AVDOVIDataMapping {
Re: [FFmpeg-devel] 5.0 release
On 12/22/2021 11:03 AM, Michael Niedermayer wrote: On Mon, Dec 13, 2021 at 07:05:07PM +0100, Jean-Baptiste Kempf wrote: On Mon, 13 Dec 2021, at 16:25, Michael Niedermayer wrote: If you know of any major issues which need to be done before the release do them now. If you know of any issues which are release-blocking list them in a reply here please. Maybe the audio channel layout would be nice to settle before? iam not sure we will achieve a december 2021 release if we want to include that anyone has an opinion if we should wait with the release until this is in ? thx Is the December target to get into the feature freeze schedule from distros? If so, then IMO better make the release now. The channel layout API is unlikely to be committed before the end of the year. ___ 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] 5.0 release
On Mon, Dec 13, 2021 at 07:05:07PM +0100, Jean-Baptiste Kempf wrote: > On Mon, 13 Dec 2021, at 16:25, Michael Niedermayer wrote: > > If you know of any major issues which need to be done before the release do > > them > > now. If you know of any issues which are release-blocking list them in a > > reply > > here please. > > Maybe the audio channel layout would be nice to settle before? iam not sure we will achieve a december 2021 release if we want to include that anyone has an opinion if we should wait with the release until this is in ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- 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] avformat: add bitpacked demuxer
On Wed, Dec 22, 2021 at 02:38:13PM +0100, Andreas Rheinhardt wrote:
> lance.lmw...@gmail.com:
> > On Tue, Dec 21, 2021 at 02:20:31PM +0100, Andreas Rheinhardt wrote:
> >> lance.lmw...@gmail.com:
> >>> From: Limin Wang
> >>>
> >>> Allows user can playback bitpacked pixel format directly:
> >>> ffplay -video_size 1280x720 test.bitpacked
> >>> ffplay -f bitpacked -video_size 1280x720 -pixel_format uyvy422 test.yuv
> >>>
> >>> Signed-off-by: Limin Wang
> >>> ---
> >>> libavformat/Makefile | 1 +
> >>> libavformat/allformats.c | 1 +
> >>> libavformat/bitpackeddec.c | 136
> >>> +
> >>> 3 files changed, 138 insertions(+)
> >>> create mode 100644 libavformat/bitpackeddec.c
> >>>
> >>> diff --git a/libavformat/Makefile b/libavformat/Makefile
> >>> index 2b5caf9..90b7333 100644
> >>> --- a/libavformat/Makefile
> >>> +++ b/libavformat/Makefile
> >>> @@ -138,6 +138,7 @@ OBJS-$(CONFIG_BINKA_DEMUXER) += binka.o
> >>> OBJS-$(CONFIG_BINTEXT_DEMUXER) += bintext.o sauce.o
> >>> OBJS-$(CONFIG_BIT_DEMUXER) += bit.o
> >>> OBJS-$(CONFIG_BIT_MUXER) += bit.o
> >>> +OBJS-$(CONFIG_BITPACKED_DEMUXER) += bitpackeddec.o
> >>> OBJS-$(CONFIG_BMV_DEMUXER) += bmv.o
> >>> OBJS-$(CONFIG_BOA_DEMUXER) += boadec.o
> >>> OBJS-$(CONFIG_BFSTM_DEMUXER) += brstm.o
> >>> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> >>> index 1054ac9..a100639 100644
> >>> --- a/libavformat/allformats.c
> >>> +++ b/libavformat/allformats.c
> >>> @@ -96,6 +96,7 @@ extern const AVInputFormat ff_bink_demuxer;
> >>> extern const AVInputFormat ff_binka_demuxer;
> >>> extern const AVInputFormat ff_bit_demuxer;
> >>> extern const AVOutputFormat ff_bit_muxer;
> >>> +extern const AVInputFormat ff_bitpacked_demuxer;
> >>> extern const AVInputFormat ff_bmv_demuxer;
> >>> extern const AVInputFormat ff_bfstm_demuxer;
> >>> extern const AVInputFormat ff_brstm_demuxer;
> >>> diff --git a/libavformat/bitpackeddec.c b/libavformat/bitpackeddec.c
> >>> new file mode 100644
> >>> index 000..ba404ad
> >>> --- /dev/null
> >>> +++ b/libavformat/bitpackeddec.c
> >>> @@ -0,0 +1,136 @@
> >>> +/*
> >>> + * Raw bitpacked video demuxer
> >>> + * Copyright (c) 2021 Limin Wang
> >>> + *
> >>> + * This file is part of FFmpeg.
> >>> + *
> >>> + * FFmpeg is free software; you can redistribute it and/or
> >>> + * modify it under the terms of the GNU Lesser General Public
> >>> + * License as published by the Free Software Foundation; either
> >>> + * version 2.1 of the License, or (at your option) any later version.
> >>> + *
> >>> + * FFmpeg is distributed in the hope that it will be useful,
> >>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> >>> + * Lesser General Public License for more details.
> >>> + *
> >>> + * You should have received a copy of the GNU Lesser General Public
> >>> + * License along with FFmpeg; if not, write to the Free Software
> >>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> >>> 02110-1301 USA
> >>> + */
> >>> +
> >>> +#include "libavutil/imgutils.h"
> >>> +#include "libavutil/parseutils.h"
> >>> +#include "libavutil/pixdesc.h"
> >>> +#include "libavutil/opt.h"
> >>> +#include "internal.h"
> >>> +#include "avformat.h"
> >>> +
> >>> +typedef struct BitPackedDemuxerContext {
> >>> +const AVClass *class; /**< Class for private options. */
> >>> +int width, height;/**< Integers describing video size, set
> >>> by a private option. */
> >>> +char *pixel_format; /**< Set by a private option. */
> >>> +AVRational framerate; /**< AVRational describing framerate, set
> >>> by a private option. */
> >>> +} BitPackedDemuxerContext;
> >>> +
> >>> +static int bitpacked_read_header(AVFormatContext *ctx)
> >>> +{
> >>> +BitPackedDemuxerContext *s = ctx->priv_data;
> >>> +AVStream *st;
> >>> +enum AVPixelFormat pix_fmt;
> >>> +unsigned int pgroup; /* size of the pixel group in bytes */
> >>> +unsigned int xinc;
> >>> +const AVPixFmtDescriptor *desc;
> >>> +int tag;
> >>> +int ret;
> >>> +
> >>> +st = avformat_new_stream(ctx, NULL);
> >>> +if (!st)
> >>> +return AVERROR(ENOMEM);
> >>> +
> >>> +st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
> >>> +st->codecpar->codec_id = ctx->iformat->raw_codec_id;
> >>
> >> Seems like you copied this code from somewhere. Where did you copy it from?
> >
> > Yes, this part is coming from v210 demuxer I think.
> >
>
> The original source seems to be rawvideodec; it has exactly the same
> options, exactly the same private struct, exactly the same read_packet
> function and its read_header function is quite similar. You should reuse
> the common code.
OK, I'll try to add it to rawvideodec.c and reuse the common code.
>
> >>
> >>> +
>
Re: [FFmpeg-devel] [PATCH v8 1/6] lavu/frame: Add Dolby Vision metadata side data type
On Wed, Dec 22, 2021 at 2:33 PM Andreas Rheinhardt
wrote:
>
> Hendrik Leppkes:
> > On Wed, Dec 22, 2021 at 2:00 PM Lynne wrote:
> >>
> >> 20 Dec 2021, 16:31 by ffm...@haasn.xyz:
> >>
> >>> From: Niklas Haas
> >>>
> >>> Signed-off-by: Niklas Haas
> >>> ---
> >>> doc/APIchanges| 3 +
> >>> libavutil/dovi_meta.c | 12
> >>> libavutil/dovi_meta.h | 143 ++
> >>> libavutil/frame.c | 1 +
> >>> libavutil/frame.h | 9 ++-
> >>> libavutil/version.h | 2 +-
> >>> 6 files changed, 168 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/doc/APIchanges b/doc/APIchanges
> >>> index 17aa664ca3..ff78edec88 100644
> >>> --- a/doc/APIchanges
> >>> +++ b/doc/APIchanges
> >>> @@ -14,6 +14,9 @@ libavutil: 2021-04-27
> >>>
> >>> API changes, most recent first:
> >>>
> >>> +2021-12-xx - xx - lavu 57.12.100 - frame.h
> >>> + Add AV_FRAME_DATA_DOVI_METADATA.
> >>> +
> >>> 2021-12-xx - xx - lavf 59.10.100 - avformat.h
> >>> Add AVFormatContext io_close2 which returns an int
> >>>
> >>> diff --git a/libavutil/dovi_meta.c b/libavutil/dovi_meta.c
> >>> index 7bd08f6c54..60b4cb2376 100644
> >>> --- a/libavutil/dovi_meta.c
> >>> +++ b/libavutil/dovi_meta.c
> >>> @@ -33,3 +33,15 @@ AVDOVIDecoderConfigurationRecord *av_dovi_alloc(size_t
> >>> *size)
> >>>
> >>> return dovi;
> >>> }
> >>> +
> >>> +AVDOVIMetadata *av_dovi_metadata_alloc(size_t *size)
> >>> +{
> >>> +AVDOVIMetadata *dovi = av_mallocz(sizeof(AVDOVIMetadata));
> >>> +if (!dovi)
> >>> +return NULL;
> >>> +
> >>> +if (size)
> >>> +*size = sizeof(*dovi);
> >>> +
> >>> +return dovi;
> >>> +}
> >>> diff --git a/libavutil/dovi_meta.h b/libavutil/dovi_meta.h
> >>> index 299911d434..25e6d7b42f 100644
> >>> --- a/libavutil/dovi_meta.h
> >>> +++ b/libavutil/dovi_meta.h
> >>> @@ -29,6 +29,7 @@
> >>>
> >>> #include
> >>> #include
> >>> +#include "rational.h"
> >>>
> >>> /*
> >>> * DOVI configuration
> >>> @@ -67,4 +68,146 @@ typedef struct AVDOVIDecoderConfigurationRecord {
> >>> */
> >>> AVDOVIDecoderConfigurationRecord *av_dovi_alloc(size_t *size);
> >>>
> >>> +/**
> >>> + * Dolby Vision RPU data header.
> >>> + *
> >>> + * @note Cannot be extended without an ABI bump.
> >>> + */
> >>> +typedef struct AVDOVIRpuDataHeader {
> >>> +uint8_t rpu_type;
> >>> +uint16_t rpu_format;
> >>> +uint8_t vdr_rpu_profile;
> >>> +uint8_t vdr_rpu_level;
> >>> +uint8_t chroma_resampling_explicit_filter_flag;
> >>> +uint8_t coef_data_type; /* informative, lavc always converts to
> >>> fixed */
> >>> +uint8_t coef_log2_denom;
> >>> +uint8_t vdr_rpu_normalized_idc;
> >>> +uint8_t bl_video_full_range_flag;
> >>> +uint8_t bl_bit_depth; /* [8, 16] */
> >>> +uint8_t el_bit_depth; /* [8, 16] */
> >>> +uint8_t vdr_bit_depth; /* [8, 16] */
> >>> +uint8_t spatial_resampling_filter_flag;
> >>> +uint8_t el_spatial_resampling_filter_flag;
> >>> +uint8_t disable_residual_flag;
> >>> +} AVDOVIRpuDataHeader;
> >>> +
> >>> +enum AVDOVIMappingMethod {
> >>> +AV_DOVI_MAPPING_POLYNOMIAL = 0,
> >>> +AV_DOVI_MAPPING_MMR = 1,
> >>> +};
> >>> +
> >>> +/**
> >>> + * Coefficients of a piece-wise function. The pieces of the function
> >>> span the
> >>> + * value ranges between two adjacent pivot values.
> >>> + *
> >>> + * @note Cannot be extended without an ABI bump.
> >>> + */
> >>> +#define AV_DOVI_MAX_PIECES 8
> >>> +typedef struct AVDOVIReshapingCurve {
> >>> +uint8_t num_pivots; /* [2, 9] */
> >>> +uint16_t pivots[AV_DOVI_MAX_PIECES + 1];/* sorted ascending */
> >>> +enum AVDOVIMappingMethod mapping_idc[AV_DOVI_MAX_PIECES];
> >>> +/* AV_DOVI_MAPPING_POLYNOMIAL */
> >>> +uint8_t poly_order[AV_DOVI_MAX_PIECES]; /* [1, 2] */
> >>> +int64_t poly_coef[AV_DOVI_MAX_PIECES][3]; /* x^0, x^1, x^2 */
> >>> +/* AV_DOVI_MAPPING_MMR */
> >>> +uint8_t mmr_order[AV_DOVI_MAX_PIECES]; /* [1, 3] */
> >>> +int64_t mmr_constant[AV_DOVI_MAX_PIECES];
> >>> +int64_t mmr_coef[AV_DOVI_MAX_PIECES][3/* order - 1 */][7];
> >>> +} AVDOVIReshapingCurve;
> >>> +
> >>> +enum AVDOVINLQMethod {
> >>> +AV_DOVI_NLQ_NONE = -1,
> >>> +AV_DOVI_NLQ_LINEAR_DZ = 0,
> >>> +};
> >>> +
> >>> +/**
> >>> + * Coefficients of the non-linear inverse quantization. For the
> >>> interpretation
> >>> + * of these, see ETSI GS CCM 001.
> >>> + *
> >>> + * @note Cannot be extended without an ABI bump.
> >>> + */
> >>> +typedef struct AVDOVINLQParams {
> >>> +uint64_t nlq_offset;
> >>> +uint64_t vdr_in_max;
> >>> +/* AV_DOVI_NLQ_LINEAR_DZ */
> >>> +uint64_t linear_deadzone_slope;
> >>> +uint64_t linear_deadzone_threshold;
> >>> +} AVDOVINLQParams;
> >>> +
> >>> +/**
> >>> + * Dolby Vision RPU data mapping parameters.
> >>> + *
> >>> + * @note Cannot be extended without an ABI bump.
> >>> + */
> >>> +typedef struct AVDOVIDataMapping {
> >>> +uint8_t
Re: [FFmpeg-devel] [PATCH] avformat: add bitpacked demuxer
lance.lmw...@gmail.com:
> On Tue, Dec 21, 2021 at 02:20:31PM +0100, Andreas Rheinhardt wrote:
>> lance.lmw...@gmail.com:
>>> From: Limin Wang
>>>
>>> Allows user can playback bitpacked pixel format directly:
>>> ffplay -video_size 1280x720 test.bitpacked
>>> ffplay -f bitpacked -video_size 1280x720 -pixel_format uyvy422 test.yuv
>>>
>>> Signed-off-by: Limin Wang
>>> ---
>>> libavformat/Makefile | 1 +
>>> libavformat/allformats.c | 1 +
>>> libavformat/bitpackeddec.c | 136
>>> +
>>> 3 files changed, 138 insertions(+)
>>> create mode 100644 libavformat/bitpackeddec.c
>>>
>>> diff --git a/libavformat/Makefile b/libavformat/Makefile
>>> index 2b5caf9..90b7333 100644
>>> --- a/libavformat/Makefile
>>> +++ b/libavformat/Makefile
>>> @@ -138,6 +138,7 @@ OBJS-$(CONFIG_BINKA_DEMUXER) += binka.o
>>> OBJS-$(CONFIG_BINTEXT_DEMUXER) += bintext.o sauce.o
>>> OBJS-$(CONFIG_BIT_DEMUXER) += bit.o
>>> OBJS-$(CONFIG_BIT_MUXER) += bit.o
>>> +OBJS-$(CONFIG_BITPACKED_DEMUXER) += bitpackeddec.o
>>> OBJS-$(CONFIG_BMV_DEMUXER) += bmv.o
>>> OBJS-$(CONFIG_BOA_DEMUXER) += boadec.o
>>> OBJS-$(CONFIG_BFSTM_DEMUXER) += brstm.o
>>> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
>>> index 1054ac9..a100639 100644
>>> --- a/libavformat/allformats.c
>>> +++ b/libavformat/allformats.c
>>> @@ -96,6 +96,7 @@ extern const AVInputFormat ff_bink_demuxer;
>>> extern const AVInputFormat ff_binka_demuxer;
>>> extern const AVInputFormat ff_bit_demuxer;
>>> extern const AVOutputFormat ff_bit_muxer;
>>> +extern const AVInputFormat ff_bitpacked_demuxer;
>>> extern const AVInputFormat ff_bmv_demuxer;
>>> extern const AVInputFormat ff_bfstm_demuxer;
>>> extern const AVInputFormat ff_brstm_demuxer;
>>> diff --git a/libavformat/bitpackeddec.c b/libavformat/bitpackeddec.c
>>> new file mode 100644
>>> index 000..ba404ad
>>> --- /dev/null
>>> +++ b/libavformat/bitpackeddec.c
>>> @@ -0,0 +1,136 @@
>>> +/*
>>> + * Raw bitpacked video demuxer
>>> + * Copyright (c) 2021 Limin Wang
>>> + *
>>> + * This file is part of FFmpeg.
>>> + *
>>> + * FFmpeg is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU Lesser General Public
>>> + * License as published by the Free Software Foundation; either
>>> + * version 2.1 of the License, or (at your option) any later version.
>>> + *
>>> + * FFmpeg is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>>> + * Lesser General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU Lesser General Public
>>> + * License along with FFmpeg; if not, write to the Free Software
>>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>>> 02110-1301 USA
>>> + */
>>> +
>>> +#include "libavutil/imgutils.h"
>>> +#include "libavutil/parseutils.h"
>>> +#include "libavutil/pixdesc.h"
>>> +#include "libavutil/opt.h"
>>> +#include "internal.h"
>>> +#include "avformat.h"
>>> +
>>> +typedef struct BitPackedDemuxerContext {
>>> +const AVClass *class; /**< Class for private options. */
>>> +int width, height;/**< Integers describing video size, set by
>>> a private option. */
>>> +char *pixel_format; /**< Set by a private option. */
>>> +AVRational framerate; /**< AVRational describing framerate, set by
>>> a private option. */
>>> +} BitPackedDemuxerContext;
>>> +
>>> +static int bitpacked_read_header(AVFormatContext *ctx)
>>> +{
>>> +BitPackedDemuxerContext *s = ctx->priv_data;
>>> +AVStream *st;
>>> +enum AVPixelFormat pix_fmt;
>>> +unsigned int pgroup; /* size of the pixel group in bytes */
>>> +unsigned int xinc;
>>> +const AVPixFmtDescriptor *desc;
>>> +int tag;
>>> +int ret;
>>> +
>>> +st = avformat_new_stream(ctx, NULL);
>>> +if (!st)
>>> +return AVERROR(ENOMEM);
>>> +
>>> +st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
>>> +st->codecpar->codec_id = ctx->iformat->raw_codec_id;
>>
>> Seems like you copied this code from somewhere. Where did you copy it from?
>
> Yes, this part is coming from v210 demuxer I think.
>
The original source seems to be rawvideodec; it has exactly the same
options, exactly the same private struct, exactly the same read_packet
function and its read_header function is quite similar. You should reuse
the common code.
>>
>>> +
>>> +if ((pix_fmt = av_get_pix_fmt(s->pixel_format)) == AV_PIX_FMT_NONE) {
>>> +av_log(ctx, AV_LOG_ERROR, "No such pixel format: %s.\n",
>>> s->pixel_format);
>>> +return AVERROR(EINVAL);
>>> +}
>>> +desc = av_pix_fmt_desc_get(pix_fmt);
>>> +
>>> +ret = av_image_check_size(s->width, s->height, 0, ctx);
>>> +if (ret < 0)
>>> +
Re: [FFmpeg-devel] [PATCH v2 1/2] avformat/mov: add validate_box_size
On 2021-12-22 06:43 pm, Nicolas George wrote:
Gyan Doshi (12021-12-22):
Helper function to check if stored box size is correct and looks
to be fully available.
---
libavformat/mov.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2aed6e80ef..7de95b7ab0 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -80,6 +80,40 @@ static int mov_read_mfra(MOVContext *c, AVIOContext *f);
static int64_t add_ctts_entry(MOVCtts** ctts_data, unsigned int* ctts_count,
unsigned int* allocated_size,
int count, int duration);
+/** Check if the box size meets the requirements passed in limit and constraint_type.
+ * If input avio_size is valid, it checks if box size appears to be
available.
+ *
+ * constraint_type may be
+ * 0 if the box size has to be exactly equal to limit
+ * -1 if the box size has to be at most limit
+ * 1 if the box size has to be at least limit
+ *
+ * Returns 0 if size meets requirements.
+ */
+static int validate_box_size(MOVContext *c, MOVAtom atom, AVIOContext *pb,
+ int64_t pos, int64_t limit, int constraint_type)
+{
+int size_fit;
+int64_t input_size = avio_size(pb);
+
+if (input_size > 0 &&
+input_size - pos < atom.size) {
+av_log(c->fc, AV_LOG_ERROR, "Box %s is truncated\n",
av_fourcc2str(atom.type));
+return AVERROR_INVALIDDATA;
+}
+
+if (FFABS(constraint_type) > 1)
+return AVERROR_BUG;
av_assert() whould have been the right choice here.
Will change.
+
+switch(constraint_type) {
+case 0: size_fit = atom.size == limit; break;
+case -1: size_fit = atom.size <= limit; break;
+case 1: size_fit = atom.size >= limit; break;
This code is unused, AFAICS. Not a good idea.
I'll call this function in other box readers. Their requirements are
different.
That's why I made the check a separate function.
Regards,
Gyan
___
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 v8 1/6] lavu/frame: Add Dolby Vision metadata side data type
Hendrik Leppkes:
> On Wed, Dec 22, 2021 at 2:00 PM Lynne wrote:
>>
>> 20 Dec 2021, 16:31 by ffm...@haasn.xyz:
>>
>>> From: Niklas Haas
>>>
>>> Signed-off-by: Niklas Haas
>>> ---
>>> doc/APIchanges| 3 +
>>> libavutil/dovi_meta.c | 12
>>> libavutil/dovi_meta.h | 143 ++
>>> libavutil/frame.c | 1 +
>>> libavutil/frame.h | 9 ++-
>>> libavutil/version.h | 2 +-
>>> 6 files changed, 168 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/doc/APIchanges b/doc/APIchanges
>>> index 17aa664ca3..ff78edec88 100644
>>> --- a/doc/APIchanges
>>> +++ b/doc/APIchanges
>>> @@ -14,6 +14,9 @@ libavutil: 2021-04-27
>>>
>>> API changes, most recent first:
>>>
>>> +2021-12-xx - xx - lavu 57.12.100 - frame.h
>>> + Add AV_FRAME_DATA_DOVI_METADATA.
>>> +
>>> 2021-12-xx - xx - lavf 59.10.100 - avformat.h
>>> Add AVFormatContext io_close2 which returns an int
>>>
>>> diff --git a/libavutil/dovi_meta.c b/libavutil/dovi_meta.c
>>> index 7bd08f6c54..60b4cb2376 100644
>>> --- a/libavutil/dovi_meta.c
>>> +++ b/libavutil/dovi_meta.c
>>> @@ -33,3 +33,15 @@ AVDOVIDecoderConfigurationRecord *av_dovi_alloc(size_t
>>> *size)
>>>
>>> return dovi;
>>> }
>>> +
>>> +AVDOVIMetadata *av_dovi_metadata_alloc(size_t *size)
>>> +{
>>> +AVDOVIMetadata *dovi = av_mallocz(sizeof(AVDOVIMetadata));
>>> +if (!dovi)
>>> +return NULL;
>>> +
>>> +if (size)
>>> +*size = sizeof(*dovi);
>>> +
>>> +return dovi;
>>> +}
>>> diff --git a/libavutil/dovi_meta.h b/libavutil/dovi_meta.h
>>> index 299911d434..25e6d7b42f 100644
>>> --- a/libavutil/dovi_meta.h
>>> +++ b/libavutil/dovi_meta.h
>>> @@ -29,6 +29,7 @@
>>>
>>> #include
>>> #include
>>> +#include "rational.h"
>>>
>>> /*
>>> * DOVI configuration
>>> @@ -67,4 +68,146 @@ typedef struct AVDOVIDecoderConfigurationRecord {
>>> */
>>> AVDOVIDecoderConfigurationRecord *av_dovi_alloc(size_t *size);
>>>
>>> +/**
>>> + * Dolby Vision RPU data header.
>>> + *
>>> + * @note Cannot be extended without an ABI bump.
>>> + */
>>> +typedef struct AVDOVIRpuDataHeader {
>>> +uint8_t rpu_type;
>>> +uint16_t rpu_format;
>>> +uint8_t vdr_rpu_profile;
>>> +uint8_t vdr_rpu_level;
>>> +uint8_t chroma_resampling_explicit_filter_flag;
>>> +uint8_t coef_data_type; /* informative, lavc always converts to fixed
>>> */
>>> +uint8_t coef_log2_denom;
>>> +uint8_t vdr_rpu_normalized_idc;
>>> +uint8_t bl_video_full_range_flag;
>>> +uint8_t bl_bit_depth; /* [8, 16] */
>>> +uint8_t el_bit_depth; /* [8, 16] */
>>> +uint8_t vdr_bit_depth; /* [8, 16] */
>>> +uint8_t spatial_resampling_filter_flag;
>>> +uint8_t el_spatial_resampling_filter_flag;
>>> +uint8_t disable_residual_flag;
>>> +} AVDOVIRpuDataHeader;
>>> +
>>> +enum AVDOVIMappingMethod {
>>> +AV_DOVI_MAPPING_POLYNOMIAL = 0,
>>> +AV_DOVI_MAPPING_MMR = 1,
>>> +};
>>> +
>>> +/**
>>> + * Coefficients of a piece-wise function. The pieces of the function span
>>> the
>>> + * value ranges between two adjacent pivot values.
>>> + *
>>> + * @note Cannot be extended without an ABI bump.
>>> + */
>>> +#define AV_DOVI_MAX_PIECES 8
>>> +typedef struct AVDOVIReshapingCurve {
>>> +uint8_t num_pivots; /* [2, 9] */
>>> +uint16_t pivots[AV_DOVI_MAX_PIECES + 1];/* sorted ascending */
>>> +enum AVDOVIMappingMethod mapping_idc[AV_DOVI_MAX_PIECES];
>>> +/* AV_DOVI_MAPPING_POLYNOMIAL */
>>> +uint8_t poly_order[AV_DOVI_MAX_PIECES]; /* [1, 2] */
>>> +int64_t poly_coef[AV_DOVI_MAX_PIECES][3]; /* x^0, x^1, x^2 */
>>> +/* AV_DOVI_MAPPING_MMR */
>>> +uint8_t mmr_order[AV_DOVI_MAX_PIECES]; /* [1, 3] */
>>> +int64_t mmr_constant[AV_DOVI_MAX_PIECES];
>>> +int64_t mmr_coef[AV_DOVI_MAX_PIECES][3/* order - 1 */][7];
>>> +} AVDOVIReshapingCurve;
>>> +
>>> +enum AVDOVINLQMethod {
>>> +AV_DOVI_NLQ_NONE = -1,
>>> +AV_DOVI_NLQ_LINEAR_DZ = 0,
>>> +};
>>> +
>>> +/**
>>> + * Coefficients of the non-linear inverse quantization. For the
>>> interpretation
>>> + * of these, see ETSI GS CCM 001.
>>> + *
>>> + * @note Cannot be extended without an ABI bump.
>>> + */
>>> +typedef struct AVDOVINLQParams {
>>> +uint64_t nlq_offset;
>>> +uint64_t vdr_in_max;
>>> +/* AV_DOVI_NLQ_LINEAR_DZ */
>>> +uint64_t linear_deadzone_slope;
>>> +uint64_t linear_deadzone_threshold;
>>> +} AVDOVINLQParams;
>>> +
>>> +/**
>>> + * Dolby Vision RPU data mapping parameters.
>>> + *
>>> + * @note Cannot be extended without an ABI bump.
>>> + */
>>> +typedef struct AVDOVIDataMapping {
>>> +uint8_t vdr_rpu_id;
>>> +uint8_t mapping_color_space;
>>> +uint8_t mapping_chroma_format_idc;
>>> +AVDOVIReshapingCurve curves[3]; /* per component */
>>> +
>>> +/* Non-linear inverse quantization */
>>> +enum AVDOVINLQMethod nlq_method_idc;
>>> +uint32_t num_x_partitions;
>>> +uint32_t num_y_partitions;
>>> +AVDOVINLQParams nlq[3];
Re: [FFmpeg-devel] Politics
> -Original Message- > From: ffmpeg-devel On Behalf Of Michael > Niedermayer > Sent: Monday, December 20, 2021 4:24 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] Politics > > I am not sure the direction from which you approuch this is going to > increase the chances this patch has. > > All stream types in libavformat/codec are timebase based, that was > done because its exact (for some definition of exact at least) > > I think you should argue why this is the best way forward not why its > not too bad > > also in a few places where a fixed timebase is used ffmpeg uses > AV_TIME_BASE_Q which is micro not milli seconds. That suddenly > allows exactly addressing individual frames and audio samples. > And it should be easy to change to from ms, its just a *1000 > it would weaken the precission argument For the final chapter of this story, let us return to the original subject which I would summarize like: "Even though the whole world is fine using millisecond precision for subtitle display, I think I know better and therefore insist on having a higher precision and/or flexible timebase for subtitle timings, otherwise I won't accept the patchset" I have been waiting for a while to answer, expecting somebody might come to realize himself how useless this whole idea actually is, but I guess it's time to reveal: Let's look at the concern first: The concern is about that with a subtitle precision of milliseconds (let's say milli, even though we actually have microseconds), it would not be possible to make sure that a subtitle event would be shown exactly at a specific video frame. The claim is: This could be achieved by having a high precision (and/or a custom time base) for subtitle timings, because this would allow to have subtitle start times that could exactly match the frame display time of the frame at which a subtitle should be initially displayed. For a moment let's put aside the argument about subtitle format precision. Let's assume we'd have a subtitle format that allows such precisions and maybe even custom time bases and let's assume a player that can handle this. Now we look at the player and a situation where the player needs to display frame N. At this point, a range of different things can happen, mostly specific to the implementation of the player: Whether it reads a frame's time value or infers it from the frame rate or which time base a player is using internally, just to name a few examples. And then - at a total different place of implementation in the player (could be custom, or a library like libass), the player needs to determine whether a (and which) subtitle needs to be displayed over frame N. Here, we have the frame time, which has undergone a number of calculations and we have a subtitle event with our super- precise subtitle start time. The player converts that to its internal time base, and then.. ..how does the player determine whether the subtitle event should be shown on frame N? Does it check like: frame.pts == subtitle.pts? No, it doesn't! It does something like: frame.pts > subtitle.pts && frame.pts < subtitle.end_pts ..because it also needs to display all subtitle events that are already visible. Let's look again at the proposal: to use high precision subtitle timings which would allow us to have subtitle start times that are as close as possible (or even equal) to the video frame time. Now what a surprise: having-frame-equal subtitle start-times wouldn't make it _more_ clear at which video frame the subtitle should be shown - it would make it more and more _unclear_ and non-deterministic whether it should be shown at that frame or the next! Eventually, the final presentation would depend on: client implementation details and rounding errors, which means the opposite of consistent, reliable or predictable. The closer and more precise a subtitle start time would be set to a frame's display time, the higher the chance that it would be shown at the wrong time (due to the >/< tests that clients need to perform. Everybody who is creating computer animations and who wants to achieve sudden changes from one frame to another knows, that this change needs to be authored in a way that it happens in the timely middle between two frames (to make it safe against slight adjustments, rescaling, etc.) And the same goes for subtitle authoring: When you want to make sure that a subtitle is shown at frame N+1 but not at frame N, then you set the subtitle start time to a time half-way between N and N+1. And this doesn't require high-precision timing values nor custom time bases and it's also stable against calculations and rounding errors that might occur during processing. My wish for the future would be criticism that isn't based on mind-farts or unrealistic hypothetical cases, but actual problems, ideally accompanied by an example to demonstrate. Kind regards, softworkz
Re: [FFmpeg-devel] [PATCH v8 1/6] lavu/frame: Add Dolby Vision metadata side data type
On Wed, Dec 22, 2021 at 2:00 PM Lynne wrote:
>
> 20 Dec 2021, 16:31 by ffm...@haasn.xyz:
>
> > From: Niklas Haas
> >
> > Signed-off-by: Niklas Haas
> > ---
> > doc/APIchanges| 3 +
> > libavutil/dovi_meta.c | 12
> > libavutil/dovi_meta.h | 143 ++
> > libavutil/frame.c | 1 +
> > libavutil/frame.h | 9 ++-
> > libavutil/version.h | 2 +-
> > 6 files changed, 168 insertions(+), 2 deletions(-)
> >
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index 17aa664ca3..ff78edec88 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -14,6 +14,9 @@ libavutil: 2021-04-27
> >
> > API changes, most recent first:
> >
> > +2021-12-xx - xx - lavu 57.12.100 - frame.h
> > + Add AV_FRAME_DATA_DOVI_METADATA.
> > +
> > 2021-12-xx - xx - lavf 59.10.100 - avformat.h
> > Add AVFormatContext io_close2 which returns an int
> >
> > diff --git a/libavutil/dovi_meta.c b/libavutil/dovi_meta.c
> > index 7bd08f6c54..60b4cb2376 100644
> > --- a/libavutil/dovi_meta.c
> > +++ b/libavutil/dovi_meta.c
> > @@ -33,3 +33,15 @@ AVDOVIDecoderConfigurationRecord *av_dovi_alloc(size_t
> > *size)
> >
> > return dovi;
> > }
> > +
> > +AVDOVIMetadata *av_dovi_metadata_alloc(size_t *size)
> > +{
> > +AVDOVIMetadata *dovi = av_mallocz(sizeof(AVDOVIMetadata));
> > +if (!dovi)
> > +return NULL;
> > +
> > +if (size)
> > +*size = sizeof(*dovi);
> > +
> > +return dovi;
> > +}
> > diff --git a/libavutil/dovi_meta.h b/libavutil/dovi_meta.h
> > index 299911d434..25e6d7b42f 100644
> > --- a/libavutil/dovi_meta.h
> > +++ b/libavutil/dovi_meta.h
> > @@ -29,6 +29,7 @@
> >
> > #include
> > #include
> > +#include "rational.h"
> >
> > /*
> > * DOVI configuration
> > @@ -67,4 +68,146 @@ typedef struct AVDOVIDecoderConfigurationRecord {
> > */
> > AVDOVIDecoderConfigurationRecord *av_dovi_alloc(size_t *size);
> >
> > +/**
> > + * Dolby Vision RPU data header.
> > + *
> > + * @note Cannot be extended without an ABI bump.
> > + */
> > +typedef struct AVDOVIRpuDataHeader {
> > +uint8_t rpu_type;
> > +uint16_t rpu_format;
> > +uint8_t vdr_rpu_profile;
> > +uint8_t vdr_rpu_level;
> > +uint8_t chroma_resampling_explicit_filter_flag;
> > +uint8_t coef_data_type; /* informative, lavc always converts to fixed
> > */
> > +uint8_t coef_log2_denom;
> > +uint8_t vdr_rpu_normalized_idc;
> > +uint8_t bl_video_full_range_flag;
> > +uint8_t bl_bit_depth; /* [8, 16] */
> > +uint8_t el_bit_depth; /* [8, 16] */
> > +uint8_t vdr_bit_depth; /* [8, 16] */
> > +uint8_t spatial_resampling_filter_flag;
> > +uint8_t el_spatial_resampling_filter_flag;
> > +uint8_t disable_residual_flag;
> > +} AVDOVIRpuDataHeader;
> > +
> > +enum AVDOVIMappingMethod {
> > +AV_DOVI_MAPPING_POLYNOMIAL = 0,
> > +AV_DOVI_MAPPING_MMR = 1,
> > +};
> > +
> > +/**
> > + * Coefficients of a piece-wise function. The pieces of the function span
> > the
> > + * value ranges between two adjacent pivot values.
> > + *
> > + * @note Cannot be extended without an ABI bump.
> > + */
> > +#define AV_DOVI_MAX_PIECES 8
> > +typedef struct AVDOVIReshapingCurve {
> > +uint8_t num_pivots; /* [2, 9] */
> > +uint16_t pivots[AV_DOVI_MAX_PIECES + 1];/* sorted ascending */
> > +enum AVDOVIMappingMethod mapping_idc[AV_DOVI_MAX_PIECES];
> > +/* AV_DOVI_MAPPING_POLYNOMIAL */
> > +uint8_t poly_order[AV_DOVI_MAX_PIECES]; /* [1, 2] */
> > +int64_t poly_coef[AV_DOVI_MAX_PIECES][3]; /* x^0, x^1, x^2 */
> > +/* AV_DOVI_MAPPING_MMR */
> > +uint8_t mmr_order[AV_DOVI_MAX_PIECES]; /* [1, 3] */
> > +int64_t mmr_constant[AV_DOVI_MAX_PIECES];
> > +int64_t mmr_coef[AV_DOVI_MAX_PIECES][3/* order - 1 */][7];
> > +} AVDOVIReshapingCurve;
> > +
> > +enum AVDOVINLQMethod {
> > +AV_DOVI_NLQ_NONE = -1,
> > +AV_DOVI_NLQ_LINEAR_DZ = 0,
> > +};
> > +
> > +/**
> > + * Coefficients of the non-linear inverse quantization. For the
> > interpretation
> > + * of these, see ETSI GS CCM 001.
> > + *
> > + * @note Cannot be extended without an ABI bump.
> > + */
> > +typedef struct AVDOVINLQParams {
> > +uint64_t nlq_offset;
> > +uint64_t vdr_in_max;
> > +/* AV_DOVI_NLQ_LINEAR_DZ */
> > +uint64_t linear_deadzone_slope;
> > +uint64_t linear_deadzone_threshold;
> > +} AVDOVINLQParams;
> > +
> > +/**
> > + * Dolby Vision RPU data mapping parameters.
> > + *
> > + * @note Cannot be extended without an ABI bump.
> > + */
> > +typedef struct AVDOVIDataMapping {
> > +uint8_t vdr_rpu_id;
> > +uint8_t mapping_color_space;
> > +uint8_t mapping_chroma_format_idc;
> > +AVDOVIReshapingCurve curves[3]; /* per component */
> > +
> > +/* Non-linear inverse quantization */
> > +enum AVDOVINLQMethod nlq_method_idc;
> > +uint32_t num_x_partitions;
> > +uint32_t num_y_partitions;
> > +AVDOVINLQParams nlq[3]; /* per component */
>
Re: [FFmpeg-devel] [PATCH v2 1/2] avformat/mov: add validate_box_size
Gyan Doshi (12021-12-22):
> Helper function to check if stored box size is correct and looks
> to be fully available.
> ---
> libavformat/mov.c | 34 ++
> 1 file changed, 34 insertions(+)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 2aed6e80ef..7de95b7ab0 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -80,6 +80,40 @@ static int mov_read_mfra(MOVContext *c, AVIOContext *f);
> static int64_t add_ctts_entry(MOVCtts** ctts_data, unsigned int* ctts_count,
> unsigned int* allocated_size,
>int count, int duration);
>
> +/** Check if the box size meets the requirements passed in limit and
> constraint_type.
> + * If input avio_size is valid, it checks if box size appears to be
> available.
> + *
> + * constraint_type may be
> + * 0 if the box size has to be exactly equal to limit
> + * -1 if the box size has to be at most limit
> + * 1 if the box size has to be at least limit
> + *
> + * Returns 0 if size meets requirements.
> + */
> +static int validate_box_size(MOVContext *c, MOVAtom atom, AVIOContext *pb,
> + int64_t pos, int64_t limit, int constraint_type)
> +{
> +int size_fit;
> +int64_t input_size = avio_size(pb);
> +
> +if (input_size > 0 &&
> +input_size - pos < atom.size) {
> +av_log(c->fc, AV_LOG_ERROR, "Box %s is truncated\n",
> av_fourcc2str(atom.type));
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (FFABS(constraint_type) > 1)
> +return AVERROR_BUG;
av_assert() whould have been the right choice here.
> +
> +switch(constraint_type) {
> +case 0: size_fit = atom.size == limit; break;
> +case -1: size_fit = atom.size <= limit; break;
> +case 1: size_fit = atom.size >= limit; break;
This code is unused, AFAICS. Not a good idea.
> +}
> +
> + return !size_fit;
> +}
> +
> static int mov_metadata_track_or_disc_number(MOVContext *c, AVIOContext *pb,
> unsigned len, const char *key)
> {
I think the changes belong in a single patch.
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 1/4] avcodec/mjpegdec: Fix exif rotation->displaymatrix conversion
Andreas Rheinhardt: > The cases in which there was flipping together with a rotation > that is not a multiple of the identity were wrong. > > Signed-off-by: Andreas Rheinhardt > --- > This whole patchset relies on the mismatch in av_display_rotation_set() > being solved by keeping the current behaviour and updating the > documentation. > > libavcodec/mjpegdec.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c > index 8b154ce0ab..0dbbc14bae 100644 > --- a/libavcodec/mjpegdec.c > +++ b/libavcodec/mjpegdec.c > @@ -2896,14 +2896,14 @@ the_end: > break; > case 5: > av_display_rotation_set(matrix, 90.0); > -av_display_matrix_flip(matrix, 0, 1); > +av_display_matrix_flip(matrix, 1, 0); > break; > case 6: > av_display_rotation_set(matrix, 90.0); > break; > case 7: > av_display_rotation_set(matrix, -90.0); > -av_display_matrix_flip(matrix, 0, 1); > +av_display_matrix_flip(matrix, 1, 0); > break; > case 8: > av_display_rotation_set(matrix, -90.0); > Will apply this patchset tonight unless there are objections. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v8 1/6] lavu/frame: Add Dolby Vision metadata side data type
20 Dec 2021, 16:31 by ffm...@haasn.xyz:
> From: Niklas Haas
>
> Signed-off-by: Niklas Haas
> ---
> doc/APIchanges| 3 +
> libavutil/dovi_meta.c | 12
> libavutil/dovi_meta.h | 143 ++
> libavutil/frame.c | 1 +
> libavutil/frame.h | 9 ++-
> libavutil/version.h | 2 +-
> 6 files changed, 168 insertions(+), 2 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 17aa664ca3..ff78edec88 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -14,6 +14,9 @@ libavutil: 2021-04-27
>
> API changes, most recent first:
>
> +2021-12-xx - xx - lavu 57.12.100 - frame.h
> + Add AV_FRAME_DATA_DOVI_METADATA.
> +
> 2021-12-xx - xx - lavf 59.10.100 - avformat.h
> Add AVFormatContext io_close2 which returns an int
>
> diff --git a/libavutil/dovi_meta.c b/libavutil/dovi_meta.c
> index 7bd08f6c54..60b4cb2376 100644
> --- a/libavutil/dovi_meta.c
> +++ b/libavutil/dovi_meta.c
> @@ -33,3 +33,15 @@ AVDOVIDecoderConfigurationRecord *av_dovi_alloc(size_t
> *size)
>
> return dovi;
> }
> +
> +AVDOVIMetadata *av_dovi_metadata_alloc(size_t *size)
> +{
> +AVDOVIMetadata *dovi = av_mallocz(sizeof(AVDOVIMetadata));
> +if (!dovi)
> +return NULL;
> +
> +if (size)
> +*size = sizeof(*dovi);
> +
> +return dovi;
> +}
> diff --git a/libavutil/dovi_meta.h b/libavutil/dovi_meta.h
> index 299911d434..25e6d7b42f 100644
> --- a/libavutil/dovi_meta.h
> +++ b/libavutil/dovi_meta.h
> @@ -29,6 +29,7 @@
>
> #include
> #include
> +#include "rational.h"
>
> /*
> * DOVI configuration
> @@ -67,4 +68,146 @@ typedef struct AVDOVIDecoderConfigurationRecord {
> */
> AVDOVIDecoderConfigurationRecord *av_dovi_alloc(size_t *size);
>
> +/**
> + * Dolby Vision RPU data header.
> + *
> + * @note Cannot be extended without an ABI bump.
> + */
> +typedef struct AVDOVIRpuDataHeader {
> +uint8_t rpu_type;
> +uint16_t rpu_format;
> +uint8_t vdr_rpu_profile;
> +uint8_t vdr_rpu_level;
> +uint8_t chroma_resampling_explicit_filter_flag;
> +uint8_t coef_data_type; /* informative, lavc always converts to fixed */
> +uint8_t coef_log2_denom;
> +uint8_t vdr_rpu_normalized_idc;
> +uint8_t bl_video_full_range_flag;
> +uint8_t bl_bit_depth; /* [8, 16] */
> +uint8_t el_bit_depth; /* [8, 16] */
> +uint8_t vdr_bit_depth; /* [8, 16] */
> +uint8_t spatial_resampling_filter_flag;
> +uint8_t el_spatial_resampling_filter_flag;
> +uint8_t disable_residual_flag;
> +} AVDOVIRpuDataHeader;
> +
> +enum AVDOVIMappingMethod {
> +AV_DOVI_MAPPING_POLYNOMIAL = 0,
> +AV_DOVI_MAPPING_MMR = 1,
> +};
> +
> +/**
> + * Coefficients of a piece-wise function. The pieces of the function span the
> + * value ranges between two adjacent pivot values.
> + *
> + * @note Cannot be extended without an ABI bump.
> + */
> +#define AV_DOVI_MAX_PIECES 8
> +typedef struct AVDOVIReshapingCurve {
> +uint8_t num_pivots; /* [2, 9] */
> +uint16_t pivots[AV_DOVI_MAX_PIECES + 1];/* sorted ascending */
> +enum AVDOVIMappingMethod mapping_idc[AV_DOVI_MAX_PIECES];
> +/* AV_DOVI_MAPPING_POLYNOMIAL */
> +uint8_t poly_order[AV_DOVI_MAX_PIECES]; /* [1, 2] */
> +int64_t poly_coef[AV_DOVI_MAX_PIECES][3]; /* x^0, x^1, x^2 */
> +/* AV_DOVI_MAPPING_MMR */
> +uint8_t mmr_order[AV_DOVI_MAX_PIECES]; /* [1, 3] */
> +int64_t mmr_constant[AV_DOVI_MAX_PIECES];
> +int64_t mmr_coef[AV_DOVI_MAX_PIECES][3/* order - 1 */][7];
> +} AVDOVIReshapingCurve;
> +
> +enum AVDOVINLQMethod {
> +AV_DOVI_NLQ_NONE = -1,
> +AV_DOVI_NLQ_LINEAR_DZ = 0,
> +};
> +
> +/**
> + * Coefficients of the non-linear inverse quantization. For the
> interpretation
> + * of these, see ETSI GS CCM 001.
> + *
> + * @note Cannot be extended without an ABI bump.
> + */
> +typedef struct AVDOVINLQParams {
> +uint64_t nlq_offset;
> +uint64_t vdr_in_max;
> +/* AV_DOVI_NLQ_LINEAR_DZ */
> +uint64_t linear_deadzone_slope;
> +uint64_t linear_deadzone_threshold;
> +} AVDOVINLQParams;
> +
> +/**
> + * Dolby Vision RPU data mapping parameters.
> + *
> + * @note Cannot be extended without an ABI bump.
> + */
> +typedef struct AVDOVIDataMapping {
> +uint8_t vdr_rpu_id;
> +uint8_t mapping_color_space;
> +uint8_t mapping_chroma_format_idc;
> +AVDOVIReshapingCurve curves[3]; /* per component */
> +
> +/* Non-linear inverse quantization */
> +enum AVDOVINLQMethod nlq_method_idc;
> +uint32_t num_x_partitions;
> +uint32_t num_y_partitions;
> +AVDOVINLQParams nlq[3]; /* per component */
> +} AVDOVIDataMapping;
> +
> +typedef struct AVDOVIColorMetadata {
> +uint8_t dm_metadata_id;
> +uint8_t scene_refresh_flag;
> +
> +/**
> + * Coefficients of the custom Dolby Vision IPT-PQ matrices. These are to
> be
> + * used instead of the matrices indicated by the frame's colorspace tags.
> + * The output of
[FFmpeg-devel] [PATCH v2 2/2] avformat/mov: validate box size for stts
---
libavformat/mov.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7de95b7ab0..1e44c74944 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2969,6 +2969,12 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
avio_rb24(pb); /* flags */
entries = avio_rb32(pb);
+if (validate_box_size(c, atom, pb, avio_tell(pb)-8, 8+(int64_t)entries*8,
0)) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid or incomplete %s box in stream
%d\n",
+ av_fourcc2str(atom.type), c->fc->nb_streams-1);
+ return AVERROR_INVALIDDATA;
+}
+
av_log(c->fc, AV_LOG_TRACE, "track[%u].stts.entries = %u\n",
c->fc->nb_streams-1, entries);
--
2.33.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] [PATCH v2 1/2] avformat/mov: add validate_box_size
Helper function to check if stored box size is correct and looks
to be fully available.
---
libavformat/mov.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2aed6e80ef..7de95b7ab0 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -80,6 +80,40 @@ static int mov_read_mfra(MOVContext *c, AVIOContext *f);
static int64_t add_ctts_entry(MOVCtts** ctts_data, unsigned int* ctts_count,
unsigned int* allocated_size,
int count, int duration);
+/** Check if the box size meets the requirements passed in limit and
constraint_type.
+ * If input avio_size is valid, it checks if box size appears to be
available.
+ *
+ * constraint_type may be
+ * 0 if the box size has to be exactly equal to limit
+ * -1 if the box size has to be at most limit
+ * 1 if the box size has to be at least limit
+ *
+ * Returns 0 if size meets requirements.
+ */
+static int validate_box_size(MOVContext *c, MOVAtom atom, AVIOContext *pb,
+ int64_t pos, int64_t limit, int constraint_type)
+{
+int size_fit;
+int64_t input_size = avio_size(pb);
+
+if (input_size > 0 &&
+input_size - pos < atom.size) {
+av_log(c->fc, AV_LOG_ERROR, "Box %s is truncated\n",
av_fourcc2str(atom.type));
+return AVERROR_INVALIDDATA;
+}
+
+if (FFABS(constraint_type) > 1)
+return AVERROR_BUG;
+
+switch(constraint_type) {
+case 0: size_fit = atom.size == limit; break;
+case -1: size_fit = atom.size <= limit; break;
+case 1: size_fit = atom.size >= limit; break;
+}
+
+ return !size_fit;
+}
+
static int mov_metadata_track_or_disc_number(MOVContext *c, AVIOContext *pb,
unsigned len, const char *key)
{
--
2.33.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 1/2] avformat/mxf: support MCA audio information
tis 2021-12-21 klockan 21:24 +0100 skrev Marton Balint: > > > On Tue, 21 Dec 2021, Tomas Härdin wrote: > > > tis 2021-12-21 klockan 11:44 +0100 skrev Marc-Antoine ARNAUD: > > > Le ven. 17 déc. 2021 à 19:12, Marton Balint a > > > écrit : > > > > > > > > > > > > > > > On Fri, 17 Dec 2021, Marc-Antoine ARNAUD wrote: > > > > > > > > > Hi all, > > > > > > > > > > Can I have an update on this patch submission ? > > > > > Is something required to be done before it can be merged ? > > > > > > > > New channel layout API is on its way, which makes in-demuxer > > > > channel > > > > reordering uneeded. Therefore the reordering option should not > > > > be > > > > added > > > > as it is in this patch. I can rework the patch after the > > > > channel > > > > layout > > > > API is in. (should happen in a couple of weeks at most). > > > > > > > > Regards, > > > > Marton > > > > > > > > > > So it will happen only after the release 5 of FFMpeg right ? > > Not sure. There were people who wanted the merge the channel layout > api > before the release. > > > > > > > Is it possible to merge it, and we can rework it after the new > > > API is > > > released ? > > > Patches are related to IMF (new format) patches, and if FFmpeg > > > can > > > accept > > > IMF without MCA support it will generate a lot of errors in audio > > > mapping. > > > So even if it's not performant for now, is it possible to imagine > > > to > > > merge > > > patches and rework after ? > > > > I suspect this might create problems for the people writing the > > reordering API > > It is not matter of performance, we should not introduce a hack such > as > reordering PCM channels in a demuxer if there is a better solution on > the > horizon. > > If this is urgent, we could merge it without reordering support. I think we can trust our users to maintain their own forks if they need special hacks /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".
Re: [FFmpeg-devel] [PATCH 1/2] avformat/mov: add validate_box_size
> On Dec 22, 2021, at 7:30 PM, Gyan Doshi wrote:
>
> Helper function to check if stored box size is correct and looks
> to be fully available.
> ---
> libavformat/mov.c | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 2aed6e80ef..2cc9e699de 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -80,6 +80,38 @@ static int mov_read_mfra(MOVContext *c, AVIOContext *f);
> static int64_t add_ctts_entry(MOVCtts** ctts_data, unsigned int* ctts_count,
> unsigned int* allocated_size,
> int count, int duration);
>
> +/** Check if the box size meets the requirements passed in limit and
> constraint_type.
> + * If input avio_size is valid, it checks if box size appears to be
> available.
> + *
> + * constraint_type may be
> + * 0 if the box size has to be exactly equal to limit
> + * -1 if the box size has to be at most limit
> + * 1 if the box size has to be at least limit
> + *
> + * Returns 0 if size meets requirements.
> + */
> +static int validate_box_size(MOVContext *c, MOVAtom atom, AVIOContext *pb,
> + int64_t pos, int64_t limit, int constraint_type)
> +{
> +int size_fit;
> +int64_t input_size = avio_size(pb);
> +
> +if (input_size > 0 &&
> +input_size - pos < atom.size) {
> +av_log(c->fc, AV_LOG_ERROR, "Box %s is truncated\n",
> av_fourcc2str(atom.type));
> +return AVERROR_INVALIDDATA;
> +}
> +
> +switch(constraint_type) {
> +case 0: size_fit = atom.size == limit; break;
> +case -1: size_fit = atom.size <= limit; break;
> +case 1: size_fit = atom.size >= limit; break;
> +default: return AVERROR_INVALIDDATA;
The default case doesn’t come from invalid data, I prefer assert and
return AVERROR(EINVAL) or AVERROR_BUG.
> +}
> +
> + return !size_fit;
> +}
> +
> static int mov_metadata_track_or_disc_number(MOVContext *c, AVIOContext *pb,
> unsigned len, const char *key)
> {
> --
> 2.33.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 v2] avformat/mov: abort reading truncated stts
Patch superseded by new patch using helper function.
On 2021-12-21 10:20 am, Gyan Doshi wrote:
On 2021-12-21 03:06 am, Michael Niedermayer wrote:
On Mon, Dec 20, 2021 at 10:21:53PM +0100, Michael Niedermayer wrote:
On Tue, Dec 21, 2021 at 02:31:33AM +0530, Gyan Doshi wrote:
On 2021-12-21 02:24 am, Andreas Rheinhardt wrote:
Gyan Doshi:
On 2021-12-21 02:18 am, Andreas Rheinhardt wrote:
Gyan Doshi:
Avoids overreading the box and ingesting absurd values into
stts_data
---
libavformat/mov.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2aed6e80ef..5a7209837f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2935,6 +2935,11 @@ static int mov_read_stts(MOVContext *c,
AVIOContext *pb, MOVAtom atom)
avio_rb24(pb); /* flags */
entries = avio_rb32(pb);
+ if (atom.size < 8 + (int64_t)entries*8) {
+ av_log(c->fc, AV_LOG_ERROR, "Truncated STTS box for st
%d.\n", c->fc->nb_streams-1);
+ return AVERROR_INVALIDDATA;
+ }
+
av_log(c->fc, AV_LOG_TRACE, "track[%u].stts.entries =
%u\n",
c->fc->nb_streams-1, entries);
This might fix the issue with the fuzzer sample Michael gave
you, but
what would stop the fuzzer (or a malicious adversary) from
simply using
a gigantic atom size?
Do you want the comparison to switch to a strict inequality?
No, because it might be that the adversary just uses the expected
size,
so this would not fix anything.
There are real world multi-hour files with large stts boxes, so
there is no
robust solution for that, only heuristics.
lets take a closer look at the loop you are adding
sample_count = avio_rb32(pb);
sample_duration = avio_rb32(pb);
sc->stts_data[i].count= sample_count;
sc->stts_data[i].duration= sample_duration;
for (int j = 0; j < sample_count; j++) {
This also adds undefined behavior as j overflows when sample_count >
INT_MAX
I'll try to optimize by getting rid of the loop if I can, but this
discussion belongs to the patch for max_stts_delta.
How's this patch?
Regards,
Gyan
___
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 2/2] avformat/mov: validate box size for stts
---
libavformat/mov.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2cc9e699de..59ee7ed2a9 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2967,6 +2967,12 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
avio_rb24(pb); /* flags */
entries = avio_rb32(pb);
+if (validate_box_size(c, atom, pb, avio_tell(pb)-8, 8+(int64_t)entries*8,
0)) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid or incomplete %s box in stream
%d\n",
+ av_fourcc2str(atom.type), c->fc->nb_streams-1);
+ return AVERROR_INVALIDDATA;
+}
+
av_log(c->fc, AV_LOG_TRACE, "track[%u].stts.entries = %u\n",
c->fc->nb_streams-1, entries);
--
2.33.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] [PATCH 1/2] avformat/mov: add validate_box_size
Helper function to check if stored box size is correct and looks
to be fully available.
---
libavformat/mov.c | 32
1 file changed, 32 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2aed6e80ef..2cc9e699de 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -80,6 +80,38 @@ static int mov_read_mfra(MOVContext *c, AVIOContext *f);
static int64_t add_ctts_entry(MOVCtts** ctts_data, unsigned int* ctts_count,
unsigned int* allocated_size,
int count, int duration);
+/** Check if the box size meets the requirements passed in limit and
constraint_type.
+ * If input avio_size is valid, it checks if box size appears to be
available.
+ *
+ * constraint_type may be
+ * 0 if the box size has to be exactly equal to limit
+ * -1 if the box size has to be at most limit
+ * 1 if the box size has to be at least limit
+ *
+ * Returns 0 if size meets requirements.
+ */
+static int validate_box_size(MOVContext *c, MOVAtom atom, AVIOContext *pb,
+ int64_t pos, int64_t limit, int constraint_type)
+{
+int size_fit;
+int64_t input_size = avio_size(pb);
+
+if (input_size > 0 &&
+input_size - pos < atom.size) {
+av_log(c->fc, AV_LOG_ERROR, "Box %s is truncated\n",
av_fourcc2str(atom.type));
+return AVERROR_INVALIDDATA;
+}
+
+switch(constraint_type) {
+case 0: size_fit = atom.size == limit; break;
+case -1: size_fit = atom.size <= limit; break;
+case 1: size_fit = atom.size >= limit; break;
+default: return AVERROR_INVALIDDATA;
+}
+
+ return !size_fit;
+}
+
static int mov_metadata_track_or_disc_number(MOVContext *c, AVIOContext *pb,
unsigned len, const char *key)
{
--
2.33.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] libavformat: add side_data copy in concat demuxer
Gerard Sole (12021-12-15): > Adds support for concat demuxer to copy the side data information > from the input file to the resulting file. It will behave like the > metadata copy, where the metadata of the first file is kept in the > the output file. > > Extract the current code that already performs the stream side_data > copy into a separate method and reuse the method in the concat demuxer. > > Signed-off-by: Gerard Sole > --- > libavformat/concatdec.c | 1 + > libavformat/internal.h | 9 + > libavformat/utils.c | 9 + > tests/ref/fate/concat-demuxer-extended-lavf-mxf | 2 +- > tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10 | 2 +- > tests/ref/fate/concat-demuxer-simple1-lavf-mxf | 1 + > tests/ref/fate/concat-demuxer-simple1-lavf-mxf_d10 | 1 + > tests/ref/fate/concat-demuxer-simple2-lavf-ts | 1 + > 8 files changed, 24 insertions(+), 2 deletions(-) Applied, thanks, and again sorry for the delay. 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] Politics
> -Original Message- > From: ffmpeg-devel On Behalf Of Michael > Niedermayer > Sent: Tuesday, December 21, 2021 7:39 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] Politics > > On Mon, Dec 20, 2021 at 11:20:38PM +, Soft Works wrote: > [...] > > > Enlightened by this, let's go back to to your example. The EU frame has a > > > > > duration of 40ms, the US frame 33.3ms. The US frame start 0.02ms later > and > > > > > is fully included in the duration of the EU frame. > > > > > > > > Seems I accidentally deleted a paragraph: > > > > > > > > The two frames are almost congruent in start and to a large percentage in > duration, and as they are meant to present the same picture > > > > it cannot happen at all that only one of them would have a hard change > (like from white to black or something appearing or disappearing within a > short > > video frames often are not sampled accross the whole period representing the > frame. just look at some video with fast moving things > > now what can give you a sub ms change > a scene change, an instantaneos cut from one scene to another > a flipped light switch, an explosion, an electric arc striking something > a camera flash, a spinning wheel with hole or a black/white pattern > a laser pointer just gently waving over your camera or something seen by > your camera, a fast moving object between the camera and light source > and many more Yes, but that invalidates your claim that videos created from computer generated sources would always be "exact". And in fact those things are done in a very different way. I'm familiar with 3D animations since the initial release of 3D Studio (the DOS based one, not Max), and some friends of mine are doing this on a professional basis, so I'm pretty familiar with the procedures. It is important to understand that 3D animations, with its tooling and all the techniques involved are not doing simulations of reality. Instead, it's only about creating visuals that look like reality as close as possible, and the methods involved are in many ways different from the actual physics by which our reality is driven. So, one important thing to note is, that it doesn't work in a way like you described above, that an animation is created once, independent of presentation framerate, and then you could create videos from that definition at arbitrary framerates - no way to do it like that, given the way animations are done nowadays. Just the opposite is true: I don't know any other video creation discipline where the individual output frame "raster" is more important and getting more attention and individual work than with computer animations. After the creative part (and other steps) are done, the whole animation is undergoing another stage that is all about output frames. Every single frame of the animation is rendered for the given output framerate, and all timings key-frame timings and values are specifically adjusted for that output framerate. There are many reasons why this needs to be done; for most, it burns down to avoiding visual artifacts, imperfections, "ghost" visuals and also for having "clean cuts" (intra-scene, not the cutting that is done even later between scenes). This is a tedious and time-consuming process which can take many weeks any a large team, depending on the length of the output. When an output at a different framerate is needed, that whole process needs to be repeated, and in the end you will have a different animation definition for the new framerate with hundreds or thousands of tiny differences. Another point one might find interesting is that none of those applications is working with time bases at precisions like we are talking about here. I'm still wondering whether somebody will get the twist... 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] MAINTAINERS: add my gpg fingerprint
Signed-off-by: Haihao Xiang --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 50ee5efecc..c065e94498 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -611,6 +611,7 @@ Daniel Verkamp78A6 07ED 782C 653E C628 B8B9 F0EB 8DD8 2F0E 21C7 FFmpeg release signing keyFCF9 86EA 15E6 E293 A564 4F10 B432 2F04 D676 58D8 Ganesh AjjanagaddeC96A 848E 97C3 CEA2 AB72 5CE4 45F9 6A2D 3C36 FB1B Gwenole Beauchesne2E63 B3A6 3E44 37E2 017D 2704 53C7 6266 B153 99C4 +Haihao Xiang (haihao) 1F0C 31E8 B4FE F7A4 4DC1 DC99 E0F5 76D4 76FC 437F Jaikrishnan Menon 61A1 F09F 01C9 2D45 78E1 C862 25DC 8831 AF70 D368 James Almer 7751 2E8C FD94 A169 57E6 9A7A 1463 01AD 7376 59E0 Jean Delvare 7CA6 9F44 60F1 BDC4 1FD2 C858 A552 6B9B B3CD 4E6A -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
