Re: [FFmpeg-devel] [PATCH] avformat/segafilmenc - set keyframe bit correctly

[Gyan Doshi]

On 5/6/2018 4:39 AM, James Almer wrote:

On 5/5/2018 8:06 PM, Michael Niedermayer wrote:

On Sat, May 05, 2018 at 05:16:09PM +0530, Gyan Doshi wrote:

Since the muxer author hasn't made the change, the patch is submitted.

Reference:

http://www.ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228602.html




A micro bump should be enough.


Micro version bumped.
From 1d84745b8a7131523c89c46de70666d56684cb69 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Sat, 5 May 2018 17:04:53 +0530
Subject: [PATCH] avformat/segafilmenc - set keyframe bit correctly

As per
https://web.archive.org/web/20020803104640/http://www.pcisys.net:80/~melanson/codecs/film-format.txt,

the top bit of the info1 chunk is set as 1 for inter-coded frames and 0
otherwise.
---
 libavformat/segafilmenc.c | 2 +-
 libavformat/version.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
index 5b0d7e69e8..524230e461 100644
--- a/libavformat/segafilmenc.c
+++ b/libavformat/segafilmenc.c
@@ -69,7 +69,7 @@ static int film_write_packet_to_header(AVFormatContext 
*format_context, FILMPack
 info1 = pkt->pts;
 info2 = pkt->duration;
 /* The top bit being set indicates a key frame */
-if (pkt->keyframe)
+if (!pkt->keyframe)
 info1 |= (1 << 31);
 }
 
diff --git a/libavformat/version.h b/libavformat/version.h
index e589d77798..49e40e9494 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -33,7 +33,7 @@
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  58
 #define LIBAVFORMAT_VERSION_MINOR  13
-#define LIBAVFORMAT_VERSION_MICRO 101
+#define LIBAVFORMAT_VERSION_MICRO 102
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
-- 
2.12.2.windows.2___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] introduction

[kendell clark]

Hi all
My name is Kendell Clark, and I’ve been involved in open source software since 
august of 2011. I’ve recently purchased a used iPod touch, 5th generation, and 
have found that to use it well, windows and iTunes is required, which I’m not 
happy about. I’d much rather use Linux to manage the thing, which is partly 
doable. However, I’ve also found out that books purchased through iTunes are 
protected with some ridiculous drm scheme, and ffmpeg cannot handle these 
files, yet. I’ve built ffmpeg from source and wish to help you guys add support 
for this format if you guys are interested. I’ve burned the book to a cd so I 
can play it on other devices and my pc, but I want to help you guys add support 
for whatever scheme these guys are using. I’m being told to upload a sample to 
your ftp server at ftp.ffmpeg.org/incoming, but 
I’m unsure how to generate a sample that will be enough of the file to figure 
out what apple is doing but not so much as to be a burdeon on your server. I 
don’t want to upload the entire thing but I also want to be helpful. Any help 
would be appreciated. I cannot code, so won’t be able to help code, but I’d be 
glad to help test, or in any other way you guys would find useful.
Thanks
Kendell Clark


Sent from Mail for Windows 10

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

[FFmpeg-devel] [PATCH 1/2] checkasm/sw_rgb: fix the function declaration warning

[Jun Zhao]

fix the warning: "function declaration isn’t a prototype", in C
int foo() and int foo(void) are different functions. int foo()
accepts an arbitrary number of arguments, while int foo(void) accepts 0
arguments.

Signed-off-by: Jun Zhao 
---
 tests/checkasm/sw_rgb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index d2b211f..000420d 100644
--- a/tests/checkasm/sw_rgb.c
+++ b/tests/checkasm/sw_rgb.c
@@ -68,7 +68,7 @@ static void check_shuffle_bytes(void * func, const char * 
report)
 }
 }
 
-static void check_uyvy_to_422p()
+static void check_uyvy_to_422p(void)
 {
 int i;
 
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 2/2] lavfi/tests/filtfmts: fix the build warning.

[Jun Zhao]

fix the build warning: ignoring return value.

Signed-off-by: Jun Zhao 
---
 libavfilter/tests/filtfmts.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/tests/filtfmts.c b/libavfilter/tests/filtfmts.c
index a958621..317df86 100644
--- a/libavfilter/tests/filtfmts.c
+++ b/libavfilter/tests/filtfmts.c
@@ -138,9 +138,9 @@ int main(int argc, char **argv)
 }
 
 if (filter->query_formats)
-filter->query_formats(filter_ctx);
+ret = filter->query_formats(filter_ctx);
 else
-ff_default_query_formats(filter_ctx);
+ret = ff_default_query_formats(filter_ctx);
 
 print_formats(filter_ctx);
 
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH] dcaenc: fix segfault when attempting to encode with invalid samplerate

[Michael Niedermayer]

On Sat, May 05, 2018 at 06:43:34PM +0100, Rostislav Pehlivanov wrote:
> ---
>  libavcodec/dcaenc.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/dcaenc.c b/libavcodec/dcaenc.c
> index 186997c631..4b4ceeff05 100644
> --- a/libavcodec/dcaenc.c
> +++ b/libavcodec/dcaenc.c
> @@ -152,8 +152,11 @@ static int subband_bufer_alloc(DCAEncContext *c)
>  
>  static void subband_bufer_free(DCAEncContext *c)
>  {
> -int32_t *bufer = c->subband[0][0] - DCA_ADPCM_COEFFS;
> -av_freep();
> +if (c->subband[0][0]) {
> +int32_t *bufer = c->subband[0][0] - DCA_ADPCM_COEFFS;
> +av_free(bufer);
> +c->subband[0][0] = NULL;
> +}

LGTM but adding a seperate field representing the allocated array
that isnt offset could be clearer and more robust.

thx

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- 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] opt: print a deprecation indicator when listing options

[Michael Niedermayer]

On Sat, May 05, 2018 at 09:45:26PM +0100, Rostislav Pehlivanov wrote:
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavutil/opt.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavutil/opt.c b/libavutil/opt.c
> index 99282605f5..73295356a1 100644
> --- a/libavutil/opt.c
> +++ b/libavutil/opt.c
> @@ -1276,6 +1276,8 @@ static void opt_list(void *obj, void *av_log_obj, const 
> char *unit,
>  }
>  av_log(av_log_obj, AV_LOG_INFO, ")");
>  }
> +if (opt->flags & AV_OPT_FLAG_DEPRECATED)
> +av_log(av_log_obj, AV_LOG_INFO, " (deprecated)");

Printing this together with the other flags as "%c" would reduce the
worst case width, leaving more space for the other fields

but maybe a bigger text as in this patch is better, i dont know

either way LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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/segafilmenc - set keyframe bit correctly

[James Almer]

On 5/5/2018 8:16 PM, Michael Niedermayer wrote:
> On Sat, May 05, 2018 at 08:09:07PM -0300, James Almer wrote:
>> On 5/5/2018 8:06 PM, Michael Niedermayer wrote:
>>> On Sat, May 05, 2018 at 05:16:09PM +0530, Gyan Doshi wrote:
 Since the muxer author hasn't made the change, the patch is submitted.

 Reference:

 http://www.ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228602.html
>>>
  segafilmenc.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 710a71f12fae34d125a755bc0f5b290c6a6018e9  
 0001-avformat-segafilmenc-set-keyframe-bit-correctly.patch
 From 79f87ff264c2989193d5e59da8c5cf285940aa50 Mon Sep 17 00:00:00 2001
 From: Gyan Doshi 
 Date: Sat, 5 May 2018 17:04:53 +0530
 Subject: [PATCH] avformat/segafilmenc - set keyframe bit correctly

 As per
 https://web.archive.org/web/20020803104640/http://www.pcisys.net:80/~melanson/codecs/film-format.txt,

 the top bit of the info1 chunk is set as 1 for inter-coded frames and 0
 otherwise.
 ---
  libavformat/segafilmenc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
 index 5b0d7e69e8..524230e461 100644
 --- a/libavformat/segafilmenc.c
 +++ b/libavformat/segafilmenc.c
 @@ -69,7 +69,7 @@ static int film_write_packet_to_header(AVFormatContext 
 *format_context, FILMPack
  info1 = pkt->pts;
  info2 = pkt->duration;
  /* The top bit being set indicates a key frame */
 -if (pkt->keyframe)
 +if (!pkt->keyframe)
  info1 |= (1 << 31);
  }
>>>
>>> Fixes to muxers and encoders should always bump the minor or micro version 
>>> of
>>> the lib.
>>>
>>> It would also be ideal if this version is stored in the file, that way
>>> demuxers/decoders can compensate for bugs in the muxer/encoder.
>>> Not sure the format has a place for this?
>>
>> It's a decades old format used on a few games, it's very likely it doesn't.
> 
> yes
> 
> its probably possible to detect the muxer bug without it, if someone wants to
> implement it

Paul said that if the first video frame was not marked as keyframe then
the file is invalid, so the demuxer can probably use that and flip the
flag accordingly.

Or someone could write a cinepak parser, which would allow us to ignore
container level parameters. But i don't expect that to ever happen :p

> 
> 
>>
>> A micro bump should be enough.
> 
> sure
> 
> [...]
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

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

Re: [FFmpeg-devel] [PATCH] avformat/segafilmenc - set keyframe bit correctly

[Michael Niedermayer]

On Sat, May 05, 2018 at 08:09:07PM -0300, James Almer wrote:
> On 5/5/2018 8:06 PM, Michael Niedermayer wrote:
> > On Sat, May 05, 2018 at 05:16:09PM +0530, Gyan Doshi wrote:
> >> Since the muxer author hasn't made the change, the patch is submitted.
> >>
> >> Reference:
> >>
> >> http://www.ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228602.html
> > 
> >>  segafilmenc.c |2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> 710a71f12fae34d125a755bc0f5b290c6a6018e9  
> >> 0001-avformat-segafilmenc-set-keyframe-bit-correctly.patch
> >> From 79f87ff264c2989193d5e59da8c5cf285940aa50 Mon Sep 17 00:00:00 2001
> >> From: Gyan Doshi 
> >> Date: Sat, 5 May 2018 17:04:53 +0530
> >> Subject: [PATCH] avformat/segafilmenc - set keyframe bit correctly
> >>
> >> As per
> >> https://web.archive.org/web/20020803104640/http://www.pcisys.net:80/~melanson/codecs/film-format.txt,
> >>
> >> the top bit of the info1 chunk is set as 1 for inter-coded frames and 0
> >> otherwise.
> >> ---
> >>  libavformat/segafilmenc.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
> >> index 5b0d7e69e8..524230e461 100644
> >> --- a/libavformat/segafilmenc.c
> >> +++ b/libavformat/segafilmenc.c
> >> @@ -69,7 +69,7 @@ static int film_write_packet_to_header(AVFormatContext 
> >> *format_context, FILMPack
> >>  info1 = pkt->pts;
> >>  info2 = pkt->duration;
> >>  /* The top bit being set indicates a key frame */
> >> -if (pkt->keyframe)
> >> +if (!pkt->keyframe)
> >>  info1 |= (1 << 31);
> >>  }
> > 
> > Fixes to muxers and encoders should always bump the minor or micro version 
> > of
> > the lib.
> > 
> > It would also be ideal if this version is stored in the file, that way
> > demuxers/decoders can compensate for bugs in the muxer/encoder.
> > Not sure the format has a place for this?
> 
> It's a decades old format used on a few games, it's very likely it doesn't.

yes

its probably possible to detect the muxer bug without it, if someone wants to
implement it


> 
> A micro bump should be enough.

sure

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

No great genius has ever existed without some touch of madness. -- Aristotle


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/segafilmenc - set keyframe bit correctly

[James Almer]

On 5/5/2018 8:06 PM, Michael Niedermayer wrote:
> On Sat, May 05, 2018 at 05:16:09PM +0530, Gyan Doshi wrote:
>> Since the muxer author hasn't made the change, the patch is submitted.
>>
>> Reference:
>>
>> http://www.ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228602.html
> 
>>  segafilmenc.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 710a71f12fae34d125a755bc0f5b290c6a6018e9  
>> 0001-avformat-segafilmenc-set-keyframe-bit-correctly.patch
>> From 79f87ff264c2989193d5e59da8c5cf285940aa50 Mon Sep 17 00:00:00 2001
>> From: Gyan Doshi 
>> Date: Sat, 5 May 2018 17:04:53 +0530
>> Subject: [PATCH] avformat/segafilmenc - set keyframe bit correctly
>>
>> As per
>> https://web.archive.org/web/20020803104640/http://www.pcisys.net:80/~melanson/codecs/film-format.txt,
>>
>> the top bit of the info1 chunk is set as 1 for inter-coded frames and 0
>> otherwise.
>> ---
>>  libavformat/segafilmenc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
>> index 5b0d7e69e8..524230e461 100644
>> --- a/libavformat/segafilmenc.c
>> +++ b/libavformat/segafilmenc.c
>> @@ -69,7 +69,7 @@ static int film_write_packet_to_header(AVFormatContext 
>> *format_context, FILMPack
>>  info1 = pkt->pts;
>>  info2 = pkt->duration;
>>  /* The top bit being set indicates a key frame */
>> -if (pkt->keyframe)
>> +if (!pkt->keyframe)
>>  info1 |= (1 << 31);
>>  }
> 
> Fixes to muxers and encoders should always bump the minor or micro version of
> the lib.
> 
> It would also be ideal if this version is stored in the file, that way
> demuxers/decoders can compensate for bugs in the muxer/encoder.
> Not sure the format has a place for this?

It's a decades old format used on a few games, it's very likely it doesn't.

A micro bump should be enough.

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

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

Re: [FFmpeg-devel] [PATCH] avformat/segafilmenc - set keyframe bit correctly

[Michael Niedermayer]

On Sat, May 05, 2018 at 05:16:09PM +0530, Gyan Doshi wrote:
> Since the muxer author hasn't made the change, the patch is submitted.
> 
> Reference:
> 
> http://www.ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228602.html

>  segafilmenc.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 710a71f12fae34d125a755bc0f5b290c6a6018e9  
> 0001-avformat-segafilmenc-set-keyframe-bit-correctly.patch
> From 79f87ff264c2989193d5e59da8c5cf285940aa50 Mon Sep 17 00:00:00 2001
> From: Gyan Doshi 
> Date: Sat, 5 May 2018 17:04:53 +0530
> Subject: [PATCH] avformat/segafilmenc - set keyframe bit correctly
> 
> As per
> https://web.archive.org/web/20020803104640/http://www.pcisys.net:80/~melanson/codecs/film-format.txt,
> 
> the top bit of the info1 chunk is set as 1 for inter-coded frames and 0
> otherwise.
> ---
>  libavformat/segafilmenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
> index 5b0d7e69e8..524230e461 100644
> --- a/libavformat/segafilmenc.c
> +++ b/libavformat/segafilmenc.c
> @@ -69,7 +69,7 @@ static int film_write_packet_to_header(AVFormatContext 
> *format_context, FILMPack
>  info1 = pkt->pts;
>  info2 = pkt->duration;
>  /* The top bit being set indicates a key frame */
> -if (pkt->keyframe)
> +if (!pkt->keyframe)
>  info1 |= (1 << 31);
>  }

Fixes to muxers and encoders should always bump the minor or micro version of
the lib.

It would also be ideal if this version is stored in the file, that way
demuxers/decoders can compensate for bugs in the muxer/encoder.
Not sure the format has a place for this?

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


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

Re: [FFmpeg-devel] [PATCH] avcodec/fic: Check available input space for cursor

[Michael Niedermayer]

On Sat, May 05, 2018 at 11:12:06PM +0200, Paul B Mahol wrote:
> On 5/5/18, wm4  wrote:
> > On Sat,  5 May 2018 22:47:37 +0200
> > Michael Niedermayer  wrote:
> >
> >> Fixes: out of array read
> >> Fixes:
> >> 6546/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FIC_fuzzer-6317064647081984
> >>
> >> Found-by: continuous fuzzing process
> >> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> >> Signed-off-by: Michael Niedermayer 
> >> ---
> >>  libavcodec/fic.c | 5 +
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/libavcodec/fic.c b/libavcodec/fic.c
> >> index d7ee370423..6824a5683c 100644
> >> --- a/libavcodec/fic.c
> >> +++ b/libavcodec/fic.c
> >> @@ -337,6 +337,11 @@ static int fic_decode_frame(AVCodecContext *avctx,
> >> void *data,
> >>  skip_cursor = 1;
> >>  }
> >>
> >> +if (!skip_cursor && avpkt->size < 59 + 32 * 32 * 4) {
> >> +av_log(avctx, AV_LOG_WARNING, "Input is cursorless\n");
> >> +skip_cursor = 1;
> >> +}
> >> +
> >>  /* Slice height for all but the last slice. */
> >>  ctx->slice_h = 16 * (ctx->aligned_height >> 4) / nslices;
> >>  if (ctx->slice_h % 16)
> >
> > No warning needed.
> 
> Agreed.

Do you prefer i remove the message completely or make it a debug level one ?
Note, it seems every other case that sets skip_cursor in result of a 
unexpected condition prints something

Thanks

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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


signature.asc
Description: PGP signature
___
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.

[Daniel Oberhoff]

> Am 05.05.2018 um 20:41 schrieb Rostislav Pehlivanov :
> 
> On 5 May 2018 at 18:40, Daniel Oberhoff 
> wrote:
> 
>> 
>>> 
>>> As a last note, you can find my GLSL(+Vulkan) implementations of the
>>> algorithm changes described above, as well as all of the related
>>> color-management code and various decision logic for what values to
>>> infer/default here:
>>> https://github.com/haasn/libplacebo/blob/master/src/shaders/colorspace.c
>> 
>> Again I am wondering if there is interest of having gl and/or Vulkan
>> filters in ffmpeg, along with direct transfer support where the
>> source/target is on gpu, as with many of the hwaccel targets?
>> 
>> That is what we do in our pipeline to get high throughput, and i‘d be
>> happy in pushing some of that back into ffmpeg.
>> 
>> Best,
>> 
>> Daniel
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
> 
> There is already a Vulkan patchset alongside a bunch of filters. I posted
> it 2 weeks ago. Yes, it does accept GLSL using libshaderc. Yes, it supports
> mapping VAAPI and DRM frames. Yes, its much faster than opencl on all
> systems I've tested. No, there will not be an opengl-based filtering
> system, only vulkan.

That makes a lot of sense, gl is dying. We are just reluctant right now to 
switch (yet) for various reasons. Is there any chance for that to land? Can I 
have a look? :)

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

Re: [FFmpeg-devel] [PATCH] avcodec/vp3: Check that there will be sufficient input for the coded fragments in unpack_superblocks()

[Michael Niedermayer]

On Sat, May 05, 2018 at 09:14:52PM +0200, wm4 wrote:
> On Sat,  5 May 2018 21:10:06 +0200
> Michael Niedermayer  wrote:
> 
> > Fixes: Timeout
> > Fixes: 
> > 6292/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP3_fuzzer-4871218218926080
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/vp3.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
> > index 1d83753314..fcc19a627b 100644
> > --- a/libavcodec/vp3.c
> > +++ b/libavcodec/vp3.c
> > @@ -543,7 +543,11 @@ static int unpack_superblocks(Vp3DecodeContext *s, 
> > GetBitContext *gb)
> >   : s->y_superblock_count);
> >  int num_coded_frags = 0;
> >  
> > -for (i = sb_start; i < sb_end && get_bits_left(gb) > 0; i++) {
> > +for (i = sb_start; i < sb_end; i++) {
> > +if (get_bits_left(gb) < ((s->total_num_coded_frags + 
> > num_coded_frags) >> 2)) {
> > +av_log(s->avctx, AV_LOG_ERROR, "Insufficient input data 
> > for coded fragments\n");
> > +return AVERROR_INVALIDDATA;
> > +}
> >  /* iterate through all 16 fragments in a superblock */
> >  for (j = 0; j < 16; j++) {
> >  /* if the fragment is in bounds, check its coding status */
> 
> The log message is pointless bloat.

All error returns of this function print a log message.

Thanks

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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

Re: [FFmpeg-devel] [PATCH] avcodec/fic: Check available input space for cursor

[Paul B Mahol]

On 5/5/18, wm4  wrote:
> On Sat,  5 May 2018 22:47:37 +0200
> Michael Niedermayer  wrote:
>
>> Fixes: out of array read
>> Fixes:
>> 6546/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FIC_fuzzer-6317064647081984
>>
>> Found-by: continuous fuzzing process
>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> Signed-off-by: Michael Niedermayer 
>> ---
>>  libavcodec/fic.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/libavcodec/fic.c b/libavcodec/fic.c
>> index d7ee370423..6824a5683c 100644
>> --- a/libavcodec/fic.c
>> +++ b/libavcodec/fic.c
>> @@ -337,6 +337,11 @@ static int fic_decode_frame(AVCodecContext *avctx,
>> void *data,
>>  skip_cursor = 1;
>>  }
>>
>> +if (!skip_cursor && avpkt->size < 59 + 32 * 32 * 4) {
>> +av_log(avctx, AV_LOG_WARNING, "Input is cursorless\n");
>> +skip_cursor = 1;
>> +}
>> +
>>  /* Slice height for all but the last slice. */
>>  ctx->slice_h = 16 * (ctx->aligned_height >> 4) / nslices;
>>  if (ctx->slice_h % 16)
>
> No warning needed.

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

Re: [FFmpeg-devel] [PATCH] avcodec/fic: Check available input space for cursor

[wm4]

On Sat,  5 May 2018 22:47:37 +0200
Michael Niedermayer  wrote:

> Fixes: out of array read
> Fixes: 
> 6546/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FIC_fuzzer-6317064647081984
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/fic.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libavcodec/fic.c b/libavcodec/fic.c
> index d7ee370423..6824a5683c 100644
> --- a/libavcodec/fic.c
> +++ b/libavcodec/fic.c
> @@ -337,6 +337,11 @@ static int fic_decode_frame(AVCodecContext *avctx, void 
> *data,
>  skip_cursor = 1;
>  }
>  
> +if (!skip_cursor && avpkt->size < 59 + 32 * 32 * 4) {
> +av_log(avctx, AV_LOG_WARNING, "Input is cursorless\n");
> +skip_cursor = 1;
> +}
> +
>  /* Slice height for all but the last slice. */
>  ctx->slice_h = 16 * (ctx->aligned_height >> 4) / nslices;
>  if (ctx->slice_h % 16)

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

[FFmpeg-devel] [PATCH] avcodec/fic: Check available input space for cursor

[Michael Niedermayer]

Fixes: out of array read
Fixes: 
6546/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FIC_fuzzer-6317064647081984

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

diff --git a/libavcodec/fic.c b/libavcodec/fic.c
index d7ee370423..6824a5683c 100644
--- a/libavcodec/fic.c
+++ b/libavcodec/fic.c
@@ -337,6 +337,11 @@ static int fic_decode_frame(AVCodecContext *avctx, void 
*data,
 skip_cursor = 1;
 }
 
+if (!skip_cursor && avpkt->size < 59 + 32 * 32 * 4) {
+av_log(avctx, AV_LOG_WARNING, "Input is cursorless\n");
+skip_cursor = 1;
+}
+
 /* Slice height for all but the last slice. */
 ctx->slice_h = 16 * (ctx->aligned_height >> 4) / nslices;
 if (ctx->slice_h % 16)
-- 
2.17.0

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

[FFmpeg-devel] [PATCH] opt: print a deprecation indicator when listing options

[Rostislav Pehlivanov]

Signed-off-by: Rostislav Pehlivanov 
---
 libavutil/opt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavutil/opt.c b/libavutil/opt.c
index 99282605f5..73295356a1 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -1276,6 +1276,8 @@ static void opt_list(void *obj, void *av_log_obj, const 
char *unit,
 }
 av_log(av_log_obj, AV_LOG_INFO, ")");
 }
+if (opt->flags & AV_OPT_FLAG_DEPRECATED)
+av_log(av_log_obj, AV_LOG_INFO, " (deprecated)");
 
 av_log(av_log_obj, AV_LOG_INFO, "\n");
 if (opt->unit && opt->type != AV_OPT_TYPE_CONST)
-- 
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

[James Almer]

On 4/10/2018 2:16 PM, Sergey Lavrushkin wrote:
> diff --git a/libavfilter/vf_srcnn.c b/libavfilter/vf_srcnn.c
> new file mode 100644
> index 00..d9b4891f7f
> --- /dev/null
> +++ b/libavfilter/vf_srcnn.c
> @@ -0,0 +1,420 @@
> +/*
> + * Copyright (c) 2018 Sergey Lavrushkin
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +/**
> + * @file
> + * Filter implementing image super-resolution using deep convolutional 
> networks.
> + * https://arxiv.org/abs/1501.00092
> + */
> +
> +#include "avfilter.h"
> +#include "formats.h"
> +#include "internal.h"
> +#include "libavutil/opt.h"
> +#include "unistd.h"

This broke msvc. It should be (if anything) , and wrapped
inside a HAVE_UNISTD_H preprocessor check.

> +static av_cold int init(AVFilterContext* context)
> +{
> +SRCNNContext *srcnn_context = context->priv;
> +AVIOContext* config_file_context;
> +int64_t file_size, srcnn_size;
> +
> +/// Check specified confguration file name and read network weights from 
> it
> +if (!srcnn_context->config_file_path){
> +av_log(context, AV_LOG_INFO, "configuration file for network was not 
> specified, using default weights for x2 upsampling\n");
> +
> +/// Create convolution kernels and copy default weights
> +srcnn_context->conv1.input_channels = 1;
> +srcnn_context->conv1.output_channels = 64;
> +srcnn_context->conv1.size = 9;
> +CHECK_ALLOCATION(allocate_copy_conv_data(_context->conv1, 
> conv1_kernel, conv1_biases), )
> +
> +srcnn_context->conv2.input_channels = 64;
> +srcnn_context->conv2.output_channels = 32;
> +srcnn_context->conv2.size = 1;
> +CHECK_ALLOCATION(allocate_copy_conv_data(_context->conv2, 
> conv2_kernel, conv2_biases), )
> +
> +srcnn_context->conv3.input_channels = 32;
> +srcnn_context->conv3.output_channels = 1;
> +srcnn_context->conv3.size = 5;
> +CHECK_ALLOCATION(allocate_copy_conv_data(_context->conv3, 
> conv3_kernel, conv3_biases), )
> +}
> +else if (access(srcnn_context->config_file_path, R_OK) != -1){

This seems to be the function needed from unistd.h

Looking at configure and libavformat/file.c it's apparently not
available everywhere (we have a HAVE_ACCESS define, and also check for
mode constants like R_OK).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/vp3: Check that there will be sufficient input for the coded fragments in unpack_superblocks()

[wm4]

On Sat,  5 May 2018 21:10:06 +0200
Michael Niedermayer  wrote:

> Fixes: Timeout
> Fixes: 
> 6292/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP3_fuzzer-4871218218926080
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/vp3.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
> index 1d83753314..fcc19a627b 100644
> --- a/libavcodec/vp3.c
> +++ b/libavcodec/vp3.c
> @@ -543,7 +543,11 @@ static int unpack_superblocks(Vp3DecodeContext *s, 
> GetBitContext *gb)
>   : s->y_superblock_count);
>  int num_coded_frags = 0;
>  
> -for (i = sb_start; i < sb_end && get_bits_left(gb) > 0; i++) {
> +for (i = sb_start; i < sb_end; i++) {
> +if (get_bits_left(gb) < ((s->total_num_coded_frags + 
> num_coded_frags) >> 2)) {
> +av_log(s->avctx, AV_LOG_ERROR, "Insufficient input data for 
> coded fragments\n");
> +return AVERROR_INVALIDDATA;
> +}
>  /* iterate through all 16 fragments in a superblock */
>  for (j = 0; j < 16; j++) {
>  /* if the fragment is in bounds, check its coding status */

The log message is pointless bloat.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] configure: add pkg-config check for zlib

[Jan Ekström]

It exists, so why not use it? Helps one get rid of additional
search path related flags in addition to PKG_CONFIG_{PATH,LIBDIR}
when utilizing a cross-prefix separate from the sysroot.
---
 configure | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index f78853cc6c..2d99c8ea85 100755
--- a/configure
+++ b/configure
@@ -5933,7 +5933,8 @@ if ! disabled pthreads && ! enabled w32threads && ! 
enabled os2threads; then
 fi
 fi
 
-enabled  zlib && check_lib zlib   zlib.h  zlibVersion-lz
+enabled  zlib && { check_pkg_config zlib zlib "zlib.h" zlibVersion ||
+   check_lib zlib   zlib.h  zlibVersion-lz; }
 enabled bzlib && check_lib bzlib bzlib.h BZ2_bzlibVersion-lbz2
 enabled  lzma && check_lib lzma   lzma.h lzma_version_number -llzma
 
-- 
2.17.0

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

[FFmpeg-devel] [PATCH] avcodec/vp3: Check that there will be sufficient input for the coded fragments in unpack_superblocks()

[Michael Niedermayer]

Fixes: Timeout
Fixes: 
6292/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP3_fuzzer-4871218218926080

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

diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
index 1d83753314..fcc19a627b 100644
--- a/libavcodec/vp3.c
+++ b/libavcodec/vp3.c
@@ -543,7 +543,11 @@ static int unpack_superblocks(Vp3DecodeContext *s, 
GetBitContext *gb)
  : s->y_superblock_count);
 int num_coded_frags = 0;
 
-for (i = sb_start; i < sb_end && get_bits_left(gb) > 0; i++) {
+for (i = sb_start; i < sb_end; i++) {
+if (get_bits_left(gb) < ((s->total_num_coded_frags + 
num_coded_frags) >> 2)) {
+av_log(s->avctx, AV_LOG_ERROR, "Insufficient input data for 
coded fragments\n");
+return AVERROR_INVALIDDATA;
+}
 /* iterate through all 16 fragments in a superblock */
 for (j = 0; j < 16; j++) {
 /* if the fragment is in bounds, check its coding status */
-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH] lavu, lavc/amf: hwcontext_amf phase 1. move AMF library and AMF device management from amfenc to hwcontext_amf

[Alexander Kravchenko]

> -Original Message-
> From: Alexander Kravchenko [mailto:akravchenko...@gmail.com]
> Sent: Thursday, April 26, 2018 10:01 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Alexander Kravchenko 
> Subject: [PATCH] lavu,lavc/amf: hwcontext_amf phase 1. move AMF library and 
> AMF device management from amfenc to
> hwcontext_amf
> 
> This patch moves AMF library and AMF device management from amfenc to 
> hwcontext_amf.
> Now av_hwdevice_ctx API is used for AMF library/context creation/destroying 
> Phase 2 probably will include frame interop/map
> functions using hwframe_ctx API
> 

Hello, 
I am sending reminder to review the patch.

Hopefully you could review it soon.
I am waiting applying it to send patches with vf_scale_amf which is color-space 
converter/scaler using DX9, DX11, OpenCL.


Thanks,
Alexander

___
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.

[Rostislav Pehlivanov]

On 5 May 2018 at 18:40, Daniel Oberhoff 
wrote:

>
> >
> > As a last note, you can find my GLSL(+Vulkan) implementations of the
> > algorithm changes described above, as well as all of the related
> > color-management code and various decision logic for what values to
> > infer/default here:
> > https://github.com/haasn/libplacebo/blob/master/src/shaders/colorspace.c
>
> Again I am wondering if there is interest of having gl and/or Vulkan
> filters in ffmpeg, along with direct transfer support where the
> source/target is on gpu, as with many of the hwaccel targets?
>
> That is what we do in our pipeline to get high throughput, and i‘d be
> happy in pushing some of that back into ffmpeg.
>
> Best,
>
> Daniel
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

There is already a Vulkan patchset alongside a bunch of filters. I posted
it 2 weeks ago. Yes, it does accept GLSL using libshaderc. Yes, it supports
mapping VAAPI and DRM frames. Yes, its much faster than opencl on all
systems I've tested. No, there will not be an opengl-based filtering
system, only vulkan.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] mpegvideo: remove support for libxvid's RC system

[Rostislav Pehlivanov]

On 3 May 2018 at 00:12, Rostislav Pehlivanov  wrote:

> ---
>  MAINTAINERS|   1 -
>  libavcodec/Makefile|   2 +-
>  libavcodec/libxvid_rc.c| 164 -
>  libavcodec/mpegvideo.h |  14 +---
>  libavcodec/mpegvideo_enc.c |  24 +-
>  5 files changed, 6 insertions(+), 199 deletions(-)
>  delete mode 100644 libavcodec/libxvid_rc.c
>
>
pushed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] dcaenc: fix segfault when attempting to encode with invalid samplerate

[Paul B Mahol]

On 5/5/18, Rostislav Pehlivanov  wrote:
> ---
>  libavcodec/dcaenc.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/dcaenc.c b/libavcodec/dcaenc.c
> index 186997c631..4b4ceeff05 100644
> --- a/libavcodec/dcaenc.c
> +++ b/libavcodec/dcaenc.c
> @@ -152,8 +152,11 @@ static int subband_bufer_alloc(DCAEncContext *c)
>
>  static void subband_bufer_free(DCAEncContext *c)
>  {
> -int32_t *bufer = c->subband[0][0] - DCA_ADPCM_COEFFS;
> -av_freep();
> +if (c->subband[0][0]) {
> +int32_t *bufer = c->subband[0][0] - DCA_ADPCM_COEFFS;
> +av_free(bufer);
> +c->subband[0][0] = NULL;
> +}
>  }
>
>  static int encode_init(AVCodecContext *avctx)

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

[FFmpeg-devel] [PATCH] dcaenc: fix segfault when attempting to encode with invalid samplerate

[Rostislav Pehlivanov]

---
 libavcodec/dcaenc.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavcodec/dcaenc.c b/libavcodec/dcaenc.c
index 186997c631..4b4ceeff05 100644
--- a/libavcodec/dcaenc.c
+++ b/libavcodec/dcaenc.c
@@ -152,8 +152,11 @@ static int subband_bufer_alloc(DCAEncContext *c)
 
 static void subband_bufer_free(DCAEncContext *c)
 {
-int32_t *bufer = c->subband[0][0] - DCA_ADPCM_COEFFS;
-av_freep();
+if (c->subband[0][0]) {
+int32_t *bufer = c->subband[0][0] - DCA_ADPCM_COEFFS;
+av_free(bufer);
+c->subband[0][0] = NULL;
+}
 }
 
 static int encode_init(AVCodecContext *avctx)
-- 
2.17.0

___
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

[Nicolas George]

Paul B Mahol (2018-05-04):
> 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 - 

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

[Daniel Oberhoff]

> 
> As a last note, you can find my GLSL(+Vulkan) implementations of the
> algorithm changes described above, as well as all of the related
> color-management code and various decision logic for what values to
> infer/default here:
> https://github.com/haasn/libplacebo/blob/master/src/shaders/colorspace.c

Again I am wondering if there is interest of having gl and/or Vulkan filters in 
ffmpeg, along with direct transfer support where the source/target is on gpu, 
as with many of the hwaccel targets?

That is what we do in our pipeline to get high throughput, and i‘d be happy in 
pushing some of that back into ffmpeg.

Best,

Daniel
___
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]

Another thing that came to my mind:

On Fri,  4 May 2018 15:32:58 +0800, Ruiling Song  wrote:
> +static int tonemap_opencl_filter_frame(AVFilterLink *inlink, AVFrame *input)
> +{
> +AVFilterContext*avctx = inlink->dst;
> +AVFilterLink *outlink = avctx->outputs[0];
> +TonemapOpenCLContext *ctx = avctx->priv;
> +AVFrame *output = NULL;
> +cl_int cle;
> +int err;
> +double peak = ctx->peak;
> +
> +AVHWFramesContext *input_frames_ctx =
> +(AVHWFramesContext*)input->hw_frames_ctx->data;
> +
> +av_log(ctx, AV_LOG_DEBUG, "Filter input: %s, %ux%u (%"PRId64").\n",
> +   av_get_pix_fmt_name(input->format),
> +   input->width, input->height, input->pts);
> +
> +if (!input->hw_frames_ctx)
> +return AVERROR(EINVAL);
> +
> +output = ff_get_video_buffer(outlink, outlink->w, outlink->h);
> +if (!output) {
> +err = AVERROR(ENOMEM);
> +goto fail;
> +}
> +
> +err = av_frame_copy_props(output, input);
> +if (err < 0)
> +goto fail;
> +
> +if (!peak)
> +peak = determine_signal_peak(input);
> +
> +if (ctx->trc != -1)
> +output->color_trc = ctx->trc;
> +if (ctx->primaries != -1)
> +output->color_primaries = ctx->primaries;
> +if (ctx->colorspace != -1)
> +output->colorspace = ctx->colorspace;
> +
> +ctx->trc_in = input->color_trc;
> +ctx->trc_out = output->color_trc;
> +ctx->colorspace_in = input->colorspace;
> +ctx->colorspace_out = output->colorspace;
> +ctx->primaries_in = input->color_primaries;
> +ctx->primaries_out = output->color_primaries;
> +
> +assert(output->sw_format == AV_PIX_FMT_NV12);
> +
> +if (!ctx->initialised) {
> +err = tonemap_opencl_init(avctx);
> +if (err < 0)
> +goto fail;
> +}
> +
> +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;
> +default:
> +av_log(ctx, AV_LOG_ERROR, "unsupported format in tonemap_opencl.\n");
> +err = AVERROR(ENOSYS);
> +goto fail;
> +}
> +
> +cle = clFinish(ctx->command_queue);
> +if (cle != CL_SUCCESS) {
> +av_log(avctx, AV_LOG_ERROR, "Failed to finish command queue: %d.\n",
> +   cle);
> +err = AVERROR(EIO);
> +goto fail;
> +}
> +
> +
> +av_frame_free();
> +
> +av_log(ctx, AV_LOG_DEBUG, "Filter output: %s, %ux%u (%"PRId64").\n",
> +   av_get_pix_fmt_name(output->format),
> +   output->width, output->height, output->pts);
> +
> +return ff_filter_frame(outlink, output);
> +
> +fail:
> +clFinish(ctx->command_queue);
> +av_frame_free();
> +av_frame_free();
> +return err;
> +}

Reading this logic, it seems like each frame is individually processed
by calling clEnqueueNDRangeKernel followed by clFinish, after which the
function returns. I'm not very familiar with OpenCL, but if it behaves
anything like OpenGL and Vulkan, this kind of design essentially forces
blocking until the frame is finished processing and fully resident in
host RAM again, before the next frame can be started?

Generally when batch processing large amounts of images, it's better to
do asynchronous processing to avoid pipeline stalls. If the GPU is free
to resume work on the next image while the previous image is still in
the process of getting cleared from caches and DMA'd back into host
RAM, without having to stall for the transfer either way. Ideally,
PCIe bandwidth permitting, you want either the compute processors or the
DMA engine to be saturated. A blocking design permits neither.

I'm not entirely sure how that's done in OpenCL, if at all possible, but
normally it would revolve around using some kind of fence or signal
object to regularly poll in-flight frames and only emit them from the
filter once they're available. In general, this requires some kind of
filter API that allows ingesting and emitting frames at different times
- I'm sure this is possible with lavf somehow?

Correct me if I'm wrong,
Niklas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] make install prefix configurable

[Timo Rothenpieler]

Am 05.05.2018 um 17:28 schrieb Daniel Oberhoff:

---
  Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index a51c2c9..c3a9209 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,4 @@
-PREFIX = /usr/local
+PREFIX ?= /usr/local


This shouldn't be necessary, this and all the other variables around it 
can already be overridden just fine.




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] make install prefix configurable

[Daniel Oberhoff]

> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index a51c2c9..98d8b59 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,4 +1,4 @@
> -PREFIX = /usr/local
> +PREFIX = ${PREFIX:-/usr/local}

sorry, that was wrong, new patch coming




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

[FFmpeg-devel] [PATCH] make install prefix configurable

[Daniel Oberhoff]

---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index a51c2c9..c3a9209 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,4 @@
-PREFIX = /usr/local
+PREFIX ?= /usr/local
 LIBDIR = lib
 INSTALL = install
 SED = sed
-- 
2.14.3 (Apple Git-98)

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

[FFmpeg-devel] [PATCH] make install prefix configurable

[Daniel Oberhoff]

---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index a51c2c9..98d8b59 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,4 @@
-PREFIX = /usr/local
+PREFIX = ${PREFIX:-/usr/local}
 LIBDIR = lib
 INSTALL = install
 SED = sed
-- 
2.14.3 (Apple Git-98)

___
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/5/2018 5:33 AM, wm4 wrote:
> On Fri, 4 May 2018 21:51:38 -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.
> 
> Why don't you get it? We don't want to copy and then end up with
> unaligned shit.

Has this been a problem with Avisynth? And you're telling that to me,
who spent the past couple months dicking around with buffer references
to remove as many allocations and copies i could find. I'm all about
zero copy, but not when it means an ABI violation.

Back to the subject in question, you suggested a function to return
sizeof(AVFrame) at runtime. It could even be avpriv to prevent its usage
outside of libav*, so i guess that's a good solution to avoid having to
rewrite a bunch of modules.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/flac_parser: Fix infinite loop

[Michael Niedermayer]

On Fri, May 04, 2018 at 02:42:14AM +0200, Michael Niedermayer wrote:
> Fixes: crbug/827204
> 
> Reported-by: Frank Liberato 
> Reviewed-by: Frank Liberato 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/flac_parser.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)

will apply

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


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

Re: [FFmpeg-devel] [PATCH 2/3] swscale: add gray14 support

[Michael Niedermayer]

On Sat, May 05, 2018 at 03:43:49PM +0200, Michael Niedermayer wrote:
> On Thu, May 03, 2018 at 10:49:54PM +0200, Paul B Mahol wrote:
> > Signed-off-by: Paul B Mahol 
> > ---
> >  libavcodec/raw.c | 2 ++
> >  libavformat/nut.c| 3 +++
> >  libswscale/input.c   | 2 ++
> >  libswscale/swscale_unscaled.c| 1 +
> >  libswscale/utils.c   | 4 
> >  tests/ref/fate/filter-pixdesc-gray14be   | 1 +
> >  tests/ref/fate/filter-pixdesc-gray14le   | 1 +
> >  tests/ref/fate/filter-pixfmts-copy   | 2 ++
> >  tests/ref/fate/filter-pixfmts-crop   | 2 ++
> >  tests/ref/fate/filter-pixfmts-field  | 2 ++
> >  tests/ref/fate/filter-pixfmts-fieldorder | 2 ++
> >  tests/ref/fate/filter-pixfmts-hflip  | 2 ++
> >  tests/ref/fate/filter-pixfmts-il | 2 ++
> >  tests/ref/fate/filter-pixfmts-null   | 2 ++
> >  tests/ref/fate/filter-pixfmts-pad| 1 +
> >  tests/ref/fate/filter-pixfmts-scale  | 2 ++
> >  tests/ref/fate/filter-pixfmts-transpose  | 2 ++
> >  tests/ref/fate/filter-pixfmts-vflip  | 2 ++
> >  18 files changed, 35 insertions(+)
> >  create mode 100644 tests/ref/fate/filter-pixdesc-gray14be
> >  create mode 100644 tests/ref/fate/filter-pixdesc-gray14le
> 
> should be ok if you tested scaled and unscaled, ASM and C convert
> 
> thx

and fate needs an update for one of these patches, probably this one

thx

[...]

-- 
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 2/3] swscale: add gray14 support

[Michael Niedermayer]

On Thu, May 03, 2018 at 10:49:54PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/raw.c | 2 ++
>  libavformat/nut.c| 3 +++
>  libswscale/input.c   | 2 ++
>  libswscale/swscale_unscaled.c| 1 +
>  libswscale/utils.c   | 4 
>  tests/ref/fate/filter-pixdesc-gray14be   | 1 +
>  tests/ref/fate/filter-pixdesc-gray14le   | 1 +
>  tests/ref/fate/filter-pixfmts-copy   | 2 ++
>  tests/ref/fate/filter-pixfmts-crop   | 2 ++
>  tests/ref/fate/filter-pixfmts-field  | 2 ++
>  tests/ref/fate/filter-pixfmts-fieldorder | 2 ++
>  tests/ref/fate/filter-pixfmts-hflip  | 2 ++
>  tests/ref/fate/filter-pixfmts-il | 2 ++
>  tests/ref/fate/filter-pixfmts-null   | 2 ++
>  tests/ref/fate/filter-pixfmts-pad| 1 +
>  tests/ref/fate/filter-pixfmts-scale  | 2 ++
>  tests/ref/fate/filter-pixfmts-transpose  | 2 ++
>  tests/ref/fate/filter-pixfmts-vflip  | 2 ++
>  18 files changed, 35 insertions(+)
>  create mode 100644 tests/ref/fate/filter-pixdesc-gray14be
>  create mode 100644 tests/ref/fate/filter-pixdesc-gray14le

should be ok if you tested scaled and unscaled, ASM and C convert

thx

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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] avutil: add gray14 pixel format

[Michael Niedermayer]

On Thu, May 03, 2018 at 10:49:53PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavutil/pixdesc.c | 21 +
>  libavutil/pixfmt.h  |  4 
>  2 files changed, 25 insertions(+)

LGTM

thx

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

Never trust a computer, one day, it may think you are the virus. -- Compn


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

[FFmpeg-devel] [PATCH] avformat/segafilmenc - set keyframe bit correctly

[Gyan Doshi]

Since the muxer author hasn't made the change, the patch is submitted.

Reference:

http://www.ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228602.html
From 79f87ff264c2989193d5e59da8c5cf285940aa50 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Sat, 5 May 2018 17:04:53 +0530
Subject: [PATCH] avformat/segafilmenc - set keyframe bit correctly

As per
https://web.archive.org/web/20020803104640/http://www.pcisys.net:80/~melanson/codecs/film-format.txt,

the top bit of the info1 chunk is set as 1 for inter-coded frames and 0
otherwise.
---
 libavformat/segafilmenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
index 5b0d7e69e8..524230e461 100644
--- a/libavformat/segafilmenc.c
+++ b/libavformat/segafilmenc.c
@@ -69,7 +69,7 @@ static int film_write_packet_to_header(AVFormatContext 
*format_context, FILMPack
 info1 = pkt->pts;
 info2 = pkt->duration;
 /* The top bit being set indicates a key frame */
-if (pkt->keyframe)
+if (!pkt->keyframe)
 info1 |= (1 << 31);
 }
 
-- 
2.12.2.windows.2___
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]

Am 05.05.2018 um 02:00 schrieb 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


I was under the impression that the ones in DVB/mpegts work by ending 
one stream, and starting another one? So essentially spinning up an 
entire new de/encoder, and not by just changing the width/height in the 
AVCodecContext mid stream, hoping the encoder does something reasonable?


At least libx264.c does not check for width/height changes in its 
reconfigure function.




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] avformat: add vapoursynth wrapper

[Paul B Mahol]

On 5/5/18, wm4  wrote:
> On Fri, 4 May 2018 21:51:38 -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.
>
> Why don't you get it? We don't want to copy and then end up with
> unaligned shit.

The days of micro optimizations are passed?
___
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, 5 May 2018 02:35:52 +0200
Carl Eugen Hoyos  wrote:

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

Wow yet another passive aggressive attack against for no reason. I
think I'll just block all your mails so I have peace. Just because I
participate in this project it doesn't mean I have to tolerate your
obnoxious rudeness.
___
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 21:51:38 -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.

Why don't you get it? We don't want to copy and then end up with
unaligned shit.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel