Re: [FFmpeg-devel] [PATCH] avformat: add vapoursynth wrapper

[Michael Niedermayer]

On Fri, May 04, 2018 at 09:51:38PM -0300, James Almer wrote:
> On 5/4/2018 9:19 PM, Michael Niedermayer wrote:
> > On Fri, May 04, 2018 at 02:02:02PM -0300, James Almer wrote:
> >> On 5/4/2018 1:51 PM, wm4 wrote:
> >>> On Fri, 4 May 2018 13:30:38 -0300
> >>> James Almer  wrote:
> >>>
>  On 5/4/2018 12:58 PM, wm4 wrote:
> > On Sat, 28 Apr 2018 19:05:29 +0200
> > wm4  wrote:
> >   
> >> This can "demux" .vpy files.
> >>
> >> Some minor code copied from other LGPL parts of FFmpeg.
> >>
> >> I did not found a good way to test a few of the more obscure features,
> >> like VFR nodes, compat pixel formats, or nodes with dynamic size/format
> >> changes. These can be easily implemented on demand.
> >> ---
> >>  configure |   5 +
> >>  libavformat/Makefile  |   1 +
> >>  libavformat/allformats.c  |   1 +
> >>  libavformat/vapoursynth.c | 421 
> >> ++
> >>  4 files changed, 428 insertions(+)
> >>  create mode 100644 libavformat/vapoursynth.c
> >>  
> >
> > Pushed, with some minor changes, and zero-copy frame passing.  
> 
>  The first step to fix something (in this case, usage sizeof(AVFrame)
>  outside libavutil) is not adding even more cases of the issue in 
>  question.
>  You still can replace this with rawvideo. Someone even already wrote it
>  for you.
> 
>  Lets try to abide our own ABI rules...
> >>>
> >>> That's requires a frame copy and is not what I went through all the
> >>> effort for.
> >>>
> >>> Why didn't you say anything when the kmsgrab code did the same thing?
> >>> Or when the unwrapped frame stuff was added in the first place?
> >>
> >> I did the other day on IRC when you asked me why i was against this, if
> >> you recall, because it was then when i found out this has been the case
> >> for a long while, and why I'm now saying adding even more cases is going
> >> in the opposite direction of an actual solution.
> >>
> >> In any case, i explicitly didn't block this, and no one else seems to
> >> care, so whatever.
> > 
> > I just now realized this, no, use of sizeof(AVFrame) outside libavutil is 
> > not ok,
> > thats a ABI/API breakage.
> > 
> > This must be removed/reverted. In all cases that are relevant.
> 
> Fixed/adapted, not reverted. For vapoursynth and kmsgrab it should be a
> matter of making them output rawvideo packets.

I think we meant the same thing

the use of sizeof(AVFrame) outside libavutil must be removed/reverted.
That can be of course through adapting/fixing the code in some form.



> 
> > (there can be exceptions if they are irrelevant to API/ABI compatibility)
> > 
> > For example the "if (pkt->size < sizeof(AVFrame))" in 
> > libavcodec/wrapped_avframe.c
> > should be ok
> 
> How is that one ok? Is it because sizeof(AVFrame) can grow but never
> shrink without a soname bump so the check is safe?

yes


> 
> Still, that's only the wrapped_avframe decoder. What about the encoder?

that one doesnt look so good unless iam missing something


> It's used by the null and yuv4mpeg muxers, plus decklink and
> libndi_newtek outdevs.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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

Re: [FFmpeg-devel] [PATCH] avformat: add vapoursynth wrapper

[James Almer]

On 5/4/2018 9:19 PM, Michael Niedermayer wrote:
> On Fri, May 04, 2018 at 02:02:02PM -0300, James Almer wrote:
>> On 5/4/2018 1:51 PM, wm4 wrote:
>>> On Fri, 4 May 2018 13:30:38 -0300
>>> James Almer  wrote:
>>>
 On 5/4/2018 12:58 PM, wm4 wrote:
> On Sat, 28 Apr 2018 19:05:29 +0200
> wm4  wrote:
>   
>> This can "demux" .vpy files.
>>
>> Some minor code copied from other LGPL parts of FFmpeg.
>>
>> I did not found a good way to test a few of the more obscure features,
>> like VFR nodes, compat pixel formats, or nodes with dynamic size/format
>> changes. These can be easily implemented on demand.
>> ---
>>  configure |   5 +
>>  libavformat/Makefile  |   1 +
>>  libavformat/allformats.c  |   1 +
>>  libavformat/vapoursynth.c | 421 
>> ++
>>  4 files changed, 428 insertions(+)
>>  create mode 100644 libavformat/vapoursynth.c
>>  
>
> Pushed, with some minor changes, and zero-copy frame passing.  

 The first step to fix something (in this case, usage sizeof(AVFrame)
 outside libavutil) is not adding even more cases of the issue in question.
 You still can replace this with rawvideo. Someone even already wrote it
 for you.

 Lets try to abide our own ABI rules...
>>>
>>> That's requires a frame copy and is not what I went through all the
>>> effort for.
>>>
>>> Why didn't you say anything when the kmsgrab code did the same thing?
>>> Or when the unwrapped frame stuff was added in the first place?
>>
>> I did the other day on IRC when you asked me why i was against this, if
>> you recall, because it was then when i found out this has been the case
>> for a long while, and why I'm now saying adding even more cases is going
>> in the opposite direction of an actual solution.
>>
>> In any case, i explicitly didn't block this, and no one else seems to
>> care, so whatever.
> 
> I just now realized this, no, use of sizeof(AVFrame) outside libavutil is not 
> ok,
> thats a ABI/API breakage.
> 
> This must be removed/reverted. In all cases that are relevant.

Fixed/adapted, not reverted. For vapoursynth and kmsgrab it should be a
matter of making them output rawvideo packets.

> (there can be exceptions if they are irrelevant to API/ABI compatibility)
> 
> For example the "if (pkt->size < sizeof(AVFrame))" in 
> libavcodec/wrapped_avframe.c
> should be ok

How is that one ok? Is it because sizeof(AVFrame) can grow but never
shrink without a soname bump so the check is safe?

Still, that's only the wrapped_avframe decoder. What about the encoder?
It's used by the null and yuv4mpeg muxers, plus decklink and
libndi_newtek outdevs.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: do not write timebase as framerate

[Carl Eugen Hoyos]

2018-05-04 15:00 GMT+02:00, wm4 :
> On Sat, 28 Apr 2018 19:24:21 +0200
> wm4  wrote:
>
>> If the API user doesn't set avg_frame_rate, matroskaenc will write the
>> current timebase as "default duration" for the video track. This makes
>> no sense, because the "default duration" implies the framerate of the
>> video. Since the timebase is forced to 1/1000, this will make the
>> resulting file claim 1000fps.
>>
>> Drop it and don't write the element. It's optional, so it's better not
>> to write it if the framerate is unknown.
>>
>> Strangely does not require FATE changes.
>> ---
>>  libavformat/matroskaenc.c | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
>> index 5950b4de44..b7ff1950d3 100644
>> --- a/libavformat/matroskaenc.c
>> +++ b/libavformat/matroskaenc.c
>> @@ -1304,8 +1304,6 @@ static int mkv_write_track(AVFormatContext *s,
>> MatroskaMuxContext *mkv,
>>  if(   st->avg_frame_rate.num > 0 && st->avg_frame_rate.den > 0
>> && av_cmp_q(av_inv_q(st->avg_frame_rate), st->time_base) > 0)
>>  put_ebml_uint(pb, MATROSKA_ID_TRACKDEFAULTDURATION,
>> 10LL * st->avg_frame_rate.den / st->avg_frame_rate.num);
>> -else
>> -put_ebml_uint(pb, MATROSKA_ID_TRACKDEFAULTDURATION,
>> 10LL * st->time_base.num / st->time_base.den);
>>
>>  if (!native_id &&
>>  ff_codec_get_tag(ff_codec_movvideo_tags, par->codec_id) &&
>
> Pushed.

Good to know that your behaviour hasn't improved.

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

[FFmpeg-devel] [PATCH]lavc/qdrw: Read PixMap palette

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #6195 for me.

Please comment, Carl Eugen
From 3aaeb2e44972d23d021e4567c9826162beb816f2 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 5 May 2018 02:24:15 +0200
Subject: [PATCH] lavc/qdrw: Read PixMap palette.

Fixes ticket #6195.
---
 libavcodec/qdrw.c |   12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/libavcodec/qdrw.c b/libavcodec/qdrw.c
index 82cc528..32ba410 100644
--- a/libavcodec/qdrw.c
+++ b/libavcodec/qdrw.c
@@ -45,14 +45,14 @@ enum QuickdrawOpcodes {
 };
 
 static int parse_palette(AVCodecContext *avctx, GetByteContext *gbc,
- uint32_t *pal, int colors)
+ uint32_t *pal, int colors, int pixmap)
 {
 int i;
 
 for (i = 0; i <= colors; i++) {
 uint8_t r, g, b;
 unsigned int idx = bytestream2_get_be16(gbc); /* color index */
-if (idx > 255) {
+if (idx > 255 && !pixmap) {
 av_log(avctx, AV_LOG_WARNING,
"Palette index out of range: %u\n", idx);
 bytestream2_skip(gbc, 6);
@@ -66,7 +66,7 @@ static int parse_palette(AVCodecContext *avctx, GetByteContext *gbc,
 bytestream2_skip(gbc, 1);
 b = bytestream2_get_byte(gbc);
 bytestream2_skip(gbc, 1);
-pal[idx] = (0xFFU << 24) | (r << 16) | (g << 8) | b;
+pal[pixmap ? i : idx] = (0xFFU << 24) | (r << 16) | (g << 8) | b;
 }
 return 0;
 }
@@ -335,6 +335,7 @@ static int decode_frame(AVCodecContext *avctx,
 while (bytestream2_get_bytes_left() >= 4) {
 int bppcnt, bpp;
 int rowbytes, pack_type;
+int flags;
 int opcode = bytestream2_get_be16();
 
 switch(opcode) {
@@ -345,7 +346,8 @@ static int decode_frame(AVCodecContext *avctx,
 case PACKBITSRGN:
 av_log(avctx, AV_LOG_DEBUG, "Parsing Packbit opcode\n");
 
-bytestream2_skip(, 30);
+flags = bytestream2_get_be16() & 0xC000;
+bytestream2_skip(, 28);
 bppcnt = bytestream2_get_be16(); /* cmpCount */
 bpp= bytestream2_get_be16(); /* cmpSize */
 
@@ -380,7 +382,7 @@ static int decode_frame(AVCodecContext *avctx,
 if ((ret = ff_get_buffer(avctx, p, 0)) < 0)
 return ret;
 
-ret = parse_palette(avctx, , (uint32_t *)p->data[1], colors);
+ret = parse_palette(avctx, , (uint32_t *)p->data[1], colors, flags & 0x8000);
 if (ret < 0)
 return ret;
 p->palette_has_changed = 1;
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] avformat: add vapoursynth wrapper

[Michael Niedermayer]

On Fri, May 04, 2018 at 02:02:02PM -0300, James Almer wrote:
> On 5/4/2018 1:51 PM, wm4 wrote:
> > On Fri, 4 May 2018 13:30:38 -0300
> > James Almer  wrote:
> > 
> >> On 5/4/2018 12:58 PM, wm4 wrote:
> >>> On Sat, 28 Apr 2018 19:05:29 +0200
> >>> wm4  wrote:
> >>>   
>  This can "demux" .vpy files.
> 
>  Some minor code copied from other LGPL parts of FFmpeg.
> 
>  I did not found a good way to test a few of the more obscure features,
>  like VFR nodes, compat pixel formats, or nodes with dynamic size/format
>  changes. These can be easily implemented on demand.
>  ---
>   configure |   5 +
>   libavformat/Makefile  |   1 +
>   libavformat/allformats.c  |   1 +
>   libavformat/vapoursynth.c | 421 
>  ++
>   4 files changed, 428 insertions(+)
>   create mode 100644 libavformat/vapoursynth.c
>   
> >>>
> >>> Pushed, with some minor changes, and zero-copy frame passing.  
> >>
> >> The first step to fix something (in this case, usage sizeof(AVFrame)
> >> outside libavutil) is not adding even more cases of the issue in question.
> >> You still can replace this with rawvideo. Someone even already wrote it
> >> for you.
> >>
> >> Lets try to abide our own ABI rules...
> > 
> > That's requires a frame copy and is not what I went through all the
> > effort for.
> > 
> > Why didn't you say anything when the kmsgrab code did the same thing?
> > Or when the unwrapped frame stuff was added in the first place?
> 
> I did the other day on IRC when you asked me why i was against this, if
> you recall, because it was then when i found out this has been the case
> for a long while, and why I'm now saying adding even more cases is going
> in the opposite direction of an actual solution.
> 
> In any case, i explicitly didn't block this, and no one else seems to
> care, so whatever.

I just now realized this, no, use of sizeof(AVFrame) outside libavutil is not 
ok,
thats a ABI/API breakage.

This must be removed/reverted. In all cases that are relevant.
(there can be exceptions if they are irrelevant to API/ABI compatibility)

For example the "if (pkt->size < sizeof(AVFrame))" in 
libavcodec/wrapped_avframe.c
should be ok

Thanks

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH v4]avocdec/nvenc: Reconfigure bitrate on the fly

[Carl Eugen Hoyos]

2018-05-04 10:32 GMT+02:00, Timo Rothenpieler :

> I'm not sure if actual resolution changes are even supported
> by avcodec.

There are better (read: DVB) samples but I can't find them atm:
https://trac.ffmpeg.org/raw-attachment/ticket/1507/Wrong_aspect_after_resolution_change.rmvb

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

[FFmpeg-devel] [PATCH 1/4] avcodec/videotoolbox: cleanups

[Aman Gupta]

From: Aman Gupta 

No functional changes.
---
 libavcodec/videotoolbox.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 57b6698e1b..1fd4be7135 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -340,7 +340,7 @@ int ff_videotoolbox_h264_start_frame(AVCodecContext *avctx,
  uint32_t size)
 {
 VTContext *vtctx = avctx->internal->hwaccel_priv_data;
-H264Context *h  = avctx->priv_data;
+H264Context *h = avctx->priv_data;
 
 if (h->is_avc == 1) {
 return videotoolbox_buffer_copy(vtctx, buffer, size);
@@ -935,9 +935,7 @@ static int videotoolbox_hevc_end_frame(AVCodecContext 
*avctx)
 HEVCContext *h = avctx->priv_data;
 AVFrame *frame = h->ref->frame;
 VTContext *vtctx = avctx->internal->hwaccel_priv_data;
-int ret;
-
-ret = videotoolbox_common_end_frame(avctx, frame);
+int ret = videotoolbox_common_end_frame(avctx, frame);
 vtctx->bitstream_size = 0;
 return ret;
 }
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 3/4] avcodec/hevc: remove videotoolbox hack

[Aman Gupta]

From: Aman Gupta 

No longer required since 63d875772d. The equivalent hack
for h264 was removed in that commit, but this one was missed.
---
 libavcodec/hevc_refs.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index ac462d350b..68c730edcc 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -208,9 +208,6 @@ int ff_hevc_output_frame(HEVCContext *s, AVFrame *out, int 
flush)
 if (nb_output) {
 HEVCFrame *frame = >DPB[min_idx];
 
-if (frame->frame->format == AV_PIX_FMT_VIDEOTOOLBOX && 
frame->frame->buf[0]->size == 1)
-return 0;
-
 ret = av_frame_ref(out, frame->frame);
 if (frame->flags & HEVC_FRAME_FLAG_BUMPING)
 ff_hevc_unref_frame(s, frame, HEVC_FRAME_FLAG_OUTPUT | 
HEVC_FRAME_FLAG_BUMPING);
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 2/4] avcodec/videotoolbox: split h264/hevc callbacks

[Aman Gupta]

From: Aman Gupta 

Previously the shared callbacks were trying to interpret
avctx->priv_data as H264Context*
---
 libavcodec/videotoolbox.c | 43 +--
 1 file changed, 33 insertions(+), 10 deletions(-)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 1fd4be7135..08b133e1b1 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -372,17 +372,13 @@ static int videotoolbox_h264_decode_params(AVCodecContext 
*avctx,
 return ff_videotoolbox_h264_decode_slice(avctx, buffer, size);
 }
 
-int ff_videotoolbox_h264_decode_slice(AVCodecContext *avctx,
-  const uint8_t *buffer,
-  uint32_t size)
+static int videotoolbox_common_decode_slice(AVCodecContext *avctx,
+const uint8_t *buffer,
+uint32_t size)
 {
 VTContext *vtctx = avctx->internal->hwaccel_priv_data;
-H264Context *h  = avctx->priv_data;
 void *tmp;
 
-if (h->is_avc == 1)
-return 0;
-
 tmp = av_fast_realloc(vtctx->bitstream,
   >allocated_size,
   vtctx->bitstream_size+size+4);
@@ -399,6 +395,18 @@ int ff_videotoolbox_h264_decode_slice(AVCodecContext 
*avctx,
 return 0;
 }
 
+int ff_videotoolbox_h264_decode_slice(AVCodecContext *avctx,
+  const uint8_t *buffer,
+  uint32_t size)
+{
+H264Context *h = avctx->priv_data;
+
+if (h->is_avc == 1)
+return 0;
+
+return videotoolbox_common_decode_slice(avctx, buffer, size);
+}
+
 int ff_videotoolbox_uninit(AVCodecContext *avctx)
 {
 VTContext *vtctx = avctx->internal->hwaccel_priv_data;
@@ -922,12 +930,27 @@ static int videotoolbox_h264_end_frame(AVCodecContext 
*avctx)
 return ret;
 }
 
+static int videotoolbox_hevc_start_frame(AVCodecContext *avctx,
+ const uint8_t *buffer,
+ uint32_t size)
+{
+return 0;
+}
+
+static int videotoolbox_hevc_decode_slice(AVCodecContext *avctx,
+  const uint8_t *buffer,
+  uint32_t size)
+{
+return videotoolbox_common_decode_slice(avctx, buffer, size);
+}
+
+
 static int videotoolbox_hevc_decode_params(AVCodecContext *avctx,
int type,
const uint8_t *buffer,
uint32_t size)
 {
-return ff_videotoolbox_h264_decode_slice(avctx, buffer, size);
+return videotoolbox_common_decode_slice(avctx, buffer, size);
 }
 
 static int videotoolbox_hevc_end_frame(AVCodecContext *avctx)
@@ -1084,8 +1107,8 @@ const AVHWAccel ff_hevc_videotoolbox_hwaccel = {
 .id = AV_CODEC_ID_HEVC,
 .pix_fmt= AV_PIX_FMT_VIDEOTOOLBOX,
 .alloc_frame= ff_videotoolbox_alloc_frame,
-.start_frame= ff_videotoolbox_h264_start_frame,
-.decode_slice   = ff_videotoolbox_h264_decode_slice,
+.start_frame= videotoolbox_hevc_start_frame,
+.decode_slice   = videotoolbox_hevc_decode_slice,
 .decode_params  = videotoolbox_hevc_decode_params,
 .end_frame  = videotoolbox_hevc_end_frame,
 .frame_params   = videotoolbox_frame_params,
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 4/4] avcodec/videotoolbox: fix decoding of some hevc videos

[Aman Gupta]

From: Aman Gupta 

See https://s3.amazonaws.com/tmm1/videotoolbox/germany-hevc-zdf.ts

Although videotoolbox_buffer_create() sets frame->hw_frames_ctx,
by the time videotoolbox_postproc_frame() is called, some frames
randomly have frame->hw_frames_ctx == NULL. I don't really
understand what's going on, and why this only affects some frames
and only in some hevc videos.

This patch attempts to detect the missing hw_frames_ctx and reset
it in the post_process callback. This is obviously a huge hack, but
it does fix playback of the affected samples.
---
 libavcodec/videotoolbox.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 08b133e1b1..279180179d 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -73,6 +73,7 @@ static int videotoolbox_buffer_copy(VTContext *vtctx,
 
 static int videotoolbox_postproc_frame(void *avctx, AVFrame *frame)
 {
+VTContext *vtctx = ((AVCodecContext *)avctx)->internal->hwaccel_priv_data;
 CVPixelBufferRef ref = *(CVPixelBufferRef *)frame->buf[0]->data;
 
 if (!ref) {
@@ -83,6 +84,11 @@ static int videotoolbox_postproc_frame(void *avctx, AVFrame 
*frame)
 
 frame->data[3] = (uint8_t*)ref;
 
+if (!frame->hw_frames_ctx)
+frame->hw_frames_ctx = av_buffer_ref(vtctx->cached_hw_frames_ctx);
+if (!frame->hw_frames_ctx)
+return AVERROR(ENOMEM);
+
 return 0;
 }
 
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH] libavcodec/cuviddec A53CC closed captions support added to cuviddec & nvenc

[Timo Rothenpieler]

applied



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v4]avocdec/nvenc: Reconfigure bitrate on the fly

[Timo Rothenpieler]

applied



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavfilter/vf_libvmaf.c The libvmaf filter tried to join on an invalid thread id

[James Almer]

On 5/3/2018 8:38 AM, Ronald S. Bultje wrote:
> Hi,
> 
> On Thu, May 3, 2018 at 4:41 AM, Kevin Wheatley 
> wrote:
> 
>> Following up my own email with another question or so:
>>
>> Could somebody point me at a suitable method of testing this within
>> the Fate framework?
> 
> 
> Why?
> 
> Your patch fixes a bug, I don't think we test bugs in fate, just features.
> 
> Patch LGTM.
> 
> Ronald

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

Re: [FFmpeg-devel] HLS Questions

[Moritz Barsnick]

On Thu, May 03, 2018 at 17:10:20 -0400, Ronak wrote:
> Are these issues being tracked somewhere already?

Bug reports are handled at https://trac.ffmpeg.org/ . You have a better
chance to get visibility there (though no guarantee).

> I'm happy to send pull requests, but I'll also have to get familiar
> with the AAC muxer code.

ffmpeg does not accept pull requests. You need to send your patch to
this mailing list (git format-patch or better git send-email).

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

Re: [FFmpeg-devel] [FFmpeg-devel, RFC] lavfi: add opencl tonemap filter.

[Niklas Haas]

Hello Ruiling,

On Fri,  4 May 2018 15:32:58 +0800, Ruiling Song  wrote:
> It basically does hdr to sdr conversion with tonemapping.
> 
> Signed-off-by: Ruiling Song 
> ---
> This patch tries to add a filter to do hdr to sdr conversion with tonemapping.
> The filter does all the job of tonemapping in one pass, which is quite 
> different from the vf_tonemap.c
> I choose this way because I think this would introduce less memory access.
> 
> And I find that tonemaping shares lots of code with colorspace conversion.
> So I move color space related code into seprated files (both OpenCL kernel 
> and host code).
> 
> I am not sure whether the design seems OK?
> Is there anybody would like to give some comments on the overall design or 
> implementation details?
> 
> 
> Thanks!
> Ruiling

As the original author of the tone mapping code that inspired vf_tonemap
and (by proxy) vf_tonemap_opencl, I can provide a handful of comments.

> +float3 map_one_pixel_rgb(float3 rgb, float peak) {
> +// de-saturate
> +float luma = get_luma(rgb.x, rgb.y, rgb.z);
> +float overbright = max(luma - 2.0f, 1e-6f) / max(luma, 1e-6f);
> +rgb = mix(rgb, (float3)luma, (float3)overbright);
> +
> +float sig = max(max(rgb.x, max(rgb.y, rgb.z)), 1e-6f);
> +float sig_old = sig;
> +sig = TONE_FUNC(sig, peak);
> +rgb *= (sig/sig_old);
> +return rgb;
> +}

I consider this desaturation algorithm outdated. It works, but I think
it produces lower quality results than this one:

  float sig = max(max(rgb.x, max(rgb.y, rgb.z)), 1e-6f);
  float luma = get_luma(rgb.x, rgb.y, rgb.z);
  float coeff = max(sig - 0.18f, 1e-6f) / max(sig, 1e-6f);

  const float desaturation_coefficient = 0.5f; // or configurable!
  coeff = pow(coeff, 10 / desaturation_coefficient;
  rgb = mix(rgb, (float3)luma, coeff);
  sig = mix(sig, luma, coeff);

  // do the rest of tone-mapping on `sig`
  float sig_old = sig;
  ...

Basically, I've done the following:

- Calculate the overbright coefficient on `sig` rather than `luma` alone
- Instead of using an offset of 2.0f, use an offset of 0.18f
- Take the coefficient to a high exponent (lower exponent = more
  desaturation, which is why I invert the user-configurable parameter)

Since the new code needs to read `sig`, we also have to move up the
`sig` calculation and then correctly adjust it afterwards as well.



More importantly, this algorithm is missing something that I now
consider very important, and which would align well with OpenCL: source
brightness detection. Just doing the tone-mapping "blind" like this
works to some extent, but I think the best results require also
adjusting the exposure in order to compensate for hollywood's tendency
to ship poorly mastered, over-illuminated HDR material.

The basic premise is to calculate both the peak brightness as well as
the average brightness on a frame-by-frame basis, and incorporate those
measured values in the algorithm, in order to re-normalize overly bright
scenes to correspond to a typical SDR average of around 0.25. In
addition to this, calculating the peak explicitly allows us to exactly
tailor the hable() function to this specific frame, even if the
mastering metadata is missing or useless. (Which it almost always is)

Doing this in OpenCL would essentially require implementing a big
map-reduce to keep track of respectively the sum and max of each pixel's
brightness. In addition to this, I recommend averaging the results over
a few frames (I like to use around one second), with the caveat that
this is best paired with at least a naive scene change detection
heuristic to make sure this averaging window gets reset on a scene
change.

> +static double determine_signal_peak(AVFrame *in)
> +{
> +AVFrameSideData *sd = av_frame_get_side_data(in, 
> AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
> +double peak = 0;
> +
> +if (sd) {
> +AVContentLightMetadata *clm = (AVContentLightMetadata *)sd->data;
> +peak = clm->MaxCLL;
> +}
> +
> +sd = av_frame_get_side_data(in, 
> AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
> +if (!peak && sd) {
> +AVMasteringDisplayMetadata *metadata = (AVMasteringDisplayMetadata 
> *)sd->data;
> +if (metadata->has_luminance)
> +peak = av_q2d(metadata->max_luminance);
> +}
> +
> +/* smpte2084 needs the side data above to work correctly
> + * if missing, assume that the original transfer was arib-std-b67 */
> +if (!peak)
> +peak = 1200;
> +
> +return peak;
> +}

This seems strange. For a source without peak tagging, you should
probably be deciding based on the video frame's tagged transfer function
(ST.2084 or STD-B67). If it's the former, default to 10,000, rather than
1200.

> +switch(input_frames_ctx->sw_format) {
> +case AV_PIX_FMT_P010:
> +err = launch_kernel(avctx, ctx->kernel, output, input, peak);
> +if (err < 0) goto fail;
> +break;
> +

Re: [FFmpeg-devel] [PATCH v2 2/4] avcodec/mediacodecdec: restructure mediacodec_receive_frame

[Aman Gupta]

On Fri, May 4, 2018 at 8:13 AM, Matthieu Bouron 
wrote:

> On Thu, May 03, 2018 at 10:24:49AM -0700, Aman Gupta wrote:
> > On Thu, May 3, 2018 at 12:33 AM, Matthieu Bouron <
> matthieu.bou...@gmail.com>
> > wrote:
> >
> > > On Wed, May 02, 2018 at 07:24:58PM -0700, Aman Gupta wrote:
> > > > From: Aman Gupta 
> > > >
> > > > The new logic follows a recommendation by @rcombs to use
> > > > dequeueInputBuffer with a timeout of 0 as a way to detect
> > > > whether the codec wants more data. The dequeued buffer index is
> > > > kept in MediaCodecDecContext until it can be used next.
> > > >
> > > > A similar technique is also used by the Google's official media
> > > > player Exoplayer: see MediaCodecRenderer.feedInputBuffer().
> > > >
> > > > Signed-off-by: Aman Gupta 
> > > > ---
> > > >  libavcodec/mediacodecdec.c| 80
> --
> > > -
> > > >  libavcodec/mediacodecdec_common.c | 28 --
> > > >  libavcodec/mediacodecdec_common.h |  4 +-
> > > >  3 files changed, 61 insertions(+), 51 deletions(-)
> > > >
> > > > diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> > > > index 86ceee5a83..2ac22dd1f6 100644
> > > > --- a/libavcodec/mediacodecdec.c
> > > > +++ b/libavcodec/mediacodecdec.c
> > > > @@ -391,33 +391,11 @@ done:
> > > >  return ret;
> > > >  }
> > > >
> > > > -static int mediacodec_send_receive(AVCodecContext *avctx,
> > > > -   MediaCodecH264DecContext *s,
> > > > -   AVFrame *frame, bool wait)
> > > > -{
> > > > -int ret;
> > > > -
> > > > -/* send any pending data from buffered packet */
> > > > -while (s->buffered_pkt.size) {
> > > > -ret = ff_mediacodec_dec_send(avctx, s->ctx,
> >buffered_pkt);
> > > > -if (ret == AVERROR(EAGAIN))
> > > > -break;
> > > > -else if (ret < 0)
> > > > -return ret;
> > > > -s->buffered_pkt.size -= ret;
> > > > -s->buffered_pkt.data += ret;
> > > > -if (s->buffered_pkt.size <= 0)
> > > > -av_packet_unref(>buffered_pkt);
> > > > -}
> > > > -
> > > > -/* check for new frame */
> > > > -return ff_mediacodec_dec_receive(avctx, s->ctx, frame, wait);
> > > > -}
> > > > -
> > > >  static int mediacodec_receive_frame(AVCodecContext *avctx, AVFrame
> > > *frame)
> > > >  {
> > > >  MediaCodecH264DecContext *s = avctx->priv_data;
> > > >  int ret;
> > > > +ssize_t index;
> > > >
> > > >  /* In delay_flush mode, wait until the user has released or
> rendered
> > > > all retained frames. */
> > > > @@ -427,28 +405,54 @@ static int mediacodec_receive_frame(
> AVCodecContext
> > > *avctx, AVFrame *frame)
> > > >  }
> > > >  }
> > > >
> > > > -/* flush buffered packet and check for new frame */
> > > > -ret = mediacodec_send_receive(avctx, s, frame, false);
> > > > +/* poll for new frame */
> > > > +ret = ff_mediacodec_dec_receive(avctx, s->ctx, frame, false);
> > > >  if (ret != AVERROR(EAGAIN))
> > > >  return ret;
> > > >
> > > > -/* skip fetching new packet if we still have one buffered */
> > > > -if (s->buffered_pkt.size > 0)
> > > > -return mediacodec_send_receive(avctx, s, frame, true);
> > > > +/* feed decoder */
> > > > +while (1) {
> > > > +if (s->ctx->current_input_buffer < 0) {
> > > > +/* poll for input space */
> > > > +index = ff_AMediaCodec_dequeueInputBuffer(s->ctx->
> codec,
> > > 0);
> > > > +if (index < 0) {
> > > > +/* no space, block for an output frame to appear */
> > > > +return ff_mediacodec_dec_receive(avctx, s->ctx,
> frame,
> > > true);
> > > > +}
> > > > +s->ctx->current_input_buffer = index;
> > > > +}
> > > >
> > > > -/* fetch new packet or eof */
> > > > -ret = ff_decode_get_packet(avctx, >buffered_pkt);
> > > > -if (ret == AVERROR_EOF) {
> > > > -AVPacket null_pkt = { 0 };
> > > > -ret = ff_mediacodec_dec_send(avctx, s->ctx, _pkt);
> > > > -if (ret < 0)
> > > > +/* try to flush any buffered packet data */
> > > > +if (s->buffered_pkt.size > 0) {
> > > > +ret = ff_mediacodec_dec_send(avctx, s->ctx,
> > > >buffered_pkt, false);
> > > > +if (ret >= 0) {
> > > > +s->buffered_pkt.size -= ret;
> > > > +s->buffered_pkt.data += ret;
> > > > +if (s->buffered_pkt.size <= 0)
> > > > +av_packet_unref(>buffered_pkt);
> > > > +} else if (ret < 0 && ret != AVERROR(EAGAIN)) {
> > > > +return ret;
> > > > +}
> > > > +
> > > > +/* poll for space again */
> > > > +continue;
> > > > +}
> > > > +
> > > > +/* fetch new packet or eof */
> > > > +ret = 

Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_edgedetect: add more formats support to canny mode

[Clément Bœsch]

On Thu, May 03, 2018 at 03:44:44PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/vf_edgedetect.c | 48 
> ++---
>  1 file changed, 28 insertions(+), 20 deletions(-)
> 
> diff --git a/libavfilter/vf_edgedetect.c b/libavfilter/vf_edgedetect.c
> index 6f86115d23..55c4cc3b5a 100644
> --- a/libavfilter/vf_edgedetect.c
> +++ b/libavfilter/vf_edgedetect.c
> @@ -52,6 +52,7 @@ struct plane_info {
>  uint8_t  *tmpbuf;
>  uint16_t *gradients;
>  char *directions;
> +int  width, height;
>  };
>  
>  typedef struct EdgeDetectContext {
> @@ -98,7 +99,7 @@ static int query_formats(AVFilterContext *ctx)
>  {
>  const EdgeDetectContext *edgedetect = ctx->priv;
>  static const enum AVPixelFormat wires_pix_fmts[] = {AV_PIX_FMT_GRAY8, 
> AV_PIX_FMT_NONE};
> -static const enum AVPixelFormat canny_pix_fmts[] = {AV_PIX_FMT_YUV444P, 
> AV_PIX_FMT_GBRP, AV_PIX_FMT_GRAY8, AV_PIX_FMT_NONE};
> +static const enum AVPixelFormat canny_pix_fmts[] = {AV_PIX_FMT_YUV420P, 
> AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV444P, AV_PIX_FMT_GBRP, AV_PIX_FMT_GRAY8, 
> AV_PIX_FMT_NONE};
>  static const enum AVPixelFormat colormix_pix_fmts[] = {AV_PIX_FMT_GBRP, 
> AV_PIX_FMT_GRAY8, AV_PIX_FMT_NONE};
>  AVFilterFormats *fmts_list;
>  const enum AVPixelFormat *pix_fmts = NULL;
> @@ -123,14 +124,19 @@ static int config_props(AVFilterLink *inlink)
>  int p;
>  AVFilterContext *ctx = inlink->dst;
>  EdgeDetectContext *edgedetect = ctx->priv;
> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
>  
>  edgedetect->nb_planes = inlink->format == AV_PIX_FMT_GRAY8 ? 1 : 3;
>  for (p = 0; p < edgedetect->nb_planes; p++) {
>  struct plane_info *plane = >planes[p];
> -
> -plane->tmpbuf = av_malloc(inlink->w * inlink->h);
> -plane->gradients  = av_calloc(inlink->w * inlink->h, 
> sizeof(*plane->gradients));
> -plane->directions = av_malloc(inlink->w * inlink->h);
> +int vsub = p ? desc->log2_chroma_h : 0;
> +int hsub = p ? desc->log2_chroma_w : 0;
> +
> +plane->width  = AV_CEIL_RSHIFT(inlink->w, hsub);
> +plane->height = AV_CEIL_RSHIFT(inlink->h, vsub);
> +plane->tmpbuf = av_malloc(plane->width * plane->height);
> +plane->gradients  = av_calloc(plane->width * plane->height, 
> sizeof(*plane->gradients));
> +plane->directions = av_malloc(plane->width * plane->height);
>  if (!plane->tmpbuf || !plane->gradients || !plane->directions)
>  return AVERROR(ENOMEM);
>  }
> @@ -338,42 +344,44 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
> *in)
>  uint8_t  *tmpbuf = plane->tmpbuf;
>  uint16_t *gradients  = plane->gradients;
>  int8_t   *directions = plane->directions;
> +const int width  = plane->width;
> +const int height = plane->height;
>  
>  if (!((1 << p) & edgedetect->filter_planes)) {
>  if (!direct)
>  av_image_copy_plane(out->data[p], out->linesize[p],
>  in->data[p], in->linesize[p],
> -inlink->w, inlink->h);
> +width, height);
>  continue;
>  }
>  
>  /* gaussian filter to reduce noise  */
> -gaussian_blur(ctx, inlink->w, inlink->h,
> -  tmpbuf,  inlink->w,
> +gaussian_blur(ctx, width, height,
> +  tmpbuf,  width,
>in->data[p], in->linesize[p]);
>  
>  /* compute the 16-bits gradients and directions for the next step */
> -sobel(inlink->w, inlink->h,
> -  gradients, inlink->w,
> -  directions,inlink->w,
> -  tmpbuf,inlink->w);
> +sobel(width, height,
> +  gradients, width,
> +  directions,width,
> +  tmpbuf,width);
>  
>  /* non_maximum_suppression() will actually keep & clip what's 
> necessary and
>   * ignore the rest, so we need a clean output buffer */
> -memset(tmpbuf, 0, inlink->w * inlink->h);
> -non_maximum_suppression(inlink->w, inlink->h,
> -tmpbuf,inlink->w,
> -directions,inlink->w,
> -gradients, inlink->w);
> +memset(tmpbuf, 0, width * height);
> +non_maximum_suppression(width, height,
> +tmpbuf,width,
> +directions,width,
> +gradients, width);
>  
>  /* keep high values, or low values surrounded by high values */
>  double_threshold(edgedetect->low_u8, edgedetect->high_u8,
> - inlink->w, inlink->h,
> + width, height,
> 

Re: [FFmpeg-devel] [PATCH 2/3] avfilter/vf_edgedetect: add planes option

[Clément Bœsch]

On Thu, May 03, 2018 at 03:44:43PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi|  4 +++-
>  libavfilter/vf_edgedetect.c | 25 +
>  2 files changed, 28 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 29b5a5b15f..245326154c 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -8272,8 +8272,10 @@ Mix the colors to create a paint/cartoon effect.
>  @item canny
>  Apply Canny edge detector on all selected planes.
>  @end table
> -
>  Default value is @var{wires}.
> +
> +@item planes
> +Select planes for filtering. By default all available planes are filtered.
>  @end table
>  
>  @subsection Examples
> diff --git a/libavfilter/vf_edgedetect.c b/libavfilter/vf_edgedetect.c
> index 534a302d90..6f86115d23 100644
> --- a/libavfilter/vf_edgedetect.c
> +++ b/libavfilter/vf_edgedetect.c
> @@ -26,12 +26,21 @@
>   */
>  
>  #include "libavutil/avassert.h"
> +#include "libavutil/imgutils.h"
>  #include "libavutil/opt.h"
>  #include "avfilter.h"
>  #include "formats.h"
>  #include "internal.h"
>  #include "video.h"
>  
> +#define PLANE_R 0x4
> +#define PLANE_G 0x1
> +#define PLANE_B 0x2
> +#define PLANE_Y 0x1
> +#define PLANE_U 0x2
> +#define PLANE_V 0x4
> +#define PLANE_A 0x8
> +
>  enum FilterMode {
>  MODE_WIRES,
>  MODE_COLORMIX,
> @@ -48,6 +57,7 @@ struct plane_info {
>  typedef struct EdgeDetectContext {
>  const AVClass *class;
>  struct plane_info planes[3];
> +int filter_planes;
>  int nb_planes;
>  double   low, high;
>  uint8_t  low_u8, high_u8;
> @@ -63,6 +73,13 @@ static const AVOption edgedetect_options[] = {
>  { "wires","white/gray wires on black",  0, AV_OPT_TYPE_CONST, 
> {.i64=MODE_WIRES},INT_MIN, INT_MAX, FLAGS, "mode" },
>  { "colormix", "mix colors", 0, AV_OPT_TYPE_CONST, 
> {.i64=MODE_COLORMIX}, INT_MIN, INT_MAX, FLAGS, "mode" },
>  { "canny","detect edges on planes", 0, AV_OPT_TYPE_CONST, 
> {.i64=MODE_CANNY},INT_MIN, INT_MAX, FLAGS, "mode" },
> +{ "planes", "set planes to filter",  OFFSET(filter_planes), 
> AV_OPT_TYPE_FLAGS, {.i64=7}, 1, 0x7, FLAGS, "flags" },

> +{  "y", "filter luma plane",  0, AV_OPT_TYPE_CONST, {.i64=PLANE_Y}, 
> 0, 0, FLAGS, "flags"},
> +{  "u", "filter u plane", 0, AV_OPT_TYPE_CONST, {.i64=PLANE_U}, 
> 0, 0, FLAGS, "flags"},
> +{  "v", "filter v plane", 0, AV_OPT_TYPE_CONST, {.i64=PLANE_V}, 
> 0, 0, FLAGS, "flags"},
> +{  "r", "filter red plane",   0, AV_OPT_TYPE_CONST, {.i64=PLANE_R}, 
> 0, 0, FLAGS, "flags"},
> +{  "g", "filter green plane", 0, AV_OPT_TYPE_CONST, {.i64=PLANE_G}, 
> 0, 0, FLAGS, "flags"},
> +{  "b", "filter blue plane",  0, AV_OPT_TYPE_CONST, {.i64=PLANE_B}, 
> 0, 0, FLAGS, "flags"},

please keep the style consistent with above (also beware of the trailing
space before "}")

>  { NULL }
>  };
>  
> @@ -322,6 +339,14 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
> *in)
>  uint16_t *gradients  = plane->gradients;
>  int8_t   *directions = plane->directions;
>  
> +if (!((1 << p) & edgedetect->filter_planes)) {
> +if (!direct)
> +av_image_copy_plane(out->data[p], out->linesize[p],
> +in->data[p], in->linesize[p],
> +inlink->w, inlink->h);
> +continue;
> +}
> +

Should be fine. Though, I'd say the green (0) is unexpected for chroma
planes; I'd expect gray (128) instead. Not blocking but could be changed
in the future.

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH 1/3] avfilter/vf_edgedetect: add canny mode

[Clément Bœsch]

On Thu, May 03, 2018 at 03:44:42PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi| 3 +++
>  libavfilter/vf_edgedetect.c | 5 +
>  2 files changed, 8 insertions(+)
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 218f30ef5f..29b5a5b15f 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -8268,6 +8268,9 @@ Draw white/gray wires on black background.
>  
>  @item colormix
>  Mix the colors to create a paint/cartoon effect.
> +
> +@item canny
> +Apply Canny edge detector on all selected planes.
>  @end table
>  
>  Default value is @var{wires}.
> diff --git a/libavfilter/vf_edgedetect.c b/libavfilter/vf_edgedetect.c
> index 173f9fe161..534a302d90 100644
> --- a/libavfilter/vf_edgedetect.c
> +++ b/libavfilter/vf_edgedetect.c
> @@ -35,6 +35,7 @@
>  enum FilterMode {
>  MODE_WIRES,
>  MODE_COLORMIX,
> +MODE_CANNY,
>  NB_MODE
>  };
>  
> @@ -61,6 +62,7 @@ static const AVOption edgedetect_options[] = {
>  { "mode", "set mode", OFFSET(mode), AV_OPT_TYPE_INT, {.i64=MODE_WIRES}, 
> 0, NB_MODE-1, FLAGS, "mode" },
>  { "wires","white/gray wires on black",  0, AV_OPT_TYPE_CONST, 
> {.i64=MODE_WIRES},INT_MIN, INT_MAX, FLAGS, "mode" },
>  { "colormix", "mix colors", 0, AV_OPT_TYPE_CONST, 
> {.i64=MODE_COLORMIX}, INT_MIN, INT_MAX, FLAGS, "mode" },
> +{ "canny","detect edges on planes", 0, AV_OPT_TYPE_CONST, 
> {.i64=MODE_CANNY},INT_MIN, INT_MAX, FLAGS, "mode" },
>  { NULL }
>  };
>  
> @@ -79,6 +81,7 @@ static int query_formats(AVFilterContext *ctx)
>  {
>  const EdgeDetectContext *edgedetect = ctx->priv;
>  static const enum AVPixelFormat wires_pix_fmts[] = {AV_PIX_FMT_GRAY8, 
> AV_PIX_FMT_NONE};
> +static const enum AVPixelFormat canny_pix_fmts[] = {AV_PIX_FMT_YUV444P, 
> AV_PIX_FMT_GBRP, AV_PIX_FMT_GRAY8, AV_PIX_FMT_NONE};
>  static const enum AVPixelFormat colormix_pix_fmts[] = {AV_PIX_FMT_GBRP, 
> AV_PIX_FMT_GRAY8, AV_PIX_FMT_NONE};
>  AVFilterFormats *fmts_list;
>  const enum AVPixelFormat *pix_fmts = NULL;
> @@ -87,6 +90,8 @@ static int query_formats(AVFilterContext *ctx)
>  pix_fmts = wires_pix_fmts;
>  } else if (edgedetect->mode == MODE_COLORMIX) {
>  pix_fmts = colormix_pix_fmts;
> +} else if (edgedetect->mode == MODE_CANNY) {
> +pix_fmts = canny_pix_fmts;
>  } else {
>  av_assert0(0);
>  }

Sure, why not

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_lut3d: add planar rgb support

[Clément Bœsch]

On Thu, May 03, 2018 at 08:08:03PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/vf_lut3d.c | 114 
> +++--
>  1 file changed, 111 insertions(+), 3 deletions(-)
> 
> diff --git a/libavfilter/vf_lut3d.c b/libavfilter/vf_lut3d.c
> index c9b72249aa..2f8fc723b7 100644
> --- a/libavfilter/vf_lut3d.c
> +++ b/libavfilter/vf_lut3d.c
> @@ -198,6 +198,83 @@ static inline struct rgbvec interp_tetrahedral(const 
> LUT3DContext *lut3d,
>  return c;
>  }
>  

> +#define DEFINE_INTERP_FUNC_PLANAR(name, nbits, depth)
>\
> +static int interp_##nbits##_##name##_p##depth(AVFilterContext *ctx, void 
> *arg, int jobnr, int nb_jobs) \

align style

[...]
>  #define SET_FUNC(name) do { \
> -if (is16bit) lut3d->interp = interp_16_##name;  \
> -else lut3d->interp = interp_8_##name;   \
> +if (planar) {   \
> +switch (depth) {\
> +case  8: lut3d->interp = interp_8_##name##_p8;   break; \
> +case  9: lut3d->interp = interp_16_##name##_p9;  break; \
> +case 10: lut3d->interp = interp_16_##name##_p10; break; \
> +case 12: lut3d->interp = interp_16_##name##_p12; break; \
> +case 14: lut3d->interp = interp_16_##name##_p14; break; \
> +case 16: lut3d->interp = interp_16_##name##_p16; break; \
> +}   \

> +} else if (is16bit) { lut3d->interp = interp_16_##name; \
> +} else {   lut3d->interp = interp_8_##name; }   \

align style

[...]

aside from these details, LGTM, thanks

feel free to adjust the av_clip in DEFINE_INTERP_FUNC in another commit if
it works

-- 
Clément B.


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

[FFmpeg-devel] [PATCH 1/4] avcodec/g2meet: Change order of operations to avoid undefined behavior

[Michael Niedermayer]

Fixes: signed integer overflow: 65280 * 196032 cannot be represented in type 
'int'
Fixes: 
7279/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G2M_fuzzer-5977332473921536

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/g2meet.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavcodec/g2meet.c b/libavcodec/g2meet.c
index b409dae813..5edfb31560 100644
--- a/libavcodec/g2meet.c
+++ b/libavcodec/g2meet.c
@@ -1356,14 +1356,16 @@ static void g2m_paint_cursor(G2MContext *c, uint8_t 
*dst, int stride)
 } else {
 dst+=  x * 3;
 }
-if (y < 0) {
+
+if (y < 0)
 h  +=  y;
+if (w < 0 || h < 0)
+return;
+if (y < 0) {
 cursor += -y * c->cursor_stride;
 } else {
 dst+=  y * stride;
 }
-if (w < 0 || h < 0)
-return;
 
 for (j = 0; j < h; j++) {
 for (i = 0; i < w; i++) {
-- 
2.17.0

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

[FFmpeg-devel] [PATCH 2/4] avcodec/jpeg2000dec: Reduce the number of tile parts allocated

[Michael Niedermayer]

This is large enough for all jpeg2000 files i tested. If some need more then 
this
should be changed to dynamic allocation. Dynamic allocation would need to be 
done
carefully as these are many relatively small arrays so repeatly reallocating 
them
would not be good.
The decrease is a clean and simple solution assuming it works for all files.

Fixes: OOM
Fixes: 
6534/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-4821490731057152

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/jpeg2000dec.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 5414ce5655..6aa63a9771 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -82,7 +82,7 @@ typedef struct Jpeg2000Tile {
 Jpeg2000CodingStyle codsty[4];
 Jpeg2000QuantStyle  qntsty[4];
 Jpeg2000POC poc;
-Jpeg2000TileParttile_part[256];
+Jpeg2000TileParttile_part[32];
 uint16_t tp_idx;// Tile-part index
 int coord[2][2];// border coordinates {{x0, x1}, {y0, 
y1}}
 } Jpeg2000Tile;
@@ -761,7 +761,10 @@ static int get_sot(Jpeg2000DecoderContext *s, int n)
 return AVERROR_INVALIDDATA;
 }
 
-av_assert0(TPsot < FF_ARRAY_ELEMS(s->tile[Isot].tile_part));
+if (TPsot >= FF_ARRAY_ELEMS(s->tile[Isot].tile_part)) {
+avpriv_request_sample(s->avctx, "Too many tile parts");
+return AVERROR_PATCHWELCOME;
+}
 
 s->tile[Isot].tp_idx = TPsot;
 tp = s->tile[Isot].tile_part + TPsot;
-- 
2.17.0

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

[FFmpeg-devel] [PATCH 3/4] avcodec/jpeg2000dec: Skip init for component in CPRL if nothing is to be done

[Michael Niedermayer]

Fixes: assertion failure
Fixes: 
7949/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-4819602782552064

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/jpeg2000dec.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 6aa63a9771..5aa0713ed6 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -1159,6 +1159,9 @@ static int 
jpeg2000_decode_packets_po_iteration(Jpeg2000DecoderContext *s, Jpeg2
 step_x = 32;
 step_y = 32;
 
+if (RSpoc > FFMIN(codsty->nreslevels, REpoc))
+continue;
+
 for (reslevelno = RSpoc; reslevelno < FFMIN(codsty->nreslevels, 
REpoc); reslevelno++) {
 uint8_t reducedresno = codsty->nreslevels - 1 -reslevelno; //  
==> N_L - r
 Jpeg2000ResLevel *rlevel = comp->reslevel + reslevelno;
-- 
2.17.0

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

[FFmpeg-devel] [PATCH 4/4] avcodec/jpeg2000dec: Fix undefined shift in the jpeg2000_decode_packets_po_iteration() CPRL case

[Michael Niedermayer]

Fixes: shift exponent 47 is too large for 32-bit type 'int'
Fixes: 
7955/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-6016721977606144

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/jpeg2000dec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 5aa0713ed6..12dcc5c6f5 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -1181,10 +1181,10 @@ static int 
jpeg2000_decode_packets_po_iteration(Jpeg2000DecoderContext *s, Jpeg2
 int xc = x / s->cdx[compno];
 int yc = y / s->cdy[compno];
 
-if (yc % (1 << (rlevel->log2_prec_height + 
reducedresno)) && y != tile->coord[1][0]) //FIXME this is a subset of the check
+if (yc % (1LL << (rlevel->log2_prec_height + 
reducedresno)) && y != tile->coord[1][0]) //FIXME this is a subset of the check
 continue;
 
-if (xc % (1 << (rlevel->log2_prec_width + 
reducedresno)) && x != tile->coord[0][0]) //FIXME this is a subset of the check
+if (xc % (1LL << (rlevel->log2_prec_width + 
reducedresno)) && x != tile->coord[0][0]) //FIXME this is a subset of the check
 continue;
 
 // check if a precinct exists
-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH] avformat: add vapoursynth wrapper

[James Almer]

On 5/4/2018 1:51 PM, wm4 wrote:
> On Fri, 4 May 2018 13:30:38 -0300
> James Almer  wrote:
> 
>> On 5/4/2018 12:58 PM, wm4 wrote:
>>> On Sat, 28 Apr 2018 19:05:29 +0200
>>> wm4  wrote:
>>>   
 This can "demux" .vpy files.

 Some minor code copied from other LGPL parts of FFmpeg.

 I did not found a good way to test a few of the more obscure features,
 like VFR nodes, compat pixel formats, or nodes with dynamic size/format
 changes. These can be easily implemented on demand.
 ---
  configure |   5 +
  libavformat/Makefile  |   1 +
  libavformat/allformats.c  |   1 +
  libavformat/vapoursynth.c | 421 
 ++
  4 files changed, 428 insertions(+)
  create mode 100644 libavformat/vapoursynth.c
  
>>>
>>> Pushed, with some minor changes, and zero-copy frame passing.  
>>
>> The first step to fix something (in this case, usage sizeof(AVFrame)
>> outside libavutil) is not adding even more cases of the issue in question.
>> You still can replace this with rawvideo. Someone even already wrote it
>> for you.
>>
>> Lets try to abide our own ABI rules...
> 
> That's requires a frame copy and is not what I went through all the
> effort for.
> 
> Why didn't you say anything when the kmsgrab code did the same thing?
> Or when the unwrapped frame stuff was added in the first place?

I did the other day on IRC when you asked me why i was against this, if
you recall, because it was then when i found out this has been the case
for a long while, and why I'm now saying adding even more cases is going
in the opposite direction of an actual solution.

In any case, i explicitly didn't block this, and no one else seems to
care, so whatever.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat: add vapoursynth wrapper

[wm4]

On Fri, 4 May 2018 13:30:38 -0300
James Almer  wrote:

> On 5/4/2018 12:58 PM, wm4 wrote:
> > On Sat, 28 Apr 2018 19:05:29 +0200
> > wm4  wrote:
> >   
> >> This can "demux" .vpy files.
> >>
> >> Some minor code copied from other LGPL parts of FFmpeg.
> >>
> >> I did not found a good way to test a few of the more obscure features,
> >> like VFR nodes, compat pixel formats, or nodes with dynamic size/format
> >> changes. These can be easily implemented on demand.
> >> ---
> >>  configure |   5 +
> >>  libavformat/Makefile  |   1 +
> >>  libavformat/allformats.c  |   1 +
> >>  libavformat/vapoursynth.c | 421 
> >> ++
> >>  4 files changed, 428 insertions(+)
> >>  create mode 100644 libavformat/vapoursynth.c
> >>  
> > 
> > Pushed, with some minor changes, and zero-copy frame passing.  
> 
> The first step to fix something (in this case, usage sizeof(AVFrame)
> outside libavutil) is not adding even more cases of the issue in question.
> You still can replace this with rawvideo. Someone even already wrote it
> for you.
> 
> Lets try to abide our own ABI rules...

That's requires a frame copy and is not what I went through all the
effort for.

Why didn't you say anything when the kmsgrab code did the same thing?
Or when the unwrapped frame stuff was added in the first place?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat: add vapoursynth wrapper

[James Almer]

On 5/4/2018 12:58 PM, wm4 wrote:
> On Sat, 28 Apr 2018 19:05:29 +0200
> wm4  wrote:
> 
>> This can "demux" .vpy files.
>>
>> Some minor code copied from other LGPL parts of FFmpeg.
>>
>> I did not found a good way to test a few of the more obscure features,
>> like VFR nodes, compat pixel formats, or nodes with dynamic size/format
>> changes. These can be easily implemented on demand.
>> ---
>>  configure |   5 +
>>  libavformat/Makefile  |   1 +
>>  libavformat/allformats.c  |   1 +
>>  libavformat/vapoursynth.c | 421 
>> ++
>>  4 files changed, 428 insertions(+)
>>  create mode 100644 libavformat/vapoursynth.c
>>
> 
> Pushed, with some minor changes, and zero-copy frame passing.

The first step to fix something (in this case, usage sizeof(AVFrame)
outside libavutil) is not adding even more cases of the issue in question.
You still can replace this with rawvideo. Someone even already wrote it
for you.

Lets try to abide our own ABI rules...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat: add vapoursynth wrapper

[Gyan Doshi]

On 5/4/2018 9:28 PM, wm4 wrote:


---
  configure |   5 +
  libavformat/Makefile  |   1 +
  libavformat/allformats.c  |   1 +
  libavformat/vapoursynth.c | 421 ++
  4 files changed, 428 insertions(+)
  create mode 100644 libavformat/vapoursynth.c


Doesn't this merit a changelog entry, and if needed, docs?

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

Re: [FFmpeg-devel] [PATCH] avformat: add vapoursynth wrapper

[wm4]

On Sat, 28 Apr 2018 19:05:29 +0200
wm4  wrote:

> This can "demux" .vpy files.
> 
> Some minor code copied from other LGPL parts of FFmpeg.
> 
> I did not found a good way to test a few of the more obscure features,
> like VFR nodes, compat pixel formats, or nodes with dynamic size/format
> changes. These can be easily implemented on demand.
> ---
>  configure |   5 +
>  libavformat/Makefile  |   1 +
>  libavformat/allformats.c  |   1 +
>  libavformat/vapoursynth.c | 421 
> ++
>  4 files changed, 428 insertions(+)
>  create mode 100644 libavformat/vapoursynth.c
> 

Pushed, with some minor changes, and zero-copy frame passing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 2/4] avcodec/mediacodecdec: restructure mediacodec_receive_frame

[Matthieu Bouron]

On Thu, May 03, 2018 at 10:24:49AM -0700, Aman Gupta wrote:
> On Thu, May 3, 2018 at 12:33 AM, Matthieu Bouron 
> wrote:
> 
> > On Wed, May 02, 2018 at 07:24:58PM -0700, Aman Gupta wrote:
> > > From: Aman Gupta 
> > >
> > > The new logic follows a recommendation by @rcombs to use
> > > dequeueInputBuffer with a timeout of 0 as a way to detect
> > > whether the codec wants more data. The dequeued buffer index is
> > > kept in MediaCodecDecContext until it can be used next.
> > >
> > > A similar technique is also used by the Google's official media
> > > player Exoplayer: see MediaCodecRenderer.feedInputBuffer().
> > >
> > > Signed-off-by: Aman Gupta 
> > > ---
> > >  libavcodec/mediacodecdec.c| 80 --
> > -
> > >  libavcodec/mediacodecdec_common.c | 28 --
> > >  libavcodec/mediacodecdec_common.h |  4 +-
> > >  3 files changed, 61 insertions(+), 51 deletions(-)
> > >
> > > diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> > > index 86ceee5a83..2ac22dd1f6 100644
> > > --- a/libavcodec/mediacodecdec.c
> > > +++ b/libavcodec/mediacodecdec.c
> > > @@ -391,33 +391,11 @@ done:
> > >  return ret;
> > >  }
> > >
> > > -static int mediacodec_send_receive(AVCodecContext *avctx,
> > > -   MediaCodecH264DecContext *s,
> > > -   AVFrame *frame, bool wait)
> > > -{
> > > -int ret;
> > > -
> > > -/* send any pending data from buffered packet */
> > > -while (s->buffered_pkt.size) {
> > > -ret = ff_mediacodec_dec_send(avctx, s->ctx, >buffered_pkt);
> > > -if (ret == AVERROR(EAGAIN))
> > > -break;
> > > -else if (ret < 0)
> > > -return ret;
> > > -s->buffered_pkt.size -= ret;
> > > -s->buffered_pkt.data += ret;
> > > -if (s->buffered_pkt.size <= 0)
> > > -av_packet_unref(>buffered_pkt);
> > > -}
> > > -
> > > -/* check for new frame */
> > > -return ff_mediacodec_dec_receive(avctx, s->ctx, frame, wait);
> > > -}
> > > -
> > >  static int mediacodec_receive_frame(AVCodecContext *avctx, AVFrame
> > *frame)
> > >  {
> > >  MediaCodecH264DecContext *s = avctx->priv_data;
> > >  int ret;
> > > +ssize_t index;
> > >
> > >  /* In delay_flush mode, wait until the user has released or rendered
> > > all retained frames. */
> > > @@ -427,28 +405,54 @@ static int mediacodec_receive_frame(AVCodecContext
> > *avctx, AVFrame *frame)
> > >  }
> > >  }
> > >
> > > -/* flush buffered packet and check for new frame */
> > > -ret = mediacodec_send_receive(avctx, s, frame, false);
> > > +/* poll for new frame */
> > > +ret = ff_mediacodec_dec_receive(avctx, s->ctx, frame, false);
> > >  if (ret != AVERROR(EAGAIN))
> > >  return ret;
> > >
> > > -/* skip fetching new packet if we still have one buffered */
> > > -if (s->buffered_pkt.size > 0)
> > > -return mediacodec_send_receive(avctx, s, frame, true);
> > > +/* feed decoder */
> > > +while (1) {
> > > +if (s->ctx->current_input_buffer < 0) {
> > > +/* poll for input space */
> > > +index = ff_AMediaCodec_dequeueInputBuffer(s->ctx->codec,
> > 0);
> > > +if (index < 0) {
> > > +/* no space, block for an output frame to appear */
> > > +return ff_mediacodec_dec_receive(avctx, s->ctx, frame,
> > true);
> > > +}
> > > +s->ctx->current_input_buffer = index;
> > > +}
> > >
> > > -/* fetch new packet or eof */
> > > -ret = ff_decode_get_packet(avctx, >buffered_pkt);
> > > -if (ret == AVERROR_EOF) {
> > > -AVPacket null_pkt = { 0 };
> > > -ret = ff_mediacodec_dec_send(avctx, s->ctx, _pkt);
> > > -if (ret < 0)
> > > +/* try to flush any buffered packet data */
> > > +if (s->buffered_pkt.size > 0) {
> > > +ret = ff_mediacodec_dec_send(avctx, s->ctx,
> > >buffered_pkt, false);
> > > +if (ret >= 0) {
> > > +s->buffered_pkt.size -= ret;
> > > +s->buffered_pkt.data += ret;
> > > +if (s->buffered_pkt.size <= 0)
> > > +av_packet_unref(>buffered_pkt);
> > > +} else if (ret < 0 && ret != AVERROR(EAGAIN)) {
> > > +return ret;
> > > +}
> > > +
> > > +/* poll for space again */
> > > +continue;
> > > +}
> > > +
> > > +/* fetch new packet or eof */
> > > +ret = ff_decode_get_packet(avctx, >buffered_pkt);
> > > +if (ret == AVERROR_EOF) {
> > > +AVPacket null_pkt = { 0 };
> > > +ret = ff_mediacodec_dec_send(avctx, s->ctx, _pkt,
> > true);
> > > +if (ret < 0)
> > > +return ret;
> > > +} else if (ret == AVERROR(EAGAIN) &&
> > 

[FFmpeg-devel] [PATCH 3/3] vaapi_encode_vp8: memset the the structure to 0

[Haihao Xiang]

The structure has reserved bytes, it is required to set the reserved
bytes to 0 for future use.

Signed-off-by: Haihao Xiang 
---
 libavcodec/vaapi_encode_vp8.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/vaapi_encode_vp8.c b/libavcodec/vaapi_encode_vp8.c
index b4c5521d1f..a2e861a8d1 100644
--- a/libavcodec/vaapi_encode_vp8.c
+++ b/libavcodec/vaapi_encode_vp8.c
@@ -143,6 +143,8 @@ static int 
vaapi_encode_vp8_write_quant_table(AVCodecContext *avctx,
 *type = VAQMatrixBufferType;
 *data_len = sizeof(quant);
 
+memset(, 0, sizeof(quant));
+
 if (pic->type == PICTURE_TYPE_P)
 q = priv->q_index_p;
 else
-- 
2.17.0

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

[FFmpeg-devel] [PATCH 2/3] hwcontext_vaapi: Return error if can not find a VA RT format

[Haihao Xiang]

Otherwise va_rt_format might be unitialized

Signed-off-by: Haihao Xiang 
---
 libavutil/hwcontext_vaapi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 7daaa951cc..e59042487d 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -1028,6 +1028,11 @@ static int vaapi_map_from_drm(AVHWFramesContext *src_fc, 
AVFrame *dst,
 va_rt_format = vaapi_format_map[i].rt_format;
 }
 
+if (i >= FF_ARRAY_ELEMS(vaapi_format_map)) {
+av_log(dst_fc, AV_LOG_ERROR, "No matching VA RT format \n");
+return AVERROR(EINVAL);
+}
+
 buffer_handle = desc->objects[0].fd;
 buffer_desc.pixel_format = va_fourcc;
 buffer_desc.width= src_fc->width;
-- 
2.17.0

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

[FFmpeg-devel] [PATCH 1/3] vaapi_encode: Initialize the pointer

[Haihao Xiang]

Otherwise it might use unitialized last_pic in av_assert0(last_pic)

Signed-off-by: Haihao Xiang 
---
 libavcodec/vaapi_encode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 36c85a3815..141e50c8ad 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -760,7 +760,7 @@ fail:
 static int vaapi_encode_truncate_gop(AVCodecContext *avctx)
 {
 VAAPIEncodeContext *ctx = avctx->priv_data;
-VAAPIEncodePicture *pic, *last_pic, *next;
+VAAPIEncodePicture *pic, *last_pic = NULL, *next;
 
 // Find the last picture we actually have input for.
 for (pic = ctx->pic_start; pic; pic = pic->next) {
-- 
2.17.0

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

Re: [FFmpeg-devel] [GSOC] [PATCH] SRCNN filter

[Pedro Arthur]

2018-05-03 17:58 GMT-03:00 Michael Niedermayer :
> On Thu, May 03, 2018 at 03:17:11PM -0300, Pedro Arthur wrote:
>> 2018-04-10 14:16 GMT-03:00 Sergey Lavrushkin :
>> > 2018-03-29 3:55 GMT+03:00 Michael Niedermayer :
>> >
>> >> On Wed, Mar 28, 2018 at 11:17:40AM +0300, Sergey Lavrushkin wrote:
>> >> > > [...]
>> >> > > > +#define OFFSET(x) offsetof(SRCNNContext, x)
>> >> > > > +#define FLAGS AV_OPT_FLAG_FILTERING_PARAM | AV_OPT_FLAG_VIDEO_PARAM
>> >> > > > +static const AVOption srcnn_options[] = {
>> >> > > > +{ "config_file", "path to configuration file with network
>> >> > > parameters", OFFSET(config_file_path), AV_OPT_TYPE_STRING,
>> >> {.str=NULL}, 0,
>> >> > > 0, FLAGS },
>> >> > > > +{ NULL }
>> >> > > > +};
>> >> > > > +
>> >> > > > +AVFILTER_DEFINE_CLASS(srcnn);
>> >> > > > +
>> >> > > > +#define CHECK_FILE(file)if (ferror(file) || feof(file)){ \
>> >> > > > +av_log(context, AV_LOG_ERROR, 
>> >> > > > "error
>> >> > > reading configuration file\n");\
>> >> > > > +fclose(file); \
>> >> > > > +return AVERROR(EIO); \
>> >> > > > +}
>> >> > > > +
>> >> > > > +#define CHECK_ALLOCATION(conv, file)if
>> >> > > (allocate_and_read_convolution_data(, file)){ \
>> >> > > > +av_log(context,
>> >> > > AV_LOG_ERROR, "could not allocate memory for convolutions\n"); \
>> >> > > > +fclose(file); \
>> >> > > > +return AVERROR(ENOMEM);
>> >> \
>> >> > > > +}
>> >> > > > +
>> >> > >
>> >> > > > +static int allocate_and_read_convolution_data(Convolution* conv,
>> >> FILE*
>> >> > > config_file)
>> >> > > > +{
>> >> > > > +int32_t kernel_size = conv->output_channels * conv->size *
>> >> > > conv->size * conv->input_channels;
>> >> > > > +conv->kernel = av_malloc(kernel_size * sizeof(double));
>> >> > > > +if (!conv->kernel){
>> >> > > > +return 1;
>> >> > >
>> >> > > this should return an AVERROR code for consistency with the rest of
>> >> > > the codebase
>> >> > >
>> >> >
>> >> > Ok.
>> >> >
>> >> >
>> >> > > > +}
>> >> > >
>> >> > > > +fread(conv->kernel, sizeof(double), kernel_size, config_file);
>> >> > >
>> >> > > directly reading data types is not portable, it would for example be
>> >> > > endian specific
>> >> > > and using avio for reading may be better, though fread is as far as 
>> >> > > iam
>> >> > > concerned also ok
>> >> > >
>> >> >
>> >> > Ok, I understand the problem, but I have not really worked with it
>> >> before,
>> >> > so I need an advice of how to properly fix it. If I understand 
>> >> > correctly,
>> >> > for
>> >>
>> >> > int32_t I need to check endianness and reverse bytes if necessary. But
>> >> with
>> >>
>> >> see avio_rb32()
>> >> might not be as fast as reading a whole array and byteswaping though.
>> >> Not sure it matters
>> >>
>> >>
>> >> > doubles it is more complicated. Should I write a IEEE 754 converter from
>> >> > binary
>> >> > to double or maybe I can somehow check IEEE 754 doubles support and
>> >> > depending
>> >> > on it either stick to the default network weights, or just read bytes 
>> >> > and
>> >> > check
>> >> > endianness, if IEEE 754 doubles are supported? Or maybe avio provide 
>> >> > some
>> >> > utility to deal with this problem?
>> >>
>> >> something like this should work:
>> >> av_int2float(avio_rb32(pb));
>> >> av_int2double(avio_rb64(pb));
>> >>
>> >> >
>> >> >
>> >> > > [...]
>> >> > > > +/**
>> >> > > > + * @file
>> >> > > > + * Default cnn weights for x2 upsampling with srcnn filter.
>> >> > > > + */
>> >> > > > +
>> >> > > > +/// First convolution kernel
>> >> > >
>> >> > > > +static double conv1_kernel[] = {
>> >> > >
>> >> > > static data should be also const, otherwise it may be changed and 
>> >> > > could
>> >> > > cause
>> >> > > thread saftey issues
>> >> > >
>> >> >
>> >> > Ok, I just wanted to not allocate additional memory in case of using
>> >> > default weights.
>> >>
>> >> well, there can be more than one instance of a filter running at the same
>> >> time
>> >> so static variables that are actually changing will affect the other
>> >> filter instance
>> >>
>> >
>> > Hi,
>> >
>> > Here is the updated patch with fixed issues.
>> > Sorry for the late reply, I was busy doing things related to my university
>> > activities.
>> >
>> > ___
>> > ffmpeg-devel mailing list
>> > ffmpeg-devel@ffmpeg.org
>> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> >
>>
>> I think all concerns were addressed, can the patch be pushed?
>
> sure you can push it if it looks ok to you.
> please make sure fate-source passes (i think it fails with the patch)
Fixed and pushed.

>
> thanks
>
> [...]
> --
> Michael 

Re: [FFmpeg-devel] [PATCH] flvenc: Fix sequence header update timestamps

[Josh de Kock]

> On 4 May 2018, at 12:26, Michael Niedermayer  wrote:
> 
>> On Fri, May 04, 2018 at 11:03:20AM +0800, Steven Liu wrote:
>> 
>> 
>>> On 4 May 2018, at 02:00, Jan Ekström  wrote:
>>> 
>>> On Thu, May 3, 2018 at 8:58 PM, Jan Ekström  wrote:
 On Thu, May 3, 2018 at 7:50 PM, Alex Converse  
 wrote:
> [...]
> 
>> Will apply.
> 
> I think Alex Converse has a git write account, so he can push himself if you
> prefer
> 
> thx
> 
> [...]
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> In a rich man's house there is no place to spit but his face.
> -- Diogenes of Sinope

Hold off on pushing this for a day or two, I think Jan had some extra comments 
(he said he was unable to reply until later as he is busy right now).

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

Re: [FFmpeg-devel] [PATCH 4/4] vaapi_encode_h265: Insert content light level information

[Xiang, Haihao]

>-Original Message-
>From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>Mark Thompson
>Sent: Friday, May 4, 2018 5:49 AM
>To: ffmpeg-devel@ffmpeg.org
>Subject: Re: [FFmpeg-devel] [PATCH 4/4] vaapi_encode_h265: Insert content
>light level information
>
>On 03/05/18 04:07, Haihao Xiang wrote:
>> Signed-off-by: Haihao Xiang 
>> ---
>>  libavcodec/vaapi_encode_h265.c | 29 -
>>  1 file changed, 28 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/vaapi_encode_h265.c
>> b/libavcodec/vaapi_encode_h265.c index 326fe4fe66..5fe487dfc5 100644
>> --- a/libavcodec/vaapi_encode_h265.c
>> +++ b/libavcodec/vaapi_encode_h265.c
>> @@ -37,6 +37,7 @@
>>
>>  enum {
>>  SEI_MASTERING_DISPLAY   = 0x08,
>> +SEI_CONTENT_LIGHT_LEVLE = 0x10,
>>  };
>>
>>  typedef struct VAAPIEncodeH265Context { @@ -55,6 +56,7 @@ typedef
>> struct VAAPIEncodeH265Context {
>>  H265RawSEI sei;
>>
>>  H265RawSEIMasteringDiplayColourVolume mastering_display;
>> +H265RawSEIContentLightLevelInfo content_light_level;
>>
>>  int64_t last_idr_frame;
>>  int pic_order_cnt;
>> @@ -218,6 +220,12 @@ static int
>vaapi_encode_h265_write_extra_header(AVCodecContext *avctx,
>>  ++i;
>>  }
>>
>> +if (priv->sei_needed & SEI_CONTENT_LIGHT_LEVLE) {
>> +priv->sei.payload[i].payload_type =
>HEVC_SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO;
>> +priv->sei.payload[i].payload.content_light_level = priv-
>>content_light_level;
>> +++i;
>> +}
>> +
>>  priv->sei.payload_count = i;
>>  av_assert0(priv->sei.payload_count > 0);
>>
>> @@ -702,6 +710,22 @@ static int
>vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
>>  }
>>  }
>>
>> +if (opt->sei & SEI_CONTENT_LIGHT_LEVLE) {
>> +AVFrameSideData *sd =
>> +av_frame_get_side_data(pic->input_image,
>> +
>> + AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
>
>Same question about when this side data is set as for mastering display.
>

The persistence scope for content light level is also CLVS, my understanding is 
to set this side-data per I/IDR frame 

>> +
>> +if (sd) {
>> +AVContentLightMetadata *clm =
>> +(AVContentLightMetadata *)sd->data;
>> +
>> +priv->content_light_level.max_content_light_level = clm->MaxCLL;
>> +priv->content_light_level.max_pic_average_light_level =
>> + clm->MaxFALL;
>
>Possibly needs to be clipped to 16 bits?


Yes, I will change it.

>
>> +
>> +priv->sei_needed |= SEI_CONTENT_LIGHT_LEVLE;
>> +}
>> +}
>> +
>>  vpic->decoded_curr_pic = (VAPictureHEVC) {
>>  .picture_id= pic->recon_surface,
>>  .pic_order_cnt = priv->pic_order_cnt, @@ -1123,11 +1147,14 @@
>> static const AVOption vaapi_encode_h265_options[] = {
>>
>>  { "sei", "Set SEI to include",
>>OFFSET(sei), AV_OPT_TYPE_FLAGS,
>> -  { .i64 = SEI_MASTERING_DISPLAY },
>> +  { .i64 = SEI_MASTERING_DISPLAY | SEI_CONTENT_LIGHT_LEVLE },
>>0, INT_MAX, FLAGS, "sei" },
>>  { "mastering_display", "Include mastering display colour volume",
>>0, AV_OPT_TYPE_CONST, { .i64 = SEI_MASTERING_DISPLAY },
>>INT_MIN, INT_MAX, FLAGS, "sei" },
>> +{ "content_light_level", "Include content light level information",
>> +  0, AV_OPT_TYPE_CONST, { .i64 = SEI_CONTENT_LIGHT_LEVLE },
>> +  INT_MIN, INT_MAX, FLAGS, "sei" },
>
>If you still like the idea of an "hdr" option (so that '-sei hdr' works), you 
>can
>make it have the value SEI_MASTERING_DISPLAY|SEI_CONTENT_LIGHT_LEVEL.
>

Sure, I will change it to '-sei hdr'.

>>
>>  { NULL },
>>  };
>>
>___
>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]lavf/isom: Recognize fourcc HEVC

[wm4]

On Fri, 4 May 2018 08:56:18 -0400
Compn  wrote:

> On Fri, 4 May 2018 14:36:03 +0200, wm4  wrote:
> 
> > FourCC are already split up for avi and mov. Apparently it got
> > sabotaged at some point.  
> 
> i think mkv re-uses riff list from avi on purpose, as it was meant as a
> replacement to avi (and has all the vfw codec tags in the spec).
> duplicating mkv and avi seems like a bad idea as they use the same tags.
> 
> https://www.matroska.org/technical/guides/faq/index.html

mkv has a VfW muxing mode, in which it uses AVI headers and FourCCs in
the codec data. They're completely separate from normal Matroska codec
IDs, which are strings.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hls: don't propagate deprecated "user-agent" AVOption

[wm4]

On Sun, 29 Apr 2018 14:23:17 +0200
Clément Bœsch  wrote:

> On Sat, Apr 28, 2018 at 08:37:06PM +0200, wm4 wrote:
> > This code will print a warning if any user agent is set - even if the
> > API user used the proper non-deprecated "user_agent" option.
> > 
> > This change should not even break anything, because even if the user
> > sets the deprecated "user-agent" option, http.c copies it to the
> > "user_agent" option anyway.
> > ---
> >  libavformat/hls.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > index ffec124818..4ee4be769d 100644
> > --- a/libavformat/hls.c
> > +++ b/libavformat/hls.c
> > @@ -1593,7 +1593,7 @@ static int save_avio_options(AVFormatContext *s)
> >  {
> >  HLSContext *c = s->priv_data;
> >  static const char * const opts[] = {
> > -"headers", "http_proxy", "user_agent", "user-agent", "cookies", 
> > "referer", "rw_timeout", NULL };
> > +"headers", "http_proxy", "user_agent", "cookies", "referer", 
> > "rw_timeout", NULL };
> >  const char * const * opt = opts;
> >  uint8_t *buf;
> >  int ret = 0;  
> 
> Should be fine, thanks.
> 

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

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: do not write timebase as framerate

[wm4]

On Sat, 28 Apr 2018 19:24:21 +0200
wm4  wrote:

> If the API user doesn't set avg_frame_rate, matroskaenc will write the
> current timebase as "default duration" for the video track. This makes
> no sense, because the "default duration" implies the framerate of the
> video. Since the timebase is forced to 1/1000, this will make the
> resulting file claim 1000fps.
> 
> Drop it and don't write the element. It's optional, so it's better not
> to write it if the framerate is unknown.
> 
> Strangely does not require FATE changes.
> ---
>  libavformat/matroskaenc.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index 5950b4de44..b7ff1950d3 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -1304,8 +1304,6 @@ static int mkv_write_track(AVFormatContext *s, 
> MatroskaMuxContext *mkv,
>  if(   st->avg_frame_rate.num > 0 && st->avg_frame_rate.den > 0
> && av_cmp_q(av_inv_q(st->avg_frame_rate), st->time_base) > 0)
>  put_ebml_uint(pb, MATROSKA_ID_TRACKDEFAULTDURATION, 10LL 
> * st->avg_frame_rate.den / st->avg_frame_rate.num);
> -else
> -put_ebml_uint(pb, MATROSKA_ID_TRACKDEFAULTDURATION, 10LL 
> * st->time_base.num / st->time_base.den);
>  
>  if (!native_id &&
>  ff_codec_get_tag(ff_codec_movvideo_tags, par->codec_id) &&

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

Re: [FFmpeg-devel] [PATCH]lavf/isom: Recognize fourcc HEVC

[Compn]

On Fri, 4 May 2018 14:36:03 +0200, wm4  wrote:

> FourCC are already split up for avi and mov. Apparently it got
> sabotaged at some point.

i think mkv re-uses riff list from avi on purpose, as it was meant as a
replacement to avi (and has all the vfw codec tags in the spec).
duplicating mkv and avi seems like a bad idea as they use the same tags.

https://www.matroska.org/technical/guides/faq/index.html

> A mux whitelist would be just as much as splitting the list. (Although
> having separate mux lists would be a good idea too.)

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

Re: [FFmpeg-devel] [PATCH] avfilter/af_amerge: port to activate API

[Paul B Mahol]

On 5/4/18, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/af_amerge.c | 144
> ++--
>  1 file changed, 67 insertions(+), 77 deletions(-)
>

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

Re: [FFmpeg-devel] [PATCH]lavf/isom: Recognize fourcc HEVC

[Compn]

On Fri, 4 May 2018 08:19:27 -0400, Compn  wrote:

> my idea would be to create a whitelist of codec ids we can encode to,
> instead of splitting up the decode fourcc list amongst formats.

that would also be a nightmare to maintain and users would ask for
support for "xxx codec" in "xyz format".

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

Re: [FFmpeg-devel] [PATCH]lavf/isom: Recognize fourcc HEVC

[wm4]

On Fri, 4 May 2018 08:19:27 -0400
Compn  wrote:

> On Thu, 3 May 2018 17:26:38 -0300, James Almer 
> wrote:
> > Create a new table with all non standard codecids from ff_codec_bmp_tags
> > and use it exclusively in avidec, then remove them from
> > ff_codec_bmp_tags, adapting other de/muxers if needed (like ivf).
> > 
> > And then add this HEVC codecid to it.  
> 
> as fourcc maintainer i approve carls patch to add h265.

I'm against it.

> while i like james's idea, it would create a duplicated mess
> of fourcc lists in each container. the fourcc problem got worse as
> more people were using mov tags in avi, which is why the hack was
> requested to have the avi container look at the isom list. saving us
> from duplicating the isom list in the avi list. mostly due to apple
> users needing an intermediate format for their apple codecs.
> 
> i would be extremely against splitting and duplicating the
> decoding fourccs again. internal and external fourccs like VLC and
> mplayer would be the end game to that. ugh.

VLC and mplayer need internal FourCCs because of their architecture.
It's not relevant to FFmpeg.

> 
> my idea would be to create a whitelist of codec ids we can encode to,
> instead of splitting up the decode fourcc list amongst formats.

FourCC are already split up for avi and mov. Apparently it got
sabotaged at some point.

A mux whitelist would be just as much as splitting the list. (Although
having separate mux lists would be a good idea too.)

Also here's an advice to FFmpeg: STOP ALLOWING USERS TO CREATE INVALID
FILES. I'm sick of working them around. Stop creating a fucked up mess.
It starts with rejecting this patch.

> that way we fully control which fourcc we support in which codecs on
> the encoder side (avienc, movenc). and we dont mess with the decoder
> fourccs at all.
> 
> please let me know if my idea would work, i am probably missing some
> huge flaw somewhere...
> 
> -compn
> ___
> 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]lavf/isom: Recognize fourcc HEVC

[Paul B Mahol]

On 5/4/18, Compn  wrote:
> On Thu, 3 May 2018 17:26:38 -0300, James Almer 
> wrote:
>> Create a new table with all non standard codecids from ff_codec_bmp_tags
>> and use it exclusively in avidec, then remove them from
>> ff_codec_bmp_tags, adapting other de/muxers if needed (like ivf).
>>
>> And then add this HEVC codecid to it.
>
> as fourcc maintainer i approve carls patch to add h265.

I blocked it, your approval means now nothing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/isom: Recognize fourcc HEVC

[Compn]

On Thu, 3 May 2018 17:26:38 -0300, James Almer 
wrote:
> Create a new table with all non standard codecids from ff_codec_bmp_tags
> and use it exclusively in avidec, then remove them from
> ff_codec_bmp_tags, adapting other de/muxers if needed (like ivf).
> 
> And then add this HEVC codecid to it.

as fourcc maintainer i approve carls patch to add h265.

while i like james's idea, it would create a duplicated mess
of fourcc lists in each container. the fourcc problem got worse as
more people were using mov tags in avi, which is why the hack was
requested to have the avi container look at the isom list. saving us
from duplicating the isom list in the avi list. mostly due to apple
users needing an intermediate format for their apple codecs.

i would be extremely against splitting and duplicating the
decoding fourccs again. internal and external fourccs like VLC and
mplayer would be the end game to that. ugh.

my idea would be to create a whitelist of codec ids we can encode to,
instead of splitting up the decode fourcc list amongst formats.

that way we fully control which fourcc we support in which codecs on
the encoder side (avienc, movenc). and we dont mess with the decoder
fourccs at all.

please let me know if my idea would work, i am probably missing some
huge flaw somewhere...

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

Re: [FFmpeg-devel] [PATCH] flvenc: Fix sequence header update timestamps

[wm4]

On Fri, 4 May 2018 17:31:52 +0800
Steven Liu  wrote:

> > On 4 May 2018, at 17:20, Jan Ekström  wrote:
> > 
> > WHAT!?
> > 
> > This LGTM was for the bit mask *only*
> > 
> > ALL OTHER POINTS STAND  
> 
> Don’t worry , all LGTM too, this could fix the resend sequence header 
> timestamp problem, all should be ok.

Well it doesn't LGT him.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] flvenc: Fix sequence header update timestamps

[Michael Niedermayer]

On Fri, May 04, 2018 at 11:03:20AM +0800, Steven Liu wrote:
> 
> 
> > On 4 May 2018, at 02:00, Jan Ekström  wrote:
> > 
> > On Thu, May 3, 2018 at 8:58 PM, Jan Ekström  wrote:
> >> On Thu, May 3, 2018 at 7:50 PM, Alex Converse  
> >> wrote:
[...]

> Will apply.

I think Alex Converse has a git write account, so he can push himself if you
prefer

thx

[...]
-- 
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

[FFmpeg-devel] [PATCH] avfilter/af_amerge: port to activate API

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavfilter/af_amerge.c | 144 ++--
 1 file changed, 67 insertions(+), 77 deletions(-)

diff --git a/libavfilter/af_amerge.c b/libavfilter/af_amerge.c
index 09c660ef49..8b71b3ce49 100644
--- a/libavfilter/af_amerge.c
+++ b/libavfilter/af_amerge.c
@@ -31,8 +31,8 @@
 #include "libavutil/channel_layout.h"
 #include "libavutil/opt.h"
 #include "avfilter.h"
+#include "filters.h"
 #include "audio.h"
-#include "bufferqueue.h"
 #include "internal.h"
 
 #define SWR_CH_MAX 64
@@ -43,10 +43,7 @@ typedef struct AMergeContext {
 int route[SWR_CH_MAX]; /**< channels routing, see copy_samples */
 int bps;
 struct amerge_input {
-struct FFBufQueue queue;
 int nb_ch; /**< number of channels for the input */
-int nb_samples;
-int pos;
 } *in;
 } AMergeContext;
 
@@ -67,8 +64,6 @@ static av_cold void uninit(AVFilterContext *ctx)
 int i;
 
 for (i = 0; i < s->nb_inputs; i++) {
-if (s->in)
-ff_bufqueue_discard_all(>in[i].queue);
 if (ctx->input_pads)
 av_freep(>input_pads[i].name);
 }
@@ -183,21 +178,6 @@ static int config_output(AVFilterLink *outlink)
 return 0;
 }
 
-static int request_frame(AVFilterLink *outlink)
-{
-AVFilterContext *ctx = outlink->src;
-AMergeContext *s = ctx->priv;
-int i, ret;
-
-for (i = 0; i < s->nb_inputs; i++)
-if (!s->in[i].nb_samples ||
-/* detect EOF immediately */
-(ctx->inputs[i]->status_in && !ctx->inputs[i]->status_out))
-if ((ret = ff_request_frame(ctx->inputs[i])) < 0)
-return ret;
-return 0;
-}
-
 /**
  * Copy samples from several input streams to one output stream.
  * @param nb_inputs number of inputs
@@ -235,90 +215,101 @@ static inline void copy_samples(int nb_inputs, struct 
amerge_input in[],
 }
 }
 
-static int filter_frame(AVFilterLink *inlink, AVFrame *insamples)
+static void free_frames(int nb_inputs, AVFrame **input_frames)
+{
+int i;
+for (i = 0; i < nb_inputs; i++)
+av_frame_free(_frames[i]);
+}
+
+static int try_push_frame(AVFilterContext *ctx, int nb_samples)
 {
-AVFilterContext *ctx = inlink->dst;
 AMergeContext *s = ctx->priv;
-AVFilterLink *const outlink = ctx->outputs[0];
-int input_number;
-int nb_samples, ns, i;
-AVFrame *outbuf, *inbuf[SWR_CH_MAX];
-uint8_t *ins[SWR_CH_MAX], *outs;
-
-for (input_number = 0; input_number < s->nb_inputs; input_number++)
-if (inlink == ctx->inputs[input_number])
-break;
-av_assert1(input_number < s->nb_inputs);
-if (ff_bufqueue_is_full(>in[input_number].queue)) {
-av_frame_free();
-return AVERROR(ENOMEM);
+AVFilterLink *outlink = ctx->outputs[0];
+int i, ret;
+AVFrame *outbuf, *inbuf[SWR_CH_MAX] = { NULL };
+uint8_t *outs, *ins[SWR_CH_MAX];
+
+for (i = 0; i < ctx->nb_inputs; i++) {
+ret = ff_inlink_consume_samples(ctx->inputs[i], nb_samples, 
nb_samples, [i]);
+if (ret < 0) {
+free_frames(i, inbuf);
+return ret;
+}
+ins[i] = inbuf[i]->data[0];
 }
-ff_bufqueue_add(ctx, >in[input_number].queue, 
av_frame_clone(insamples));
-s->in[input_number].nb_samples += insamples->nb_samples;
-av_frame_free();
-nb_samples = s->in[0].nb_samples;
-for (i = 1; i < s->nb_inputs; i++)
-nb_samples = FFMIN(nb_samples, s->in[i].nb_samples);
-if (!nb_samples)
-return 0;
 
 outbuf = ff_get_audio_buffer(ctx->outputs[0], nb_samples);
-if (!outbuf)
+if (!outbuf) {
+free_frames(s->nb_inputs, inbuf);
 return AVERROR(ENOMEM);
-outs = outbuf->data[0];
-for (i = 0; i < s->nb_inputs; i++) {
-inbuf[i] = ff_bufqueue_peek(>in[i].queue, 0);
-ins[i] = inbuf[i]->data[0] +
- s->in[i].pos * s->in[i].nb_ch * s->bps;
 }
-av_frame_copy_props(outbuf, inbuf[0]);
-outbuf->pts = inbuf[0]->pts == AV_NOPTS_VALUE ? AV_NOPTS_VALUE :
-  inbuf[0]->pts +
-  av_rescale_q(s->in[0].pos,
-   av_make_q(1, ctx->inputs[0]->sample_rate),
-   ctx->outputs[0]->time_base);
+
+outs = outbuf->data[0];
+outbuf->pts = inbuf[0]->pts;
 
 outbuf->nb_samples = nb_samples;
 outbuf->channel_layout = outlink->channel_layout;
 outbuf->channels   = outlink->channels;
 
 while (nb_samples) {
-ns = nb_samples;
-for (i = 0; i < s->nb_inputs; i++)
-ns = FFMIN(ns, inbuf[i]->nb_samples - s->in[i].pos);
 /* Unroll the most common sample formats: speed +~350% for the loop,
+~13% overall (including two common decoders) */
 switch (s->bps) {
 case 1:
-copy_samples(s->nb_inputs, s->in, s->route, ins, , ns, 1);
+copy_samples(s->nb_inputs, 

Re: [FFmpeg-devel] [PATCH] flvenc: Fix sequence header update timestamps

[Steven Liu]

> On 4 May 2018, at 17:20, Jan Ekström  wrote:
> 
> WHAT!?
> 
> This LGTM was for the bit mask *only*
> 
> ALL OTHER POINTS STAND

Don’t worry , all LGTM too, this could fix the resend sequence header timestamp 
problem, all should be ok.
> 
> Jan



Thanks
Steven





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

Re: [FFmpeg-devel] [PATCH] flvenc: Fix sequence header update timestamps

[Jan Ekström]

WHAT!?

This LGTM was for the bit mask *only*

ALL OTHER POINTS STAND

Jan

On Fri, May 4, 2018, 06:04 Steven Liu  wrote:

>
>
> > On 4 May 2018, at 02:00, Jan Ekström  wrote:
> >
> > On Thu, May 3, 2018 at 8:58 PM, Jan Ekström  wrote:
> >> On Thu, May 3, 2018 at 7:50 PM, Alex Converse 
> wrote:
> >>> From: Alex Converse 
> >>>
> >>> ---
> >>> libavformat/flvenc.c | 10 +-
> >>> 1 file changed, 5 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
> >>> index e8af48cb64..827d798a61 100644
> >>> --- a/libavformat/flvenc.c
> >>> +++ b/libavformat/flvenc.c
> >>> @@ -480,7 +480,7 @@ static int unsupported_codec(AVFormatContext *s,
> >>> return AVERROR(ENOSYS);
> >>> }
> >>>
> >>> -static void flv_write_codec_header(AVFormatContext* s,
> AVCodecParameters* par) {
> >>> +static void flv_write_codec_header(AVFormatContext* s,
> AVCodecParameters* par, unsigned int ts) {
> >>
> >> Hi,
> >>
> >> While the timestamp field is 8+24=32 bits, the DTS value is int64_ts.
> >> Thus, while I'm really bad at doing wrap-around logic, wouldn't it be
> >> something a la ´uint32_t wrapped_timestamp = (uint32_t)(ts %
> >> UINT32_MAX)`?
> >>
> >> Additionally, I did briefly go through E.4.1 (FLV Tag) in the spec and
> >> it doesn't really seem to define whether this value is PTS or DTS...
> >> Is this defined anywhere proper? Given FLV's age I wouldn't be
> >> surprised that the answer would be "effectively DTS", of course. But
> >> if you've seen what  Adobe's implementation writes with B-frames it'd
> >> be interesting to see.
> >>
> >>> int64_t data_size;
> >>> AVIOContext *pb = s->pb;
> >>> FLVContext *flv = s->priv_data;
> >>> @@ -492,8 +492,8 @@ static void
> flv_write_codec_header(AVFormatContext* s, AVCodecParameters* par) {
> >>> par->codec_type == AVMEDIA_TYPE_VIDEO ?
> >>> FLV_TAG_TYPE_VIDEO : FLV_TAG_TYPE_AUDIO);
> >>> avio_wb24(pb, 0); // size patched later
> >>> -avio_wb24(pb, 0); // ts
> >>> -avio_w8(pb, 0);   // ts ext
> >>> +avio_wb24(pb, ts & 0xFF);
> >>> +avio_w8(pb, (ts >> 24) & 0x7F);
> >>
> >> Looking at the spec this is bottom 24 bits of the timestamp and top 8,
> >> thus why is the second one not & 0xFF ?
> >>
> >
> > D'oh, I should read better. "...to form a SI32 value". Thus, this is
> LGTM.
>
> Will apply.
>
> Thanks
> Steven
>
>
>
>
>
> ___
> 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 2/4] vaapi_encode_h265: Insert mastering display colour colume if needed

[Xiang, Haihao]

On Thu, 2018-05-03 at 22:43 +0100, Mark Thompson wrote:
> On 03/05/18 04:07, Haihao Xiang wrote:
> > '-sei xxx' is added to control SEI insertion, so far only mastering
> > display colour colume is available for testing.
> 
> Typo: "colume" (also in the commit title).
> 

Thanks for catching the typo, I will correct it in the new version of patch.

> > v2: use the mastering display parameters from
> > AVMasteringDisplayMetadata, set SEI_MASTERING_DISPLAY to 8 to match
> > the H.264 part and take VAAPIEncodeH265Context::sei_needed as a ORed
> > value so that we needn't check the correspoding SEI message again when
> > writting the header.
> > 
> > Signed-off-by: Haihao Xiang 
> > ---
> >  libavcodec/vaapi_encode_h265.c | 128
> > -
> >  1 file changed, 127 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
> > index 5203c6871d..326fe4fe66 100644
> > --- a/libavcodec/vaapi_encode_h265.c
> > +++ b/libavcodec/vaapi_encode_h265.c
> > @@ -24,15 +24,20 @@
> >  #include "libavutil/avassert.h"
> >  #include "libavutil/common.h"
> >  #include "libavutil/opt.h"
> > +#include "libavutil/mastering_display_metadata.h"
> >  
> >  #include "avcodec.h"
> >  #include "cbs.h"
> >  #include "cbs_h265.h"
> >  #include "hevc.h"
> > +#include "hevc_sei.h"
> >  #include "internal.h"
> >  #include "put_bits.h"
> >  #include "vaapi_encode.h"
> >  
> > +enum {
> > +SEI_MASTERING_DISPLAY   = 0x08,
> > +};
> >  
> >  typedef struct VAAPIEncodeH265Context {
> >  unsigned int ctu_width;
> > @@ -47,6 +52,9 @@ typedef struct VAAPIEncodeH265Context {
> >  H265RawSPS sps;
> >  H265RawPPS pps;
> >  H265RawSlice slice;
> > +H265RawSEI sei;
> > +
> > +H265RawSEIMasteringDiplayColourVolume mastering_display;
> >  
> >  int64_t last_idr_frame;
> >  int pic_order_cnt;
> > @@ -58,6 +66,7 @@ typedef struct VAAPIEncodeH265Context {
> >  CodedBitstreamContext *cbc;
> >  CodedBitstreamFragment current_access_unit;
> >  int aud_needed;
> > +int sei_needed;
> >  } VAAPIEncodeH265Context;
> >  
> >  typedef struct VAAPIEncodeH265Options {
> > @@ -65,6 +74,7 @@ typedef struct VAAPIEncodeH265Options {
> >  int aud;
> >  int profile;
> >  int level;
> > +int sei;
> >  } VAAPIEncodeH265Options;
> >  
> >  
> > @@ -175,6 +185,64 @@ fail:
> >  return err;
> >  }
> >  
> > +static int vaapi_encode_h265_write_extra_header(AVCodecContext *avctx,
> > +VAAPIEncodePicture *pic,
> > +int index, int *type,
> > +char *data, size_t
> > *data_len)
> > +{
> > +VAAPIEncodeContext  *ctx = avctx->priv_data;
> > +VAAPIEncodeH265Context *priv = ctx->priv_data;
> > +CodedBitstreamFragment   *au = >current_access_unit;
> > +int err, i;
> > +
> > +if (priv->sei_needed) {
> > +if (priv->aud_needed) {
> > +err = vaapi_encode_h265_add_nal(avctx, au, >aud);
> > +if (err < 0)
> > +goto fail;
> > +priv->aud_needed = 0;
> > +}
> > +
> > +memset(>sei, 0, sizeof(priv->sei));
> > +priv->sei.nal_unit_header  = (H265RawNALUnitHeader) {
> > +.nal_unit_type = HEVC_NAL_SEI_PREFIX,
> > +.nuh_layer_id  = 0,
> > +.nuh_temporal_id_plus1 = 1,
> > +};
> > +
> > +i = 0;
> > +
> > +if (priv->sei_needed & SEI_MASTERING_DISPLAY) {
> > +priv->sei.payload[i].payload_type =
> > HEVC_SEI_TYPE_MASTERING_DISPLAY_INFO;
> > +priv->sei.payload[i].payload.mastering_display = priv-
> > >mastering_display;
> > +++i;
> > +}
> > +
> > +priv->sei.payload_count = i;
> > +av_assert0(priv->sei.payload_count > 0);
> > +
> > +err = vaapi_encode_h265_add_nal(avctx, au, >sei);
> > +if (err < 0)
> > +goto fail;
> > +priv->sei_needed = 0;
> > +
> > +err = vaapi_encode_h265_write_access_unit(avctx, data, data_len,
> > au);
> > +if (err < 0)
> > +goto fail;
> > +
> > +ff_cbs_fragment_uninit(priv->cbc, au);
> > +
> > +*type = VAEncPackedHeaderRawData;
> > +return 0;
> > +} else {
> > +return AVERROR_EOF;
> > +}
> > +
> > +fail:
> > +ff_cbs_fragment_uninit(priv->cbc, au);
> > +return err;
> > +}
> > +
> >  static int vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
> >  {
> >  VAAPIEncodeContext*ctx = avctx->priv_data;
> > @@ -587,6 +655,53 @@ static int
> > vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
> >  priv->aud_needed = 0;
> >  }
> >  
> > +priv->sei_needed = 0;
> > +
> > +if ((opt->sei & SEI_MASTERING_DISPLAY) &&
> > +(pic->type == PICTURE_TYPE_I || pic->type 

Re: [FFmpeg-devel] [PATCH] avfilter/af_join: detect EOF immediately

[Paul B Mahol]

On 8/26/17, Nicolas George  wrote:
> L'octidi 8 fructidor, an CCXXV, Paul B Mahol a ecrit :
>> Prevents hang.
>>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavfilter/af_join.c | 12 +---
>>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> Probably not 100% correct, but it comes from the fork, with the old
> broken scheduling, so no objection is it fixes something.
>
> Rewriting amerge to use activate() is high in my priorities.

Have you started work on this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v4]avocdec/nvenc: Reconfigure bitrate on the fly

[Timo Rothenpieler]

> for dynamic resolution, maybe add a check ?
> 
> ctx->support_dyn_res = nvenc_check_cap(avctx,
> NV_ENC_CAPS_SUPPORT_DYN_RES_CHANGE);
> 
> and:
> if (dw != ctx->init_encode_params.darWidth || dh !=
> ctx->init_encode_params.darHeight)
> 
> ==>
> if ( (dw != ctx->init_encode_params.darWidth || dh !=
> ctx->init_encode_params.darHeight) && ctx->support_dyn_res)

That's not a resolution change, only a dar change.
I'm not sure if actual resolution changes are even supported by avcodec.



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

[FFmpeg-devel] [RFC] lavfi: add opencl tonemap filter.

[Ruiling Song]

It basically does hdr to sdr conversion with tonemapping.

Signed-off-by: Ruiling Song 
---
This patch tries to add a filter to do hdr to sdr conversion with tonemapping.
The filter does all the job of tonemapping in one pass, which is quite 
different from the vf_tonemap.c
I choose this way because I think this would introduce less memory access.

And I find that tonemaping shares lots of code with colorspace conversion.
So I move color space related code into seprated files (both OpenCL kernel and 
host code).

I am not sure whether the design seems OK?
Is there anybody would like to give some comments on the overall design or 
implementation details?


Thanks!
Ruiling

 configure  |   1 +
 libavfilter/Makefile   |   2 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/colorspace_basic.c |  89 +++
 libavfilter/colorspace_basic.h |  40 +++
 libavfilter/opencl/colorspace_basic.cl | 137 ++
 libavfilter/opencl/tonemap.cl  | 136 ++
 libavfilter/opencl_source.h|   2 +
 libavfilter/vf_tonemap_opencl.c| 472 +
 9 files changed, 880 insertions(+)
 create mode 100644 libavfilter/colorspace_basic.c
 create mode 100644 libavfilter/colorspace_basic.h
 create mode 100644 libavfilter/opencl/colorspace_basic.cl
 create mode 100644 libavfilter/opencl/tonemap.cl
 create mode 100644 libavfilter/vf_tonemap_opencl.c

diff --git a/configure b/configure
index 7f199c6..b9e464d 100755
--- a/configure
+++ b/configure
@@ -3395,6 +3395,7 @@ tinterlace_filter_deps="gpl"
 tinterlace_merge_test_deps="tinterlace_filter"
 tinterlace_pad_test_deps="tinterlace_filter"
 tonemap_filter_deps="const_nan"
+tonemap_opencl_filter_deps="opencl"
 unsharp_opencl_filter_deps="opencl"
 uspp_filter_deps="gpl avcodec"
 vaguedenoiser_filter_deps="gpl"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 3454f25..7a1b0e8 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -348,6 +348,8 @@ OBJS-$(CONFIG_TINTERLACE_FILTER) += 
vf_tinterlace.o
 OBJS-$(CONFIG_TLUT2_FILTER)  += vf_lut2.o framesync.o
 OBJS-$(CONFIG_TMIX_FILTER)   += vf_mix.o framesync.o
 OBJS-$(CONFIG_TONEMAP_FILTER)+= vf_tonemap.o
+OBJS-$(CONFIG_TONEMAP_OPENCL_FILTER) += vf_tonemap_opencl.o 
colorspace_basic.o opencl.o \
+opencl/tonemap.o 
opencl/colorspace_basic.o
 OBJS-$(CONFIG_TRANSPOSE_FILTER)  += vf_transpose.o
 OBJS-$(CONFIG_TRIM_FILTER)   += trim.o
 OBJS-$(CONFIG_UNPREMULTIPLY_FILTER)  += vf_premultiply.o framesync.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index d958f9b..759097a 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -339,6 +339,7 @@ extern AVFilter ff_vf_tinterlace;
 extern AVFilter ff_vf_tlut2;
 extern AVFilter ff_vf_tmix;
 extern AVFilter ff_vf_tonemap;
+extern AVFilter ff_vf_tonemap_opencl;
 extern AVFilter ff_vf_transpose;
 extern AVFilter ff_vf_trim;
 extern AVFilter ff_vf_unpremultiply;
diff --git a/libavfilter/colorspace_basic.c b/libavfilter/colorspace_basic.c
new file mode 100644
index 000..93f9f08
--- /dev/null
+++ b/libavfilter/colorspace_basic.c
@@ -0,0 +1,89 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "colorspace_basic.h"
+
+
+void invert_matrix3x3(const double in[3][3], double out[3][3])
+{
+double m00 = in[0][0], m01 = in[0][1], m02 = in[0][2],
+   m10 = in[1][0], m11 = in[1][1], m12 = in[1][2],
+   m20 = in[2][0], m21 = in[2][1], m22 = in[2][2];
+int i, j;
+double det;
+
+out[0][0] =  (m11 * m22 - m21 * m12);
+out[0][1] = -(m01 * m22 - m21 * m02);
+out[0][2] =  (m01 * m12 - m11 * m02);
+out[1][0] = -(m10 * m22 - m20 * m12);
+out[1][1] =  (m00 * m22 - m20 * m02);
+out[1][2] = -(m00 * m12 - m10 * m02);
+out[2][0] =  (m10 * m21 - m20 * m11);
+out[2][1] = -(m00 * m21 - m20 * m01);
+out[2][2] =  (m00 * m11 - m10 * m01);
+
+det = m00 * out[0][0] + m10 * out[0][1] + m20 * out[0][2];
+det = 1.0 / det;
+
+for (i = 0; i < 3; i++) {
+for (j = 0; j < 3; j++)

Re: [FFmpeg-devel] [PATCH 0/3] WebM in dashenc

[Jeyapal, Karthick]

On 5/3/18 10:11 PM, Jan Ekström wrote:
> On Fri, Apr 27, 2018 at 3:51 AM, Jan Ekström  wrote:
>> Personally I would be for removal of the WebM muxing feature in dashenc
>> altogether, since the dashenc feature has never seemingly worked, and
>> since there is a whole separate WebM-specific DASH meta muxer in
>> webmdashenc.
>>
>> But these patches should at least make the thing not crash, and put it
>> under FF_COMPLIANCE_EXPERIMENTAL strictness. That way nobody should be
>> accidentally utilizing it.
>>
>
> For the record, I wrote this at around 4AM under the impression that
> the "WebM DASH" muxer was actually what you would expect from its
> name.. (and by quickly checking that it seemed to be writing a DASH
> manifest)
>
> It most certainly is not that, it just writes a DASH manifest. Does
> not actually mux anything. So yes, dashenc is the thing to poke for
> both ISOBMFF and WebM DASH.
OMG! I was also not aware of that. Oops! 
Thanks for the info.
>
> Accordingly, I have found out that someone actually utilized WebM dash
> for audio, and they mentioned that it worked for them on Chromium,
> Firefox and Edge. The muxer seems to have worked without crashing at
> least during release/3.4. I asked them to verify some video as well,
> and if it works then the FF_COMPLIANCE_EXPERIMENTAL limitation can be
> removed.
I have sent a new patch to make the output format configurable as suggested by 
you sometime back.
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-May/229436.html
I have tested the WebM output with the following results
VP8 - Works both in Chrome and Firefox
Opus - Works both in Chrome and Firefox
VP9 - Works in Chrome. But not in Firefox.
Since most of it working I have also removed the FF_COMPLIANCE_EXPERIMENTAL 
limitation and replaced it with just a warning in case of segment extension 
mismatch.  
>
> Kind of glad adding that made someone notice something, and report
> that they were actually utilizing the feature. They seemed to be happy
> about the thing no longer crashing, as well as the pass-through of
> compliance mode to the sub-muxer.
Yes, that is a really useful feature. 
>
> Best regards,
> Jan
> ___
> 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

[FFmpeg-devel] [PATCH 1/2] avformat/dashenc: Added option for Segment file format

[Karthick J]

From: Karthick Jeyapal 

Right now segment file format is chosen to be either mp4 or webm based on the 
codec format.
This patch makes that choice configurable by the user, instead of being decided 
by the muxer.
---
 doc/muxers.texi   |  8 
 libavformat/dashenc.c | 48 ++--
 2 files changed, 30 insertions(+), 26 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 6f03bba..2429f8e 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -282,6 +282,14 @@ corrects that index value.
 Typically this logic is needed in live streaming use cases. The network 
bandwidth
 fluctuations are common during long run streaming. Each fluctuation can cause
 the segment indexes fall behind the expected real time position.
+
+@item dash_segment_type @var{dash_segment_type}
+Possible values:
+@item mp4
+If this flag is set, the dash segment files will be in in ISOBMFF format. This 
is the default format.
+
+@item webm
+If this flag is set, the dash segment files will be in in WebM format.
 @end table
 
 @anchor{framecrc}
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 1dd6333..412f074 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -48,6 +48,11 @@
 #include "vpcc.h"
 #include "dash.h"
 
+typedef enum {
+SEGMENT_TYPE_MP4,
+SEGMENT_TYPE_WEBM,
+} SegmentType;
+
 typedef struct Segment {
 char file[1024];
 int64_t start_pos;
@@ -69,7 +74,6 @@ typedef struct OutputStream {
 AVFormatContext *ctx;
 int ctx_inited, as_idx;
 AVIOContext *out;
-char format_name[8];
 int packets_written;
 char initfile[1024];
 int64_t init_start_pos, pos;
@@ -125,6 +129,8 @@ typedef struct DASHContext {
 int streaming;
 int64_t timeout;
 int index_correction;
+SegmentType segment_type;
+char format_name[8];
 } DASHContext;
 
 static struct codec_string {
@@ -581,13 +587,13 @@ static int write_adaptation_set(AVFormatContext *s, 
AVIOContext *out, int as_ind
 if (as->media_type == AVMEDIA_TYPE_VIDEO) {
 AVStream *st = s->streams[i];
 avio_printf(out, "\t\t\tformat_name, os->codec_str, bandwidth_str, 
s->streams[i]->codecpar->width, s->streams[i]->codecpar->height);
+i, c->format_name, os->codec_str, bandwidth_str, 
s->streams[i]->codecpar->width, s->streams[i]->codecpar->height);
 if (st->avg_frame_rate.num)
 avio_printf(out, " frameRate=\"%d/%d\"", 
st->avg_frame_rate.num, st->avg_frame_rate.den);
 avio_printf(out, ">\n");
 } else {
 avio_printf(out, "\t\t\t\n",
-i, os->format_name, os->codec_str, bandwidth_str, 
s->streams[i]->codecpar->sample_rate);
+i, c->format_name, os->codec_str, bandwidth_str, 
s->streams[i]->codecpar->sample_rate);
 avio_printf(out, "\t\t\t\t\n",
 s->streams[i]->codecpar->channels);
 }
@@ -959,27 +965,14 @@ static int dash_init(AVFormatContext *s)
 if (!ctx)
 return AVERROR(ENOMEM);
 
-// choose muxer based on codec: webm for VP8 and opus, mp4 otherwise
-// note: os->format_name is also used as part of the mimetype of the
-//   representation, e.g. video/
-if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VP8 ||
-s->streams[i]->codecpar->codec_id == AV_CODEC_ID_OPUS ||
-s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VORBIS) {
-snprintf(os->format_name, sizeof(os->format_name), "webm");
-
-if (s->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL) {
-av_log(s, AV_LOG_ERROR,
-   "WebM support in dashenc is experimental and has not "
-   "been validated. For testing purposes, make sure "
-   "to add -strict experimental and override "
-   "-init_seg_name and -media_seg_name to end with "
-   "the extension 'webm'.\n");
-return AVERROR(EINVAL);
-}
+if (c->segment_type == SEGMENT_TYPE_WEBM) {
+snprintf(c->format_name, sizeof(c->format_name), "webm");
+} else if (c->segment_type == SEGMENT_TYPE_MP4) {
+snprintf(c->format_name, sizeof(c->format_name), "mp4");
 } else {
-snprintf(os->format_name, sizeof(os->format_name), "mp4");
+return AVERROR_MUXER_NOT_FOUND;
 }
-ctx->oformat = av_guess_format(os->format_name, NULL, NULL);
+ctx->oformat = av_guess_format(c->format_name, NULL, NULL);
 if (!ctx->oformat)
 return AVERROR_MUXER_NOT_FOUND;
 os->ctx = ctx;
@@ -1017,7 +1010,7 @@ static int dash_init(AVFormatContext *s)
 av_dict_free();
 os->init_start_pos = 0;
 
-if (!strcmp(os->format_name, "mp4")) {
+if (c->segment_type == SEGMENT_TYPE_MP4) {
 if (c->streaming)
 

[FFmpeg-devel] [PATCH 2/2] avformat/dashenc: Added a warning for incorrect segment name extension

[Karthick J]

From: Karthick Jeyapal 

Applicable only to webm output format.
By default all the segment filenames end with .m4s extension.
When someone chooses webm output format, we recommend they also override the 
relevant segment name options to end with .webm extension. This patch will 
issue a warning for he same.
---
 libavformat/dashenc.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 412f074..bd374e2 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -177,6 +177,16 @@ static void dashenc_io_close(AVFormatContext *s, 
AVIOContext **pb, char *filenam
 }
 }
 
+static int check_file_extension(const char *filename, const char *extension) {
+char *dot;
+if (!filename || !extension)
+return -1;
+dot = strrchr(filename, '.');
+if (dot && !strcmp(dot + 1, extension))
+return 0;
+return -1;
+}
+
 static void set_vp9_codec_str(AVFormatContext *s, AVCodecParameters *par,
   AVRational *frame_rate, char *str, int size) {
 VPCC vpcc;
@@ -967,6 +977,14 @@ static int dash_init(AVFormatContext *s)
 
 if (c->segment_type == SEGMENT_TYPE_WEBM) {
 snprintf(c->format_name, sizeof(c->format_name), "webm");
+if ((!c->single_file && check_file_extension(c->init_seg_name, 
c->format_name) != 0) ||
+(!c->single_file && check_file_extension(c->media_seg_name, 
c->format_name) != 0) ||
+(c->single_file && check_file_extension(c->single_file_name, 
c->format_name) != 0)) {
+av_log(s, AV_LOG_WARNING,
+   "One or many segment file names doesn't end with .webm. 
"
+   "Override -init_seg_name and/or -media_seg_name and/or "
+   "-single_file_name to end with the extension .webm\n");
+}
 } else if (c->segment_type == SEGMENT_TYPE_MP4) {
 snprintf(c->format_name, sizeof(c->format_name), "mp4");
 } else {
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 1/2] lavc/qsvenc: add detail options for MFE mode

[Zhong Li]

Not convenient if using numerals to set MFE mode. It is ambiguous
and misleading (e.g: user may misunderstand setting mfmode to 1 is to
enable MFE but actually it is to disable MFE, and set it to be 5 or above is 
meaningless).

Signed-off-by: Zhong Li 
---
 libavcodec/qsvenc_h264.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
index 718bf9c..5278a04 100644
--- a/libavcodec/qsvenc_h264.c
+++ b/libavcodec/qsvenc_h264.c
@@ -146,7 +146,11 @@ static const AVOption options[] = {
 { "aud", "Insert the Access Unit Delimiter NAL", OFFSET(qsv.aud), 
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE},
 
 #if QSV_HAVE_MF
-{ "mfmode", "Multi-Frame Mode", OFFSET(qsv.mfmode), AV_OPT_TYPE_INT, { 
.i64 = MFX_MF_AUTO }, 0, INT_MAX, VE },
+{ "mfmode", "Multi-Frame Mode", OFFSET(qsv.mfmode), AV_OPT_TYPE_INT, { 
.i64 = MFX_MF_AUTO }, MFX_MF_DEFAULT, MFX_MF_MANUAL, VE, "mfmode"},
+{ "default", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_MF_DEFAULT  }, 
INT_MIN, INT_MAX, VE, "mfmode" },
+{ "off", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_MF_DISABLED }, 
INT_MIN, INT_MAX, VE, "mfmode" },
+{ "auto"   , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_MF_AUTO }, 
INT_MIN, INT_MAX, VE, "mfmode" },
+{ "manual" , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_MF_MANUAL   }, 
INT_MIN, INT_MAX, VE, "mfmode" },
 #endif
 
 { NULL },
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 2/2] lavc/qsvenc: add mf_max_num option for MFE

[Zhong Li]

Maximum number of frames to be used for combining.
Each encoder in joined sessions has to be initialized with the same value.

Signed-off-by: Zhong Li 
---
 libavcodec/qsvenc.c  | 1 +
 libavcodec/qsvenc.h  | 1 +
 libavcodec/qsvenc_h264.c | 2 ++
 3 files changed, 4 insertions(+)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 3ce5ffe..e58fdc2 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -661,6 +661,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 q->extmfp.Header.BufferSz = sizeof(q->extmfp);
 
 q->extmfp.MFMode = q->mfmode;
+q->extmfp.MaxNumFrames = q->mf_max_num;
 av_log(avctx,AV_LOG_VERBOSE,"MFMode:%d\n", q->extmfp.MFMode);
 q->extparam_internal[q->nb_extparam_internal++] = 
(mfxExtBuffer *)>extmfp;
 }
diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
index d482722..76c8106 100644
--- a/libavcodec/qsvenc.h
+++ b/libavcodec/qsvenc.h
@@ -166,6 +166,7 @@ typedef struct QSVEncContext {
 
 #if QSV_HAVE_MF
 int mfmode;
+int mf_max_num;
 #endif
 char *load_plugins;
 SetEncodeCtrlCB *set_encode_ctrl_cb;
diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
index 5278a04..bee10b2 100644
--- a/libavcodec/qsvenc_h264.c
+++ b/libavcodec/qsvenc_h264.c
@@ -151,6 +151,8 @@ static const AVOption options[] = {
 { "off", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_MF_DISABLED }, 
INT_MIN, INT_MAX, VE, "mfmode" },
 { "auto"   , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_MF_AUTO }, 
INT_MIN, INT_MAX, VE, "mfmode" },
 { "manual" , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_MF_MANUAL   }, 
INT_MIN, INT_MAX, VE, "mfmode" },
+
+{ "mf_max_num", "Maximum frame number of Multi-Frame encoding", 
OFFSET(qsv.mf_max_num), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 3, VE},
 #endif
 
 { NULL },
-- 
2.7.4

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