Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

2017-11-15 Thread 刘歧

> 在 2017年11月15日,21:48,Dixit, Vishwanath  写道:
> 
> 
>> On 11/15/17, 9:56 AM, "刘歧"  wrote:
>>   all test info bellow:
>> 
>>   1st, look at the ffmpeg.exe banner 
>>   2nd, test with fate-filter-hls-append
>>   3nd, test with filter-hls-vs-with-master
>> 
>> 
>> /home/liuqi/ffmpeg/tests/fate-run.sh: 1: eval: ffmpeg.exe: not found
>>   make: *** [fate-filter-hls-vs-with-master] Error 1
>>   liuqi@localhost:~/ffmpeg/windows$
> 
> I have fixed the issue. Please find the updated patches in the attachment. 
> The following updates are made,
> 1. An additional FATE ‘run’ command was needed in the test to resolve 
> ‘ffmpeg.exe: not found’ issue.
> 2. Line splitter ‘\’ in make file was creating some sort of un-certainty in 
> test results between linux and windows. I have removed line splitter and have 
> made it a single line command. 
> 3. There are minor updates to resolve the compile time warnings.
> 
> <0001-avformat-hlsenc-creation-of-hls-variant-streams-in-a.patch><0002-avformat-hlsenc-creation-of-hls-master-playlist-file.patch><0003-tests-fate-addition-of-test-case-for-hls-variant-str.patch>___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

FATE test passed:  Ubuntu, OS X, qemu+MIPS Linux,  wine MingW, qemu+ARM Linux, 
Thanks.


> 0001-avformat-hlsenc-creation-of-hls-variant-streams-in-a.patch:

+static int format_name(char *name, int name_buf_len, int i)
+{
+char *p;
+char extension[10] = {'\0'};
+
+p = strrchr(name, '.');
+if (p) {
+strcpy(extension, p);
What about use av_strlcpy ?


+*p = '\0';
+}
+
+snprintf(name + strlen(name), name_buf_len - strlen(name), 
POSTFIX_PATTERN, i);
+
+if (strlen(extension))
+av_strlcat(name, extension, name_buf_len);
+
+return 0;
+}
+
+static int get_nth_codec_stream_index(AVFormatContext *s,
+  enum AVMediaType codec_type,
+  int stream_id)
+{
+unsigned int stream_index, cnt;
+if (stream_id < 0 || stream_id > s->nb_streams - 1)
+return -1;
+cnt = 0;
+for (stream_index = 0; stream_index < s->nb_streams; stream_index++) {
+if (s->streams[stream_index]->codecpar->codec_type != codec_type)
+continue;
+if (cnt == stream_id)
+return stream_index;
+cnt++;
+}
+return -1;
+}
+
+static int parse_variant_stream_mapstring(AVFormatContext *s)
+{
+HLSContext *hls = s->priv_data;
+VariantStream *vs;
+int stream_index;
+enum AVMediaType codec_type;
+int nb_varstreams, nb_streams;
+char *p, *q, *saveptr1, *saveptr2, *varstr, *keyval;
+const char *val;
+
+/**
+ * Expected format for var_stream_map string is as below:
+ * "a:0,v:0 a:1,v:1"
+ * This string specifies how to group the audio, video and subtitle streams
+ * into different variant streams. The variant stream groups are separated
+ * by space.
+ *
+ * a:, v:, s: are keys to specify audio, video and subtitle streams
+ * respectively. Allowed values are 0 to 9 digits (limited just based on
+ * practical usage)
+ *
+ */
+p = av_strdup(hls->var_stream_map);
+q = p;
+while(av_strtok(q, " \t", )) {
+q = NULL;
+hls->nb_varstreams++;
+}
+av_freep();
+
+hls->var_streams = av_mallocz(sizeof(*hls->var_streams) * 
hls->nb_varstreams);
+if (!hls->var_streams)
+return AVERROR(ENOMEM);
+
+p = hls->var_stream_map;
+nb_varstreams = 0;
+while (varstr = av_strtok(p, " \t", )) {
+p = NULL;
+
+if (nb_varstreams < hls->nb_varstreams)
+vs = &(hls->var_streams[nb_varstreams++]);
+else
+return -1;
+
+q = varstr;
+while (q < varstr + strlen(varstr)) {
+if (!strncmp(q, "a:", 2) || !strncmp(q, "v:", 2) ||
+!strncmp(q, "s:", 2))
What about use av_strcasecmp ?


+vs->nb_streams++;
+q++;
+}
+vs->streams = av_mallocz(sizeof(AVStream *) * vs->nb_streams);
+if (!vs->streams)
+return AVERROR(ENOMEM);
+
+nb_streams = 0;
+while (keyval = av_strtok(varstr, ",", )) {
+varstr = NULL;
+
+if (av_strstart(keyval, "v:", )) {
+codec_type = AVMEDIA_TYPE_VIDEO;
+} else if (av_strstart(keyval, "a:", )) {
+codec_type = AVMEDIA_TYPE_AUDIO;
+} else if (av_strstart(keyval, "s:", )) {
+codec_type = AVMEDIA_TYPE_SUBTITLE;
+} else {
+av_log(s, AV_LOG_ERROR, "Invalid keyval %s\n", keyval);
+return -1;
What about use return AVERROR(EINVAL)?


+}
+
+stream_index = -1;
+if (av_isdigit(*val))
+stream_index = get_nth_codec_stream_index (s, 

Re: [FFmpeg-devel] [PATCH 1/3] libavformat/avio: Utility function to return URLContext

2017-11-15 Thread Jeyapal, Karthick
>On 11/15/17, 6:34 PM, "Nicolas George"  wrote:

>This is rather fragile. Some kind of check that is is actually a real
>URLContext would be a very good idea.

Thanks for the feedback. I have a relevant condition check so that
only a real URLContext is returned.
Please find the new patch attached.

Regards,
Karthick

>Regards,
>
>-- 
>  Nicolas George




0001-libavformat-avio-Utility-function-to-return-URLConte.patch
Description: 0001-libavformat-avio-Utility-function-to-return-URLConte.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/proresdec: align dequantization matrix buffers

2017-11-15 Thread James Almer
On 11/16/2017 12:38 AM, Carl Eugen Hoyos wrote:
> 2017-11-16 3:51 GMT+01:00 James Almer :
> 
>> gcc -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-overflow
>> -fstack-protector-all -fPIE -c -o /tmp/ffconf.OTilhXct/test.o
>> /tmp/ffconf.OTilhXct/test.c
>> gcc -Wl,-z,relro -Wl,-z,now -fPIE -pie -o /tmp/ffconf.OTilhXct/test.exe
>> /tmp/ffconf.OTilhXct/test.o
>> F:/msys/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>> unrecognized option '-z'
>> F:/msys/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>> use the --help option for usage information
>> collect2.exe: error: ld returned 1 exit status
>> C compiler test failed.
>>
>> configure can't even succeed with --toolchain=hardened on mingw-w64
> 
> Would the following work at all?
> check_ldflags is not available yet at that point.
> 
> diff --git a/configure b/configure
> index f087ba6..828b018 100755
> --- a/configure
> +++ b/configure
> @@ -3860,6 +3860,13 @@ case "$toolchain" in
>  add_cflags   -fPIE
>  add_ldexeflags -fPIE -pie
>  ;;
> +hardened-mingw)
> +add_cppflags -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
> +add_cflags   -fno-strict-overflow -fstack-protector-all
> +add_ldflags  -fno-strict-overflow -fstack-protector-all
> +add_cflags   -fPIE
> +add_ldexeflags -fPIE -pie
> +;;
>  ?*)
>  die "Unknown toolchain $toolchain"
>  ;;

Yes, it works, but i can't seem to reproduce the crash with it.
I could however with -fstack-protector-all only.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/proresdec: align dequantization matrix buffers

2017-11-15 Thread Carl Eugen Hoyos
2017-11-16 3:51 GMT+01:00 James Almer :

> gcc -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-overflow
> -fstack-protector-all -fPIE -c -o /tmp/ffconf.OTilhXct/test.o
> /tmp/ffconf.OTilhXct/test.c
> gcc -Wl,-z,relro -Wl,-z,now -fPIE -pie -o /tmp/ffconf.OTilhXct/test.exe
> /tmp/ffconf.OTilhXct/test.o
> F:/msys/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> unrecognized option '-z'
> F:/msys/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> use the --help option for usage information
> collect2.exe: error: ld returned 1 exit status
> C compiler test failed.
>
> configure can't even succeed with --toolchain=hardened on mingw-w64

Would the following work at all?
check_ldflags is not available yet at that point.

diff --git a/configure b/configure
index f087ba6..828b018 100755
--- a/configure
+++ b/configure
@@ -3860,6 +3860,13 @@ case "$toolchain" in
 add_cflags   -fPIE
 add_ldexeflags -fPIE -pie
 ;;
+hardened-mingw)
+add_cppflags -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
+add_cflags   -fno-strict-overflow -fstack-protector-all
+add_ldflags  -fno-strict-overflow -fstack-protector-all
+add_cflags   -fPIE
+add_ldexeflags -fPIE -pie
+;;
 ?*)
 die "Unknown toolchain $toolchain"
 ;;



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


Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Check intra block dc differences.

2017-11-15 Thread Carl Eugen Hoyos
2017-11-16 4:06 GMT+01:00 Ronald S. Bultje :

> So, commit it without the error message? I really don't see the issue.

As explained, the issue is that without an error message, it
is impossible to parse any related bug report.

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


Re: [FFmpeg-devel] [PATCH] avcodec/proresdec: align dequantization matrix buffers

2017-11-15 Thread James Almer
On 11/16/2017 12:04 AM, James Almer wrote:
> On 11/15/2017 11:55 PM, Carl Eugen Hoyos wrote:
>> 2017-11-16 3:51 GMT+01:00 James Almer :
>>
>>> configure can't even succeed with --toolchain=hardened on mingw-w64, so
>>> looks like i wouldn't have been able to reproduce it to begin with.
>>
>> Try replacing toolchain with --extra-cflags=-fstack-protector-all:
>> $ configure --extra-cflags=-fstack-protector-all --enable-small --disable-avx
> 
> BEGIN /tmp/ffconf.pipZnMhH/test.c
> 1 int main(void){ return 0; }
> END /tmp/ffconf.pipZnMhH/test.c
> gcc -fstack-protector-all -c -o /tmp/ffconf.pipZnMhH/test.o
> /tmp/ffconf.pipZnMhH/test.c
> gcc -o /tmp/ffconf.pipZnMhH/test.exe /tmp/ffconf.pipZnMhH/test.o
> F:/msys/tmp/ffconf.pipZnMhH/test.o:test.c:(.text+0x33): undefined
> reference to `__stack_chk_fail'
> F:/msys/tmp/ffconf.pipZnMhH/test.o:test.c:(.rdata$.refptr.__stack_chk_guard[.refptr.__stack_chk_guard]+0x0):
> undefined reference to `__stack_chk_guard'
> collect2.exe: error: ld returned 1 exit status

Looks like adding --enable-ldflags=-fstack-protector-all to the above
command line makes it work.

> 
>>
>> Thank you for the useful info, I didn't know that hardened doesn't
>> work on Windows.
>>
>> Carl Eugen
>> ___
>> 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 1/2] avcodec/snowdec: Check intra block dc differences.

2017-11-15 Thread Ronald S. Bultje
Hi,

On Wed, Nov 15, 2017 at 7:02 PM, Michael Niedermayer  wrote:

> On Wed, Nov 15, 2017 at 03:26:42PM -0500, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Wed, Nov 15, 2017 at 3:17 PM, Michael Niedermayer
>  > > wrote:
> >
> > > Fixes: Timeout
> > > Fixes: 3142/clusterfuzz-testcase-5007853163118592
> > >
> > > Found-by: continuous fuzzing process https://github.com/google/oss-
> > > fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavcodec/snowdec.c | 19 +++
> > >  1 file changed, 15 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/libavcodec/snowdec.c b/libavcodec/snowdec.c
> > > index 727e908fb5..77ffe7f594 100644
> > > --- a/libavcodec/snowdec.c
> > > +++ b/libavcodec/snowdec.c
> > > @@ -183,13 +183,24 @@ static int decode_q_branch(SnowContext *s, int
> > > level, int x, int y){
> > >  int my_context= av_log2(2*FFABS(left->my - top->my)) +
> > > 0*av_log2(2*FFABS(tr->my - top->my));
> > >
> > >  type= get_rac(>c, >block_state[1 + left->type +
> top->type])
> > > ? BLOCK_INTRA : 0;
> > > -
> > >  if(type){
> > > +int ld, cbd, crd;
> > >  pred_mv(s, , , 0, left, top, tr);
> > > -l += get_symbol(>c, >block_state[32], 1);
> > > +ld = get_symbol(>c, >block_state[32], 1);
> > > +if (ld < -255 || ld > 255) {
> > > +av_log(s->avctx, AV_LOG_DEBUG, "Invalid (Out of range)
> > > intra luma block DC difference %d\n", ld);
> > > +return AVERROR_INVALIDDATA;
> > > +}
> > > +l += ld;
> > >  if (s->nb_planes > 2) {
> > > -cb+= get_symbol(>c, >block_state[64], 1);
> > > -cr+= get_symbol(>c, >block_state[96], 1);
> > > +cbd = get_symbol(>c, >block_state[64], 1);
> > > +crd = get_symbol(>c, >block_state[96], 1);
> > > +if (cbd < -255 || cbd > 255 || crd < -255 || crd >
> 255) {
> > > +av_log(s->avctx, AV_LOG_DEBUG, "Invalid (Out of
> > > range) intra chroma block DC difference %d, %d\n", cbd, crd);
> > > +return AVERROR_INVALIDDATA;
> > > +}
> >
> >
> > Please remove the error messages.
>
> We had this discussion multiple times already.
> I would prefer to keep an error message as its important in bug
> reporting and to maintain and debug this code which iam maintainer and
> author of.
>
> Some similar previous discussion for example:
> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216499.html
>
> To repeat from the thread above:
> "Iam happy to follow what the community prefers."
>
> It seems you dont want to poll the community
>
> Is your politly worded request meant litterally
> just as a suggestion (which i can ignore) ?
> or did you intend this to be a veto ?
> Which i would of course respect even though iam not sure you have veto
> power over maintainer and author.
>
> On top of that, this is part of a security fix for an issue that will
> be made (automatically) public soon.


So, commit it without the error message? I really don't see the issue. Is
the lack of error message the security issue?

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


Re: [FFmpeg-devel] [PATCH] avcodec/proresdec: align dequantization matrix buffers

2017-11-15 Thread James Almer
On 11/15/2017 11:55 PM, Carl Eugen Hoyos wrote:
> 2017-11-16 3:51 GMT+01:00 James Almer :
> 
>> configure can't even succeed with --toolchain=hardened on mingw-w64, so
>> looks like i wouldn't have been able to reproduce it to begin with.
> 
> Try replacing toolchain with --extra-cflags=-fstack-protector-all:
> $ configure --extra-cflags=-fstack-protector-all --enable-small --disable-avx

BEGIN /tmp/ffconf.pipZnMhH/test.c
1   int main(void){ return 0; }
END /tmp/ffconf.pipZnMhH/test.c
gcc -fstack-protector-all -c -o /tmp/ffconf.pipZnMhH/test.o
/tmp/ffconf.pipZnMhH/test.c
gcc -o /tmp/ffconf.pipZnMhH/test.exe /tmp/ffconf.pipZnMhH/test.o
F:/msys/tmp/ffconf.pipZnMhH/test.o:test.c:(.text+0x33): undefined
reference to `__stack_chk_fail'
F:/msys/tmp/ffconf.pipZnMhH/test.o:test.c:(.rdata$.refptr.__stack_chk_guard[.refptr.__stack_chk_guard]+0x0):
undefined reference to `__stack_chk_guard'
collect2.exe: error: ld returned 1 exit status

> 
> Thank you for the useful info, I didn't know that hardened doesn't
> work on Windows.
> 
> Carl Eugen
> ___
> 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] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

2017-11-15 Thread Michael Niedermayer
On Tue, Nov 14, 2017 at 05:55:33PM -0500, mmironov wrote:
> From 643006c4be514dd513232f7438b17add2a763685 Mon Sep 17 00:00:00 2001
> From: mmironov 
> Date: Tue, 14 Nov 2017 17:54:24 -0500
> Subject: [PATCH] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF
>  SDK
> 
> Signed-off-by: mmironov 
[...]

> +if (ret = ff_alloc_packet2(avctx, pkt, size, 0) < 0) {

missing ()


[...]
-- 
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: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/proresdec: align dequantization matrix buffers

2017-11-15 Thread Carl Eugen Hoyos
2017-11-16 3:51 GMT+01:00 James Almer :

> configure can't even succeed with --toolchain=hardened on mingw-w64, so
> looks like i wouldn't have been able to reproduce it to begin with.

Try replacing toolchain with --extra-cflags=-fstack-protector-all:
$ configure --extra-cflags=-fstack-protector-all --enable-small --disable-avx

Thank you for the useful info, I didn't know that hardened doesn't
work on Windows.

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


[FFmpeg-devel] [PATCH] avformat/hlsenc: checking return value of avio_open_dyn_buf

2017-11-15 Thread Steven Liu
fix CID: 1421196

Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index e0cef8b879..54342cf288 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1678,7 +1678,11 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 range_length = avio_close_dyn_buf(oc->pb, );
 avio_write(hls->out, buffer, range_length);
 hls->init_range_length = range_length;
-avio_open_dyn_buf(>pb);
+ret = avio_open_dyn_buf(>pb);
+if (ret < 0) {
+av_free(old_filename);
+return ret;
+}
 hls->packets_written = 0;
 ff_format_io_close(s, >out);
 } else {
-- 
2.11.0 (Apple Git-81)



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


Re: [FFmpeg-devel] [PATCH] avcodec/proresdec: align dequantization matrix buffers

2017-11-15 Thread James Almer
On 11/15/2017 11:01 PM, Carl Eugen Hoyos wrote:
> 2017-11-16 2:52 GMT+01:00 James Almer :
>> On 11/15/2017 10:35 PM, Carl Eugen Hoyos wrote:
>>> 2017-11-16 2:29 GMT+01:00 James Almer :
>>>
 The OP configure line is a massive dump of pointless
 "--disable" options typical from Gentoo builds,
>>>
>>> Good to know we agree on something.
>>>
 so i didn't even bother looking at it for specific things.
>>>
 And now that i look at yours they are completely different
 as well
>>>
>>> And I thought I spent several hours today only to allow you
>>> to reproduce a crash to ease testing by providing the
>>> necessary configure switches.
>>> They are of course identical to what the op provided, do
>>> you really suggest I added those stupidities for fun?
>>
>> Yours was "--enable-small --toolchain=hardened --disable-avx",
>> and only the latter is in the OP configure line. They didn't use
>> neither small or hardened.
> 
> So you are still saying that I added the options for fun?

No, i didn't say or even imply that. What i said is what's written in
that email: Since the two command lines seemed pretty different, then
perhaps said options were not related to the crash and it's a target
dependent issue.

Again, i didn't intend to offend you in any way whatsoever.

> (Thank you, as said it did take significantly more than
> an hour to find them.)
> 
> The op used an equivalent for both small and hardened in
> his configure line that imo is not supported by us, I found
> a supported configure line that has the same effect on
> config.mak and the resulting binary.
> 
> I knew that you were able to solve the riddle without
> the configure line but I still believe it makes sense
> for you to also being able to test a fix.
> 
> I do not understand why you wrote you cannot reproduce
> when you did not even try to.

Because at no point i assumed the configure line you or the OP used
could be needed to reproduce a crash like this. A wrong assumption in
retrospect, as STRIDE and av_malloc alignment can be affected by
configure options, and stack alignment (as it was the issue here) by
compiler options.
So since i was testing with a different OS than you two, i figured it
was pretty much target dependent and decided to send the patch stating
it was untested.

> Since the issue is not easily reproducible with clang, I
> still wonder if it is reproducible on Windows.

gcc -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-overflow
-fstack-protector-all -fPIE -c -o /tmp/ffconf.OTilhXct/test.o
/tmp/ffconf.OTilhXct/test.c
gcc -Wl,-z,relro -Wl,-z,now -fPIE -pie -o /tmp/ffconf.OTilhXct/test.exe
/tmp/ffconf.OTilhXct/test.o
F:/msys/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
unrecognized option '-z'
F:/msys/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
use the --help option for usage information
collect2.exe: error: ld returned 1 exit status
C compiler test failed.

configure can't even succeed with --toolchain=hardened on mingw-w64, so
looks like i wouldn't have been able to reproduce it to begin with.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v3 2/2] avformat/{http, tls}: enable tcp_nodelay

2017-11-15 Thread Aman Gupta
On Wed, Nov 15, 2017 at 2:35 AM, Jeyapal, Karthick 
wrote:

> >Hmm, I guess if we want this to propagate down we need to add the option
> to the tls protocol as well, then pass it down when it instantiates the tcp
> protocol. Then add the same option to hls/dash, and again propagate it
> >down to tls or tcp.
>
> >
>
> >This is turning into a much bigger change than I anticipated, and I don't
> really care enough about it to continue. If someone else wants to take over
> this patchset, they are more than welcome to it.
>
> >
>
> >Aman
>
>
>
> Well, I would suggest you could push the first tcp patch and leave the
> http/tls patch for somebody else to take it up later.
>

That's fair.

I've tested compiling the change on windows (w/ mingw), freebsd, linux and
macOS. I hope there are no other obscure supported platforms where
TCP_NODELAY might not be defined?

Aman


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


Re: [FFmpeg-devel] [PATCH v3 1/2] avcodec/mpeg12dec: parse A53 caption data embedded in SCTE-20 user data

2017-11-15 Thread Aman Gupta
On Tue, Nov 14, 2017 at 5:15 PM, Michael Niedermayer  wrote:

> On Tue, Nov 14, 2017 at 11:18:57AM -0800, Aman Gupta wrote:
> > From: Aman Gupta 
> >
> > Signed-off-by: Aman Gupta 
> > ---
> >  libavcodec/mpeg12dec.c   | 39 ++
> +
> >  tests/fate/subtitles.mak |  3 +++
> >  tests/ref/fate/sub-cc-scte20 | 15 +++
> >  3 files changed, 57 insertions(+)
> >  create mode 100644 tests/ref/fate/sub-cc-scte20
>
> probably ok
>

Confirmed FATE test is passing and applied to master.

Thanks for reviewing.

Aman


>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I am the wisest man alive, for I know one thing, and that is that I know
> nothing. -- Socrates
>
> ___
> 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] configure: use subarch instead of arch to create .def files on mingw

2017-11-15 Thread James Almer
arch is "x86" regardless of target being x86_32 or x86_64, and if
configuring with asm disabled it's "c" instead.
Using subarch (Always either "x86_32" or "x86_64") and adapting
makedef makes sure the symbols are always detected correctly on
x86_32.
---
 compat/windows/makedef | 2 +-
 configure  | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/compat/windows/makedef b/compat/windows/makedef
index 0cd169c15c..9e88611cc8 100755
--- a/compat/windows/makedef
+++ b/compat/windows/makedef
@@ -63,7 +63,7 @@ IFS='
 prefix=""
 if [ -n "$NM" ]; then
 case $ARCH in
-*86)
+x86_32)
 prefix="_"
 ;;
 *)
diff --git a/configure b/configure
index 934ac3abfd..4e7d7a8545 100755
--- a/configure
+++ b/configure
@@ -4971,7 +4971,7 @@ case $target_os in
 SLIB_INSTALL_LINKS=
 SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)'
 SLIB_INSTALL_EXTRA_LIB='lib$(SLIBNAME:$(SLIBSUF)=.dll.a) 
$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
-SLIB_CREATE_DEF_CMD='ARCH="$(ARCH)" AR="$(AR_CMD)" NM="$(NM_CMD)" 
$(SRC_PATH)/compat/windows/makedef $(SUBDIR)lib$(NAME).ver $(OBJS) > 
$$(@:$(SLIBSUF)=.def)'
+SLIB_CREATE_DEF_CMD='ARCH="$(SUBARCH)" AR="$(AR_CMD)" NM="$(NM_CMD)" 
$(SRC_PATH)/compat/windows/makedef $(SUBDIR)lib$(NAME).ver $(OBJS) > 
$$(@:$(SLIBSUF)=.def)'
 SHFLAGS='-shared 
-Wl,--out-implib,$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a) 
-Wl,--disable-auto-image-base $$(@:$(SLIBSUF)=.def)'
 enabled x86_64 && objformat="win64" || objformat="win32"
 ranlib=:
@@ -6779,6 +6779,7 @@ SRC_PATH:=\$(SRC_PATH:.%=..%)
 endif
 CC_IDENT=$cc_ident
 ARCH=$arch
+SUBARCH=$subarch
 INTRINSICS=$intrinsics
 CC=$cc
 CXX=$cxx
-- 
2.14.2

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


Re: [FFmpeg-devel] [PATCH] avcodec/proresdec: align dequantization matrix buffers

2017-11-15 Thread Carl Eugen Hoyos
2017-11-16 2:52 GMT+01:00 James Almer :
> On 11/15/2017 10:35 PM, Carl Eugen Hoyos wrote:
>> 2017-11-16 2:29 GMT+01:00 James Almer :
>>
>>> The OP configure line is a massive dump of pointless
>>> "--disable" options typical from Gentoo builds,
>>
>> Good to know we agree on something.
>>
>>> so i didn't even bother looking at it for specific things.
>>
>>> And now that i look at yours they are completely different
>>> as well
>>
>> And I thought I spent several hours today only to allow you
>> to reproduce a crash to ease testing by providing the
>> necessary configure switches.
>> They are of course identical to what the op provided, do
>> you really suggest I added those stupidities for fun?
>
> Yours was "--enable-small --toolchain=hardened --disable-avx",
> and only the latter is in the OP configure line. They didn't use
> neither small or hardened.

So you are still saying that I added the options for fun?
(Thank you, as said it did take significantly more than
an hour to find them.)

The op used an equivalent for both small and hardened in
his configure line that imo is not supported by us, I found
a supported configure line that has the same effect on
config.mak and the resulting binary.

I knew that you were able to solve the riddle without
the configure line but I still believe it makes sense
for you to also being able to test a fix.

I do not understand why you wrote you cannot reproduce
when you did not even try to.
Since the issue is not easily reproducible with clang, I
still wonder if it is reproducible on Windows.

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


Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mpeg12dec: avoid adding PANSCAN side data unless present

2017-11-15 Thread Michael Niedermayer
On Tue, Nov 14, 2017 at 08:38:51PM -0800, Aman Gupta wrote:
> On Tue, Nov 14, 2017 at 4:01 PM Michael Niedermayer 
> wrote:
> 
> > On Tue, Nov 14, 2017 at 10:04:02AM -0800, Aman Gupta wrote:
> > > From: Aman Gupta 
> > >
> > > ---
> > >  libavcodec/mpeg12dec.c | 20 ++--
> > >  1 file changed, 14 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
> > > index 82bb1286ff..2c96dfa638 100644
> > > --- a/libavcodec/mpeg12dec.c
> > > +++ b/libavcodec/mpeg12dec.c
> > > @@ -54,6 +54,7 @@ typedef struct Mpeg1Context {
> > >  int mpeg_enc_ctx_allocated; /* true if decoding context allocated */
> > >  int repeat_field;   /* true if we must repeat the field */
> > >  AVPanScan pan_scan; /* some temporary storage for the
> > panscan */
> > > +int has_pan_scan;
> > >  AVStereo3D stereo3d;
> > >  int has_stereo3d;
> > >  uint8_t *a53_caption;
> > > @@ -1458,6 +1459,7 @@ static void 
> > > mpeg_decode_sequence_display_extension(Mpeg1Context
> > *s1)
> > >
> > >  s1->pan_scan.width  = 16 * w;
> > >  s1->pan_scan.height = 16 * h;
> > > +s1->has_pan_scan = 1;
> > >
> > >  if (s->avctx->debug & FF_DEBUG_PICT_INFO)
> > >  av_log(s->avctx, AV_LOG_DEBUG, "sde w:%d, h:%d\n", w, h);
> > > @@ -1489,6 +1491,8 @@ static void 
> > > mpeg_decode_picture_display_extension(Mpeg1Context
> > *s1)
> > >  skip_bits(>gb, 1); // marker
> > >  }
> > >
> > > +s1->has_pan_scan = 1;
> > > +
> > >  if (s->avctx->debug & FF_DEBUG_PICT_INFO)
> > >  av_log(s->avctx, AV_LOG_DEBUG,
> > > "pde (%"PRId16",%"PRId16") (%"PRId16",%"PRId16")
> > (%"PRId16",%"PRId16")\n",
> > > @@ -1621,12 +1625,16 @@ static int mpeg_field_start(MpegEncContext *s,
> > const uint8_t *buf, int buf_size)
> > >  }
> > >  }
> > >
> > > -pan_scan = av_frame_new_side_data(s->current_picture_ptr->f,
> > > -  AV_FRAME_DATA_PANSCAN,
> > > -  sizeof(s1->pan_scan));
> > > -if (!pan_scan)
> > > -return AVERROR(ENOMEM);
> > > -memcpy(pan_scan->data, >pan_scan, sizeof(s1->pan_scan));
> > > +if (s1->has_pan_scan) {
> > > +pan_scan = av_frame_new_side_data(s->
> > current_picture_ptr->f,
> > > +AV_FRAME_DATA_PANSCAN,
> > > +sizeof(s1->pan_scan));
> > > +if (!pan_scan)
> > > +return AVERROR(ENOMEM);
> > > +
> > > +memcpy(pan_scan->data, >pan_scan, sizeof(s1->pan_scan));
> > > +s1->has_pan_scan = 0;
> >
> > the mpeg2 spec says:
> > "In   the   casethatagivenpicturedoesnothave
> >   a
> >  picture_display_extension() then the  most  recently  decoded  frame
> > centre
> >  offset shall be used."
> >
> > "Following a sequence_header() the value zero shall be  used  for  all
> > frame
> >  centre offsets until a picture_display_extension() defines non-zero
> > values."
> >
> > I dont think its a good idea to ommit the "most  recently  decoded
> > frame  centre" on the subset of AVFrames which do not explicitly store
> > it. That would make it hard for applications which want to access this,
> > an application would have to keep track of the last one as well as
> > where sequence headers occured
> 
> 
> Sorry, my mistake.
> 
> Would the patch make sense if I removed the "has_pan_scan = 0" reset? Or is

i think so, yes

> it better just to always include PANSCAN side data to make it easier for
> API consumers.
> 
> Aman

[...]
-- 
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: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [Patch] Download dash content with byte range info

2017-11-15 Thread Michael Niedermayer
On Thu, Nov 16, 2017 at 12:59:51AM +, Colin NG wrote:
> Made change suggested by Carl and add some minor fixes.

please submit git patches so they can be applied automatically
(git format-patch  / send-email)

while technically this can be applied, it cant in practice as the
whole email ends in the commit message

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.


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


Re: [FFmpeg-devel] [PATCH] avfoundation, unsupported framerate/activeVideoMinFrameDuration

2017-11-15 Thread Michael Niedermayer
On Wed, Nov 15, 2017 at 02:49:40AM +, Roman Puttkammer wrote:
> Hi,
> 
> Attached patch fixes an issue with avfoundation; the code continues to
> loop through
> the list of
> supported formats/framerates even after finding the chosen one, ending up
> with a bad format/rate
> combination. (Code breaks out of one loop only instead of two.)
> 
> rgds,
> Roman
> 
> -
> diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
> index e2ddf47dbe..463ae60b63 100644
> --- a/libavdevice/avfoundation.m
> +++ b/libavdevice/avfoundation.m
> @@ -312,6 +312,7 @@ static int configure_video_device(AVFormatContext *s,
> AVCaptureDevice *video_dev
>  }

Applying: avfoundation, unsupported framerate/activeVideoMinFrameDuration
error: corrupt patch at line 6

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

There will always be a question for which you do not know the correct answer.


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


Re: [FFmpeg-devel] [PATCH] avcodec/proresdec: align dequantization matrix buffers

2017-11-15 Thread James Almer
On 11/15/2017 10:35 PM, Carl Eugen Hoyos wrote:
> 2017-11-16 2:29 GMT+01:00 James Almer :
> 
>> The OP configure line is a massive dump of pointless
>> "--disable" options typical from Gentoo builds,
> 
> Good to know we agree on something.
> 
>> so i didn't even bother looking at it for specific things.
> 
>> And now that i look at yours they are completely different
>> as well
> 
> And I thought I spent several hours today only to allow you
> to reproduce a crash to ease testing by providing the
> necessary configure switches.
> They are of course identical to what the op provided, do
> you really suggest I added those stupidities for fun?

Yours was "--enable-small --toolchain=hardened --disable-avx", and only
the latter is in the OP configure line. They didn't use neither small or
hardened.

At no point i tried to offend you in any way. I did not care about the
configure line from OP as it was a mess, and did not even get to look at
yours since after checking what you reported as the first bad commit
(Making proresdec2 use the other decoder's DSP) it was clear to me that
said commit did not bother making sure the buffers were aligned for simd
optimizations, even if i couldn't reproduce it.

Sorry for any misunderstanding.

> 
>> so perhaps it doesn't depend on configure options but
>> something else, like target.
> 
> Yes, the issue is only reproducible on x86-64.
> 
> Carl Eugen
> ___
> 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] Download dash content with byte range info

2017-11-15 Thread Steven Liu
s/get_Fragment/get_fragment_range/g

Maybe better





> 在 2017年11月16日,上午8:59,Colin NG  写道:
> 
> Made change suggested by Carl and add some minor fixes.
> 
> 
> 
> From: ffmpeg-devel  on behalf of Carl Eugen 
> Hoyos 
> Sent: November 15, 2017 5:37 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [Patch] Download dash content with byte range info
> 
> 2017-11-15 22:00 GMT+01:00 Colin NG :
>> This patch is partial fix for ticket 6658 (Dash demuxer segfault).
> 
>> +static struct fragment * get_Fragment(char *range) {
>> +struct fragment * seg =  av_mallocz(sizeof(struct fragment));
> 
> Please make it (code-style):
> ... fragment *get_Fragment...
> ... fragment *seg =...
> 
>> +if (!seg)
>> +goto finish;
> 
> No.
> 
> You can "return NULL;" but since this is a little misleading,
> it may be better to return AVERROR(ENOMEM) and instead
> of the existing check for NULL below, check for "< 0".
> 
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> ffmpeg-devel Info Page
> ffmpeg.org
> This list is about FFmpeg development discussions and patches; but not for 
> bug-reports. Please read the Code-of-conduct. To see the collection of prior 
> postings to ...
> 
> 
> 
> 
> ___
> 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] [DEVEL][PATCH v3] ffmpeg: fix channel_layout bug on non-default layout

2017-11-15 Thread Michael Niedermayer
On Tue, Nov 14, 2017 at 11:49:26PM +0100, pkv.stream wrote:
> Le 14/11/2017 à 1:13 PM, Michael Niedermayer a écrit :
> >On Sun, Nov 12, 2017 at 06:26:18PM +0100, pkv.stream wrote:
> >>Le 12/11/2017 à 5:38 PM, Michael Niedermayer a écrit :
> >>>On Sun, Nov 12, 2017 at 05:07:04PM +0100, Kv Pham wrote:
> Le 12 nov. 2017 5:01 PM, "Michael Niedermayer"  a
> écrit :
> 
> On Sat, Nov 11, 2017 at 02:15:25AM +0100, pkv.stream wrote:
> >Le 11/11/2017 à 1:07 AM, Michael Niedermayer a écrit :
> >>On Fri, Nov 10, 2017 at 10:27:48PM +0100, pkv.stream wrote:
> >>>Le 10/11/2017 à 1:12 AM, Michael Niedermayer a écrit :
> On Thu, Nov 09, 2017 at 09:37:33PM +0100, pkv.stream wrote:
> >Hi Michael,
> >
> >>>  ffmpeg_opt.c |   11 ++-
> >>>  1 file changed, 10 insertions(+), 1 deletion(-)
> >>>2af07f4366efdfaf1018bb2ea29be672befe0823  0001-ffmpeg-fix-channel_
> layout-bug-on-non-default-layout.patch
> >>> From 4ec55dc88923108132307b41300a1abddf32e6f7 Mon Sep 17 00:00:00
> 2001
> >>>From: pkviet
> >>>Date: Mon, 2 Oct 2017 11:14:31 +0200
> >>>Subject: [PATCH] ffmpeg: fix channel_layout bug on non-default
> layout
> >>>Fix for ticket 6706.
> >>>The -channel_layout option was not working when the channel layout
> was not
> >>>a default one (ex: for 4 channels, quad was interpreted as 4.0
> which is
> >>>the default layout for 4 channels; or octagonal interpreted as 
> >>>7.1).
> >>>This led to the spurious auto-insertion of an auto-resampler filter
> >>>remapping the channels even if input and output had identical
> channel
> >>>layouts.
> >>>The fix operates by directly calling the channel layout if defined
> in
> >>>options. If the layout is undefined, the default layout is selected
> as
> >>>before the fix.
> >>>---
> >>>  ffmpeg_opt.c | 11 ++-
> >>>  1 file changed, 10 insertions(+), 1 deletion(-)
> >>>
> >>>diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
> >>>index 100fa76..cf5a63c 100644
> >>>--- a/ffmpeg_opt.c
> >>>+++ b/ffmpeg_opt.c
> >>>@@ -1804,6 +1804,12 @@ static OutputStream 
> >>>*new_audio_stream(OptionsContext
> *o, AVFormatContext *oc, in
> >>>  MATCH_PER_STREAM_OPT(audio_channels, i,
> audio_enc->channels, oc, st);
> >>>+AVDictionaryEntry *output_layout =
> av_dict_get(o->g->codec_opts,
> >>>+
>   "channel_layout",
> >>>+   NULL,
> AV_DICT_MATCH_CASE);
> >>This doesnt look right
> >>
> >>not an issue of the patch as such but
> >>why is the channel_layout option per file and not per stream?
> >just my ignorance; do you mean this is not the right way to retrieve
> >the channel_layout option from an audio stream ?
> I think there is more buggy with how the channel_layout is handled
> 
> try this:
> ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -channel_layout 5 test.wav
> and this:
> ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -channel_layout:a 5 
> test.wav
> 
> while it may appear that the are both working this is deceiving.
> I think only the channel number gets actually used in the 2nd case
> 
> Look at what your code with av_dict_get() reads.
> It does not obtain the 5 in the 2nd case
> >>>ok I fixed that by using the flag AV_DICT_IGNORE_SUFFIX ; now
> >>>-channel_layout:a works as expected.
> >>>I fixed also all the styling issues you spotted (mixed declarations,
> >>>{} for if etc).
> >>>
> >>>Still not understanding your initial comment though :
> >>>'why is the channel_layout option per file and not per stream?'
> >>>
> >>>do you mean o->g->codec_opts is not where I should retrieve the
> >>>channel_layout ? if not where from ?
> >>>
> >>>Thanks
> >>>
> [...]
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>>  ffmpeg_opt.c |   12 ++--
> >>>  1 file changed, 10 insertions(+), 2 deletions(-)
> >>>849898d28e989ffa5cc598c6fe4d43847b636132  0001-ffmpeg-fix-channel_
> layout-bug-on-non-default-layout.patch
> >>> From 6d4f1c14135f9473b77e1c649d0e7bbaeba00a50 Mon Sep 17 00:00:00 2001
> >>>From: pkviet
> >>>Date: Mon, 2 Oct 2017 11:14:31 +0200
> >>>Subject: [PATCH] ffmpeg: fix channel_layout bug on non-default layout
> >>>
> >>>Fix for ticket 6706.
> >>>The -channel_layout option was not working when the 

Re: [FFmpeg-devel] [PATCH] libavcodec/videotoolbox: fix decoding of h264 streams with minor SPS changes

2017-11-15 Thread Aman Gupta
On Wed, Nov 15, 2017 at 1:57 PM, Hendrik Leppkes 
wrote:

> On Wed, Nov 15, 2017 at 10:15 PM, Aman Gupta  wrote:
> > From: Aman Gupta 
> >
> > Previously the codec kept an entire copy of the SPS, and restarted the
> VT decoder
> > session whenever it changed. This fixed decoding errors in [1], as
> > described in 9519983c. On further inspection, that sample features an
> SPS change
> > from High/4.0 to High/3.2 while moving from one scene to another.
> >
> > Yesterday I received [2], which contains minor SPS changes where the
> > profile and level do not change. These occur frequently and are not
> associated with
> > scene changes. After 9519983c, the VT decoder session is recreated
> unnecessarily when
> > these are encountered causing visual glitches.
> >
> > This commit simplifies the state kept in the VTContext to include just
> the first three
> > bytes of the SPS, containing the profile and level details. This is
> populated initially
> > when the VT decoder session is created, and used to detect changes and
> force a restart.
> >
> > This means minor SPS changes are fed directly into the existing decoder,
> whereas
> > profile/level changes force the decoder session to be recreated with the
> new parameters.
> >
>
> The profile and level are not exactly the only things that can change
> to force a decoder to be re-created.
> How about the frame dimensions, within the same level?
>

If you know somewhere I can find such a sample, I can try it with
VideoToolbox to see if it requires the session to be recreated or not.

Aman


>
> - Hendrik
> ___
> 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] avcodec/proresdec: align dequantization matrix buffers

2017-11-15 Thread Carl Eugen Hoyos
2017-11-16 2:29 GMT+01:00 James Almer :

> The OP configure line is a massive dump of pointless
> "--disable" options typical from Gentoo builds,

Good to know we agree on something.

> so i didn't even bother looking at it for specific things.

> And now that i look at yours they are completely different
> as well

And I thought I spent several hours today only to allow you
to reproduce a crash to ease testing by providing the
necessary configure switches.
They are of course identical to what the op provided, do
you really suggest I added those stupidities for fun?

> so perhaps it doesn't depend on configure options but
> something else, like target.

Yes, the issue is only reproducible on x86-64.

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


Re: [FFmpeg-devel] [PATCH] avcodec/proresdec: align dequantization matrix buffers

2017-11-15 Thread James Almer
On 11/15/2017 9:50 PM, Carl Eugen Hoyos wrote:
> 2017-11-16 1:49 GMT+01:00 James Almer :
>> On 11/15/2017 9:33 PM, Carl Eugen Hoyos wrote:
>>> 2017-11-16 1:29 GMT+01:00 James Almer :
 On 11/15/2017 9:21 PM, Carl Eugen Hoyos wrote:
> 2017-11-16 1:14 GMT+01:00 James Almer :
>> Should fix ticket #6838
>
>> Untested as i can't reproduce.
>
> What did you try?

 GCC 7.2.0 mingw-w64 x86_64. The buffers were sufficiently
 aligned every time i decoded the file without this patch.
>>>
>>> It crashes here for many gcc binaries since gcc-4.
>>> What exact configure line did you test?
>>
>> --enable-gpl --extra-cflags='-D_WIN32_WINNT=0x0602' --prefix=/mingw64
> 
> So you did not try the compilation flags used by me or the OP?
> 
> Carl Eugen

I think it's clear i didn't.

The OP configure line is a massive dump of pointless "--disable" options
typical from Gentoo builds, so i didn't even bother looking at it for
specific things. And now that i look at yours they are completely
different as well, so perhaps it doesn't depend on configure options but
something else, like target.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Check size of STSC allocation

2017-11-15 Thread Fredrik Hubinette
Fixed indentation.


On Wed, Nov 15, 2017 at 3:40 PM, Carl Eugen Hoyos 
wrote:

> 2017-11-16 0:21 GMT+01:00 Fredrik Hubinette  org>:
> > This patch checks that the memory allocated for stsc entries isn't larger
> > than the atom.
>
> Consider fixing the indentation of the second added line,
> making the committer's life easier.
>
> Thank you, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
From 13afb2b1a5d135b6aed55b910a4146da972a6e01 Mon Sep 17 00:00:00 2001
From: Fredrik Hubinette 
Date: Wed, 15 Nov 2017 17:24:30 -0800
Subject: [PATCH] Check size of STSC allocation

---
 libavformat/mov.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7d1bd9950a..46862512ac 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2618,6 +2618,8 @@ static int mov_read_stsc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 avio_rb24(pb); /* flags */
 
 entries = avio_rb32(pb);
+if ((uint64_t)entries * 12 + 4 > atom.size)
+return AVERROR_INVALIDDATA;
 
 av_log(c->fc, AV_LOG_TRACE, "track[%u].stsc.entries = %u\n", c->fc->nb_streams - 1, entries);
 
-- 
2.15.0.448.gf294e3d99a-goog

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


Re: [FFmpeg-devel] [Patch] Download dash content with byte range info

2017-11-15 Thread Colin NG
Made change suggested by Carl and add some minor fixes.



From: ffmpeg-devel  on behalf of Carl Eugen 
Hoyos 
Sent: November 15, 2017 5:37 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [Patch] Download dash content with byte range info

2017-11-15 22:00 GMT+01:00 Colin NG :
> This patch is partial fix for ticket 6658 (Dash demuxer segfault).

> +static struct fragment * get_Fragment(char *range) {
> +struct fragment * seg =  av_mallocz(sizeof(struct fragment));

Please make it (code-style):
... fragment *get_Fragment...
... fragment *seg =...

> +if (!seg)
> +goto finish;

No.

You can "return NULL;" but since this is a little misleading,
it may be better to return AVERROR(ENOMEM) and instead
of the existing check for NULL below, check for "< 0".

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
ffmpeg-devel Info Page
ffmpeg.org
This list is about FFmpeg development discussions and patches; but not for 
bug-reports. Please read the Code-of-conduct. To see the collection of prior 
postings to ...


diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 0e3afd2..33255f2 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -522,6 +522,22 @@ static enum AVMediaType get_content_type(xmlNodePtr node)
 return type;
 }
 
+static struct fragment * get_Fragment(char *range) {
+struct fragment * seg = av_mallocz(sizeof(struct fragment));
+
+if (!seg)
+return NULL;
+
+seg->size = -1;
+if (range)  {
+char *str_end_offset;
+char *str_offset = av_strtok(range, "-", _end_offset);
+seg->url_offset = strtoll(str_offset, NULL, 10);
+seg->size = strtoll(str_end_offset, NULL, 10) -seg->url_offset+1;
+}
+return seg;
+}
+
 static int parse_manifest_segmenturlnode(AVFormatContext *s, struct 
representation *rep,
  xmlNodePtr fragmenturl_node,
  xmlNodePtr *baseurl_nodes,
@@ -530,11 +546,13 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
*s, struct representati
 {
 char *initialization_val = NULL;
 char *media_val = NULL;
+char *range_val = NULL;
 
 if (!av_strcasecmp(fragmenturl_node->name, (const char 
*)"Initialization")) {
 initialization_val = xmlGetProp(fragmenturl_node, "sourceURL");
-if (initialization_val) {
-rep->init_section = av_mallocz(sizeof(struct fragment));
+range_val = xmlGetProp(fragmenturl_node, "range");
+if (initialization_val || range_val) {
+rep->init_section = get_Fragment(range_val);
 if (!rep->init_section) {
 xmlFree(initialization_val);
 return AVERROR(ENOMEM);
@@ -548,13 +566,14 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
*s, struct representati
 xmlFree(initialization_val);
 return AVERROR(ENOMEM);
 }
-rep->init_section->size = -1;
 xmlFree(initialization_val);
+xmlFree(range_val);
 }
 } else if (!av_strcasecmp(fragmenturl_node->name, (const char 
*)"SegmentURL")) {
 media_val = xmlGetProp(fragmenturl_node, "media");
-if (media_val) {
-struct fragment *seg = av_mallocz(sizeof(struct fragment));
+range_val = xmlGetProp(fragmenturl_node, "mediaRange");
+if (media_val || range_val) {
+struct fragment *seg =  get_Fragment(range_val);
 if (!seg) {
 xmlFree(media_val);
 return AVERROR(ENOMEM);
@@ -568,15 +587,14 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
*s, struct representati
 xmlFree(media_val);
 return AVERROR(ENOMEM);
 }
-seg->size = -1;
 dynarray_add(>fragments, >n_fragments, seg);
 xmlFree(media_val);
+xmlFree(range_val);
 }
 }
 
 return 0;
 }
-
 static int parse_manifest_segmenttimeline(AVFormatContext *s, struct 
representation *rep,
   xmlNodePtr fragment_timeline_node)
 {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/proresdec: align dequantization matrix buffers

2017-11-15 Thread Carl Eugen Hoyos
2017-11-16 1:49 GMT+01:00 James Almer :
> On 11/15/2017 9:33 PM, Carl Eugen Hoyos wrote:
>> 2017-11-16 1:29 GMT+01:00 James Almer :
>>> On 11/15/2017 9:21 PM, Carl Eugen Hoyos wrote:
 2017-11-16 1:14 GMT+01:00 James Almer :
> Should fix ticket #6838

> Untested as i can't reproduce.

 What did you try?
>>>
>>> GCC 7.2.0 mingw-w64 x86_64. The buffers were sufficiently
>>> aligned every time i decoded the file without this patch.
>>
>> It crashes here for many gcc binaries since gcc-4.
>> What exact configure line did you test?
>
> --enable-gpl --extra-cflags='-D_WIN32_WINNT=0x0602' --prefix=/mingw64

So you did not try the compilation flags used by me or the OP?

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


Re: [FFmpeg-devel] [PATCH] avcodec/proresdec: align dequantization matrix buffers

2017-11-15 Thread James Almer
On 11/15/2017 9:33 PM, Carl Eugen Hoyos wrote:
> 2017-11-16 1:29 GMT+01:00 James Almer :
>> On 11/15/2017 9:21 PM, Carl Eugen Hoyos wrote:
>>> 2017-11-16 1:14 GMT+01:00 James Almer :
 Should fix ticket #6838
>>>
 Untested as i can't reproduce.
>>>
>>> What did you try?
>>
>> GCC 7.2.0 mingw-w64 x86_64. The buffers were sufficiently
>> aligned every time i decoded the file without this patch.
> 
> It crashes here for many gcc binaries since gcc-4.
> What exact configure line did you test?

--enable-gpl --extra-cflags='-D_WIN32_WINNT=0x0602' --prefix=/mingw64

Using the MSYS2 packages (both gcc and mingw-w64), so pretty much a
vanilla build.

> 
> Carl Eugen
> ___
> 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] avcodec/proresdec: align dequantization matrix buffers

2017-11-15 Thread Carl Eugen Hoyos
2017-11-16 1:29 GMT+01:00 James Almer :
> On 11/15/2017 9:21 PM, Carl Eugen Hoyos wrote:
>> 2017-11-16 1:14 GMT+01:00 James Almer :
>>> Should fix ticket #6838
>>
>>> Untested as i can't reproduce.
>>
>> What did you try?
>
> GCC 7.2.0 mingw-w64 x86_64. The buffers were sufficiently
> aligned every time i decoded the file without this patch.

It crashes here for many gcc binaries since gcc-4.
What exact configure line did you test?

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


Re: [FFmpeg-devel] [PATCH] avcodec/proresdec: align dequantization matrix buffers

2017-11-15 Thread James Almer
On 11/15/2017 9:21 PM, Carl Eugen Hoyos wrote:
> 2017-11-16 1:14 GMT+01:00 James Almer :
>> Should fix ticket #6838
> 
>> Untested as i can't reproduce.
> 
> What did you try?

GCC 7.2.0 mingw-w64 x86_64. The buffers were sufficiently aligned every
time i decoded the file without this patch.

> 
> Thank you!
> 
> Carl Eugen

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


Re: [FFmpeg-devel] [PATCH] avcodec/proresdec: align dequantization matrix buffers

2017-11-15 Thread Carl Eugen Hoyos
2017-11-16 1:14 GMT+01:00 James Almer :
> Should fix ticket #6838

> Untested as i can't reproduce.

What did you try?

Thank you!

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


[FFmpeg-devel] [PATCH] avcodec/proresdec: align dequantization matrix buffers

2017-11-15 Thread James Almer
Should fix ticket #6838

Signed-off-by: James Almer 
---
Untested as i can't reproduce.

 libavcodec/proresdec2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index e9e0153ee9..d97e264e44 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -517,8 +517,8 @@ static int decode_slice_thread(AVCodecContext *avctx, void 
*arg, int jobnr, int
 int luma_stride, chroma_stride;
 int y_data_size, u_data_size, v_data_size, a_data_size;
 uint8_t *dest_y, *dest_u, *dest_v, *dest_a;
-int16_t qmat_luma_scaled[64];
-int16_t qmat_chroma_scaled[64];
+LOCAL_ALIGNED_16(int16_t, qmat_luma_scaled,  [64]);
+LOCAL_ALIGNED_16(int16_t, qmat_chroma_scaled,[64]);
 int mb_x_shift;
 int ret;
 
-- 
2.14.2

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


Re: [FFmpeg-devel] FFmpeg 3.4.1

2017-11-15 Thread Carl Eugen Hoyos
2017-11-15 13:34 GMT+01:00 Michael Niedermayer :
> Hi all
>
> I intend to make 3.4.1 very soon

Shouldn't we first decide on how to proceed with #6775?

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


Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Check intra block dc differences.

2017-11-15 Thread Michael Niedermayer
On Wed, Nov 15, 2017 at 03:26:42PM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Nov 15, 2017 at 3:17 PM, Michael Niedermayer  > wrote:
> 
> > Fixes: Timeout
> > Fixes: 3142/clusterfuzz-testcase-5007853163118592
> >
> > Found-by: continuous fuzzing process https://github.com/google/oss-
> > fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/snowdec.c | 19 +++
> >  1 file changed, 15 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/snowdec.c b/libavcodec/snowdec.c
> > index 727e908fb5..77ffe7f594 100644
> > --- a/libavcodec/snowdec.c
> > +++ b/libavcodec/snowdec.c
> > @@ -183,13 +183,24 @@ static int decode_q_branch(SnowContext *s, int
> > level, int x, int y){
> >  int my_context= av_log2(2*FFABS(left->my - top->my)) +
> > 0*av_log2(2*FFABS(tr->my - top->my));
> >
> >  type= get_rac(>c, >block_state[1 + left->type + top->type])
> > ? BLOCK_INTRA : 0;
> > -
> >  if(type){
> > +int ld, cbd, crd;
> >  pred_mv(s, , , 0, left, top, tr);
> > -l += get_symbol(>c, >block_state[32], 1);
> > +ld = get_symbol(>c, >block_state[32], 1);
> > +if (ld < -255 || ld > 255) {
> > +av_log(s->avctx, AV_LOG_DEBUG, "Invalid (Out of range)
> > intra luma block DC difference %d\n", ld);
> > +return AVERROR_INVALIDDATA;
> > +}
> > +l += ld;
> >  if (s->nb_planes > 2) {
> > -cb+= get_symbol(>c, >block_state[64], 1);
> > -cr+= get_symbol(>c, >block_state[96], 1);
> > +cbd = get_symbol(>c, >block_state[64], 1);
> > +crd = get_symbol(>c, >block_state[96], 1);
> > +if (cbd < -255 || cbd > 255 || crd < -255 || crd > 255) {
> > +av_log(s->avctx, AV_LOG_DEBUG, "Invalid (Out of
> > range) intra chroma block DC difference %d, %d\n", cbd, crd);
> > +return AVERROR_INVALIDDATA;
> > +}
> 
> 
> Please remove the error messages.

We had this discussion multiple times already.
I would prefer to keep an error message as its important in bug
reporting and to maintain and debug this code which iam maintainer and
author of.

Some similar previous discussion for example:
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216499.html

To repeat from the thread above:
"Iam happy to follow what the community prefers."

It seems you dont want to poll the community

Is your politly worded request meant litterally
just as a suggestion (which i can ignore) ?
or did you intend this to be a veto ?
Which i would of course respect even though iam not sure you have veto
power over maintainer and author.

On top of that, this is part of a security fix for an issue that will
be made (automatically) public soon.


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

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


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


Re: [FFmpeg-devel] Check size of STSC allocation

2017-11-15 Thread Carl Eugen Hoyos
2017-11-16 0:21 GMT+01:00 Fredrik Hubinette :
> This patch checks that the memory allocated for stsc entries isn't larger
> than the atom.

Consider fixing the indentation of the second added line,
making the committer's life easier.

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


[FFmpeg-devel] Check size of STSC allocation

2017-11-15 Thread Fredrik Hubinette
This patch checks that the memory allocated for stsc entries isn't larger
than the atom.
Without this, corrupt data can easily try to allocate all the memory,
causing a crash.
From e79de93ea8426985d63a2369e8274ceaf296ba2d Mon Sep 17 00:00:00 2001
From: Fredrik Hubinette 
Date: Wed, 15 Nov 2017 15:19:15 -0800
Subject: [PATCH] Check size of STSC allocation

---
 libavformat/mov.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7d1bd9950a..b44a777193 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2618,6 +2618,8 @@ static int mov_read_stsc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 avio_rb24(pb); /* flags */
 
 entries = avio_rb32(pb);
+if ((uint64_t)entries * 12 + 4 > atom.size)
+  return AVERROR_INVALIDDATA;
 
 av_log(c->fc, AV_LOG_TRACE, "track[%u].stsc.entries = %u\n", c->fc->nb_streams - 1, entries);
 
-- 
2.15.0.448.gf294e3d99a-goog

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


Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Check intra block dc differences.

2017-11-15 Thread Carl Eugen Hoyos
2017-11-15 21:26 GMT+01:00 Ronald S. Bultje :
> Hi,
>
> On Wed, Nov 15, 2017 at 3:17 PM, Michael Niedermayer > wrote:
>
>> Fixes: Timeout
>> Fixes: 3142/clusterfuzz-testcase-5007853163118592
>>
>> Found-by: continuous fuzzing process https://github.com/google/oss-
>> fuzz/tree/master/projects/ffmpeg
>> Signed-off-by: Michael Niedermayer 
>> ---
>>  libavcodec/snowdec.c | 19 +++
>>  1 file changed, 15 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavcodec/snowdec.c b/libavcodec/snowdec.c
>> index 727e908fb5..77ffe7f594 100644
>> --- a/libavcodec/snowdec.c
>> +++ b/libavcodec/snowdec.c
>> @@ -183,13 +183,24 @@ static int decode_q_branch(SnowContext *s, int
>> level, int x, int y){
>>  int my_context= av_log2(2*FFABS(left->my - top->my)) +
>> 0*av_log2(2*FFABS(tr->my - top->my));
>>
>>  type= get_rac(>c, >block_state[1 + left->type + top->type])
>> ? BLOCK_INTRA : 0;
>> -
>>  if(type){
>> +int ld, cbd, crd;
>>  pred_mv(s, , , 0, left, top, tr);
>> -l += get_symbol(>c, >block_state[32], 1);
>> +ld = get_symbol(>c, >block_state[32], 1);
>> +if (ld < -255 || ld > 255) {
>> +av_log(s->avctx, AV_LOG_DEBUG, "Invalid (Out of range)
>> intra luma block DC difference %d\n", ld);
>> +return AVERROR_INVALIDDATA;
>> +}
>> +l += ld;
>>  if (s->nb_planes > 2) {
>> -cb+= get_symbol(>c, >block_state[64], 1);
>> -cr+= get_symbol(>c, >block_state[96], 1);
>> +cbd = get_symbol(>c, >block_state[64], 1);
>> +crd = get_symbol(>c, >block_state[96], 1);
>> +if (cbd < -255 || cbd > 255 || crd < -255 || crd > 255) {
>> +av_log(s->avctx, AV_LOG_DEBUG, "Invalid (Out of
>> range) intra chroma block DC difference %d, %d\n", cbd, crd);
>> +return AVERROR_INVALIDDATA;
>> +}
>
>
> Please remove the error messages.

How is the user supposed to know why decoding failed?
How is a developer answering on the user mailing list
supposed to know what the issue is?

(Are you planning to work on snow?)

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


Re: [FFmpeg-devel] [Patch] Download dash content with byte range info

2017-11-15 Thread Carl Eugen Hoyos
2017-11-15 22:00 GMT+01:00 Colin NG :
> This patch is partial fix for ticket 6658 (Dash demuxer segfault).

> +static struct fragment * get_Fragment(char *range) {
> +struct fragment * seg =  av_mallocz(sizeof(struct fragment));

Please make it (code-style):
... fragment *get_Fragment...
... fragment *seg =...

> +if (!seg)
> +goto finish;

No.

You can "return NULL;" but since this is a little misleading,
it may be better to return AVERROR(ENOMEM) and instead
of the existing check for NULL below, check for "< 0".

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


Re: [FFmpeg-devel] [PATCH] avfilter/vf_cropdetect: change license to LGPL

2017-11-15 Thread Carl Eugen Hoyos
2017-11-14 23:35 GMT+01:00 Aman Gupta :
> From: Aman Gupta 
>
> This filter was imported from mplayer's libmpcodecs/vf_cropdetect.c, and
> marked as GPL when originally copied over.
>
> On the mplayer side, it was authored originally by arpi and subsequently 
> touched by
> the following contributors. See 
> https://github.com/pigoz/mplayer-svn/commits/master/libmpcodecs/vf_cropdetect.c
>
>   arpi
>   albeu
>   diego
>   reimar
>   michael
>   reynaldo
>   lucabe
>   cehoyos

This list looks incomplete;-(

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


Re: [FFmpeg-devel] [PATCH] libavcodec/videotoolbox: fix decoding of h264 streams with minor SPS changes

2017-11-15 Thread Hendrik Leppkes
On Wed, Nov 15, 2017 at 10:15 PM, Aman Gupta  wrote:
> From: Aman Gupta 
>
> Previously the codec kept an entire copy of the SPS, and restarted the VT 
> decoder
> session whenever it changed. This fixed decoding errors in [1], as
> described in 9519983c. On further inspection, that sample features an SPS 
> change
> from High/4.0 to High/3.2 while moving from one scene to another.
>
> Yesterday I received [2], which contains minor SPS changes where the
> profile and level do not change. These occur frequently and are not 
> associated with
> scene changes. After 9519983c, the VT decoder session is recreated 
> unnecessarily when
> these are encountered causing visual glitches.
>
> This commit simplifies the state kept in the VTContext to include just the 
> first three
> bytes of the SPS, containing the profile and level details. This is populated 
> initially
> when the VT decoder session is created, and used to detect changes and force 
> a restart.
>
> This means minor SPS changes are fed directly into the existing decoder, 
> whereas
> profile/level changes force the decoder session to be recreated with the new 
> parameters.
>

The profile and level are not exactly the only things that can change
to force a decoder to be re-created.
How about the frame dimensions, within the same level?

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


Re: [FFmpeg-devel] [PATCH] avformat/avio: remove must_flush from AVIOContext

2017-11-15 Thread Marton Balint


On Wed, 15 Nov 2017, Nicolas George wrote:


Le quintidi 25 brumaire, an CCXXVI, Marton Balint a écrit :

It is unused.

Signed-off-by: Marton Balint 
---
 libavformat/avio.h | 1 -
 1 file changed, 1 deletion(-)


Breaks ABI by moving all the fields below.


We are still in unstable ABI period AFAIK.

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


[FFmpeg-devel] [PATCH] avfilter/vf_cropdetect: change license to LGPL

2017-11-15 Thread Aman Gupta
From: Aman Gupta 

This filter was imported from mplayer's libmpcodecs/vf_cropdetect.c, and
marked as GPL when originally copied over.

On the mplayer side, it was authored originally by arpi and subsequently 
touched by
the following contributors. See 
https://github.com/pigoz/mplayer-svn/commits/master/libmpcodecs/vf_cropdetect.c

  arpi
  albeu
  diego
  reimar
  michael
  reynaldo
  lucabe
  cehoyos

Of these contributors, all except the last two granted their permission to 
relicense
mplayer changes to LGPL. See 
https://github.com/mpv-player/mpv/wiki/List-of-MPlayer-LGPL-relicensing-agreements

The change by lucabe was to remove an include header, and the change by cehoyos 
was to
change whitespace. Both are trivial and can be ignored for copyright purposes. 
See
https://github.com/pigoz/mplayer-svn/commit/6da0237a4#diff-2d400db883ad8bca0e5d6a78f12613fd
and 
https://github.com/pigoz/mplayer-svn/commit/04d069fcb#diff-2d400db883ad8bca0e5d6a78f12613fd

The import into ffmpeg was done by Stefano Sabatini. It was then touched by the 
following
contributors, who specifically made changes to the filter. This does not include
commits which changed this file but were part of larger refactorings that 
changed
lavfi APIs and other LGPL filters as well. See
https://github.com/FFmpeg/FFmpeg/commits/master/libavfilter/vf_cropdetect.c

  Stefano Sabatini
  Michael Niedermayer
  Anton Khirnov
  Clément Bœsch
  Paul B Mahol
  Carl Eugen Hoyos
  Vittorio Giovara
  Ganesh Ajjanagadde

The people above are CC'd on this patch for their permission to relicense 
vf_cropdetect as LGPL.
---
 configure   |  1 -
 libavfilter/vf_cropdetect.c | 18 +-
 2 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/configure b/configure
index 3788f26956..c1bdea9fa5 100755
--- a/configure
+++ b/configure
@@ -3185,7 +3185,6 @@ coreimage_filter_extralibs="-framework OpenGL"
 coreimagesrc_filter_deps="coreimage appkit"
 coreimagesrc_filter_extralibs="-framework OpenGL"
 cover_rect_filter_deps="avcodec avformat gpl"
-cropdetect_filter_deps="gpl"
 deinterlace_qsv_filter_deps="libmfx"
 deinterlace_vaapi_filter_deps="vaapi"
 delogo_filter_deps="gpl"
diff --git a/libavfilter/vf_cropdetect.c b/libavfilter/vf_cropdetect.c
index 7c7d0b953a..84abbe714c 100644
--- a/libavfilter/vf_cropdetect.c
+++ b/libavfilter/vf_cropdetect.c
@@ -2,19 +2,19 @@
  * Copyright (c) 2002 A'rpi
  * This file is part of FFmpeg.
  *
- * FFmpeg is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * 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 General Public License for more details.
+ * 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 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.
+ * 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
  */
 
 /**
-- 
2.14.2

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


Re: [FFmpeg-devel] [PATCH] avformat/avio: remove must_flush from AVIOContext

2017-11-15 Thread Nicolas George
Le quintidi 25 brumaire, an CCXXVI, Marton Balint a écrit :
> It is unused.
> 
> Signed-off-by: Marton Balint 
> ---
>  libavformat/avio.h | 1 -
>  1 file changed, 1 deletion(-)

Breaks ABI by moving all the fields below.

Regards,

-- 
  Nicolas George


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


[FFmpeg-devel] [PATCH] avformat/avio: remove must_flush from AVIOContext

2017-11-15 Thread Marton Balint
It is unused.

Signed-off-by: Marton Balint 
---
 libavformat/avio.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavformat/avio.h b/libavformat/avio.h
index 76ff7cd81e..75912ce6be 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -236,7 +236,6 @@ typedef struct AVIOContext {
 int (*write_packet)(void *opaque, uint8_t *buf, int buf_size);
 int64_t (*seek)(void *opaque, int64_t offset, int whence);
 int64_t pos;/**< position in the file of the current buffer */
-int must_flush; /**< unused */
 int eof_reached;/**< true if eof reached */
 int write_flag; /**< true if open for writing */
 int max_packet_size;
-- 
2.13.6

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


[FFmpeg-devel] [PATCH] libavcodec/videotoolbox: fix decoding of h264 streams with minor SPS changes

2017-11-15 Thread Aman Gupta
From: Aman Gupta 

Previously the codec kept an entire copy of the SPS, and restarted the VT 
decoder
session whenever it changed. This fixed decoding errors in [1], as
described in 9519983c. On further inspection, that sample features an SPS change
from High/4.0 to High/3.2 while moving from one scene to another.

Yesterday I received [2], which contains minor SPS changes where the
profile and level do not change. These occur frequently and are not associated 
with
scene changes. After 9519983c, the VT decoder session is recreated 
unnecessarily when
these are encountered causing visual glitches.

This commit simplifies the state kept in the VTContext to include just the 
first three
bytes of the SPS, containing the profile and level details. This is populated 
initially
when the VT decoder session is created, and used to detect changes and force a 
restart.

This means minor SPS changes are fed directly into the existing decoder, whereas
profile/level changes force the decoder session to be recreated with the new 
parameters.

After this commit, both samples [1] and [2] playback as expected.

[1] https://s3.amazonaws.com/tmm1/videotoolbox/spschange.ts
[2] https://s3.amazonaws.com/tmm1/videotoolbox/spschange2.ts

Signed-off-by: Aman Gupta 
---
 libavcodec/videotoolbox.c | 15 ---
 libavcodec/vt_internal.h  |  4 +---
 2 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 9eeada30ba..d29607363c 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -90,6 +90,7 @@ int ff_videotoolbox_alloc_frame(AVCodecContext *avctx, 
AVFrame *frame)
 
 CFDataRef ff_videotoolbox_avcc_extradata_create(AVCodecContext *avctx)
 {
+VTContext *vtctx = avctx->internal->hwaccel_priv_data;
 H264Context *h = avctx->priv_data;
 CFDataRef data = NULL;
 uint8_t *p;
@@ -116,6 +117,10 @@ CFDataRef 
ff_videotoolbox_avcc_extradata_create(AVCodecContext *avctx)
 p += 3 + h->ps.pps->data_size;
 av_assert0(p - vt_extradata == vt_extradata_size);
 
+// save sps header (profile/level) used to create decoder session,
+// so we can detect changes and recreate it.
+memcpy(vtctx->sps, h->ps.sps->data + 1, 3);
+
 data = CFDataCreate(kCFAllocatorDefault, vt_extradata, vt_extradata_size);
 av_free(vt_extradata);
 return data;
@@ -320,16 +325,13 @@ static int videotoolbox_h264_decode_params(AVCodecContext 
*avctx,
 VTContext *vtctx = avctx->internal->hwaccel_priv_data;
 
 if (type == H264_NAL_SPS) {
-if (!vtctx->sps || vtctx->sps_len != size || memcmp(buffer, 
vtctx->sps, size) != 0) {
-vtctx->sps = av_fast_realloc(vtctx->sps, >sps_capa, size);
-if (vtctx->sps)
-memcpy(vtctx->sps, buffer, size);
+if (size > 4 && memcmp(vtctx->sps, buffer + 1, 3) != 0) {
 vtctx->reconfig_needed = true;
-vtctx->sps_len = size;
+memcpy(vtctx->sps, buffer + 1, 3);
 }
 }
 
-// pass-through new PPS to the decoder
+// pass-through SPS/PPS changes to the decoder
 return ff_videotoolbox_h264_decode_slice(avctx, buffer, size);
 }
 
@@ -365,7 +367,6 @@ int ff_videotoolbox_uninit(AVCodecContext *avctx)
 VTContext *vtctx = avctx->internal->hwaccel_priv_data;
 if (vtctx) {
 av_freep(>bitstream);
-av_freep(>sps);
 if (vtctx->frame)
 CVPixelBufferRelease(vtctx->frame);
 }
diff --git a/libavcodec/vt_internal.h b/libavcodec/vt_internal.h
index fc27dad9f9..929fe423fc 100644
--- a/libavcodec/vt_internal.h
+++ b/libavcodec/vt_internal.h
@@ -40,9 +40,7 @@ typedef struct VTContext {
 struct AVVideotoolboxContext *vt_ctx;
 
 // Current H264 parameters (used to trigger decoder restart on SPS 
changes).
-uint8_t *sps;
-uint32_tsps_len;
-unsigned intsps_capa;
+uint8_t sps[3];
 boolreconfig_needed;
 } VTContext;
 
-- 
2.14.2

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


Re: [FFmpeg-devel] [Patch] Download dash content with byte range info

2017-11-15 Thread Colin NG
This patch is partial fix for ticket 6658 (Dash demuxer segfault).



From: ffmpeg-devel  on behalf of Steven Liu 

Sent: November 15, 2017 2:58 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [Patch] Download dash content with byte range info

2017-11-15 10:26 GMT+08:00 Colin NG :
> Please ignore the previous "patch" email.
>
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 0e3afd2..68196e9 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -522,6 +522,22 @@ static enum AVMediaType get_content_type(xmlNodePtr node)
 return type;
 }

+static struct fragment * getFragment(char *range)
Camel-Case code style, please use name looks like : get_fragment

+{
+struct fragment * seg =  av_mallocz(sizeof(struct fragment));
check the seg , if av_mallocz is failed, it will error;
+
+memset(seg, 0, sizeof(struct fragment));
unnecessary memset, because av_mallocz is set seg to 0 already.

+seg->size = -1;
+if (range)  {
+char *str_end_offset;
+char *str_offset = av_strtok(range, "-", _end_offset);
+seg->url_offset = strtoll(str_offset, NULL, 10);
+seg->size = strtoll(str_end_offset, NULL, 10) -seg->url_offset;
+}
+
+return seg;
+}
+
 static int parse_manifest_segmenturlnode(AVFormatContext *s, struct
representation *rep,
  xmlNodePtr fragmenturl_node,
  xmlNodePtr *baseurl_nodes,
@@ -530,11 +546,13 @@ static int
parse_manifest_segmenturlnode(AVFormatContext *s, struct representati
 {
 char *initialization_val = NULL;
 char *media_val = NULL;
+char *range_val = NULL;

 if (!av_strcasecmp(fragmenturl_node->name, (const char
*)"Initialization")) {
 initialization_val = xmlGetProp(fragmenturl_node, "sourceURL");
-if (initialization_val) {
-rep->init_section = av_mallocz(sizeof(struct fragment));
+range_val = xmlGetProp(fragmenturl_node, "range");
+if (initialization_val || range_val) {
+rep->init_section = getFragment(range_val);// byte range on
 if (!rep->init_section) {
 xmlFree(initialization_val);
 return AVERROR(ENOMEM);
@@ -550,11 +568,13 @@ static int
parse_manifest_segmenturlnode(AVFormatContext *s, struct representati
 }
 rep->init_section->size = -1;
 xmlFree(initialization_val);
+xmlFree(range_val);
 }
 } else if (!av_strcasecmp(fragmenturl_node->name, (const char
*)"SegmentURL")) {
 media_val = xmlGetProp(fragmenturl_node, "media");
-if (media_val) {
-struct fragment *seg = av_mallocz(sizeof(struct fragment));
+range_val = xmlGetProp(fragmenturl_node, "mediaRange");
+if (media_val || range_val) {
+struct fragment *seg =  getFragment(range_val);// byte range on
 if (!seg) {
 xmlFree(media_val);
 return AVERROR(ENOMEM);
@@ -571,12 +591,12 @@ static int
parse_manifest_segmenturlnode(AVFormatContext *s, struct representati
 seg->size = -1;
 dynarray_add(>fragments, >n_fragments, seg);
 xmlFree(media_val);
+xmlFree(range_val);
 }
 }

 return 0;
 }
-
 static int parse_manifest_segmenttimeline(AVFormatContext *s, struct
representation *rep,
   xmlNodePtr fragment_timeline_node)
 {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
ffmpeg-devel Info Page
ffmpeg.org
This list is about FFmpeg development discussions and patches; but not for 
bug-reports. Please read the Code-of-conduct. To see the collection of prior 
postings to ...


diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 0e3afd2..0bc0f06 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -522,6 +522,23 @@ static enum AVMediaType get_content_type(xmlNodePtr node)
 return type;
 }
 
+static struct fragment * get_Fragment(char *range) {
+struct fragment * seg =  av_mallocz(sizeof(struct fragment));
+
+if (!seg) 
+goto finish;
+
+seg->size = -1;
+if (range)  {
+char *str_end_offset;
+char *str_offset = av_strtok(range, "-", _end_offset);
+seg->url_offset = strtoll(str_offset, NULL, 10);
+seg->size = strtoll(str_end_offset, NULL, 10) -seg->url_offset;
+}
+finish:
+return seg;
+}
+
 static int parse_manifest_segmenturlnode(AVFormatContext *s, struct 
representation *rep,

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Check intra block dc differences.

2017-11-15 Thread Ronald S. Bultje
Hi,

On Wed, Nov 15, 2017 at 3:17 PM, Michael Niedermayer  wrote:

> Fixes: Timeout
> Fixes: 3142/clusterfuzz-testcase-5007853163118592
>
> Found-by: continuous fuzzing process https://github.com/google/oss-
> fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/snowdec.c | 19 +++
>  1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/snowdec.c b/libavcodec/snowdec.c
> index 727e908fb5..77ffe7f594 100644
> --- a/libavcodec/snowdec.c
> +++ b/libavcodec/snowdec.c
> @@ -183,13 +183,24 @@ static int decode_q_branch(SnowContext *s, int
> level, int x, int y){
>  int my_context= av_log2(2*FFABS(left->my - top->my)) +
> 0*av_log2(2*FFABS(tr->my - top->my));
>
>  type= get_rac(>c, >block_state[1 + left->type + top->type])
> ? BLOCK_INTRA : 0;
> -
>  if(type){
> +int ld, cbd, crd;
>  pred_mv(s, , , 0, left, top, tr);
> -l += get_symbol(>c, >block_state[32], 1);
> +ld = get_symbol(>c, >block_state[32], 1);
> +if (ld < -255 || ld > 255) {
> +av_log(s->avctx, AV_LOG_DEBUG, "Invalid (Out of range)
> intra luma block DC difference %d\n", ld);
> +return AVERROR_INVALIDDATA;
> +}
> +l += ld;
>  if (s->nb_planes > 2) {
> -cb+= get_symbol(>c, >block_state[64], 1);
> -cr+= get_symbol(>c, >block_state[96], 1);
> +cbd = get_symbol(>c, >block_state[64], 1);
> +crd = get_symbol(>c, >block_state[96], 1);
> +if (cbd < -255 || cbd > 255 || crd < -255 || crd > 255) {
> +av_log(s->avctx, AV_LOG_DEBUG, "Invalid (Out of
> range) intra chroma block DC difference %d, %d\n", cbd, crd);
> +return AVERROR_INVALIDDATA;
> +}


Please remove the error messages.

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


[FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Check intra block dc differences.

2017-11-15 Thread Michael Niedermayer
Fixes: Timeout
Fixes: 3142/clusterfuzz-testcase-5007853163118592

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

diff --git a/libavcodec/snowdec.c b/libavcodec/snowdec.c
index 727e908fb5..77ffe7f594 100644
--- a/libavcodec/snowdec.c
+++ b/libavcodec/snowdec.c
@@ -183,13 +183,24 @@ static int decode_q_branch(SnowContext *s, int level, int 
x, int y){
 int my_context= av_log2(2*FFABS(left->my - top->my)) + 
0*av_log2(2*FFABS(tr->my - top->my));
 
 type= get_rac(>c, >block_state[1 + left->type + top->type]) ? 
BLOCK_INTRA : 0;
-
 if(type){
+int ld, cbd, crd;
 pred_mv(s, , , 0, left, top, tr);
-l += get_symbol(>c, >block_state[32], 1);
+ld = get_symbol(>c, >block_state[32], 1);
+if (ld < -255 || ld > 255) {
+av_log(s->avctx, AV_LOG_DEBUG, "Invalid (Out of range) intra 
luma block DC difference %d\n", ld);
+return AVERROR_INVALIDDATA;
+}
+l += ld;
 if (s->nb_planes > 2) {
-cb+= get_symbol(>c, >block_state[64], 1);
-cr+= get_symbol(>c, >block_state[96], 1);
+cbd = get_symbol(>c, >block_state[64], 1);
+crd = get_symbol(>c, >block_state[96], 1);
+if (cbd < -255 || cbd > 255 || crd < -255 || crd > 255) {
+av_log(s->avctx, AV_LOG_DEBUG, "Invalid (Out of range) 
intra chroma block DC difference %d, %d\n", cbd, crd);
+return AVERROR_INVALIDDATA;
+}
+cb += cbd;
+cr += crd;
 }
 }else{
 if(s->ref_frames > 1)
-- 
2.15.0

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


[FFmpeg-devel] [PATCH 2/2] avcodec/snowdec: Check for remaining bitstream in decode_blocks()

2017-11-15 Thread Michael Niedermayer
Fixes: Timeout
Fixes: 3142/clusterfuzz-testcase-5007853163118592

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

diff --git a/libavcodec/snowdec.c b/libavcodec/snowdec.c
index 77ffe7f594..99b5a86394 100644
--- a/libavcodec/snowdec.c
+++ b/libavcodec/snowdec.c
@@ -439,6 +439,8 @@ static int decode_blocks(SnowContext *s){
 
 for(y=0; yc.bytestream >= s->c.bytestream_end)
+return AVERROR_INVALIDDATA;
 if ((res = decode_q_branch(s, 0, x, y)) < 0)
 return res;
 }
-- 
2.15.0

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


Re: [FFmpeg-devel] [PATCH 1/1] avdevice/decklink_dec: Autodetect the video input format

2017-11-15 Thread Marton Balint


On Tue, 7 Nov 2017, Jeyapal, Karthick wrote:


On 11/6/17, 6:19 AM, "Marton Balint"  wrote:


On Fri, 27 Oct 2017, Jeyapal, Karthick wrote:



Please find the patch attached.



Thanks, below some comments:


Thanks a lot for your detailed comments. I have incorporated all your comments 
in this new patch(es).
Also, I have split it as two patches as you suggested. Please find them 
attached.


For the first patch, I think you forgot to call ff_decklink_set_configs in 
decklink_enc.


For the second patch here are some comments:


From 041bed1ef07e59419f1befda3f064f0fe3f8e30b Mon Sep 17 00:00:00 2001
From: Karthick J 
Date: Fri, 27 Oct 2017 12:00:23 +0530
Subject: [PATCH 2/2] libavdevice/decklink_dec: Autodetect the video input
 format

When -format_code is not specified autodetection will happen
---
 doc/indevs.texi |  2 ++
 libavdevice/decklink_common.cpp |  3 --
 libavdevice/decklink_common.h   |  1 +
 libavdevice/decklink_common_c.h |  6 
 libavdevice/decklink_dec.cpp| 78 ++---
 5 files changed, 74 insertions(+), 16 deletions(-)

diff --git a/doc/indevs.texi b/doc/indevs.texi
index d308bbf..56066bf 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -238,6 +238,8 @@ This sets the input video format to the format given by the 
FourCC. To see
 the supported values of your device(s) use @option{list_formats}.
 Note that there is a FourCC @option{'pal '} that can also be used
 as @option{pal} (3 letters).
+Default behavior is autodetection of the input video format, if the hardware
+supports it.

 @item bm_v210
 This is a deprecated option, you can use @option{raw_format} instead.
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index b952e74..6ef2c52 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -75,7 +75,6 @@ static char *dup_wchar_to_utf8(wchar_t *w)
 #define DECKLINK_STROLECHAR *
 #define DECKLINK_STRDUP dup_wchar_to_utf8
 #define DECKLINK_FREE(s) SysFreeString(s)
-#define DECKLINK_BOOL BOOL
 #elif defined(__APPLE__)
 static char *dup_cfstring_to_utf8(CFStringRef w)
 {
@@ -86,13 +85,11 @@ static char *dup_cfstring_to_utf8(CFStringRef w)
 #define DECKLINK_STRconst __CFString *
 #define DECKLINK_STRDUP dup_cfstring_to_utf8
 #define DECKLINK_FREE(s) CFRelease(s)
-#define DECKLINK_BOOL bool
 #else
 #define DECKLINK_STRconst char *
 #define DECKLINK_STRDUP av_strdup
 /* free() is needed for a string returned by the DeckLink SDL. */
 #define DECKLINK_FREE(s) free((void *) s)
-#define DECKLINK_BOOL bool
 #endif

 HRESULT ff_decklink_get_display_name(IDeckLink *This, const char **displayName)
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 4345156..d18b643 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -95,6 +95,7 @@ struct decklink_ctx {
 pthread_mutex_t mutex;
 pthread_cond_t cond;
 int frames_buffer_available_spots;
+int autodetect;

 int channels;
 int audio_depth;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index 368ac25..4e4c369 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -23,6 +23,12 @@
 #ifndef AVDEVICE_DECKLINK_COMMON_C_H
 #define AVDEVICE_DECKLINK_COMMON_C_H

+#ifdef _WIN32
+#define DECKLINK_BOOL BOOL
+#else
+#define DECKLINK_BOOL bool
+#endif
+


This rather belongs to decklink_common.h.


 typedef enum DecklinkPtsSource {
 PTS_SRC_AUDIO = 1,
 PTS_SRC_VIDEO = 2,
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 242a194..60017e4 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -36,6 +36,7 @@ extern "C" {
 #include "libavutil/avutil.h"
 #include "libavutil/common.h"
 #include "libavutil/imgutils.h"
+#include "libavutil/intreadwrite.h"
 #include "libavutil/time.h"
 #include "libavutil/mathematics.h"
 #include "libavutil/reverse.h"
@@ -49,6 +50,7 @@ extern "C" {
 #include "decklink_dec.h"

 #define MAX_WIDTH_VANC 1920
+const BMDDisplayMode AUTODETECT_DEFAULT_MODE = bmdModeNTSC;

 typedef struct VANCLineNumber {
 BMDDisplayMode mode;
@@ -634,6 +636,17 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
 BMDTimeValue frameDuration;
 int64_t wallclock = 0;

+if (ctx->autodetect) {
+pthread_mutex_lock(>mutex);


Do you still need a mutex? VideoInputFrameArrived and
VideoInputFormatChanged are called from the same thread, no?


+if (videoFrame && !(videoFrame->GetFlags() & bmdFrameHasNoInputSource) 
&&
+ctx->bmd_mode == bmdModeUnknown)
+{
+ctx->bmd_mode = AUTODETECT_DEFAULT_MODE;
+}
+pthread_mutex_unlock(>mutex);
+return S_OK;
+}
+
 ctx->frameCount++;
 if (ctx->audio_pts_source == PTS_SRC_WALLCLOCK || ctx->video_pts_source == 
PTS_SRC_WALLCLOCK)
 wallclock = 

[FFmpeg-devel] [PATCH] hwcontext_d3d11va: add missing stdint.h include

2017-11-15 Thread Timo Rothenpieler
This caused checkheaders to fail on cygwin on this file.
---
 libavutil/hwcontext_d3d11va.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavutil/hwcontext_d3d11va.h b/libavutil/hwcontext_d3d11va.h
index 98db7ce343..9f91e9b1b6 100644
--- a/libavutil/hwcontext_d3d11va.h
+++ b/libavutil/hwcontext_d3d11va.h
@@ -37,6 +37,7 @@
  */
 
 #include 
+#include 
 
 /**
  * This struct is allocated as AVHWDeviceContext.hwctx
-- 
2.15.0

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


[FFmpeg-devel] [PATCH] lavf/movenc: allow writing avc3 sample entry type

2017-11-15 Thread John Stebbins
The avc3 sample entry type is useful for adaptive streaming.  It permits
parameter sets to be written inline in the video stream.
---
 libavformat/movenc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index cc3fc19d9b..01ae467fa1 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6513,6 +6513,7 @@ static const AVCodecTag codec_3gp_tags[] = {
 const AVCodecTag codec_mp4_tags[] = {
 { AV_CODEC_ID_MPEG4   , MKTAG('m', 'p', '4', 'v') },
 { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '1') },
+{ AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '3') },
 { AV_CODEC_ID_HEVC, MKTAG('h', 'e', 'v', '1') },
 { AV_CODEC_ID_HEVC, MKTAG('h', 'v', 'c', '1') },
 { AV_CODEC_ID_MPEG2VIDEO  , MKTAG('m', 'p', '4', 'v') },
-- 
2.13.6

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


Re: [FFmpeg-devel] [PATCH]lavf/matroskaenc: Do not write 0 duration for subtitles

2017-11-15 Thread John Stebbins

On 11/14/2017 02:18 PM, Carl Eugen Hoyos wrote:
> 2017-11-14 19:02 GMT+01:00 Jerome Martinez :
>> On 12/11/2017 03:12, Carl Eugen Hoyos wrote:
>>> -put_ebml_uint(pb, MATROSKA_ID_BLOCKDURATION, duration);
>>> +if (duration > 0)
>>> +put_ebml_uint(pb, MATROSKA_ID_BLOCKDURATION, duration);
>>
>> In that case, the duration of the block is DefaultDuration (if it exists),
>> completely different.
>> Is it intended to say that a duration of 0 at this place means that the
>> block has the default block duration if it exists?
>>
>> What is the use case for a duration of 0?
> Iirc, pgs subtitles send an empty "frame" to reset / remove the
> subtitle.

Correct, this is the source of these 0 duration pgs "subtitles".

>
>> (Note: the meaning of the a block duration of 0 is unclear to me, I'll ask
>> on CELLAR mailing list to clarify that)
> So maybe the issue is with mkvalidate?
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
John  GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01  83F0 49F1 D7B2 60D4 D0F7




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


Re: [FFmpeg-devel] [PATCH] vf_zscale: Add more supported input properties

2017-11-15 Thread Carl Eugen Hoyos
2017-11-15 17:26 GMT+01:00 Vittorio Giovara :

> There is a stable release with this code, and it's a minor update,
> not sure if it warrants a configure check, but I'll add it if requested.

Does it compile without? Does configure succeed?

The patch must not lead to a situation where configure
passes but build fails.

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


[FFmpeg-devel] [PATCH] vf_zscale: Add more supported input properties

2017-11-15 Thread Vittorio Giovara
---
Now without mxf code >_>

There is a stable release with this code, and it's a minor update,
not sure if it warrants a configure check, but I'll add it if requested.
Vittorio

 libavfilter/vf_zscale.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 09fd842fe5..7d048da1ef 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -353,10 +353,10 @@ static int convert_matrix(enum AVColorSpace colorspace)
 return ZIMG_MATRIX_709;
 case AVCOL_SPC_UNSPECIFIED:
 return ZIMG_MATRIX_UNSPECIFIED;
-case AVCOL_SPC_BT470BG:
-return ZIMG_MATRIX_470BG;
 case AVCOL_SPC_SMPTE170M:
 return ZIMG_MATRIX_170M;
+case AVCOL_SPC_SMPTE240M:
+return ZIMG_MATRIX_240M;
 case AVCOL_SPC_YCGCO:
 return ZIMG_MATRIX_YCGCO;
 case AVCOL_SPC_BT2020_NCL:
@@ -374,10 +374,22 @@ static int convert_trc(enum AVColorTransferCharacteristic 
color_trc)
 return ZIMG_TRANSFER_UNSPECIFIED;
 case AVCOL_TRC_BT709:
 return ZIMG_TRANSFER_709;
+case AVCOL_TRC_GAMMA22:
+return ZIMG_TRANSFER_470_M;
+case AVCOL_TRC_GAMMA28:
+return ZIMG_TRANSFER_470_BG;
 case AVCOL_TRC_SMPTE170M:
 return ZIMG_TRANSFER_601;
+case AVCOL_TRC_SMPTE240M:
+return ZIMG_TRANSFER_240M;
 case AVCOL_TRC_LINEAR:
 return ZIMG_TRANSFER_LINEAR;
+case AVCOL_TRC_LOG:
+return ZIMG_TRANSFER_LOG_100;
+case AVCOL_TRC_LOG_SQRT:
+return ZIMG_TRANSFER_LOG_316;
+case AVCOL_TRC_IEC61966_2_4:
+return ZIMG_TRANSFER_IEC_61966_2_4;
 case AVCOL_TRC_BT2020_10:
 return ZIMG_TRANSFER_2020_10;
 case AVCOL_TRC_BT2020_12:
@@ -399,6 +411,10 @@ static int convert_primaries(enum AVColorPrimaries 
color_primaries)
 return ZIMG_PRIMARIES_UNSPECIFIED;
 case AVCOL_PRI_BT709:
 return ZIMG_PRIMARIES_709;
+case AVCOL_PRI_BT470M:
+return ZIMG_PRIMARIES_470_M;
+case AVCOL_PRI_BT470BG:
+return ZIMG_PRIMARIES_470_BG;
 case AVCOL_PRI_SMPTE170M:
 return ZIMG_PRIMARIES_170M;
 case AVCOL_PRI_SMPTE240M:
@@ -745,6 +761,8 @@ static const AVOption zscale_options[] = {
 { "2020", 0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_2020},0, 0, FLAGS, "primaries" },
 { "unknown",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_UNSPECIFIED}, 0, 0, FLAGS, "primaries" },
 { "bt709",0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_709}, 0, 0, FLAGS, "primaries" },
+{ "bt470m",   0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_470_M},   0, 0, FLAGS, "primaries" },
+{ "bt470bg",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_470_BG},  0, 0, FLAGS, "primaries" },
 { "smpte170m",0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_170M},0, 0, FLAGS, "primaries" },
 { "smpte240m",0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_240M},0, 0, FLAGS, "primaries" },
 { "bt2020",   0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_2020},0, 0, FLAGS, "primaries" },
@@ -756,9 +774,13 @@ static const AVOption zscale_options[] = {
 { "unspecified",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_UNSPECIFIED}, 0, 0, FLAGS, "transfer" },
 { "601",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_601}, 0, 0, FLAGS, "transfer" },
 { "linear",   0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_LINEAR},  0, 0, FLAGS, "transfer" },
+{ "log100",   0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_LOG_100},  0, 0, FLAGS, "transfer" },
+{ "log316",   0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_LOG_316},  0, 0, FLAGS, "transfer" },
 { "2020_10",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_2020_10}, 0, 0, FLAGS, "transfer" },
 { "2020_12",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_2020_12}, 0, 0, FLAGS, "transfer" },
 { "unknown",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_UNSPECIFIED}, 0, 0, FLAGS, "transfer" },
+{ "bt470m",   0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_470_M}, 0, 0, FLAGS, "transfer" },
+{ "bt470bg",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_470_BG}, 0, 0, FLAGS, "transfer" },
 { "smpte170m",0,   0, AV_OPT_TYPE_CONST, 
{.i64 = 

[FFmpeg-devel] [PATCH] avcodec/zmbv: Check that the buffer is large enough for mvec

2017-11-15 Thread Michael Niedermayer
Fixes: Timeout
Fixes: 4143/clusterfuzz-testcase-4736864637419520

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

diff --git a/libavcodec/zmbv.c b/libavcodec/zmbv.c
index b09dc41ebd..f91d2e3931 100644
--- a/libavcodec/zmbv.c
+++ b/libavcodec/zmbv.c
@@ -539,6 +539,8 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame, AVPac
 } else {
 frame->key_frame = 0;
 frame->pict_type = AV_PICTURE_TYPE_P;
+if (c->decomp_len < 2LL * ((c->width + c->bw - 1) / c->bw) * 
((c->height + c->bh - 1) / c->bh))
+return AVERROR_INVALIDDATA;
 if (c->decomp_len)
 c->decode_xor(c);
 }
-- 
2.15.0

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


Re: [FFmpeg-devel] [PATCH 00/15] OpenCL infrastructure, filters

2017-11-15 Thread Mark Thompson
On 15/11/17 15:39, Carl Eugen Hoyos wrote:
> 2017-11-15 15:34 GMT+01:00 Mark Thompson :
>> On 14/11/17 22:30, Carl Eugen Hoyos wrote:
>>> 2017-11-14 20:47 GMT+01:00 Mark Thompson :
>>>
 Silly example using everything (for i965 VAAPI + Beignet):

 ./ffmpeg_g -y -init_hw_device vaapi=va:/dev/dri/renderD128
 -init_hw_device opencl=ocl@va -hwaccel vaapi
 -hwaccel_device va -hwaccel_output_format vaapi -i in.mp4
 -f image2 -r 1 -i overlays/%d.png -an -filter_hw_device ocl
 -filter_complex '[1:v]format=yuva420p,hwupload[x2];
 [0:v]scale_vaapi=1280:720:yuv420p,hwmap[x1];
 [x1][x2]overlay_opencl=0:0,
>>>
 program_opencl=test.cl
>>>
>>> Is this the equivalent of the vhook functionality?
>>
>> I suppose it has some similarities.
> 
>> Is that a problem?
> 
> That's exactly my question, I wonder if it is an issue.

The code itself shouldn't be a problem - OpenCL is fully standardised with 
runtime compilation (and indeed we have to do this for the filters including 
source as well).

Like other filters making use of external files, it shouldn't be used where 
arguments (given e.g. "source=/etc/passwd" the build errors can leak 
inappropriate information) or the source file (easy to DoS the GPU) could be 
controlled by an attacker, but I don't think that sort of thing is a common 
use-case.

>> The point of it is to allow the user to run simple pixel shaders
>> on the GPU side without having to integrate them into ffmpeg.
> 
> Why would this only be possible for simple shaders?

It only has the input frame and an increasing index to decide what to do - 
there are no persistent data to guide anything.  (More could be added, of 
course, but making something which is generally useful is difficult and quickly 
loses the simplicity of the current form.  Ideas certainly welcome, though.)

Thanks,

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


Re: [FFmpeg-devel] [Patch] Fix for ticket 6658 (Dash demuxer segfault)

2017-11-15 Thread Colin NG
Have submitted already for the byte range issue in another email with title 
"Download dash content with byte range info"



From: ffmpeg-devel  on behalf of Carl Eugen 
Hoyos 
Sent: November 15, 2017 10:54 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [Patch] Fix for ticket 6658 (Dash demuxer segfault)

2017-11-15 3:54 GMT+01:00 Colin NG :
> - Add a function to handle the base URL Processing described in section 5.6.5 
> of IEC_23009-1.
>
> - Fix for downloading dash content with byte range info

As said: If these are two separate issues, please send two patches.

Use tools/patcheck to check your patch for many style issues.
(No Changelog entry necessary.)

Try to avoid if ((var1 = var2) > 1), instead add an additional line.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
ffmpeg-devel Info Page
ffmpeg.org
This list is about FFmpeg development discussions and patches; but not for 
bug-reports. Please read the Code-of-conduct. To see the collection of prior 
postings to ...



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


Re: [FFmpeg-devel] [Patch] Fix for ticket 6658 (Dash demuxer segfault)

2017-11-15 Thread Carl Eugen Hoyos
2017-11-15 3:54 GMT+01:00 Colin NG :
> - Add a function to handle the base URL Processing described in section 5.6.5 
> of IEC_23009-1.
>
> - Fix for downloading dash content with byte range info

As said: If these are two separate issues, please send two patches.

Use tools/patcheck to check your patch for many style issues.
(No Changelog entry necessary.)

Try to avoid if ((var1 = var2) > 1), instead add an additional line.

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


Re: [FFmpeg-devel] libavcodec/als: remove check for predictor order of a block

2017-11-15 Thread Carl Eugen Hoyos
2017-11-15 8:54 GMT+01:00 Umair Khan :

> I'm now moving to the ALS encoder tasks before we start with the next GSoC.

Great!

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


Re: [FFmpeg-devel] [PATCH 3/3] lavf/qsv_vpp: fix compiling warning

2017-11-15 Thread Carl Eugen Hoyos
2017-11-15 10:04 GMT+01:00 Zhong Li :
> fix the compiling warning of "ignoring return value"

> -ff_formats_ref(in_fmts, >inputs[0]->out_formats);
> -ff_formats_ref(out_fmts, >outputs[0]->in_formats);
> +if ((ret = ff_formats_ref(in_fmts, >inputs[0]->out_formats)) < 0)
> +return ret;
> +if ((ret = ff_formats_ref(out_fmts, >outputs[0]->in_formats)) < 0)

Two additional lines are cheap.

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


Re: [FFmpeg-devel] [PATCH 00/15] OpenCL infrastructure, filters

2017-11-15 Thread Carl Eugen Hoyos
2017-11-15 15:34 GMT+01:00 Mark Thompson :
> On 14/11/17 22:30, Carl Eugen Hoyos wrote:
>> 2017-11-14 20:47 GMT+01:00 Mark Thompson :
>>
>>> Silly example using everything (for i965 VAAPI + Beignet):
>>>
>>> ./ffmpeg_g -y -init_hw_device vaapi=va:/dev/dri/renderD128
>>> -init_hw_device opencl=ocl@va -hwaccel vaapi
>>> -hwaccel_device va -hwaccel_output_format vaapi -i in.mp4
>>> -f image2 -r 1 -i overlays/%d.png -an -filter_hw_device ocl
>>> -filter_complex '[1:v]format=yuva420p,hwupload[x2];
>>> [0:v]scale_vaapi=1280:720:yuv420p,hwmap[x1];
>>> [x1][x2]overlay_opencl=0:0,
>>
>>> program_opencl=test.cl
>>
>> Is this the equivalent of the vhook functionality?
>
> I suppose it has some similarities.

> Is that a problem?

That's exactly my question, I wonder if it is an issue.

> The point of it is to allow the user to run simple pixel shaders
> on the GPU side without having to integrate them into ffmpeg.

Why would this only be possible for simple shaders?

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


Re: [FFmpeg-devel] [PATCH 00/15] OpenCL infrastructure, filters

2017-11-15 Thread Mark Thompson
On 14/11/17 22:30, Carl Eugen Hoyos wrote:
> 2017-11-14 20:47 GMT+01:00 Mark Thompson :
> 
>> Silly example using everything (for i965 VAAPI + Beignet):
>>
>> ./ffmpeg_g -y -init_hw_device vaapi=va:/dev/dri/renderD128
>> -init_hw_device opencl=ocl@va -hwaccel vaapi
>> -hwaccel_device va -hwaccel_output_format vaapi -i in.mp4
>> -f image2 -r 1 -i overlays/%d.png -an -filter_hw_device ocl
>> -filter_complex '[1:v]format=yuva420p,hwupload[x2];
>> [0:v]scale_vaapi=1280:720:yuv420p,hwmap[x1];
>> [x1][x2]overlay_opencl=0:0,
> 
>> program_opencl=test.cl
> 
> Is this the equivalent of the vhook functionality?

I suppose it has some similarities.  Is that a problem?

The point of it is to allow the user to run simple pixel shaders on the GPU 
side without having to integrate them into ffmpeg.  Compare, for example, the 
user shaders feature in mpv.

Thanks,

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


Re: [FFmpeg-devel] [PATCH 1/3] libavformat/avio: Utility function to return URLContext

2017-11-15 Thread Nicolas George
Le septidi 17 brumaire, an CCXXVI, Karthick J a écrit :
> ---
>  libavformat/avio_internal.h | 8 
>  libavformat/aviobuf.c   | 8 
>  2 files changed, 16 insertions(+)
> 
> diff --git a/libavformat/avio_internal.h b/libavformat/avio_internal.h
> index c01835d..04c1ad5 100644
> --- a/libavformat/avio_internal.h
> +++ b/libavformat/avio_internal.h
> @@ -133,6 +133,14 @@ int ffio_open_dyn_packet_buf(AVIOContext **s, int 
> max_packet_size);
>  int ffio_fdopen(AVIOContext **s, URLContext *h);
>  
>  /**
> + * Return the URLContext associated with the AVIOContext
> + *
> + * @param s IO context
> + * @return pointer to URLContext or NULL.
> + */
> +URLContext *ffio_geturlcontext(AVIOContext *s);
> +
> +/**
>   * Open a write-only fake memory stream. The written data is not stored
>   * anywhere - this is only used for measuring the amount of data
>   * written.
> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> index 3b4c843..1353c80 100644
> --- a/libavformat/aviobuf.c
> +++ b/libavformat/aviobuf.c
> @@ -980,6 +980,14 @@ fail:
>  return AVERROR(ENOMEM);
>  }
>  
> +URLContext* ffio_geturlcontext(AVIOContext *s) {
> +AVIOInternal *internal = s->opaque;

> +if (internal)
> +return internal->h;

This is rather fragile. Some kind of check that is is actually a real
URLContext would be a very good idea.

> +else
> +return NULL;
> +}
> +
>  int ffio_ensure_seekback(AVIOContext *s, int64_t buf_size)
>  {
>  uint8_t *buffer;

Regards,

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


[FFmpeg-devel] FFmpeg 3.4.1

2017-11-15 Thread Michael Niedermayer
Hi all

I intend to make 3.4.1 very soon, if you want something in it, please
backport to release/3.4

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.


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


Re: [FFmpeg-devel] [PATCH] avformat/subfile: allow to extract till EOF

2017-11-15 Thread Gyan Doshi
Disregard patch in first message. Didn't remove residue of aborted doc 
change earlier.


Regards,
Gyan
From 418879680f6d009b37aea29f667a5df142a83f83 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Wed, 15 Nov 2017 17:36:19 +0530
Subject: [PATCH] avformat/subfile: allow to extract till EOF

Users can set end offset as 0 to extract till end of file.
Tested locally and documented.
---
 doc/protocols.texi| 6 ++
 libavformat/subfile.c | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/doc/protocols.texi b/doc/protocols.texi
index a7968ff56e..f50a49b789 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1186,6 +1186,7 @@ Accepted options:
 Start offset of the extracted segment, in bytes.
 @item end
 End offset of the extracted segment, in bytes.
+If set to 0, extract till end of file.
 @end table
 
 Examples:
@@ -1201,6 +1202,11 @@ Play an AVI file directly from a TAR archive:
 subfile,,start,183241728,end,366490624,,:archive.tar
 @end example
 
+Play a MPEG-TS file from start offset till end:
+@example
+subfile,,start,32815239,end,0,,:video.ts
+@end example
+
 @section tee
 
 Writes the output to multiple protocols. The individual outputs are separated
diff --git a/libavformat/subfile.c b/libavformat/subfile.c
index 497cf85211..b527f2bee1 100644
--- a/libavformat/subfile.c
+++ b/libavformat/subfile.c
@@ -72,6 +72,9 @@ static int subfile_open(URLContext *h, const char *filename, 
int flags,
 SubfileContext *c = h->priv_data;
 int ret;
 
+if (!c->end)
+c->end = INT64_MAX;
+
 if (c->end <= c->start) {
 av_log(h, AV_LOG_ERROR, "end before start\n");
 return AVERROR(EINVAL);
-- 
2.11.1.windows.1___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avformat/subfile: allow to extract till EOF

2017-11-15 Thread Gyan Doshi
Attached patch allows users to set end offset as 0 to extract till end 
of file.


Tested locally and documented.

Regards,
Gyan
From e5c555774f88639f0e9337f1b55733d0ad156b64 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Wed, 15 Nov 2017 17:12:30 +0530
Subject: [PATCH] avformat/subfile: allow to extract till EOF

Users can set end offset as 0 to extract till end of file.
Tested locally and documented.
---
 doc/protocols.texi| 8 +++-
 libavformat/subfile.c | 3 +++
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/doc/protocols.texi b/doc/protocols.texi
index a7968ff56e..18c72532e1 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1186,6 +1186,7 @@ Accepted options:
 Start offset of the extracted segment, in bytes.
 @item end
 End offset of the extracted segment, in bytes.
+If set to 0, extract till end of file.
 @end table
 
 Examples:
@@ -1193,7 +1194,7 @@ Examples:
 Extract a chapter from a DVD VOB file (start and end sectors obtained
 externally and multiplied by 2048):
 @example
-subfile,,start,153391104,end,268142592,,:/media/dvd/VIDEO_TS/VTS_08_1.VOB
+ffmpeg 
subfile,,start,153391104,end,268142592,,:/media/dvd/VIDEO_TS/VTS_08_1.VOB
 @end example
 
 Play an AVI file directly from a TAR archive:
@@ -1201,6 +1202,11 @@ Play an AVI file directly from a TAR archive:
 subfile,,start,183241728,end,366490624,,:archive.tar
 @end example
 
+Play a MPEG-TS file from start offset till end:
+@example
+subfile,,start,32815239,end,0,,:video.ts
+@end example
+
 @section tee
 
 Writes the output to multiple protocols. The individual outputs are separated
diff --git a/libavformat/subfile.c b/libavformat/subfile.c
index 497cf85211..2094cdcdd0 100644
--- a/libavformat/subfile.c
+++ b/libavformat/subfile.c
@@ -72,6 +72,9 @@ static int subfile_open(URLContext *h, const char *filename, 
int flags,
 SubfileContext *c = h->priv_data;
 int ret;
 
+if (c->end == 0)
+c->end = INT64_MAX;
+
 if (c->end <= c->start) {
 av_log(h, AV_LOG_ERROR, "end before start\n");
 return AVERROR(EINVAL);
-- 
2.11.1.windows.1___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/3] libavformat/avio: Utility function to return URLContext

2017-11-15 Thread Jeyapal, Karthick
>>On Tue, Nov 7, 2017 at 2:34 AM Karthick J  wrote:
>>---
>> libavformat/avio_internal.h | 8 
>> libavformat/aviobuf.c       | 8 
>> 2 files changed, 16 insertions(+)
>
>LGTM. This would make my hls demuxer keepalive patch simpler as well.
>
>I know there were some concerns earlier about exposing URLContext, but since 
>this is internal I think it should be okay.
>
>Any objections?
>
>Aman

Well more than a week has passed by. It looks like there are no objections from 
anyone. 
If that is the case, could somebody push this patchset to mainline. I don’t 
have push permissions.

Regards,
Karthick



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


Re: [FFmpeg-devel] [PATCH v3 2/2] avformat/{http, tls}: enable tcp_nodelay

2017-11-15 Thread Jeyapal, Karthick
>Hmm, I guess if we want this to propagate down we need to add the option to 
>the tls protocol as well, then pass it down when it instantiates the tcp 
>protocol. Then add the same option to hls/dash, and again propagate it >down 
>to tls or tcp.
>
>This is turning into a much bigger change than I anticipated, and I don't 
>really care enough about it to continue. If someone else wants to take over 
>this patchset, they are more than welcome to it.
>
>Aman

Well, I would suggest you could push the first tcp patch and leave the http/tls 
patch for somebody else to take it up later.

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


Re: [FFmpeg-devel] [PATCH 2/2] nvenc: support d3d11 surface input

2017-11-15 Thread Hendrik Leppkes
On Sun, Nov 12, 2017 at 3:32 PM, Timo Rothenpieler
 wrote:
> Am 12.11.2017 um 10:30 schrieb Hendrik Leppkes:
>>
>> ---
>>   libavcodec/nvenc.c | 106
>> ++---
>>   libavcodec/nvenc.h |  11 +-
>>   2 files changed, 95 insertions(+), 22 deletions(-)
>>
>
> Don't have a setup to test D3D11VA with right now, but it does not break
> stuff on Linux and Cygwin. So if it works for you, that's LGTM as well.
>

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


[FFmpeg-devel] [PATCH 3/3] lavf/qsv_vpp: fix compiling warning

2017-11-15 Thread Zhong Li
fix the compiling warning of "ignoring return value"

Signed-off-by: Zhong Li 
---
 libavfilter/vf_vpp_qsv.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
index eb2f1cc..bc059cc 100644
--- a/libavfilter/vf_vpp_qsv.c
+++ b/libavfilter/vf_vpp_qsv.c
@@ -332,6 +332,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*picref)
 
 static int query_formats(AVFilterContext *ctx)
 {
+int ret;
 AVFilterFormats *in_fmts, *out_fmts;
 static const enum AVPixelFormat in_pix_fmts[] = {
 AV_PIX_FMT_YUV420P,
@@ -349,8 +350,10 @@ static int query_formats(AVFilterContext *ctx)
 
 in_fmts  = ff_make_format_list(in_pix_fmts);
 out_fmts = ff_make_format_list(out_pix_fmts);
-ff_formats_ref(in_fmts, >inputs[0]->out_formats);
-ff_formats_ref(out_fmts, >outputs[0]->in_formats);
+if ((ret = ff_formats_ref(in_fmts, >inputs[0]->out_formats)) < 0)
+return ret;
+if ((ret = ff_formats_ref(out_fmts, >outputs[0]->in_formats)) < 0)
+return ret;
 
 return 0;
 }
-- 
1.8.3.1

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


[FFmpeg-devel] [PATCH] Add FAQs about running in background (rev 2)

2017-11-15 Thread Jim DeLaHunt
Add two FAQs about running FFmpeg in the background.
The first explains the use of the -nostdin option in
a straightforward way. Text revised based on review.

The second FAQ starts from a confusing error message,
and leads to the solution, use of the -nostdin option.
The purpose of the second FAQ is to attract web searches
from people having the problem, and offer them a solution.

Add an anchor to the Main Options section of the ffmpeg
documentation, so that the FAQs can link directly there.
---
 doc/faq.texi| 65 +
 doc/ffmpeg.texi |  1 +
 2 files changed, 66 insertions(+)

diff --git a/doc/faq.texi b/doc/faq.texi
index dcaf89c6d2..73624c647e 100644
--- a/doc/faq.texi
+++ b/doc/faq.texi
@@ -501,6 +501,71 @@ ffmpeg -i ega_screen.nut -vf setdar=4/3 
ega_screen_anamorphic.nut
 ffmpeg -i ega_screen.nut -aspect 4/3 -c copy ega_screen_overridden.nut
 @end example
 
+@anchor{background task}
+@section How do I run ffmpeg as a background task?
+
+ffmpeg normally checks the console input, for entries like "q" to stop
+and "?" to give help, while performing operations. ffmpeg does not have a way 
of
+detecting when it is running as a background task.
+When it checks the console input, that can cause the process running ffmpeg
+in the background to suspend.
+
+To prevent those input checks, allowing ffmpeg to run as a background task,
+use the @url{ffmpeg.html#stdin-option, @code{-nostdin} option}
+in the ffmpeg invocation. This is effective whether you run ffmpeg in a shell
+or invoke ffmpeg in its own process via an operating system API.
+
+As an alternative, when you are running ffmpeg in a shell, you can redirect
+standard input to @code{/dev/null} (on Linux and Mac OS)
+or @code{NUL} (on Windows). You can do this redirect either
+on the ffmpeg invocation, or from a shell script which calls ffmpeg.
+
+For example:
+
+@example
+ffmpeg -nostdin -i INPUT OUTPUT
+@end example
+
+or (on Linux, Mac OS, and other UNIX-like shells):
+
+@example
+ffmpeg -i INPUT OUTPUT  ~/tmp/log.txt &
+[1] 93352
+%
+[1]  + suspended (tty output)  ffmpeg -i INPUT OUTPUT &>
+@end example
+
+The message "tty output" notwithstanding, the problem here is that
+ffmpeg normally checks the console input when it runs. The operating system
+detects this, and suspends the process until you can bring it to the
+foreground and attend to it.
+
+The solution is to use the right techniques to tell ffmpeg not to consult
+console input. You can use the
+@url{ffmpeg.html#stdin-option, @code{-nostdin} option},
+or redirect standard input with @code{< /dev/null}.
+See FAQ
+@ref{background task, @emph{How do I run ffmpeg as a background task?}}
+for details.
+
 @chapter Development
 
 @section Are there examples illustrating how to use the FFmpeg libraries, 
particularly libavcodec and libavformat?
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 7db80ebf6a..2bcad75973 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -470,6 +470,7 @@ the encoding process. It is made of "@var{key}=@var{value}" 
lines. @var{key}
 consists of only alphanumeric characters. The last key of a sequence of
 progress information is always "progress".
 
+@anchor{stdin option}
 @item -stdin
 Enable interaction on standard input. On by default unless standard input is
 used as an input. To explicitly disable interaction you need to specify
-- 
2.12.2

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


Re: [FFmpeg-devel] [PATCH v3 1/2] avformat/tcp: add option to enable TCP_NODELAY

2017-11-15 Thread Steven Liu
2017-11-15 13:01 GMT+08:00 Aman Gupta :
> From: Aman Gupta 
>
> This can reduce latency and increase throughput, particularly on high
> latency networks.
>
> Signed-off-by: Aman Gupta 
> Reviewed-by: Jeyapal, Karthick 
> ---
>  doc/protocols.texi| 3 +++
>  libavformat/network.h | 1 +
>  libavformat/tcp.c | 5 +
>  3 files changed, 9 insertions(+)
>
> diff --git a/doc/protocols.texi b/doc/protocols.texi
> index a7968ff56e..4d48f8a411 100644
> --- a/doc/protocols.texi
> +++ b/doc/protocols.texi
> @@ -1242,6 +1242,9 @@ Set receive buffer size, expressed bytes.
>
>  @item send_buffer_size=@var{bytes}
>  Set send buffer size, expressed bytes.
> +
> +@item tcp_nodelay=@var{1|0}
> +Set TCP_NODELAY to disable Nagle's algorithm. Default value is 0.
>  @end table
>
>  The following example shows how to setup a listening TCP connection
> diff --git a/libavformat/network.h b/libavformat/network.h
> index f83c796a95..b78e3ad6ed 100644
> --- a/libavformat/network.h
> +++ b/libavformat/network.h
> @@ -59,6 +59,7 @@ int ff_neterrno(void);
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #define ff_neterrno() AVERROR(errno)
> diff --git a/libavformat/tcp.c b/libavformat/tcp.c
> index 07b4ed9fa3..f3f9d4f431 100644
> --- a/libavformat/tcp.c
> +++ b/libavformat/tcp.c
> @@ -41,6 +41,7 @@ typedef struct TCPContext {
>  int listen_timeout;
>  int recv_buffer_size;
>  int send_buffer_size;
> +int tcp_nodelay;
>  } TCPContext;
>
>  #define OFFSET(x) offsetof(TCPContext, x)
> @@ -52,6 +53,7 @@ static const AVOption options[] = {
>  { "listen_timeout",  "Connection awaiting timeout (in milliseconds)",
>   OFFSET(listen_timeout), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 
> INT_MAX, .flags = D|E },
>  { "send_buffer_size", "Socket send buffer size (in bytes)",  
>   OFFSET(send_buffer_size), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 
> INT_MAX, .flags = D|E },
>  { "recv_buffer_size", "Socket receive buffer size (in bytes)",   
>   OFFSET(recv_buffer_size), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 
> INT_MAX, .flags = D|E },
> +{ "tcp_nodelay", "Use TCP_NODELAY to disable nagle's algorithm", 
>   OFFSET(tcp_nodelay), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, 
> .flags = D|E },
>  { NULL }
>  };
>
> @@ -148,6 +150,9 @@ static int tcp_open(URLContext *h, const char *uri, int 
> flags)
>  if (s->send_buffer_size > 0) {
>  setsockopt (fd, SOL_SOCKET, SO_SNDBUF, >send_buffer_size, sizeof 
> (s->send_buffer_size));
>  }
> +if (s->tcp_nodelay > 0) {
> +setsockopt (fd, IPPROTO_TCP, TCP_NODELAY, >tcp_nodelay, sizeof 
> (s->tcp_nodelay));
> +}
>
>  if (s->listen == 2) {
>  // multi-client
> --
> 2.14.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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