Re: [FFmpeg-devel] [PATCH v1 2/2] libavformat/file: initilize the fd to -1 instead of 0(valid fd) in case unexpected file close
On Thu, Jul 11, 2019 at 11:16:49AM +0800, myp...@gmail.com wrote:
> On Wed, Jul 10, 2019 at 11:11 PM Limin Wang wrote:
> >
> >
> > ping? I have developed code to use avio_open_dir function, after using
> > avio_close_dir
> > to release the resource, my ffmepg command will lost interact for the fd
> > 0 is closed by avio_close_dir.
> >
> >
> > On Tue, Jun 18, 2019 at 06:45:13PM +0800, lance.lmw...@gmail.com wrote:
> > > From: Limin Wang
> > >
> > > Signed-off-by: Limin Wang
> > > ---
> > > libavformat/file.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/libavformat/file.c b/libavformat/file.c
> > > index 08c7f8e6dd.. 40ae9ad2a8 100644
> > > --- a/libavformat/file.c
> > > +++ b/libavformat/file.c
> > > @@ -274,6 +274,7 @@ static int file_open_dir(URLContext *h)
> > > #if HAVE_LSTAT
> > > FileContext *c = h->priv_data;
> > >
> > > +c->fd = -1;
> I don't konw why need to change the fd , suppose we have a calling
> sequence like file_open ahead of file_open_dir, can we leak a fd
> resource ?
How to reproduce the issue:
1. add one debug message like below:
diff --git a/libavformat/file.c b/libavformat/file.c
index 08c7f8e6dd..f06f1aa506 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -266,6 +266,8 @@ static int64_t file_seek(URLContext *h, int64_t pos,
int whence)
static int file_close(URLContext *h)
{
FileContext *c = h->priv_data;
+
+av_log(h, AV_LOG_INFO, "fd: %d\n", c->fd);
return close(c->fd);
}
2. build the examples with make examples
3. run below example tool:
./doc/examples/avio_dir_cmd list ./doc/examples
78056 transcoding.o501(20) 644
156281847900 156281894900 156281847900
18744308 muxing501(20) 755
156281894800 156281894800 156281894800
[file @ 0x7f8e50406700] fd: 0
You can see valid fd 0 is closed unexpected, if you run in ffmpeg with
avio_dir_close option, you'll lose interaction cli control for the
close.
> > > c->dir = opendir(h->filename);
> > > if (!c->dir)
> > > return AVERROR(errno);
> > > --
> > > 2.21.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 v1 2/2] libavformat/file: initilize the fd to -1 instead of 0(valid fd) in case unexpected file close
On Wed, Jul 10, 2019 at 11:11 PM Limin Wang wrote: > > > ping? I have developed code to use avio_open_dir function, after using > avio_close_dir > to release the resource, my ffmepg command will lost interact for the fd > 0 is closed by avio_close_dir. > > > On Tue, Jun 18, 2019 at 06:45:13PM +0800, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > libavformat/file.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/libavformat/file.c b/libavformat/file.c > > index 08c7f8e6dd.. 40ae9ad2a8 100644 > > --- a/libavformat/file.c > > +++ b/libavformat/file.c > > @@ -274,6 +274,7 @@ static int file_open_dir(URLContext *h) > > #if HAVE_LSTAT > > FileContext *c = h->priv_data; > > > > +c->fd = -1; I don't konw why need to change the fd , suppose we have a calling sequence like file_open ahead of file_open_dir, can we leak a fd resource ? > > c->dir = opendir(h->filename); > > if (!c->dir) > > return AVERROR(errno); > > -- > > 2.21.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] fftools/ffmpeg: fix video frame lost sync for the dual input ts files with audio
From: Limin Wang
How to reproduce the problem(use two ts files with audio stream):
ffmpeg -i left_w_a.ts -i right_w_a.ts -filter_complex "hstack=inputs=2" -f null
-
With above command, the audio stream of the second input will be discarded
default, however the start_time is
initalized from the audio stream, so the old code will try to correct the ts
offset in the condition which will
cause the video frame out of sync and report some dts error like below:
[null @ 0x7fa78c000c00] Application provided invalid, non monotonically
increasing dts to muxer in stream 0: 43 >= 43
[null @ 0x7fa78c000c00] Application provided invalid, non monotonically
increasing dts to muxer in stream 0: 44 >= 44
[null @ 0x7fa78c000c00] Application provided invalid, non monotonically
increasing dts to muxer in stream 0: 45 >= 45
[null @ 0x7fa78c000c00] Application provided invalid, non monotonically
increasing dts to muxer in stream 0: 46 >= 46
[null @ 0x7fa78c000c00] Application provided invalid, non monotonically
increasing dts to muxer in stream 0: 47 >= 47
Or you can try with below command to reproduce the issue:
ffmpeg -i input_w_a.ts -i input_w_a.ts -filter_complex "ssim=f=ssim.log" -f
null -
You'll get below ssim result which isn't expected result for the two input is
same, the SSIM should be 1.0
SSIM Y:0.777353 (6.523822) U:0.964087 (14.447539) V:0.966739 (14.780661)
All:0.840039 (7.959872)
With the patch applied, the above testing command can get expected result.
Other solution are: use the setpts=PTS-STARTPTS filter or skip all audio stream
to avoid the timestamp adjustment.
Have passed "make fate SAMPLES=fate-suite" with mpeg2-ticket186 ref data is
updated.
Reviewed-by: Michael Niedermayer
Signed-off-by: Limin Wang
---
fftools/ffmpeg.c | 5 +-
tests/ref/fate/mpeg2-ticket186 | 703 +
2 files changed, 356 insertions(+), 352 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 01f0410..3fed926 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4378,13 +4378,16 @@ static int process_input(int file_index)
&& ifile->ts_offset == -is->start_time
&& (is->iformat->flags & AVFMT_TS_DISCONT)) {
int64_t new_start_time = INT64_MAX;
+int nb_used_streams = 0;
+
for (i=0; inb_streams; i++) {
AVStream *st = is->streams[i];
if(st->discard == AVDISCARD_ALL || st->start_time ==
AV_NOPTS_VALUE)
continue;
+nb_used_streams++;
new_start_time = FFMIN(new_start_time,
av_rescale_q(st->start_time, st->time_base, AV_TIME_BASE_Q));
}
-if (new_start_time > is->start_time) {
+if (nb_used_streams > 1 && new_start_time > is->start_time) {
av_log(is, AV_LOG_VERBOSE, "Correcting start time by
%"PRId64"\n", new_start_time - is->start_time);
ifile->ts_offset = -new_start_time;
}
diff --git a/tests/ref/fate/mpeg2-ticket186 b/tests/ref/fate/mpeg2-ticket186
index 31afda1..a734ae7 100644
--- a/tests/ref/fate/mpeg2-ticket186
+++ b/tests/ref/fate/mpeg2-ticket186
@@ -3,354 +3,355 @@
#codec_id 0: rawvideo
#dimensions 0: 352x288
#sar 0: 12/11
-0, 0, 0,1, 152064, 0x8f9d00c1
-0, 1, 1,1, 152064, 0x899fb8b1
-0, 2, 2,1, 152064, 0x7225cb39
-0, 3, 3,1, 152064, 0xf2becd8f
-0, 4, 4,1, 152064, 0xd56bc556
-0, 5, 5,1, 152064, 0x7ca54f36
-0, 6, 6,1, 152064, 0x06d7805c
-0, 7, 7,1, 152064, 0x469f3f87
-0, 8, 8,1, 152064, 0xdb2f57d5
-0, 9, 9,1, 152064, 0x3876c20c
-0, 10, 10,1, 152064, 0x5b670e79
-0, 11, 11,1, 152064, 0xdfe420e0
-0, 12, 12,1, 152064, 0x17578222
-0, 13, 13,1, 152064, 0x47e1cb26
-0, 14, 14,1, 152064, 0x168e35d6
-0, 15, 15,1, 152064, 0xe9d34b4e
-0, 16, 16,1, 152064, 0x5e395308
-0, 17, 17,1, 152064, 0x88e3b39f
-0, 18, 18,1, 152064, 0x6b099c51
-0, 19, 19,1, 152064, 0xb1a24ddf
-0, 20, 20,1, 152064, 0xcea840fc
-0, 21, 21,1, 152064, 0x98306d64
-0, 22, 22,1, 152064, 0xb05354d3
-0, 23, 23,1, 152064, 0xacac26f3
-0, 24, 24,1, 152064, 0xbccdf14b
-0, 25, 25,1, 152064, 0xd9398539
-0, 26, 26,1, 152064, 0x07aec13a
-0, 27, 27,1, 152064, 0xa6ef9440
-0, 28, 28,1, 152064, 0x0e7ab64e
-0,
[FFmpeg-devel] [PATCH 2/2] mpeg4_unpack_bframes: Merge close and flush
They are identical now.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpeg4_unpack_bframes_bsf.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/libavcodec/mpeg4_unpack_bframes_bsf.c
b/libavcodec/mpeg4_unpack_bframes_bsf.c
index 382070b423..1500d2135d 100644
--- a/libavcodec/mpeg4_unpack_bframes_bsf.c
+++ b/libavcodec/mpeg4_unpack_bframes_bsf.c
@@ -145,13 +145,7 @@ static int mpeg4_unpack_bframes_init(AVBSFContext *ctx)
return 0;
}
-static void mpeg4_unpack_bframes_flush(AVBSFContext *bsfc)
-{
-UnpackBFramesBSFContext *ctx = bsfc->priv_data;
-av_buffer_unref(&ctx->b_frame_ref);
-}
-
-static void mpeg4_unpack_bframes_close(AVBSFContext *bsfc)
+static void mpeg4_unpack_bframes_close_flush(AVBSFContext *bsfc)
{
UnpackBFramesBSFContext *ctx = bsfc->priv_data;
av_buffer_unref(&ctx->b_frame_ref);
@@ -166,7 +160,7 @@ const AVBitStreamFilter ff_mpeg4_unpack_bframes_bsf = {
.priv_data_size = sizeof(UnpackBFramesBSFContext),
.init = mpeg4_unpack_bframes_init,
.filter = mpeg4_unpack_bframes_filter,
-.flush = mpeg4_unpack_bframes_flush,
-.close = mpeg4_unpack_bframes_close,
+.flush = mpeg4_unpack_bframes_close_flush,
+.close = mpeg4_unpack_bframes_close_flush,
.codec_ids = codec_ids,
};
--
2.21.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] mpeg4_unpack_bframes: Avoid allocations and copies of packet structures
1. Since bd90a2ec, mpeg4_unpack_bframes caches whole packets instead of
just the pointer to the buffer and the buffer's size in order to be able
to make use of refcounting to avoid copying of data; this unfortunately
introduced copies of packet structures and side data (if existing),
although the only fields that are needed are the buffer-related ones
(data, size and buf). This can be changed without compromising the
advantages of refcounting by storing a reference to the buffer.
2. This change also makes it easy to use only one packet throughout
so that an allocation and free of an AVPacket structure per filtered
packet can be saved by switching to ff_bsf_get_packet_ref.
3. Furthermore, this commit also fixes a memleak introduced in bd90a2ec:
If a stored b_frame with side data was used for a later frame, the side
data would leak when the input frame's properties were copied into the
output frame.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpeg4_unpack_bframes_bsf.c | 77 ---
1 file changed, 35 insertions(+), 42 deletions(-)
diff --git a/libavcodec/mpeg4_unpack_bframes_bsf.c
b/libavcodec/mpeg4_unpack_bframes_bsf.c
index 1daf133ce5..382070b423 100644
--- a/libavcodec/mpeg4_unpack_bframes_bsf.c
+++ b/libavcodec/mpeg4_unpack_bframes_bsf.c
@@ -25,7 +25,7 @@
#include "mpeg4video.h"
typedef struct UnpackBFramesBSFContext {
-AVPacket *b_frame;
+AVBufferRef *b_frame_ref;
} UnpackBFramesBSFContext;
/* determine the position of the packed marker in the userdata,
@@ -56,32 +56,32 @@ static void scan_buffer(const uint8_t *buf, int buf_size,
}
}
-static int mpeg4_unpack_bframes_filter(AVBSFContext *ctx, AVPacket *out)
+static int mpeg4_unpack_bframes_filter(AVBSFContext *ctx, AVPacket *pkt)
{
UnpackBFramesBSFContext *s = ctx->priv_data;
int pos_p = -1, nb_vop = 0, pos_vop2 = -1, ret = 0;
-AVPacket *in;
-ret = ff_bsf_get_packet(ctx, &in);
+ret = ff_bsf_get_packet_ref(ctx, pkt);
if (ret < 0)
return ret;
-scan_buffer(in->data, in->size, &pos_p, &nb_vop, &pos_vop2);
+scan_buffer(pkt->data, pkt->size, &pos_p, &nb_vop, &pos_vop2);
av_log(ctx, AV_LOG_DEBUG, "Found %d VOP startcode(s) in this packet.\n",
nb_vop);
if (pos_vop2 >= 0) {
-if (s->b_frame->data) {
+if (s->b_frame_ref) {
av_log(ctx, AV_LOG_WARNING,
"Missing one N-VOP packet, discarding one B-frame.\n");
-av_packet_unref(s->b_frame);
+av_buffer_unref(&s->b_frame_ref);
}
-/* store the packed B-frame in the BSFContext */
-ret = av_packet_ref(s->b_frame, in);
-if (ret < 0) {
+/* store a reference to the packed B-frame's data in the BSFContext */
+s->b_frame_ref = av_buffer_ref(pkt->buf);
+if (!s->b_frame_ref) {
+ret = AVERROR(ENOMEM);
goto fail;
}
-s->b_frame->size -= pos_vop2;
-s->b_frame->data += pos_vop2;
+s->b_frame_ref->data = pkt->data + pos_vop2;
+s->b_frame_ref->size = pkt->size - pos_vop2;
}
if (nb_vop > 2) {
@@ -89,56 +89,49 @@ static int mpeg4_unpack_bframes_filter(AVBSFContext *ctx,
AVPacket *out)
"Found %d VOP headers in one packet, only unpacking one.\n", nb_vop);
}
-if (nb_vop == 1 && s->b_frame->data) {
-/* use frame from BSFContext */
-av_packet_move_ref(out, s->b_frame);
+if (nb_vop == 1 && s->b_frame_ref) {
+AVBufferRef *tmp = pkt->buf;
-/* use properties from current input packet */
-ret = av_packet_copy_props(out, in);
-if (ret < 0) {
-goto fail;
-}
+/* make tmp accurately reflect the packet's data */
+tmp->data = pkt->data;
+tmp->size = pkt->size;
+
+/* replace data in packet with stored data */
+pkt->buf = s->b_frame_ref;
+pkt->data = s->b_frame_ref->data;
+pkt->size = s->b_frame_ref->size;
+
+/* store reference to data into BSFContext */
+s->b_frame_ref = tmp;
-if (in->size <= MAX_NVOP_SIZE) {
-/* N-VOP */
+if (s->b_frame_ref->size <= MAX_NVOP_SIZE) {
+/* N-VOP - discard stored data */
av_log(ctx, AV_LOG_DEBUG, "Skipping N-VOP.\n");
-} else {
-/* copy packet into BSFContext */
-av_packet_move_ref(s->b_frame, in);
+av_buffer_unref(&s->b_frame_ref);
}
} else if (nb_vop >= 2) {
/* use first frame of the packet */
-av_packet_move_ref(out, in);
-out->size = pos_vop2;
+pkt->size = pos_vop2;
} else if (pos_p >= 0) {
-ret = av_packet_make_writable(in);
+ret = av_packet_make_writable(pkt);
if (ret < 0)
goto fail;
av_log(ctx, AV_LOG_DEBUG, "Updating DivX userdata (remove trailing
'p').\n");
-av_packet_move_ref(out, in);
/* remove 'p' (packed) from the end o
Re: [FFmpeg-devel] [FFmpeg-cvslog] vf_drawtext: Add pkt_pos, pkt_duration, pkt_size as variables
On 11-07-2019 02:01 AM, greg Luce wrote:
Yes, but it's not needed. These are constants, so they have to be
referenced within a function. There are two suitable ones: e and eif
e.g.
drawtext=text='pos %{e\:pkt_pos}, dur %{e\:pkt_duration}, size
%{e\:pkt_size}'
Oh my goodness gracious that's amazing! Thanks, I'll try that out now!
So I guess does that mean %{e\:n} does the same thing as %{n} ?
Almost, e will output as a float, so %{eif\:n\:d} will do the same thing.
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] [FFmpeg-cvslog] vf_drawtext: Add pkt_pos, pkt_duration, pkt_size as variables
> Yes, but it's not needed. These are constants, so they have to be
> referenced within a function. There are two suitable ones: e and eif
>
> e.g.
>
> drawtext=text='pos %{e\:pkt_pos}, dur %{e\:pkt_duration}, size
> %{e\:pkt_size}'
Oh my goodness gracious that's amazing! Thanks, I'll try that out now!
So I guess does that mean %{e\:n} does the same thing as %{n} ?
___
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] [FFmpeg-cvslog] vf_drawtext: Add pkt_pos, pkt_duration, pkt_size as variables
> You haven't tested your patch? Correct ___ 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] [FFmpeg-cvslog] vf_drawtext: Add pkt_pos, pkt_duration, pkt_size as variables
On 11-07-2019 01:33 AM, greg Luce wrote:
What output were you expecting with the first patch and what command did
you test to check?
I was hoping it would make
-filter_complex [0:v]drawtext=text='%{pkt_duration}'
(and also pkt_size and pkt_pos) work the same way as
-filter_complex [0:v]drawtext=text='%{frame_num}'
does currently, but all I got was error messages as if I'd put
nonsense between the {brackets}
Would this new patch make that work now?
Yes, but it's not needed. These are constants, so they have to be
referenced within a function. There are two suitable ones: e and eif
e.g.
drawtext=text='pos %{e\:pkt_pos}, dur %{e\:pkt_duration}, size
%{e\:pkt_size}'
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] [FFmpeg-cvslog] vf_drawtext: Add pkt_pos, pkt_duration, pkt_size as variables
On 7/10/19, greg Luce wrote:
>> What output were you expecting with the first patch and what command did
>> you test to check?
>
> I was hoping it would make
> -filter_complex [0:v]drawtext=text='%{pkt_duration}'
> (and also pkt_size and pkt_pos) work the same way as
> -filter_complex [0:v]drawtext=text='%{frame_num}'
> does currently, but all I got was error messages as if I'd put
> nonsense between the {brackets}
>
> Would this new patch make that work now?
You haven't tested your patch?
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
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] [FFmpeg-cvslog] vf_drawtext: Add pkt_pos, pkt_duration, pkt_size as variables
> What output were you expecting with the first patch and what command did
> you test to check?
I was hoping it would make
-filter_complex [0:v]drawtext=text='%{pkt_duration}'
(and also pkt_size and pkt_pos) work the same way as
-filter_complex [0:v]drawtext=text='%{frame_num}'
does currently, but all I got was error messages as if I'd put
nonsense between the {brackets}
Would this new patch make that work now?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
On 7/10/19, Eoff, Ullysses A wrote: >> -Original Message- >> From: Eoff, Ullysses A >> Sent: Tuesday, July 09, 2019 6:45 PM >> To: ffmpeg-devel@ffmpeg.org >> Cc: Eoff, Ullysses A >> Subject: [PATCH] avfilter: add rawdump filter >> >> This filter enables raw frames to be dumped to a >> file before they are sent through the auto-inserted >> scaler filter and useful when you want unscaled >> raw frames in an output file. >> > > The primary goal that I'm trying to achieve here is > dump raw "unscaled" yuv to an output file while > decoding a multi-resolution video. Unfortunately, > the ffmpeg utility auto-inserts a scaler into the filter > graph, so -f rawvideo doesn't suffice here since the > decoded data passes through the scaler before it's > handed off to the rawvideo filter. > > I experimented with the alternative methods suggested > in earlier feedback. More specifically, "reinit_filter" > and "split" were suggested. > > For "split" filter, I couldn't find a way that it could bypass > the auto-inserted scaler. > > Although -reinit_filter 0 works in some cases, it is quite > verbose. And I have found many other cases where it > doesn't work when we need to specify additional filters > (e.g. hwupload, hwdownload when doing qsv or vaapi > accelerated decoding with hw output formats). > > So, afaict, this patch is the only reliable method I can > find to intercept the decoded data before it reaches > the scaler for various use-cases (although the patch still > needs a little bit of work as pointed out in previous > replies). > > For added context, my organizations team and I contribute > to both msdk/qsv and vaapi plugins for ffmpeg and > gstreamer development. The idea is we want a way to > validate that direct decoder output is an exact bitmatch > across every decoder solution that we contribute > to (to provide a better and more consistent end-user > experience regardless of end-user choice). But since > ffmpeg auto-inserts this "scaler" and not all scaling > algo's are equal, it poses a challenge to verify. You can use this in your own branch. I see no valid usecase except in this testing scenario. > > Regards, > U. Artie > > ___ > 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] avfilter: add rawdump filter
> -Original Message- > From: Eoff, Ullysses A > Sent: Tuesday, July 09, 2019 6:45 PM > To: ffmpeg-devel@ffmpeg.org > Cc: Eoff, Ullysses A > Subject: [PATCH] avfilter: add rawdump filter > > This filter enables raw frames to be dumped to a > file before they are sent through the auto-inserted > scaler filter and useful when you want unscaled > raw frames in an output file. > The primary goal that I'm trying to achieve here is dump raw "unscaled" yuv to an output file while decoding a multi-resolution video. Unfortunately, the ffmpeg utility auto-inserts a scaler into the filter graph, so -f rawvideo doesn't suffice here since the decoded data passes through the scaler before it's handed off to the rawvideo filter. I experimented with the alternative methods suggested in earlier feedback. More specifically, "reinit_filter" and "split" were suggested. For "split" filter, I couldn't find a way that it could bypass the auto-inserted scaler. Although -reinit_filter 0 works in some cases, it is quite verbose. And I have found many other cases where it doesn't work when we need to specify additional filters (e.g. hwupload, hwdownload when doing qsv or vaapi accelerated decoding with hw output formats). So, afaict, this patch is the only reliable method I can find to intercept the decoded data before it reaches the scaler for various use-cases (although the patch still needs a little bit of work as pointed out in previous replies). For added context, my organizations team and I contribute to both msdk/qsv and vaapi plugins for ffmpeg and gstreamer development. The idea is we want a way to validate that direct decoder output is an exact bitmatch across every decoder solution that we contribute to (to provide a better and more consistent end-user experience regardless of end-user choice). But since ffmpeg auto-inserts this "scaler" and not all scaling algo's are equal, it poses a challenge to verify. Regards, U. Artie ___ 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] [FFmpeg-cvslog] vf_drawtext: Add pkt_pos, pkt_duration, pkt_size as variables
On 11-07-2019 12:52 AM, greg Luce wrote: This makes very little sense, please try hard to avoid similar commits in the future. What makes very little sense? Gyan Carl, if you mean the language is confusing I'm happy to write stuff differently! I'm very new to ffmpeg-devel in general. If you mean you can't picture someone actually using the feature this patch adds, I actually agree with you. I misunderstood what the patch would change, and am testing a further modification to add these variables to text expansion where they'd probably be more useful (and where I'd actually have a use for them) I've attached the patch, though I haven't tested building with it yet What output were you expecting with the first patch and what command did you test to check? 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] [FFmpeg-cvslog] vf_drawtext: Add pkt_pos, pkt_duration, pkt_size as variables
> > This makes very little sense, please try hard to avoid similar commits in > > the future. > What makes very little sense? > > Gyan Carl, if you mean the language is confusing I'm happy to write stuff differently! I'm very new to ffmpeg-devel in general. If you mean you can't picture someone actually using the feature this patch adds, I actually agree with you. I misunderstood what the patch would change, and am testing a further modification to add these variables to text expansion where they'd probably be more useful (and where I'd actually have a use for them) I've attached the patch, though I haven't tested building with it yet vf_drawtext - Add pkt_pos, pkt_duration, pkt_size to text expansion.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
On 10-07-2019 10:15 PM, Eoff, Ullysses A wrote: -Original Message- From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Gyan Sent: Wednesday, July 10, 2019 7:33 AM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter On 10-07-2019 07:51 PM, Eoff, Ullysses A wrote: -Original Message- From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Hendrik Leppkes Sent: Wednesday, July 10, 2019 4:13 AM To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter ... I believe using -reinit_filter 0 with ffmpeg can achieve such a result., as long as you make sure all filtering done (preferably none) is capable of on-the-fly changes. Excellent! I wouldn't have thought to try -reinit_filter 0 for such a scenario. I just tried it and it achieves the exact result we're looking for. But it's unfortunate that it generates a warning message for every frame processed. Is there a simple way to silence that message, yet still get other verbose logging (I don't want to flood our automation logs)? No. You'll have to upgrade the level in libavfilter/buffersrc.c I see. Would anyone object if I sent a patch to upgrade the level to AV_LOG_DEBUG? Yes, I would. A video stream with changing frame properties is atypical, so the user should be warned about it. Your specific use case specifically seems to involve regularly, and perhaps purposely, varying prop changes, so I understand you find these messages to be bloat. An acceptable middle ground would be to add three additional state variables (called, say, last_w, last_h, last_pix_fmt) which prints the warning only when the props change relative to the last time it changed. 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] avfilter: add rawdump filter
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Gyan > Sent: Wednesday, July 10, 2019 7:33 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter > > > > On 10-07-2019 07:51 PM, Eoff, Ullysses A wrote: > >> -Original Message- > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > >> Hendrik Leppkes > >> Sent: Wednesday, July 10, 2019 4:13 AM > >> To: FFmpeg development discussions and patches > >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter > >> > >> ... > >> I believe using -reinit_filter 0 with ffmpeg can achieve such a > >> result., as long as you make sure all filtering done (preferably none) > >> is capable of on-the-fly changes. > >> > > Excellent! I wouldn't have thought to try -reinit_filter 0 for such a > > scenario. I > > just tried it and it achieves the exact result we're looking for. But it's > > unfortunate > > that it generates a warning message for every frame processed. Is there a > > simple > > way to silence that message, yet still get other verbose logging (I don't > > want to > > flood our automation logs)? > > No. You'll have to upgrade the level in libavfilter/buffersrc.c > I see. Would anyone object if I sent a patch to upgrade the level to AV_LOG_DEBUG? > 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".
Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Nicolas George > Sent: Wednesday, July 10, 2019 7:53 AM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter > > Eoff, Ullysses A (12019-07-10): > > For the record, this "static" is a problem if multiple rawdump filters are > > specified in the graph. The initial reason for this was to open the file > > for > > writing on the first init (to overwrite any pre-existing file), then open > > for > > appending on successive reinit's (e.g. frame resolution changes). Thus, > > would need a better solution to achieve the same result without > > influencing other instances of the filter. > > The variable needs to be in the filter's private context, nothing more. > Each time init is called (i.e. for reinit on resolution change), the private context is a new instance. On first init we want mode="w" for each rawdump filter in the graph, but on reinit we want mode="a". How do we achieve this when every call to init passes a new private context instance. I am not very familiar with ffmpeg's programming API's, so maybe I'm missing something? > Regards, > > -- > Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Nicolas George > Sent: Wednesday, July 10, 2019 8:05 AM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter > > Eoff, Ullysses A (12019-07-10): > > Agree. There are many ways to specify format. But there are some formats > > which one might want to dump that some hw drivers can't output directly > > without conversion. > > In that case, your goal to avoid conversion is moot. > The goal is to avoid scaling ;-) > Regards, > > -- > Nicolas George ___ 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 v1 2/2] libavformat/file: initilize the fd to -1 instead of 0(valid fd) in case unexpected file close
ping? I have developed code to use avio_open_dir function, after using avio_close_dir to release the resource, my ffmepg command will lost interact for the fd 0 is closed by avio_close_dir. On Tue, Jun 18, 2019 at 06:45:13PM +0800, lance.lmw...@gmail.com wrote: > From: Limin Wang > > Signed-off-by: Limin Wang > --- > libavformat/file.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavformat/file.c b/libavformat/file.c > index 08c7f8e6dd..40ae9ad2a8 100644 > --- a/libavformat/file.c > +++ b/libavformat/file.c > @@ -274,6 +274,7 @@ static int file_open_dir(URLContext *h) > #if HAVE_LSTAT > FileContext *c = h->priv_data; > > +c->fd = -1; > c->dir = opendir(h->filename); > if (!c->dir) > return AVERROR(errno); > -- > 2.21.0 > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
Eoff, Ullysses A (12019-07-10): > Agree. There are many ways to specify format. But there are some formats > which one might want to dump that some hw drivers can't output directly > without conversion. In that case, your goal to avoid conversion is moot. 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] avfilter: add rawdump filter
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Lynne > Sent: Wednesday, July 10, 2019 7:52 AM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter > > > > > Jul 10, 2019, 3:26 PM by ullysses.a.e...@intel.com: > > >> -Original Message- > >> From: Paul B Mahol [mailto:one...@gmail.com] > >> Sent: Wednesday, July 10, 2019 7:20 AM > >> To: Eoff, Ullysses A > >> Cc: FFmpeg development discussions and patches > >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter > >> > >> On 7/10/19, Eoff, Ullysses A wrote: > >> >> -Original Message- > >> >> From: Paul B Mahol [mailto:one...@gmail.com] > >> >> Sent: Wednesday, July 10, 2019 3:25 AM > >> >> To: FFmpeg development discussions and patches > >> >> Cc: Eoff, Ullysses A > >> >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter > >> >> > >> >> On 7/10/19, Fu, Linjie wrote: > >> >> >> -Original Message- > >> >> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > >> >> >> Of Paul B Mahol > >> >> >> Sent: Wednesday, July 10, 2019 15:55 > >> >> >> To: FFmpeg development discussions and patches >> >> >> de...@ffmpeg.org> > >> >> >> Cc: Eoff, Ullysses A > >> >> >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter > >> >> >> > >> >> >> On 7/10/19, U. Artie Eoff wrote: > >> >> >> > This filter enables raw frames to be dumped to a > >> >> >> > file before they are sent through the auto-inserted > >> >> >> > scaler filter and useful when you want unscaled > >> >> >> > raw frames in an output file. > >> >> >> > > >> >> >> > >> >> >> Why? > >> >> >> > >> >> >> -f rawvideo doesn't work for you? > >> >> > > >> >> > unscaled raw video could be dumped through this filter in resolution > >> >> > changing cases. > >> >> > > >> >> > >> >> Maybe, I still fail how this filter is useful, when user can use split > >> >> filter to dump video > >> >> at any point in graph. > >> >> > >> > > >> > If there are already other ways to achieve the same result without this > >> > filter then that's great! Essentially, I'm trying to achieve exactly > >> > what > >> > Linjie stated so we can compare raw results across different decoder > >> > solutions. And the forced insertion of the auto scaler in ffmpeg makes > >> > that difficult for multi-resolution cases. > >> > >> Please provide examples of filtergraph where you are supposed to use > >> this "filter". > >> > > > > ffmpeg -v verbose -hwaccel vaapi -vaapi_device /dev/dri/renderD128 \ > > -i input.h264 -vf 'format=nv12,rawdump=file=./ffdump.yuv' -f null - > > > > You can make the decoder output nv12 directly via -hwaccel_output_format nv12 Agree. There are many ways to specify format. But there are some formats which one might want to dump that some hw drivers can't output directly without conversion. > ___ > 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] avfilter: add rawdump filter
> -Original Message- > From: Nicolas George [mailto:geo...@nsup.org] > Sent: Wednesday, July 10, 2019 7:37 AM > To: FFmpeg development discussions and patches > Cc: Eoff, Ullysses A > Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter > > U. Artie Eoff (12019-07-09): > > +FILE *rawdump_file; > > Independently from the question of whether this filter is useful or not, > I think the dump should have used AVIO. > Thanks for the tip! Even though this patch is redundant and unnecessary (based on feedback)... I will have a look at AVIO for future changes/patches. Cheers, U. Artie > Regards, > > -- > Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
Eoff, Ullysses A (12019-07-10): > For the record, this "static" is a problem if multiple rawdump filters are > specified in the graph. The initial reason for this was to open the file for > writing on the first init (to overwrite any pre-existing file), then open for > appending on successive reinit's (e.g. frame resolution changes). Thus, > would need a better solution to achieve the same result without > influencing other instances of the filter. The variable needs to be in the filter's private context, nothing more. 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] avfilter: add rawdump filter
Jul 10, 2019, 3:26 PM by ullysses.a.e...@intel.com: >> -Original Message- >> From: Paul B Mahol [mailto:one...@gmail.com] >> Sent: Wednesday, July 10, 2019 7:20 AM >> To: Eoff, Ullysses A >> Cc: FFmpeg development discussions and patches >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter >> >> On 7/10/19, Eoff, Ullysses A wrote: >> >> -Original Message- >> >> From: Paul B Mahol [mailto:one...@gmail.com] >> >> Sent: Wednesday, July 10, 2019 3:25 AM >> >> To: FFmpeg development discussions and patches >> >> Cc: Eoff, Ullysses A >> >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter >> >> >> >> On 7/10/19, Fu, Linjie wrote: >> >> >> -Original Message- >> >> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >> >> >> Of Paul B Mahol >> >> >> Sent: Wednesday, July 10, 2019 15:55 >> >> >> To: FFmpeg development discussions and patches > >> >> de...@ffmpeg.org> >> >> >> Cc: Eoff, Ullysses A >> >> >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter >> >> >> >> >> >> On 7/10/19, U. Artie Eoff wrote: >> >> >> > This filter enables raw frames to be dumped to a >> >> >> > file before they are sent through the auto-inserted >> >> >> > scaler filter and useful when you want unscaled >> >> >> > raw frames in an output file. >> >> >> > >> >> >> >> >> >> Why? >> >> >> >> >> >> -f rawvideo doesn't work for you? >> >> > >> >> > unscaled raw video could be dumped through this filter in resolution >> >> > changing cases. >> >> > >> >> >> >> Maybe, I still fail how this filter is useful, when user can use split >> >> filter to dump video >> >> at any point in graph. >> >> >> > >> > If there are already other ways to achieve the same result without this >> > filter then that's great! Essentially, I'm trying to achieve exactly what >> > Linjie stated so we can compare raw results across different decoder >> > solutions. And the forced insertion of the auto scaler in ffmpeg makes >> > that difficult for multi-resolution cases. >> >> Please provide examples of filtergraph where you are supposed to use >> this "filter". >> > > ffmpeg -v verbose -hwaccel vaapi -vaapi_device /dev/dri/renderD128 \ > -i input.h264 -vf 'format=nv12,rawdump=file=./ffdump.yuv' -f null - > You can make the decoder output nv12 directly via -hwaccel_output_format nv12 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> From: Eoff, Ullysses A
> +static av_cold int rawdump_init(AVFilterContext *avctx)
> +{
> +RawDumpContext *ctx = avctx->priv;
> +static char *mode = "w";
For the record, this "static" is a problem if multiple rawdump filters are
specified in the graph. The initial reason for this was to open the file for
writing on the first init (to overwrite any pre-existing file), then open for
appending on successive reinit's (e.g. frame resolution changes). Thus,
would need a better solution to achieve the same result without
influencing other instances of the filter.
> +
> +ctx->rawdump_file = fopen(ctx->rawdump_file_str, mode);
> +
> +if (ctx->rawdump_file == NULL) {
> +int err = AVERROR(errno);
> +char buf[128];
> +av_strerror(err, buf, sizeof(buf));
> +av_log(ctx, AV_LOG_ERROR, "Failed to open %s for dumping: %s\n",
> + ctx->rawdump_file_str, buf);
> +return err;
> +}
> +
> +av_log(ctx, AV_LOG_DEBUG, "Opened %s (mode:%s) for dumping.\n",
> + ctx->rawdump_file_str, mode);
> +
> +mode = "a";
> +
> +return 0;
> +}
> +
> +static av_cold void rawdump_uninit(AVFilterContext *avctx)
> +{
> +RawDumpContext *ctx = avctx->priv;
> +
> +if (ctx->rawdump_file != NULL)
> +fclose(ctx->rawdump_file);
> +}
> +
> +#define OFFSET(x) offsetof(RawDumpContext, x)
> +#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
> +static const AVOption rawdump_options[] = {
> +{"file", "Set file where to dump raw frames", OFFSET(rawdump_file_str),
> AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, FLAGS },
> +{ NULL }
> +};
> +
> +AVFILTER_DEFINE_CLASS(rawdump);
> +
> +static const AVFilterPad rawdump_inputs[] = {
> +{
> +.name = "default",
> +.type = AVMEDIA_TYPE_VIDEO,
> +.filter_frame = rawdump_filter_frame,
> +},
> +{ NULL }
> +};
> +
> +static const AVFilterPad rawdump_outputs[] = {
> +{
> +.name = "default",
> +.type = AVMEDIA_TYPE_VIDEO,
> +},
> +{ NULL }
> +};
> +
> +AVFilter ff_vf_rawdump = {
> +.name = "rawdump",
> +.description = NULL_IF_CONFIG_SMALL("Dump frames to file"),
> +.init = rawdump_init,
> +.uninit= rawdump_uninit,
> +.query_formats = rawdump_query_formats,
> +.priv_size = sizeof(RawDumpContext),
> +.priv_class= &rawdump_class,
> +.inputs= rawdump_inputs,
> +.outputs = rawdump_outputs,
> +};
> --
> 2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: fix video frame lost sync for the dual input ts files with audio
On 7/10/19, Limin Wang wrote: > On Tue, Jul 09, 2019 at 07:49:23PM +0200, Michael Niedermayer wrote: >> On Mon, Jul 08, 2019 at 06:34:12PM +0800, lance.lmw...@gmail.com wrote: >> > From: Limin Wang >> > >> > How to reproduce the problem(use two ts files with audio stream): >> > ffmpeg -i left_w_a.ts -i right_w_a.ts -filter_complex "hstack=inputs=2" >> > -f null - >> > >> > With above command, the audio stream of the second input will be >> > discarded default, however the start_time is >> > initalized from the audio stream, so the old code will try to correct >> > the ts offset in the condition which will >> > cause the video frame out of sync and report some dts error like below: >> > [null @ 0x7fa78c000c00] Application provided invalid, non monotonically >> > increasing dts to muxer in stream 0: 43 >= 43 >> > [null @ 0x7fa78c000c00] Application provided invalid, non monotonically >> > increasing dts to muxer in stream 0: 44 >= 44 >> > [null @ 0x7fa78c000c00] Application provided invalid, non monotonically >> > increasing dts to muxer in stream 0: 45 >= 45 >> > [null @ 0x7fa78c000c00] Application provided invalid, non monotonically >> > increasing dts to muxer in stream 0: 46 >= 46 >> > [null @ 0x7fa78c000c00] Application provided invalid, non monotonically >> > increasing dts to muxer in stream 0: 47 >= 47 >> > >> > Or you can try with below command to reproduce the issue: >> > ffmpeg -i input_w_a.ts -i input_w_a.ts -filter_complex "ssim=f=ssim.log" >> > -f null - >> > >> > You'll get below ssim result which isn't expected result for the two >> > input is same, the SSIM should be 1.0 >> > SSIM Y:0.777353 (6.523822) U:0.964087 (14.447539) V:0.966739 (14.780661) >> > All:0.840039 (7.959872) >> > >> > With the patch applied, the above testing command can get expected >> > result. >> > >> > other solution are: use the setpts=PTS-STARTPTS filter or skip all audio >> > stream to avoid the timestamp adjustment. >> > >> > Signed-off-by: Limin Wang >> > --- >> > fftools/ffmpeg.c | 5 - >> > 1 file changed, 4 insertions(+), 1 deletion(-) >> >> this breaks fate-mpeg2-ticket186 >> > > For the fate-mpeg2-ticket186 case, the new code wasn't triggered the > timestamp > adjustment for the audio is skiped and have one stream only. So we'll get > one > extra video frame in the beginning than old code, I have checked the next > 350 frames are bitexact. Can I update the tests/ref/fate/mpeg2-ticket186 > to fix it? > Yes, if change is correct, update relevant files. > below is the extra one frame bit info: > +0, 0, 0,1, 152064, 0x5c464d94 > > > >> [...] >> -- >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB >> >> When you are offended at any man's fault, turn to yourself and study your >> own failings. Then you will forget your anger. -- Epictetus > > > >> ___ >> 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] fftools/ffmpeg: fix video frame lost sync for the dual input ts files with audio
On Tue, Jul 09, 2019 at 07:49:23PM +0200, Michael Niedermayer wrote: > On Mon, Jul 08, 2019 at 06:34:12PM +0800, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > How to reproduce the problem(use two ts files with audio stream): > > ffmpeg -i left_w_a.ts -i right_w_a.ts -filter_complex "hstack=inputs=2" -f > > null - > > > > With above command, the audio stream of the second input will be discarded > > default, however the start_time is > > initalized from the audio stream, so the old code will try to correct the > > ts offset in the condition which will > > cause the video frame out of sync and report some dts error like below: > > [null @ 0x7fa78c000c00] Application provided invalid, non monotonically > > increasing dts to muxer in stream 0: 43 >= 43 > > [null @ 0x7fa78c000c00] Application provided invalid, non monotonically > > increasing dts to muxer in stream 0: 44 >= 44 > > [null @ 0x7fa78c000c00] Application provided invalid, non monotonically > > increasing dts to muxer in stream 0: 45 >= 45 > > [null @ 0x7fa78c000c00] Application provided invalid, non monotonically > > increasing dts to muxer in stream 0: 46 >= 46 > > [null @ 0x7fa78c000c00] Application provided invalid, non monotonically > > increasing dts to muxer in stream 0: 47 >= 47 > > > > Or you can try with below command to reproduce the issue: > > ffmpeg -i input_w_a.ts -i input_w_a.ts -filter_complex "ssim=f=ssim.log" -f > > null - > > > > You'll get below ssim result which isn't expected result for the two input > > is same, the SSIM should be 1.0 > > SSIM Y:0.777353 (6.523822) U:0.964087 (14.447539) V:0.966739 (14.780661) > > All:0.840039 (7.959872) > > > > With the patch applied, the above testing command can get expected result. > > > > other solution are: use the setpts=PTS-STARTPTS filter or skip all audio > > stream to avoid the timestamp adjustment. > > > > Signed-off-by: Limin Wang > > --- > > fftools/ffmpeg.c | 5 - > > 1 file changed, 4 insertions(+), 1 deletion(-) > > this breaks fate-mpeg2-ticket186 > For the fate-mpeg2-ticket186 case, the new code wasn't triggered the timestamp adjustment for the audio is skiped and have one stream only. So we'll get one extra video frame in the beginning than old code, I have checked the next 350 frames are bitexact. Can I update the tests/ref/fate/mpeg2-ticket186 to fix it? below is the extra one frame bit info: +0, 0, 0,1, 152064, 0x5c464d94 > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > When you are offended at any man's fault, turn to yourself and study your > own failings. Then you will forget your anger. -- Epictetus > ___ > 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] avfilter: add rawdump filter
U. Artie Eoff (12019-07-09): > +FILE *rawdump_file; Independently from the question of whether this filter is useful or not, I think the dump should have used AVIO. 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] avfilter: add rawdump filter
On 10-07-2019 07:51 PM, Eoff, Ullysses A wrote: -Original Message- From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Hendrik Leppkes Sent: Wednesday, July 10, 2019 4:13 AM To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter ... I believe using -reinit_filter 0 with ffmpeg can achieve such a result., as long as you make sure all filtering done (preferably none) is capable of on-the-fly changes. Excellent! I wouldn't have thought to try -reinit_filter 0 for such a scenario. I just tried it and it achieves the exact result we're looking for. But it's unfortunate that it generates a warning message for every frame processed. Is there a simple way to silence that message, yet still get other verbose logging (I don't want to flood our automation logs)? No. You'll have to upgrade the level in libavfilter/buffersrc.c 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] avfilter: add rawdump filter
On 7/10/19, Eoff, Ullysses A wrote: >> -Original Message- >> From: Paul B Mahol [mailto:one...@gmail.com] >> Sent: Wednesday, July 10, 2019 7:20 AM >> To: Eoff, Ullysses A >> Cc: FFmpeg development discussions and patches >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter >> >> On 7/10/19, Eoff, Ullysses A wrote: >> >> -Original Message- >> >> From: Paul B Mahol [mailto:one...@gmail.com] >> >> Sent: Wednesday, July 10, 2019 3:25 AM >> >> To: FFmpeg development discussions and patches >> >> >> >> Cc: Eoff, Ullysses A >> >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter >> >> >> >> On 7/10/19, Fu, Linjie wrote: >> >> >> -Original Message- >> >> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On >> >> >> Behalf >> >> >> Of Paul B Mahol >> >> >> Sent: Wednesday, July 10, 2019 15:55 >> >> >> To: FFmpeg development discussions and patches > >> >> de...@ffmpeg.org> >> >> >> Cc: Eoff, Ullysses A >> >> >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter >> >> >> >> >> >> On 7/10/19, U. Artie Eoff wrote: >> >> >> > This filter enables raw frames to be dumped to a >> >> >> > file before they are sent through the auto-inserted >> >> >> > scaler filter and useful when you want unscaled >> >> >> > raw frames in an output file. >> >> >> > >> >> >> >> >> >> Why? >> >> >> >> >> >> -f rawvideo doesn't work for you? >> >> > >> >> > unscaled raw video could be dumped through this filter in resolution >> >> > changing cases. >> >> > >> >> >> >> Maybe, I still fail how this filter is useful, when user can use split >> >> filter to dump video >> >> at any point in graph. >> >> >> > >> > If there are already other ways to achieve the same result without this >> > filter then that's great! Essentially, I'm trying to achieve exactly >> > what >> > Linjie stated so we can compare raw results across different decoder >> > solutions. And the forced insertion of the auto scaler in ffmpeg makes >> > that difficult for multi-resolution cases. >> >> Please provide examples of filtergraph where you are supposed to use >> this "filter". >> > > ffmpeg -v verbose -hwaccel vaapi -vaapi_device /dev/dri/renderD128 \ > -i input.h264 -vf 'format=nv12,rawdump=file=./ffdump.yuv' -f null - > >> > >> > Could you point me to an example of using split to achieve this? >> >> See documentation of split filter. > > Thanks. I will take a look and experiment with it. The resolution changing support is big hack, and should not be relied upon. Use some other tool. Like gstreamer. > >> >> > >> > U. Artie >> > >> >> >> >> > IMHO, it will be great if there are some options available to >> >> > disable/enable >> >> > the auto scaling filter >> >> > in pipeline, thus the whole stream doesn't need to be scaled into >> >> > the >> >> > same >> >> > size of the first frame. >> >> > The difference in scale algorithms will make it hard to compare the >> >> > output >> >> > with other decoder. >> >> > >> >> > - linjie >> >> > ___ >> >> > 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] avfilter: add rawdump filter
> -Original Message- > From: Paul B Mahol [mailto:one...@gmail.com] > Sent: Wednesday, July 10, 2019 7:20 AM > To: Eoff, Ullysses A > Cc: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter > > On 7/10/19, Eoff, Ullysses A wrote: > >> -Original Message- > >> From: Paul B Mahol [mailto:one...@gmail.com] > >> Sent: Wednesday, July 10, 2019 3:25 AM > >> To: FFmpeg development discussions and patches > >> Cc: Eoff, Ullysses A > >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter > >> > >> On 7/10/19, Fu, Linjie wrote: > >> >> -Original Message- > >> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > >> >> Of Paul B Mahol > >> >> Sent: Wednesday, July 10, 2019 15:55 > >> >> To: FFmpeg development discussions and patches >> >> de...@ffmpeg.org> > >> >> Cc: Eoff, Ullysses A > >> >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter > >> >> > >> >> On 7/10/19, U. Artie Eoff wrote: > >> >> > This filter enables raw frames to be dumped to a > >> >> > file before they are sent through the auto-inserted > >> >> > scaler filter and useful when you want unscaled > >> >> > raw frames in an output file. > >> >> > > >> >> > >> >> Why? > >> >> > >> >> -f rawvideo doesn't work for you? > >> > > >> > unscaled raw video could be dumped through this filter in resolution > >> > changing cases. > >> > > >> > >> Maybe, I still fail how this filter is useful, when user can use split > >> filter to dump video > >> at any point in graph. > >> > > > > If there are already other ways to achieve the same result without this > > filter then that's great! Essentially, I'm trying to achieve exactly what > > Linjie stated so we can compare raw results across different decoder > > solutions. And the forced insertion of the auto scaler in ffmpeg makes > > that difficult for multi-resolution cases. > > Please provide examples of filtergraph where you are supposed to use > this "filter". > ffmpeg -v verbose -hwaccel vaapi -vaapi_device /dev/dri/renderD128 \ -i input.h264 -vf 'format=nv12,rawdump=file=./ffdump.yuv' -f null - > > > > Could you point me to an example of using split to achieve this? > > See documentation of split filter. Thanks. I will take a look and experiment with it. > > > > > U. Artie > > > >> > >> > IMHO, it will be great if there are some options available to > >> > disable/enable > >> > the auto scaling filter > >> > in pipeline, thus the whole stream doesn't need to be scaled into the > >> > same > >> > size of the first frame. > >> > The difference in scale algorithms will make it hard to compare the > >> > output > >> > with other decoder. > >> > > >> > - linjie > >> > ___ > >> > 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] avfilter: add rawdump filter
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Hendrik Leppkes > Sent: Wednesday, July 10, 2019 4:13 AM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter > > On Wed, Jul 10, 2019 at 12:13 PM Fu, Linjie wrote: > > > > > -Original Message- > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > > > Of Paul B Mahol > > > Sent: Wednesday, July 10, 2019 15:55 > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Cc: Eoff, Ullysses A > > > Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter > > > > > > On 7/10/19, U. Artie Eoff wrote: > > > > This filter enables raw frames to be dumped to a > > > > file before they are sent through the auto-inserted > > > > scaler filter and useful when you want unscaled > > > > raw frames in an output file. > > > > > > > > > > Why? > > > > > > -f rawvideo doesn't work for you? > > > > unscaled raw video could be dumped through this filter in resolution > > changing cases. > > > > IMHO, it will be great if there are some options available to > > disable/enable the auto scaling filter > > in pipeline, thus the whole stream doesn't need to be scaled into the same > > size of the first frame. > > The difference in scale algorithms will make it hard to compare the output > > with other decoder. > > > > I believe using -reinit_filter 0 with ffmpeg can achieve such a > result., as long as you make sure all filtering done (preferably none) > is capable of on-the-fly changes. > Excellent! I wouldn't have thought to try -reinit_filter 0 for such a scenario. I just tried it and it achieves the exact result we're looking for. But it's unfortunate that it generates a warning message for every frame processed. Is there a simple way to silence that message, yet still get other verbose logging (I don't want to flood our automation logs)? U. Artie > - Hendrik > ___ > 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] avfilter: add rawdump filter
On 7/10/19, Eoff, Ullysses A wrote: >> -Original Message- >> From: Paul B Mahol [mailto:one...@gmail.com] >> Sent: Wednesday, July 10, 2019 3:25 AM >> To: FFmpeg development discussions and patches >> Cc: Eoff, Ullysses A >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter >> >> On 7/10/19, Fu, Linjie wrote: >> >> -Original Message- >> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >> >> Of Paul B Mahol >> >> Sent: Wednesday, July 10, 2019 15:55 >> >> To: FFmpeg development discussions and patches > >> de...@ffmpeg.org> >> >> Cc: Eoff, Ullysses A >> >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter >> >> >> >> On 7/10/19, U. Artie Eoff wrote: >> >> > This filter enables raw frames to be dumped to a >> >> > file before they are sent through the auto-inserted >> >> > scaler filter and useful when you want unscaled >> >> > raw frames in an output file. >> >> > >> >> >> >> Why? >> >> >> >> -f rawvideo doesn't work for you? >> > >> > unscaled raw video could be dumped through this filter in resolution >> > changing cases. >> > >> >> Maybe, I still fail how this filter is useful, when user can use split >> filter to dump video >> at any point in graph. >> > > If there are already other ways to achieve the same result without this > filter then that's great! Essentially, I'm trying to achieve exactly what > Linjie stated so we can compare raw results across different decoder > solutions. And the forced insertion of the auto scaler in ffmpeg makes > that difficult for multi-resolution cases. Please provide examples of filtergraph where you are supposed to use this "filter". > > Could you point me to an example of using split to achieve this? See documentation of split filter. > > U. Artie > >> >> > IMHO, it will be great if there are some options available to >> > disable/enable >> > the auto scaling filter >> > in pipeline, thus the whole stream doesn't need to be scaled into the >> > same >> > size of the first frame. >> > The difference in scale algorithms will make it hard to compare the >> > output >> > with other decoder. >> > >> > - linjie >> > ___ >> > 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] avfilter: add rawdump filter
> -Original Message- > From: Paul B Mahol [mailto:one...@gmail.com] > Sent: Wednesday, July 10, 2019 3:25 AM > To: FFmpeg development discussions and patches > Cc: Eoff, Ullysses A > Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter > > On 7/10/19, Fu, Linjie wrote: > >> -Original Message- > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > >> Of Paul B Mahol > >> Sent: Wednesday, July 10, 2019 15:55 > >> To: FFmpeg development discussions and patches >> de...@ffmpeg.org> > >> Cc: Eoff, Ullysses A > >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter > >> > >> On 7/10/19, U. Artie Eoff wrote: > >> > This filter enables raw frames to be dumped to a > >> > file before they are sent through the auto-inserted > >> > scaler filter and useful when you want unscaled > >> > raw frames in an output file. > >> > > >> > >> Why? > >> > >> -f rawvideo doesn't work for you? > > > > unscaled raw video could be dumped through this filter in resolution > > changing cases. > > > > Maybe, I still fail how this filter is useful, when user can use split > filter to dump video > at any point in graph. > If there are already other ways to achieve the same result without this filter then that's great! Essentially, I'm trying to achieve exactly what Linjie stated so we can compare raw results across different decoder solutions. And the forced insertion of the auto scaler in ffmpeg makes that difficult for multi-resolution cases. Could you point me to an example of using split to achieve this? U. Artie > > > IMHO, it will be great if there are some options available to disable/enable > > the auto scaling filter > > in pipeline, thus the whole stream doesn't need to be scaled into the same > > size of the first frame. > > The difference in scale algorithms will make it hard to compare the output > > with other decoder. > > > > - linjie > > ___ > > 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 v3] libavcodec/vp9: fix ref-frame size judging method
Hi, On Tue, Jul 9, 2019 at 7:22 AM Ronald S. Bultje wrote: > Hi, > > On Mon, Jul 8, 2019 at 6:23 PM Yan Cen wrote: > >> From: yancen >> >> There is no need all reference frame demension is valid in libvpx. >> > > Haven't we discussed this before? Anyway, it seems you're really eager to > get this in, so I'll drop my objection. (I still think this could cause > issues in HW decoders.) > I want to take this discussion one step further though. So, obviously, the central goal of this patch is to allow streams that can be decoded with libvpx to be decoded with ffvp9, specifically these that have frame size vs. ref size discrepancies that go beyond the limits formally allowed. We used to say that all refs have to comply with the limits, and you're changing it so that only one ref has to comply with the limits. I understand that so far. Now, what does libvpx do with the "invalid" refs? And what do hardware decoders do? What does the spec formally require? Is this mandated? Or optional? I can imagine several things happening in libvpx: - it just allows using invalid references like this; - it conceals as if the ref were missing and uses another one; - something else?? What does libvpx do, and what are we formally mandated to do, if anything? Are these streams considered proper? If so, isn't this an hardware exploit? Else, why have ref size limits at all? Ronald ___ 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 4/5 v2] mlpenc: improve lpc filtering
Jul 10, 2019, 4:56 AM by m...@jailuthra.in: > * fix a possible memory leak (apply_filter returned before freeing) > * use apply_filters in process_major_frame > * revert back to checking bounds with 24 bitdepth, as huff offset takes > care of it > > Signed-off-by: Jai Luthra > Tested the patchset, and while it does reduce lossless check failures, there's still many. Also 24 bit encoding still has way too many failures to be enabled. ___ 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] [PATCHv4] avcodec: Add librav1e encoder
On 10/07/2019 13:56, James Almer wrote: >> Heavily disagree. rav1e has its own 'tiles' option that determines the right >> cols/rows to use for a reason, and I will not be emulating libaomenc's algo >> instead of using the one provided by rav1e. It's confusing at best (since >> it goes against the rav1e API, and makes the official CLI and ffmpeg work >> differently). > > It's not libaom code, it's Mark Thompson's code. It derives > tile_rows_log2 and tile_cols_log2 values, which are what libaom expects, > from a Cols X Rows string (image size AVOption type), so you can tell > the encoder if you want a sample with exactly 4x2 tiles or such. That should be handled by the tile-columns and tile-rows options below, I think. > > But if you prefer the tiles option to match the behavior or rav1e's CLI, > then I'm fine with it. I do prefer this. >> Why? What's the use-case? "Being the same as libaomenc" is not a good use >> case. > > Command line option consistency between encoders is a good reason. It's > why you're using "qp" instead of "quantizer" or whatever, after all. > Rav1e lets you set cols and rows in log2 values much like libaom, right? > Then why not add options that map directly to them? Even if you don't > use Mark's code to convert Cols x Rows strings, both a tiles and > tile-cols/rows options can coexist, with the latter two taking > precedence over the former, since they give the user more control over > tiling. That's fair enough, having users set log2 values is crappy. I'll add these. - Derek ___ 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] [PATCHv4] avcodec: Add librav1e encoder
On 7/10/2019 9:22 AM, Derek Buitenhuis wrote:
> On 09/07/2019 22:06, James Almer wrote:
>>> @@ -3174,6 +3176,7 @@ libopenmpt_demuxer_deps="libopenmpt"
>>> libopus_decoder_deps="libopus"
>>> libopus_encoder_deps="libopus"
>>> libopus_encoder_select="audio_frame_queue"
>>> +librav1e_encoder_deps="librav1e"
>>
>> Needs to enable extract_extradata_bsf with a _select line as well.
>
> Fixed locally.
>
>>> +if (ctx->tiles >= 0) {
>>> +rret = rav1e_config_parse_int(cfg, "tiles", ctx->speed);
>>
>> ctx->tiles
>
> Fixed locally.
>
>>
>> Also, it may be a good idea to instead look into making the "tiles"
>> option parsing code in libaomenc shared and reuse it here, so it's
>> consistent between encoders. With it you can pass a Cols x Rows string
>> using the AV_OPT_TYPE_IMAGE_SIZE AVOption type and derive values you can
>> then map to rav1e's tile_rows_log2 and tile_cols_log2 options.
>
> Heavily disagree. rav1e has its own 'tiles' option that determines the right
> cols/rows to use for a reason, and I will not be emulating libaomenc's algo
> instead of using the one provided by rav1e. It's confusing at best (since
> it goes against the rav1e API, and makes the official CLI and ffmpeg work
> differently).
It's not libaom code, it's Mark Thompson's code. It derives
tile_rows_log2 and tile_cols_log2 values, which are what libaom expects,
from a Cols X Rows string (image size AVOption type), so you can tell
the encoder if you want a sample with exactly 4x2 tiles or such.
But if you prefer the tiles option to match the behavior or rav1e's CLI,
then I'm fine with it.
>
>> In the meantime, you can define tile-columns and tile-rows AVOptions and
>> directly map them to the aforementioned rav1e options.
>
> Why? What's the use-case? "Being the same as libaomenc" is not a good use
> case.
Command line option consistency between encoders is a good reason. It's
why you're using "qp" instead of "quantizer" or whatever, after all.
Rav1e lets you set cols and rows in log2 values much like libaom, right?
Then why not add options that map directly to them? Even if you don't
use Mark's code to convert Cols x Rows strings, both a tiles and
tile-cols/rows options can coexist, with the latter two taking
precedence over the former, since they give the user more control over
tiling.
>
>>> +case RA_ENCODER_STATUS_ENCODED:
>>> +if (avctx->internal->draining)
>>> +goto retry;
>>> +return AVERROR(EAGAIN);
>>
>> Is rav1e_send_frame() guaranteed to not return
>> RA_ENCODER_STATUS_ENOUGH_DATA if called right after
>> rav1e_receive_packet() returned RA_ENCODER_STATUS_ENCODED?
>> In other words, if it encoded a frame but didn't return it, is it safe
>> to assume its buffers are not full and will not reject new data passed
>> to it?
>
> rav1e, in fact, never returns this error. I need to check what the
> guarantee is, though - I'm not sure what the future plans are.
Ok, should be good then.
>
>> If not, then we would have to do goto retry here unconditionally,
>> draining or not. The doxy for avcodec_receive_packet and
>> avcodec_send_frame state that when one returns EAGAIN, the other is
>> guaranteed to return something else.
>
> [...]
>
> - Derek
> ___
> 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] [PATCHv4] avcodec: Add librav1e encoder
On 09/07/2019 21:23, Moritz Barsnick wrote: >> +Sets the minimum quantizer (ceiling) to use when in bitrate mdoe. > > Typo -> "mode" Fixed locally. > >> +av_log(avctx, AV_LOG_ERROR, "Unknown return code from >> rav1e_send_frame.\n"); >> +return AVERROR_UNKNOWN; > > Feel free to include the error code in the message, as you did in > librav1e_receive_packet(). OK. - Derek ___ 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] [PATCHv4] avcodec: Add librav1e encoder
On 09/07/2019 22:06, James Almer wrote:
>> @@ -3174,6 +3176,7 @@ libopenmpt_demuxer_deps="libopenmpt"
>> libopus_decoder_deps="libopus"
>> libopus_encoder_deps="libopus"
>> libopus_encoder_select="audio_frame_queue"
>> +librav1e_encoder_deps="librav1e"
>
> Needs to enable extract_extradata_bsf with a _select line as well.
Fixed locally.
>> +if (ctx->tiles >= 0) {
>> +rret = rav1e_config_parse_int(cfg, "tiles", ctx->speed);
>
> ctx->tiles
Fixed locally.
>
> Also, it may be a good idea to instead look into making the "tiles"
> option parsing code in libaomenc shared and reuse it here, so it's
> consistent between encoders. With it you can pass a Cols x Rows string
> using the AV_OPT_TYPE_IMAGE_SIZE AVOption type and derive values you can
> then map to rav1e's tile_rows_log2 and tile_cols_log2 options.
Heavily disagree. rav1e has its own 'tiles' option that determines the right
cols/rows to use for a reason, and I will not be emulating libaomenc's algo
instead of using the one provided by rav1e. It's confusing at best (since
it goes against the rav1e API, and makes the official CLI and ffmpeg work
differently).
> In the meantime, you can define tile-columns and tile-rows AVOptions and
> directly map them to the aforementioned rav1e options.
Why? What's the use-case? "Being the same as libaomenc" is not a good use case.
>> +case RA_ENCODER_STATUS_ENCODED:
>> +if (avctx->internal->draining)
>> +goto retry;
>> +return AVERROR(EAGAIN);
>
> Is rav1e_send_frame() guaranteed to not return
> RA_ENCODER_STATUS_ENOUGH_DATA if called right after
> rav1e_receive_packet() returned RA_ENCODER_STATUS_ENCODED?
> In other words, if it encoded a frame but didn't return it, is it safe
> to assume its buffers are not full and will not reject new data passed
> to it?
rav1e, in fact, never returns this error. I need to check what the
guarantee is, though - I'm not sure what the future plans are.
> If not, then we would have to do goto retry here unconditionally,
> draining or not. The doxy for avcodec_receive_packet and
> avcodec_send_frame state that when one returns EAGAIN, the other is
> guaranteed to return something else.
[...]
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
On Wed, Jul 10, 2019 at 12:13 PM Fu, Linjie wrote: > > > -Original Message- > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > > Of Paul B Mahol > > Sent: Wednesday, July 10, 2019 15:55 > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Cc: Eoff, Ullysses A > > Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter > > > > On 7/10/19, U. Artie Eoff wrote: > > > This filter enables raw frames to be dumped to a > > > file before they are sent through the auto-inserted > > > scaler filter and useful when you want unscaled > > > raw frames in an output file. > > > > > > > Why? > > > > -f rawvideo doesn't work for you? > > unscaled raw video could be dumped through this filter in resolution changing > cases. > > IMHO, it will be great if there are some options available to disable/enable > the auto scaling filter > in pipeline, thus the whole stream doesn't need to be scaled into the same > size of the first frame. > The difference in scale algorithms will make it hard to compare the output > with other decoder. > I believe using -reinit_filter 0 with ffmpeg can achieve such a result., as long as you make sure all filtering done (preferably none) is capable of on-the-fly changes. - Hendrik ___ 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] avutil/mips: optimize UNPCK&SAD macros with MSA2.0 instruction.
On Tue, Jul 09, 2019 at 08:43:37PM +0800, Shiyou Yin wrote: > Loongson 3A4000 and 2k1000 has supported MSA2.0. > This patch optimized SAD_UB2_UH,UNPCK_R_SH_SW,UNPCK_SB_SH and UNPCK_SH_SW > with MSA2.0 instruction. > --- > configure | 5 + > libavutil/mips/generic_macros_msa.h | 42 > ++--- > 2 files changed, 44 insertions(+), 3 deletions(-) will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri 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] MIPS: replace addi with addiu
On Tue, Jul 09, 2019 at 09:10:33PM +0800, Shiyou Yin wrote: > >-Original Message- > >From: ffmpeg-devel-boun...@ffmpeg.org > >[mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > >YunQiang Su > >Sent: Tuesday, July 2, 2019 11:53 AM > >To: ffmpeg-devel@ffmpeg.org > >Cc: YunQiang Su > >Subject: [FFmpeg-devel] [PATCH] MIPS: replace addi with addiu > > > >addi/daddi are deprecated by MIPS for years, and MIPS r6 remove > >them. > > > >They should be replace with addiu: > > ADDIU performs the same arithmetic operation but > > does not trap on overflow. > >--- > > libavcodec/mips/cabac.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > >diff --git a/libavcodec/mips/cabac.h b/libavcodec/mips/cabac.h > >index 82cee29..2a05e5a 100644 > >--- a/libavcodec/mips/cabac.h > >+++ b/libavcodec/mips/cabac.h > >@@ -72,7 +72,7 @@ static av_always_inline int get_cabac_inline(CABACContext > >*c, > > > > "and %[tmp0], %[c_low], %[cabac_mask] \n\t" > > "bnez %[tmp0], 1f\n\t" > >-PTR_ADDI "%[tmp0], %[c_low], -0X01 \n\t" > >+PTR_ADDIU"%[tmp0], %[c_low], -0x01 \n\t" > > "xor %[tmp0], %[c_low], %[tmp0] \n\t" > > PTR_SRA "%[tmp0], %[tmp0],0x0f \n\t" > > PTR_ADDU "%[tmp0], %[tmp0],%[tables] \n\t" > >-- > >2.20.1 > > > > good suggestion. will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/utils, avcodec_open2: close codec on failure
On Tue, Jul 09, 2019 at 07:03:58PM -0700, James Zern wrote: > after a successful init if the function fails for another reason close > the codec without requiring FF_CODEC_CAP_INIT_CLEANUP which is meant to > cover init failures themselves. fixes a memory leak in those cases. > > BUG=oss-fuzz:15529 > > Signed-off-by: James Zern > --- > libavcodec/utils.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
On 7/10/19, Fu, Linjie wrote: >> -Original Message- >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >> Of Paul B Mahol >> Sent: Wednesday, July 10, 2019 15:55 >> To: FFmpeg development discussions and patches > de...@ffmpeg.org> >> Cc: Eoff, Ullysses A >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter >> >> On 7/10/19, U. Artie Eoff wrote: >> > This filter enables raw frames to be dumped to a >> > file before they are sent through the auto-inserted >> > scaler filter and useful when you want unscaled >> > raw frames in an output file. >> > >> >> Why? >> >> -f rawvideo doesn't work for you? > > unscaled raw video could be dumped through this filter in resolution > changing cases. > Maybe, I still fail how this filter is useful, when user can use split filter to dump video at any point in graph. > IMHO, it will be great if there are some options available to disable/enable > the auto scaling filter > in pipeline, thus the whole stream doesn't need to be scaled into the same > size of the first frame. > The difference in scale algorithms will make it hard to compare the output > with other decoder. > > - linjie > ___ > 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] avfilter: add rawdump filter
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Paul B Mahol > Sent: Wednesday, July 10, 2019 15:55 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Cc: Eoff, Ullysses A > Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter > > On 7/10/19, U. Artie Eoff wrote: > > This filter enables raw frames to be dumped to a > > file before they are sent through the auto-inserted > > scaler filter and useful when you want unscaled > > raw frames in an output file. > > > > Why? > > -f rawvideo doesn't work for you? unscaled raw video could be dumped through this filter in resolution changing cases. IMHO, it will be great if there are some options available to disable/enable the auto scaling filter in pipeline, thus the whole stream doesn't need to be scaled into the same size of the first frame. The difference in scale algorithms will make it hard to compare the output with other decoder. - linjie ___ 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] lavf/vf_vpp_qsv: add support for QSV transpose filter
Add transpose support for qsv_vpp with rotate and hflip:
- rotate: [0, 3] support clockwise rotation of 0, 90, 180, 270;
- hflip: [0, 1] support horizontal flip;
Configure with:
{"cclock_hflip","clock","cclock","clock_hflip","reversal","hflip","vflip"}
Limitation:
If pipeline contains resize, mirroring and other, VPP skips other filters
in MSDK when IOPattern equals d3d->d3d. So "cclock_hflip, clock_hflip, vflip"
will not work in d3d->d3d condition.
This pr is fixing this:
https://github.com/Intel-Media-SDK/MediaSDK/pull/1491
CMD:
ffmpeg -hwaccel qsv -c:v h264_qsv -i input.h264
-vf 'format=qsv,vpp_qsv=transpose=clock' -c:v h264_qsv output.h264
ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -c:v h264_qsv -i input.h264
-vf 'hwupload=extra_hw_frames=64,format=qsv,vpp_qsv=transpose=cclock_hflip'
-f rawvideo -pix_fmt nv12 ./transpose.yuv
Signed-off-by: Linjie Fu
---
libavfilter/vf_vpp_qsv.c | 101 ++-
1 file changed, 99 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
index dd05e8baff..01ff42a677 100644
--- a/libavfilter/vf_vpp_qsv.c
+++ b/libavfilter/vf_vpp_qsv.c
@@ -36,12 +36,15 @@
#include "libavformat/avformat.h"
#include "qsvvpp.h"
+#include "transpose.h"
#define OFFSET(x) offsetof(VPPContext, x)
#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM)
/* number of video enhancement filters */
-#define ENH_FILTERS_COUNT (5)
+#define ENH_FILTERS_COUNT (7)
+#define QSV_HAVE_ROTATION QSV_VERSION_ATLEAST(1, 17)
+#define QSV_HAVE_MIRRORING QSV_VERSION_ATLEAST(1, 19)
typedef struct VPPContext{
const AVClass *class;
@@ -54,6 +57,8 @@ typedef struct VPPContext{
mfxExtVPPDenoise denoise_conf;
mfxExtVPPDetail detail_conf;
mfxExtVPPProcAmp procamp_conf;
+mfxExtVPPRotation rotation_conf;
+mfxExtVPPMirroring mirroring_conf;
int out_width;
int out_height;
@@ -70,6 +75,10 @@ typedef struct VPPContext{
int crop_x;
int crop_y;
+int transpose;
+int rotate; /* rotate angle : [0, 90, 180, 270] */
+int hflip; /* flip mode : 0 = off, 1 = HORIZONTAL flip */
+
/* param for the procamp */
intprocamp;/* enable procamp */
float hue;
@@ -95,6 +104,15 @@ static const AVOption options[] = {
{ "contrast","ProcAmp contrast", OFFSET(contrast),
AV_OPT_TYPE_FLOAT,{ .dbl = 1.0 }, 0.0, 10.0, .flags = FLAGS},
{ "brightness", "ProcAmp brightness", OFFSET(brightness),
AV_OPT_TYPE_FLOAT,{ .dbl = 0.0 }, -100.0, 100.0, .flags = FLAGS},
+{ "transpose", "set transpose direction", OFFSET(transpose),
AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 6, FLAGS, "transpose"},
+{ "cclock_hflip", "rotate counter-clockwise with horizontal flip",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CCLOCK_FLIP }, .flags=FLAGS, .unit =
"transpose" },
+{ "clock", "rotate clockwise",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CLOCK }, .flags=FLAGS, .unit =
"transpose" },
+{ "cclock","rotate counter-clockwise",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CCLOCK }, .flags=FLAGS, .unit =
"transpose" },
+{ "clock_hflip", "rotate clockwise with horizontal flip",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CLOCK_FLIP }, .flags=FLAGS, .unit =
"transpose" },
+{ "reversal", "rotate by half-turn",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_REVERSAL}, .flags=FLAGS, .unit =
"transpose" },
+{ "hflip", "flip horizontally",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_HFLIP }, .flags=FLAGS, .unit =
"transpose" },
+{ "vflip", "flip vertically",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_VFLIP }, .flags=FLAGS, .unit =
"transpose" },
+
{ "cw", "set the width crop area expression", OFFSET(cw),
AV_OPT_TYPE_STRING, { .str = "iw" }, CHAR_MIN, CHAR_MAX, FLAGS },
{ "ch", "set the height crop area expression", OFFSET(ch),
AV_OPT_TYPE_STRING, { .str = "ih" }, CHAR_MIN, CHAR_MAX, FLAGS },
{ "cx", "set the x crop area expression", OFFSET(cx),
AV_OPT_TYPE_STRING, { .str = "(in_w-out_w)/2" }, CHAR_MIN, CHAR_MAX, FLAGS },
@@ -322,8 +340,87 @@ static int config_output(AVFilterLink *outlink)
param.ext_buf[param.num_ext_buf++] = (mfxExtBuffer*)&vpp->procamp_conf;
}
+if (vpp->transpose >= 0) {
+#ifdef QSV_HAVE_ROTATION
+switch (vpp->transpose) {
+case TRANSPOSE_CCLOCK_FLIP:
+vpp->rotate = MFX_ANGLE_270;
+vpp->hflip = MFX_MIRRORING_HORIZONTAL;
+break;
+case TRANSPOSE_CLOCK:
+vpp->rotate = MFX_ANGLE_90;
+vpp->hflip = MFX_MIRRORING_DISABLED;
+br
Re: [FFmpeg-devel] [PATCH 2/2] lavf/vf_vpp_qsv: add support for QSV transpose filter
> -Original Message-
> From: Li, Zhong
> Sent: Monday, July 8, 2019 11:16
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Fu, Linjie
> Subject: RE: [FFmpeg-devel] [PATCH 2/2] lavf/vf_vpp_qsv: add support for
> QSV transpose filter
>
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Tuesday, June 18, 2019 10:53 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie
> > Subject: [FFmpeg-devel] [PATCH 2/2] lavf/vf_vpp_qsv: add support for
> QSV
> > transpose filter
> >
> > Add transpose support for qsv_vpp with rotate and hflip:
> > - rotate: [0, 3] support clockwise rotation of 0, 90, 180, 270;
> > - hflip: [0, 1] support horizontal flip;
> >
> > Configure with:
> > {"cclock_hflip","clock","cclock","clock_hflip","reversal","hflip","vflip"}
> >
> > Limitation:
> > If pipeline contains resize, mirroring and other, VPP skips other
> > filters in
> > MSDK when IOPattern equals d3d->d3d. So "cclock_hflip, clock_hflip, vflip"
> > will not work in d3d->d3d condition.
>
> How user can aware this if not check the log message? And any MSDK github
> issue created?
Yes, a PR has been sent to support mirror when working on IOPattern equals
d3d->d3d.
https://github.com/Intel-Media-SDK/MediaSDK/pull/1491
> > CMD:
> > ffmpeg -hwaccel qsv -c:v h264_qsv -i input.h264
> > -vf 'format=qsv,vpp_qsv=transpose=clock' -c:v h264_qsv output.h264
> >
> > ffmpeg -init_hw_device qsv=foo -filter_hw_device foo -f rawvideo
> > -pix_fmt nv12 -s:v 1920x1080 -i input.nv12 -vf
> >
> >
> 'hwupload=extra_hw_frames=64,format=qsv,vpp_qsv=transpose=cclock_hf
> li
> > p'
> > -f rawvideo -pix_fmt nv12 -y ./transpose.yuv
>
> What is the platform tested? Probably adding MFXVideoVPP_Query() to
> runtime capability checking is a good idea.
Tested on KBL, it should have been supported early.
Will think of adding MFXVideoVPP_Query() in a separate patch.
> > Signed-off-by: Linjie Fu
> > ---
> > libavfilter/vf_vpp_qsv.c | 95
> > +++-
> > 1 file changed, 93 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c index
> > dd05e8baff..974fc7a255 100644
> > --- a/libavfilter/vf_vpp_qsv.c
> > +++ b/libavfilter/vf_vpp_qsv.c
> > @@ -36,12 +36,15 @@
> > #include "libavformat/avformat.h"
> >
> > #include "qsvvpp.h"
> > +#include "transpose.h"
> >
> > #define OFFSET(x) offsetof(VPPContext, x) #define FLAGS
> > (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM)
> >
> > /* number of video enhancement filters */ -#define ENH_FILTERS_COUNT
> > (5)
> > +#define ENH_FILTERS_COUNT (7)
> > +#define QSV_HAVE_ROTATION QSV_VERSION_ATLEAST(1, 17) #define
> > +QSV_HAVE_MIRRORING QSV_VERSION_ATLEAST(1, 19)
> >
> > typedef struct VPPContext{
> > const AVClass *class;
> > @@ -54,6 +57,8 @@ typedef struct VPPContext{
> > mfxExtVPPDenoise denoise_conf;
> > mfxExtVPPDetail detail_conf;
> > mfxExtVPPProcAmp procamp_conf;
> > +mfxExtVPPRotation rotation_conf;
> > +mfxExtVPPMirroring mirroring_conf;
> >
> > int out_width;
> > int out_height;
> > @@ -70,6 +75,10 @@ typedef struct VPPContext{
> > int crop_x;
> > int crop_y;
> >
> > +int transpose;
> > +int rotate; /* rotate angle : [0, 90, 180, 270] */
> > +int hflip; /* flip mode : 0 = off, 1 = HORIZONTAL
> > flip */
> > +
> > /* param for the procamp */
> > intprocamp;/* enable procamp */
> > float hue;
> > @@ -95,6 +104,15 @@ static const AVOption options[] = {
> > { "contrast","ProcAmp contrast",
> > OFFSET(contrast),AV_OPT_TYPE_FLOAT,{ .dbl = 1.0 }, 0.0,
> > 10.0, .flags = FLAGS},
> > { "brightness", "ProcAmp brightness",
> > OFFSET(brightness), AV_OPT_TYPE_FLOAT,{ .dbl = 0.0 }, -100.0,
> > 100.0, .flags = FLAGS},
> >
> > +{ "transpose", "set transpose direction", OFFSET(transpose),
> > AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 6, FLAGS, "transpose"},
> > +{ "cclock_hflip", "rotate counter-clockwise with horizontal flip",
> > 0, AV_OPT_TYPE_CONST, { .i64 =
> > TRANSPOSE_CCLOCK_FLIP }, .flags=FLAGS, .unit = "transpose" },
> > +{ "clock", "rotate clockwise",
> > 0, AV_OPT_TYPE_CONST, { .i64 =
> > TRANSPOSE_CLOCK }, .flags=FLAGS, .unit = "transpose" },
> > +{ "cclock","rotate counter-clockwise",
> > 0, AV_OPT_TYPE_CONST, { .i64 =
> > TRANSPOSE_CCLOCK }, .flags=FLAGS, .unit = "transpose" },
> > +{ "clock_hflip", "rotate clockwise with horizontal flip",
> > 0, AV_OPT_TYPE_CONST, { .i64 =
> > TRANSPOSE_CLOCK_FLIP }, .flags=FLAGS, .unit = "transpose" },
> > +{ "reversal", "rotate by half-turn",
> > 0, AV_OPT_TYPE_CONST, { .i64 =
> > TRANSPOSE_REVERSAL}, .flags=FLAGS, .unit = "transpose" },
> > +{ "hflip", "flip horizontally",
> > 0, AV_OPT_TYPE_CONST, { .i64 =
> > TRANSPO
Re: [FFmpeg-devel] [PATCH] lavc/videotoolboxenc: add hdr10, linear, hlg color transfer function for videotoolboxenc
On Wed, Jul 10, 2019, 11:06 Hendrik Leppkes wrote:
> On Wed, Jul 10, 2019 at 4:23 AM Dennis Mungai wrote:
> >
> > On Wed, Jul 10, 2019, 03:05 Aman Gupta wrote:
> >
> > > On Wed, Jun 26, 2019 at 4:25 AM wrote:
> > >
> > > > From: Limin Wang
> > > >
> > > > Below is the testing ffmpeg command for the setting:
> > > > ./ffmpeg -i input.ts -c:v hevc_videotoolbox -color_primaries bt2020
> > > > -colorspace bt2020_ncl -color_trc smpte2084 smpte2048.ts
> > > > ./ffmpeg -i input.ts -c:v hevc_videotoolbox -color_primaries bt2020
> > > > -colorspace bt2020_ncl -color_trc linear linear.ts
> > > > ./ffmpeg -i input.ts -c:v hevc_videotoolbox -color_primaries bt2020
> > > > -colorspace bt2020_ncl -color_trc arib-std-b67 hlg.ts
> > > >
> > >
> > > Patch looks reasonable to me. Will commit in a few days if no one else
> > > comments.
> > >
> > > Aman
> > >
> > >
> > > >
> > > > Signed-off-by: Limin Wang
> > > > ---
> > > > configure| 6 ++
> > > > libavcodec/videotoolboxenc.c | 16
> > > > 2 files changed, 22 insertions(+)
> > > >
> > > > diff --git a/configure b/configure
> > > > index 7cea9d4d73..0a5e940c0c 100755
> > > > --- a/configure
> > > > +++ b/configure
> > > > @@ -2260,6 +2260,9 @@ TOOLCHAIN_FEATURES="
> > > > TYPES_LIST="
> > > > kCMVideoCodecType_HEVC
> > > > kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange
> > > > +kCVImageBufferTransferFunction_SMPTE_ST_2084_PQ
> > > > +kCVImageBufferTransferFunction_ITU_R_2100_HLG
> > > > +kCVImageBufferTransferFunction_Linear
> > > > socklen_t
> > > > struct_addrinfo
> > > > struct_group_source_req
> > > > @@ -6044,6 +6047,9 @@ enabled videotoolbox && {
> > > > check_lib coreservices CoreServices/CoreServices.h
> > > > UTGetOSTypeFromString "-framework CoreServices"
> > > > check_func_headers CoreMedia/CMFormatDescription.h
> > > > kCMVideoCodecType_HEVC "-framework CoreMedia"
> > > > check_func_headers CoreVideo/CVPixelBuffer.h
> > > > kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange "-framework
> CoreVideo"
> > > > +check_func_headers CoreVideo/CVImageBuffer.h
> > > > kCVImageBufferTransferFunction_SMPTE_ST_2084_PQ "-framework
> CoreVideo"
> > > > +check_func_headers CoreVideo/CVImageBuffer.h
> > > > kCVImageBufferTransferFunction_ITU_R_2100_HLG "-framework CoreVideo"
> > > > +check_func_headers CoreVideo/CVImageBuffer.h
> > > > kCVImageBufferTransferFunction_Linear "-framework CoreVideo"
> > > > }
> > > >
> > > > check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
> > > > diff --git a/libavcodec/videotoolboxenc.c
> b/libavcodec/videotoolboxenc.c
> > > > index f8ccdea52d..0dc6eb4cf4 100644
> > > > --- a/libavcodec/videotoolboxenc.c
> > > > +++ b/libavcodec/videotoolboxenc.c
> > > > @@ -915,6 +915,22 @@ static int
> get_cv_transfer_function(AVCodecContext
> > > > *avctx,
> > > > *transfer_fnc =
> > > > kCVImageBufferTransferFunction_SMPTE_240M_1995;
> > > > break;
> > > >
> > > > +#if HAVE_KCVIMAGEBUFFERTRANSFERFUNCTION_SMPTE_ST_2084_PQ
> > > > +case AVCOL_TRC_SMPTE2084:
> > > > +*transfer_fnc =
> > > > kCVImageBufferTransferFunction_SMPTE_ST_2084_PQ;
> > > > +break;
> > > > +#endif
> > > > +#if HAVE_KCVIMAGEBUFFERTRANSFERFUNCTION_LINEAR
> > > > +case AVCOL_TRC_LINEAR:
> > > > +*transfer_fnc = kCVImageBufferTransferFunction_Linear;
> > > > +break;
> > > > +#endif
> > > > +#if HAVE_KCVIMAGEBUFFERTRANSFERFUNCTION_ITU_R_2100_HLG
> > > > +case AVCOL_TRC_ARIB_STD_B67:
> > > > +*transfer_fnc =
> > > kCVImageBufferTransferFunction_ITU_R_2100_HLG;
> > > > +break;
> > > > +#endif
> > > > +
> > > > case AVCOL_TRC_GAMMA22:
> > > > gamma = 2.2;
> > > > *transfer_fnc = kCVImageBufferTransferFunction_UseGamma;
> > > > --
> > > > 2.21.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".
> > >
> >
> > A while back, a similar patch was rejected for NVENC (from the same
> author)
> > on the basis of such functionality not being suitably placed as an
> encoder
> > feature.
> >
> > Looking back at other implementations, eg hevc_vaapi, the same is indeed
> > allowed, where SEI metadata retention for HDR is present.
> >
> > To the OP: If the patch for NVENC were refactored in a manner similar to
> > this, abstracting details such as master display info for HDR (something
> > that was specifically flagged as not suitable as an encoder feature), it
> > might pass the patch review and be merged.
> >
> > Are there specific limitations (as implemented) that block such a feature
> > in NVENC? Perhaps the initial patch with mastering display controls for
> H
Re: [FFmpeg-devel] [FFmpeg-cvslog] vf_drawtext: Add pkt_pos, pkt_duration, pkt_size as variables
On 10-07-2019 02:01 PM, Carl Eugen Hoyos wrote: Am 07.07.2019 um 07:43 schrieb Calvin Walton : ffmpeg | branch: master | Calvin Walton | Fri Jun 21 09:08:03 2019 -0400| [2bd21b96096320bc12532119a6b0f7a974db6c19] | committer: Gyan Doshi vf_drawtext: Add pkt_pos, pkt_duration, pkt_size as variables Changes to vf_drawtext.c written by Calvin Walton Changes to filters.texi written by greg Luce with lots of help from Moritz Barsnick and Gyan This makes very little sense, please try hard to avoid similar commits in the future. What makes very little sense? 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] [FFmpeg-cvslog] vf_drawtext: Add pkt_pos, pkt_duration, pkt_size as variables
On 7/10/19, Carl Eugen Hoyos wrote: > > > >> Am 07.07.2019 um 07:43 schrieb Calvin Walton : >> >> ffmpeg | branch: master | Calvin Walton | Fri >> Jun 21 09:08:03 2019 -0400| [2bd21b96096320bc12532119a6b0f7a974db6c19] | >> committer: Gyan Doshi >> >> vf_drawtext: Add pkt_pos, pkt_duration, pkt_size as variables >> >> Changes to vf_drawtext.c written by >> Calvin Walton >> >> Changes to filters.texi written by >> greg Luce >> with lots of help from Moritz Barsnick and Gyan > > This makes very little sense, please try hard to avoid similar commits in > the future. What makes exactly very little sense? > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/dashdec: set the parent of represenation
and get the current sequence number after refresh playlist
Signed-off-by: Steven Liu
---
libavformat/dashdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 9364718c15..aa9f1726c9 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -1065,6 +1065,7 @@ static int parse_manifest_representation(AVFormatContext
*s, const char *url,
av_log(s, AV_LOG_VERBOSE, "Ignoring invalid frame rate
'%s'\n", rep_framerate_val);
}
+rep->parent = s;
switch (type) {
case AVMEDIA_TYPE_VIDEO:
rep->rep_idx = video_rep_idx;
@@ -1614,6 +1615,7 @@ static struct fragment *get_current_fragment(struct
representation *pls)
return seg;
} else if (c->is_live) {
refresh_manifest(pls->parent);
+pls->cur_seq_no = calc_cur_seg_no(pls->parent, pls);
} else {
break;
}
--
2.17.2 (Apple Git-113)
___
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] [FFmpeg-cvslog] vf_drawtext: Add pkt_pos, pkt_duration, pkt_size as variables
> Am 07.07.2019 um 07:43 schrieb Calvin Walton : > > ffmpeg | branch: master | Calvin Walton | Fri Jun > 21 09:08:03 2019 -0400| [2bd21b96096320bc12532119a6b0f7a974db6c19] | > committer: Gyan Doshi > > vf_drawtext: Add pkt_pos, pkt_duration, pkt_size as variables > > Changes to vf_drawtext.c written by > Calvin Walton > > Changes to filters.texi written by > greg Luce > with lots of help from Moritz Barsnick and Gyan This makes very little sense, please try hard to avoid similar commits in the future. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avformat/rpl: Replace strcpy with av_strlcpy
On Tue, Jul 09, 2019 at 10:46:14PM +0100, Cameron Cawley wrote:
> The second use of strcpy() that this patch fixes was added in
> commit 0e9c01f.
the first strcpy is added by:
commit ee32e12ccb0d2af99c356ff7730ecfa07fd5c945
Author: Cameron Cawley
Date: Thu Jun 27 20:56:02 2019 +0100
avformat/rpl: Support files containing Replay IMA ADPCM audio
Signed-off-by: Michael Niedermayer
diff --git a/libavformat/rpl.c b/libavformat/rpl.c
index 17b45e3a67..c28ae696ac 100644
--- a/libavformat/rpl.c
+++ b/libavformat/rpl.c
@@ -189,7 +190,9 @@ static int rpl_read_header(AVFormatContext *s)
// ARMovie supports multiple audio tracks; I don't have any
// samples, though. This code will ignore additional tracks.
-audio_format = read_line_and_int(pb, &error); // audio format ID
+error |= read_line(pb, line, sizeof(line));
+audio_format = read_int(line, &endptr, &error); // audio format ID
+strcpy(audio_codec, endptr);
if (audio_format) {
ast = avformat_new_stream(s, NULL);
if (!ast)
Its not good to apply patches which add bad code just to remove it
again in the next commit
ill apply the strcpy hunk which (should) apply to git master
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/aacdec_template: fix integer overflow in imdct_and_windowing()
Fixes: signed integer overflow: 2147483645 + 4 cannot be represented in type 'int' Fixes: 15418/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-5685269069561856 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/aacdec_template.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c index 28765c768d..6e086e00df 100644 --- a/libavcodec/aacdec_template.c +++ b/libavcodec/aacdec_template.c @@ -2659,7 +2659,7 @@ static void imdct_and_windowing(AACContext *ac, SingleChannelElement *sce) ac->mdct.imdct_half(&ac->mdct, buf, in); #if USE_FIXED for (i=0; i<1024; i++) - buf[i] = (buf[i] + 4) >> 3; + buf[i] = (buf[i] + 4LL) >> 3; #endif /* USE_FIXED */ } -- 2.22.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] lavc/videotoolboxenc: add hdr10, linear, hlg color transfer function for videotoolboxenc
On Wed, Jul 10, 2019 at 4:23 AM Dennis Mungai wrote:
>
> On Wed, Jul 10, 2019, 03:05 Aman Gupta wrote:
>
> > On Wed, Jun 26, 2019 at 4:25 AM wrote:
> >
> > > From: Limin Wang
> > >
> > > Below is the testing ffmpeg command for the setting:
> > > ./ffmpeg -i input.ts -c:v hevc_videotoolbox -color_primaries bt2020
> > > -colorspace bt2020_ncl -color_trc smpte2084 smpte2048.ts
> > > ./ffmpeg -i input.ts -c:v hevc_videotoolbox -color_primaries bt2020
> > > -colorspace bt2020_ncl -color_trc linear linear.ts
> > > ./ffmpeg -i input.ts -c:v hevc_videotoolbox -color_primaries bt2020
> > > -colorspace bt2020_ncl -color_trc arib-std-b67 hlg.ts
> > >
> >
> > Patch looks reasonable to me. Will commit in a few days if no one else
> > comments.
> >
> > Aman
> >
> >
> > >
> > > Signed-off-by: Limin Wang
> > > ---
> > > configure| 6 ++
> > > libavcodec/videotoolboxenc.c | 16
> > > 2 files changed, 22 insertions(+)
> > >
> > > diff --git a/configure b/configure
> > > index 7cea9d4d73..0a5e940c0c 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -2260,6 +2260,9 @@ TOOLCHAIN_FEATURES="
> > > TYPES_LIST="
> > > kCMVideoCodecType_HEVC
> > > kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange
> > > +kCVImageBufferTransferFunction_SMPTE_ST_2084_PQ
> > > +kCVImageBufferTransferFunction_ITU_R_2100_HLG
> > > +kCVImageBufferTransferFunction_Linear
> > > socklen_t
> > > struct_addrinfo
> > > struct_group_source_req
> > > @@ -6044,6 +6047,9 @@ enabled videotoolbox && {
> > > check_lib coreservices CoreServices/CoreServices.h
> > > UTGetOSTypeFromString "-framework CoreServices"
> > > check_func_headers CoreMedia/CMFormatDescription.h
> > > kCMVideoCodecType_HEVC "-framework CoreMedia"
> > > check_func_headers CoreVideo/CVPixelBuffer.h
> > > kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange "-framework CoreVideo"
> > > +check_func_headers CoreVideo/CVImageBuffer.h
> > > kCVImageBufferTransferFunction_SMPTE_ST_2084_PQ "-framework CoreVideo"
> > > +check_func_headers CoreVideo/CVImageBuffer.h
> > > kCVImageBufferTransferFunction_ITU_R_2100_HLG "-framework CoreVideo"
> > > +check_func_headers CoreVideo/CVImageBuffer.h
> > > kCVImageBufferTransferFunction_Linear "-framework CoreVideo"
> > > }
> > >
> > > check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
> > > diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> > > index f8ccdea52d..0dc6eb4cf4 100644
> > > --- a/libavcodec/videotoolboxenc.c
> > > +++ b/libavcodec/videotoolboxenc.c
> > > @@ -915,6 +915,22 @@ static int get_cv_transfer_function(AVCodecContext
> > > *avctx,
> > > *transfer_fnc =
> > > kCVImageBufferTransferFunction_SMPTE_240M_1995;
> > > break;
> > >
> > > +#if HAVE_KCVIMAGEBUFFERTRANSFERFUNCTION_SMPTE_ST_2084_PQ
> > > +case AVCOL_TRC_SMPTE2084:
> > > +*transfer_fnc =
> > > kCVImageBufferTransferFunction_SMPTE_ST_2084_PQ;
> > > +break;
> > > +#endif
> > > +#if HAVE_KCVIMAGEBUFFERTRANSFERFUNCTION_LINEAR
> > > +case AVCOL_TRC_LINEAR:
> > > +*transfer_fnc = kCVImageBufferTransferFunction_Linear;
> > > +break;
> > > +#endif
> > > +#if HAVE_KCVIMAGEBUFFERTRANSFERFUNCTION_ITU_R_2100_HLG
> > > +case AVCOL_TRC_ARIB_STD_B67:
> > > +*transfer_fnc =
> > kCVImageBufferTransferFunction_ITU_R_2100_HLG;
> > > +break;
> > > +#endif
> > > +
> > > case AVCOL_TRC_GAMMA22:
> > > gamma = 2.2;
> > > *transfer_fnc = kCVImageBufferTransferFunction_UseGamma;
> > > --
> > > 2.21.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".
> >
>
> A while back, a similar patch was rejected for NVENC (from the same author)
> on the basis of such functionality not being suitably placed as an encoder
> feature.
>
> Looking back at other implementations, eg hevc_vaapi, the same is indeed
> allowed, where SEI metadata retention for HDR is present.
>
> To the OP: If the patch for NVENC were refactored in a manner similar to
> this, abstracting details such as master display info for HDR (something
> that was specifically flagged as not suitable as an encoder feature), it
> might pass the patch review and be merged.
>
> Are there specific limitations (as implemented) that block such a feature
> in NVENC? Perhaps the initial patch with mastering display controls for HDR
> was written that way to circumvent such a limitation.
>
I think you are confusing the type of patches here. This does nothing
but extend existing functionality to forward a few more values in
basically an enum that was already being set.
The other patch was about parsing user inputs and generat
Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
On 7/10/19, U. Artie Eoff wrote: > This filter enables raw frames to be dumped to a > file before they are sent through the auto-inserted > scaler filter and useful when you want unscaled > raw frames in an output file. > Why? -f rawvideo doesn't work for you? ___ 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".
