Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: improve compute after_init_list_dur

[Steven Liu]

Steven Liu  于2018年7月9日周一 下午5:12写道：
>
> fix ticket: 7305
> vs->sequence - hls->start_sequence - vs->nb_entries is the
> after_init_list_dur fragment numbers
> fix the wrong compute way vs->sequence - vs->nb_entries
>
> Signed-off-by: Steven Liu 
> ---
>  libavformat/hlsenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 2268f898b0..35a26e8875 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2178,7 +2178,7 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  if (vs->sequence - vs->nb_entries > hls->start_sequence && 
> hls->init_time > 0) {
>  /* reset end_pts, hls->recording_time at end of the init hls list */
>  int init_list_dur = hls->init_time * vs->nb_entries * AV_TIME_BASE;
> -int after_init_list_dur = (vs->sequence - vs->nb_entries ) * 
> hls->time * AV_TIME_BASE;
> +int after_init_list_dur = (vs->sequence - hls->start_sequence - 
> vs->nb_entries ) * (hls->time * AV_TIME_BASE);
>  hls->recording_time = hls->time * AV_TIME_BASE;
>  end_pts = init_list_dur + after_init_list_dur ;
>  }
> --
> 2.15.2 (Apple Git-101.1)
>
>
Pushed


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

Re: [FFmpeg-devel] [PATCH 3/3] lavfi/motion_estimation: use pixelutils API for sad.

[Zhao Jun]

On Wed, Jul 11, 2018 at 8:31 AM Michael Niedermayer
 wrote:
>
> On Wed, Jul 11, 2018 at 06:37:37AM +0800, Jun Zhao wrote:
> > use pixelutils API for sad in motion estimation.
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavfilter/motion_estimation.c |   12 +---
> >  libavfilter/motion_estimation.h |2 ++
> >  2 files changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavfilter/motion_estimation.c 
> > b/libavfilter/motion_estimation.c
> > index 0f9ba21..8ccd879 100644
> > --- a/libavfilter/motion_estimation.c
> > +++ b/libavfilter/motion_estimation.c
> > @@ -54,6 +54,8 @@ void ff_me_init_context(AVMotionEstContext *me_ctx, int 
> > mb_size, int search_para
> >  me_ctx->x_max = x_max;
> >  me_ctx->y_min = y_min;
> >  me_ctx->y_max = y_max;
> > +
> > +me_ctx->sad = av_pixelutils_get_sad_fn(av_ceil_log2_c(mb_size), 
> > av_ceil_log2_c(mb_size), 0, NULL);
> >  }
> >
> >  uint64_t ff_me_cmp_sad(AVMotionEstContext *me_ctx, int x_mb, int y_mb, int 
> > x_mv, int y_mv)
> > @@ -67,9 +69,13 @@ uint64_t ff_me_cmp_sad(AVMotionEstContext *me_ctx, int 
> > x_mb, int y_mb, int x_mv,
> >  data_ref += y_mv * linesize;
> >  data_cur += y_mb * linesize;
> >
> > -for (j = 0; j < me_ctx->mb_size; j++)
> > -for (i = 0; i < me_ctx->mb_size; i++)
> > -sad += FFABS(data_ref[x_mv + i + j * linesize] - data_cur[x_mb 
> > + i + j * linesize]);
> > +if (me_ctx->sad) {
> > +sad = me_ctx->sad(data_ref+x_mv, linesize, data_cur+x_mb, 
> > linesize);
> > +} else {
> > +for (j = 0; j < me_ctx->mb_size; j++)
> > +for (i = 0; i < me_ctx->mb_size; i++)
> > +sad += FFABS(data_ref[x_mv + i + j * linesize] - 
> > data_cur[x_mb + i + j * linesize]);
> > +}
> >
>
> The function pointers which point to ff_me_cmp_sad() should point to SIMD
> code in the optimized case.
> there should be no check per call
Thanks the suggestion, will move the check in ff_me_init_context to
avoid the check per call in ff_me_cmp_sad
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> it is not once nor twice but times without number that the same ideas make
> their appearance in the world. -- Aristotle
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] lavfi/motion_estimation: use pixelutils API for sad.

[Zhao Jun]

On Wed, Jul 11, 2018 at 7:47 AM Carl Eugen Hoyos  wrote:
>
> 2018-07-11 0:37 GMT+02:00, Jun Zhao :
> > use pixelutils API for sad in motion estimation.
>
> Some performance number make sense for the commit message imo.
>
> Carl Eugen
Will update performance number in next version, Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] lavfi/motion_estimation: use pixelutils API for sad.

[Michael Niedermayer]

On Wed, Jul 11, 2018 at 06:37:37AM +0800, Jun Zhao wrote:
> use pixelutils API for sad in motion estimation.
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavfilter/motion_estimation.c |   12 +---
>  libavfilter/motion_estimation.h |2 ++
>  2 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/libavfilter/motion_estimation.c b/libavfilter/motion_estimation.c
> index 0f9ba21..8ccd879 100644
> --- a/libavfilter/motion_estimation.c
> +++ b/libavfilter/motion_estimation.c
> @@ -54,6 +54,8 @@ void ff_me_init_context(AVMotionEstContext *me_ctx, int 
> mb_size, int search_para
>  me_ctx->x_max = x_max;
>  me_ctx->y_min = y_min;
>  me_ctx->y_max = y_max;
> +
> +me_ctx->sad = av_pixelutils_get_sad_fn(av_ceil_log2_c(mb_size), 
> av_ceil_log2_c(mb_size), 0, NULL);
>  }
>  
>  uint64_t ff_me_cmp_sad(AVMotionEstContext *me_ctx, int x_mb, int y_mb, int 
> x_mv, int y_mv)
> @@ -67,9 +69,13 @@ uint64_t ff_me_cmp_sad(AVMotionEstContext *me_ctx, int 
> x_mb, int y_mb, int x_mv,
>  data_ref += y_mv * linesize;
>  data_cur += y_mb * linesize;
>  
> -for (j = 0; j < me_ctx->mb_size; j++)
> -for (i = 0; i < me_ctx->mb_size; i++)
> -sad += FFABS(data_ref[x_mv + i + j * linesize] - data_cur[x_mb + 
> i + j * linesize]);
> +if (me_ctx->sad) {
> +sad = me_ctx->sad(data_ref+x_mv, linesize, data_cur+x_mb, linesize);
> +} else {
> +for (j = 0; j < me_ctx->mb_size; j++)
> +for (i = 0; i < me_ctx->mb_size; i++)
> +sad += FFABS(data_ref[x_mv + i + j * linesize] - 
> data_cur[x_mb + i + j * linesize]);
> +}
>  

The function pointers which point to ff_me_cmp_sad() should point to SIMD
code in the optimized case.
there should be no check per call

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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

[FFmpeg-devel] [PATCH 4/4] avformat/mov: Break out of inner loop early in mov_estimate_video_delay()

[Michael Niedermayer]

0.266 <- 0.299 sec (this is time ffmpeg so containing alot other things)

Sample for benchmark was: ffmpeg -f rawvideo -pix_fmt yuv420p -s 32x32 -i 
/dev/zero -t 24:00:00.00 out.mp4

Signed-off-by: Michael Niedermayer 
---
 libavformat/mov.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 951a337cca..b0b9fd99cc 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3331,7 +3331,8 @@ static void mov_estimate_video_delay(MOVContext *c, 
AVStream* st) {
 if (pts_buf[j] < pts_buf[r]) {
 FFSWAP(int64_t, pts_buf[j], pts_buf[r]);
 ++num_swaps;
-}
+} else
+break;
 j = r;
 }
 st->codecpar->video_delay = FFMAX(st->codecpar->video_delay, 
num_swaps);
-- 
2.18.0

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

[FFmpeg-devel] [PATCH 1/4] avformat/mov: remove modulo operations from mov_estimate_video_delay()

[Michael Niedermayer]

0.324 <-0.491 sec

Signed-off-by: Michael Niedermayer 
---
 libavformat/mov.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 1346ffe480..aabf06de12 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3310,13 +3310,16 @@ static void mov_estimate_video_delay(MOVContext *c, 
AVStream* st) {
 for(ind = 0; ind < st->nb_index_entries && ctts_ind < msc->ctts_count; 
++ind) {
 if (buf_size == (MAX_REORDER_DELAY + 1)) {
 // If circular buffer is full, then move the first element 
forward.
-buf_start = (buf_start + 1) % buf_size;
+buf_start = (buf_start + 1);
+if (buf_start == MAX_REORDER_DELAY + 1)
+buf_start = 0;
 } else {
 ++buf_size;
 }
 
 // Point j to the last elem of the buffer and insert the current 
pts there.
-j = (buf_start + buf_size - 1) % buf_size;
+j = buf_start - 1;
+if (j < 0) j = buf_size - 1;
 pts_buf[j] = st->index_entries[ind].timestamp + 
msc->ctts_data[ctts_ind].duration;
 
 // The timestamps that are already in the sorted buffer, and are 
greater than the
@@ -3327,7 +3330,8 @@ static void mov_estimate_video_delay(MOVContext *c, 
AVStream* st) {
 // go through, to keep this buffer in sorted order.
 num_swaps = 0;
 while (j != buf_start) {
-r = (j - 1 + buf_size) % buf_size;
+r = j - 1;
+if (r < 0) r = buf_size - 1;
 if (pts_buf[j] < pts_buf[r]) {
 FFSWAP(int64_t, pts_buf[j], pts_buf[r]);
 ++num_swaps;
-- 
2.18.0

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

[FFmpeg-devel] [PATCH 3/4] avformat/mov: Simplify last element computation in mov_estimate_video_delay()

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavformat/mov.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 67b3e11eb9..951a337cca 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3310,13 +3310,12 @@ static void mov_estimate_video_delay(MOVContext *c, 
AVStream* st) {
 st->codecpar->codec_id == AV_CODEC_ID_H264) {
 st->codecpar->video_delay = 0;
 for(ind = 0; ind < st->nb_index_entries && ctts_ind < msc->ctts_count; 
++ind) {
+// Point j to the last elem of the buffer and insert the current 
pts there.
+j = buf_start;
 buf_start = (buf_start + 1);
 if (buf_start == MAX_REORDER_DELAY + 1)
 buf_start = 0;
 
-// Point j to the last elem of the buffer and insert the current 
pts there.
-j = buf_start - 1;
-if (j < 0) j = MAX_REORDER_DELAY;
 pts_buf[j] = st->index_entries[ind].timestamp + 
msc->ctts_data[ctts_ind].duration;
 
 // The timestamps that are already in the sorted buffer, and are 
greater than the
-- 
2.18.0

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

[FFmpeg-devel] [PATCH 2/4] bavformat/mov: Eliminate variable buf_size from mov_estimate_video_delay()

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavformat/mov.c | 19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index aabf06de12..67b3e11eb9 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3301,25 +3301,22 @@ static void mov_estimate_video_delay(MOVContext *c, 
AVStream* st) {
 int ctts_sample = 0;
 int64_t pts_buf[MAX_REORDER_DELAY + 1]; // Circular buffer to sort pts.
 int buf_start = 0;
-int buf_size = 0;
 int j, r, num_swaps;
 
+for (j = 0; j < MAX_REORDER_DELAY + 1; j++)
+pts_buf[j] = INT64_MIN;
+
 if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
 st->codecpar->codec_id == AV_CODEC_ID_H264) {
 st->codecpar->video_delay = 0;
 for(ind = 0; ind < st->nb_index_entries && ctts_ind < msc->ctts_count; 
++ind) {
-if (buf_size == (MAX_REORDER_DELAY + 1)) {
-// If circular buffer is full, then move the first element 
forward.
-buf_start = (buf_start + 1);
-if (buf_start == MAX_REORDER_DELAY + 1)
-buf_start = 0;
-} else {
-++buf_size;
-}
+buf_start = (buf_start + 1);
+if (buf_start == MAX_REORDER_DELAY + 1)
+buf_start = 0;
 
 // Point j to the last elem of the buffer and insert the current 
pts there.
 j = buf_start - 1;
-if (j < 0) j = buf_size - 1;
+if (j < 0) j = MAX_REORDER_DELAY;
 pts_buf[j] = st->index_entries[ind].timestamp + 
msc->ctts_data[ctts_ind].duration;
 
 // The timestamps that are already in the sorted buffer, and are 
greater than the
@@ -3331,7 +3328,7 @@ static void mov_estimate_video_delay(MOVContext *c, 
AVStream* st) {
 num_swaps = 0;
 while (j != buf_start) {
 r = j - 1;
-if (r < 0) r = buf_size - 1;
+if (r < 0) r = MAX_REORDER_DELAY;
 if (pts_buf[j] < pts_buf[r]) {
 FFSWAP(int64_t, pts_buf[j], pts_buf[r]);
 ++num_swaps;
-- 
2.18.0

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[Michael Niedermayer]

On Tue, Jul 10, 2018 at 11:31:39AM -0400, Derek Buitenhuis wrote:
> Hi,
> 
> Apologies for commenting on this so many months after it was pushed.
> 
> > ffmpeg | branch: master | Sasi Inguva  | 
> > Mon Dec 18 15:31:16 2017 -0800| [58a25aeb8e69532aae6ed1762fe7e0b260990010] 
> > | committer: Michael Niedermayer
> >
> > lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.
> >
> > Signed-off-by: Sasi Inguva 
> > Signed-off-by: Michael Niedermayer 
> >
> > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=58a25aeb8e69532aae6ed1762fe7e0b260990010
> > ---
> 
> This commit massively tanked perf of mov demuxer when opening files.
> On average it has doubled and/or tripled (!!!) the amount of cycles that
> opening an MP4 needs.
> 
> Also, I'm not sure why generic PTS reordering/delay code is in mov.c,
> rather than utils.c or something. There's nothing inherently mov-specific
> about this, unless you count "has an index".
> 
> On an example file (24h long, warm runs):
> 
> Before Patch
> 
> 4446217810 decicycles in mov_build_index,   1 runs,  0 skips
> 4603125860 decicycles in mov_build_index,   2 runs,  0 skips
> 
> After Patch
> ---
> 14457275100 decicycles in mov_build_index,   1 runs,  0 skips
> 9608655040 decicycles in mov_build_index,   2 runs,  0 skips
> 
> I happen to call the mov open API quite heavily (in my case, for on-the-fly
> remuxing), and this increase CPU load around 25%+ per core, overall,
> which is nontrivial.
> 
> I appreciate the perf of opening a file may not be something we care about,
> so I see a few options:
> 
> * I just patch it out at $dayjob; not ideal, since I prefer to upstream, but
>   I can understand the usecase is too niche for upstreaming.
> * Add a yet another option to mov.c to bypass it entirely.
> * Add yet another option to mov.c to restrict the calculations to the first
>   MAX_REORDER_FRAMES+1 frames of the file. This would make
>   it unsuitable for seeking.
> * Move the code to a generic place like utils.c and add a generic
>   option to bypass it.
> * Some algorithmic trickery to make it faster - I tried to think of a better
>   way to do it, but all the things I could think of would only yeild minor
>   gains, leaving the overal big-O complexity the same.

ill post a patchset that seems to make it much faster but i need to test it
first a bit


> * Some mix of the above, or something not listed here.
> 
> Ideas and comments very welcome, even if they amount to "go pound
> sand".
> 
> Cheers,
> - Derek
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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

Re: [FFmpeg-devel] [PATCH 3/3] lavfi/motion_estimation: use pixelutils API for sad.

[Carl Eugen Hoyos]

2018-07-11 0:37 GMT+02:00, Jun Zhao :
> use pixelutils API for sad in motion estimation.

Some performance number make sense for the commit message imo.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[Carl Eugen Hoyos]

2018-07-10 17:31 GMT+02:00, Derek Buitenhuis :

> On an example file (24h long, warm runs):
>
> Before Patch
> 
> 4446217810 decicycles in mov_build_index,   1 runs,  0 skips
> 4603125860 decicycles in mov_build_index,   2 runs,  0 skips
>
> After Patch
> ---
> 14457275100 decicycles in mov_build_index,   1 runs,  0 skips
> 9608655040 decicycles in mov_build_index,   2 runs,  0 skips

I find the numbers with "time ffmpeg" (and the sample created with
your guidance, thank you!) more impressive but that may be me...

Do I understand correctly that this patch only avoids dropping one
or rarely a few B-frames on startup? Isn't this unnecessary with
-strict 1 because it already sets the number of B-frames to the
maximum possible?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavf/vf_scale_amf: AMF scaler/format converter filter implementation

[Michael Niedermayer]

On Tue, Jul 10, 2018 at 05:30:15PM +0300, Alexander Kravchenko wrote:
> ---
> Sending updated patch based on Mark's review
> 1) added RGBA/BGRA
> 2) in case is device_ctx is set there is only the device hw format will be 
> allowed as input and output
> 3) extended amf properties removed for now to have usual for ffmpeg 
> scaler&format converter interface
> 4) input frame colorspace is set as color profile to select conversion matrix 
> in case YUV->RGB, user setting removed.
> 5) misc bugs fixed
> 

not specific to this patch but more general, it would be nice if 
hw scaling/colorspa converting would be in our lib that is intended for 
scaling/colorspace converting (libswscale)

Thanks

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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[Derek Buitenhuis]

On Tue, Jul 10, 2018 at 4:46 PM, Carl Eugen Hoyos  wrote:
> Is it possible to produce such a sample with FFmpeg?

The slow down happens with all MP4 and MOV files, but if you just want
a long sample that makes it obvious, yes ffmpeg can make it.

Probably something like (untested):
ffmpeg -f rawvideo -pix_fmt yuv420p -s 32x32 -i /dev/zero -t
24:00:00.00 out.mp4

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

[FFmpeg-devel] [PATCH 1/3] lavutil/pixelutils: add sad_32x32 in pixelutils API.

[Jun Zhao]

add sad_32x32 in pixelutils API, and update the fate.

Signed-off-by: Jun Zhao 
---
 libavutil/pixelutils.c   |2 ++
 libavutil/tests/pixelutils.c |2 +-
 tests/ref/fate/pixelutils|   12 
 3 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/libavutil/pixelutils.c b/libavutil/pixelutils.c
index b663027..ebee3d6 100644
--- a/libavutil/pixelutils.c
+++ b/libavutil/pixelutils.c
@@ -51,12 +51,14 @@ DECLARE_BLOCK_FUNCTIONS(2)
 DECLARE_BLOCK_FUNCTIONS(4)
 DECLARE_BLOCK_FUNCTIONS(8)
 DECLARE_BLOCK_FUNCTIONS(16)
+DECLARE_BLOCK_FUNCTIONS(32)
 
 static const av_pixelutils_sad_fn sad_c[] = {
 block_sad_2x2_c,
 block_sad_4x4_c,
 block_sad_8x8_c,
 block_sad_16x16_c,
+block_sad_32x32_c,
 };
 
 #endif /* CONFIG_PIXELUTILS */
diff --git a/libavutil/tests/pixelutils.c b/libavutil/tests/pixelutils.c
index ec4dc8f..2f80758 100644
--- a/libavutil/tests/pixelutils.c
+++ b/libavutil/tests/pixelutils.c
@@ -115,7 +115,7 @@ int main(void)
 goto end;
 
 /* Exact buffer sizes, to check for overreads */
-for (i = 1; i <= 4; i++) {
+for (i = 1; i <= 5; i++) {
 for (align = 0; align < 3; align++) {
 int size1, size2;
 
diff --git a/tests/ref/fate/pixelutils b/tests/ref/fate/pixelutils
index 493497f..434904e 100644
--- a/tests/ref/fate/pixelutils
+++ b/tests/ref/fate/pixelutils
@@ -2,38 +2,47 @@
 [OK] [UU] SAD [random] 4x4=1370 ref=1370
 [OK] [UU] SAD [random] 8x8=5178 ref=5178
 [OK] [UU] SAD [random] 16x16=20946 ref=20946
+[OK] [UU] SAD [random] 32x32=83150 ref=83150
 [OK] [AU] SAD [random] 2x2=320 ref=320
 [OK] [AU] SAD [random] 4x4=1522 ref=1522
 [OK] [AU] SAD [random] 8x8=5821 ref=5821
 [OK] [AU] SAD [random] 16x16=21951 ref=21951
+[OK] [AU] SAD [random] 32x32=86983 ref=86983
 [OK] [AA] SAD [random] 2x2=276 ref=276
 [OK] [AA] SAD [random] 4x4=1521 ref=1521
 [OK] [AA] SAD [random] 8x8=5130 ref=5130
 [OK] [AA] SAD [random] 16x16=20775 ref=20775
+[OK] [AA] SAD [random] 32x32=83402 ref=83402
 [OK] [UU] SAD [max] 2x2=1020 ref=1020
 [OK] [UU] SAD [max] 4x4=4080 ref=4080
 [OK] [UU] SAD [max] 8x8=16320 ref=16320
 [OK] [UU] SAD [max] 16x16=65280 ref=65280
+[OK] [UU] SAD [max] 32x32=261120 ref=261120
 [OK] [AU] SAD [max] 2x2=1020 ref=1020
 [OK] [AU] SAD [max] 4x4=4080 ref=4080
 [OK] [AU] SAD [max] 8x8=16320 ref=16320
 [OK] [AU] SAD [max] 16x16=65280 ref=65280
+[OK] [AU] SAD [max] 32x32=261120 ref=261120
 [OK] [AA] SAD [max] 2x2=1020 ref=1020
 [OK] [AA] SAD [max] 4x4=4080 ref=4080
 [OK] [AA] SAD [max] 8x8=16320 ref=16320
 [OK] [AA] SAD [max] 16x16=65280 ref=65280
+[OK] [AA] SAD [max] 32x32=261120 ref=261120
 [OK] [UU] SAD [min] 2x2=0 ref=0
 [OK] [UU] SAD [min] 4x4=0 ref=0
 [OK] [UU] SAD [min] 8x8=0 ref=0
 [OK] [UU] SAD [min] 16x16=0 ref=0
+[OK] [UU] SAD [min] 32x32=0 ref=0
 [OK] [AU] SAD [min] 2x2=0 ref=0
 [OK] [AU] SAD [min] 4x4=0 ref=0
 [OK] [AU] SAD [min] 8x8=0 ref=0
 [OK] [AU] SAD [min] 16x16=0 ref=0
+[OK] [AU] SAD [min] 32x32=0 ref=0
 [OK] [AA] SAD [min] 2x2=0 ref=0
 [OK] [AA] SAD [min] 4x4=0 ref=0
 [OK] [AA] SAD [min] 8x8=0 ref=0
 [OK] [AA] SAD [min] 16x16=0 ref=0
+[OK] [AA] SAD [min] 32x32=0 ref=0
 [OK] [UU] SAD [small] 2x2=400 ref=400
 [OK] [AU] SAD [small] 2x2=384 ref=384
 [OK] [AA] SAD [small] 2x2=409 ref=409
@@ -46,3 +55,6 @@
 [OK] [UU] SAD [small] 16x16=19490 ref=19490
 [OK] [AU] SAD [small] 16x16=21037 ref=21037
 [OK] [AA] SAD [small] 16x16=22986 ref=22986
+[OK] [UU] SAD [small] 32x32=86550 ref=86550
+[OK] [AU] SAD [small] 32x32=83656 ref=83656
+[OK] [AA] SAD [small] 32x32=85164 ref=85164
\ No newline at end of file
-- 
1.7.1

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

[FFmpeg-devel] [PATCH 3/3] lavfi/motion_estimation: use pixelutils API for sad.

[Jun Zhao]

use pixelutils API for sad in motion estimation.

Signed-off-by: Jun Zhao 
---
 libavfilter/motion_estimation.c |   12 +---
 libavfilter/motion_estimation.h |2 ++
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/libavfilter/motion_estimation.c b/libavfilter/motion_estimation.c
index 0f9ba21..8ccd879 100644
--- a/libavfilter/motion_estimation.c
+++ b/libavfilter/motion_estimation.c
@@ -54,6 +54,8 @@ void ff_me_init_context(AVMotionEstContext *me_ctx, int 
mb_size, int search_para
 me_ctx->x_max = x_max;
 me_ctx->y_min = y_min;
 me_ctx->y_max = y_max;
+
+me_ctx->sad = av_pixelutils_get_sad_fn(av_ceil_log2_c(mb_size), 
av_ceil_log2_c(mb_size), 0, NULL);
 }
 
 uint64_t ff_me_cmp_sad(AVMotionEstContext *me_ctx, int x_mb, int y_mb, int 
x_mv, int y_mv)
@@ -67,9 +69,13 @@ uint64_t ff_me_cmp_sad(AVMotionEstContext *me_ctx, int x_mb, 
int y_mb, int x_mv,
 data_ref += y_mv * linesize;
 data_cur += y_mb * linesize;
 
-for (j = 0; j < me_ctx->mb_size; j++)
-for (i = 0; i < me_ctx->mb_size; i++)
-sad += FFABS(data_ref[x_mv + i + j * linesize] - data_cur[x_mb + i 
+ j * linesize]);
+if (me_ctx->sad) {
+sad = me_ctx->sad(data_ref+x_mv, linesize, data_cur+x_mb, linesize);
+} else {
+for (j = 0; j < me_ctx->mb_size; j++)
+for (i = 0; i < me_ctx->mb_size; i++)
+sad += FFABS(data_ref[x_mv + i + j * linesize] - data_cur[x_mb 
+ i + j * linesize]);
+}
 
 return sad;
 }
diff --git a/libavfilter/motion_estimation.h b/libavfilter/motion_estimation.h
index 6ae29dd..9f7710b 100644
--- a/libavfilter/motion_estimation.h
+++ b/libavfilter/motion_estimation.h
@@ -22,6 +22,7 @@
 #define AVFILTER_MOTION_ESTIMATION_H
 
 #include "libavutil/avutil.h"
+#include "libavutil/pixelutils.h"
 
 #define AV_ME_METHOD_ESA1
 #define AV_ME_METHOD_TSS2
@@ -59,6 +60,7 @@ typedef struct AVMotionEstContext {
 
 uint64_t (*get_cost)(struct AVMotionEstContext *me_ctx, int x_mb, int y_mb,
  int mv_x, int mv_y);
+av_pixelutils_sad_fn sad;
 } AVMotionEstContext;
 
 void ff_me_init_context(AVMotionEstContext *me_ctx, int mb_size, int 
search_param,
-- 
1.7.1

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

[FFmpeg-devel] [PATCH 2/3] avutil/pixelutils: sad_32x32 sse2/avx2 optimizations.

[Jun Zhao]

add ff_pixelutils_sad_32x32_sse2, ff_pixelutils_sad_{a,u}_32x32_sse2,
ff_pixelutils_sad_32x32_avx22, ff_pixelutils_sad_{a,u}_32x32_avx2

Signed-off-by: Jun Zhao 
---
 libavutil/x86/pixelutils.asm|  220 +++
 libavutil/x86/pixelutils_init.c |   30 ++
 2 files changed, 250 insertions(+), 0 deletions(-)

diff --git a/libavutil/x86/pixelutils.asm b/libavutil/x86/pixelutils.asm
index 7af3007..76b1a1a 100644
--- a/libavutil/x86/pixelutils.asm
+++ b/libavutil/x86/pixelutils.asm
@@ -163,3 +163,223 @@ cglobal pixelutils_sad_%1_16x16, 4,4,3, src1, stride1, 
src2, stride2
 
 SAD_XMM_16x16 a
 SAD_XMM_16x16 u
+
+
+%macro PROCESS_SAD_32x4_U 0
+movum1,  [r2]
+movum2,  [r2 + 16]
+movum3,  [r0]
+movum4,  [r0 + 16] 
+psadbw  m1,  m3
+psadbw  m2,  m4
+paddd   m1,  m2
+paddd   m0,  m1
+lea r2,  [r2 + r3]
+lea r0,  [r0 + r1]
+
+movum1,  [r2]
+movum2,  [r2 + 16]
+movum3,  [r0]
+movum4,  [r0 + 16] 
+psadbw  m1,  m3
+psadbw  m2,  m4
+paddd   m1,  m2
+paddd   m0,  m1
+lea r2,  [r2 + r3]
+lea r0,  [r0 + r1]
+
+movum1,  [r2]
+movum2,  [r2 + 16]
+movum3,  [r0]
+movum4,  [r0 + 16] 
+psadbw  m1,  m3
+psadbw  m2,  m4
+paddd   m1,  m2
+paddd   m0,  m1
+lea r2,  [r2 + r3]
+lea r0,  [r0 + r1]
+
+movum1,  [r2]
+movum2,  [r2 + 16]
+movum3,  [r0]
+movum4,  [r0 + 16] 
+psadbw  m1,  m3
+psadbw  m2,  m4
+paddd   m1,  m2
+paddd   m0,  m1
+lea r2,  [r2 + r3]
+lea r0,  [r0 + r1]
+%endmacro
+
+%macro PROCESS_SAD_32x4 1
+mov%1   m1,  [r2]
+mov%1   m2,  [r2 + 16]
+psadbw  m1,  [r0]
+psadbw  m2,  [r0 + 16]
+paddd   m1,  m2
+paddd   m0,  m1
+lea r2,  [r2 + r3]
+lea r0,  [r0 + r1]
+   
+mov%1   m1,  [r2]
+mov%1   m2,  [r2 + 16]
+psadbw  m1,  [r0]
+psadbw  m2,  [r0 + 16]
+paddd   m1,  m2
+paddd   m0,  m1
+lea r2,  [r2 + r3]
+lea r0,  [r0 + r1]
+   
+mov%1   m1,  [r2]
+mov%1   m2,  [r2 + 16]
+psadbw  m1,  [r0]
+psadbw  m2,  [r0 + 16]
+paddd   m1,  m2
+paddd   m0,  m1
+lea r2,  [r2 + r3]
+lea r0,  [r0 + r1]
+   
+mov%1   m1,  [r2]
+mov%1   m2,  [r2 + 16]
+psadbw  m1,  [r0]
+psadbw  m2,  [r0 + 16]
+paddd   m1,  m2
+paddd   m0,  m1
+lea r2,  [r2 + r3]
+lea r0,  [r0 + r1]
+%endmacro
+
+;-
+; int ff_pixelutils_sad_32x32_sse2(const uint8_t *src1, ptrdiff_t stride1,
+;  const uint8_t *src2, ptrdiff_t stride2);
+;-
+INIT_XMM sse2
+cglobal pixelutils_sad_32x32, 4,5,5, src1, stride1, src2, stride2
+pxor  m0,  m0
+mov   r4d, 4
+.loop:
+PROCESS_SAD_32x4_U
+PROCESS_SAD_32x4_U
+dec r4d
+jnz .loop
+
+movhlps m1,  m0
+paddd   m0,  m1
+movdeax, m0
+RET
+   
+
+;---
+; int ff_pixelutils_sad_[au]_32x32_sse2(const uint8_t *src1, ptrdiff_t stride1,
+;   const uint8_t *src2, ptrdiff_t 
stride2);
+;---
+%macro SAD_XMM_32x32 1
+INIT_XMM sse2
+cglobal pixelutils_sad_%1_32x32, 4,5,3, src1, stride1, src2, stride2
+pxor  m0,  m0
+mov   r4d, 4
+.loop:
+PROCESS_SAD_32x4 %1
+PROCESS_SAD_32x4 %1
+dec r4d
+jnz .loop
+
+movhlps m1,  m0
+paddd   m0,  m1
+movdeax, m0
+RET
+%endmacro
+
+SAD_XMM_32x32 a
+SAD_XMM_32x32 u
+
+;---
+; int ff_pixelutils_sad_32x32_avx2(const uint8_t *src1, ptrdiff_t stride1,
+;  const uint8_t *src2, ptrdiff_t stride2);
+;---
+INIT_YMM avx2
+cglobal pixelutils_sad_32x32, 4,7,5, src1, stride1, src2, stride2
+xorps   m0, m0
+mov r4d, 32/4
+lea r5, [stride1q * 3]
+lea r6, [stride2q * 3]
+
+.loop:
+movu   m1, [src1q]   ; row 0 of pix0
+movu   m2, [src2q]   ; row 0 of pix1
+movu   m3, [src1q + stride1q]; row 1 of pix0
+movu   m4, [src2q + stride2q]; row 1 of pix1
+
+psadbw m1, m2
+psadbw m3, m4
+paddd  m0, m1
+paddd  m0, m3
+
+movu   m1, [src1q + 2 * stride1q] ; row 2 of pix0
+movu   m2, [src2q + 2 * stride2q] ; row 2 of pix1
+movu   m3, [src1q + r5]   ; row 3 of pix0
+movu   m4, [src2q + r6]   ; row 3 of pix1
+

[FFmpeg-devel] [PATCH v8 3/3] avformat/rtpdec_rfc4175: handle interlace format

[Patrick Keroulas]

From: Damien Riegel 

In order to handle the interlaced formats, the demuxer has only a few
things to do:
 - parse the SDP correctly and propagate the information
 - check the field bit in the RFC4175 header, and pass that information
   to the decoder

In interlaced mode, received data only consist of fields, and their
heights are half of the frame size, so some adjustments must be done
here and there to take that into account.

Signed-off-by: Damien Riegel 
Signed-off-by: Patrick Keroulas 
---
 libavformat/rtpdec_rfc4175.c | 57 
 1 file changed, 47 insertions(+), 10 deletions(-)

diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c
index e9c62c1..b9619be 100644
--- a/libavformat/rtpdec_rfc4175.c
+++ b/libavformat/rtpdec_rfc4175.c
@@ -23,6 +23,7 @@
 
 #include "avio_internal.h"
 #include "rtpdec_formats.h"
+#include "libavutil/ancillary_data.h"
 #include "libavutil/avstring.h"
 #include "libavutil/pixdesc.h"
 
@@ -31,6 +32,8 @@ struct PayloadContext {
 int depth;
 int width;
 int height;
+int interlaced;
+int field;
 
 uint8_t *frame;
 unsigned int frame_size;
@@ -65,10 +68,18 @@ static int rfc4175_parse_format(AVStream *stream, 
PayloadContext *data)
 return AVERROR_INVALIDDATA;
 }
 
+if (data->interlaced)
+stream->codecpar->field_order = AV_FIELD_TT;
+else
+stream->codecpar->field_order = AV_FIELD_PROGRESSIVE;
+
 stream->codecpar->format = pixfmt;
 stream->codecpar->codec_tag = tag;
 stream->codecpar->bits_per_coded_sample = bits_per_sample;
-data->frame_size = data->width * data->height * data->pgroup / data->xinc;
+if (data->interlaced)
+data->frame_size = data->width * (data->height / 2) * data->pgroup / 
data->xinc;
+else
+data->frame_size = data->width * data->height * data->pgroup / 
data->xinc;
 
 return 0;
 }
@@ -85,6 +96,8 @@ static int rfc4175_parse_fmtp(AVFormatContext *s, AVStream 
*stream,
 data->sampling = av_strdup(value);
 else if (!strncmp(attr, "depth", 5))
 data->depth = atoi(value);
+else if (!strncmp(attr, "interlace", 9))
+data->interlaced = 1;
 
 return 0;
 }
@@ -123,17 +136,38 @@ static int rfc4175_parse_sdp_line(AVFormatContext *s, int 
st_index,
 static int rfc4175_finalize_packet(PayloadContext *data, AVPacket *pkt,
int stream_index)
 {
-   int ret;
+AVAncillaryData * ancillary;
+int ret;
+uint8_t * side_data;
+
+pkt->stream_index = stream_index;
+ret = av_packet_from_data(pkt, data->frame, data->frame_size);
+if (ret < 0) {
+av_freep(&data->frame);
+}
 
-   pkt->stream_index = stream_index;
-   ret = av_packet_from_data(pkt, data->frame, data->frame_size);
-   if (ret < 0) {
-   av_freep(&data->frame);
-   }
+/* In the packet header, the field is set to 0 for top field
+ * and 1 for bottom */
+ if (data->interlaced) {
+ ancillary = av_ancillary_data_alloc();
+ if (!ancillary)
+ return AVERROR(ENOMEM);
 
-   data->frame = NULL;
+ ancillary->field = data->field ? AV_ANCILLARY_DATA_FIELD_BOTTOM_FIELD
+ : AV_ANCILLARY_DATA_FIELD_TOP_FIELD;
 
-   return ret;
+ side_data = av_packet_new_side_data(pkt, AV_PKT_DATA_ANCILLARY,
+ sizeof(AVAncillaryData));
+ if (!side_data)
+ return AVERROR(ENOMEM);
+
+ memcpy(side_data, ancillary, sizeof(AVAncillaryData));
+}
+
+data->frame = NULL;
+data->field = 0;
+
+return ret;
 }
 
 static int rfc4175_handle_packet(AVFormatContext *ctx, PayloadContext *data,
@@ -141,7 +175,7 @@ static int rfc4175_handle_packet(AVFormatContext *ctx, 
PayloadContext *data,
  const uint8_t * buf, int len,
  uint16_t seq, int flags)
 {
-int length, line, offset, cont;
+int length, line, offset, cont, field;
 const uint8_t *headers = buf + 2; /* skip extended seqnum */
 const uint8_t *payload = buf + 2;
 int payload_len = len - 2;
@@ -194,11 +228,14 @@ static int rfc4175_handle_packet(AVFormatContext *ctx, 
PayloadContext *data,
 return AVERROR_INVALIDDATA;
 
 length = (headers[0] << 8) | headers[1];
+field = (headers[2] & 0x80);
 line = ((headers[2] & 0x7f) << 8) | headers[3];
 offset = ((headers[4] & 0x7f) << 8) | headers[5];
 cont = headers[4] & 0x80;
 headers += 6;
 
+data->field = field;
+
 if (length % data->pgroup)
 return AVERROR_INVALIDDATA;
 
-- 
2.7.4

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

[FFmpeg-devel] [PATCH v8 2/3] avcodec/bitpacked: add interlace support

[Patrick Keroulas]

This codec is already capable of depacking some combinations of pixel
formats and depth as defined in the RFC4175. The only difference between
progressive and interlace is that either a packet will contain the whole
frame, or only a field of the frame.

There is no mechanism for interlaced frames reconstruction at the rtp
demux level, so it has to be handled by the codec which needs to
partially recompose an AVFrame with every incoming field AVPacket.
A frame is ouput only when the frame is completed with the 2nd field
(bottom).

The AVAncillary Data carried by AVPacket side data allows the decoder to
dynamically determine the frame format, i.e. progressive or interlaced.

Signed-off-by: Patrick Keroulas 
Signed-off-by: Damien Riegel 
---

Changes v7 -> v8: style

---
---
 libavcodec/bitpacked.c | 140 +
 1 file changed, 117 insertions(+), 23 deletions(-)

diff --git a/libavcodec/bitpacked.c b/libavcodec/bitpacked.c
index f0b417d..e71593c 100644
--- a/libavcodec/bitpacked.c
+++ b/libavcodec/bitpacked.c
@@ -29,16 +29,18 @@
 #include "avcodec.h"
 #include "internal.h"
 #include "get_bits.h"
+#include "libavutil/ancillary_data.h"
 #include "libavutil/imgutils.h"
 
 struct BitpackedContext {
-int (*decode)(AVCodecContext *avctx, AVFrame *frame,
-  AVPacket *pkt);
+int (*decode)(AVCodecContext *avctx, AVFrame *frame, AVPacket *pkt, 
uint8_t field);
+AVFrame *cur_interlaced_frame;
+int prev_top_field;
 };
 
 /* For this format, it's a simple passthrough */
 static int bitpacked_decode_uyvy422(AVCodecContext *avctx, AVFrame *frame,
-AVPacket *avpkt)
+AVPacket *avpkt, uint8_t field)
 {
 int ret;
 
@@ -56,29 +58,43 @@ static int bitpacked_decode_uyvy422(AVCodecContext *avctx, 
AVFrame *frame,
 }
 
 static int bitpacked_decode_yuv422p10(AVCodecContext *avctx, AVFrame *frame,
-  AVPacket *avpkt)
+  AVPacket *avpkt, uint8_t field)
 {
-uint64_t frame_size = (uint64_t)avctx->width * (uint64_t)avctx->height * 
20;
+uint64_t frame_size = avctx->width * avctx->height * 20LL;
 uint64_t packet_size = (uint64_t)avpkt->size * 8;
+int interlaced = frame->interlaced_frame;
+int top_field = (field & AV_ANCILLARY_DATA_FIELD_TOP_FIELD) ? 1 : 0;
 GetBitContext bc;
 uint16_t *y, *u, *v;
 int ret, i, j;
 
-ret = ff_get_buffer(avctx, frame, 0);
-if (ret < 0)
-return ret;
+if ((avctx->width % 2 ) || (avctx->height % 2))
+return AVERROR_PATCHWELCOME;
 
-if (frame_size > packet_size)
+/* check packet size depending on the interlaced/progressive format */
+if (interlaced) {
+if ((frame_size / 2) > packet_size)
+return AVERROR_INVALIDDATA;
+} else if (frame_size > packet_size) {
 return AVERROR_INVALIDDATA;
+}
 
-if (avctx->width % 2)
-return AVERROR_PATCHWELCOME;
+/*
+ * if the frame is interlaced, the avpkt we are getting is either the top
+ * or the bottom field. If it's the bottom field, it contains all the odd
+ * lines of the recomposed frame, so we start at offset 1.
+ */
+i = (interlaced && !top_field) ? 1 : 0;
 
-ret = init_get_bits(&bc, avpkt->data, avctx->width * avctx->height * 20);
+ret = init_get_bits(&bc, avpkt->data, frame_size);
 if (ret)
 return ret;
 
-for (i = 0; i < avctx->height; i++) {
+/*
+ * Packets from interlaced frames contain either even lines, or odd
+ * lines, so increment by two in that case.
+ */
+for (; i < avctx->height; i += 1 + interlaced) {
 y = (uint16_t*)(frame->data[0] + i * frame->linesize[0]);
 u = (uint16_t*)(frame->data[1] + i * frame->linesize[1]);
 v = (uint16_t*)(frame->data[2] + i * frame->linesize[2]);
@@ -103,17 +119,35 @@ static av_cold int bitpacked_init_decoder(AVCodecContext 
*avctx)
 
 if (avctx->codec_tag == MKTAG('U', 'Y', 'V', 'Y')) {
 if (avctx->bits_per_coded_sample == 16 &&
-avctx->pix_fmt == AV_PIX_FMT_UYVY422)
+avctx->pix_fmt == AV_PIX_FMT_UYVY422) {
+
+if (avctx->field_order > AV_FIELD_PROGRESSIVE) {
+av_log(avctx, AV_LOG_ERROR, "interlaced not yet supported for 
8-bit\n");
+return AVERROR_PATCHWELCOME;
+}
+
 bc->decode = bitpacked_decode_uyvy422;
-else if (avctx->bits_per_coded_sample == 20 &&
- avctx->pix_fmt == AV_PIX_FMT_YUV422P10)
+} else if (avctx->bits_per_coded_sample == 20 &&
+ avctx->pix_fmt == AV_PIX_FMT_YUV422P10) {
 bc->decode = bitpacked_decode_yuv422p10;
-else
+} else {
 return AVERROR_INVALIDDATA;
+}
 } else {
 return AVERROR_INVALIDDATA;
 }
 
+bc->cur_interlaced_frame = av_frame_alloc();
+
+return 0;
+}
+
+sta

[FFmpeg-devel] [PATCH v8 1/3] avcodec: add side data type for ancillary

[Patrick Keroulas]

Ancillary data can carry various side data that can't be transmitted in
bitstreams. For now, this struct includes interlaced field flags and
the must be attached to an AVPacket as side data.

Signed-off-by: Patrick Keroulas 
---

Changes v7 -> v8:
 * Merge the definition of AVAncillaryData and its allocation in
avcodec.h in a single patch.

---
---
 doc/APIchanges |  3 +++
 libavcodec/avcodec.h   |  7 +-
 libavcodec/avpacket.c  |  1 +
 libavcodec/version.h   |  4 ++--
 libavutil/Makefile |  2 ++
 libavutil/ancillary_data.c | 27 ++
 libavutil/ancillary_data.h | 56 ++
 libavutil/version.h|  4 ++--
 8 files changed, 99 insertions(+), 5 deletions(-)
 create mode 100644 libavutil/ancillary_data.c
 create mode 100644 libavutil/ancillary_data.h

diff --git a/doc/APIchanges b/doc/APIchanges
index efe15ba..ff2baff 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-05-xx - xx - lavc 58.20.100 - avcodec.h
+  Add AV_PKT_DATA_ANCILLARY to hold various side data.
+
 2018-05-xx - xx - lavf 58.15.100 - avformat.h
   Add pmt_version field to AVProgram
 
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index f85af3f..658bd9e 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1360,6 +1360,12 @@ enum AVPacketSideDataType {
 AV_PKT_DATA_ENCRYPTION_INFO,
 
 /**
+ * Generic side data for any parameter that can't fit in a AVPacket,
+ * e.g. interlaced field flags.
+ */
+AV_PKT_DATA_ANCILLARY,
+
+/**
  * The number of side data types.
  * This is not part of the public API/ABI in the sense that it may
  * change when new side data types are added.
@@ -1482,7 +1488,6 @@ typedef struct AVPacket {
  */
 #define AV_PKT_FLAG_DISPOSABLE 0x0010
 
-
 enum AVSideDataParamChangeFlags {
 AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT  = 0x0001,
 AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_LAYOUT = 0x0002,
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 99a0c13..27355e1 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -388,6 +388,7 @@ const char *av_packet_side_data_name(enum 
AVPacketSideDataType type)
 case AV_PKT_DATA_CONTENT_LIGHT_LEVEL:return "Content light level 
metadata";
 case AV_PKT_DATA_SPHERICAL:  return "Spherical Mapping";
 case AV_PKT_DATA_A53_CC: return "A53 Closed Captions";
+case AV_PKT_DATA_ANCILLARY:  return "Ancillary data";
 }
 return NULL;
 }
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 471ea4a..3f0d98e 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,8 +28,8 @@
 #include "libavutil/version.h"
 
 #define LIBAVCODEC_VERSION_MAJOR  58
-#define LIBAVCODEC_VERSION_MINOR  21
-#define LIBAVCODEC_VERSION_MICRO 104
+#define LIBAVCODEC_VERSION_MINOR  22
+#define LIBAVCODEC_VERSION_MICRO 100
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
diff --git a/libavutil/Makefile b/libavutil/Makefile
index 9ed24cf..100ce10 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -4,6 +4,7 @@ DESC = FFmpeg utility library
 HEADERS = adler32.h \
   aes.h \
   aes_ctr.h \
+  ancillary_data.h  \
   attributes.h  \
   audio_fifo.h  \
   avassert.h\
@@ -92,6 +93,7 @@ BUILT_HEADERS = avconfig.h
  \
 OBJS = adler32.o\
aes.o\
aes_ctr.o\
+   ancillary_data.o \
audio_fifo.o \
avstring.o   \
base64.o \
diff --git a/libavutil/ancillary_data.c b/libavutil/ancillary_data.c
new file mode 100644
index 000..26686b8
--- /dev/null
+++ b/libavutil/ancillary_data.c
@@ -0,0 +1,27 @@
+/**
+ * Copyright (c) 2018 Patrick Keroulas 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at 

Re: [FFmpeg-devel] [PATCH 2/2] lavf/vf_scale_amf: AMF scaler/format converter filter implementation

[Carl Eugen Hoyos]

2018-07-10 16:30 GMT+02:00, Alexander Kravchenko :

> 1) added RGBA/BGRA

> +static const enum AVPixelFormat input_pix_fmts[] = {
> +AV_PIX_FMT_NV12,
> +AV_PIX_FMT_0RGB,
> +AV_PIX_FMT_BGR0,
> +AV_PIX_FMT_RGB0,
> +AV_PIX_FMT_GRAY8,
> +AV_PIX_FMT_YUV420P,
> +AV_PIX_FMT_YUYV422,
> +AV_PIX_FMT_NONE,
> +};

Do I miss it or did you forget to add RGBA?

Can you confirm that the alpha plane is really scaled?
(Unless I misunderstand, you haven't tested it.)

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[Carl Eugen Hoyos]

2018-07-10 17:31 GMT+02:00, Derek Buitenhuis :

> On an example file (24h long, warm runs):
>
> Before Patch
> 
> 4446217810 decicycles in mov_build_index,   1 runs,  0 skips
> 4603125860 decicycles in mov_build_index,   2 runs,  0 skips
>
> After Patch
> ---
> 14457275100 decicycles in mov_build_index,   1 runs,  0 skips
> 9608655040 decicycles in mov_build_index,   2 runs,  0 skips

Is it possible to produce such a sample with FFmpeg?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v4 3/3] aadec: improve seeking in mp3 content

[Karsten Otto]

Ping - What about this one? I tested it with about 20 files and it works 
perfectly
for all of them - except one which has tag/padding. In its case, playback 
quality
is virtually the same as without the patch, i.e. no harm done.

Cheers, Karsten

> Am 07.07.2018 um 19:41 schrieb Karsten Otto :
> 
> MP3 frames may not be aligned to aa chunk boundaries. When seeking,
> calculate the expected frame offset in the target chunk. Adjust the
> timestamp and truncate the next packet accordingly.
> 
> This solution works for the majority of tested audio material. For
> some rare encodings with mp3 padding or embedded id3 tags, it will
> mispredict the correct offset, and at worst skip an extra frame.
> ---
> libavformat/aadec.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/aadec.c b/libavformat/aadec.c
> index e3c03bc522..2b9e4e526c 100644
> --- a/libavformat/aadec.c
> +++ b/libavformat/aadec.c
> @@ -37,6 +37,7 @@
> #define TEA_BLOCK_SIZE 8
> #define CHAPTER_HEADER_SIZE 8
> #define TIMEPREC 1000
> +#define MP3_FRAME_SIZE 104
> 
> typedef struct AADemuxContext {
> AVClass *class;
> @@ -50,6 +51,7 @@ typedef struct AADemuxContext {
> int64_t current_chapter_size;
> int64_t content_start;
> int64_t content_end;
> +int seek_offset;
> } AADemuxContext;
> 
> static int get_second_size(char *codec_name)
> @@ -230,6 +232,7 @@ static int aa_read_header(AVFormatContext *s)
> ff_update_cur_dts(s, st, 0);
> avio_seek(pb, start, SEEK_SET);
> c->current_chapter_size = 0;
> +c->seek_offset = 0;
> 
> return 0;
> }
> @@ -295,12 +298,13 @@ static int aa_read_packet(AVFormatContext *s, AVPacket 
> *pkt)
> if (c->current_chapter_size <= 0)
> c->current_chapter_size = 0;
> 
> -ret = av_new_packet(pkt, written);
> +ret = av_new_packet(pkt, written - c->seek_offset);
> if (ret < 0)
> return ret;
> -memcpy(pkt->data, buf, written);
> +memcpy(pkt->data, buf + c->seek_offset, written - c->seek_offset);
> pkt->pos = pos;
> 
> +c->seek_offset = 0;
> return 0;
> }
> 
> @@ -344,7 +348,12 @@ static int aa_read_seek(AVFormatContext *s,
> c->current_chapter_size = chapter_size - chapter_pos;
> c->chapter_idx = 1 + chapter_idx;
> 
> -ff_update_cur_dts(s, s->streams[0], ch->start + chapter_pos * TIMEPREC);
> +// handle extra offset for unaligned frames
> +if (s->streams[0]->codecpar->codec_id == AV_CODEC_ID_MP3) {
> +c->seek_offset = (MP3_FRAME_SIZE - chapter_pos % MP3_FRAME_SIZE) % 
> MP3_FRAME_SIZE;
> +}
> +
> +ff_update_cur_dts(s, s->streams[0], ch->start + (chapter_pos + 
> c->seek_offset) * TIMEPREC);
> 
> return 1;
> }
> -- 
> 2.14.3 (Apple Git-98)
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avformat/movenc: write track data in minf->hdlr for MOV

[Gyan Doshi]

Plan to push in a day if no objections.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Limited timecode support for lavd/decklink

[Jonathan Morley]

Hi Marton et al,

I am revisiting this now that I have access to the BlackMagic DeckLink Duo 
again. I see what made it into master and had a few questions.

1) Can you please explain more about storing the timecodes as side packet data 
in each video packet? Basically is there some convention among demuxers and 
muxers to handle that specific metadata?

2) Is there any reason not to make a valid timecode track (ala 
AVMEDIA_TYPE_DATA AVStream) with timecode packets? Would that conflict with the 
side data approach currently implemented?

I have found that (much as you originally predicted) my original approach 
relies on what could generously be called a race case. Since I was using the 
decklink demuxer to feed the movenc format writer I was relying on having set 
the timecode metadata on the video stream before either mov_init or 
mov_write_header get called (since those two functions create the timecode 
track for “free” if they detect the metadata initially). This is not really a 
deterministic approach and seems to be worse than making a valid timecode 
stream to begin with.

What I am trying to understand now is if there is any overlap in responsibility 
between the video packet side data approach and creating a dedicated timecode 
data stream. Please let me know what you think.

Thanks,
Jon

> On Jun 12, 2018, at 3:27 PM, Marton Balint  wrote:
> 
> 
> 
> On Tue, 12 Jun 2018, Dave Rice wrote:
> 
>> 
>>> On Jun 7, 2018, at 5:01 PM, Marton Balint  wrote:
>>> On Thu, 7 Jun 2018, Dave Rice wrote:
>>> [...]
 Before I only tested with vitc but now have a serial cable connected as 
 well and found a source tape that has distinct values for LTC and VITC 
 timecodes. The LTC values are from 1:00:00 to 2:00:00 and the VITC values 
 are from 07:00:00 - 08:00:00.
 With the deckcontrol utility at https://github.com/bavc/deckcontrol 
 , I can use the command gettimecode 
 to grab the LTC value:
 deckcontrol gettimecode
 Issued command 'gettimecode'
 TC=07:37:56:21
 Command sucessfully issued
 Error sending command (No error)
 With these patches, I can only grab the vitc values:
 for i in rp188vitc rp188vitc2 rp188ltc rp188any vitc vitc2 serial ; do 
 echo -n "${i}: " ; ./ffprobe -v quiet -timecode_format "$i" -f decklink 
 -draw_bars 0 -audio_input embedded -video_input sdi -format_code ntsc 
 -channels 8 -raw_format yuv422p10 -i "UltraStudio Express" -select_streams 
 v -show_entries stream_tags=timecode -of default=nw=1:nk=1 ; echo ; done
 rp188vitc: rp188vitc2: rp188ltc: rp188any: vitc: 01:41:44;06
 vitc2: 01:41:44;21
 serial:
 Also it may be interesting in cases like this to support accepting 
 multiple timecode inputs at once, such as "-timecode_format vitc+rp188ltc” 
 though it would need to be contextualized more in metadata.
 With a serial cable connected, I can access LTC via the deckcontrol 
 utility but not with this patch.
>>> Well, the way I understand it, deckcontrol is using a totally different 
>>> timecode source: the RS422 deck control interface. In contrast, the
>>> timecode capture in the patch is using the SDI (video) source.
>>> If the deck does not put the LTC timecode into SDI line 10, then the driver 
>>> won't be able to capture it if you specify 'rp188ltc'. I am not sure 
>>> however why 'serial' does not work, but from a quick look at the SDK maybe 
>>> that only works if you use the deck control capture functions…
>> 
> 
>> I see at 
>> https://forum.blackmagicdesign.com/viewtopic.php?f=12&t=71730&p=400097&hilit=bmdTimecodeSerial#p400097
>>  
>> 
>>  that capturing bmdTimecodeSerial is an issue there too, so this is likely 
>> an issue with the sdk rather than with your patch. Otherwise I’ve been 
>> testing this more and find it really useful. Hope to see this merged.
> 
> Pushed, thanks for testing.
> 
> Regards,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[Derek Buitenhuis]

Hi,

Apologies for commenting on this so many months after it was pushed.

> ffmpeg | branch: master | Sasi Inguva  | 
> Mon Dec 18 15:31:16 2017 -0800| [58a25aeb8e69532aae6ed1762fe7e0b260990010] | 
> committer: Michael Niedermayer
>
> lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.
>
> Signed-off-by: Sasi Inguva 
> Signed-off-by: Michael Niedermayer 
>
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=58a25aeb8e69532aae6ed1762fe7e0b260990010
> ---

This commit massively tanked perf of mov demuxer when opening files.
On average it has doubled and/or tripled (!!!) the amount of cycles that
opening an MP4 needs.

Also, I'm not sure why generic PTS reordering/delay code is in mov.c,
rather than utils.c or something. There's nothing inherently mov-specific
about this, unless you count "has an index".

On an example file (24h long, warm runs):

Before Patch

4446217810 decicycles in mov_build_index,   1 runs,  0 skips
4603125860 decicycles in mov_build_index,   2 runs,  0 skips

After Patch
---
14457275100 decicycles in mov_build_index,   1 runs,  0 skips
9608655040 decicycles in mov_build_index,   2 runs,  0 skips

I happen to call the mov open API quite heavily (in my case, for on-the-fly
remuxing), and this increase CPU load around 25%+ per core, overall,
which is nontrivial.

I appreciate the perf of opening a file may not be something we care about,
so I see a few options:

* I just patch it out at $dayjob; not ideal, since I prefer to upstream, but
  I can understand the usecase is too niche for upstreaming.
* Add a yet another option to mov.c to bypass it entirely.
* Add yet another option to mov.c to restrict the calculations to the first
  MAX_REORDER_FRAMES+1 frames of the file. This would make
  it unsuitable for seeking.
* Move the code to a generic place like utils.c and add a generic
  option to bypass it.
* Some algorithmic trickery to make it faster - I tried to think of a better
  way to do it, but all the things I could think of would only yeild minor
  gains, leaving the overal big-O complexity the same.
* Some mix of the above, or something not listed here.

Ideas and comments very welcome, even if they amount to "go pound
sand".

Cheers,
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] mjpegdec: Support 4x1, 2x1, 2x1 notation for 4:2:2 chroma subsampling

[Derek Buitenhuis]

Hi,

Sorry for the slow response; life is hectic.

On Tue, Jun 19, 2018 at 8:32 PM, Michael Niedermayer
 wrote:
> The absolute values define the bitstream and have to be used

OK, I was unaware.

> with a count of 4, mjpeg is coded in MCUs of 4 8x8 blocks in that direction
> all buffers must be sized accordingly so that these blocks fit in.
> I suspect that is already done but i could be wrong

Near as I can tell, it should already be handled OK?

I would also update the bit you mentioned, but, if I'm honest,
I am not 100% sure it and its subsequent bits of uncommented
bit fiddling do, or why.

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

[FFmpeg-devel] avformat/lrcdec: fix losing opening bracket

[Umair Khan]

Hi,

Patch attached.

-Umair


0001-avformat-lrcdec-fix-losing-opening-bracket.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] lavc/amfenc: moving amf common code (library and context) to lavu/hwcontext_amf from amfenc to be reused in other amf components

[Alexander Kravchenko]

---
 libavcodec/amfenc.c| 247 +
 libavcodec/amfenc.h|  27 +---
 libavutil/Makefile |   2 +
 libavutil/hwcontext.c  |   4 +
 libavutil/hwcontext.h  |   1 +
 libavutil/hwcontext_amf.c  | 271 +
 libavutil/hwcontext_amf.h  |  54 
 libavutil/hwcontext_internal.h |   1 +
 8 files changed, 368 insertions(+), 239 deletions(-)
 create mode 100644 libavutil/hwcontext_amf.c
 create mode 100644 libavutil/hwcontext_amf.h

diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 384d8efc92..5a0fb90433 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -21,13 +21,7 @@
 #include "libavutil/avassert.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/hwcontext.h"
-#if CONFIG_D3D11VA
-#include "libavutil/hwcontext_d3d11va.h"
-#endif
-#if CONFIG_DXVA2
-#define COBJMACROS
-#include "libavutil/hwcontext_dxva2.h"
-#endif
+
 #include "libavutil/mem.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/time.h"
@@ -35,14 +29,12 @@
 #include "amfenc.h"
 #include "internal.h"
 
-#if CONFIG_D3D11VA
-#include 
+#if CONFIG_DXVA2
+#include 
 #endif
 
-#ifdef _WIN32
-#include "compat/w32dlfcn.h"
-#else
-#include 
+#if CONFIG_D3D11VA
+#include 
 #endif
 
 #define FFMPEG_AMF_WRITER_ID L"ffmpeg_amf"
@@ -88,34 +80,18 @@ static enum AMF_SURFACE_FORMAT amf_av_to_amf_format(enum 
AVPixelFormat fmt)
 return AMF_SURFACE_UNKNOWN;
 }
 
-static void AMF_CDECL_CALL AMFTraceWriter_Write(AMFTraceWriter *pThis,
-const wchar_t *scope, const wchar_t *message)
-{
-AmfTraceWriter *tracer = (AmfTraceWriter*)pThis;
-av_log(tracer->avctx, AV_LOG_DEBUG, "%ls: %ls", scope, message); // \n is 
provided from AMF
-}
 
-static void AMF_CDECL_CALL AMFTraceWriter_Flush(AMFTraceWriter *pThis)
-{
-}
-
-static AMFTraceWriterVtbl tracer_vtbl =
-{
-.Write = AMFTraceWriter_Write,
-.Flush = AMFTraceWriter_Flush,
-};
-
-static int amf_load_library(AVCodecContext *avctx)
+static int amf_init_context(AVCodecContext *avctx)
 {
-AmfContext*ctx = avctx->priv_data;
-AMFInit_Fn init_fun;
-AMFQueryVersion_Fn version_fun;
-AMF_RESULT res;
+AmfContext *ctx = avctx->priv_data;
+AVAMFDeviceContext *amf_ctx;
+int ret;
 
 ctx->delayed_frame = av_frame_alloc();
 if (!ctx->delayed_frame) {
 return AVERROR(ENOMEM);
 }
+
 // hardcoded to current HW queue size - will realloc in 
timestamp_queue_enqueue() if too small
 ctx->timestamp_list = av_fifo_alloc((avctx->max_b_frames + 16) * 
sizeof(int64_t));
 if (!ctx->timestamp_list) {
@@ -123,119 +99,9 @@ static int amf_load_library(AVCodecContext *avctx)
 }
 ctx->dts_delay = 0;
 
-
-ctx->library = dlopen(AMF_DLL_NAMEA, RTLD_NOW | RTLD_LOCAL);
-AMF_RETURN_IF_FALSE(ctx, ctx->library != NULL,
-AVERROR_UNKNOWN, "DLL %s failed to open\n", AMF_DLL_NAMEA);
-
-init_fun = (AMFInit_Fn)dlsym(ctx->library, AMF_INIT_FUNCTION_NAME);
-AMF_RETURN_IF_FALSE(ctx, init_fun != NULL, AVERROR_UNKNOWN, "DLL %s failed 
to find function %s\n", AMF_DLL_NAMEA, AMF_INIT_FUNCTION_NAME);
-
-version_fun = (AMFQueryVersion_Fn)dlsym(ctx->library, 
AMF_QUERY_VERSION_FUNCTION_NAME);
-AMF_RETURN_IF_FALSE(ctx, version_fun != NULL, AVERROR_UNKNOWN, "DLL %s 
failed to find function %s\n", AMF_DLL_NAMEA, AMF_QUERY_VERSION_FUNCTION_NAME);
-
-res = version_fun(&ctx->version);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "%s failed with 
error %d\n", AMF_QUERY_VERSION_FUNCTION_NAME, res);
-res = init_fun(AMF_FULL_VERSION, &ctx->factory);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "%s failed with 
error %d\n", AMF_INIT_FUNCTION_NAME, res);
-res = ctx->factory->pVtbl->GetTrace(ctx->factory, &ctx->trace);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "GetTrace() 
failed with error %d\n", res);
-res = ctx->factory->pVtbl->GetDebug(ctx->factory, &ctx->debug);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "GetDebug() 
failed with error %d\n", res);
-return 0;
-}
-
-#if CONFIG_D3D11VA
-static int amf_init_from_d3d11_device(AVCodecContext *avctx, 
AVD3D11VADeviceContext *hwctx)
-{
-AmfContext *ctx = avctx->priv_data;
-AMF_RESULT res;
-
-res = ctx->context->pVtbl->InitDX11(ctx->context, hwctx->device, 
AMF_DX11_1);
-if (res != AMF_OK) {
-if (res == AMF_NOT_SUPPORTED)
-av_log(avctx, AV_LOG_ERROR, "AMF via D3D11 is not supported on the 
given device.\n");
-else
-av_log(avctx, AV_LOG_ERROR, "AMF failed to initialise on the given 
D3D11 device: %d.\n", res);
-return AVERROR(ENODEV);
-}
-
-return 0;
-}
-#endif
-
-#if CONFIG_DXVA2
-static int amf_init_from_dxva2_device(AVCodecContext *avctx, 
AVDXVA2DeviceContext *hwctx)
-{
-AmfContext *ctx = avctx->priv_data;
-HANDLE device_handle;
-IDirect3DDevice9 *device;
-HRESULT hr;
-   

[FFmpeg-devel] [PATCH 2/2] lavf/vf_scale_amf: AMF scaler/format converter filter implementation

[Alexander Kravchenko]

---
Sending updated patch based on Mark's review
1) added RGBA/BGRA
2) in case is device_ctx is set there is only the device hw format will be 
allowed as input and output
3) extended amf properties removed for now to have usual for ffmpeg 
scaler&format converter interface
4) input frame colorspace is set as color profile to select conversion matrix 
in case YUV->RGB, user setting removed.
5) misc bugs fixed


 configure  |   1 +
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/vf_scale_amf.c | 623 +
 4 files changed, 626 insertions(+)
 create mode 100644 libavfilter/vf_scale_amf.c

diff --git a/configure b/configure
index b1a4dcfc42..321e9bdb70 100755
--- a/configure
+++ b/configure
@@ -3385,6 +3385,7 @@ rubberband_filter_deps="librubberband"
 sab_filter_deps="gpl swscale"
 scale2ref_filter_deps="swscale"
 scale_filter_deps="swscale"
+scale_amf_filter_deps="amf"
 scale_qsv_filter_deps="libmfx"
 select_filter_select="pixelutils"
 sharpness_vaapi_filter_deps="vaapi VAProcPipelineParameterBuffer"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 7735c26529..1b35c9dd5e 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -317,6 +317,7 @@ OBJS-$(CONFIG_ROBERTS_OPENCL_FILTER) += 
vf_convolution_opencl.o opencl.o
 OBJS-$(CONFIG_ROTATE_FILTER) += vf_rotate.o
 OBJS-$(CONFIG_SAB_FILTER)+= vf_sab.o
 OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o scale.o
+OBJS-$(CONFIG_SCALE_AMF_FILTER)  += vf_scale_amf.o scale.o
 OBJS-$(CONFIG_SCALE_CUDA_FILTER) += vf_scale_cuda.o 
vf_scale_cuda.ptx.o
 OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
 OBJS-$(CONFIG_SCALE_QSV_FILTER)  += vf_scale_qsv.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 0ded83ede2..7c7eb1526a 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -303,6 +303,7 @@ extern AVFilter ff_vf_roberts_opencl;
 extern AVFilter ff_vf_rotate;
 extern AVFilter ff_vf_sab;
 extern AVFilter ff_vf_scale;
+extern AVFilter ff_vf_scale_amf;
 extern AVFilter ff_vf_scale_cuda;
 extern AVFilter ff_vf_scale_npp;
 extern AVFilter ff_vf_scale_qsv;
diff --git a/libavfilter/vf_scale_amf.c b/libavfilter/vf_scale_amf.c
new file mode 100644
index 00..49250281e5
--- /dev/null
+++ b/libavfilter/vf_scale_amf.c
@@ -0,0 +1,623 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * scale video filter - AMF
+ */
+
+#include 
+#include 
+
+#include "libavutil/avassert.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/time.h"
+
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_amf.h"
+
+#include "AMF/components/VideoConverter.h"
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+#include "scale.h"
+
+#if CONFIG_DXVA2
+#include 
+#endif
+
+#if CONFIG_D3D11VA
+#include 
+#endif
+
+#define AMFAV_RETURN_IF_FALSE(avctx, exp, ret_value, /*message,*/ ...) \
+if (!(exp)) { \
+av_log(avctx, AV_LOG_ERROR, __VA_ARGS__); \
+return ret_value; \
+}
+
+#define AMFAV_GOTO_FAIL_IF_FALSE(avctx, exp, ret_value, /*message,*/ ...) \
+if (!(exp)) { \
+av_log(avctx, AV_LOG_ERROR, __VA_ARGS__); \
+ret = ret_value; \
+goto fail; \
+}
+
+typedef struct FormatMap {
+enum AVPixelFormat   av_format;
+enum AMF_SURFACE_FORMAT  amf_format;
+} FormatMap;
+
+static const FormatMap format_map[] =
+{
+{ AV_PIX_FMT_NV12,   AMF_SURFACE_NV12 },
+
+{ AV_PIX_FMT_BGR0,   AMF_SURFACE_BGRA },
+{ AV_PIX_FMT_BGRA,   AMF_SURFACE_BGRA },
+
+{ AV_PIX_FMT_RGB0,   AMF_SURFACE_RGBA },
+{ AV_PIX_FMT_RGBA,   AMF_SURFACE_RGBA },
+
+{ AV_PIX_FMT_0RGB,   AMF_SURFACE_ARGB },
+{ AV_PIX_FMT_ARGB,   AMF_SURFACE_ARGB },
+
+{ AV_PIX_FMT_GRAY8,  AMF_SURFACE_GRAY8 },
+{ AV_PIX_FMT_YUV420P,AMF_SURFACE_YUV420P },
+{ AV_PIX_FMT_YUYV422,AMF_SURFACE_YUY2 },
+};
+
+static enum AMF_SURFACE_FORMAT amf_av_to_amf_format(enum AVPixelFormat fmt)
+{
+int i;
+for (i = 0; i < amf_countof

Re: [FFmpeg-devel] [PATCH v8 2/3] lavf/riff: add avs2 fourcc

[Carl Eugen Hoyos]

2018-07-10 14:50 GMT+02:00, Carl Eugen Hoyos :
> 2018-07-05 13:00 GMT+02:00, hwren :
>> Signed-off-by: hwren 
>> ---
>>  libavformat/riff.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavformat/riff.c b/libavformat/riff.c
>> index 8911725..4153372 100644
>> --- a/libavformat/riff.c
>> +++ b/libavformat/riff.c
>> @@ -369,6 +369,7 @@ const AVCodecTag ff_codec_bmp_tags[] = {
>>  { AV_CODEC_ID_ZMBV, MKTAG('Z', 'M', 'B', 'V') },
>>  { AV_CODEC_ID_KMVC, MKTAG('K', 'M', 'V', 'C') },
>>  { AV_CODEC_ID_CAVS, MKTAG('C', 'A', 'V', 'S') },
>> +{ AV_CODEC_ID_AVS2, MKTAG('A', 'V', 'S', '2') },
>
> Why is this needed?

Please ignore this.

A sample would still be nice, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mpegts: add support for AVS2

[Carl Eugen Hoyos]

2018-05-26 8:50 GMT+02:00, hwren :

> diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
> index 272e2be..b37db3c 100644
> --- a/libavformat/mpegts.h
> +++ b/libavformat/mpegts.h
> @@ -55,6 +55,7 @@
>  #define STREAM_TYPE_VIDEO_H264  0x1b
>  #define STREAM_TYPE_VIDEO_HEVC  0x24
>  #define STREAM_TYPE_VIDEO_CAVS  0x42
> +#define STREAM_TYPE_VIDEO_AVS2  0xd2

This hunk should be part of the patch changing mpegtsenc.c
(It is not needed for demuxing, only for muxing.)

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate: allow temp files for passed test to be kept

[Gyan Doshi]

On 10-07-2018 05:40 PM, Carl Eugen Hoyos wrote:


Shouldn't this be -1 for keep if fail, 0 for always delete, 1 for keep?


$keep is checked only when $err = 0 i.e.

a) passed test or
b) failed test and GEN != no

In the 2nd case, since user has decided to overwrite existing ref, I 
assume the action is post-diagnosis and the failure doesn't signal a

regression.

Regards,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v8 2/3] lavf/riff: add avs2 fourcc

[Carl Eugen Hoyos]

2018-07-05 13:00 GMT+02:00, hwren :
> Signed-off-by: hwren 
> ---
>  libavformat/riff.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/riff.c b/libavformat/riff.c
> index 8911725..4153372 100644
> --- a/libavformat/riff.c
> +++ b/libavformat/riff.c
> @@ -369,6 +369,7 @@ const AVCodecTag ff_codec_bmp_tags[] = {
>  { AV_CODEC_ID_ZMBV, MKTAG('Z', 'M', 'B', 'V') },
>  { AV_CODEC_ID_KMVC, MKTAG('K', 'M', 'V', 'C') },
>  { AV_CODEC_ID_CAVS, MKTAG('C', 'A', 'V', 'S') },
> +{ AV_CODEC_ID_AVS2, MKTAG('A', 'V', 'S', '2') },

Why is this needed?

Please point us to a sample, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate: allow temp files for passed test to be kept

[Carl Eugen Hoyos]

2018-07-06 11:35 GMT+02:00, Gyan Doshi :

> +@item KEEP
> +Set to @samp{1} to keep temp files generated by fate test(s) when test is 
> successful.
> +Default is @samp{0}, which removes these files. Files are always kept when a 
> test
> +fails.

Sorry for the late comment:
Shouldn't this be -1 for keep if fail, 0 for always delete, 1 for keep?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/drawtext: fix box sizing

[Gyan Doshi]

Test command:

ffplay -f lavfi -i "color,\
drawtext=fontfile='arial.ttf':fontcolor=white:fontsize=H/5:\
text='A string of characters':\
box=1:boxcolor=green:boxborderw=5:\
x='w-w*t/5':y=-th+h*t/10"

From b98969d12b3f6959ab1a036f20ba649951bcd1ea Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Tue, 10 Jul 2018 15:14:06 +0530
Subject: [PATCH] avfilter/drawtext: fix box sizing

At present, box size is clipped to frame size before being drawn,
which can lead to the box not fully covering animated text which is
longer than one or both frame dimensions.

Since ff_blend_rectangle correctly takes care of clipping, it is skipped
here which results in correct box sizing
---
 libavfilter/vf_drawtext.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index 3affa736c7..cca2cbcb88 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -1407,8 +1407,8 @@ static int draw_text(AVFilterContext *ctx, AVFrame *frame,
 update_color_with_alpha(s, &bordercolor, s->bordercolor);
 update_color_with_alpha(s, &boxcolor   , s->boxcolor   );
 
-box_w = FFMIN(width - 1 , max_text_line_w);
-box_h = FFMIN(height - 1, y + s->max_glyph_h);
+box_w = max_text_line_w;
+box_h = y + s->max_glyph_h;
 
 if (s->fix_bounds) {
 
-- 
2.17.1___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Use channel count if channel layout is undefined

[Marcin Gorzel]

Hi Michael,

I think I know where the misunderstanding could be.

The main changes in my patch are:

rematrix.c:389 and rematrix_int.c:36:

Before:
int nb_in  = av_get_channel_layout_nb_channels(s->in_ch_layout)

After:
int nb_in  = s->in_ch_layout != 0
? av_get_channel_layout_nb_channels(s->in_ch_layout)
: s->user_in_ch_count;

However, the change you are referring to (rematrix.c:72) has been made just
to match the above changes (although you are right that functionally this
particular one change should be the same).
I just thought that
since av_get_channel_layout_nb_channels(s->user_in_ch_layout) was
originally used, there may be preference to rely on the channel layout
first (if available) before falling back to the user channel count.
Please let me know if that makes sense.

Each field has a defined range in libswresample/options.c
> the AVOption code checks this when setting the field


> If the value in the table is wrong, thats what should be fixed.
> If something sets it ignoring the value, that code should be fixed.
> i dont think we should add a check without first understanding what
> sets it outside the range


I believe the check if the number of channels is valid is made in
libavcodec/utils.c:676.
However, the output error message is quite general and possibly not very
helpful:

Error while opening decoder for input stream #0:0 : Invalid argument

That's why in this patch I've added an av_log in the utils.c so that the
output error message is more useful:

[pcm_s16le @ 0x55fd9950d5c0] Unsupported number of channels: 72.
Stream mapping:
  Stream #0:0 -> #0:0 (pcm_s16le (native) -> pcm_s16le (native))
Error while opening decoder for input stream #0:0 : Invalid argument

Re. the additional checks in the swresample.c, if you think they are
unnecessary, I will happily remove them from this patch. Please let me know!

Regards,

Marcin

On Mon, Jul 9, 2018 at 9:11 PM Michael Niedermayer 
wrote:

> On Mon, Jul 09, 2018 at 01:55:37PM +0100, Marcin Gorzel wrote:
> > Thank you for your comments Michael and apologies if my commit message
> was
> > inadequate (I am new to this forum and this is my first patch).
> >
> > The bug can be reproduced when downmixing audio with more than 8
> channels,
> > for example:
> >
> > ./ffmpeg -i input_9ch.wav -filter:a:0
> > pan="6c|c0=0.166*c0+0.166*c6|c1=c1|c2=c2|c3=c3|c4=c4|c5=c5" -y
> > output_6ch.wav
> >
> > The result is noisy output in the first channel.
> >
> > #6790 applies the fix to the swr_set_matrix() method but a similar fix
> > needs to be applied to the swri_rematrix_init()
> > and swri_rematrix_init_x86() as well.
> >
>
> > Since currently the number of in/out channels is determined based on the
> > channel layout (av_get_channel_layout_nb_channels(s->in_ch_layout)) my
> > patch first checks if the channel layout is non-zero, and if it 0, then
> it
> > falls back to using the (user) channel count instead.
>
> theres the layout and the channel count
>
> before  one is checked and used and if possible and if not the other
> afterwards  one is checked and used and if possible and if not the other
>
> the patch seems to just check the other field
> I dont know how to match this up with the explanation of what this patch
> does.
> Quite possibly iam missing something
>
>
> >
> > Re. FFMIN: Agreed. I could add checks if the channel count is within
> > supported range. For example if s->user_out_ch_count < SWR_CH_MAX and
> > s->user_in_ch_count
> > < SWR_CH_MAX inside swr_init() method (for example, similarly as is done
> in
> > swresample.c:178)?
>
> Each field has a defined range in libswresample/options.c
> the AVOption code checks this when setting the field
>
> If the value in the table is wrong, thats what should be fixed.
> If something sets it ignoring the value, that code should be fixed.
> i dont think we should add a check without first understanding what
> sets it outside the range
>
>
>
>
>
> >
> > Thanks,
> >
> > Marcin
> >
> > On Sat, Jul 7, 2018 at 2:04 AM Michael Niedermayer
> 
> > wrote:
> >
> > > On Fri, Jul 06, 2018 at 03:15:58PM +0100, Marcin Gorzel wrote:
> > > > Rematrixing supports up to 64 channels but there is only a limited
> > > number of channel layouts defined. Currently, in/out channel count is
> > > obtained from the channel layout so if the channel layout is undefined
> > > (e.g. for 9, 10, 11 channels etc.) the in/out channel count will be 0
> and
> > > the rematrixing will fail. This change adds a check if the channel
> layout
> > > is non-zero, and if not, prefers to use the in|out_ch_count instead.
> This
> > > seems to be related to ticket #6790.
> > > > ---
> > > >  libswresample/rematrix.c  | 18 --
> > > >  libswresample/x86/rematrix_init.c |  8 ++--
> > > >  2 files changed, 18 insertions(+), 8 deletions(-)
> > >
> > > Iam not completely sure what this is trying to do exactly
> > > but the commit message inadequently describes it.
> > >
> > > #6790 is already fixed, the co

Re: [FFmpeg-devel] [PATCH] Use channel count if channel layout is undefined

[Marcin Gorzel]

Thanks for the explanation Nicolas.

When the matrix is not explicitly provided, lswr computes it. For that,
> it needs the channel layout, because you do not mix a rear channel the
> same way as a subwoofer. This patch absolutely needs to be tested under
> these circumstances too.
>

This patch does not affect the behavior when the downmix matrix is not
explicitly provided. For example, running:

./ffmpeg -i input_9ch.wav -ac 6 output_6ch.wav

Results in:

[auto_resampler_0 @ 0x5617a8668c80] [SWR @ 0x5617a8669180] Rematrix is
needed between 9 channels and 5.1 but there is not enough information to do
it
[auto_resampler_0 @ 0x5617a8668c80] Failed to configure output pad on
auto_resampler_0

Which I think is a reasonable expectation. Since the channel layout for 9
channel audio is undefined, there is no 'standard' way to downmix it to 5.1
or 2.0 etc.

For 'known' channel layouts, the output is correct as well:

./ffmpeg -i input_8ch.wav -ac 6 output_6ch.wav

[auto_resampler_0 @ 0x55adfbd6fa00] [SWR @ 0x55adfbd6fec0] FL: FL:0.585786
FR:0.00 FC:0.00 LFE:0.00 BL:0.00 BR:0.00 SL:0.00
SR:0.00
[auto_resampler_0 @ 0x55adfbd6fa00] [SWR @ 0x55adfbd6fec0] FR: FL:0.00
FR:0.585786 FC:0.00 LFE:0.00 BL:0.00 BR:0.00 SL:0.00
SR:0.00
[auto_resampler_0 @ 0x55adfbd6fa00] [SWR @ 0x55adfbd6fec0] FC: FL:0.00
FR:0.00 FC:0.585786 LFE:0.00 BL:0.00 BR:0.00 SL:0.00
SR:0.00
[auto_resampler_0 @ 0x55adfbd6fa00] [SWR @ 0x55adfbd6fec0] LFE: FL:0.00
FR:0.00 FC:0.00 LFE:0.585786 BL:0.00 BR:0.00 SL:0.00
SR:0.00
[auto_resampler_0 @ 0x55adfbd6fa00] [SWR @ 0x55adfbd6fec0] BL: FL:0.00
FR:0.00 FC:0.00 LFE:0.00 BL:0.585786 BR:0.00 SL:0.414214
SR:0.00
[auto_resampler_0 @ 0x55adfbd6fa00] [SWR @ 0x55adfbd6fec0] BR: FL:0.00
FR:0.00 FC:0.00 LFE:0.00 BL:0.00 BR:0.585786 SL:0.00
SR:0.414214
[auto_resampler_0 @ 0x55adfbd6fa00] ch:8 chl:7.1 fmt:s16 r:48000Hz -> ch:6
chl:5.1 fmt:s16 r:48000Hz

Thank you for raising that point and please let me know if you still have
concerns.

Regards,

-- 

Marcin Gorzel |  Software Engineer |  gor...@google.com |
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_qsv: fix log level for session initialization error

[Li, Zhong]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Moritz Barsnick
> Sent: Thursday, July 5, 2018 9:20 PM
> To: FFmpeg development discussions and patches
> 
> Subject: Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_qsv: fix log level for
> session initialization error
> 
> On Thu, Jul 05, 2018 at 10:17:35 +, Li, Zhong wrote:
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > Behalf Of Moritz Barsnick
> [...]
> > > Ideally, the returned mfxStatus would be evaluated and printed, but
> > > no such function is available (yet). %d perhaps?
> >
> > ff_qsv_print_error() can be used to print detailed error type. Is it 
> > helpful?
> 
> Basically yes, even in other places, but that function's in libavcodec, and
> we're in libavutil. We would need to move the code around IIUC,but I don't

Yes, it is a general problem in libavfilter an libavutil. Currently for mostly 
all cases "status != MFX_ERR_NONE", AVERROR_UNKNOWN is returned. 
This is confusing just like you mentioned mfx status haven't been printed. And 
also MFX_WRN_XX is not fatal, giving a warning message should be enough.
So making ff_qsv_print_error() can be called by libavfilter/libavutils should 
be a good idea.

> have any way of testing new code with this failing scenario right now (I have
> this effect on a Windows machine, but can't actually build on Windows), so
> that would be a blind modification from my side.
> Better if the QSV maintainers (i.e. you ;-)) did this.
> 
> This is the issue it would help to understand:
> http://ffmpeg.org/pipermail/ffmpeg-user/2018-July/040438.html
> 
> Thanks,
> Moritz

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