[FFmpeg-devel] [PATCH] avformat: Fix error when writing uncoded frames.

[Matt Oliver]

commit "lavf: add automatic bitstream filtering; bump version" broke the use
av_interleaved_write_uncoded_frame as any input uncoded frame has an
invalid packet size that will crash when av_packet_ref tries to allocate
'size'
new memory. Since the packet is a temporary created within mux itself it
can be used directly without needing a new ref.

Signed-off-by: Matt Oliver 
---
 libavformat/mux.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index 2da8cf2..cf1fb5c 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -832,11 +832,15 @@ int ff_interleave_add_packet(AVFormatContext *s,
AVPacket *pkt,
 if ((pkt->flags & AV_PKT_FLAG_UNCODED_FRAME)) {
 av_assert0(pkt->size == UNCODED_FRAME_PACKET_SIZE);
 av_assert0(((AVFrame *)pkt->data)->buf);
-}
-
-if ((ret = av_packet_ref(&this_pktl->pkt, pkt)) < 0) {
-av_free(this_pktl);
-return ret;
+this_pktl->pkt = *pkt;
+pkt->buf = NULL;
+pkt->side_data = NULL;
+pkt->side_data_elems = 0;
+} else {
+if ((ret = av_packet_ref(&this_pktl->pkt, pkt)) < 0) {
+av_free(this_pktl);
+return ret;
+}
 }

 if (s->streams[pkt->stream_index]->last_in_packet_buffer) {
--


0001-avformat-Fix-error-when-writing-uncoded-frames.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add nnedi filter

[Michael Niedermayer]

On Sat, Jan 23, 2016 at 07:53:59PM +0100, Paul B Mahol wrote:
> Hi,
> 
> patch attached.

>  configure|1 
>  libavfilter/Makefile |1 
>  libavfilter/allfilters.c |1 
>  libavfilter/vf_nnedi.c   |  939 
> +++
>  4 files changed, 942 insertions(+)
> fd0161c6e14c0f39f4fc344c1737713691a13f1d  0001-avfilter-add-nnedi-filter.patch
> From a41c741bb4d3146661e629552d750638a0bdc87c Mon Sep 17 00:00:00 2001
> From: Paul B Mahol 
> Date: Sat, 23 Jan 2016 17:15:53 +0100
> Subject: [PATCH] avfilter: add nnedi filter
> 
> Port of nnedi3 vapoursynth filter.

nice

this produces some warnings though

libavfilter/vf_nnedi.c: In function ‘copyPad’:
libavfilter/vf_nnedi.c:157:9: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c:188:13: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c:201:9: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c: In function ‘computeNetwork0_C’:
libavfilter/vf_nnedi.c:245:5: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c: In function ‘computeNetwork0_i16_C’:
libavfilter/vf_nnedi.c:262:5: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c: In function ‘computeNetwork0new_C’:
libavfilter/vf_nnedi.c:331:9: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c:340:5: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c: In function ‘evalFunc_0’:
libavfilter/vf_nnedi.c:360:9: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c:374:9: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c:378:9: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c: In function ‘extract_m8_C’:
libavfilter/vf_nnedi.c:425:5: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c:427:5: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c: In function ‘extract_m8_i16_C’:
libavfilter/vf_nnedi.c:449:5: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c: In function ‘evalFunc_1’:
libavfilter/vf_nnedi.c:503:9: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c:517:9: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c:524:17: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c:530:17: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c: In function ‘filter_frame’:
libavfilter/vf_nnedi.c:615:5: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c:626:5: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c:629:5: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c:635:9: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c:657:5: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c: In function ‘init’:
libavfilter/vf_nnedi.c:713:5: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c:729:5: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c:740:5: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c:770:9: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c:787:13: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c:812:17: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c:864:17: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavfilter/vf_nnedi.c:874:17: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


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

Re: [FFmpeg-devel] [PATCH] avfilter: add nnedi filter

[Paul B Mahol]

On 1/24/16, Michael Niedermayer  wrote:
> On Sat, Jan 23, 2016 at 07:53:59PM +0100, Paul B Mahol wrote:
>> Hi,
>>
>> patch attached.
>
>>  configure|1
>>  libavfilter/Makefile |1
>>  libavfilter/allfilters.c |1
>>  libavfilter/vf_nnedi.c   |  939
>> +++
>>  4 files changed, 942 insertions(+)
>> fd0161c6e14c0f39f4fc344c1737713691a13f1d
>> 0001-avfilter-add-nnedi-filter.patch
>> From a41c741bb4d3146661e629552d750638a0bdc87c Mon Sep 17 00:00:00 2001
>> From: Paul B Mahol 
>> Date: Sat, 23 Jan 2016 17:15:53 +0100
>> Subject: [PATCH] avfilter: add nnedi filter
>>
>> Port of nnedi3 vapoursynth filter.
>
> nice
>
> this produces some warnings though
>
> libavfilter/vf_nnedi.c: In function `copyPad':
> libavfilter/vf_nnedi.c:157:9: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c:188:13: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c:201:9: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c: In function `computeNetwork0_C':
> libavfilter/vf_nnedi.c:245:5: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c: In function `computeNetwork0_i16_C':
> libavfilter/vf_nnedi.c:262:5: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c: In function `computeNetwork0new_C':
> libavfilter/vf_nnedi.c:331:9: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c:340:5: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c: In function `evalFunc_0':
> libavfilter/vf_nnedi.c:360:9: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c:374:9: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c:378:9: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c: In function `extract_m8_C':
> libavfilter/vf_nnedi.c:425:5: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c:427:5: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c: In function `extract_m8_i16_C':
> libavfilter/vf_nnedi.c:449:5: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c: In function `evalFunc_1':
> libavfilter/vf_nnedi.c:503:9: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c:517:9: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c:524:17: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c:530:17: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c: In function `filter_frame':
> libavfilter/vf_nnedi.c:615:5: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c:626:5: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c:629:5: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c:635:9: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c:657:5: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c: In function `init':
> libavfilter/vf_nnedi.c:713:5: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c:729:5: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c:740:5: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c:770:9: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c:787:13: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c:812:17: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c:864:17: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]
> libavfilter/vf_nnedi.c:874:17: warning: ISO C90 forbids mixed declarations
> and code [-Wdeclaration-after-statement]

Hey, its 21 century!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailma

Re: [FFmpeg-devel] [PATCH] avfilter: add nnedi filter

[Andy Furniss]

Michael Niedermayer wrote:

On Sat, Jan 23, 2016 at 07:53:59PM +0100, Paul B Mahol wrote:

Hi,

patch attached.



  configure|1
  libavfilter/Makefile |1
  libavfilter/allfilters.c |1
  libavfilter/vf_nnedi.c   |  939 
+++
  4 files changed, 942 insertions(+)
fd0161c6e14c0f39f4fc344c1737713691a13f1d  0001-avfilter-add-nnedi-filter.patch
 From a41c741bb4d3146661e629552d750638a0bdc87c Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Sat, 23 Jan 2016 17:15:53 +0100
Subject: [PATCH] avfilter: add nnedi filter

Port of nnedi3 vapoursynth filter.


nice


Agree - but there's apparently no field parameter + will the required 
bin file be included?


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

Re: [FFmpeg-devel] [PATCH] avfilter: add nnedi filter

[Paul B Mahol]

On 1/24/16, Andy Furniss  wrote:
> Michael Niedermayer wrote:
>> On Sat, Jan 23, 2016 at 07:53:59PM +0100, Paul B Mahol wrote:
>>> Hi,
>>>
>>> patch attached.
>>
>>>   configure|1
>>>   libavfilter/Makefile |1
>>>   libavfilter/allfilters.c |1
>>>   libavfilter/vf_nnedi.c   |  939
>>> +++
>>>   4 files changed, 942 insertions(+)
>>> fd0161c6e14c0f39f4fc344c1737713691a13f1d
>>> 0001-avfilter-add-nnedi-filter.patch
>>>  From a41c741bb4d3146661e629552d750638a0bdc87c Mon Sep 17 00:00:00 2001
>>> From: Paul B Mahol 
>>> Date: Sat, 23 Jan 2016 17:15:53 +0100
>>> Subject: [PATCH] avfilter: add nnedi filter
>>>
>>> Port of nnedi3 vapoursynth filter.
>>
>> nice
>
> Agree - but there's apparently no field parameter + will the required
> bin file be included?

I forgot field parameter and other things.

No, bin file will not be included, it is few megabytes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add nnedi filter

[Andy Furniss]

Paul B Mahol wrote:

On 1/24/16, Andy Furniss  wrote:

Michael Niedermayer wrote:

On Sat, Jan 23, 2016 at 07:53:59PM +0100, Paul B Mahol wrote:

Hi,

patch attached.



configure|1 libavfilter/Makefile |
1 libavfilter/allfilters.c |1 libavfilter/vf_nnedi.c   |
939 +++ 4 files
changed, 942 insertions(+)
fd0161c6e14c0f39f4fc344c1737713691a13f1d
0001-avfilter-add-nnedi-filter.patch From
a41c741bb4d3146661e629552d750638a0bdc87c Mon Sep 17 00:00:00
2001 From: Paul B Mahol  Date: Sat, 23 Jan
2016 17:15:53 +0100 Subject: [PATCH] avfilter: add nnedi
filter

Port of nnedi3 vapoursynth filter.


nice


Agree - but there's apparently no field parameter + will the
required bin file be included?


I forgot field parameter and other things.

No, bin file will not be included, it is few megabytes.


OK, so maybe (if easily possible) it would be more user friendly to
mention it when it errors out due to not having one. I know it's named
in help - just a thought.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mpegtsenc: Fix multi program so that it supports adding the same stream to multiple programs.

[Michael Niedermayer]

On Sun, Jan 24, 2016 at 06:06:36AM +0100, Vittorio Gambaletta (VittGam) wrote:
> Signed-off-by: Vittorio Gambaletta 
> ---
>  libavformat/mpegtsenc.c |   15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
> index 2c12043..a20e229 100644
> --- a/libavformat/mpegtsenc.c
> +++ b/libavformat/mpegtsenc.c
> @@ -275,8 +275,19 @@ static int mpegts_write_pmt(AVFormatContext *s, 
> MpegTSService *service)
>  AVDictionaryEntry *lang = av_dict_get(st->metadata, "language", 
> NULL, 0);
>  
>  if (s->nb_programs) {
> -AVProgram *program = av_find_program_from_stream(s, NULL, i);
> -if (program->id != service->sid)
> +int j, k, found = 0;
> +
> +for (j = 0; j < s->nb_programs; j++)
> +if (s->programs[j]->id == service->sid) {
> +for (k = 0; k < s->programs[j]->nb_stream_indexes; k++)
> +if (s->programs[j]->stream_index[k] == i) {
> +found = 1;
> +break;
> +}
> +break;
> +}

av_find_program_from_stream() should be run in a loop to enumerate
the programs, see other uses of av_find_program_from_stream()

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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

Re: [FFmpeg-devel] [PATCH] avfilter: add nnedi filter

[Michael Niedermayer]

On Sun, Jan 24, 2016 at 10:50:37AM +0100, Paul B Mahol wrote:
> On 1/24/16, Michael Niedermayer  wrote:
> > On Sat, Jan 23, 2016 at 07:53:59PM +0100, Paul B Mahol wrote:
> >> Hi,
> >>
> >> patch attached.
> >
> >>  configure|1
> >>  libavfilter/Makefile |1
> >>  libavfilter/allfilters.c |1
> >>  libavfilter/vf_nnedi.c   |  939
> >> +++
> >>  4 files changed, 942 insertions(+)
> >> fd0161c6e14c0f39f4fc344c1737713691a13f1d
> >> 0001-avfilter-add-nnedi-filter.patch
> >> From a41c741bb4d3146661e629552d750638a0bdc87c Mon Sep 17 00:00:00 2001
> >> From: Paul B Mahol 
> >> Date: Sat, 23 Jan 2016 17:15:53 +0100
> >> Subject: [PATCH] avfilter: add nnedi filter
> >>
> >> Port of nnedi3 vapoursynth filter.
> >
> > nice
> >
> > this produces some warnings though
> >
> > libavfilter/vf_nnedi.c: In function `copyPad':
> > libavfilter/vf_nnedi.c:157:9: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c:188:13: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c:201:9: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c: In function `computeNetwork0_C':
> > libavfilter/vf_nnedi.c:245:5: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c: In function `computeNetwork0_i16_C':
> > libavfilter/vf_nnedi.c:262:5: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c: In function `computeNetwork0new_C':
> > libavfilter/vf_nnedi.c:331:9: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c:340:5: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c: In function `evalFunc_0':
> > libavfilter/vf_nnedi.c:360:9: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c:374:9: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c:378:9: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c: In function `extract_m8_C':
> > libavfilter/vf_nnedi.c:425:5: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c:427:5: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c: In function `extract_m8_i16_C':
> > libavfilter/vf_nnedi.c:449:5: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c: In function `evalFunc_1':
> > libavfilter/vf_nnedi.c:503:9: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c:517:9: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c:524:17: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c:530:17: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c: In function `filter_frame':
> > libavfilter/vf_nnedi.c:615:5: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c:626:5: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c:629:5: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c:635:9: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c:657:5: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c: In function `init':
> > libavfilter/vf_nnedi.c:713:5: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c:729:5: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c:740:5: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c:770:9: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c:787:13: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c:812:17: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/vf_nnedi.c:864:17: warning: ISO C90 forbids mixed declarations
> > and code [-Wdeclaration-after-statement]
> > libavfilter/

Re: [FFmpeg-devel] [PATCH] avformat: Document urls a bit

[Moritz Barsnick]

On Sat, Jan 23, 2016 at 00:36:51 +0100, Michael Niedermayer wrote:
>  libavformat/avformat.h |9 +
>  1 file changed, 9 insertions(+)

This will at least need some spelling fixes and commas. ;-)

> + * @section urls
> + * URLs in libavformat are made of a protocol a ':' and a protocol specific 
> string
> + * urls without a protocol and ':' used for local files are supported but
> + * deprecated. "file:" should be used for local files.
> + * It is important that the protocol string is not taken from untrusted 
> soucres
> + * without checks.
> + * some protocols are quite powerfull, allowing access to local and remote 
> files,
> + * parts of them, concatenations of them, local audio and video devices and 
> so on.

Such as:

  URL strings in libavformat are made of a protocol, a ':', and a protocol
  specific string. URLs without a protocol and ':' used for local files
  are supported but deprecated. "file:" should be used for local files.

  It is important that the protocol string is not taken from untrusted
  sources without checks.

  Note that some protocols are quite powerful, allowing access to both
  local and remote files, parts of them, concatenations of them, local
  audio and video devices and so on.


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

Re: [FFmpeg-devel] [PATCH] ffmpeg_opt: Allow program metadata other than title to be set.

[Michael Niedermayer]

On Sun, Jan 24, 2016 at 05:23:22AM +0100, Vittorio Gambaletta (VittGam) wrote:
> This commit makes it possible to add optional metadata (such as 
> "service_provider") to an mpegts output stream composed by multiple programs 
> (mpts).
> 
> This is needed because the global metadata is not inherited by the single 
> programs.
> 
> Signed-off-by: Vittorio Gambaletta 
> ---
>  ffmpeg_opt.c |   10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)

with this change the whole namespace except "st"/"program_num" would
be used for metadata. This might be a problem in the future if we
want to add some non metadata key/value

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

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


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

Re: [FFmpeg-devel] [PATCH 2/2] avformat: add protocol_whitelist

[Nicolas George]

Le quintidi 5 pluviôse, an CCXXIV, Michael Niedermayer a écrit :
> --- a/libavformat/avio.h
> +++ b/libavformat/avio.h
> @@ -595,6 +595,10 @@ int avio_open(AVIOContext **s, const char *url, int 
> flags);
>  int avio_open2(AVIOContext **s, const char *url, int flags,
> const AVIOInterruptCB *int_cb, AVDictionary **options);
>  
> +int avio_open_whitelist(AVIOContext **s, const char *url, int flags,
> + const AVIOInterruptCB *int_cb, AVDictionary 
> **options,
> + const char *whitelist);
> +

Please no! Adding new arguments to a function that already has too many and
using a string as a structured data structure: two things that are already
present way too much in the code base and should be avoided for future
design.

I suggest to put it in a structure, maybe AVIOSettings (or directly
AVGlobalSettings), as an array of protocols, and with int_cb while we are at
it:

typedef struct AVIOSettings {
AVIOInterruptCB *int_cb;
struct URLProtocol **protocols;
unsigned nb_protocols;
}

Then, if someone really like strings for user interface, they can do:

int avio_settings_set_protocols_whitelist_string(AVIOSettings *settings,
 const char *whitelist);

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Andreas Cadhalpun]

On 24.01.2016 03:19, Hendrik Leppkes wrote:
> The hastly pushed fix doesn't actually work,

It might not work in your environment, but it worked in Charlie's tests.

> all my MSVC fate boxes are still broken, ie.
> http://fatebeta.ffmpeg.org/report/x86_32-msvc14-dll-windows-native/20160123234847

They now use paths with 'C:\' twice:
C:\Dev\ffmpeg\git\C:\Dev\BuildEnv\MSYS2\Dev\ffmpeg\fate\x86_32-msvc2015-shared\build\libavdevice\avdevice.o

I think SRC_PATH, which is also set using $(pwd), needs the same adjustment as 
DST_PATH.

> Lets just revert this entire batch and re-try after proper testing and review.

You're very quick to suggest a revert here, but very reluctant about reverting
commit 31741ae. That's not consistent.
Thus I object to reverting this before the regression caused by 31741ae is 
fixed.

Also, please be a bit more constructive. Just complaining that it doesn't work
in your setup is not helpful, as I don't have that setup and thus can't 
investigate
the problem. At the very least I'd need to see the output of 'make V=1'.

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

[FFmpeg-devel] [PATCH] avfilter/vf_zoompan: do not cache all output frames in memory

[Paul B Mahol]

Hi,

patch attached.

Please comment.
From e6a47c61473d35e952957dfd74cc4ebd5a4f181e Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Sun, 24 Jan 2016 11:38:15 +0100
Subject: [PATCH] avfilter/vf_zoompan: rewrite so it doesn't cache all output
 frames

Signed-off-by: Paul B Mahol 
---
 libavfilter/vf_zoompan.c | 275 +++
 1 file changed, 161 insertions(+), 114 deletions(-)

diff --git a/libavfilter/vf_zoompan.c b/libavfilter/vf_zoompan.c
index c65ce56..7c02d3d 100644
--- a/libavfilter/vf_zoompan.c
+++ b/libavfilter/vf_zoompan.c
@@ -18,6 +18,7 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include "libavutil/avassert.h"
 #include "libavutil/eval.h"
 #include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
@@ -85,6 +86,12 @@ typedef struct ZPcontext {
 int prev_nb_frames;
 struct SwsContext *sws;
 int64_t frame_count;
+const AVPixFmtDescriptor *desc;
+AVFrame *in;
+double var_values[VARS_NB];
+int nb_frames;
+int current_frame;
+int frame_pending;
 } ZPContext;
 
 #define OFFSET(x) offsetof(ZPContext, x)
@@ -116,141 +123,179 @@ static int config_output(AVFilterLink *outlink)
 
 outlink->w = s->w;
 outlink->h = s->h;
+s->desc = av_pix_fmt_desc_get(outlink->format);
 
 return 0;
 }
 
+static int output_single_frame(AVFilterContext *ctx, AVFrame *in, double *var_values, int i,
+   double *zoom, double *dx, double *dy)
+{
+ZPContext *s = ctx->priv;
+AVFilterLink *outlink = ctx->outputs[0];
+int64_t pts = av_rescale_q(in->pts, ctx->inputs[0]->time_base,
+   outlink->time_base) + s->frame_count;
+int k, x, y, w, h, ret = 0;
+uint8_t *input[4];
+int px[4], py[4];
+AVFrame *out;
+
+var_values[VAR_TIME] = pts * av_q2d(outlink->time_base);
+var_values[VAR_FRAME] = i;
+var_values[VAR_ON] = outlink->frame_count + 1;
+if ((ret = av_expr_parse_and_eval(zoom, s->zoom_expr_str,
+  var_names, var_values,
+  NULL, NULL, NULL, NULL, NULL, 0, ctx)) < 0)
+return ret;
+
+*zoom = av_clipd(*zoom, 1, 10);
+var_values[VAR_ZOOM] = *zoom;
+w = in->width * (1.0 / *zoom);
+h = in->height * (1.0 / *zoom);
+
+if ((ret = av_expr_parse_and_eval(dx, s->x_expr_str,
+  var_names, var_values,
+  NULL, NULL, NULL, NULL, NULL, 0, ctx)) < 0)
+return ret;
+x = *dx = av_clipd(*dx, 0, FFMAX(in->width - w, 0));
+var_values[VAR_X] = *dx;
+x &= ~((1 << s->desc->log2_chroma_w) - 1);
+
+if ((ret = av_expr_parse_and_eval(dy, s->y_expr_str,
+  var_names, var_values,
+  NULL, NULL, NULL, NULL, NULL, 0, ctx)) < 0)
+return ret;
+y = *dy = av_clipd(*dy, 0, FFMAX(in->height - h, 0));
+var_values[VAR_Y] = *dy;
+y &= ~((1 << s->desc->log2_chroma_h) - 1);
+
+out = ff_get_video_buffer(outlink, outlink->w, outlink->h);
+if (!out) {
+ret = AVERROR(ENOMEM);
+return ret;
+}
+
+px[1] = px[2] = FF_CEIL_RSHIFT(x, s->desc->log2_chroma_w);
+px[0] = px[3] = x;
+
+py[1] = py[2] = FF_CEIL_RSHIFT(y, s->desc->log2_chroma_h);
+py[0] = py[3] = y;
+
+s->sws = sws_alloc_context();
+if (!s->sws) {
+ret = AVERROR(ENOMEM);
+return ret;
+}
+
+for (k = 0; in->data[k]; k++)
+input[k] = in->data[k] + py[k] * in->linesize[k] + px[k];
+
+av_opt_set_int(s->sws, "srcw", w, 0);
+av_opt_set_int(s->sws, "srch", h, 0);
+av_opt_set_int(s->sws, "src_format", in->format, 0);
+av_opt_set_int(s->sws, "dstw", outlink->w, 0);
+av_opt_set_int(s->sws, "dsth", outlink->h, 0);
+av_opt_set_int(s->sws, "dst_format", outlink->format, 0);
+av_opt_set_int(s->sws, "sws_flags", SWS_BICUBIC, 0);
+
+if ((ret = sws_init_context(s->sws, NULL, NULL)) < 0)
+return ret;
+
+sws_scale(s->sws, (const uint8_t *const *)&input, in->linesize, 0, h, out->data, out->linesize);
+
+out->pts = pts;
+s->frame_count++;
+
+ret = ff_filter_frame(outlink, out);
+sws_freeContext(s->sws);
+s->sws = NULL;
+return ret;
+}
+
 static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 {
 AVFilterContext *ctx = inlink->dst;
 AVFilterLink *outlink = ctx->outputs[0];
 ZPContext *s = ctx->priv;
-double var_values[VARS_NB], nb_frames, zoom, dx, dy;
-const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(in->format);
-AVFrame *out = NULL;
-int i, k, x, y, w, h, ret = 0;
-
-var_values[VAR_IN_W]  = var_values[VAR_IW] = in->width;
-var_values[VAR_IN_H]  = var_values[VAR_IH] = in->height;
-var_values[VAR_OUT_W] = var_values[VAR_OW] = s->w;
-var_values[VAR_OUT_H] = var_values[VAR_OH] = s->h;
-var_values[VAR_IN]= inlink->frame_count + 1;

Re: [FFmpeg-devel] [PATCH] avformat: Document urls a bit

[Michael Niedermayer]

On Sun, Jan 24, 2016 at 12:28:23PM +0100, Moritz Barsnick wrote:
> On Sat, Jan 23, 2016 at 00:36:51 +0100, Michael Niedermayer wrote:
> >  libavformat/avformat.h |9 +
> >  1 file changed, 9 insertions(+)
> 
> This will at least need some spelling fixes and commas. ;-)
> 
> > + * @section urls
> > + * URLs in libavformat are made of a protocol a ':' and a protocol 
> > specific string
> > + * urls without a protocol and ':' used for local files are supported but
> > + * deprecated. "file:" should be used for local files.
> > + * It is important that the protocol string is not taken from untrusted 
> > soucres
> > + * without checks.
> > + * some protocols are quite powerfull, allowing access to local and remote 
> > files,
> > + * parts of them, concatenations of them, local audio and video devices 
> > and so on.
> 
> Such as:
> 
>   URL strings in libavformat are made of a protocol, a ':', and a protocol
>   specific string. URLs without a protocol and ':' used for local files
>   are supported but deprecated. "file:" should be used for local files.
> 
>   It is important that the protocol string is not taken from untrusted
>   sources without checks.
> 
>   Note that some protocols are quite powerful, allowing access to both
>   local and remote files, parts of them, concatenations of them, local
>   audio and video devices and so on.

ok, updated
applied

PS: all further improvments welcome

thx

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

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- 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 v4 1/5] libavutil: VAAPI infrastructure

[wm4]

On Sat, 23 Jan 2016 16:34:45 -0800
Timothy Gu  wrote:

> On Sat, Jan 23, 2016 at 07:13:38PM +, Mark Thompson wrote:
> > +av_log(0, AV_LOG_ERROR, "Failed to destroy surface: "
> > +   "%d (%s).\n", vas, vaErrorStr(vas));  
> 
> Maybe you can consider adding an AVClass just for logging. Either way the “0”
> needs to be “NULL.”

(0 is perfectly fine, some libcs even define NULL to 0.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter: update some comments

[Paul B Mahol]

Hi,

patch attached.
From 5e1d45290115d2e865249d633ff1612877d8c0eb Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Sun, 24 Jan 2016 13:14:26 +0100
Subject: [PATCH] avfilter: update some docs

start_frame is no more, samplesref argument is now frame argument.

Signed-off-by: Paul B Mahol 
---
 libavfilter/avfilter.h | 2 +-
 libavfilter/internal.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
index 599369d..04bf585 100644
--- a/libavfilter/avfilter.h
+++ b/libavfilter/avfilter.h
@@ -491,7 +491,7 @@ struct AVFilterLink {
 
 /**
  * Link status.
- * If not zero, all attempts of start_frame, filter_frame or request_frame
+ * If not zero, all attempts of filter_frame or request_frame
  * will fail with the corresponding code, and if necessary the reference
  * will be destroyed.
  * If request_frame returns an error, the status is set on the
diff --git a/libavfilter/internal.h b/libavfilter/internal.h
index 766debe..769e65b 100644
--- a/libavfilter/internal.h
+++ b/libavfilter/internal.h
@@ -86,7 +86,7 @@ struct AVFilterPad {
  * Input pads only.
  *
  * @return >= 0 on success, a negative AVERROR on error. This function
- * must ensure that samplesref is properly unreferenced on error if it
+ * must ensure that frame is properly unreferenced on error if it
  * hasn't been passed on to another filter.
  */
 int (*filter_frame)(AVFilterLink *link, AVFrame *frame);
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] avformat: Document urls a bit

[Michael Niedermayer]

On Sun, Jan 24, 2016 at 01:02:28PM +0100, Michael Niedermayer wrote:
> On Sun, Jan 24, 2016 at 12:28:23PM +0100, Moritz Barsnick wrote:
> > On Sat, Jan 23, 2016 at 00:36:51 +0100, Michael Niedermayer wrote:
> > >  libavformat/avformat.h |9 +
> > >  1 file changed, 9 insertions(+)
> > 
> > This will at least need some spelling fixes and commas. ;-)
> > 
> > > + * @section urls
> > > + * URLs in libavformat are made of a protocol a ':' and a protocol 
> > > specific string
> > > + * urls without a protocol and ':' used for local files are supported but
> > > + * deprecated. "file:" should be used for local files.
> > > + * It is important that the protocol string is not taken from untrusted 
> > > soucres
> > > + * without checks.
> > > + * some protocols are quite powerfull, allowing access to local and 
> > > remote files,
> > > + * parts of them, concatenations of them, local audio and video devices 
> > > and so on.
> > 
> > Such as:
> > 
> >   URL strings in libavformat are made of a protocol, a ':', and a protocol
> >   specific string. URLs without a protocol and ':' used for local files
> >   are supported but deprecated. "file:" should be used for local files.
> > 
> >   It is important that the protocol string is not taken from untrusted
> >   sources without checks.
> > 
> >   Note that some protocols are quite powerful, allowing access to both
> >   local and remote files, parts of them, concatenations of them, local
> >   audio and video devices and so on.
> 
> ok, updated
> applied
> 
> PS: all further improvments welcome

slightly changed before push to align terminology more with the RFC

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Michael Niedermayer]

On Sun, Jan 24, 2016 at 12:52:37PM +0100, Andreas Cadhalpun wrote:
> On 24.01.2016 03:19, Hendrik Leppkes wrote:
> > The hastly pushed fix doesn't actually work,
> 
> It might not work in your environment, but it worked in Charlie's tests.
> 
> > all my MSVC fate boxes are still broken, ie.
> > http://fatebeta.ffmpeg.org/report/x86_32-msvc14-dll-windows-native/20160123234847
> 
> They now use paths with 'C:\' twice:
> C:\Dev\ffmpeg\git\C:\Dev\BuildEnv\MSYS2\Dev\ffmpeg\fate\x86_32-msvc2015-shared\build\libavdevice\avdevice.o
> 
> I think SRC_PATH, which is also set using $(pwd), needs the same adjustment 
> as DST_PATH.
> 
> > Lets just revert this entire batch and re-try after proper testing and 
> > review.
> 
> You're very quick to suggest a revert here, but very reluctant about reverting
> commit 31741ae. That's not consistent.
> Thus I object to reverting this before the regression caused by 31741ae is 
> fixed.
> 
> Also, please be a bit more constructive. Just complaining that it doesn't work
> in your setup is not helpful, as I don't have that setup and thus can't 
> investigate
> the problem. At the very least I'd need to see the output of 'make V=1'.

btw, i might be wrong but maybe this can be resolved quicker if you
and nevcairiel discuss this on IRC or something

just guessing ...

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

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


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

Re: [FFmpeg-devel] [PATCH v4 1/5] libavutil: VAAPI infrastructure

[wm4]

On Sat, 23 Jan 2016 19:13:38 +
Mark Thompson  wrote:

> ---
>  configure  |   5 +
>  libavutil/Makefile |   1 +
>  libavutil/vaapi.c  | 546 
> +
>  libavutil/vaapi.h  | 115 +++
>  4 files changed, 667 insertions(+)
>  create mode 100644 libavutil/vaapi.c
>  create mode 100644 libavutil/vaapi.h
> 
> diff --git a/configure b/configure
> index 8f4642b..cd386b4 100755
> --- a/configure
> +++ b/configure
> @@ -2042,6 +2042,7 @@ CONFIG_EXTRA="
>  texturedsp
>  texturedspenc
>  tpeldsp
> +vaapi_recent
>  videodsp
>  vp3dsp
>  vp56dsp
> @@ -5740,6 +5741,10 @@ enabled vaapi &&
>  check_lib va/va.h vaInitialize -lva ||
>  disable vaapi
> 
> +enabled vaapi &&
> +check_code cc va/va.h "vaCreateSurfaces(0, 0, 0, 0, 0, 0, 0, 0)" &&
> +enable vaapi_recent
> +
>  enabled vaapi && enabled xlib &&
>  check_lib2 "va/va.h va/va_x11.h" vaGetDisplay -lva -lva-x11 &&
>  enable vaapi_x11
> diff --git a/libavutil/Makefile b/libavutil/Makefile
> index 65b2d25..9d6a313 100644
> --- a/libavutil/Makefile
> +++ b/libavutil/Makefile
> @@ -148,6 +148,7 @@ OBJS-$(!HAVE_ATOMICS_NATIVE)+= atomic.o   
>   \
> 
>  OBJS-$(CONFIG_LZO)  += lzo.o
>  OBJS-$(CONFIG_OPENCL)   += opencl.o opencl_internal.o
> +OBJS-$(CONFIG_VAAPI_RECENT) += vaapi.o
> 
>  OBJS += $(COMPAT_OBJS:%=../compat/%)
> 
> diff --git a/libavutil/vaapi.c b/libavutil/vaapi.c
> new file mode 100644
> index 000..d5e67c4
> --- /dev/null
> +++ b/libavutil/vaapi.c
> @@ -0,0 +1,546 @@
> +/*
> + * VAAPI helper functions.
> + *
> + * Copyright (C) 2016 Mark Thompson 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include "vaapi.h"
> +
> +#include "avassert.h"
> +#include "imgutils.h"
> +#include "pixfmt.h"
> +
> +
> +AVVAAPIHardwareContext *av_vaapi_alloc_hardware_context(void)
> +{
> +return av_mallocz(sizeof(AVVAAPIHardwareContext));
> +}
> +
> +void av_vaapi_lock_hardware_context(AVVAAPIHardwareContext *ctx)
> +{
> +if(ctx->lock)
> +ctx->lock(ctx->lock_user_context);
> +}
> +
> +void av_vaapi_unlock_hardware_context(AVVAAPIHardwareContext *ctx)
> +{
> +if(ctx->unlock)
> +ctx->unlock(ctx->lock_user_context);
> +}
> +
> +
> +typedef struct AVVAAPISurface {
> +VASurfaceID id;
> +AVVAAPIHardwareContext *hardware_context;
> +
> +VAImage image;
> +void *mapped_address;
> +} AVVAAPISurface;
> +
> +static AVVAAPISurface *vaapi_get_surface(const AVFrame *frame)
> +{
> +av_assert0(frame);
> +av_assert0(frame->buf[0]);
> +av_assert0(frame->buf[0]->data);
> +return (AVVAAPISurface*)frame->buf[0]->data;
> +}
> +
> +static AVVAAPISurfaceConfig *vaapi_get_surface_config(const AVFrame *frame)
> +{
> +av_assert0(frame);
> +av_assert0(frame->buf[1]);
> +av_assert0(frame->buf[1]->data);
> +return (AVVAAPISurfaceConfig*)frame->buf[1]->data;
> +}
> +
> +static void vaapi_surface_free(void *opaque, uint8_t *data)
> +{
> +AVVAAPISurface *surface = (AVVAAPISurface*)data;
> +AVVAAPIHardwareContext *hw_ctx = surface->hardware_context;
> +VAStatus vas;
> +
> +av_vaapi_lock_hardware_context(hw_ctx);
> +
> +vas = vaDestroySurfaces(surface->hardware_context->display,
> +&surface->id, 1);
> +if(vas != VA_STATUS_SUCCESS) {
> +av_log(0, AV_LOG_ERROR, "Failed to destroy surface: "
> +   "%d (%s).\n", vas, vaErrorStr(vas));

I second that av_log should take a context in as many cases as possible.

> +}
> +
> +av_free(surface);
> +
> +av_vaapi_unlock_hardware_context(hw_ctx);
> +}
> +
> +int av_vaapi_surface_pool_init(AVVAAPISurfacePool *pool,
> +   AVVAAPIHardwareContext *hw_ctx,
> +   AVVAAPISurfaceConfig *config,
> +   int frame_count)
> +{
> +AVBufferRef *config_buffer;
> +AVVAAPISurface *surface;
> +AVFrame *frame;
> +VAStatus vas;
> +int i, err;
> +
> +memset(pool, 0, sizeof(*pool));
> +
> +pool->hardware_context = hw_ctx;
> +pool->frame_count = frame_count;
> +
> +config_buffe

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Hendrik Leppkes]

On Sun, Jan 24, 2016 at 12:52 PM, Andreas Cadhalpun
 wrote:
> On 24.01.2016 03:19, Hendrik Leppkes wrote:
>> The hastly pushed fix doesn't actually work,
>
> It might not work in your environment, but it worked in Charlie's tests.
>
>> all my MSVC fate boxes are still broken, ie.
>> http://fatebeta.ffmpeg.org/report/x86_32-msvc14-dll-windows-native/20160123234847
>
> They now use paths with 'C:\' twice:
> C:\Dev\ffmpeg\git\C:\Dev\BuildEnv\MSYS2\Dev\ffmpeg\fate\x86_32-msvc2015-shared\build\libavdevice\avdevice.o
>
> I think SRC_PATH, which is also set using $(pwd), needs the same adjustment 
> as DST_PATH.
>
>> Lets just revert this entire batch and re-try after proper testing and 
>> review.
>
> You're very quick to suggest a revert here, but very reluctant about reverting
> commit 31741ae. That's not consistent.

Broken build of git master and some behavior change you disagree with
are rather different things.

> Thus I object to reverting this before the regression caused by 31741ae is 
> fixed.

So you break building of git master, and you try to leverage this to
get your own agenda forward? Seriously?
I already conceded the other issue as long as it doesn't cause serious
regressions (ie. vp9), so get over yourself. Is this how debian does
business? Sounds like a fun place to be.

>
> Also, please be a bit more constructive. Just complaining that it doesn't work
> in your setup is not helpful, as I don't have that setup and thus can't 
> investigate
> the problem. At the very least I'd need to see the output of 'make V=1'.
>

Here have some output:
D:\Multimedia\ffmpeg\build>make V=1
cl -nologo -ID:/Multimedia/ffmpeg/build/
-I/d/Multimedia/ffmpeg/develop/ -D_ISOC99_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_WIN32_WINNT=0x0502
-DZLIB_CONST -DHAVE_AV_CONFIG_H -ID:/Multimedia/ffmpeg/build/
-I/d/Multimedia/ffmpeg/develop/ -D_ISOC99_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_WIN32_WINNT=0x0502
-DZLIB_CONST -DHAVE_AV_CONFIG_H -nologo -D_USE_MATH_DEFINES
-D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_WARNINGS-Z7 -W4
-wd4244 -wd4127 -wd4018 -wd4389 -wd4146 -wd4057 -wd4204 -wd4706
-wd4305 -wd4152 -wd4324 -we4013 -wd4100 -wd4214 -wd4307 -wd4273
-wd4554 -wd4701 -O2   -Oy-  -showIncludes -Zs
/d/Multimedia/ffmpeg/develop/libavdevice/alldevices.c 2>&1 | awk
'/including/ { sub(/^.*file: */, ""); gsub(/\\/, "/"); if (!match($0,
/ /)) print "libavdevice/alldevices.o:", $0 }' >
libavdevice/alldevices.d
cd /d/Multimedia/ffmpeg/develop; if [ -n
"/d/Multimedia/ffmpeg/develop" ]; then dest=libavdevice/alldevices.c;
else 
dest=D:/Multimedia/ffmpeg/build//d/Multimedia/ffmpeg/develop/libavdevice/alldevices.c;
fi; cl -ID:/Multimedia/ffmpeg/build/ -I/d/Multimedia/ffmpeg/develop/
-D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_WIN32_WINNT=0x0502 -DZLIB_CONST -DHAVE_AV_CONFIG_H -nologo
-D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS
-D_CRT_NONSTDC_NO_WARNINGS-Z7 -W4 -wd4244 -wd4127 -wd4018 -wd4389
-wd4146 -wd4057 -wd4204 -wd4706 -wd4305 -wd4152 -wd4324 -we4013
-wd4100 -wd4214 -wd4307 -wd4273 -wd4554 -wd4701 -O2   -Oy-   -c
-FoD:/Multimedia/ffmpeg/build/libavdevice/alldevices.o $dest
alldevices.c
D:\Multimedia\ffmpeg\develop\libavdevice\alldevices.c : fatal error
C1083: Cannot open compiler generated file:
'D:\Multimedia\ffmpeg\develop\D:\Multimedia\BuildEnv\MSYS2\Multimedia\ffmpeg\build\libavdevice\alldevices.o':
Invalid argument
/d/Multimedia/ffmpeg/develop/common.mak:61: recipe for target
'libavdevice/alldevices.o' failed
make: *** [libavdevice/alldevices.o] Error 1

It seems to screw up somewhere in the middle wherever this "dest=..."
comes from, I don't really know the makefiles that well.

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

Re: [FFmpeg-devel] [PATCH v4 2/5] ffmpeg: VAAPI hwaccel helper and related initialisation

[wm4]

On Sat, 23 Jan 2016 19:14:29 +
Mark Thompson  wrote:

> ---
>  Makefile   |   1 +
>  configure  |   5 +
>  ffmpeg.c   |   6 +
>  ffmpeg.h   |   5 +
>  ffmpeg_opt.c   |  16 ++
>  ffmpeg_vaapi.c | 633 
> +
>  6 files changed, 666 insertions(+)
>  create mode 100644 ffmpeg_vaapi.c
> 
> diff --git a/Makefile b/Makefile
> index f3bd5f6..4cccffd 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -37,6 +37,7 @@ OBJS-ffmpeg-$(CONFIG_VDA) += ffmpeg_videotoolbox.o
>  endif
>  OBJS-ffmpeg-$(CONFIG_VIDEOTOOLBOX) += ffmpeg_videotoolbox.o
>  OBJS-ffmpeg-$(CONFIG_LIBMFX)  += ffmpeg_qsv.o
> +OBJS-ffmpeg-$(CONFIG_VAAPI_RECENT) += ffmpeg_vaapi.o
>  OBJS-ffserver += ffserver_config.o
> 
>  TESTTOOLS   = audiogen videogen rotozoom tiny_psnr tiny_ssim base64
> diff --git a/configure b/configure
> index cd386b4..791334f 100755
> --- a/configure
> +++ b/configure
> @@ -1971,6 +1971,7 @@ HAVE_LIST="
>  section_data_rel_ro
>  texi2html
>  threads
> +vaapi_drm
>  vaapi_x11
>  vdpau_x11
>  xlib
> @@ -5749,6 +5750,10 @@ enabled vaapi && enabled xlib &&
>  check_lib2 "va/va.h va/va_x11.h" vaGetDisplay -lva -lva-x11 &&
>  enable vaapi_x11
> 
> +enabled vaapi &&
> +check_lib2 "va/va.h va/va_drm.h" vaGetDisplayDRM -lva -lva-drm &&
> +enable vaapi_drm
> +
>  enabled vdpau &&
>  check_cpp_condition vdpau/vdpau.h "defined 
> VDP_DECODER_PROFILE_MPEG4_PART2_ASP" ||
>  disable vdpau
> diff --git a/ffmpeg.c b/ffmpeg.c
> index 97aca10..5439761 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -2603,6 +2603,12 @@ static int init_output_stream(OutputStream *ost, char 
> *error, int error_len)
>  !av_dict_get(ost->encoder_opts, "ab", NULL, 0))
>  av_dict_set(&ost->encoder_opts, "b", "128000", 0);
> 
> +#if CONFIG_VAAPI_RECENT
> +if(ost->enc->type == AVMEDIA_TYPE_VIDEO &&
> +   strstr(ost->enc->name, "vaapi"))
> +vaapi_hardware_set_options(&ost->encoder_opts);
> +#endif
> +
>  if ((ret = avcodec_open2(ost->enc_ctx, codec, &ost->encoder_opts)) < 
> 0) {
>  if (ret == AVERROR_EXPERIMENTAL)
>  abort_codec_experimental(codec, 1);
> diff --git a/ffmpeg.h b/ffmpeg.h
> index 20322b0..2134213 100644
> --- a/ffmpeg.h
> +++ b/ffmpeg.h
> @@ -65,6 +65,7 @@ enum HWAccelID {
>  HWACCEL_VDA,
>  HWACCEL_VIDEOTOOLBOX,
>  HWACCEL_QSV,
> +HWACCEL_VAAPI,
>  };
> 
>  typedef struct HWAccel {
> @@ -577,5 +578,9 @@ int vda_init(AVCodecContext *s);
>  int videotoolbox_init(AVCodecContext *s);
>  int qsv_init(AVCodecContext *s);
>  int qsv_transcode_init(OutputStream *ost);
> +int vaapi_decode_init(AVCodecContext *s);
> +
> +int vaapi_hardware_init(const char *device);
> +int vaapi_hardware_set_options(AVDictionary **dict);
> 
>  #endif /* FFMPEG_H */
> diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
> index 9b341cf..fd41600 100644
> --- a/ffmpeg_opt.c
> +++ b/ffmpeg_opt.c
> @@ -82,6 +82,9 @@ const HWAccel hwaccels[] = {
>  #if CONFIG_LIBMFX
>  { "qsv",   qsv_init,   HWACCEL_QSV,   AV_PIX_FMT_QSV },
>  #endif
> +#if CONFIG_VAAPI_RECENT
> +{ "vaapi", vaapi_decode_init, HWACCEL_VAAPI, AV_PIX_FMT_VAAPI },
> +#endif
>  { 0 },
>  };
> 
> @@ -442,6 +445,15 @@ static int opt_sdp_file(void *optctx, const char *opt, 
> const char *arg)
>  return 0;
>  }
> 
> +#if CONFIG_VAAPI_RECENT
> +static int opt_vaapi(void *optctx, const char *opt, const char *arg)
> +{
> +if(vaapi_hardware_init(arg))
> +exit_program(1);
> +return 0;
> +}
> +#endif
> +
>  /**
>   * Parse a metadata specifier passed as 'arg' parameter.
>   * @param arg  metadata string to parse
> @@ -3438,5 +3450,9 @@ const OptionDef options[] = {
>  { "dn", OPT_BOOL | OPT_VIDEO | OPT_OFFSET | OPT_INPUT | OPT_OUTPUT, { 
> .off = OFFSET(data_disable) },
>  "disable data" },
> 
> +#if CONFIG_VAAPI_RECENT
> +{ "vaapi", HAS_ARG, { .func_arg = opt_vaapi }, "set VAAPI hardware 
> context" },
> +#endif
> +
>  { NULL, },
>  };
> diff --git a/ffmpeg_vaapi.c b/ffmpeg_vaapi.c
> new file mode 100644
> index 000..9a71cc2
> --- /dev/null
> +++ b/ffmpeg_vaapi.c
> @@ -0,0 +1,633 @@
> +/*
> + * VAAPI helper for hardware-accelerated decoding.
> + *
> + * Copyright (C) 2016 Mark Thompson 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFm

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Derek Buitenhuis]

On 1/24/2016 11:52 AM, Andreas Cadhalpun wrote:
> On 24.01.2016 03:19, Hendrik Leppkes wrote:
>> Lets just revert this entire batch and re-try after proper testing and 
>> review.
> 
> You're very quick to suggest a revert here, but very reluctant about reverting
> commit 31741ae. That's not consistent.

And you're very quick about pushing a broken patch after literally five minutes.

Myself, wm4, Timo, and James, I believe, were/are all in favour of a revert for
this (dst_path) patch, as well. Who exactly is supporting this slew of quick
fixes?

As for 31741ae, it's unrelated to this, and attacking someone based on a 
something
utterly unrelated is childish at best. (My opinion on 31741ae is: why the heck 
haven't
you been trying to fix it in VLC? My hunch is that it's less effort to make your
packages happy by just reverting it here.)

> Thus I object to reverting this before the regression caused by 31741ae is 
> fixed.

Oh, please. How old are we?

> Also, please be a bit more constructive. Just complaining that it doesn't work
> in your setup is not helpful, as I don't have that setup and thus can't 
> investigate
> the problem. At the very least I'd need to see the output of 'make V=1'.

One could argue the same for you. You'd rather push a bunch of different 
(broken)
fixes until it works instead of reverting and making *one* patch that works. 
That's
hardly constructive.

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat: add protocol_whitelist

[Clément Bœsch]

On Sun, Jan 24, 2016 at 12:47:59PM +0100, Nicolas George wrote:
> Le quintidi 5 pluviôse, an CCXXIV, Michael Niedermayer a écrit :
> > --- a/libavformat/avio.h
> > +++ b/libavformat/avio.h
> > @@ -595,6 +595,10 @@ int avio_open(AVIOContext **s, const char *url, int 
> > flags);
> >  int avio_open2(AVIOContext **s, const char *url, int flags,
> > const AVIOInterruptCB *int_cb, AVDictionary **options);
> >  
> > +int avio_open_whitelist(AVIOContext **s, const char *url, int flags,
> > + const AVIOInterruptCB *int_cb, AVDictionary 
> > **options,
> > + const char *whitelist);
> > +
> 
> Please no! Adding new arguments to a function that already has too many and
> using a string as a structured data structure: two things that are already
> present way too much in the code base and should be avoided for future
> design.
> 
> I suggest to put it in a structure, maybe AVIOSettings (or directly
> AVGlobalSettings), as an array of protocols, and with int_cb while we are at
> it:
> 
> typedef struct AVIOSettings {
> AVIOInterruptCB *int_cb;
> struct URLProtocol **protocols;
> unsigned nb_protocols;
> }
> 
> Then, if someone really like strings for user interface, they can do:
> 
> int avio_settings_set_protocols_whitelist_string(AVIOSettings *settings,
>  const char *whitelist);
> 

Why not an entry in the AVDictionary options?

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH v4 5/5] libavfilter: VAAPI surface converter

[wm4]

On Sat, 23 Jan 2016 19:17:00 +
Mark Thompson  wrote:

> ---
>  configure   |   2 +
>  libavfilter/Makefile|   1 +
>  libavfilter/allfilters.c|   1 +
>  libavfilter/vf_vaapi_conv.c | 537 
> 
>  4 files changed, 541 insertions(+)
>  create mode 100644 libavfilter/vf_vaapi_conv.c
> 
> diff --git a/configure b/configure
> index f30ddab..a068d05 100755
> --- a/configure
> +++ b/configure
> @@ -2920,6 +2920,7 @@ stereo3d_filter_deps="gpl"
>  subtitles_filter_deps="avformat avcodec libass"
>  super2xsai_filter_deps="gpl"
>  tinterlace_filter_deps="gpl"
> +vaapi_conv_filter_deps="vaapi_recent VAProcPipelineParameterBuffer"
>  vidstabdetect_filter_deps="libvidstab"
>  vidstabtransform_filter_deps="libvidstab"
>  pixfmts_super2xsai_test_deps="super2xsai_filter"
> @@ -5362,6 +5363,7 @@ check_type "va/va.h" "VAPictureParameterBufferHEVC"
>  check_type "va/va.h" "VADecPictureParameterBufferVP9"
>  check_type "va/va.h" "VAEncPictureParameterBufferH264"
>  check_type "va/va.h" "VAEncPictureParameterBufferHEVC"
> +check_type "va/va.h" "VAProcPipelineParameterBuffer"
> 
>  check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
> 
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index b93e5f2..c8ed7c8 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -248,6 +248,7 @@ OBJS-$(CONFIG_TRANSPOSE_FILTER)  += 
> vf_transpose.o
>  OBJS-$(CONFIG_TRIM_FILTER)   += trim.o
>  OBJS-$(CONFIG_UNSHARP_FILTER)+= vf_unsharp.o
>  OBJS-$(CONFIG_USPP_FILTER)   += vf_uspp.o
> +OBJS-$(CONFIG_VAAPI_CONV_FILTER) += vf_vaapi_conv.o
>  OBJS-$(CONFIG_VECTORSCOPE_FILTER)+= vf_vectorscope.o
>  OBJS-$(CONFIG_VFLIP_FILTER)  += vf_vflip.o
>  OBJS-$(CONFIG_VIDSTABDETECT_FILTER)  += vidstabutils.o 
> vf_vidstabdetect.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 1d48970..12e3859 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -268,6 +268,7 @@ void avfilter_register_all(void)
>  REGISTER_FILTER(TRIM,   trim,   vf);
>  REGISTER_FILTER(UNSHARP,unsharp,vf);
>  REGISTER_FILTER(USPP,   uspp,   vf);
> +REGISTER_FILTER(VAAPI_CONV, vaapi_conv, vf);
>  REGISTER_FILTER(VECTORSCOPE,vectorscope,vf);
>  REGISTER_FILTER(VFLIP,  vflip,  vf);
>  REGISTER_FILTER(VIDSTABDETECT,  vidstabdetect,  vf);
> diff --git a/libavfilter/vf_vaapi_conv.c b/libavfilter/vf_vaapi_conv.c
> new file mode 100644
> index 000..c8034e7
> --- /dev/null
> +++ b/libavfilter/vf_vaapi_conv.c
> @@ -0,0 +1,537 @@
> +/*
> + * VAAPI converter (scaling and colour conversion).
> + *
> + * Copyright (C) 2016 Mark Thompson 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include "avfilter.h"
> +#include "formats.h"
> +#include "internal.h"
> +
> +#include "libavutil/avassert.h"
> +#include "libavutil/opt.h"
> +#include "libavutil/pixdesc.h"
> +#include "libavutil/vaapi.h"
> +
> +#include 
> +
> +typedef struct VAAPIConvContext {
> +const AVClass *class;
> +
> +AVVAAPIHardwareContext *hardware_context;
> +AVVAAPIPipelineConfig  pipeline_config;
> +AVVAAPIPipelineContext pipeline;
> +int pipeline_initialised;
> +
> +int input_is_vaapi;
> +AVVAAPISurfaceConfig input_config;
> +AVVAAPISurfacePool   input_pool;
> +AVVAAPISurfaceConfig output_config;
> +AVVAAPISurfacePool   output_pool;
> +
> +int output_width;
> +int output_height;
> +
> +struct {
> +int64_t hardware_context;
> +int output_size[2];
> +} options;
> +
> +} VAAPIConvContext;
> +
> +
> +static int vaapi_conv_query_formats(AVFilterContext *avctx)
> +{
> +VAAPIConvContext *ctx = avctx->priv;
> +VAStatus vas;
> +VAConfigAttrib rt_format = {
> +.type = VAConfigAttribRTFormat
> +};
> +enum AVPixelFormat pix_fmt_list[16] = {
> +AV_PIX_FMT_VAAPI,
> +};
> +int pix_fmt_count = 1, err;
> +
> +#if 0
> +// The Intel driver doesn't return anything useful here - it only
> +// declares support for YUV 4:2:0 fo

Re: [FFmpeg-devel] [PATCH 2/2] avformat: add protocol_whitelist

[wm4]

On Sun, 24 Jan 2016 12:47:59 +0100
Nicolas George  wrote:

> Le quintidi 5 pluviôse, an CCXXIV, Michael Niedermayer a écrit :
> > --- a/libavformat/avio.h
> > +++ b/libavformat/avio.h
> > @@ -595,6 +595,10 @@ int avio_open(AVIOContext **s, const char *url, int 
> > flags);
> >  int avio_open2(AVIOContext **s, const char *url, int flags,
> > const AVIOInterruptCB *int_cb, AVDictionary **options);
> >  
> > +int avio_open_whitelist(AVIOContext **s, const char *url, int flags,
> > + const AVIOInterruptCB *int_cb, AVDictionary 
> > **options,
> > + const char *whitelist);
> > +  
> 
> Please no! Adding new arguments to a function that already has too many and
> using a string as a structured data structure: two things that are already
> present way too much in the code base and should be avoided for future
> design.
> 
> I suggest to put it in a structure, maybe AVIOSettings (or directly
> AVGlobalSettings), as an array of protocols, and with int_cb while we are at
> it:
> 
> typedef struct AVIOSettings {
> AVIOInterruptCB *int_cb;
> struct URLProtocol **protocols;
> unsigned nb_protocols;
> }

+1

In general, there might be even more things that have to be passed down
than these. I'm also wondering if proper event-based interruption could
be added later using this mechanism (AVIOInterruptCB can't be extended
due to ABI issues).

> 
> Then, if someone really like strings for user interface, they can do:
> 
> int avio_settings_set_protocols_whitelist_string(AVIOSettings *settings,
>  const char *whitelist);
> 
> Regards,
> 

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat: add protocol_whitelist

[wm4]

On Sun, 24 Jan 2016 13:43:40 +0100
Clément Bœsch  wrote:

> On Sun, Jan 24, 2016 at 12:47:59PM +0100, Nicolas George wrote:
> > Le quintidi 5 pluviôse, an CCXXIV, Michael Niedermayer a écrit :  
> > > --- a/libavformat/avio.h
> > > +++ b/libavformat/avio.h
> > > @@ -595,6 +595,10 @@ int avio_open(AVIOContext **s, const char *url, int 
> > > flags);
> > >  int avio_open2(AVIOContext **s, const char *url, int flags,
> > > const AVIOInterruptCB *int_cb, AVDictionary **options);
> > >  
> > > +int avio_open_whitelist(AVIOContext **s, const char *url, int flags,
> > > + const AVIOInterruptCB *int_cb, AVDictionary 
> > > **options,
> > > + const char *whitelist);
> > > +  
> > 
> > Please no! Adding new arguments to a function that already has too many and
> > using a string as a structured data structure: two things that are already
> > present way too much in the code base and should be avoided for future
> > design.
> > 
> > I suggest to put it in a structure, maybe AVIOSettings (or directly
> > AVGlobalSettings), as an array of protocols, and with int_cb while we are at
> > it:
> > 
> > typedef struct AVIOSettings {
> > AVIOInterruptCB *int_cb;
> > struct URLProtocol **protocols;
> > unsigned nb_protocols;
> > }
> > 
> > Then, if someone really like strings for user interface, they can do:
> > 
> > int avio_settings_set_protocols_whitelist_string(AVIOSettings *settings,
> >  const char *whitelist);
> >   
> 
> Why not an entry in the AVDictionary options?
> 

Can AVDictionary store pointers?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat: add protocol_whitelist

[Nicolas George]

Le quintidi 5 pluviôse, an CCXXIV, Clement Boesch a écrit :
> Why not an entry in the AVDictionary options?

That could be a short-term solution to avoid introducing a new API with
ad-hoc parameters, but AVDictionary is still based on strings exclusively,
that is very unpractical for applications. Furthermore, as I pointed out
earlier, just a whitelist at protocol level is not enough to fix all
security issues raised by playlists, especially all kind of cross-site
information leak. Furthermore, this AVGlobalSettings structure could be the
first step in getting rid of global state.

Still, you are probably right: people seem to be rushed about patching this
particularly visible instance of the issue, an entry in the AVDictionary
options is probably the simplest way of doing it right now without
introducing API changes that will need to be reverted after proper
designing.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH v4 5/5] libavfilter: VAAPI surface converter

[wm4]

On Sat, 23 Jan 2016 16:21:04 -0800
Timothy Gu  wrote:

> On Sat, Jan 23, 2016 at 07:17:00PM +, Mark Thompson wrote:
> > 
> > ---
> >  configure   |   2 +
> >  libavfilter/Makefile|   1 +
> >  libavfilter/allfilters.c|   1 +
> >  libavfilter/vf_vaapi_conv.c | 537 
> > 
> >  4 files changed, 541 insertions(+)
> >  create mode 100644 libavfilter/vf_vaapi_conv.c
> > 
> > diff --git a/configure b/configure
> > index f30ddab..a068d05 100755
> > --- a/configure
> > +++ b/configure

> 
> Perhaps stupid question: will VAAPI surfaces be converted to/from actual
> frames automatically (like the automatic format conversion that is in
> libavfilter right now) or will this filter be needed to be applied manually?

Do you mean automatic insertion as conversion filter? No.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavu: add ff_pthread_setname() and use it in various places

[Clément Bœsch]

On Wed, Jan 20, 2016 at 09:15:15PM -0300, James Almer wrote:
> On 1/20/2016 7:46 PM, Clément Bœsch wrote:
> > diff --git a/libavutil/thread.h b/libavutil/thread.h
> > index 32ddf40..42430fb 100644
> > --- a/libavutil/thread.h
> > +++ b/libavutil/thread.h
> > @@ -31,6 +31,15 @@
> >  #if HAVE_PTHREADS
> >  #include 
> >  
> > +static inline void ff_thread_setname(const char *name)
> > +{
> > +#if defined(__APPLE__)
> > +pthread_setname_np(name);
> > +#elif defined(__linux__) && defined(__GLIBC__)
> > +pthread_setname_np(pthread_self(), name);
> > +#endif
> > +}
> > +
> >  #if defined(ASSERT_LEVEL) && ASSERT_LEVEL > 1
> >  
> >  #include "log.h"
> > @@ -143,6 +152,7 @@ static inline int strict_pthread_once(pthread_once_t 
> > *once_control, void (*init_
> >  #define AV_ONCE_INIT PTHREAD_ONCE_INIT
> >  
> >  #define ff_thread_once(control, routine) pthread_once(control, routine)
> > +#define ff_thread_setname(name) (0)
> 
> This is also being applied to pthreads.

Damn, it's not a good excuse but I was tired and in a hurry that day.
Thanks for your patience, new patch attached.

-- 
Clément B.
From c8e30fee6c3ccc8f6de11351ade97c8fdedcccf3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20B=C5=93sch?= 
Date: Wed, 20 Jan 2016 21:30:32 +0100
Subject: [PATCH] lavu: add ff_pthread_setname() and use it in various places

---
 libavcodec/frame_thread_encoder.c |  2 ++
 libavcodec/pthread_frame.c|  2 ++
 libavcodec/pthread_slice.c|  2 ++
 libavfilter/pthread.c |  2 ++
 libavformat/async.c   |  2 ++
 libavformat/udp.c |  3 +++
 libavutil/thread.h| 13 +
 7 files changed, 26 insertions(+)

diff --git a/libavcodec/frame_thread_encoder.c b/libavcodec/frame_thread_encoder.c
index f4d35f9..87570a4 100644
--- a/libavcodec/frame_thread_encoder.c
+++ b/libavcodec/frame_thread_encoder.c
@@ -62,6 +62,8 @@ static void * attribute_align_arg worker(void *v){
 ThreadContext *c = avctx->internal->frame_thread_encoder;
 AVPacket *pkt = NULL;
 
+ff_thread_setname("lavc-frame-enc");
+
 while(!c->exit){
 int got_packet, ret;
 AVFrame *frame;
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index b77dd1e..6374d7c 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -132,6 +132,8 @@ static attribute_align_arg void *frame_worker_thread(void *arg)
 AVCodecContext *avctx = p->avctx;
 const AVCodec *codec = avctx->codec;
 
+ff_thread_setname("lavc-frame");
+
 pthread_mutex_lock(&p->mutex);
 while (1) {
 while (p->state == STATE_INPUT_READY && !fctx->die)
diff --git a/libavcodec/pthread_slice.c b/libavcodec/pthread_slice.c
index 96a7643..fbb4a53 100644
--- a/libavcodec/pthread_slice.c
+++ b/libavcodec/pthread_slice.c
@@ -70,6 +70,8 @@ static void* attribute_align_arg worker(void *v)
 int thread_count = avctx->thread_count;
 int self_id;
 
+ff_thread_setname("lavc-slice");
+
 pthread_mutex_lock(&c->current_job_lock);
 self_id = c->current_job++;
 for (;;){
diff --git a/libavfilter/pthread.c b/libavfilter/pthread.c
index 1c54193..53d4c74 100644
--- a/libavfilter/pthread.c
+++ b/libavfilter/pthread.c
@@ -63,6 +63,8 @@ static void* attribute_align_arg worker(void *v)
 unsigned int last_execute = 0;
 int self_id;
 
+ff_thread_setname("lavfi-worker");
+
 pthread_mutex_lock(&c->current_job_lock);
 self_id = c->current_job++;
 for (;;) {
diff --git a/libavformat/async.c b/libavformat/async.c
index 4308c4b..9f4d553 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -181,6 +181,8 @@ static void *async_buffer_task(void *arg)
 int   ret  = 0;
 int64_t   seek_ret;
 
+ff_thread_setname("lavf-async-buf");
+
 while (1) {
 int fifo_space, to_copy;
 
diff --git a/libavformat/udp.c b/libavformat/udp.c
index ea80e52..e053a91 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -35,6 +35,7 @@
 #include "libavutil/avstring.h"
 #include "libavutil/opt.h"
 #include "libavutil/log.h"
+#include "libavutil/thread.h"
 #include "libavutil/time.h"
 #include "internal.h"
 #include "network.h"
@@ -492,6 +493,8 @@ static void *circular_buffer_task( void *_URLContext)
 UDPContext *s = h->priv_data;
 int old_cancelstate;
 
+ff_thread_setname("udp-circ-buf");
+
 pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &old_cancelstate);
 pthread_mutex_lock(&s->mutex);
 if (ff_socket_nonblock(s->udp_fd, 0) < 0) {
diff --git a/libavutil/thread.h b/libavutil/thread.h
index 32ddf40..616250a 100644
--- a/libavutil/thread.h
+++ b/libavutil/thread.h
@@ -126,10 +126,21 @@ static inline int strict_pthread_once(pthread_once_t *once_control, void (*init_
 #define pthread_once   strict_pthread_once
 #endif
 
+static inline void ff_thread_setname(const char *name)
+{
+#if defined(__APPLE__)
+pthread_setname_np(name);
+#elif defined(__linux__) && defined(__GLIBC__)
+   

Re: [FFmpeg-devel] [PATCH v4 1/5] libavutil: VAAPI infrastructure

[Timo Rothenpieler]

>> +void *address;
>> +// On current Intel drivers, derive gives you memory which is very slow
>> +// to read (uncached?).  It can be better for write-only cases, but for
>> +// now play it safe and never use derive.
> 
> Still subject to debate when we introduce a "GPU memcpy".
> 
> I think someone on this list once even posted a patch to add such a
> memcpy, but it didn't get in yet.

Related article from Intel:

https://software.intel.com/en-us/articles/copying-accelerated-video-decode-frame-buffers

It contains a ready-to-use copy-function, which just has to be converted
from intrinsics to yasm.
And propably also needs a reversed counterpart, as it's designed to copy
from uswc memory to normal system memory, while ffmpeg also needs to
copy data into such uswc buffers.



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 2/2] avformat: add protocol_whitelist

[Clément Bœsch]

On Sun, Jan 24, 2016 at 01:57:05PM +0100, wm4 wrote:
> On Sun, 24 Jan 2016 13:43:40 +0100
> Clément Bœsch  wrote:
> 
> > On Sun, Jan 24, 2016 at 12:47:59PM +0100, Nicolas George wrote:
> > > Le quintidi 5 pluviôse, an CCXXIV, Michael Niedermayer a écrit :  
> > > > --- a/libavformat/avio.h
> > > > +++ b/libavformat/avio.h
> > > > @@ -595,6 +595,10 @@ int avio_open(AVIOContext **s, const char *url, 
> > > > int flags);
> > > >  int avio_open2(AVIOContext **s, const char *url, int flags,
> > > > const AVIOInterruptCB *int_cb, AVDictionary **options);
> > > >  
> > > > +int avio_open_whitelist(AVIOContext **s, const char *url, int flags,
> > > > + const AVIOInterruptCB *int_cb, AVDictionary 
> > > > **options,
> > > > + const char *whitelist);
> > > > +  
> > > 
> > > Please no! Adding new arguments to a function that already has too many 
> > > and
> > > using a string as a structured data structure: two things that are already
> > > present way too much in the code base and should be avoided for future
> > > design.
> > > 
> > > I suggest to put it in a structure, maybe AVIOSettings (or directly
> > > AVGlobalSettings), as an array of protocols, and with int_cb while we are 
> > > at
> > > it:
> > > 
> > > typedef struct AVIOSettings {
> > > AVIOInterruptCB *int_cb;
> > > struct URLProtocol **protocols;
> > > unsigned nb_protocols;
> > > }
> > > 
> > > Then, if someone really like strings for user interface, they can do:
> > > 
> > > int avio_settings_set_protocols_whitelist_string(AVIOSettings *settings,
> > >  const char *whitelist);
> > >   
> > 
> > Why not an entry in the AVDictionary options?
> > 
> 
> Can AVDictionary store pointers?

The patch seems to be about adding a white list as a string, so
key:"whitelist" → value:"file,http".

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] avfilter: update some comments

[Ronald S. Bultje]

Hi,

On Sun, Jan 24, 2016 at 7:17 AM, Paul B Mahol  wrote:

> Hi,
>
> patch attached.


lgtm.

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

Re: [FFmpeg-devel] [PATCH] lavu: add ff_pthread_setname() and use it in various places

[Clément Bœsch]

On Thu, Jan 21, 2016 at 10:52:46AM +0100, Moritz Barsnick wrote:
> On Wed, Jan 20, 2016 at 23:46:02 +0100, Clément Bœsch wrote:
> > Subject: [PATCH] lavu: add ff_pthread_setname() and use it in various places
> [...]
> > +static inline void ff_thread_setname(const char *name)
> 
> The commit message is out of line with the adapted function name.
> 

fixed locally, thanks

> Shouldn't the introduction of the new functionality and its use in
> various threads be split into two commits? Just wondering.
> 

it could, but it sounds a bit overkill in this case

[...]

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Ronald S. Bultje]

Hi,

On Sun, Jan 24, 2016 at 6:52 AM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:

> Thus I object to reverting this before the regression caused by 31741ae is
> fixed.


This is ridiculous, I (who didn't break it and don't even have hw
supporting any of our hwaccel implementatons) already proposed a method to
fix it _properly_ (without introducing alternate regressions) that everyone
agreed to. That is, everyone that responded. After a re-poke. And you
weren't one of them.

Which makes me wonder, you're very good at objecting, but you never give
+1s on good ideas that are different (but better) than your ideas. That's a
terrible attitude. You're not perfect. Other people's ideas can be better
than yours. Can you please look at my RFC in the related thread and comment
on the proposed fix? If you like it, that includes +1'ing it so I can
assume we have general consensus before I implement it and get bikeshedded
after doing work on it.

And after you've done that, can we not bring this subject and 31741ae up
again?

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

Re: [FFmpeg-devel] [PATCH v4 1/5] libavutil: VAAPI infrastructure

[wm4]

On Sun, 24 Jan 2016 13:58:59 +0100
Timo Rothenpieler  wrote:

> >> +void *address;
> >> +// On current Intel drivers, derive gives you memory which is very 
> >> slow
> >> +// to read (uncached?).  It can be better for write-only cases, but 
> >> for
> >> +// now play it safe and never use derive.  
> > 
> > Still subject to debate when we introduce a "GPU memcpy".
> > 
> > I think someone on this list once even posted a patch to add such a
> > memcpy, but it didn't get in yet.  
> 
> Related article from Intel:
> 
> https://software.intel.com/en-us/articles/copying-accelerated-video-decode-frame-buffers
> 
> It contains a ready-to-use copy-function, which just has to be converted
> from intrinsics to yasm.
> And propably also needs a reversed counterpart, as it's designed to copy
> from uswc memory to normal system memory, while ffmpeg also needs to
> copy data into such uswc buffers.
> 

Yes, though apparently we can get by without this additional "cache"
suggested on this page.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v4 5/5] libavfilter: VAAPI surface converter

[Mark Thompson]

On 24/01/16 00:21, Timothy Gu wrote:
> On Sat, Jan 23, 2016 at 07:17:00PM +, Mark Thompson wrote:
>> +err = ...(...);
>> +if(err) {
> 
> err < 0?
> 

Is there a policy on this?

For functions with only zero success or error code, I would prefer to check for 
nonzero as error.  It will catch any strange cases, including raising an error 
if the underlying API changes to have more different success cases that you 
need to modify the code to handle.

- Mark

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

Re: [FFmpeg-devel] [PATCH v4 5/5] libavfilter: VAAPI surface converter

[wm4]

On Sun, 24 Jan 2016 13:12:44 +
Mark Thompson  wrote:

> On 24/01/16 00:21, Timothy Gu wrote:
> > On Sat, Jan 23, 2016 at 07:17:00PM +, Mark Thompson wrote:  
> >> +err = ...(...);
> >> +if(err) {  
> > 
> > err < 0?
> >   
> 
> Is there a policy on this?
> 
> For functions with only zero success or error code, I would prefer to check 
> for nonzero as error.  It will catch any strange cases, including raising an 
> error if the underlying API changes to have more different success cases that 
> you need to modify the code to handle.

Almost all functions in ffmpeg that return error codes return <0 on
error, and >=0 on success. It would thus be advisable to follow this
convention.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v4 1/5] libavutil: VAAPI infrastructure

[Mark Thompson]

On 24/01/16 00:34, Timothy Gu wrote:
> On Sat, Jan 23, 2016 at 07:13:38PM +, Mark Thompson wrote:
>> +av_log(0, AV_LOG_ERROR, "Failed to destroy surface: "
>> +   "%d (%s).\n", vas, vaErrorStr(vas));
> 
> Maybe you can consider adding an AVClass just for logging. Either way the “0”
> needs to be “NULL.”

This got lost when most things got moved out of pipeline context (also making 
the class for that somewhat vestigial).

I'll add a new generic class and use it for everything in that file, I think.

- Mark

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

Re: [FFmpeg-devel] [PATCH v4 2/5] ffmpeg: VAAPI hwaccel helper and related initialisation

[Mark Thompson]

On 24/01/16 00:43, Timothy Gu wrote:
> On Sat, Jan 23, 2016 at 07:14:29PM +, Mark Thompson wrote:
>>
>> +#if CONFIG_VAAPI_RECENT
>> +{ "vaapi", HAS_ARG, { .func_arg = opt_vaapi }, "set VAAPI hardware 
>> context" },
> 
> What is "hardware context"? The address of an AVVAAPIHardwareContext? That
> makes no sense.
> 

It's the device string to pass to vaapi_hardware_init(), so something like ":0" 
(X11) or "/dev/dri/card0" (DRM).

Not sure what I was thinking with that string, I'll change it to something more 
sensible.  (Though still hoping that a better method to get this initialisation 
is possible.)

- Mark

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

Re: [FFmpeg-devel] [PATCH v4 2/5] ffmpeg: VAAPI hwaccel helper and related initialisation

[Paul B Mahol]

On 1/23/16, Mark Thompson  wrote:
>
> ---
>  Makefile   |   1 +
>  configure  |   5 +
>  ffmpeg.c   |   6 +
>  ffmpeg.h   |   5 +
>  ffmpeg_opt.c   |  16 ++
>  ffmpeg_vaapi.c | 633
> +
>  6 files changed, 666 insertions(+)

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

Re: [FFmpeg-devel] [PATCH v4 1/5] libavutil: VAAPI infrastructure

[Mark Thompson]

On 24/01/16 12:29, wm4 wrote:
> On Sat, 23 Jan 2016 19:13:38 +
> Mark Thompson  wrote:
> 
>> ---
>>  configure  |   5 +
>>  libavutil/Makefile |   1 +
>>  libavutil/vaapi.c  | 546 
>> +
>>  libavutil/vaapi.h  | 115 +++
>>  4 files changed, 667 insertions(+)
>>  create mode 100644 libavutil/vaapi.c
>>  create mode 100644 libavutil/vaapi.h
>>
>> diff --git a/configure b/configure
>> index 8f4642b..cd386b4 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2042,6 +2042,7 @@ CONFIG_EXTRA="
>>  texturedsp
>>  texturedspenc
>>  tpeldsp
>> +vaapi_recent
>>  videodsp
>>  vp3dsp
>>  vp56dsp
>> @@ -5740,6 +5741,10 @@ enabled vaapi &&
>>  check_lib va/va.h vaInitialize -lva ||
>>  disable vaapi
>>
>> +enabled vaapi &&
>> +check_code cc va/va.h "vaCreateSurfaces(0, 0, 0, 0, 0, 0, 0, 0)" &&
>> +enable vaapi_recent
>> +
>>  enabled vaapi && enabled xlib &&
>>  check_lib2 "va/va.h va/va_x11.h" vaGetDisplay -lva -lva-x11 &&
>>  enable vaapi_x11
>> diff --git a/libavutil/Makefile b/libavutil/Makefile
>> index 65b2d25..9d6a313 100644
>> --- a/libavutil/Makefile
>> +++ b/libavutil/Makefile
>> @@ -148,6 +148,7 @@ OBJS-$(!HAVE_ATOMICS_NATIVE)+= atomic.o  
>>\
>>
>>  OBJS-$(CONFIG_LZO)  += lzo.o
>>  OBJS-$(CONFIG_OPENCL)   += opencl.o opencl_internal.o
>> +OBJS-$(CONFIG_VAAPI_RECENT) += vaapi.o
>>
>>  OBJS += $(COMPAT_OBJS:%=../compat/%)
>>
>> diff --git a/libavutil/vaapi.c b/libavutil/vaapi.c
>> new file mode 100644
>> index 000..d5e67c4
>> --- /dev/null
>> +++ b/libavutil/vaapi.c
>> @@ -0,0 +1,546 @@
>> +/*
>> + * VAAPI helper functions.
>> + *
>> + * Copyright (C) 2016 Mark Thompson 
>> + *
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with FFmpeg; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
>> USA
>> + */
>> +
>> +#include "vaapi.h"
>> +
>> +#include "avassert.h"
>> +#include "imgutils.h"
>> +#include "pixfmt.h"
>> +
>> +
>> +AVVAAPIHardwareContext *av_vaapi_alloc_hardware_context(void)
>> +{
>> +return av_mallocz(sizeof(AVVAAPIHardwareContext));
>> +}
>> +
>> +void av_vaapi_lock_hardware_context(AVVAAPIHardwareContext *ctx)
>> +{
>> +if(ctx->lock)
>> +ctx->lock(ctx->lock_user_context);
>> +}
>> +
>> +void av_vaapi_unlock_hardware_context(AVVAAPIHardwareContext *ctx)
>> +{
>> +if(ctx->unlock)
>> +ctx->unlock(ctx->lock_user_context);
>> +}
>> +
>> +
>> +typedef struct AVVAAPISurface {
>> +VASurfaceID id;
>> +AVVAAPIHardwareContext *hardware_context;
>> +
>> +VAImage image;
>> +void *mapped_address;
>> +} AVVAAPISurface;
>> +
>> +static AVVAAPISurface *vaapi_get_surface(const AVFrame *frame)
>> +{
>> +av_assert0(frame);
>> +av_assert0(frame->buf[0]);
>> +av_assert0(frame->buf[0]->data);
>> +return (AVVAAPISurface*)frame->buf[0]->data;
>> +}
>> +
>> +static AVVAAPISurfaceConfig *vaapi_get_surface_config(const AVFrame *frame)
>> +{
>> +av_assert0(frame);
>> +av_assert0(frame->buf[1]);
>> +av_assert0(frame->buf[1]->data);
>> +return (AVVAAPISurfaceConfig*)frame->buf[1]->data;
>> +}
>> +
>> +static void vaapi_surface_free(void *opaque, uint8_t *data)
>> +{
>> +AVVAAPISurface *surface = (AVVAAPISurface*)data;
>> +AVVAAPIHardwareContext *hw_ctx = surface->hardware_context;
>> +VAStatus vas;
>> +
>> +av_vaapi_lock_hardware_context(hw_ctx);
>> +
>> +vas = vaDestroySurfaces(surface->hardware_context->display,
>> +&surface->id, 1);
>> +if(vas != VA_STATUS_SUCCESS) {
>> +av_log(0, AV_LOG_ERROR, "Failed to destroy surface: "
>> +   "%d (%s).\n", vas, vaErrorStr(vas));
> 
> I second that av_log should take a context in as many cases as possible.

Will add, as in other thread.

>> +}
>> +
>> +av_free(surface);
>> +
>> +av_vaapi_unlock_hardware_context(hw_ctx);
>> +}
>> +
>> +int av_vaapi_surface_pool_init(AVVAAPISurfacePool *pool,
>> +   AVVAAPIHardwareContext *hw_ctx,
>> +   AVVAAPISurfaceConfig *config,
>> +   int frame_count)
>> +{
>> +AVBufferRef *config_buffer;
>> +AVVAAPISurface *surfa

Re: [FFmpeg-devel] [PATCH 2/2] avformat: add protocol_whitelist

[Michael Niedermayer]

On Sun, Jan 24, 2016 at 12:47:59PM +0100, Nicolas George wrote:
> Le quintidi 5 pluviôse, an CCXXIV, Michael Niedermayer a écrit :
> > --- a/libavformat/avio.h
> > +++ b/libavformat/avio.h
> > @@ -595,6 +595,10 @@ int avio_open(AVIOContext **s, const char *url, int 
> > flags);
> >  int avio_open2(AVIOContext **s, const char *url, int flags,
> > const AVIOInterruptCB *int_cb, AVDictionary **options);
> >  
> > +int avio_open_whitelist(AVIOContext **s, const char *url, int flags,
> > + const AVIOInterruptCB *int_cb, AVDictionary 
> > **options,
> > + const char *whitelist);
> > +
> 
> Please no! Adding new arguments to a function that already has too many and

the argument is added, not out of strict need, (there already is a
AVDictionary that can be used) but to make it clear that the author
set the whitelist correctly. Also it simplifies the code compared
to using the AVDictionary.

security relevant code should be clear and explicit so that a
mistake in the code can easily be spotted. Its very hard to spot that
a passed dictionary doesnt carry/lost the whitelist, easy to spot that
a argument is missed and set to NULL


> using a string as a structured data structure: two things that are already
> present way too much in the code base and should be avoided for future
> design.
> 
> I suggest to put it in a structure, maybe AVIOSettings (or directly
> AVGlobalSettings), as an array of protocols, and with int_cb while we are at
> it:
> 
> typedef struct AVIOSettings {
> AVIOInterruptCB *int_cb;
> struct URLProtocol **protocols;
> unsigned nb_protocols;
> }

we use string whitelists for codecs and formats, using a differnet
system for protocols would be inconsistent at least

The struct suggested has a few flaws as well
URLProtocols are not public so lists of pointers to them in a "AV*"
that is public struct might cause problems

also if the same is done for codecs and formats you have 3 such
structs with the need for 3 sets of allocators, deallocators and
probably a few helper functions for each to construct them.
then new function prototypes could be needed for
encoder, decoder, audio, video, subtitles, muxers, demuxers and
protocols to pass in these structs. (depending on details of the API)
also to maintain support for the existng codec/format whitelists
convertion and merging code would be needed

this is alot of complexity

another problem of the struct is that depending on from which lib
the protocols are set the same protocol may have unequal pointers

which system do people prefer ?
do we have a volunteer to implement a struct based system ?

do people want the string based solution to be applied till then
or to not have this security feature until then ?


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange


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

Re: [FFmpeg-devel] [PATCH 2/2] avformat: add protocol_whitelist

[Michael Niedermayer]

On Sun, Jan 24, 2016 at 01:56:51PM +0100, Nicolas George wrote:
> Le quintidi 5 pluviôse, an CCXXIV, Clement Boesch a écrit :
> > Why not an entry in the AVDictionary options?
> 
> That could be a short-term solution to avoid introducing a new API with
> ad-hoc parameters, but AVDictionary is still based on strings exclusively,
> that is very unpractical for applications. Furthermore, as I pointed out
> earlier, just a whitelist at protocol level is not enough to fix all
> security issues raised by playlists, especially all kind of cross-site
> information leak. Furthermore, this AVGlobalSettings structure could be the
> first step in getting rid of global state.
> 

> Still, you are probably right: people seem to be rushed about patching this
> particularly visible instance of the issue, an entry in the AVDictionary
> options is probably the simplest way of doing it right now without
> introducing API changes that will need to be reverted after proper
> designing.

I avoided AVDictionaries a bit in the patch for 2 reasons

the first is that its more code, setting a whitelist in a AVDictionary
can always fail (ENOMEM), also depending on later failure pathes
the added whitelist needs to be freed
that would be duplicated code around *_open() which ive added in a
new *_open_whitelist(), that of course coulde be kept as a private
function in libavformat if preferred ?

the 2nd reason is that option semantics remove "consumed" parameters
from the AVDictionary options. So the whitelist has a tendency to be
removed from the AVDictionary. Which is not good security wise when
NULL is considered "everything"

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.


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

Re: [FFmpeg-devel] [PATCH v4 2/5] ffmpeg: VAAPI hwaccel helper and related initialisation

[Mark Thompson]

On 24/01/16 12:42, wm4 wrote:
> On Sat, 23 Jan 2016 19:14:29 +
> Mark Thompson  wrote:
> 
>> ---
>>  Makefile   |   1 +
>>  configure  |   5 +
>>  ffmpeg.c   |   6 +
>>  ffmpeg.h   |   5 +
>>  ffmpeg_opt.c   |  16 ++
>>  ffmpeg_vaapi.c | 633 
>> +
>>  6 files changed, 666 insertions(+)
>>  create mode 100644 ffmpeg_vaapi.c
>>
>> diff --git a/Makefile b/Makefile
>> index f3bd5f6..4cccffd 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -37,6 +37,7 @@ OBJS-ffmpeg-$(CONFIG_VDA) += ffmpeg_videotoolbox.o
>>  endif
>>  OBJS-ffmpeg-$(CONFIG_VIDEOTOOLBOX) += ffmpeg_videotoolbox.o
>>  OBJS-ffmpeg-$(CONFIG_LIBMFX)  += ffmpeg_qsv.o
>> +OBJS-ffmpeg-$(CONFIG_VAAPI_RECENT) += ffmpeg_vaapi.o
>>  OBJS-ffserver += ffserver_config.o
>>
>>  TESTTOOLS   = audiogen videogen rotozoom tiny_psnr tiny_ssim base64
>> diff --git a/configure b/configure
>> index cd386b4..791334f 100755
>> --- a/configure
>> +++ b/configure
>> @@ -1971,6 +1971,7 @@ HAVE_LIST="
>>  section_data_rel_ro
>>  texi2html
>>  threads
>> +vaapi_drm
>>  vaapi_x11
>>  vdpau_x11
>>  xlib
>> @@ -5749,6 +5750,10 @@ enabled vaapi && enabled xlib &&
>>  check_lib2 "va/va.h va/va_x11.h" vaGetDisplay -lva -lva-x11 &&
>>  enable vaapi_x11
>>
>> +enabled vaapi &&
>> +check_lib2 "va/va.h va/va_drm.h" vaGetDisplayDRM -lva -lva-drm &&
>> +enable vaapi_drm
>> +
>>  enabled vdpau &&
>>  check_cpp_condition vdpau/vdpau.h "defined 
>> VDP_DECODER_PROFILE_MPEG4_PART2_ASP" ||
>>  disable vdpau
>> diff --git a/ffmpeg.c b/ffmpeg.c
>> index 97aca10..5439761 100644
>> --- a/ffmpeg.c
>> +++ b/ffmpeg.c
>> @@ -2603,6 +2603,12 @@ static int init_output_stream(OutputStream *ost, char 
>> *error, int error_len)
>>  !av_dict_get(ost->encoder_opts, "ab", NULL, 0))
>>  av_dict_set(&ost->encoder_opts, "b", "128000", 0);
>>
>> +#if CONFIG_VAAPI_RECENT
>> +if(ost->enc->type == AVMEDIA_TYPE_VIDEO &&
>> +   strstr(ost->enc->name, "vaapi"))
>> +vaapi_hardware_set_options(&ost->encoder_opts);
>> +#endif
>> +
>>  if ((ret = avcodec_open2(ost->enc_ctx, codec, &ost->encoder_opts)) 
>> < 0) {
>>  if (ret == AVERROR_EXPERIMENTAL)
>>  abort_codec_experimental(codec, 1);
>> diff --git a/ffmpeg.h b/ffmpeg.h
>> index 20322b0..2134213 100644
>> --- a/ffmpeg.h
>> +++ b/ffmpeg.h
>> @@ -65,6 +65,7 @@ enum HWAccelID {
>>  HWACCEL_VDA,
>>  HWACCEL_VIDEOTOOLBOX,
>>  HWACCEL_QSV,
>> +HWACCEL_VAAPI,
>>  };
>>
>>  typedef struct HWAccel {
>> @@ -577,5 +578,9 @@ int vda_init(AVCodecContext *s);
>>  int videotoolbox_init(AVCodecContext *s);
>>  int qsv_init(AVCodecContext *s);
>>  int qsv_transcode_init(OutputStream *ost);
>> +int vaapi_decode_init(AVCodecContext *s);
>> +
>> +int vaapi_hardware_init(const char *device);
>> +int vaapi_hardware_set_options(AVDictionary **dict);
>>
>>  #endif /* FFMPEG_H */
>> diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
>> index 9b341cf..fd41600 100644
>> --- a/ffmpeg_opt.c
>> +++ b/ffmpeg_opt.c
>> @@ -82,6 +82,9 @@ const HWAccel hwaccels[] = {
>>  #if CONFIG_LIBMFX
>>  { "qsv",   qsv_init,   HWACCEL_QSV,   AV_PIX_FMT_QSV },
>>  #endif
>> +#if CONFIG_VAAPI_RECENT
>> +{ "vaapi", vaapi_decode_init, HWACCEL_VAAPI, AV_PIX_FMT_VAAPI },
>> +#endif
>>  { 0 },
>>  };
>>
>> @@ -442,6 +445,15 @@ static int opt_sdp_file(void *optctx, const char *opt, 
>> const char *arg)
>>  return 0;
>>  }
>>
>> +#if CONFIG_VAAPI_RECENT
>> +static int opt_vaapi(void *optctx, const char *opt, const char *arg)
>> +{
>> +if(vaapi_hardware_init(arg))
>> +exit_program(1);
>> +return 0;
>> +}
>> +#endif
>> +
>>  /**
>>   * Parse a metadata specifier passed as 'arg' parameter.
>>   * @param arg  metadata string to parse
>> @@ -3438,5 +3450,9 @@ const OptionDef options[] = {
>>  { "dn", OPT_BOOL | OPT_VIDEO | OPT_OFFSET | OPT_INPUT | OPT_OUTPUT, { 
>> .off = OFFSET(data_disable) },
>>  "disable data" },
>>
>> +#if CONFIG_VAAPI_RECENT
>> +{ "vaapi", HAS_ARG, { .func_arg = opt_vaapi }, "set VAAPI hardware 
>> context" },
>> +#endif
>> +
>>  { NULL, },
>>  };
>> diff --git a/ffmpeg_vaapi.c b/ffmpeg_vaapi.c
>> new file mode 100644
>> index 000..9a71cc2
>> --- /dev/null
>> +++ b/ffmpeg_vaapi.c
>> @@ -0,0 +1,633 @@
>> +/*
>> + * VAAPI helper for hardware-accelerated decoding.
>> + *
>> + * Copyright (C) 2016 Mark Thompson 
>> + *
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PU

Re: [FFmpeg-devel] [PATCH 2/2] avformat: add protocol_whitelist

[Andreas Cadhalpun]

On 24.01.2016 03:42, Michael Niedermayer wrote:
> From: Michael Niedermayer 
> 
> TODO: Docs
> TODO: version bump
> 
> Note to maintainers: update tools
> 
> Note, testing and checking for missing changes is needed
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  ffmpeg_opt.c  |4 ++--
>  libavdevice/lavfi.c   |2 +-
>  libavformat/async.c   |2 +-
>  libavformat/avformat.h|7 ++
>  libavformat/avio.c|   44 
> ++---
>  libavformat/avio.h|4 
>  libavformat/aviobuf.c |   16 ++
>  libavformat/cache.c   |3 ++-
>  libavformat/concat.c  |5 +++--
>  libavformat/crypto.c  |5 +++--
>  libavformat/dashenc.c |9 
>  libavformat/ftp.c |   10 +
>  libavformat/gopher.c  |4 ++--
>  libavformat/hdsenc.c  |   12 +-
>  libavformat/hls.c |8 ---
>  libavformat/hlsenc.c  |   28 +++
>  libavformat/hlsproto.c|   10 +
>  libavformat/http.c|   16 +-
>  libavformat/icecast.c |3 ++-
>  libavformat/md5proto.c|5 +++--
>  libavformat/mmst.c|5 +++--
>  libavformat/movenc.c  |2 +-
>  libavformat/options_table.h   |1 +
>  libavformat/rtmpcrypt.c   |5 +++--
>  libavformat/rtmpproto.c   |   10 +
>  libavformat/rtpproto.c|   10 ++---
>  libavformat/rtsp.c|   20 -
>  libavformat/rtspdec.c |   10 +
>  libavformat/sapdec.c  |5 +++--
>  libavformat/sapenc.c  |9 +---
>  libavformat/segment.c |   16 +++---
>  libavformat/smoothstreamingenc.c  |   18 ---
>  libavformat/srtpproto.c   |3 ++-
>  libavformat/subfile.c |3 ++-
>  libavformat/tee.c |4 +++-
>  libavformat/tls.c |5 +++--
>  libavformat/tls_securetransport.c |5 +++--
>  libavformat/url.h |5 +
>  libavformat/utils.c   |   13 +++
>  libavformat/webm_chunk.c  |7 +++---
>  40 files changed, 230 insertions(+), 123 deletions(-)
> 

To make reviewing easier it would be nice to split this into a patch
that adds the protocol_whitelist mechanism and a subsequent one,
which forwards the protocol_whitelist where necessary.

> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 4964263..2fb9130 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -1815,6 +1815,13 @@ typedef struct AVFormatContext {
>   * Demuxing: Set by user.
>   */
>  int (*open_cb)(struct AVFormatContext *s, AVIOContext **p, const char 
> *url, int flags, const AVIOInterruptCB *int_cb, AVDictionary **options);
> +
> +/**
> + * ',' separated list of allowed protocols.
> + * - encoding: unused
> + * - decoding: set by user through AVOptions (NO direct access)
> + */
> +char *protocol_whitelist;
>  } AVFormatContext;

I'm not sure if adding protocol_whitelist to the AVFormatContext is good.
Conceptually it would fit better in the AVIOContext. I think that would also
make it easier to set a default for it.

> diff --git a/libavformat/avio.c b/libavformat/avio.c
> index 05d0557..ad9712d 100644
> --- a/libavformat/avio.c
> +++ b/libavformat/avio.c
[...]
> @@ -296,18 +302,43 @@ int ffurl_alloc(URLContext **puc, const char *filename, 
> int flags,
>  return AVERROR_PROTOCOL_NOT_FOUND;
>  }
>  
> -int ffurl_open(URLContext **puc, const char *filename, int flags,
> -   const AVIOInterruptCB *int_cb, AVDictionary **options)
> +int ffurl_open_whitelist(URLContext **puc, const char *filename, int flags,
> + const AVIOInterruptCB *int_cb, AVDictionary 
> **options, const char *whitelist)
>  {
> +AVDictionary *tmp_opts = NULL;
> +AVDictionaryEntry *e;
>  int ret = ffurl_alloc(puc, filename, flags, int_cb);
>  if (ret < 0)
>  return ret;
>  if (options && (*puc)->prot->priv_data_class &&
>  (ret = av_opt_set_dict((*puc)->priv_data, options)) < 0)
>  goto fail;
> +
> +if (!options)
> +options = &tmp_opts;
> +
> +av_assert0(!whitelist ||
> +   !(e=av_dict_get(*options, "protocol_whitelist", NULL, 0)) ||
> +   !strcmp(whitelist, e->value));
> +
> +if ((ret = av_dict_set(options, "protocol_whitelist", whitelist, 0)) < 0)
> +goto fail;
> +

Wouldn't it be much simpler to pass the protocol_whitelist directly in options
to ffurl_open, instead of adding a new function with a new parameter, just
to set the option here.
That way one could avoid the need for a new public avio_open_whitelist functio

Re: [FFmpeg-devel] [PATCH v4 1/5] libavutil: VAAPI infrastructure

[wm4]

On Sun, 24 Jan 2016 13:44:47 +
Mark Thompson  wrote:

> ...
> >> +
> >> +vas = vaSyncSurface(hw_ctx->display, surface->id);  
> > 
> > Is this strictly needed? (I don't know.)  
> 
> It's definitely needed in some cases - the hwaccel decoder does not call 
> vaSyncSurface(), so we have to somewhere on the path to copying the data out.

OK then.

> 
> It could be separated, but if someone else has already called it then it's 
> idempotent so it seems sensible to leave it here,
> 
> >> +if(vas != VA_STATUS_SUCCESS) {
> >> +av_log(0, AV_LOG_ERROR, "Failed to sync surface "
> >> +   "%#x: %d (%s).\n", surface->id, vas, vaErrorStr(vas));
> >> +err = AVERROR_EXTERNAL;
> >> +goto fail;
> >> +}
> >> +
> >> +if(derive) {
> >> +vas = vaDeriveImage(hw_ctx->display,
> >> +surface->id, image);
> >> +if(vas != VA_STATUS_SUCCESS) {
> >> +av_log(0, AV_LOG_ERROR, "Failed to derive image from surface "
> >> +   "%#x: %d (%s).\n", surface->id, vas, vaErrorStr(vas)); 
> >>  
> > 
> > Is it guaranteed that surface->id is an unsigned int and VAStatus is
> > int? I know the typedefs resolve to these types, but is there a chance
> > a future libva version will change them?
> > 
> > Also, this message should probably not be an error, but a verbose at
> > most. (Since it can gracefully fallback to the code path below.)  
> 
> I've assumed unsigned int / int throughout.
> 
> The alternative is adding PRIxVASurfaceID and PRIdVAStatus macros which look 
> at libva version, which rather seems like overkill.
> 
> Anyway, VASurfaceID == unsigned int at least is already baked into their ABI 
> (it's in a lot of the parameter structures).

If we care, we should do something that can't break if libva ever
changes it, and e.g. cast the values when passing them to printf.

Anyway, it's probably fine to ignore this, since libva would have to
break their ABI anyway.

> >> +derive = 0;
> >> +}
> >> +}
> >> +if(!derive) {
> >> +vas = vaCreateImage(hw_ctx->display, &config->image_format,
> >> +config->width, config->height, image);
> >> +if(vas != VA_STATUS_SUCCESS) {
> >> +av_log(0, AV_LOG_ERROR, "Failed to create image for surface "
> >> +   "%#x: %d (%s).\n", surface->id, vas, vaErrorStr(vas));
> >> +err = AVERROR_EXTERNAL;
> >> +goto fail;
> >> +}
> >> +
> >> +if(get) {
> >> +vas = vaGetImage(hw_ctx->display, surface->id, 0, 0,
> >> + config->width, config->height, 
> >> image->image_id);
> >> +if(vas != VA_STATUS_SUCCESS) {
> >> +av_log(0, AV_LOG_ERROR, "Failed to get image for surface "
> >> +   "%#x: %d (%s).\n", surface->id, vas, 
> >> vaErrorStr(vas));
> >> +err = AVERROR_EXTERNAL;
> >> +goto fail_image;
> >> +}
> >> +}
> >> +}
> >> +
> >> +av_assert0(image->format.fourcc == config->image_format.fourcc);  
> > 
> > I wouldn't use assert to check expectations from API return values.  
> 
> Sure, it can just be a different failure case.
> 
> >> +
> >> +vas = vaMapBuffer(hw_ctx->display, image->buf, &address);
> >> +if(vas != VA_STATUS_SUCCESS) {
> >> +av_log(0, AV_LOG_ERROR, "Failed to map image from surface "
> >> +   "%#x: %d (%s).\n", surface->id, vas, vaErrorStr(vas));
> >> +err = AVERROR_EXTERNAL;
> >> +goto fail_image;
> >> +}
> >> +
> >> +surface->mapped_address = address;
> >> +
> >> +for(i = 0; i < image->num_planes; i++) {
> >> +frame->data[i] = (uint8_t*)address + image->offsets[i];
> >> +frame->linesize[i] = image->pitches[i];
> >> +}
> >> +
> >> +av_vaapi_unlock_hardware_context(hw_ctx);
> >> +return 0;
> >> +
> >> +  fail_image:
> >> +vas = vaDestroyImage(hw_ctx->display, surface->image.image_id);
> >> +if(vas != VA_STATUS_SUCCESS) {
> >> +av_log(0, AV_LOG_ERROR, "Failed to destroy image for surface "
> >> +   "%#x: %d (%s).\n", surface->id, vas, vaErrorStr(vas));
> >> +}
> >> +  fail:
> >> +av_vaapi_unlock_hardware_context(hw_ctx);
> >> +return err;
> >> +}  
> > 
> > So this API function uses a per-surface image struct and other fields.
> > What happens if multiple threads try to map it? Does libva even allow
> > this in theory? (If not, this isn't a concern. But maybe the function
> > could complain loudly if such an use is detected.)  
> 
> Don't do that?  The mapping information is saved so it could work in theory 
> (needs a map-refcount on the surface), but I didn't have a sensible use case 
> so ignored it (you definitely can't map a surface while using it for other 
> operations (even read-only ones like encoding), so there already strong 
> parallelism constraints the user has to be awar

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Andreas Cadhalpun]

On 24.01.2016 13:38, Hendrik Leppkes wrote:
> On Sun, Jan 24, 2016 at 12:52 PM, Andreas Cadhalpun
>> Thus I object to reverting this before the regression caused by 31741ae is 
>> fixed.
> 
> So you break building of git master, and you try to leverage this to
> get your own agenda forward? Seriously?
> I already conceded the other issue as long as it doesn't cause serious
> regressions (ie. vp9), so get over yourself. Is this how debian does
> business? Sounds like a fun place to be.

Let's just not continue along this way.
Your behavior annoyed me and I guess my behavior annoyed you, leading to
harsh words from both sides. I'm sorry about that.

>> Also, please be a bit more constructive. Just complaining that it doesn't 
>> work
>> in your setup is not helpful, as I don't have that setup and thus can't 
>> investigate
>> the problem. At the very least I'd need to see the output of 'make V=1'.
>>
> 
> Here have some output:
> D:\Multimedia\ffmpeg\build>make V=1
> cl -nologo -ID:/Multimedia/ffmpeg/build/
> -I/d/Multimedia/ffmpeg/develop/ -D_ISOC99_SOURCE
> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_WIN32_WINNT=0x0502
> -DZLIB_CONST -DHAVE_AV_CONFIG_H -ID:/Multimedia/ffmpeg/build/
> -I/d/Multimedia/ffmpeg/develop/ -D_ISOC99_SOURCE
> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_WIN32_WINNT=0x0502
> -DZLIB_CONST -DHAVE_AV_CONFIG_H -nologo -D_USE_MATH_DEFINES
> -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_WARNINGS-Z7 -W4
> -wd4244 -wd4127 -wd4018 -wd4389 -wd4146 -wd4057 -wd4204 -wd4706
> -wd4305 -wd4152 -wd4324 -we4013 -wd4100 -wd4214 -wd4307 -wd4273
> -wd4554 -wd4701 -O2   -Oy-  -showIncludes -Zs
> /d/Multimedia/ffmpeg/develop/libavdevice/alldevices.c 2>&1 | awk
> '/including/ { sub(/^.*file: */, ""); gsub(/\\/, "/"); if (!match($0,
> / /)) print "libavdevice/alldevices.o:", $0 }' >
> libavdevice/alldevices.d
> cd /d/Multimedia/ffmpeg/develop; if [ -n
> "/d/Multimedia/ffmpeg/develop" ]; then dest=libavdevice/alldevices.c;
> else 
> dest=D:/Multimedia/ffmpeg/build//d/Multimedia/ffmpeg/develop/libavdevice/alldevices.c;
> fi; cl -ID:/Multimedia/ffmpeg/build/ -I/d/Multimedia/ffmpeg/develop/
> -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> -D_WIN32_WINNT=0x0502 -DZLIB_CONST -DHAVE_AV_CONFIG_H -nologo
> -D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS
> -D_CRT_NONSTDC_NO_WARNINGS-Z7 -W4 -wd4244 -wd4127 -wd4018 -wd4389
> -wd4146 -wd4057 -wd4204 -wd4706 -wd4305 -wd4152 -wd4324 -we4013
> -wd4100 -wd4214 -wd4307 -wd4273 -wd4554 -wd4701 -O2   -Oy-   -c
> -FoD:/Multimedia/ffmpeg/build/libavdevice/alldevices.o $dest
> alldevices.c

So here the correct path is passed to '-Fo'.

> D:\Multimedia\ffmpeg\develop\libavdevice\alldevices.c : fatal error
> C1083: Cannot open compiler generated file:
> 'D:\Multimedia\ffmpeg\develop\D:\Multimedia\BuildEnv\MSYS2\Multimedia\ffmpeg\build\libavdevice\alldevices.o':
> Invalid argument

But it seems MSYS2 interpreted it as unix path and tried to convert it
to a Windows path. This is probably caused by the original path using
'/' instead of '\'.

Does the following fix it?
--- a/configure
+++ b/configure
@@ -6234,7 +6234,7 @@ enabled stripping || strip="echo skipping strip"
 config_files="$TMPH config.mak doc/config.texi"
 
 if enabled msvc; then
-dst_path=$(pwd -W)
+dst_path=$(pwd -W | sed 's_/_\\_g')
 else
 dst_path=$(pwd)
 fi

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

Re: [FFmpeg-devel] [PATCH v4 2/5] ffmpeg: VAAPI hwaccel helper and related initialisation

[wm4]

On Sun, 24 Jan 2016 14:20:54 +
Mark Thompson  wrote:

> ...
> >> +static int vaapi_get_buffer(AVCodecContext *s, AVFrame *frame, int flags)
> >> +{
> >> +InputStream *ist = s->opaque;
> >> +VAAPIDecoderContext *ctx = ist->hwaccel_ctx;
> >> +AVFrame *new_frame;
> >> +
> >> +av_assert0(frame->format == AV_PIX_FMT_VAAPI);  
> > 
> > This can actually change on software decoding fallback, I think?  
> 
> But this function won't be called in that case?
> 
> It works on the switching cases in FATE, at least: 
> h264-reinit-small_420_8-to-large_444_10 and 
> h264-reinit-small_420_9-to-small_420_8 both pass.

OK, didn't realize ffmpeg.c already dispatches the call is needed.

> >> +
> >> +new_frame = av_frame_alloc();
> >> +if(!new_frame)
> >> +return AVERROR(ENOMEM);
> >> +
> >> +av_vaapi_surface_pool_get(&ctx->pool, new_frame);
> >> +
> >> +av_log(ctx, AV_LOG_DEBUG, "Decoder given reference to surface %#x.\n",
> >> +   (VASurfaceID)new_frame->data[3]);
> >> +
> >> +av_frame_copy_props(new_frame, frame);
> >> +av_frame_unref(frame);
> >> +av_frame_move_ref(frame, new_frame);  
> > 
> > What are these acrobatics for? Why not use frame directly?  
> 
> The AVFrame supplied by the decoder already has a lot of the metadata filled 
> in, but the surface pool needs to make a new reference to its own AVFrame.
> 
> Without this, you get display order == decode order (that was fun to track 
> down).

I still don't understand - AVFrames aren't referenced, AVBufferRefs
are.

> ...
> >> +// If there isn't an exact match, we will choose the last 
> >> (highest)
> >> +// profile in the mapping table.  This is unfortunate because it
> >> +// could well be wrong, but it improves compatibility because 
> >> streams
> >> +// and decoders do not necessarily conform to the requirements.
> >> +// (Without this, a lot of streams in FATE are discarded when then
> >> +// could have worked - H.264 extended profile which actually 
> >> decodes
> >> +// with main, for example.)  
> > 
> > I still think this should not be done by default, and instead a user
> > option should enable it.  
> 
> I guess that works if the error message suggests the option they could try.  
> "-lax-codec-profile-constraints"?  Other hwaccels might want it too.

Yes, something like this. At least vdpau already checks it pretty
strictly (even verifies the level).

> >> +}
> >> +return result;
> >> +}
> >> +
> >> +static const struct {
> >> +enum AVPixelFormat pix_fmt;
> >> +unsigned int fourcc;
> >> +} vaapi_image_formats[] = {
> >> +{ AV_PIX_FMT_NV12,VA_FOURCC_NV12 },
> >> +{ AV_PIX_FMT_YUV420P, VA_FOURCC_YV12 },
> >> +{ AV_PIX_FMT_GRAY8,   VA_FOURCC_Y800 },
> >> +};
> >> +
> >> +static int vaapi_get_pix_fmt(unsigned int fourcc)
> >> +{
> >> +int i;
> >> +for(i = 0; i < FF_ARRAY_ELEMS(vaapi_image_formats); i++)
> >> +if(vaapi_image_formats[i].fourcc == fourcc)
> >> +return vaapi_image_formats[i].pix_fmt;
> >> +return 0;
> >> +}  
> > 
> > Again wondering why there's not just a single mapping table in the
> > libavutil code. (Just a suggestion; this is ok too.)  
> 
> Ok, that does make sense to go with the mapping now.  I'll change it.
> 
> >> +
> >> +static int vaapi_build_decoder_config(VAAPIDecoderContext *ctx,
> >> +  AVVAAPIPipelineConfig *config,
> >> +  AVVAAPISurfaceConfig *output,
> >> +  AVCodecContext *avctx)
> >> +{
> >> +VAStatus vas;
> >> +int i;
> >> +
> >> +memset(config, 0, sizeof(*config));
> >> +
> >> +// Pick codec profile to use.
> >> +{
> >> +VAProfile profile;
> >> +int profile_count;
> >> +VAProfile *profile_list;
> >> +
> >> +profile = vaapi_find_profile(avctx);
> >> +if(profile == VAProfileNone) {
> >> +av_log(ctx, AV_LOG_ERROR, "VAAPI does not support codec 
> >> %s.\n",
> >> +   avcodec_get_name(avctx->codec_id));
> >> +return AVERROR(EINVAL);
> >> +}
> >> +
> >> +profile_count = vaMaxNumProfiles(ctx->hardware_context->display);
> >> +profile_list = av_calloc(profile_count, sizeof(VAProfile));
> >> +if(!profile_list)
> >> +return AVERROR(ENOMEM);
> >> +
> >> +vas = vaQueryConfigProfiles(ctx->hardware_context->display,
> >> +profile_list, &profile_count);
> >> +if(vas != VA_STATUS_SUCCESS) {
> >> +av_log(ctx, AV_LOG_ERROR, "Failed to query profiles: %d 
> >> (%s).\n",
> >> +   vas, vaErrorStr(vas));
> >> +av_free(profile_list);
> >> +return AVERROR(EINVAL);
> >> +}
> >> +
> >> +while(1) {
> >> +for(i = 0; i < profile_count; i++) {
> >> +if(profile_list[i] == profi

Re: [FFmpeg-devel] [PATCH] avformat/mpegtsenc: Fix multi program so that it supports adding the same stream to multiple programs.

[Vittorio Gambaletta (VittGam)]

Hi,

On 24/01/2016 12:01:38 CET, Michael Niedermayer wrote:

On Sun, Jan 24, 2016 at 06:06:36AM +0100, Vittorio Gambaletta (VittGam) wrote:

Signed-off-by: Vittorio Gambaletta 
---
 libavformat/mpegtsenc.c |   15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 2c12043..a20e229 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -275,8 +275,19 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
 AVDictionaryEntry *lang = av_dict_get(st->metadata, "language", NULL, 
0);

 if (s->nb_programs) {
-AVProgram *program = av_find_program_from_stream(s, NULL, i);
-if (program->id != service->sid)
+int j, k, found = 0;
+
+for (j = 0; j < s->nb_programs; j++)
+if (s->programs[j]->id == service->sid) {
+for (k = 0; k < s->programs[j]->nb_stream_indexes; k++)
+if (s->programs[j]->stream_index[k] == i) {
+found = 1;
+break;
+}
+break;
+}


av_find_program_from_stream() should be run in a loop to enumerate
the programs, see other uses of av_find_program_from_stream()


Wouldn't this solve the problem backwards?

We need to search the program that has the same ID as the service
being evaluated, and then we search that program for the stream with
the same ID as the stream being evaluated. My code does that.

av_find_program_from_stream() instead enumerates every stream in every
program (starting from `last`) until it finds a stream with the same ID
as the stream being searched, so every time it returns a different
program ID. In fact it is used to update every program that contain
a certain stream, not the reverse.

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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Andreas Cadhalpun]

Hi Ronald,

On 24.01.2016 14:06, Ronald S. Bultje wrote:
> On Sun, Jan 24, 2016 at 6:52 AM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
> 
>> Thus I object to reverting this before the regression caused by 31741ae is
>> fixed.
> 
> 
> This is ridiculous, I (who didn't break it and don't even have hw
> supporting any of our hwaccel implementatons) already proposed a method to
> fix it _properly_ (without introducing alternate regressions) that everyone
> agreed to.

I'm not sure if the method you proposed would work. I don't know the hwaccel
implementation very well, as I'm a mere user of that feature.

> That is, everyone that responded. After a re-poke. And you
> weren't one of them.

And thus I haven't responded, yet. If you're confident that it will work,
just give it a go. I'm happy to test patches.

> Which makes me wonder, you're very good at objecting,

Thanks for the compliment.

> but you never give +1s on good ideas that are different (but better) than
> your ideas.

I never give '+1s', because I prefer to write full sentences, including
some sort of explanation. Doing that requires to first figure out whether it
could work, which can take a lot of time.

> That's a terrible attitude. You're not perfect. Other people's ideas can be 
> better
> than yours.

Agreed.

> Can you please look at my RFC in the related thread and comment
> on the proposed fix? If you like it, that includes +1'ing it so I can
> assume we have general consensus before I implement it and get bikeshedded
> after doing work on it.

I'm fine with any solution that makes VLC's hwaccels work again.
So you can assume there is a general consensus for your suggestion, if it works.

> And after you've done that, can we not bring this subject and 31741ae up
> again?

Fine with me.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat: add protocol_whitelist

[Michael Niedermayer]

On Sun, Jan 24, 2016 at 03:37:24PM +0100, Andreas Cadhalpun wrote:
> On 24.01.2016 03:42, Michael Niedermayer wrote:
> > From: Michael Niedermayer 
> > 
> > TODO: Docs
> > TODO: version bump
> > 
> > Note to maintainers: update tools
> > 
> > Note, testing and checking for missing changes is needed
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  ffmpeg_opt.c  |4 ++--
> >  libavdevice/lavfi.c   |2 +-
> >  libavformat/async.c   |2 +-
> >  libavformat/avformat.h|7 ++
> >  libavformat/avio.c|   44 
> > ++---
> >  libavformat/avio.h|4 
> >  libavformat/aviobuf.c |   16 ++
> >  libavformat/cache.c   |3 ++-
> >  libavformat/concat.c  |5 +++--
> >  libavformat/crypto.c  |5 +++--
> >  libavformat/dashenc.c |9 
> >  libavformat/ftp.c |   10 +
> >  libavformat/gopher.c  |4 ++--
> >  libavformat/hdsenc.c  |   12 +-
> >  libavformat/hls.c |8 ---
> >  libavformat/hlsenc.c  |   28 +++
> >  libavformat/hlsproto.c|   10 +
> >  libavformat/http.c|   16 +-
> >  libavformat/icecast.c |3 ++-
> >  libavformat/md5proto.c|5 +++--
> >  libavformat/mmst.c|5 +++--
> >  libavformat/movenc.c  |2 +-
> >  libavformat/options_table.h   |1 +
> >  libavformat/rtmpcrypt.c   |5 +++--
> >  libavformat/rtmpproto.c   |   10 +
> >  libavformat/rtpproto.c|   10 ++---
> >  libavformat/rtsp.c|   20 -
> >  libavformat/rtspdec.c |   10 +
> >  libavformat/sapdec.c  |5 +++--
> >  libavformat/sapenc.c  |9 +---
> >  libavformat/segment.c |   16 +++---
> >  libavformat/smoothstreamingenc.c  |   18 ---
> >  libavformat/srtpproto.c   |3 ++-
> >  libavformat/subfile.c |3 ++-
> >  libavformat/tee.c |4 +++-
> >  libavformat/tls.c |5 +++--
> >  libavformat/tls_securetransport.c |5 +++--
> >  libavformat/url.h |5 +
> >  libavformat/utils.c   |   13 +++
> >  libavformat/webm_chunk.c  |7 +++---
> >  40 files changed, 230 insertions(+), 123 deletions(-)
> > 
> 
> To make reviewing easier it would be nice to split this into a patch
> that adds the protocol_whitelist mechanism and a subsequent one,
> which forwards the protocol_whitelist where necessary.
> 

> > diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> > index 4964263..2fb9130 100644
> > --- a/libavformat/avformat.h
> > +++ b/libavformat/avformat.h
> > @@ -1815,6 +1815,13 @@ typedef struct AVFormatContext {
> >   * Demuxing: Set by user.
> >   */
> >  int (*open_cb)(struct AVFormatContext *s, AVIOContext **p, const char 
> > *url, int flags, const AVIOInterruptCB *int_cb, AVDictionary **options);
> > +
> > +/**
> > + * ',' separated list of allowed protocols.
> > + * - encoding: unused
> > + * - decoding: set by user through AVOptions (NO direct access)
> > + */
> > +char *protocol_whitelist;
> >  } AVFormatContext;
> 
> I'm not sure if adding protocol_whitelist to the AVFormatContext is good.
> Conceptually it would fit better in the AVIOContext. I think that would also
> make it easier to set a default for it.

the AVFormatContexts AVIOContext can be NULL


> 
> > diff --git a/libavformat/avio.c b/libavformat/avio.c
> > index 05d0557..ad9712d 100644
> > --- a/libavformat/avio.c
> > +++ b/libavformat/avio.c
> [...]
> > @@ -296,18 +302,43 @@ int ffurl_alloc(URLContext **puc, const char 
> > *filename, int flags,
> >  return AVERROR_PROTOCOL_NOT_FOUND;
> >  }
> >  
> > -int ffurl_open(URLContext **puc, const char *filename, int flags,
> > -   const AVIOInterruptCB *int_cb, AVDictionary **options)
> > +int ffurl_open_whitelist(URLContext **puc, const char *filename, int flags,
> > + const AVIOInterruptCB *int_cb, AVDictionary 
> > **options, const char *whitelist)
> >  {
> > +AVDictionary *tmp_opts = NULL;
> > +AVDictionaryEntry *e;
> >  int ret = ffurl_alloc(puc, filename, flags, int_cb);
> >  if (ret < 0)
> >  return ret;
> >  if (options && (*puc)->prot->priv_data_class &&
> >  (ret = av_opt_set_dict((*puc)->priv_data, options)) < 0)
> >  goto fail;
> > +
> > +if (!options)
> > +options = &tmp_opts;
> > +
> > +av_assert0(!whitelist ||
> > +   !(e=av_dict_get(*options, "protocol_whitelist", NULL, 0)) ||
> > +   !strcmp(whitelist, e->value));
> > +
> > +if ((ret = 

Re: [FFmpeg-devel] [PATCH] ffmpeg_opt: Allow program metadata other than title to be set.

[Vittorio Gambaletta (VittGam)]

Hi,

On 24/01/2016 12:33:51 CET, Michael Niedermayer wrote:

On Sun, Jan 24, 2016 at 05:23:22AM +0100, Vittorio Gambaletta (VittGam) wrote:

This commit makes it possible to add optional metadata (such as 
"service_provider") to an mpegts output stream composed by multiple programs 
(mpts).

This is needed because the global metadata is not inherited by the single 
programs.

Signed-off-by: Vittorio Gambaletta 
---
 ffmpeg_opt.c |   10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)


with this change the whole namespace except "st"/"program_num" would
be used for metadata. This might be a problem in the future if we
want to add some non metadata key/value


What would you suggest then? I have two ideas:

1. Move the 'process manually set programs' block above 'process
   manually set metadata' and have it handle `-metadata:p:`
2. Use a prefix: `-program st=0:st=1:metadata=service_provider=HelloWorld`
3. Change mpegtsenc to look for global metadata if program metadata
   is not present

The first is probably cleaner.

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat: add protocol_whitelist

[Michael Niedermayer]

On Sun, Jan 24, 2016 at 04:03:40PM +0100, Michael Niedermayer wrote:
> On Sun, Jan 24, 2016 at 03:37:24PM +0100, Andreas Cadhalpun wrote:
> > On 24.01.2016 03:42, Michael Niedermayer wrote:
[...]
> > >  if ((ret = av_opt_set_dict(*puc, options)) < 0)
> > >  goto fail;
> > > +
> > > +whitelist = (*puc)->protocol_whitelist;
> > > +if (whitelist && av_match_list((*puc)->prot->name, whitelist, ',') 
> > > <= 0) {
> > > +av_log(*puc, AV_LOG_ERROR, "Protocol not on whitelist!\n");
> > 
> > It would be nice to mention the protocol and the whitelist in the error 
> > message.

the protocol is already printed as part of the av_log() prefix, ill
add printing the whitelist

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Hendrik Leppkes]

On Sun, Jan 24, 2016 at 3:45 PM, Andreas Cadhalpun
 wrote:
>
> So here the correct path is passed to '-Fo'.
>
>> D:\Multimedia\ffmpeg\develop\libavdevice\alldevices.c : fatal error
>> C1083: Cannot open compiler generated file:
>> 'D:\Multimedia\ffmpeg\develop\D:\Multimedia\BuildEnv\MSYS2\Multimedia\ffmpeg\build\libavdevice\alldevices.o':
>> Invalid argument
>
> But it seems MSYS2 interpreted it as unix path and tried to convert it
> to a Windows path. This is probably caused by the original path using
> '/' instead of '\'.
>
> Does the following fix it?
> --- a/configure
> +++ b/configure
> @@ -6234,7 +6234,7 @@ enabled stripping || strip="echo skipping strip"
>  config_files="$TMPH config.mak doc/config.texi"
>
>  if enabled msvc; then
> -dst_path=$(pwd -W)
> +dst_path=$(pwd -W | sed 's_/_\\_g')
>  else
>  dst_path=$(pwd)
>  fi
>

If anything backslashes make it worse, now it won't even find its
include path anymore (ie fails at config.h not found).

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

Re: [FFmpeg-devel] [PATCH 1/3] common.mak: Use CCFLAGS for assembly generation as well

[Timothy Gu]

On Tue, Dec 01, 2015 at 09:46:04PM -0800, Timothy Gu wrote:
> CCFLAGS is equivalent to CPPFLAGS + CFLAGS.
> ---
>  common.mak | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Set pushed (some with improved commit messages).

[...]

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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Andreas Cadhalpun]

On 24.01.2016 16:29, Hendrik Leppkes wrote:
> On Sun, Jan 24, 2016 at 3:45 PM, Andreas Cadhalpun
>  wrote:
>>
>> So here the correct path is passed to '-Fo'.
>>
>>> D:\Multimedia\ffmpeg\develop\libavdevice\alldevices.c : fatal error
>>> C1083: Cannot open compiler generated file:
>>> 'D:\Multimedia\ffmpeg\develop\D:\Multimedia\BuildEnv\MSYS2\Multimedia\ffmpeg\build\libavdevice\alldevices.o':
>>> Invalid argument
>>
>> But it seems MSYS2 interpreted it as unix path and tried to convert it
>> to a Windows path. This is probably caused by the original path using
>> '/' instead of '\'.
>>
>> Does the following fix it?
>> --- a/configure
>> +++ b/configure
>> @@ -6234,7 +6234,7 @@ enabled stripping || strip="echo skipping strip"
>>  config_files="$TMPH config.mak doc/config.texi"
>>
>>  if enabled msvc; then
>> -dst_path=$(pwd -W)
>> +dst_path=$(pwd -W | sed 's_/_\\_g')
>>  else
>>  dst_path=$(pwd)
>>  fi
>>
> 
> If anything backslashes make it worse, now it won't even find its
> include path anymore (ie fails at config.h not found).

Argh. Is that because there is a '/' added at the end of the include path?
Does the following help?
--- a/common.mak
+++ b/common.mak
@@ -32,7 +32,7 @@ endif
 ALLFFLIBS = avcodec avdevice avfilter avformat avresample avutil postproc 
swscale swresample
 
 # NASM requires -I path terminated with /
-IFLAGS := -I$(DST_PATH)/ -I$(SRC_PATH)/
+IFLAGS := -I$(DST_PATH) -I$(SRC_PATH)/
 CPPFLAGS   := $(IFLAGS) $(CPPFLAGS)
 CFLAGS += $(ECFLAGS)
 CCFLAGS = $(CPPFLAGS) $(CFLAGS)

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Hendrik Leppkes]

On Sun, Jan 24, 2016 at 4:56 PM, Andreas Cadhalpun
 wrote:
> On 24.01.2016 16:29, Hendrik Leppkes wrote:
>> On Sun, Jan 24, 2016 at 3:45 PM, Andreas Cadhalpun
>>  wrote:
>>>
>>> So here the correct path is passed to '-Fo'.
>>>
 D:\Multimedia\ffmpeg\develop\libavdevice\alldevices.c : fatal error
 C1083: Cannot open compiler generated file:
 'D:\Multimedia\ffmpeg\develop\D:\Multimedia\BuildEnv\MSYS2\Multimedia\ffmpeg\build\libavdevice\alldevices.o':
 Invalid argument
>>>
>>> But it seems MSYS2 interpreted it as unix path and tried to convert it
>>> to a Windows path. This is probably caused by the original path using
>>> '/' instead of '\'.
>>>
>>> Does the following fix it?
>>> --- a/configure
>>> +++ b/configure
>>> @@ -6234,7 +6234,7 @@ enabled stripping || strip="echo skipping strip"
>>>  config_files="$TMPH config.mak doc/config.texi"
>>>
>>>  if enabled msvc; then
>>> -dst_path=$(pwd -W)
>>> +dst_path=$(pwd -W | sed 's_/_\\_g')
>>>  else
>>>  dst_path=$(pwd)
>>>  fi
>>>
>>
>> If anything backslashes make it worse, now it won't even find its
>> include path anymore (ie fails at config.h not found).
>
> Argh. Is that because there is a '/' added at the end of the include path?
> Does the following help?
> --- a/common.mak
> +++ b/common.mak
> @@ -32,7 +32,7 @@ endif
>  ALLFFLIBS = avcodec avdevice avfilter avformat avresample avutil postproc 
> swscale swresample
>
>  # NASM requires -I path terminated with /
> -IFLAGS := -I$(DST_PATH)/ -I$(SRC_PATH)/
> +IFLAGS := -I$(DST_PATH) -I$(SRC_PATH)/
>  CPPFLAGS   := $(IFLAGS) $(CPPFLAGS)
>  CFLAGS += $(ECFLAGS)
>  CCFLAGS = $(CPPFLAGS) $(CFLAGS)
>

Windows doesn't particularly care which slash direction you give it,
so no, that changes nothing. I'm not quite sure why it fails with the
include path this way, maybe some msys shenanigans.
For fun and giggles, I hard-coded the correct include path in the
common.mak file and that made config.h show up again of course, but
the good old compiler error came back just like before.

Might be msys thats interfering here and translating something it
shouldn't, or double-translating something, I can't really tell just
from the commands it calls.
Like I said before, when initial MSVC support was build by Ronald and
Martin, there were lots of troubles with absolute paths, which in the
end were solved by not using them (sorry, no answers here).

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

Re: [FFmpeg-devel] [PATCH v4 2/5] ffmpeg: VAAPI hwaccel helper and related initialisation

[Mark Thompson]

On 24/01/16 14:52, wm4 wrote:
> On Sun, 24 Jan 2016 14:20:54 +
> Mark Thompson  wrote:
> 
> ...
> 
 +
 +new_frame = av_frame_alloc();
 +if(!new_frame)
 +return AVERROR(ENOMEM);
 +
 +av_vaapi_surface_pool_get(&ctx->pool, new_frame);
 +
 +av_log(ctx, AV_LOG_DEBUG, "Decoder given reference to surface %#x.\n",
 +   (VASurfaceID)new_frame->data[3]);
 +
 +av_frame_copy_props(new_frame, frame);
 +av_frame_unref(frame);
 +av_frame_move_ref(frame, new_frame);  
>>>
>>> What are these acrobatics for? Why not use frame directly?  
>>
>> The AVFrame supplied by the decoder already has a lot of the metadata filled 
>> in, but the surface pool needs to make a new reference to its own AVFrame.
>>
>> Without this, you get display order == decode order (that was fun to track 
>> down).
> 
> I still don't understand - AVFrames aren't referenced, AVBufferRefs
> are.

av_vaapi_surface_pool_get() wants a whole new AVFrame so that it can call 
av_frame_ref() to make the buffers new references to the existing things held 
in its frame pool.

I could change this so that it just fills in buf[0], buf[1] and data[3] (and 
more?) and then it could be called directly on the given AVFrame here, but that 
seems like it would introduce inconvenient subtlety for other users.

>> ...
 +// If there isn't an exact match, we will choose the last 
 (highest)
 +// profile in the mapping table.  This is unfortunate because it
 +// could well be wrong, but it improves compatibility because 
 streams
 +// and decoders do not necessarily conform to the requirements.
 +// (Without this, a lot of streams in FATE are discarded when then
 +// could have worked - H.264 extended profile which actually 
 decodes
 +// with main, for example.)  
>>>
>>> I still think this should not be done by default, and instead a user
>>> option should enable it.  
>>
>> I guess that works if the error message suggests the option they could try.  
>> "-lax-codec-profile-constraints"?  Other hwaccels might want it too.
> 
> Yes, something like this. At least vdpau already checks it pretty
> strictly (even verifies the level).

Ok, I'll look into it.

>> ...
 +
 +// Decide on the internal chroma format.
 +{
 +VAConfigAttrib attr;
 +
 +// Currently the software only supports YUV420, so just make sure
 +// that the hardware we have does too.
 +
 +memset(&attr, 0, sizeof(attr));
 +attr.type = VAConfigAttribRTFormat;
 +vas = vaGetConfigAttributes(ctx->hardware_context->display, 
 config->profile,
 +VAEntrypointVLD, &attr, 1);
 +if(vas != VA_STATUS_SUCCESS) {
 +av_log(ctx, AV_LOG_ERROR, "Failed to fetch config attributes: 
 "
 +   "%d (%s).\n", vas, vaErrorStr(vas));
 +return AVERROR(EINVAL);
 +}
 +if(!(attr.value & VA_RT_FORMAT_YUV420)) {
 +av_log(ctx, AV_LOG_ERROR, "Hardware does not support required 
 "
 +   "chroma format (%#x).\n", attr.value);
 +return AVERROR(EINVAL);
 +}
 +
 +output->rt_format = VA_RT_FORMAT_YUV420;  
>>>
>>> I'm confused, shouldn't this set it to something retrieved by the
>>> function above?  
>>
>> Read again - it's just a check, the code errors out on all other 
>> possibilities.
>>
> 
> Oh, ok.
> 
>> This section is only present because more could be added.  Currently the 
>> only other possibility in the Intel driver is greyscale for H.264 decoding 
>> only, so it didn't seem worth it now.
>>
> 
> What about conversion to RGB? I think 10 bit will also have a different
> RT format, not sure.

This is only deciding on the format of the surface which the decoder actually 
operates on, which isn't going to be RGB.

YUV 10-bit does have a different format - implementing that will need support 
here to select VA_RT_FORMAT_YUV420_10BIT.

 +}
 +
 +// Decide on the image format.
 +if(avctx->pix_fmt == AV_PIX_FMT_VAAPI) {
 +// We are going to be passing through a VAAPI surface directly:
 +// they will stay as whatever opaque internal format for that 
 time,
 +// and we never need to make VAImages from them.
 +
 +av_log(ctx, AV_LOG_DEBUG, "Using VAAPI opaque output format.\n");
 +
 +output->av_format = AV_PIX_FMT_VAAPI;
 +memset(&output->image_format, 0, sizeof(output->image_format));
 +
 +} else {
 +int image_format_count;
 +VAImageFormat *image_format_list;
 +int pix_fmt;
 +
 +// We might want to force a change to the output format here
 +// if we are intending to u

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Henrik Gramner]

On Sun, Jan 24, 2016 at 5:02 PM, Hendrik Leppkes  wrote:
> Windows doesn't particularly care which slash direction you give it,
> so no, that changes nothing. I'm not quite sure why it fails with the
> include path this way, maybe some msys shenanigans.
> For fun and giggles, I hard-coded the correct include path in the
> common.mak file and that made config.h show up again of course, but
> the good old compiler error came back just like before.
>
> Might be msys thats interfering here and translating something it
> shouldn't, or double-translating something, I can't really tell just
> from the commands it calls.
> Like I said before, when initial MSVC support was build by Ronald and
> Martin, there were lots of troubles with absolute paths, which in the
> end were solved by not using them (sorry, no answers here).

Is there any reason why we're using absolute paths then? Can't we just
stick to relative paths with forward slashes since they seem to work
with all tools?

I added some code to x264's configure some time ago to convert
absolute paths into relative paths just in order to avoid some
MSYS/Cygwin headaches.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec: Remove libvo-aacenc support.

[Kieran Kunhya]

The internal encoder is superior to libvo-aacenc.
---
 configure |   6 --
 doc/encoders.texi |  25 --
 doc/general.texi  |   8 --
 libavcodec/Makefile   |   1 -
 libavcodec/allcodecs.c|   1 -
 libavcodec/libvo-aacenc.c | 200 --
 libavcodec/version.h  |   2 +-
 7 files changed, 1 insertion(+), 242 deletions(-)
 delete mode 100644 libavcodec/libvo-aacenc.c

diff --git a/configure b/configure
index 35e3513..b940d2a 100755
--- a/configure
+++ b/configure
@@ -255,7 +255,6 @@ External library support:
   --enable-libutvideo  enable Ut Video encoding and decoding via 
libutvideo [no]
   --enable-libv4l2 enable libv4l2/v4l-utils [no]
   --enable-libvidstab  enable video stabilization using vid.stab [no]
-  --enable-libvo-aacencenable AAC encoding via libvo-aacenc [no]
   --enable-libvo-amrwbenc  enable AMR-WB encoding via libvo-amrwbenc [no]
   --enable-libvorbis   enable Vorbis en/decoding via libvorbis,
native implementation exists [no]
@@ -1481,7 +1480,6 @@ EXTERNAL_LIBRARY_LIST="
 libutvideo
 libv4l2
 libvidstab
-libvo_aacenc
 libvo_amrwbenc
 libvorbis
 libvpx
@@ -2639,8 +2637,6 @@ libspeex_encoder_deps="libspeex"
 libspeex_encoder_select="audio_frame_queue"
 libtheora_encoder_deps="libtheora"
 libtwolame_encoder_deps="libtwolame"
-libvo_aacenc_encoder_deps="libvo_aacenc"
-libvo_aacenc_encoder_select="audio_frame_queue"
 libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
 libvorbis_decoder_deps="libvorbis"
 libvorbis_encoder_deps="libvorbis"
@@ -4866,7 +4862,6 @@ die_license_disabled version3 gmp
 die_license_disabled version3 libopencore_amrnb
 die_license_disabled version3 libopencore_amrwb
 die_license_disabled version3 libsmbclient
-die_license_disabled version3 libvo_aacenc
 die_license_disabled version3 libvo_amrwbenc
 
 enabled version3 && { enabled gpl && enable gplv3 || enable lgplv3; }
@@ -5488,7 +5483,6 @@ enabled libtwolame&& require libtwolame twolame.h 
twolame_init -ltwolame
 enabled libutvideo&& require_cpp utvideo "stdint.h stdlib.h 
utvideo/utvideo.h utvideo/Codec.h" 'CCodec*' -lutvideo -lstdc++
 enabled libv4l2   && require_pkg_config libv4l2 libv4l2.h v4l2_ioctl
 enabled libvidstab&& require_pkg_config "vidstab >= 0.98" 
vid.stab/libvidstab.h vsMotionDetectInit
-enabled libvo_aacenc  && require libvo_aacenc vo-aacenc/voAAC.h 
voGetAACEncAPI -lvo-aacenc
 enabled libvo_amrwbenc&& require libvo_amrwbenc vo-amrwbenc/enc_if.h 
E_IF_init -lvo-amrwbenc
 enabled libvorbis && require libvorbis vorbis/vorbisenc.h 
vorbis_info_init -lvorbisenc -lvorbis -logg
 
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 33699df..c485f90 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1075,31 +1075,6 @@ Set MPEG audio original flag when set to 1. The default 
value is 0
 
 @end table
 
-@anchor{libvo-aacenc}
-@section libvo-aacenc
-
-VisualOn AAC encoder.
-
-Requires the presence of the libvo-aacenc headers and library during
-configuration. You need to explicitly configure the build with
-@code{--enable-libvo-aacenc --enable-version3}.
-
-This encoder is considered to be worse than the
-@ref{aacenc,,native FFmpeg AAC encoder}, according to
-multiple sources.
-
-@subsection Options
-
-The VisualOn AAC encoder only support encoding AAC-LC and up to 2
-channels. It is also CBR-only.
-
-@table @option
-
-@item b
-Set bit rate in bits/s.
-
-@end table
-
 @section libvo-amrwbenc
 
 VisualOn Adaptive Multi-Rate Wideband encoder.
diff --git a/doc/general.texi b/doc/general.texi
index 06933ab..185c978 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -53,14 +53,6 @@ instructions for installing the libraries.
 Then pass @code{--enable-libopencore-amrnb} and/or
 @code{--enable-libopencore-amrwb} to configure to enable them.
 
-@subsection VisualOn AAC encoder library
-
-FFmpeg can make use of the VisualOn AACenc library for AAC encoding.
-
-Go to @url{http://sourceforge.net/projects/opencore-amr/} and follow the
-instructions for installing the library.
-Then pass @code{--enable-libvo-aacenc} to configure to enable it.
-
 @subsection VisualOn AMR-WB encoder library
 
 FFmpeg can make use of the VisualOn AMR-WBenc library for AMR-WB encoding.
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index b9ffdb9..178bc18 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -833,7 +833,6 @@ OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
 OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
 OBJS-$(CONFIG_LIBUTVIDEO_DECODER) += libutvideodec.o
 OBJS-$(CONFIG_LIBUTVIDEO_ENCODER) += libutvideoenc.o
-OBJS-$(CONFIG_LIBVO_AACENC_ENCODER)   += libvo-aacenc.o mpeg4audio.o
 OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) += libvo-amrwbenc.o
 OBJS-$(CONFIG_LIBVORBIS_DECODER)  += libvorbisdec.o
 OBJS-$(CONFIG_LIBVORBIS_ENCODER)  += libvorbisenc.o \

[FFmpeg-devel] [PATCH] avcodec/put_bits: fix off be one

[Paul B Mahol]

Hi,

patch attached.
From cdbc09536a21400fd2df1cc7d00d806eae84572a Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Sun, 24 Jan 2016 17:39:39 +0100
Subject: [PATCH] avcodec/put_bits: fix off by one

Signed-off-by: Paul B Mahol 
---
 libavcodec/put_bits.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/put_bits.h b/libavcodec/put_bits.h
index 68ed391..0ae8754 100644
--- a/libavcodec/put_bits.h
+++ b/libavcodec/put_bits.h
@@ -105,7 +105,7 @@ static inline void flush_put_bits(PutBitContext *s)
 s->bit_buf <<= s->bit_left;
 #endif
 while (s->bit_left < 32) {
-av_assert0(s->buf_ptr < s->buf_end);
+av_assert0(s->buf_ptr <= s->buf_end);
 #ifdef BITSTREAM_WRITER_LE
 *s->buf_ptr++ = s->bit_buf;
 s->bit_buf  >>= 8;
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Ronald S. Bultje]

Hi,

On Sun, Jan 24, 2016 at 11:14 AM, Henrik Gramner  wrote:

> On Sun, Jan 24, 2016 at 5:02 PM, Hendrik Leppkes 
> wrote:
> > Windows doesn't particularly care which slash direction you give it,
> > so no, that changes nothing. I'm not quite sure why it fails with the
> > include path this way, maybe some msys shenanigans.
> > For fun and giggles, I hard-coded the correct include path in the
> > common.mak file and that made config.h show up again of course, but
> > the good old compiler error came back just like before.
> >
> > Might be msys thats interfering here and translating something it
> > shouldn't, or double-translating something, I can't really tell just
> > from the commands it calls.
> > Like I said before, when initial MSVC support was build by Ronald and
> > Martin, there were lots of troubles with absolute paths, which in the
> > end were solved by not using them (sorry, no answers here).
>
> Is there any reason why we're using absolute paths then? Can't we just
> stick to relative paths with forward slashes since they seem to work
> with all tools?
>
> I added some code to x264's configure some time ago to convert
> absolute paths into relative paths just in order to avoid some
> MSYS/Cygwin headaches.


I think Andreas' original patch removed that so in-tree and out-tree builds
are bit-exact (i.e. the pathnames to in-tree source files are identical
between the two build types).

I don't know if that's worth it. Andreas seems to claim it is, others seem
to doubt it...

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

Re: [FFmpeg-devel] [PATCH] avcodec/put_bits: fix off be one

[Ronald S. Bultje]

Hi,

On Sun, Jan 24, 2016 at 11:41 AM, Paul B Mahol  wrote:

> patch attached.


I think that's wrong. buf_end is buf_start+size, so if size=1, this allows
writing up to and including buf_start[1], which overflows size=1.

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

Re: [FFmpeg-devel] [PATCH] lavfi: recognize GBR9-14P as RGB in ff_fill_rgba_map().

[Ronald S. Bultje]

Hi,

On Thu, Jan 21, 2016 at 12:50 PM, Paul B Mahol  wrote:

> On 1/21/16, Ronald S. Bultje  wrote:
> > ---
> >  libavfilter/drawutils.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
> > index 3257192..f9a5eb8 100644
> > --- a/libavfilter/drawutils.c
> > +++ b/libavfilter/drawutils.c
> > @@ -52,6 +52,10 @@ int ff_fill_rgba_map(uint8_t *rgba_map, enum
> > AVPixelFormat pix_fmt)
> >  case AV_PIX_FMT_BGRA:
> >  case AV_PIX_FMT_BGR0:
> >  case AV_PIX_FMT_BGR24: rgba_map[BLUE ] = 0; rgba_map[GREEN] = 1;
> > rgba_map[RED  ] = 2; rgba_map[ALPHA] = 3; break;
> > +case AV_PIX_FMT_GBRP9:
> > +case AV_PIX_FMT_GBRP10:
> > +case AV_PIX_FMT_GBRP12:
> > +case AV_PIX_FMT_GBRP14:
> >  case AV_PIX_FMT_GBRAP:
> >  case AV_PIX_FMT_GBRP:  rgba_map[GREEN] = 0; rgba_map[BLUE ] = 1;
> > rgba_map[RED  ] = 2; rgba_map[ALPHA] = 3; break;
> >  default:/* unsupported */
> > --
> > 2.1.2
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
> ok, but note that drawutils doesnt have >8 bit support
>

Pushed.

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

Re: [FFmpeg-devel] [PATCH] avcodec/put_bits: fix off be one

[Paul B Mahol]

On 1/24/16, Ronald S. Bultje  wrote:
> Hi,
>
> On Sun, Jan 24, 2016 at 11:41 AM, Paul B Mahol  wrote:
>
>> patch attached.
>
>
> I think that's wrong. buf_end is buf_start+size, so if size=1, this allows
> writing up to and including buf_start[1], which overflows size=1.

Assert happens otherwise when encoding flac.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/put_bits: fix off be one

[Hendrik Leppkes]

On Sun, Jan 24, 2016 at 5:51 PM, Paul B Mahol  wrote:
> On 1/24/16, Ronald S. Bultje  wrote:
>> Hi,
>>
>> On Sun, Jan 24, 2016 at 11:41 AM, Paul B Mahol  wrote:
>>
>>> patch attached.
>>
>>
>> I think that's wrong. buf_end is buf_start+size, so if size=1, this allows
>> writing up to and including buf_start[1], which overflows size=1.
>
> Assert happens otherwise when encoding flac.

I agree with Ronald, the check appears to be correct, buf_end points
to the first byte *after* the valid buffer.
Something else must be up in the flac encoder, maybe its buffer is a
bit too small?

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

Re: [FFmpeg-devel] [PATCH] avcodec/put_bits: fix off be one

[Paul B Mahol]

On 1/24/16, Paul B Mahol  wrote:
> On 1/24/16, Ronald S. Bultje  wrote:
>> Hi,
>>
>> On Sun, Jan 24, 2016 at 11:41 AM, Paul B Mahol  wrote:
>>
>>> patch attached.
>>
>>
>> I think that's wrong. buf_end is buf_start+size, so if size=1, this
>> allows
>> writing up to and including buf_start[1], which overflows size=1.
>
> Assert happens otherwise when encoding flac.
>

ffmpeg -i http://granjow.net/uploads/kdenlive/samples/red-leaf-tips.avi o.flac
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/put_bits: fix off be one

[Ronald S. Bultje]

Hi,

On Sun, Jan 24, 2016 at 12:02 PM, Paul B Mahol  wrote:

> On 1/24/16, Paul B Mahol  wrote:
> > On 1/24/16, Ronald S. Bultje  wrote:
> >> Hi,
> >>
> >> On Sun, Jan 24, 2016 at 11:41 AM, Paul B Mahol 
> wrote:
> >>
> >>> patch attached.
> >>
> >>
> >> I think that's wrong. buf_end is buf_start+size, so if size=1, this
> >> allows
> >> writing up to and including buf_start[1], which overflows size=1.
> >
> > Assert happens otherwise when encoding flac.
> >
>
> ffmpeg -i http://granjow.net/uploads/kdenlive/samples/red-leaf-tips.avi
> o.flac


Is there a trac issue to track this? Do you have a backtrace?

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

Re: [FFmpeg-devel] [PATCH] avcodec/put_bits: fix off be one

[Paul B Mahol]

On 1/24/16, Ronald S. Bultje  wrote:
> Hi,
>
> On Sun, Jan 24, 2016 at 12:02 PM, Paul B Mahol  wrote:
>
>> On 1/24/16, Paul B Mahol  wrote:
>> > On 1/24/16, Ronald S. Bultje  wrote:
>> >> Hi,
>> >>
>> >> On Sun, Jan 24, 2016 at 11:41 AM, Paul B Mahol 
>> wrote:
>> >>
>> >>> patch attached.
>> >>
>> >>
>> >> I think that's wrong. buf_end is buf_start+size, so if size=1, this
>> >> allows
>> >> writing up to and including buf_start[1], which overflows size=1.
>> >
>> > Assert happens otherwise when encoding flac.
>> >
>>
>> ffmpeg -i http://granjow.net/uploads/kdenlive/samples/red-leaf-tips.avi
>> o.flac
>
>
> Is there a trac issue to track this? Do you have a backtrace?

No, can you reproduce it?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v4 2/5] ffmpeg: VAAPI hwaccel helper and related initialisation

[wm4]

On Sun, 24 Jan 2016 16:12:15 +
Mark Thompson  wrote:

> On 24/01/16 14:52, wm4 wrote:
> > On Sun, 24 Jan 2016 14:20:54 +
> > Mark Thompson  wrote:
> > 
> > ...
> >   
>  +
>  +new_frame = av_frame_alloc();
>  +if(!new_frame)
>  +return AVERROR(ENOMEM);
>  +
>  +av_vaapi_surface_pool_get(&ctx->pool, new_frame);
>  +
>  +av_log(ctx, AV_LOG_DEBUG, "Decoder given reference to surface 
>  %#x.\n",
>  +   (VASurfaceID)new_frame->data[3]);
>  +
>  +av_frame_copy_props(new_frame, frame);
>  +av_frame_unref(frame);
>  +av_frame_move_ref(frame, new_frame);
> >>>
> >>> What are these acrobatics for? Why not use frame directly?
> >>
> >> The AVFrame supplied by the decoder already has a lot of the metadata 
> >> filled in, but the surface pool needs to make a new reference to its own 
> >> AVFrame.
> >>
> >> Without this, you get display order == decode order (that was fun to track 
> >> down).  
> > 
> > I still don't understand - AVFrames aren't referenced, AVBufferRefs
> > are.  
> 
> av_vaapi_surface_pool_get() wants a whole new AVFrame so that it can call 
> av_frame_ref() to make the buffers new references to the existing things held 
> in its frame pool.
> 

I still don't follow. It does create a reference on the target, and
references all buffers.

By the way, av_frame_ref() assumes the target is empty (unreffed
before), so maybe that's causing confusion?

> I could change this so that it just fills in buf[0], buf[1] and data[3] (and 
> more?) and then it could be called directly on the given AVFrame here, but 
> that seems like it would introduce inconvenient subtlety for other users.

Hm, I still don't get it. get_buffer2 (which calls this) expects that
the returned frame is reffed once.

> >> ...  
>  +// If there isn't an exact match, we will choose the last 
>  (highest)
>  +// profile in the mapping table.  This is unfortunate because it
>  +// could well be wrong, but it improves compatibility because 
>  streams
>  +// and decoders do not necessarily conform to the requirements.
>  +// (Without this, a lot of streams in FATE are discarded when 
>  then
>  +// could have worked - H.264 extended profile which actually 
>  decodes
>  +// with main, for example.)
> >>>
> >>> I still think this should not be done by default, and instead a user
> >>> option should enable it.
> >>
> >> I guess that works if the error message suggests the option they could 
> >> try.  "-lax-codec-profile-constraints"?  Other hwaccels might want it too. 
> >>  
> > 
> > Yes, something like this. At least vdpau already checks it pretty
> > strictly (even verifies the level).  
> 
> Ok, I'll look into it.
> 
> >> ...  
>  +
>  +// Decide on the internal chroma format.
>  +{
>  +VAConfigAttrib attr;
>  +
>  +// Currently the software only supports YUV420, so just make 
>  sure
>  +// that the hardware we have does too.
>  +
>  +memset(&attr, 0, sizeof(attr));
>  +attr.type = VAConfigAttribRTFormat;
>  +vas = vaGetConfigAttributes(ctx->hardware_context->display, 
>  config->profile,
>  +VAEntrypointVLD, &attr, 1);
>  +if(vas != VA_STATUS_SUCCESS) {
>  +av_log(ctx, AV_LOG_ERROR, "Failed to fetch config 
>  attributes: "
>  +   "%d (%s).\n", vas, vaErrorStr(vas));
>  +return AVERROR(EINVAL);
>  +}
>  +if(!(attr.value & VA_RT_FORMAT_YUV420)) {
>  +av_log(ctx, AV_LOG_ERROR, "Hardware does not support 
>  required "
>  +   "chroma format (%#x).\n", attr.value);
>  +return AVERROR(EINVAL);
>  +}
>  +
>  +output->rt_format = VA_RT_FORMAT_YUV420;
> >>>
> >>> I'm confused, shouldn't this set it to something retrieved by the
> >>> function above?
> >>
> >> Read again - it's just a check, the code errors out on all other 
> >> possibilities.
> >>  
> > 
> > Oh, ok.
> >   
> >> This section is only present because more could be added.  Currently the 
> >> only other possibility in the Intel driver is greyscale for H.264 decoding 
> >> only, so it didn't seem worth it now.
> >>  
> > 
> > What about conversion to RGB? I think 10 bit will also have a different
> > RT format, not sure.  
> 
> This is only deciding on the format of the surface which the decoder actually 
> operates on, which isn't going to be RGB.

Right, I forgot this is ffmpeg.c and for decoders only, and not generic
pipeline code which can also be used by libavfilter.

> YUV 10-bit does have a different format - implementing that will need support 
> here to select VA_RT_FORMAT_YUV420_10BIT.

Yep.

>  +}
>  +
>  +   

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libvo-aacenc support.

[Derek Buitenhuis]

On 1/24/2016 4:33 PM, Kieran Kunhya wrote:
> The internal encoder is superior to libvo-aacenc.
> ---

Just about everything is.

+1 to removing.

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

Re: [FFmpeg-devel] [PATCH] avcodec/put_bits: fix off be one

[Ronald S. Bultje]

Hi,

On Sun, Jan 24, 2016 at 12:13 PM, Paul B Mahol  wrote:

> On 1/24/16, Ronald S. Bultje  wrote:
> > Hi,
> >
> > On Sun, Jan 24, 2016 at 12:02 PM, Paul B Mahol  wrote:
> >
> >> On 1/24/16, Paul B Mahol  wrote:
> >> > On 1/24/16, Ronald S. Bultje  wrote:
> >> >> Hi,
> >> >>
> >> >> On Sun, Jan 24, 2016 at 11:41 AM, Paul B Mahol 
> >> wrote:
> >> >>
> >> >>> patch attached.
> >> >>
> >> >>
> >> >> I think that's wrong. buf_end is buf_start+size, so if size=1, this
> >> >> allows
> >> >> writing up to and including buf_start[1], which overflows size=1.
> >> >
> >> > Assert happens otherwise when encoding flac.
> >> >
> >>
> >> ffmpeg -i http://granjow.net/uploads/kdenlive/samples/red-leaf-tips.avi
> >> o.flac
> >
> >
> > Is there a trac issue to track this? Do you have a backtrace?
>
> No, can you reproduce it?
>

  * frame #0: 0x7fff8d2ea286 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x7fff8fd859f9 libsystem_pthread.dylib`pthread_kill + 90
frame #2: 0x7fff895269b3 libsystem_c.dylib`abort + 129
frame #3: 0x0001003bc13c
ffmpeg_g`flush_put_bits(s=0x00010488) + 140 at put_bits.h:108
frame #4: 0x0001003bfc98
ffmpeg_g`write_frame_footer(s=0x00010480) + 184 at flacenc.c:1287
frame #5: 0x0001003bca35 ffmpeg_g`write_frame(s=0x00010480,
avpkt=0x7fff5fbfabf8) + 85 at flacenc.c:1296
frame #6: 0x0001003bb788
ffmpeg_g`flac_encode_frame(avctx=0x000102817000,
avpkt=0x7fff5fbfabf8, frame=0x000102302d20,
got_packet_ptr=0x7fff5fbfabf4) + 600 at flacenc.c:1404
frame #7: 0x0001007f2ed4
ffmpeg_g`avcodec_encode_audio2(avctx=0x000102817000,
avpkt=0x7fff5fbfabf8, frame=0x000102302d20,
got_packet_ptr=0x7fff5fbfabf4) + 996 at utils.c:1769
frame #8: 0x00010001f10e ffmpeg_g`reap_filters [inlined]
do_audio_out(s=, ost=) + 228 at ffmpeg.c:812
frame #9: 0x00010001f02a ffmpeg_g`reap_filters(flush=)
+ 1546 at ffmpeg.c:1364
frame #10: 0x00010001a2ff ffmpeg_g`transcode [inlined]
transcode_step + 77 at ffmpeg.c:4084
frame #11: 0x00010001a2b2 ffmpeg_g`transcode + 18210 at
ffmpeg.c:4128
frame #12: 0x000100015548 ffmpeg_g`main(argc=,
argv=) + 328 at ffmpeg.c:4319

So it looks like it allocates one byte too little.

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

Re: [FFmpeg-devel] [PATCH] avcodec/put_bits: fix off be one

[Ronald S. Bultje]

Hi,

On Sun, Jan 24, 2016 at 12:24 PM, Ronald S. Bultje 
wrote:

> Hi,
>
> On Sun, Jan 24, 2016 at 12:13 PM, Paul B Mahol  wrote:
>
>> On 1/24/16, Ronald S. Bultje  wrote:
>> > Hi,
>> >
>> > On Sun, Jan 24, 2016 at 12:02 PM, Paul B Mahol 
>> wrote:
>> >
>> >> On 1/24/16, Paul B Mahol  wrote:
>> >> > On 1/24/16, Ronald S. Bultje  wrote:
>> >> >> Hi,
>> >> >>
>> >> >> On Sun, Jan 24, 2016 at 11:41 AM, Paul B Mahol 
>> >> wrote:
>> >> >>
>> >> >>> patch attached.
>> >> >>
>> >> >>
>> >> >> I think that's wrong. buf_end is buf_start+size, so if size=1, this
>> >> >> allows
>> >> >> writing up to and including buf_start[1], which overflows size=1.
>> >> >
>> >> > Assert happens otherwise when encoding flac.
>> >> >
>> >>
>> >> ffmpeg -i
>> http://granjow.net/uploads/kdenlive/samples/red-leaf-tips.avi
>> >> o.flac
>> >
>> >
>> > Is there a trac issue to track this? Do you have a backtrace?
>>
>> No, can you reproduce it?
>>
>
>   * frame #0: 0x7fff8d2ea286 libsystem_kernel.dylib`__pthread_kill + 10
> frame #1: 0x7fff8fd859f9 libsystem_pthread.dylib`pthread_kill + 90
> frame #2: 0x7fff895269b3 libsystem_c.dylib`abort + 129
> frame #3: 0x0001003bc13c
> ffmpeg_g`flush_put_bits(s=0x00010488) + 140 at put_bits.h:108
> frame #4: 0x0001003bfc98
> ffmpeg_g`write_frame_footer(s=0x00010480) + 184 at flacenc.c:1287
> frame #5: 0x0001003bca35
> ffmpeg_g`write_frame(s=0x00010480, avpkt=0x7fff5fbfabf8) + 85
> at flacenc.c:1296
> frame #6: 0x0001003bb788
> ffmpeg_g`flac_encode_frame(avctx=0x000102817000,
> avpkt=0x7fff5fbfabf8, frame=0x000102302d20,
> got_packet_ptr=0x7fff5fbfabf4) + 600 at flacenc.c:1404
> frame #7: 0x0001007f2ed4
> ffmpeg_g`avcodec_encode_audio2(avctx=0x000102817000,
> avpkt=0x7fff5fbfabf8, frame=0x000102302d20,
> got_packet_ptr=0x7fff5fbfabf4) + 996 at utils.c:1769
> frame #8: 0x00010001f10e ffmpeg_g`reap_filters [inlined]
> do_audio_out(s=, ost=) + 228 at ffmpeg.c:812
> frame #9: 0x00010001f02a
> ffmpeg_g`reap_filters(flush=) + 1546 at ffmpeg.c:1364
> frame #10: 0x00010001a2ff ffmpeg_g`transcode [inlined]
> transcode_step + 77 at ffmpeg.c:4084
> frame #11: 0x00010001a2b2 ffmpeg_g`transcode + 18210 at
> ffmpeg.c:4128
> frame #12: 0x000100015548 ffmpeg_g`main(argc=,
> argv=) + 328 at ffmpeg.c:4319
>
> So it looks like it allocates one byte too little.
>

And a potential explanation for that is that encode_frame() does not
byte-align per channel or between header and channels.

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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Ganesh Ajjanagadde]

On Sun, Jan 24, 2016 at 10:14 PM, Ronald S. Bultje  wrote:
> Hi,
>
> On Sun, Jan 24, 2016 at 11:14 AM, Henrik Gramner  wrote:
>
>> On Sun, Jan 24, 2016 at 5:02 PM, Hendrik Leppkes 
>> wrote:
>> > Windows doesn't particularly care which slash direction you give it,
>> > so no, that changes nothing. I'm not quite sure why it fails with the
>> > include path this way, maybe some msys shenanigans.
>> > For fun and giggles, I hard-coded the correct include path in the
>> > common.mak file and that made config.h show up again of course, but
>> > the good old compiler error came back just like before.
>> >
>> > Might be msys thats interfering here and translating something it
>> > shouldn't, or double-translating something, I can't really tell just
>> > from the commands it calls.
>> > Like I said before, when initial MSVC support was build by Ronald and
>> > Martin, there were lots of troubles with absolute paths, which in the
>> > end were solved by not using them (sorry, no answers here).
>>
>> Is there any reason why we're using absolute paths then? Can't we just
>> stick to relative paths with forward slashes since they seem to work
>> with all tools?
>>
>> I added some code to x264's configure some time ago to convert
>> absolute paths into relative paths just in order to avoid some
>> MSYS/Cygwin headaches.
>
>
> I think Andreas' original patch removed that so in-tree and out-tree builds
> are bit-exact (i.e. the pathnames to in-tree source files are identical
> between the two build types).
>
> I don't know if that's worth it. Andreas seems to claim it is, others seem
> to doubt it...

FWIW, I do agree that Andreas's goals wrt the out of tree build are
worthy. To roughly the same degree you and some others dislike "ubsan
appeasement" or "theoretical changes", I don't like the GNU/Linux (or
more broadly POSIX) platform to suffer gratuitously.

Unfortunately, I lack a setup and time to peer into the make and
microsoft internals to offer some technical suggestions, beyond an
idea I proposed earlier of testing the presence of windows via some
shell command.

>
> Ronald
> ___
> 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] avcodec: Remove libaacplus

[Timothy Gu]

It's inferior to fdk-aac and has an arguably more problematic
license.
---
 LICENSE.md  |   2 +-
 configure   |   5 --
 doc/general.texi|   6 +-
 doc/platform.texi   |   2 +-
 libavcodec/Makefile |   1 -
 libavcodec/allcodecs.c  |   1 -
 libavcodec/libaacplus.c | 150 
 7 files changed, 5 insertions(+), 162 deletions(-)
 delete mode 100644 libavcodec/libaacplus.c

diff --git a/LICENSE.md b/LICENSE.md
index 4c4a845..0c53d0f 100644
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -104,7 +104,7 @@ license version needs to be upgraded by passing 
`--enable-version3` to configure
 incompatible libraries
 --
 
-The Fraunhofer AAC library, FAAC and aacplus are under licenses which
+The Fraunhofer AAC library and FAAC are under licenses which
 are incompatible with the GPLv2 and v3. We do not know for certain if their
 licenses are compatible with the LGPL.
 If you wish to enable these libraries, pass `--enable-nonfree` to configure.
diff --git a/configure b/configure
index 6fdb5dd..916b3eb 100755
--- a/configure
+++ b/configure
@@ -207,7 +207,6 @@ External library support:
if openssl is not used [no]
   --disable-iconv  disable iconv [autodetect]
   --enable-ladspa  enable LADSPA audio filtering [no]
-  --enable-libaacplus  enable AAC+ encoding via libaacplus [no]
   --enable-libass  enable libass subtitles rendering,
needed for subtitles and ass filter [no]
   --enable-libbluray   enable BluRay reading using libbluray [no]
@@ -1435,7 +1434,6 @@ EXTERNAL_LIBRARY_LIST="
 gnutls
 iconv
 ladspa
-libaacplus
 libass
 libbluray
 libbs2b
@@ -2601,7 +2599,6 @@ mjpeg2jpeg_bsf_select="jpegtables"
 
 # external libraries
 chromaprint_muxer_deps="chromaprint"
-libaacplus_encoder_deps="libaacplus"
 libcelt_decoder_deps="libcelt"
 libdcadec_decoder_deps="libdcadec"
 libfaac_encoder_deps="libfaac"
@@ -4856,7 +4853,6 @@ die_license_disabled gpl libxvid
 die_license_disabled gpl libzvbi
 die_license_disabled gpl x11grab
 
-die_license_disabled nonfree libaacplus
 die_license_disabled nonfree libfaac
 die_license_disabled nonfree nvenc
 enabled gpl && die_license_disabled_gpl nonfree libfdk_aac
@@ -5430,7 +5426,6 @@ enabled gmp   && require2 gmp gmp.h 
mpz_export -lgmp
 enabled gnutls&& require_pkg_config gnutls gnutls/gnutls.h 
gnutls_global_init
 enabled ladspa&& { check_header ladspa.h || die "ERROR: ladspa.h 
header not found"; }
 enabled libiec61883   && require libiec61883 libiec61883/iec61883.h 
iec61883_cmp_connect -lraw1394 -lavc1394 -lrom1394 -liec61883
-enabled libaacplus&& require "libaacplus >= 2.0.0" aacplus.h 
aacplusEncOpen -laacplus
 enabled libass&& require_pkg_config libass ass/ass.h 
ass_library_init
 enabled libbluray && require_pkg_config libbluray libbluray/bluray.h 
bd_open
 enabled libbs2b   && require_pkg_config libbs2b bs2b.h bs2b_open
diff --git a/doc/general.texi b/doc/general.texi
index 06933ab..4df3d49 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -887,10 +887,10 @@ following image formats are supported:
 @item Name @tab Encoding @tab Decoding @tab Comments
 @item 8SVX exponential   @tab @tab  X
 @item 8SVX fibonacci @tab @tab  X
-@item AAC+   @tab  E  @tab  IX
-@tab encoding supported through external library libaacplus
 @item AAC@tab  E  @tab  X
-@tab encoding supported through external library libfaac and libvo-aacenc
+@tab encoding supported through external library libfaac, libfdk-aac and 
libvo-aacenc
+@item AAC+   @tab  E  @tab  IX
+@tab encoding supported through external library libfdk-aac
 @item AC-3   @tab IX  @tab  IX
 @item ADPCM 4X Movie @tab @tab  X
 @item APDCM Yamaha AICA  @tab @tab  X
diff --git a/doc/platform.texi b/doc/platform.texi
index 3f64069..f7ee456 100644
--- a/doc/platform.texi
+++ b/doc/platform.texi
@@ -314,7 +314,7 @@ These library packages are only available from
 @uref{http://sourceware.org/cygwinports/, Cygwin Ports}:
 
 @example
-yasm, libSDL-devel, libfaac-devel, libaacplus-devel, libgsm-devel, 
libmp3lame-devel,
+yasm, libSDL-devel, libfaac-devel, libgsm-devel, libmp3lame-devel,
 libschroedinger1.0-devel, speex-devel, libtheora-devel, libxvidcore-devel
 @end example
 
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index b9ffdb9..253080c 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -798,7 +798,6 @@ OBJS-$(CONFIG_WTV_DEMUXER) += mpeg4audio.o 
mpegaudiodata.o
 OBJS-$(CONFIG_ELBG_FILTER) += elbg.o
 
 # external codec libraries
-OBJS-$(CONFIG_LIBAACPLUS_ENCODER) += libaacplus.o
 OBJS-$(CONFIG_LIBCELT_DECODER)+= libcelt_dec.o
 OBJS-$(CONFIG_LIBDCADEC_DECODER)  += libdcadec.o dca.o

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Nicolas George]

Le quintidi 5 pluviôse, an CCXXIV, Ronald S. Bultje a écrit :
> I think Andreas' original patch removed that so in-tree and out-tree builds
> are bit-exact (i.e. the pathnames to in-tree source files are identical
> between the two build types).
> 
> I don't know if that's worth it. Andreas seems to claim it is, others seem
> to doubt it...

Theoretically, I believe that identical builds are worth it.

But I just realized that Andreas' patch does it the wrong way, IMHO: it
include the full path in the resulting binary. With the current tree, the
source path arrives in the final binary, even the stripped one. This is
severely wrong as it leaks private information.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Andreas Cadhalpun]

On 24.01.2016 17:14, Henrik Gramner wrote:
> On Sun, Jan 24, 2016 at 5:02 PM, Hendrik Leppkes  wrote:
>> Windows doesn't particularly care which slash direction you give it,
>> so no, that changes nothing. I'm not quite sure why it fails with the
>> include path this way, maybe some msys shenanigans.
>> For fun and giggles, I hard-coded the correct include path in the
>> common.mak file and that made config.h show up again of course, but
>> the good old compiler error came back just like before.
>>
>> Might be msys thats interfering here and translating something it
>> shouldn't, or double-translating something, I can't really tell just
>> from the commands it calls.
>> Like I said before, when initial MSVC support was build by Ronald and
>> Martin, there were lots of troubles with absolute paths, which in the
>> end were solved by not using them (sorry, no answers here).

I have a hard time believing that there are environments, where one
can't use absolute paths...

> Is there any reason why we're using absolute paths then?

It is what $(pwd) gives us.

> Can't we just stick to relative paths with forward slashes since
> they seem to work with all tools?

OK, let's try this.
Attached is a patch calculating dst_path as relative path.
That should hopefully work everywhere. Please test it.

Best regards,
Andreas
>From 162a64541cb149bc44987473962f48eaafb1d416 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Sun, 24 Jan 2016 18:49:53 +0100
Subject: [PATCH] configure: use a relative path for DST_PATH

MSVC environments don't handle absolute paths well.

Now the current path has to be always included, since some commands
(yasm) are run in the destination path.

Linking is also done in the destination path, so don't use DST_PATH
there.

Signed-off-by: Andreas Cadhalpun 
---
 common.mak |  4 ++--
 configure  | 41 +++--
 2 files changed, 37 insertions(+), 8 deletions(-)

diff --git a/common.mak b/common.mak
index 3812149..58d6ab1 100644
--- a/common.mak
+++ b/common.mak
@@ -32,7 +32,7 @@ endif
 ALLFFLIBS = avcodec avdevice avfilter avformat avresample avutil postproc swscale swresample
 
 # NASM requires -I path terminated with /
-IFLAGS := -I$(DST_PATH)/ -I$(SRC_PATH)/
+IFLAGS := -I. -I$(DST_PATH)/ -I$(SRC_PATH)/
 CPPFLAGS   := $(IFLAGS) $(CPPFLAGS)
 CFLAGS += $(ECFLAGS)
 CCFLAGS = $(CPPFLAGS) $(CFLAGS)
@@ -43,7 +43,7 @@ CXXFLAGS   += $(CPPFLAGS) $(CFLAGS)
 YASMFLAGS  += $(IFLAGS:%=%/) -Pconfig.asm
 
 HOSTCCFLAGS = $(IFLAGS) $(HOSTCPPFLAGS) $(HOSTCFLAGS)
-LDFLAGS:= $(ALLFFLIBS:%=$(LD_PATH)$(DST_PATH)/lib%) $(LDFLAGS)
+LDFLAGS:= $(ALLFFLIBS:%=$(LD_PATH)lib%) $(LDFLAGS)
 
 define COMPILE
$(call $(1)DEP,$(1))
diff --git a/configure b/configure
index 6fdb5dd..aeb05fd 100755
--- a/configure
+++ b/configure
@@ -3092,6 +3092,7 @@ DEPFLAGS='-MM'
 # find source path
 if test -f configure; then
 source_path=.
+dst_path=.
 else
 source_path=$(cd $(dirname "$0"); pwd)
 case "$source_path" in
@@ -3099,6 +3100,40 @@ else
 esac
 test -e "$source_path/config.h" &&
 die "Out of tree builds are impossible with config.h in source dir."
+
+# calculate the relative path from source to destination
+dst_path_full=$(pwd)
+common=$source_path
+dst_path=""
+
+while [ "${dst_path_full#$common}" = "${dst_path_full}" ]; do
+# no match, means that the candidate common part is not correct
+# go up one level (reduce common part)
+common="$(dirname $common)"
+# and record that we went back, with correct / handling
+if [ -z $dst_path ]; then
+dst_path=".."
+else
+dst_path="../$dst_path"
+fi
+done
+
+if [ $common = "/" ]; then
+# special case for root (no common path)
+dst_path="$dst_path/"
+fi
+
+# since we now have identified the common part,
+# compute the non-common part
+forward_part="${dst_path_full#$common}"
+
+# and now stick all parts together
+if [ -n "$dst_path" ] && [ -n "$forward_part" ]; then
+dst_path="$dst_path$forward_part"
+elif [ -n "$forward_part" ]; then
+# extra slash removal
+dst_path=$(echo "$forward_part" | sed 's_^/__')
+fi
 fi
 
 for v in "$@"; do
@@ -6229,12 +6264,6 @@ enabled stripping || strip="echo skipping strip"
 
 config_files="$TMPH config.mak doc/config.texi"
 
-if enabled msvc; then
-dst_path=$(pwd -W)
-else
-dst_path=$(pwd)
-fi
-
 cat > config.mak <___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Andreas Cadhalpun]

On 24.01.2016 18:58, Nicolas George wrote:
> Le quintidi 5 pluviôse, an CCXXIV, Ronald S. Bultje a écrit :
>> I think Andreas' original patch removed that so in-tree and out-tree builds
>> are bit-exact (i.e. the pathnames to in-tree source files are identical
>> between the two build types).
>>
>> I don't know if that's worth it. Andreas seems to claim it is, others seem
>> to doubt it...
> 
> Theoretically, I believe that identical builds are worth it.
> 
> But I just realized that Andreas' patch does it the wrong way, IMHO: it
> include the full path in the resulting binary.

How so?

> With the current tree, the
> source path arrives in the final binary, even the stripped one. This is
> severely wrong as it leaks private information.

I can't reproduce this. The path is only included in the debugging information.
And that happened even more before my change.

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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Nicolas George]

Le quintidi 5 pluviôse, an CCXXIV, Andreas Cadhalpun a écrit :
> I can't reproduce this. The path is only included in the debugging 
> information.
> And that happened even more before my change.

I just built in-tree with:

./configure && nice make -j 8, and then I get:

/tmp/ff2 $ grep /tmp/ff2 ffmpeg  
Binary file ffmpeg matches

It does not happen if I revert your original patch and those on top of it.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 2/2] avformat: add protocol_whitelist

[Nicolas George]

Le quintidi 5 pluviôse, an CCXXIV, Michael Niedermayer a écrit :
> the argument is added, not out of strict need, (there already is a
> AVDictionary that can be used) but to make it clear that the author
> set the whitelist correctly. Also it simplifies the code compared
> to using the AVDictionary.
> 
> security relevant code should be clear and explicit so that a
> mistake in the code can easily be spotted. Its very hard to spot that
> a passed dictionary doesnt carry/lost the whitelist, easy to spot that
> a argument is missed and set to NULL

I see the point, but since this whitelist is not a full fix, I believe this
is premature.

> we use string whitelists for codecs and formats, using a differnet
> system for protocols would be inconsistent at least

True, but that only means that codecs and format should be fixed as well.

> The struct suggested has a few flaws as well
> URLProtocols are not public so lists of pointers to them in a "AV*"
> that is public struct might cause problems

Not a problem if the structure is completely opaque.

> also if the same is done for codecs and formats you have 3 such
> structs with the need for 3 sets of allocators, deallocators and
> probably a few helper functions for each to construct them.

Actually, I was more thinking of the opposite: a single structure for
codecs, formats, protocols, etc.

> then new function prototypes could be needed for
> encoder, decoder, audio, video, subtitles, muxers, demuxers and
> protocols to pass in these structs. (depending on details of the API)
> also to maintain support for the existng codec/format whitelists
> convertion and merging code would be needed
> 
> this is alot of complexity

Indeed, and a lot of it comes from insufficient planning in the previous
rounds, so let us not do that again.

> another problem of the struct is that depending on from which lib
> the protocols are set the same protocol may have unequal pointers
> 
> which system do people prefer ?
> do we have a volunteer to implement a struct based system ?
> 
> do people want the string based solution to be applied till then
> or to not have this security feature until then ?

Do we want a good fix, or do we want a quick fix? As I explained earlier, a
good fix requires designing a real security policy, not just a stupid
whitelist. It will take time.

In my opinion, the security issue in question is so benign that we can just
take the time to fix it properly. If people do not agree, then a quick fix
is necessary, but then it should not make it harder to implement the correct
fix later. So for starters, either do not introduce new APIs or make it very
clear they are temporary.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Andreas Cadhalpun]

On 24.01.2016 19:37, Nicolas George wrote:
> Le quintidi 5 pluviôse, an CCXXIV, Andreas Cadhalpun a écrit :
>> I can't reproduce this. The path is only included in the debugging 
>> information.
>> And that happened even more before my change.
> 
> I just built in-tree with:
> 
> ./configure && nice make -j 8, and then I get:
> 
> /tmp/ff2 $ grep /tmp/ff2 ffmpeg  
> Binary file ffmpeg matches
> 
> It does not happen if I revert your original patch and those on top of it.

Can you still reproduce this after applying the patch to use relative paths?

Best regards,
Andreas


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

Re: [FFmpeg-devel] [PATCH 2/2] avformat: add protocol_whitelist

[Andreas Cadhalpun]

On 24.01.2016 16:03, Michael Niedermayer wrote:
> On Sun, Jan 24, 2016 at 03:37:24PM +0100, Andreas Cadhalpun wrote:
>> On 24.01.2016 03:42, Michael Niedermayer wrote:
>>> From: Michael Niedermayer 
>>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>>> index 4964263..2fb9130 100644
>>> --- a/libavformat/avformat.h
>>> +++ b/libavformat/avformat.h
>>> @@ -1815,6 +1815,13 @@ typedef struct AVFormatContext {
>>>   * Demuxing: Set by user.
>>>   */
>>>  int (*open_cb)(struct AVFormatContext *s, AVIOContext **p, const char 
>>> *url, int flags, const AVIOInterruptCB *int_cb, AVDictionary **options);
>>> +
>>> +/**
>>> + * ',' separated list of allowed protocols.
>>> + * - encoding: unused
>>> + * - decoding: set by user through AVOptions (NO direct access)
>>> + */
>>> +char *protocol_whitelist;
>>>  } AVFormatContext;
>>
>> I'm not sure if adding protocol_whitelist to the AVFormatContext is good.
>> Conceptually it would fit better in the AVIOContext. I think that would also
>> make it easier to set a default for it.
> 
> the AVFormatContexts AVIOContext can be NULL

I see. Then it could be added to AVIOContext in addition to AVFormatContext and
URLContext. It would require a bit of synchronization, though.

>> Also, this patch doesn't include a mechanism setting a good default for the
>> protocol_whitelist, which would be needed to fix the problem of 
>> unintentionally
>> mixing local and remote data.
> 
> 
>> If the protocol_whitelist would be saved in the AVIOContext, such a mechanism
>> could be implemented in ffurl_open/ffurl_connect.
> 
> can you elaborate
> i dont see how that would work

The idea is to classify protocols as local (file, concat) or remote (http, tcp).
If no whitelist is set, then it gets set to a default in ffurl_connect.
If the protocol is local, the default whitelist contains only local protocols.
If the protocol is remote the default whitelist contains only remote protocols.
That whitelist would then have to be propagated into the AVFormatContext.

> also some users use their private IO, i dont think theres a foolproof
> way to identify if its remote or local

This mechanism would only cover IO done via our protocols.

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat: add protocol_whitelist

[Nicolas George]

Le quintidi 5 pluviôse, an CCXXIV, Andreas Cadhalpun a écrit :
> The idea is to classify protocols as local (file, concat) or remote (http, 
> tcp).

I am sorry, but this is completely broken. First, concat is not local.
Second, local/remote is not a relevant distinction for security.

Any design made with these assumptions at its code would be insecure.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 2/2] avformat: add protocol_whitelist

[Andreas Cadhalpun]

On 24.01.2016 20:20, Nicolas George wrote:
> Le quintidi 5 pluviôse, an CCXXIV, Andreas Cadhalpun a écrit :
>> The idea is to classify protocols as local (file, concat) or remote (http, 
>> tcp).
> 
> I am sorry, but this is completely broken.

No. It would have prevented the issue with hls.

> First, concat is not local.

But it's usually only used with local files.

> Second, local/remote is not a relevant distinction for security.

Why not?

> Any design made with these assumptions at its code would be insecure.

How?

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Hendrik Leppkes]

On Sun, Jan 24, 2016 at 7:27 PM, Andreas Cadhalpun
 wrote:
> On 24.01.2016 17:14, Henrik Gramner wrote:
>> On Sun, Jan 24, 2016 at 5:02 PM, Hendrik Leppkes  wrote:
>>> Windows doesn't particularly care which slash direction you give it,
>>> so no, that changes nothing. I'm not quite sure why it fails with the
>>> include path this way, maybe some msys shenanigans.
>>> For fun and giggles, I hard-coded the correct include path in the
>>> common.mak file and that made config.h show up again of course, but
>>> the good old compiler error came back just like before.
>>>
>>> Might be msys thats interfering here and translating something it
>>> shouldn't, or double-translating something, I can't really tell just
>>> from the commands it calls.
>>> Like I said before, when initial MSVC support was build by Ronald and
>>> Martin, there were lots of troubles with absolute paths, which in the
>>> end were solved by not using them (sorry, no answers here).
>
> I have a hard time believing that there are environments, where one
> can't use absolute paths...

Its about the combination of msys and its automatic path translation
and the special option syntax msvc uses which msys doesn't recognize,
otherwise it would be fine.
But alas it is how it is, and we have to deal with what we have.

>
>> Is there any reason why we're using absolute paths then?
>
> It is what $(pwd) gives us.
>
>> Can't we just stick to relative paths with forward slashes since
>> they seem to work with all tools?
>
> OK, let's try this.
> Attached is a patch calculating dst_path as relative path.
> That should hopefully work everywhere. Please test it.
>

Unfortunately that doesn't work when there is no common path, ie.
sources on another drive (say D:) as my build directory (say C:)
The script produces a long chain of "../.." then of course, which
would work on a unix-like filesystem, but the only way to switch
drives in windows-path is using absolute paths.

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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Andreas Cadhalpun]

On 24.01.2016 20:40, Hendrik Leppkes wrote:
> On Sun, Jan 24, 2016 at 7:27 PM, Andreas Cadhalpun
>  wrote:
>> On 24.01.2016 17:14, Henrik Gramner wrote:
>> I have a hard time believing that there are environments, where one
>> can't use absolute paths...
> 
> Its about the combination of msys and its automatic path translation
> and the special option syntax msvc uses which msys doesn't recognize,
> otherwise it would be fine.
> But alas it is how it is, and we have to deal with what we have.

:-/

>> OK, let's try this.
>> Attached is a patch calculating dst_path as relative path.
>> That should hopefully work everywhere. Please test it.
>>
> 
> Unfortunately that doesn't work when there is no common path, ie.
> sources on another drive (say D:) as my build directory (say C:)

Don't do that then?

> The script produces a long chain of "../.." then of course, which
> would work on a unix-like filesystem, but the only way to switch
> drives in windows-path is using absolute paths.

Why does it not work with relative paths?
That looks like (another) bug in that environment.

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

[FFmpeg-devel] [PATCH] avcodec/flacenc: fix calculation of bits required in case of custom sample rate

[Paul B Mahol]

Hi,

patch attached.
From c450396407c7fb6b4fbe32a3d5c095ee6fc98d96 Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Sun, 24 Jan 2016 20:47:49 +0100
Subject: [PATCH] avcodec/flacenc: fix calculation of bits required in case of
 custom sample rate

Signed-off-by: Paul B Mahol 
---
 libavcodec/flacenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/flacenc.c b/libavcodec/flacenc.c
index 5db043a..c769833 100644
--- a/libavcodec/flacenc.c
+++ b/libavcodec/flacenc.c
@@ -1023,7 +1023,7 @@ static int count_frame_header(FlacEncodeContext *s)
 count += 16;
 
 /* explicit sample rate */
-count += ((s->sr_code[0] == 12) + (s->sr_code[0] > 12)) * 8;
+count += ((s->sr_code[0] == 12) + (s->sr_code[0] > 12) * 2) * 8;
 
 /* frame header CRC-8 */
 count += 8;
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Hendrik Leppkes]

On Sun, Jan 24, 2016 at 8:51 PM, Andreas Cadhalpun
 wrote:
> On 24.01.2016 20:40, Hendrik Leppkes wrote:
>> On Sun, Jan 24, 2016 at 7:27 PM, Andreas Cadhalpun
>>  wrote:
>>> On 24.01.2016 17:14, Henrik Gramner wrote:
>>> I have a hard time believing that there are environments, where one
>>> can't use absolute paths...
>>
>> Its about the combination of msys and its automatic path translation
>> and the special option syntax msvc uses which msys doesn't recognize,
>> otherwise it would be fine.
>> But alas it is how it is, and we have to deal with what we have.
>
> :-/
>
>>> OK, let's try this.
>>> Attached is a patch calculating dst_path as relative path.
>>> That should hopefully work everywhere. Please test it.
>>>
>>
>> Unfortunately that doesn't work when there is no common path, ie.
>> sources on another drive (say D:) as my build directory (say C:)
>
> Don't do that then?

Thats not an answer.

>
>> The script produces a long chain of "../.." then of course, which
>> would work on a unix-like filesystem, but the only way to switch
>> drives in windows-path is using absolute paths.
>
> Why does it not work with relative paths?
> That looks like (another) bug in that environment.
>

Its just how it works. Relative paths can't switch drive in windows
path, no matter how many ..'s you chain.
Once you hit the root of a drive, .. just redirects to itself, just
like a unix / would, except that you get one per drive instead of a
global one.

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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Andreas Cadhalpun]

On 24.01.2016 20:54, Hendrik Leppkes wrote:
> On Sun, Jan 24, 2016 at 8:51 PM, Andreas Cadhalpun
>  wrote:
>> On 24.01.2016 20:40, Hendrik Leppkes wrote:
>>> Unfortunately that doesn't work when there is no common path, ie.
>>> sources on another drive (say D:) as my build directory (say C:)
>>
>> Don't do that then?
> 
> Thats not an answer.

When the build environment has so many limitations some things just
don't work.

Why is it necessary to do MSVC out-of-tree builds across different
drives?

You could still copy the source to the destination drive, and build
it there.

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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Ronald S. Bultje]

Hi,

On Sun, Jan 24, 2016 at 3:10 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:

> On 24.01.2016 20:54, Hendrik Leppkes wrote:
> > On Sun, Jan 24, 2016 at 8:51 PM, Andreas Cadhalpun
> >  wrote:
> >> On 24.01.2016 20:40, Hendrik Leppkes wrote:
> >>> Unfortunately that doesn't work when there is no common path, ie.
> >>> sources on another drive (say D:) as my build directory (say C:)
> >>
> >> Don't do that then?
> >
> > Thats not an answer.
>
> When the build environment has so many limitations some things just
> don't work.


This used to work.

Fix it, or revert.

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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Henrik Gramner]

On Sun, Jan 24, 2016 at 8:54 PM, Hendrik Leppkes  wrote:
> Its just how it works. Relative paths can't switch drive in windows
> path, no matter how many ..'s you chain.
> Once you hit the root of a drive, .. just redirects to itself, just
> like a unix / would, except that you get one per drive instead of a
> global one.

Doesn't both MSYS and Cygwin map Windows drive letters to UNIX paths?
E.g. D: is at /d in MSYS.

So if you use UNIX paths it's possible to create a relative path
between two arbitrary locations.

Anyway, if git master is currently broken and there's no easy and
obvious fix available we should revert the original patch. Push an
updated version at a later time when all issues have been resolved.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Timothy Gu]

Hi,

On Sun, Jan 24, 2016 at 09:10:53PM +0100, Andreas Cadhalpun wrote:
> When the build environment has so many limitations some things just
> don't work.
> 
> Why is it necessary to do MSVC out-of-tree builds across different
> drives?

It's not, but it used to work, and it doesn't work now. Thus it is a
regression. And as you have asserted so vehemently in the hwaccel/mt thread
regressions are not acceptable.

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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Andreas Cadhalpun]

On 24.01.2016 21:14, Ronald S. Bultje wrote:
> On Sun, Jan 24, 2016 at 3:10 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
> 
>> On 24.01.2016 20:54, Hendrik Leppkes wrote:
>>> On Sun, Jan 24, 2016 at 8:51 PM, Andreas Cadhalpun
>>>  wrote:
 On 24.01.2016 20:40, Hendrik Leppkes wrote:
> Unfortunately that doesn't work when there is no common path, ie.
> sources on another drive (say D:) as my build directory (say C:)

 Don't do that then?
>>>
>>> Thats not an answer.
>>
>> When the build environment has so many limitations some things just
>> don't work.
> 
> 
> This used to work.
> 
> Fix it, or revert.

Who uses that way to build ffmpeg in an MSVC environment?

On 24.01.2016 21:15, Timothy Gu wrote:
> It's not,

Exactly.

> but it used to work, and it doesn't work now.

And there is an easy workaround.

> Thus it is a
> regression. And as you have asserted so vehemently in the hwaccel/mt thread
> regressions are not acceptable.

There is no easy workaround for that.

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat: add protocol_whitelist

[Nicolas George]

Le quintidi 5 pluviôse, an CCXXIV, Andreas Cadhalpun a écrit :
> No. It would have prevented the issue with hls.

Reacting to known attacks by ad-hoc hole-plugging is no way of building
proper security.

> But it's usually only used with local files.

I do not know that. Do you?

> Why not?

Because remote files can be more sensitive than local ones. Because some
environment may download files, turning remote to local.

> How?

I do not know, but you can assume that someone knows and is selling that
information to the highest bidder.

We know that playlists can be abused to leak information. Reimar was warning
about it years ago. People implemented them nonetheless, and guess what, it
did cause information leak.

Now, your reaction is among the lines "the burglar left a footprint in front
of that window, let us wall it". I say no, walling is overkill, and walling
only that particular window is useless. We need to properly lock all the
windows.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[James Almer]

On 1/24/2016 5:20 PM, Andreas Cadhalpun wrote:
> On 24.01.2016 21:14, Ronald S. Bultje wrote:
>> On Sun, Jan 24, 2016 at 3:10 PM, Andreas Cadhalpun <
>> andreas.cadhal...@googlemail.com> wrote:
>>
>>> On 24.01.2016 20:54, Hendrik Leppkes wrote:
 On Sun, Jan 24, 2016 at 8:51 PM, Andreas Cadhalpun
  wrote:
> On 24.01.2016 20:40, Hendrik Leppkes wrote:
>> Unfortunately that doesn't work when there is no common path, ie.
>> sources on another drive (say D:) as my build directory (say C:)
>
> Don't do that then?

 Thats not an answer.
>>>
>>> When the build environment has so many limitations some things just
>>> don't work.
>>
>>
>> This used to work.
>>
>> Fix it, or revert.
> 
> Who uses that way to build ffmpeg in an MSVC environment?

It doesn't matter. People could do it before this set of patches if they
wanted to and now they can't.

> 
> On 24.01.2016 21:15, Timothy Gu wrote:
>> It's not,
> 
> Exactly.
> 
>> but it used to work, and it doesn't work now.
> 
> And there is an easy workaround.

It is absolutely unacceptable to say "do something else" as a "workaround"
to a breakage introduced by a new feature.

Unless you can fix this for every usecase that was working before this
in the very short term, as several people told you already these patches
*must* be reverted until a proper fix is found.

> 
>> Thus it is a
>> regression. And as you have asserted so vehemently in the hwaccel/mt thread
>> regressions are not acceptable.
> 
> There is no easy workaround for that.
> 
> Best regards,
> Andreas
> ___
> 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] build: fix make checkheaders in out-of-tree builds

[Paul B Mahol]

On 1/24/16, James Almer  wrote:
> On 1/24/2016 5:20 PM, Andreas Cadhalpun wrote:
>> On 24.01.2016 21:14, Ronald S. Bultje wrote:
>>> On Sun, Jan 24, 2016 at 3:10 PM, Andreas Cadhalpun <
>>> andreas.cadhal...@googlemail.com> wrote:
>>>
 On 24.01.2016 20:54, Hendrik Leppkes wrote:
> On Sun, Jan 24, 2016 at 8:51 PM, Andreas Cadhalpun
>  wrote:
>> On 24.01.2016 20:40, Hendrik Leppkes wrote:
>>> Unfortunately that doesn't work when there is no common path, ie.
>>> sources on another drive (say D:) as my build directory (say C:)
>>
>> Don't do that then?
>
> Thats not an answer.

 When the build environment has so many limitations some things just
 don't work.
>>>
>>>
>>> This used to work.
>>>
>>> Fix it, or revert.
>>
>> Who uses that way to build ffmpeg in an MSVC environment?
>
> It doesn't matter. People could do it before this set of patches if they
> wanted to and now they can't.
>
>>
>> On 24.01.2016 21:15, Timothy Gu wrote:
>>> It's not,
>>
>> Exactly.
>>
>>> but it used to work, and it doesn't work now.
>>
>> And there is an easy workaround.
>
> It is absolutely unacceptable to say "do something else" as a "workaround"
> to a breakage introduced by a new feature.
>
> Unless you can fix this for every usecase that was working before this
> in the very short term, as several people told you already these patches
> *must* be reverted until a proper fix is found.
>

Yes, it *must* be reverted, FATE shouldn't be red.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/flacenc: fix calculation of bits required in case of custom sample rate

[Rostislav Pehlivanov]

On 24 January 2016 at 19:53, Paul B Mahol  wrote:

> Hi,
>
> patch attached.
>

LGTM

sr_code will be 12 in case the samplerate is below 255000 (so the header
will be +1 bytes long) and 14 (> 12 so the header will be +2 bytes long) if
it's above. The previous code assumed the first part in the brackets would
be 1 so it miscalculated the header size. So lgtm.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg_opt: Allow program metadata other than title to be set.

[Michael Niedermayer]

On Sun, Jan 24, 2016 at 04:03:30PM +0100, Vittorio Gambaletta (VittGam) wrote:
> Hi,
> 
> On 24/01/2016 12:33:51 CET, Michael Niedermayer wrote:
> >On Sun, Jan 24, 2016 at 05:23:22AM +0100, Vittorio Gambaletta (VittGam) 
> >wrote:
> >>This commit makes it possible to add optional metadata (such as 
> >>"service_provider") to an mpegts output stream composed by multiple 
> >>programs (mpts).
> >>
> >>This is needed because the global metadata is not inherited by the single 
> >>programs.
> >>
> >>Signed-off-by: Vittorio Gambaletta 
> >>---
> >> ffmpeg_opt.c |   10 +++---
> >> 1 file changed, 3 insertions(+), 7 deletions(-)
> >
> >with this change the whole namespace except "st"/"program_num" would
> >be used for metadata. This might be a problem in the future if we
> >want to add some non metadata key/value
> 
> What would you suggest then? I have two ideas:
> 
> 1. Move the 'process manually set programs' block above 'process
>manually set metadata' and have it handle `-metadata:p:`
> 2. Use a prefix: `-program st=0:st=1:metadata=service_provider=HelloWorld`
> 3. Change mpegtsenc to look for global metadata if program metadata
>is not present
> 
> The first is probably cleaner.

i have no real preferrance, depends mostly on the people what syntax
and variant is preferred

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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

[FFmpeg-devel] [PATCH] avcodec: split off synth_filter

[James Almer]

Signed-off-by: James Almer 
---
This should make replacing the current dca decoder for foo86's easier, without
having to disable/reenable the compilation of synth_filter files in between
removal/addition commits.

aarch64 and arm changes untested.

 configure  |   3 +-
 libavcodec/Makefile|   3 +-
 libavcodec/aarch64/Makefile|   5 +-
 libavcodec/aarch64/dcadsp_init.c   |  21 --
 .../aarch64/{dcadsp_init.c => synth_filter_init.c} |  16 +-
 libavcodec/arm/Makefile|   9 +-
 libavcodec/arm/dcadsp_init_arm.c   |  22 --
 .../dcadsp_init.c => arm/synth_filter_init_arm.c}  |  33 +--
 libavcodec/x86/Makefile|   2 +
 libavcodec/x86/dcadsp.asm  | 222 -
 libavcodec/x86/dcadsp_init.c   |  51 -
 libavcodec/x86/{dcadsp.asm => synth_filter.asm}|  99 -
 .../x86/{dcadsp_init.c => synth_filter_init.c} |  21 +-
 13 files changed, 26 insertions(+), 481 deletions(-)
 copy libavcodec/aarch64/{dcadsp_init.c => synth_filter_init.c} (78%)
 copy libavcodec/{aarch64/dcadsp_init.c => arm/synth_filter_init_arm.c} (66%)
 copy libavcodec/x86/{dcadsp.asm => synth_filter.asm} (76%)
 copy libavcodec/x86/{dcadsp_init.c => synth_filter_init.c} (83%)

diff --git a/configure b/configure
index 8f4642b..1719a5b 100755
--- a/configure
+++ b/configure
@@ -2039,6 +2039,7 @@ CONFIG_EXTRA="
 sinewin
 snappy
 startcode
+synth_filter
 texturedsp
 texturedspenc
 tpeldsp
@@ -2276,7 +2277,7 @@ comfortnoise_encoder_select="lpc"
 cook_decoder_select="audiodsp mdct sinewin"
 cscd_decoder_select="lzo"
 cscd_decoder_suggest="zlib"
-dca_decoder_select="fmtconvert mdct"
+dca_decoder_select="fmtconvert mdct synth_filter"
 dds_decoder_select="texturedsp"
 dirac_decoder_select="dirac_parse dwt golomb videodsp mpegvideoenc"
 dnxhd_decoder_select="blockdsp idctdsp"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index b9ffdb9..3a6a453 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -115,6 +115,7 @@ OBJS-$(CONFIG_SHARED)  += log2_tab.o 
reverse.o
 OBJS-$(CONFIG_SINEWIN) += sinewin.o sinewin_fixed.o
 OBJS-$(CONFIG_SNAPPY)  += snappy.o
 OBJS-$(CONFIG_STARTCODE)   += startcode.o
+OBJS-$(CONFIG_SYNTH_FILTER)+= synth_filter.o
 OBJS-$(CONFIG_TEXTUREDSP)  += texturedsp.o
 OBJS-$(CONFIG_TEXTUREDSPENC)   += texturedspenc.o
 OBJS-$(CONFIG_TPELDSP) += tpeldsp.o
@@ -223,7 +224,7 @@ OBJS-$(CONFIG_CSCD_DECODER)+= cscd.o
 OBJS-$(CONFIG_CYUV_DECODER)+= cyuv.o
 OBJS-$(CONFIG_DCA_DECODER) += dcadec.o dca.o dcadsp.o  \
   dcadata.o dca_exss.o \
-  dca_xll.o synth_filter.o
+  dca_xll.o
 OBJS-$(CONFIG_DCA_ENCODER) += dcaenc.o dca.o dcadata.o
 OBJS-$(CONFIG_DDS_DECODER) += dds.o
 OBJS-$(CONFIG_DIRAC_DECODER)   += diracdec.o dirac.o diracdsp.o \
diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index 022ed84..2df6325 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -10,6 +10,7 @@ OBJS-$(CONFIG_IMDCT15)  += 
aarch64/imdct15_init.o
 OBJS-$(CONFIG_MPEGAUDIODSP) += aarch64/mpegaudiodsp_init.o
 OBJS-$(CONFIG_NEON_CLOBBER_TEST)+= aarch64/neontest.o
 OBJS-$(CONFIG_VIDEODSP) += aarch64/videodsp_init.o
+OBJS-$(CONFIG_SYNTH_FILTER) += aarch64/synth_filter_init.o
 
 OBJS-$(CONFIG_RV40_DECODER) += aarch64/rv40dsp_init_aarch64.o
 OBJS-$(CONFIG_VC1_DECODER)  += aarch64/vc1dsp_init_aarch64.o
@@ -17,8 +18,7 @@ OBJS-$(CONFIG_VORBIS_DECODER)   += 
aarch64/vorbisdsp_init.o
 
 ARMV8-OBJS-$(CONFIG_VIDEODSP)   += aarch64/videodsp.o
 
-NEON-OBJS-$(CONFIG_DCA_DECODER) += aarch64/dcadsp_neon.o   
\
-   aarch64/synth_filter_neon.o
+NEON-OBJS-$(CONFIG_DCA_DECODER) += aarch64/dcadsp_neon.o
 NEON-OBJS-$(CONFIG_FFT) += aarch64/fft_neon.o
 NEON-OBJS-$(CONFIG_FMTCONVERT)  += aarch64/fmtconvert_neon.o
 NEON-OBJS-$(CONFIG_H264CHROMA)  += aarch64/h264cmc_neon.o
@@ -31,5 +31,6 @@ NEON-OBJS-$(CONFIG_HPELDSP) += 
aarch64/hpeldsp_neon.o
 NEON-OBJS-$(CONFIG_IMDCT15) += aarch64/imdct15_neon.o
 NEON-OBJS-$(CONFIG_MPEGAUDIODSP)+= aarch64/mpegaudiodsp_neon.o
 NEON-OBJS-$(CONFIG_MDCT)+= aarch64/mdct_neon.o
+NEON-OBJS-$(CONFIG_SYNTH_FILTER)+= aarch64/synth_filter_neon.o
 
 NEON-OBJS-$(CONFIG_VORBIS_DECODER)  += aarch64/vorbisdsp_neon.o
diff --git a/libavcodec/aarch64/dcadsp_init.c b/libavcodec/aarch64/dcadsp_init.c

Re: [FFmpeg-devel] [PATCH] lavu: add ff_pthread_setname() and use it in various places

[Michael Niedermayer]

On Sun, Jan 24, 2016 at 01:58:29PM +0100, Clément Bœsch wrote:
> On Wed, Jan 20, 2016 at 09:15:15PM -0300, James Almer wrote:
> > On 1/20/2016 7:46 PM, Clément Bœsch wrote:
> > > diff --git a/libavutil/thread.h b/libavutil/thread.h
> > > index 32ddf40..42430fb 100644
> > > --- a/libavutil/thread.h
> > > +++ b/libavutil/thread.h
> > > @@ -31,6 +31,15 @@
> > >  #if HAVE_PTHREADS
> > >  #include 
> > >  
> > > +static inline void ff_thread_setname(const char *name)
> > > +{
> > > +#if defined(__APPLE__)
> > > +pthread_setname_np(name);
> > > +#elif defined(__linux__) && defined(__GLIBC__)
> > > +pthread_setname_np(pthread_self(), name);
> > > +#endif
> > > +}
> > > +
> > >  #if defined(ASSERT_LEVEL) && ASSERT_LEVEL > 1
> > >  
> > >  #include "log.h"
> > > @@ -143,6 +152,7 @@ static inline int strict_pthread_once(pthread_once_t 
> > > *once_control, void (*init_
> > >  #define AV_ONCE_INIT PTHREAD_ONCE_INIT
> > >  
> > >  #define ff_thread_once(control, routine) pthread_once(control, routine)
> > > +#define ff_thread_setname(name) (0)
> > 
> > This is also being applied to pthreads.
> 
> Damn, it's not a good excuse but I was tired and in a hurry that day.
> Thanks for your patience, new patch attached.
> 
> -- 
> Clément B.

>  libavcodec/frame_thread_encoder.c |2 ++
>  libavcodec/pthread_frame.c|2 ++
>  libavcodec/pthread_slice.c|2 ++
>  libavfilter/pthread.c |2 ++
>  libavformat/async.c   |2 ++
>  libavformat/udp.c |3 +++
>  libavutil/thread.h|   13 +

fails to build:
make distclean ; ../configure  --enable-pthreads  --arch=x86_32 
--target-os=linux --extra-cflags=-m32 --extra-ldflags=-m32  
--enable-cross-compile && make -j12
In file included from libavfilter/pthread.c:30:0:
ffmpeg/libavutil/thread.h: In function ‘ff_thread_setname’:
ffmpeg/libavutil/thread.h:134:5: error: implicit declaration of function 
‘pthread_setname_np’ [-Werror=implicit-function-declaration]

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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