Re: [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer

2016-06-27 Thread Stefano Sabatini
On date Tuesday 2016-06-14 19:36:04 +0200, Stefano Sabatini encoded:
> On date Sunday 2016-06-05 12:59:48 +0200, Stefano Sabatini encoded:
> > On date Thursday 2016-05-19 18:50:17 +0200, Stefano Sabatini encoded:
> > > On date Thursday 2016-05-19 18:45:22 +0200, Stefano Sabatini encoded:
> > > > This format is useful to inject custom user data into streams.
> > > > ---
> > > >  doc/demuxers.texi   |  40 +
> > > >  doc/muxers.texi |  31 +++
> > > >  libavformat/Makefile|   2 +
> > > >  libavformat/allformats.c|   1 +
> > > >  libavformat/fftextdatadec.c | 212 
> > > > 
> > > >  libavformat/fftextdataenc.c | 103 +
> > > >  6 files changed, 389 insertions(+)
> > > >  create mode 100644 libavformat/fftextdatadec.c
> > > >  create mode 100644 libavformat/fftextdataenc.c
> > > 
> > > Short explanation: I needed some way to inject serialized data packets
> > > through stream-copy, so I implemented this format. The other patches
> > > are related (since I needed to inject timed ID3 data).
> > > 
> > > I'm fine with extending it with other options, or to use an
> > > alternative solution (if exists).
> > 
> > Please tell if you consider this format acceptable.
> > 
> > One obvious limitation is that it can't store codec properties (nor
> > the codec name, nor more than one stream). One possibility would be to
> > dump the serialization of AVCodecContext/AVCodecParameters, even if
> > these would require a serious limitation on the format (since that
> > means it would require to use it only as intermediary format, for
> > muxing and demuxing using the same version of FFmpeg, which is fine in
> > my use case).
> 
> Ping. Any hope to get this integrated, or there is someone against it?

Reping with updated patch.
-- 
FFmpeg = Fostering and Fast Multimedia Philosofic Eretic Gospel
>From a22253ea6831fbb3560a6275141df0bab969d3fc Mon Sep 17 00:00:00 2001
From: Stefano Sabatini 
Date: Sun, 20 Mar 2016 15:51:30 +0100
Subject: [PATCH] lavf: add textdata virtual demuxer and muxer

This format is useful to inject custom user data into streams.
---
 doc/demuxers.texi   |  40 +
 doc/muxers.texi |  31 +++
 libavformat/Makefile|   2 +
 libavformat/allformats.c|   1 +
 libavformat/fftextdatadec.c | 212 
 libavformat/fftextdataenc.c | 103 +
 6 files changed, 389 insertions(+)
 create mode 100644 libavformat/fftextdatadec.c
 create mode 100644 libavformat/fftextdataenc.c

diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index e34f8b3..9fc58eb 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -254,6 +254,46 @@ This demuxer is used to demux FLV files and RTMP network streams.
 Allocate the streams according to the onMetaData array content.
 @end table
 
+@anchor{fftextdata}
+@section fftextdata, fftd
+
+FFmpeg text data demuxer.
+
+This special demuxer allows to read serialized data base64-encoded and
+remux it. It is especially useful for injecting opaque data streams.
+
+The fftextdata bytestream consists of a sequence of packets. Each
+packet starts with a timestamps expressed in a format recognized by
+FFmpeg (see
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) manual,ffmpeg-utils})
+followed by a sequence of spaces and the base64 encoded data for the
+packet, terminated by ";". The data representation may contain
+interleaved space characters (a space, a tab, or a newline) which are
+ignored.
+
+At the moment a single stream can be represented by an fftextdata
+bytestream.
+
+If an input filename is "fftextdata" or "fftd" then the file format is
+recognized as fftextdata.
+
+@subsection Options
+@table @option
+@item codec_name
+Set the codec name for the packets data.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Inject timed_id3 packed data stored into the data.fftd file into the
+output file.
+@example
+ffmpeg -i input.mp4 -codec_name timed_id3 -f fftextdata -i data.fftd -y -map 0 -map 1 -c copy output.ts
+@end example
+@end itemize
+
 @section libgme
 
 The Game Music Emu library is a collection of video game music file emulators.
diff --git a/doc/muxers.texi b/doc/muxers.texi
index c2ca0ba..0697728 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -129,6 +129,37 @@ and the input video converted to MPEG-2 video, use the command:
 ffmpeg -i INPUT -c:a pcm_u8 -c:v mpeg2video -f crc -
 @end example
 
+@section fftextdata, fftd
+
+FFmpeg text data muxer.
+
+The fftextdata bytestream consists of a sequence of packets. Each
+packet starts with a timestamps expressed in a format recognized by
+FFmpeg (see
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) manual,ffmpeg-utils})
+followed by a sequence of spaces and the base64 encoded data for the
+packet, terminated by ";". The data representation may contain
+interleaved space characters (a sp

[FFmpeg-devel] [PATCH] tests/fate-run: support both le/be formats on pixfmts

2016-06-27 Thread Muhammad Faiz
regardless of the actual supported formats of tested filters
allowing filters to support only native endian formats

Signed-off-by: Muhammad Faiz 
---
 tests/fate-run.sh |  7 ++-
 tests/ref/fate/filter-pixfmts-lut | 22 ++
 tests/ref/fate/filter-pixfmts-pad | 32 
 3 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index c898695..066970c 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -232,7 +232,12 @@ pixfmts(){
 $showfiltfmts scale | awk -F '[ \r]' '/^OUTPUT/{ fmt=substr($3, 5); print 
fmt }' | sort >$scale_out_fmts
 comm -12 $scale_in_fmts $scale_out_fmts >$scale_exclude_fmts
 
-$showfiltfmts $filter | awk -F '[ \r]' '/^INPUT/{ fmt=substr($3, 5); print 
fmt }' | sort >$in_fmts
+$showfiltfmts $filter | awk -F '[ \r]' \
+'/^INPUT/{ fmt=substr($3, 5);
+print fmt;
+print gensub(/(be)$/, "le", "g", fmt);
+print gensub(/(le)$/, "be", "g", fmt);
+}' | sort >$in_fmts
 pix_fmts=$(comm -12 $scale_exclude_fmts $in_fmts)
 
 outertest=$test
diff --git a/tests/ref/fate/filter-pixfmts-lut 
b/tests/ref/fate/filter-pixfmts-lut
index 47e79d1..fa1763d 100644
--- a/tests/ref/fate/filter-pixfmts-lut
+++ b/tests/ref/fate/filter-pixfmts-lut
@@ -3,37 +3,59 @@ argb4f575be3cd02799389f581df99c4de38
 bgr24   fa43e3b2abfde8d9e60e157a9acc553d
 bgra4e2e689897ee7a8e42b16234597bab35
 rgb24   a356171207723a580e7d277078072005
+rgb48be d9a7669cab9159c7f28dc92387fab304
 rgb48le 5c7dd8575836d18c91e09f1915cf9aa9
 rgba7bc854c2698b78af3e9159a19c2d9d21
+rgba64be612546f91b274bcc8c314386ba410c3d
 rgba64le3a087ecab583d1930220592731f282b4
 yuv410p 51b39a0e33f108e652457a26667319ea
 yuv411p 9204c5af92aef4922a05f58c1f6c095e
 yuv420p 7c43bb0cae8dee633375c89295598508
+yuv420p10be a6663932e075bcfab96148082ab9ab7c
 yuv420p10le 1352712dd31cce78bd5441294004cf85
+yuv420p12be 7e51fa387cac0df48ec51bdfa538a53d
 yuv420p12le c66f82da9fda458ba3abda057c58e591
+yuv420p14be 99498c69bb247fadc973b6e912f32dc7
 yuv420p14le e45cb5e2a75bf6143da0b55004767f78
+yuv420p16be a8ff20f5a96ba42fa5968bda64e160bd
 yuv420p16le eff54782c51770edfd6b84c958ac7120
+yuv420p9be  84f752b682dcb02178653197bc29f2f8
 yuv420p9le  4a6776b3379f12ad45caee8072a13695
 yuv422p 67df35da0c35e54882492b2365438254
+yuv422p10be 5f6bbd95917512d650823040aebd44c0
 yuv422p10le 0158371a800294015def7f0ef66c78ea
+yuv422p12be 8fea3ed2bb16ef8052ab3dbc322b5bbe
 yuv422p12le bc49d3863ffb89658a17bf8c4fe773b0
+yuv422p14be 25ab2f40ab5b54f2d3f03ced389c1da7
 yuv422p14le b55cb791d286b0b3391fe7481785e5b3
+yuv422p16be be0db4de9820408fd6770cdcea0535f9
 yuv422p16le fc3b2ba889ffaf1633000fc774307c33
+yuv422p9be  ba42020043dd407327882de068d2a1c1
 yuv422p9le  6e2a42ae36ed5e8b5112987639728af5
 yuv440p 5e41adcfc27be4369afd217b61b2ffe3
+yuv440p10be cbcbbbdbe4a1dc041bee11b757be89d7
 yuv440p10le 8b49714bba268fb4a79b5a84223ad17a
+yuv440p12be 7603fda62bd9cb383e7d82af0bf5fefd
 yuv440p12le 15ab4f453238bd9c13b18af81e22f060
 yuv444p a2b58590aef88db2c1f14a1a3a3b0359
+yuv444p10be 3719f137bb7759e51a5116a6e3bf0066
 yuv444p10le c076c20fc808f95b34adb88aca442f48
+yuv444p12be bf93db19cf2708a6f671c73d8fe5e746
 yuv444p12le af8d4dd88169d5cffc2f3fce6333a94c
+yuv444p14be 47a825cf9f088abc744a66547e00f3a8
 yuv444p14le 93367133e25d088d4535199ed1f1ed58
+yuv444p16be 27effaa1096361ffb6b69d1d0e8a35d6
 yuv444p16le 800940feec14365ccd9b4863e38f6991
+yuv444p9be  55ea2c5d5d819ab983e4770d4ddf20a2
 yuv444p9le  c120044350852c4cd16a302dd1ceda79
 yuva420p518a380bf1af60ef2ecf4754eec088e9
+yuva420p16beaaa6db0ce07716dab15782dfbad5aca9
 yuva420p16le72ad4fa535b007d122666ce103ef9c8b
 yuva422p7110ac2e37377b05b6fc5ad967dfabb5
+yuva422p16bef5c06d197a1096314553b1d89f43d96f
 yuva422p16lee2867210660ada5784a60b4339ac52c0
 yuva444p642f3958f141dece9e99407945e2ef43
+yuva444p16be5337a7c64bd26a675d4a2bb8881e6fcb
 yuva444p16leab04ba8acbe38085b0df650d82065eb0
 yuvj420p65bc7c7f06a6221155ca7f9cfca4
 yuvj422pff5baffefc8ffe4547653092fd7da200
diff --git a/tests/ref/fate/filter-pixfmts-pad 
b/tests/ref/fate/filter-pixfmts-pad
index e94db4f..17d1800 100644
--- a/tests/ref/fate/filter-pixfmts-pad
+++ b/tests/ref/fate/filter-pixfmts-pad
@@ -7,53 +7,85 @@ bgr24   f8b65ad845905c7d0c93ca28dfbb826f
 bgra929aac15e848038e367c250037575f9f
 gbrap   6712984b4a068ffa534f0cb35b2adc6f
 gbrp3c94d39256db240

Re: [FFmpeg-devel] [PATCH] avfilter/vf_rotate: add >8 bit depth support

2016-06-27 Thread Muhammad Faiz
On Sun, Jun 26, 2016 at 4:20 PM, Muhammad Faiz  wrote:
> On Sun, Jun 26, 2016 at 3:22 PM, Paul B Mahol  wrote:
>> On 6/26/16, Muhammad Faiz  wrote:
>>> On Sun, Jun 26, 2016 at 2:30 PM, Paul B Mahol  wrote:
 On 6/26/16, Carl Eugen Hoyos  wrote:
> Muhammad Faiz  gmail.com> writes:
>
>> I think it's not because of bit-exact problem.
>> But because fate probes supported formats (with
>> libavfilter/tests/filtfmts)
>> On BE machine, code with native formats will generate error
>> because fate-ref contains yuv*le entries but fate expects yuv*be
>>>
>>> Another problem is that drawutils only support LE format.
>>>
>
> We control the fate test, so we can require an additional
> (bit-exact) conversion from BE to LE to make the fate
> test pass.

 Really, even for pixfmts?

 I will apply this as is. Feel free to add your hacks if you want, after.
>>>
>>> In the perspective of code correctness, this should be OK.
>>> But performance on BE machine will be unoptimal because:
>>>  - reading/writing in foreign endian is probably slower
>>>  - I guess most decoders' output frame is native endian. This will
>>>make unnecessary format conversion
>>>  - some other filters only support native endian formats. This will
>>>also make unnecessary format conversion.
>>>
>>> Of course, the problem is not in your patch.
>>
>> Yes. BE is dead.
>
> The problem is in drawutils. I think, it should support native endian
> or support both little/big endian.
>
> Thank's

See https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195930.html

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


Re: [FFmpeg-devel] [PATCH] tests/fate-run: support both le/be formats on pixfmts

2016-06-27 Thread Hendrik Leppkes
On Mon, Jun 27, 2016 at 9:52 AM, Muhammad Faiz  wrote:
> regardless of the actual supported formats of tested filters
> allowing filters to support only native endian formats
>
> Signed-off-by: Muhammad Faiz 
> ---
>  tests/fate-run.sh |  7 ++-
>  tests/ref/fate/filter-pixfmts-lut | 22 ++
>  tests/ref/fate/filter-pixfmts-pad | 32 
>  3 files changed, 60 insertions(+), 1 deletion(-)
>
> diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> index c898695..066970c 100755
> --- a/tests/fate-run.sh
> +++ b/tests/fate-run.sh
> @@ -232,7 +232,12 @@ pixfmts(){
>  $showfiltfmts scale | awk -F '[ \r]' '/^OUTPUT/{ fmt=substr($3, 5); 
> print fmt }' | sort >$scale_out_fmts
>  comm -12 $scale_in_fmts $scale_out_fmts >$scale_exclude_fmts
>
> -$showfiltfmts $filter | awk -F '[ \r]' '/^INPUT/{ fmt=substr($3, 5); 
> print fmt }' | sort >$in_fmts
> +$showfiltfmts $filter | awk -F '[ \r]' \
> +'/^INPUT/{ fmt=substr($3, 5);
> +print fmt;
> +print gensub(/(be)$/, "le", "g", fmt);
> +print gensub(/(le)$/, "be", "g", fmt);
> +}' | sort >$in_fmts
>  pix_fmts=$(comm -12 $scale_exclude_fmts $in_fmts)
>

This doesn't really test anything new, does it?
Just adds one more scaling step to convert endianness for some filters.

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


Re: [FFmpeg-devel] [PATCH] tests/fate-run: support both le/be formats on pixfmts

2016-06-27 Thread Muhammad Faiz
On Mon, Jun 27, 2016 at 2:59 PM, Hendrik Leppkes  wrote:
> On Mon, Jun 27, 2016 at 9:52 AM, Muhammad Faiz  wrote:
>> regardless of the actual supported formats of tested filters
>> allowing filters to support only native endian formats
>>
>> Signed-off-by: Muhammad Faiz 
>> ---
>>  tests/fate-run.sh |  7 ++-
>>  tests/ref/fate/filter-pixfmts-lut | 22 ++
>>  tests/ref/fate/filter-pixfmts-pad | 32 
>>  3 files changed, 60 insertions(+), 1 deletion(-)
>>
>> diff --git a/tests/fate-run.sh b/tests/fate-run.sh
>> index c898695..066970c 100755
>> --- a/tests/fate-run.sh
>> +++ b/tests/fate-run.sh
>> @@ -232,7 +232,12 @@ pixfmts(){
>>  $showfiltfmts scale | awk -F '[ \r]' '/^OUTPUT/{ fmt=substr($3, 5); 
>> print fmt }' | sort >$scale_out_fmts
>>  comm -12 $scale_in_fmts $scale_out_fmts >$scale_exclude_fmts
>>
>> -$showfiltfmts $filter | awk -F '[ \r]' '/^INPUT/{ fmt=substr($3, 5); 
>> print fmt }' | sort >$in_fmts
>> +$showfiltfmts $filter | awk -F '[ \r]' \
>> +'/^INPUT/{ fmt=substr($3, 5);
>> +print fmt;
>> +print gensub(/(be)$/, "le", "g", fmt);
>> +print gensub(/(le)$/, "be", "g", fmt);
>> +}' | sort >$in_fmts
>>  pix_fmts=$(comm -12 $scale_exclude_fmts $in_fmts)
>>
>
> This doesn't really test anything new, does it?
> Just adds one more scaling step to convert endianness for some filters.

No, it doesn't of course.
Just for example: a filter support yuv420p10le on LE machine,
yuv420p10be on BE machine
fate will test both yuv420p10le/yuv420p10be

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


Re: [FFmpeg-devel] [PATCH] tests/fate-run: support both le/be formats on pixfmts

2016-06-27 Thread Hendrik Leppkes
On Mon, Jun 27, 2016 at 10:12 AM, Muhammad Faiz  wrote:
> On Mon, Jun 27, 2016 at 2:59 PM, Hendrik Leppkes  wrote:
>> On Mon, Jun 27, 2016 at 9:52 AM, Muhammad Faiz  wrote:
>>> regardless of the actual supported formats of tested filters
>>> allowing filters to support only native endian formats
>>>
>>> Signed-off-by: Muhammad Faiz 
>>> ---
>>>  tests/fate-run.sh |  7 ++-
>>>  tests/ref/fate/filter-pixfmts-lut | 22 ++
>>>  tests/ref/fate/filter-pixfmts-pad | 32 
>>>  3 files changed, 60 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/tests/fate-run.sh b/tests/fate-run.sh
>>> index c898695..066970c 100755
>>> --- a/tests/fate-run.sh
>>> +++ b/tests/fate-run.sh
>>> @@ -232,7 +232,12 @@ pixfmts(){
>>>  $showfiltfmts scale | awk -F '[ \r]' '/^OUTPUT/{ fmt=substr($3, 5); 
>>> print fmt }' | sort >$scale_out_fmts
>>>  comm -12 $scale_in_fmts $scale_out_fmts >$scale_exclude_fmts
>>>
>>> -$showfiltfmts $filter | awk -F '[ \r]' '/^INPUT/{ fmt=substr($3, 5); 
>>> print fmt }' | sort >$in_fmts
>>> +$showfiltfmts $filter | awk -F '[ \r]' \
>>> +'/^INPUT/{ fmt=substr($3, 5);
>>> +print fmt;
>>> +print gensub(/(be)$/, "le", "g", fmt);
>>> +print gensub(/(le)$/, "be", "g", fmt);
>>> +}' | sort >$in_fmts
>>>  pix_fmts=$(comm -12 $scale_exclude_fmts $in_fmts)
>>>
>>
>> This doesn't really test anything new, does it?
>> Just adds one more scaling step to convert endianness for some filters.
>
> No, it doesn't of course.
> Just for example: a filter support yuv420p10le on LE machine,
> yuv420p10be on BE machine
> fate will test both yuv420p10le/yuv420p10be

I would argue it doesn't add anything then but extra runtime, unless
I'm missing something.
The endian conversion is lossless, so even if we test LE on a BE
system the result is still accurate.

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


Re: [FFmpeg-devel] [PATCH v3] lavd/decklink_common: Fix error caused by -Werror=missing-prototypes

2016-06-27 Thread Michael Niedermayer
On Sun, Jun 26, 2016 at 08:24:49PM -0400, Rick Kern wrote:
> decklink_common.cpp includes a .cpp file from the DeckLink API which fails
> to build because there are non-static functions in the included .cpp file.
> This disables the missing-prototypes error so the file can be included.
> 
> Signed-off-by: Rick Kern 
> ---
>  libavdevice/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavdevice/Makefile b/libavdevice/Makefile
> index 585827b..e281825 100644
> --- a/libavdevice/Makefile
> +++ b/libavdevice/Makefile
> @@ -19,6 +19,8 @@ OBJS-$(CONFIG_BKTR_INDEV)+= bktr.o
>  OBJS-$(CONFIG_CACA_OUTDEV)   += caca.o
>  OBJS-$(CONFIG_DECKLINK_OUTDEV)   += decklink_enc.o decklink_enc_c.o 
> decklink_common.o
>  OBJS-$(CONFIG_DECKLINK_INDEV)+= decklink_dec.o decklink_dec_c.o 
> decklink_common.o

> +$(SUBDIR)decklink_common.o: CXXFLAGS += -Wno-error=missing-prototypes

Is this portable ?
is there some posix document or similar that says that this
is supported by all compilers ?

and in what directory are these system headers that cause the problem?
is this directory a system header directory ?
what compiler fails to suppress warnings from system headers ?

also:
http://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-in-system-headers

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

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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


Re: [FFmpeg-devel] [PATCH v2] lavd/decklink_common: Fix error caused by -Werror=missing-prototypes

2016-06-27 Thread Michael Niedermayer
On Sun, Jun 26, 2016 at 09:00:58PM -0400, Richard Kern wrote:
> 
> > On Jun 25, 2016, at 3:16 PM, Michael Niedermayer  
> > wrote:
> > 
> > On Sat, Jun 25, 2016 at 05:29:56PM +, Carl Eugen Hoyos wrote:
> >> Michael Niedermayer  niedermayer.cc> writes:
> >> 
> >>> why does this happen ?
> >> 
> >> I thought it happens because FFmpeg include third-party 
> >> files that do not copmile with error=missing-prototypes.
> > 
> > but why should they build with random "warning are error" flags ?
> > one cannot write headers that are guranteed to never trigger a warning
> > on any compiler.
> > and if one cannot and does not, -Werror* could not work unless it
> > has an exception for system / 3rd party stuff
> 

> The error is being thrown when the location of the decklink headers being
> pulled in as user includes with -I.

i would assume the same happens with any header, i didnt try but
libc headers likely will also fail with sufficient pedant warning/error
if they are included as "user headers"


> Clang doesn’t support -i, and I couldn’t
> find an equivalent option to include as system headers. Am I missing
> something?

http://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-in-system-headers


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

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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


Re: [FFmpeg-devel] [PATCH] tests/fate-run: support both le/be formats on pixfmts

2016-06-27 Thread Muhammad Faiz
On Mon, Jun 27, 2016 at 3:28 PM, Hendrik Leppkes  wrote:
> On Mon, Jun 27, 2016 at 10:12 AM, Muhammad Faiz  wrote:
>> On Mon, Jun 27, 2016 at 2:59 PM, Hendrik Leppkes  wrote:
>>> On Mon, Jun 27, 2016 at 9:52 AM, Muhammad Faiz  wrote:
 regardless of the actual supported formats of tested filters
 allowing filters to support only native endian formats

 Signed-off-by: Muhammad Faiz 
 ---
  tests/fate-run.sh |  7 ++-
  tests/ref/fate/filter-pixfmts-lut | 22 ++
  tests/ref/fate/filter-pixfmts-pad | 32 
  3 files changed, 60 insertions(+), 1 deletion(-)

 diff --git a/tests/fate-run.sh b/tests/fate-run.sh
 index c898695..066970c 100755
 --- a/tests/fate-run.sh
 +++ b/tests/fate-run.sh
 @@ -232,7 +232,12 @@ pixfmts(){
  $showfiltfmts scale | awk -F '[ \r]' '/^OUTPUT/{ fmt=substr($3, 5); 
 print fmt }' | sort >$scale_out_fmts
  comm -12 $scale_in_fmts $scale_out_fmts >$scale_exclude_fmts

 -$showfiltfmts $filter | awk -F '[ \r]' '/^INPUT/{ fmt=substr($3, 5); 
 print fmt }' | sort >$in_fmts
 +$showfiltfmts $filter | awk -F '[ \r]' \
 +'/^INPUT/{ fmt=substr($3, 5);
 +print fmt;
 +print gensub(/(be)$/, "le", "g", fmt);
 +print gensub(/(le)$/, "be", "g", fmt);
 +}' | sort >$in_fmts
  pix_fmts=$(comm -12 $scale_exclude_fmts $in_fmts)

>>>
>>> This doesn't really test anything new, does it?
>>> Just adds one more scaling step to convert endianness for some filters.
>>
>> No, it doesn't of course.
>> Just for example: a filter support yuv420p10le on LE machine,
>> yuv420p10be on BE machine
>> fate will test both yuv420p10le/yuv420p10be
>
> I would argue it doesn't add anything then but extra runtime, unless
> I'm missing something.
> The endian conversion is lossless, so even if we test LE on a BE
> system the result is still accurate.

Yes, It will be slower. But, in case of filters that support both le/be,
this is required. Checking whether a filter supports native only or
supports both
isn't trivial (for me).

Another nice feature is that if someone decides to support
both le/be, the fate-ref already exists.

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


Re: [FFmpeg-devel] [PATCH v2] lavd/decklink_common: Fix error caused by -Werror=missing-prototypes

2016-06-27 Thread Nicolas George
Le decadi 10 messidor, an CCXXIV, Michael Niedermayer a écrit :
> > The error is being thrown when the location of the decklink headers being
> > pulled in as user includes with -I.
> 
> i would assume the same happens with any header, i didnt try but
> libc headers likely will also fail with sufficient pedant warning/error
> if they are included as "user headers"

It happens even with FFmpeg's own headers: -Ilibavutil will cause build
failures due to a conflicting time.h. The short of it is they should not add
-Ilibavutil.

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] release/3.1

2016-06-27 Thread Thomas Volkert
On 27.06.2016 02:48, Michael Niedermayer wrote:
> On Sun, Jun 26, 2016 at 03:36:33AM +0200, Michael Niedermayer wrote:
>> Hi all
>>
>> ive branched release/3.1 off from master
>> i will make the 3.1 release from HEAD of this branch tomorrow
>> If there are any last minute changes that should go in, thats your
>> very last chance to put them in !
> 3.1 release made
Thanks.

Shared on Facebook.

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


Re: [FFmpeg-devel] ffmpeg_vdpau: Re-add ability to ignore level check

2016-06-27 Thread Andy Furniss

Michael Niedermayer wrote:

On Tue, Jun 07, 2016 at 07:51:18PM +0100, Mark Thompson wrote:

Fixes ticket 5286.

Uses the global -hwaccel_lax_profile_check option (may be misnamed
for this purpose, but it has the right spirit).
---
Only compile tested (no hardware).

Maybe -hwaccel_lax_profile_check should be renamed to something a bit more 
general - it was named for the specific VAAPI case, but this is really the same 
type of issue.  (-hwaccel_ignore_capabilities or something like that?)

  ffmpeg_vdpau.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)


is anyone against applying this ?


From the POV of a user I still think as noted in trac -

https://trac.ffmpeg.org/ticket/5286

That it would be better if ffmpeg didn't silently fall back to s/w dec
without saying so. Which could include ... use -hwaccel_lax_profile_check
to override.


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


[FFmpeg-devel] [PATCH] avfilter/drawutils: change to support native endian only

2016-06-27 Thread Muhammad Faiz
previously support little endian only because of fate problem
generally native endian code is faster

require 'tests/fate-run: support both le/be formats on pixfmts'
need someone tests it on BE machine

Signed-off-by: Muhammad Faiz 
---
 libavfilter/drawutils.c | 43 --
 libavfilter/vf_lut.c| 81 +
 2 files changed, 62 insertions(+), 62 deletions(-)

diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
index e533040..610f8b6 100644
--- a/libavfilter/drawutils.c
+++ b/libavfilter/drawutils.c
@@ -173,6 +173,22 @@ void ff_copy_rectangle(uint8_t *dst[4], int 
dst_linesize[4],
 }
 }
 
+static int is_native_endian(const AVPixFmtDescriptor *desc)
+{
+int len = strlen(desc->name);
+#if HAVE_BIGENDIAN
+const char *native = "be", *foreign = "le";
+#else
+const char *native = "le", *foreign = "be";
+#endif
+
+if (!strcmp(desc->name+len-2, native))
+return 1;
+if (!strcmp(desc->name+len-2, foreign))
+return 0;
+return 1;
+}
+
 int ff_draw_init(FFDrawContext *draw, enum AVPixelFormat format, unsigned 
flags)
 {
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(format);
@@ -184,13 +200,13 @@ int ff_draw_init(FFDrawContext *draw, enum AVPixelFormat 
format, unsigned flags)
 return AVERROR(EINVAL);
 if (desc->flags & ~(AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_RGB | 
AV_PIX_FMT_FLAG_PSEUDOPAL | AV_PIX_FMT_FLAG_ALPHA))
 return AVERROR(ENOSYS);
+if (!is_native_endian(desc))
+return AVERROR(ENOSYS);
 for (i = 0; i < desc->nb_components; i++) {
 c = &desc->comp[i];
 /* for now, only 8-16 bits formats */
 if (c->depth < 8 || c->depth > 16)
 return AVERROR(ENOSYS);
-if (desc->flags & AV_PIX_FMT_FLAG_BE)
-return AVERROR(ENOSYS);
 if (c->plane >= MAX_PLANES)
 return AVERROR(ENOSYS);
 /* strange interleaving */
@@ -259,7 +275,7 @@ void ff_draw_color(FFDrawContext *draw, FFDrawColor *color, 
const uint8_t rgba[4
 } else if (draw->format == AV_PIX_FMT_GRAY8 || draw->format == 
AV_PIX_FMT_GRAY8A) {
 color->comp[0].u8[0] = RGB_TO_Y_CCIR(rgba[0], rgba[1], rgba[2]);
 color->comp[1].u8[0] = rgba[3];
-} else if (draw->format == AV_PIX_FMT_GRAY16LE || draw->format == 
AV_PIX_FMT_YA16LE) {
+} else if (draw->format == AV_PIX_FMT_GRAY16 || draw->format == 
AV_PIX_FMT_YA16) {
 color->comp[0].u8[0] = RGB_TO_Y_CCIR(rgba[0], rgba[1], rgba[2]);
 color->comp[0].u16[0] = color->comp[0].u8[0] << 8;
 color->comp[1].u8[0] = rgba[3];
@@ -317,11 +333,6 @@ void ff_fill_rectangle(FFDrawContext *draw, FFDrawColor 
*color,
 return;
 p = p0;
 
-if (HAVE_BIGENDIAN && draw->desc->comp[0].depth > 8) {
-for (x = 0; 2*x < draw->pixelstep[plane]; x++)
-color_tmp.comp[plane].u16[x] = 
av_bswap16(color_tmp.comp[plane].u16[x]);
-}
-
 /* copy first line from color */
 for (x = 0; x < wp; x++) {
 memcpy(p, color_tmp.comp[plane].u8, draw->pixelstep[plane]);
@@ -412,19 +423,19 @@ static void blend_line16(uint8_t *dst, unsigned src, 
unsigned alpha,
 
 if (left) {
 unsigned suba = (left * alpha) >> hsub;
-uint16_t value = AV_RL16(dst);
-AV_WL16(dst, (value * (0x10001 - suba) + src * suba) >> 16);
+uint16_t value = AV_RN16(dst);
+AV_WN16(dst, (value * (0x10001 - suba) + src * suba) >> 16);
 dst += dx;
 }
 for (x = 0; x < w; x++) {
-uint16_t value = AV_RL16(dst);
-AV_WL16(dst, (value * tau + asrc) >> 16);
+uint16_t value = AV_RN16(dst);
+AV_WN16(dst, (value * tau + asrc) >> 16);
 dst += dx;
 }
 if (right) {
 unsigned suba = (right * alpha) >> hsub;
-uint16_t value = AV_RL16(dst);
-AV_WL16(dst, (value * (0x10001 - suba) + src * suba) >> 16);
+uint16_t value = AV_RN16(dst);
+AV_WN16(dst, (value * (0x10001 - suba) + src * suba) >> 16);
 }
 }
 
@@ -516,7 +527,7 @@ static void blend_pixel16(uint8_t *dst, unsigned src, 
unsigned alpha,
 unsigned xmmod = 7 >> l2depth;
 unsigned mbits = (1 << (1 << l2depth)) - 1;
 unsigned mmult = 255 / mbits;
-uint16_t value = AV_RL16(dst);
+uint16_t value = AV_RN16(dst);
 
 for (y = 0; y < h; y++) {
 xm = xm0;
@@ -528,7 +539,7 @@ static void blend_pixel16(uint8_t *dst, unsigned src, 
unsigned alpha,
 mask += mask_linesize;
 }
 alpha = (t >> shift) * alpha;
-AV_WL16(dst, ((0x10001 - alpha) * value + alpha * src) >> 16);
+AV_WN16(dst, ((0x10001 - alpha) * value + alpha * src) >> 16);
 }
 
 static void blend_pixel(uint8_t *dst, unsigned src, unsigned alpha,
diff --git a/libavfilter/vf_lut.c b/libavfilter/vf_lut.c
index 5148663..4a6f6d2 100644
--- a/libavfilter/vf_lut.c
+++ b/libavfilter/vf_lut.c
@@ -115,18 +115,18 @@ static av_cold void uninit(AVFilterCon

Re: [FFmpeg-devel] [PATCH] avfilter/vf_rotate: add >8 bit depth support

2016-06-27 Thread Muhammad Faiz
On Mon, Jun 27, 2016 at 2:59 PM, Muhammad Faiz  wrote:
> On Sun, Jun 26, 2016 at 4:20 PM, Muhammad Faiz  wrote:
>> On Sun, Jun 26, 2016 at 3:22 PM, Paul B Mahol  wrote:
>>> On 6/26/16, Muhammad Faiz  wrote:
 On Sun, Jun 26, 2016 at 2:30 PM, Paul B Mahol  wrote:
> On 6/26/16, Carl Eugen Hoyos  wrote:
>> Muhammad Faiz  gmail.com> writes:
>>
>>> I think it's not because of bit-exact problem.
>>> But because fate probes supported formats (with
>>> libavfilter/tests/filtfmts)
>>> On BE machine, code with native formats will generate error
>>> because fate-ref contains yuv*le entries but fate expects yuv*be

 Another problem is that drawutils only support LE format.

>>
>> We control the fate test, so we can require an additional
>> (bit-exact) conversion from BE to LE to make the fate
>> test pass.
>
> Really, even for pixfmts?
>
> I will apply this as is. Feel free to add your hacks if you want, after.

 In the perspective of code correctness, this should be OK.
 But performance on BE machine will be unoptimal because:
  - reading/writing in foreign endian is probably slower
  - I guess most decoders' output frame is native endian. This will
make unnecessary format conversion
  - some other filters only support native endian formats. This will
also make unnecessary format conversion.

 Of course, the problem is not in your patch.
>>>
>>> Yes. BE is dead.
>>
>> The problem is in drawutils. I think, it should support native endian
>> or support both little/big endian.
>>
>> Thank's
>
> See https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195930.html
>
> Thank's

See also https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195941.html

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


Re: [FFmpeg-devel] [PATCH] h264: make H264ParamSets sps const

2016-06-27 Thread Benoit Fouet

Hi,

On 25/06/2016 14:15, Clément Bœsch wrote:

On Fri, Jun 24, 2016 at 09:20:35AM +0200, Benoit Fouet wrote:
[...]

Any objection to this patch now?

iam ok with the patch, maybe give others a bit of time to reply
before applying though

Yeah, I'm in no hurry, I just saw this FIXME in the context of one of
Mateo's patches.
I was more waiting for some feedback from Hendrik or Clément, anyway, as
they were the ones raising the points.

Should be fine if indeed the following computation:

 int width  = 16 * sps->mb_width;
 int height = 16 * sps->mb_height * (2 - sps->frame_mbs_only_flag);

...is always correct.


Good one. It seems the check that is done today on the height part is 
not enough.

I've also found another place which was writing to the SPS and shouldn't.
I'm sending a new patchset for all this.

Thanks for the review,
--
Ben

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


[FFmpeg-devel] [PATCH 2/2] lavf: mark stream as const pointer in av_stream_get_side_data()

2016-06-27 Thread Clément Bœsch
From: Clément Bœsch 

TODO: bump lavf minor
XXX: should i add a FF_API_NOCONST_GET_SIDE_DATA?
---
 libavformat/avformat.h | 2 +-
 libavformat/utils.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 876f1e3..43b4a02 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2051,7 +2051,7 @@ uint8_t *av_stream_new_side_data(AVStream *stream,
  * @param size pointer for side information size to store (optional)
  * @return pointer to data if present or NULL otherwise
  */
-uint8_t *av_stream_get_side_data(AVStream *stream,
+uint8_t *av_stream_get_side_data(const AVStream *stream,
  enum AVPacketSideDataType type, int *size);
 
 AVProgram *av_new_program(AVFormatContext *s, int id);
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 4d53f8f..093fcf9 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4936,7 +4936,7 @@ int ff_generate_avci_extradata(AVStream *st)
 return 0;
 }
 
-uint8_t *av_stream_get_side_data(AVStream *st, enum AVPacketSideDataType type,
+uint8_t *av_stream_get_side_data(const AVStream *st, enum AVPacketSideDataType 
type,
  int *size)
 {
 int i;
-- 
2.9.0

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


[FFmpeg-devel] [PATCH 1/2] lavf/utils: add some const to pointers parameters in a few functions

2016-06-27 Thread Clément Bœsch
From: Clément Bœsch 

---
 libavformat/internal.h | 2 +-
 libavformat/utils.c| 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavformat/internal.h b/libavformat/internal.h
index 647ad65..f66acae 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -552,7 +552,7 @@ enum AVWriteUncodedFrameFlags {
 /**
  * Copies the whilelists from one context to the other
  */
-int ff_copy_whiteblacklists(AVFormatContext *dst, AVFormatContext *src);
+int ff_copy_whiteblacklists(AVFormatContext *dst, const AVFormatContext *src);
 
 int ffio_open2_wrapper(struct AVFormatContext *s, AVIOContext **pb, const char 
*url, int flags,
const AVIOInterruptCB *int_cb, AVDictionary **options);
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 6f343f2..4d53f8f 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -90,7 +90,7 @@ static int is_relative(int64_t ts) {
  * @param timestamp the time stamp to wrap
  * @return resulting time stamp
  */
-static int64_t wrap_timestamp(AVStream *st, int64_t timestamp)
+static int64_t wrap_timestamp(const AVStream *st, int64_t timestamp)
 {
 if (st->pts_wrap_behavior != AV_PTS_WRAP_IGNORE &&
 st->pts_wrap_reference != AV_NOPTS_VALUE && timestamp != 
AV_NOPTS_VALUE) {
@@ -142,7 +142,7 @@ void av_format_inject_global_side_data(AVFormatContext *s)
 }
 }
 
-int ff_copy_whiteblacklists(AVFormatContext *dst, AVFormatContext *src)
+int ff_copy_whiteblacklists(AVFormatContext *dst, const AVFormatContext *src)
 {
 av_assert0(!dst->codec_whitelist &&
!dst->format_whitelist &&
@@ -162,7 +162,7 @@ int ff_copy_whiteblacklists(AVFormatContext *dst, 
AVFormatContext *src)
 return 0;
 }
 
-static const AVCodec *find_decoder(AVFormatContext *s, AVStream *st, enum 
AVCodecID codec_id)
+static const AVCodec *find_decoder(AVFormatContext *s, const AVStream *st, 
enum AVCodecID codec_id)
 {
 #if FF_API_LAVF_AVCTX
 FF_DISABLE_DEPRECATION_WARNINGS
-- 
2.9.0

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


Re: [FFmpeg-devel] [PATCH 01/10] diracdsp: add SIMD for the 10 bit version of put_signed_rect_clamped

2016-06-27 Thread Rostislav Pehlivanov
On 24 June 2016 at 16:21, James Almer  wrote:

> On 6/24/2016 8:44 AM, Rostislav Pehlivanov wrote:
> > From 86ecebfe70509329d6f5b8a587ae79d19f9c8154 Mon Sep 17 00:00:00 2001
> > From: Rostislav Pehlivanov 
> > Date: Thu, 23 Jun 2016 18:06:55 +0100
> > Subject: [PATCH 1/2] diracdsp: add SIMD for the 10 bit version of
> >  put_signed_rect_clamped
> >
> > Signed-off-by: Rostislav Pehlivanov 
> > ---
> >  libavcodec/x86/diracdsp.asm| 45
> ++
> >  libavcodec/x86/diracdsp_init.c | 10 ++
> >  2 files changed, 55 insertions(+)
> >
> > diff --git a/libavcodec/x86/diracdsp.asm b/libavcodec/x86/diracdsp.asm
> > index a042413..a0d6788 100644
> > --- a/libavcodec/x86/diracdsp.asm
> > +++ b/libavcodec/x86/diracdsp.asm
> > @@ -22,6 +22,8 @@
> >
> >  SECTION_RODATA
> >  pw_7: times 8 dw 7
> > +convert_to_unsigned_10bit: times 4 dd 0x200
> > +clip_10bit:times 8 dw 0x3ff
> >
> >  cextern pw_3
> >  cextern pw_16
> > @@ -263,3 +265,46 @@ ADD_RECT sse2
> >  HPEL_FILTER sse2
> >  ADD_OBMC 32, sse2
> >  ADD_OBMC 16, sse2
> > +
> > +%if ARCH_X86_64 == 1
> > +INIT_XMM sse4
> > +
> > +; void put_signed_rect_clamped_10(uint8_t *dst, int dst_stride, const
> uint8_t *src, int src_stride, int width, int height)
> > +cglobal put_signed_rect_clamped_10, 6, 9, 6, dst, dst_stride, src,
> src_stride, w, h
> > +
> > +mov  r6, srcq
> > +mov  r7, dstq
> > +mov  r8, wq
> > +pxor m2, m2
> > +mova m3, [clip_10bit]
> > +mova m4, [convert_to_unsigned_10bit]
> > +
> > +.loop_h:
> > +mov  srcq, r6
> > +mov  dstq, r7
> > +mov  wq,   r8
> > +
> > +.loop_w:
> > +movu m0, [srcq+0*mmsize]
> > +movu m1, [srcq+1*mmsize]
> > +
> > +padddm0, m4
> > +padddm1, m4
> > +packusdw m0, m0, m1
> > +CLIPWm0, m2, m3 ; packusdw saturates so it's fine
> > +
> > +movu [dstq], m0
> > +
> > +add  srcq, 2*mmsize
> > +add  dstq, 1*mmsize
> > +sub  wq, 8
> > +jl   .loop_w
>
> Since you're substracting w now, this should be jump if greater.
>
> Also, use wd, not wq, since it comes from stack on Win64. With msvc
> x86_64 afaik there's no guarantee that the upper half of the register
> is zeroed.
>
> > +
> > +add  r6, src_strideq
> > +add  r7, dst_strideq
> > +sub  hq, 1
> > +jl   .loop_h
>
> Ditto.
>
> Alternatively as i said before is to just change the prototypes to
> use ptrdiff_t instead of int.
>
> > +
> > +RET
> > +
> > +%endif
> > diff --git a/libavcodec/x86/diracdsp_init.c
> b/libavcodec/x86/diracdsp_init.c
> > index 5fae798..7fa554e 100644
> > --- a/libavcodec/x86/diracdsp_init.c
> > +++ b/libavcodec/x86/diracdsp_init.c
> > @@ -46,6 +46,10 @@ void ff_put_rect_clamped_sse2(uint8_t *dst, int
> dst_stride, const int16_t *src,
> >  void ff_put_signed_rect_clamped_mmx(uint8_t *dst, int dst_stride, const
> int16_t *src, int src_stride, int width, int height);
> >  void ff_put_signed_rect_clamped_sse2(uint8_t *dst, int dst_stride,
> const int16_t *src, int src_stride, int width, int height);
> >
> > +#if ARCH_X86_64
> > +void ff_put_signed_rect_clamped_10_sse4(uint8_t *dst, int dst_stride,
> const uint8_t *src, int src_stride, int width, int height);
> > +#endif
> > +
> >  #if HAVE_YASM
> >
> >  #define HPEL_FILTER(MMSIZE, EXT)
>  \
> > @@ -184,4 +188,10 @@ void ff_diracdsp_init_x86(DiracDSPContext* c)
> >  c->put_dirac_pixels_tab[2][0] = ff_put_dirac_pixels32_sse2;
> >  c->avg_dirac_pixels_tab[2][0] = ff_avg_dirac_pixels32_sse2;
> >  }
> > +
> > +#if ARCH_X86_64
> > +if (EXTERNAL_SSE4(mm_flags)) {
> > +c->put_signed_rect_clamped[1] =
> ff_put_signed_rect_clamped_10_sse4;
> > +}
> > +#endif
> >  }
> > --
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


Attached a new patch, should be fine now.
Chose not to change w and h to 64 bits since I'd have to do more changes to
existing code.
From 56623038d6f73afc6c3723b57cde13b9e22a955e Mon Sep 17 00:00:00 2001
From: Rostislav Pehlivanov 
Date: Thu, 23 Jun 2016 18:06:55 +0100
Subject: [PATCH] diracdsp: add SIMD for the 10 bit version of
 put_signed_rect_clamped

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/x86/diracdsp.asm| 45 ++
 libavcodec/x86/diracdsp_init.c | 10 ++
 2 files changed, 55 insertions(+)

diff --git a/libavcodec/x86/diracdsp.asm b/libavcodec/x86/diracdsp.asm
index a042413..c5cc530 100644
--- a/libavcodec/x86/diracdsp.asm
+++ b/libavcodec/x86/diracdsp.asm
@@ -22,6 +22,8 @@
 
 SECTION_RODATA
 pw_7: times 8 dw 7
+convert_to_unsigned_10bit: times 4 dd 0x200
+clip_10bit:times 8 dw 0x3ff
 
 cextern pw_3
 cextern pw_16
@@ -263,3 +265,46 @@ ADD_RECT sse2
 HPEL_FILTER sse2
 ADD_OBMC 32, sse2
 ADD_OBMC 16, sse2
+
+%if ARCH_X86_6

Re: [FFmpeg-devel] [PATCH] avfilter/drawutils: change to support native endian only

2016-06-27 Thread Michael Niedermayer
On Mon, Jun 27, 2016 at 04:46:16PM +0700, Muhammad Faiz wrote:
> previously support little endian only because of fate problem
> generally native endian code is faster
> 
> require 'tests/fate-run: support both le/be formats on pixfmts'
> need someone tests it on BE machine
> 
> Signed-off-by: Muhammad Faiz 
> ---
>  libavfilter/drawutils.c | 43 --
>  libavfilter/vf_lut.c| 81 
> +
>  2 files changed, 62 insertions(+), 62 deletions(-)

breaks fate on big endian (mips)

Test filter-pixfmts-pad failed. Look at tests/data/fate/filter-pixfmts-pad.err 
for details.
make: *** [fate-filter-pixfmts-pad] Error 1
make: *** Waiting for unfinished jobs
--- tests/ref/fate/filter-pixfmts-lut   2016-06-26 18:25:32.960458744 +0200
+++ tests/data/fate/filter-pixfmts-lut  2016-06-27 12:48:19.049852682 +0200
@@ -3,38 +3,38 @@
 bgr24   fa43e3b2abfde8d9e60e157a9acc553d
 bgra4e2e689897ee7a8e42b16234597bab35
 rgb24   a356171207723a580e7d277078072005
-rgb48le 5c7dd8575836d18c91e09f1915cf9aa9
+rgb48be d9a7669cab9159c7f28dc92387fab304
 rgba7bc854c2698b78af3e9159a19c2d9d21
-rgba64le3a087ecab583d1930220592731f282b4
+rgba64be612546f91b274bcc8c314386ba410c3d
 yuv410p 51b39a0e33f108e652457a26667319ea
 yuv411p 9204c5af92aef4922a05f58c1f6c095e
 yuv420p 7c43bb0cae8dee633375c89295598508
-yuv420p10le 1352712dd31cce78bd5441294004cf85
-yuv420p12le c66f82da9fda458ba3abda057c58e591
-yuv420p14le e45cb5e2a75bf6143da0b55004767f78
-yuv420p16le eff54782c51770edfd6b84c958ac7120
-yuv420p9le  4a6776b3379f12ad45caee8072a13695
+yuv420p10be 4ef2f621258d77ef242e37e39b636f7c
+yuv420p12be bfb9f581c3749fd102f5bbd2065ad67a
+yuv420p14be 999d29d713e52f61a5eea1765c57e660
+yuv420p16be a8ff20f5a96ba42fa5968bda64e160bd
+yuv420p9be  862db8509f9cbaa7fd542851047a50fc
 yuv422p 67df35da0c35e54882492b2365438254
-yuv422p10le 0158371a800294015def7f0ef66c78ea
-yuv422p12le bc49d3863ffb89658a17bf8c4fe773b0
-yuv422p14le b55cb791d286b0b3391fe7481785e5b3
-yuv422p16le fc3b2ba889ffaf1633000fc774307c33
-yuv422p9le  6e2a42ae36ed5e8b5112987639728af5
+yuv422p10be 384f3f8757ecdcb87e0f5225f92ee244
+yuv422p12be b6bac207d387098f22b2f3613d668d30
+yuv422p14be 48b83f5ecc7931cbab467801934bbf87
+yuv422p16be be0db4de9820408fd6770cdcea0535f9
+yuv422p9be  f2486947acf0e98977cbec23c79871b3
 yuv440p 5e41adcfc27be4369afd217b61b2ffe3
-yuv440p10le 8b49714bba268fb4a79b5a84223ad17a
-yuv440p12le 15ab4f453238bd9c13b18af81e22f060
+yuv440p10be cbcbbbdbe4a1dc041bee11b757be89d7
+yuv440p12be 7603fda62bd9cb383e7d82af0bf5fefd
 yuv444p a2b58590aef88db2c1f14a1a3a3b0359
-yuv444p10le c076c20fc808f95b34adb88aca442f48
-yuv444p12le af8d4dd88169d5cffc2f3fce6333a94c
-yuv444p14le 93367133e25d088d4535199ed1f1ed58
-yuv444p16le 800940feec14365ccd9b4863e38f6991
-yuv444p9le  c120044350852c4cd16a302dd1ceda79
+yuv444p10be a3481fe5e95190749f2ac3288ad686c3
+yuv444p12be 118c1d1f8270cebec8554972adde05da
+yuv444p14be 6671cff7f64e9f9bc1dceb3d31a69c00
+yuv444p16be 27effaa1096361ffb6b69d1d0e8a35d6
+yuv444p9be  dcd44e88c9424d5666ac950f4e3e19e4
 yuva420p518a380bf1af60ef2ecf4754eec088e9
-yuva420p16le72ad4fa535b007d122666ce103ef9c8b
+yuva420p16beaaa6db0ce07716dab15782dfbad5aca9
 yuva422p7110ac2e37377b05b6fc5ad967dfabb5
-yuva422p16lee2867210660ada5784a60b4339ac52c0
+yuva422p16bef5c06d197a1096314553b1d89f43d96f
 yuva444p642f3958f141dece9e99407945e2ef43
-yuva444p16leab04ba8acbe38085b0df650d82065eb0
+yuva444p16be5337a7c64bd26a675d4a2bb8881e6fcb
 yuvj420p65bc7c7f06a6221155ca7f9cfca4
 yuvj422pff5baffefc8ffe4547653092fd7da200
 yuvj440pef3f27270e60ac06582e3ac7c2f3e6fa


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

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


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


Re: [FFmpeg-devel] [PATCH v3] lavd/decklink_common: Fix error caused by -Werror=missing-prototypes

2016-06-27 Thread Richard Kern

> On Jun 26, 2016, at 11:03 PM, Roger Pack  wrote:
> 
> could you post a copy of the compile failure for reference?

See below - the error is only generated when -I is used.

g++ -I. -Isrc/ -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-I/Users/rick/projects/ffmpeg/compat/dispatch_semaphore -DPIC -DZLIB_CONST 
-I/usr/local/include -std=c99 -fomit-frame-pointer -fPIC -pthread -g 
-Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith 
-Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes 
-Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body -Wno-parentheses 
-Wno-switch -Wno-format-zero-length -Wno-pointer-sign 
-Wno-unused-const-variable -O3 -fno-math-errno -fno-signed-zeros 
-Qunused-arguments -Werror=implicit-function-declaration 
-Werror=missing-prototypes -Werror=return-type  -D__STDC_CONSTANT_MACROS 
-std=c++98  -c -o libavdevice/decklink_common.o 
src/libavdevice/decklink_common.cpp
In file included from src/libavdevice/decklink_common.cpp:26:
/usr/local/include/DeckLinkAPIDispatch.cpp:56:6: error: no previous prototype 
for function 'InitDeckLinkAPI' [-Werror,-Wmissing-prototypes]
voidInitDeckLinkAPI (void)
^
/usr/local/include/DeckLinkAPIDispatch.cpp:77:7: error: no previous prototype 
for function 'IsDeckLinkAPIPresent' [-Werror,-Wmissing-prototypes]
boolIsDeckLinkAPIPresent (void)
^
/usr/local/include/DeckLinkAPIDispatch.cpp:157:6: error: no previous prototype 
for function 'InitBMDStreamingAPI' [-Werror,-Wmissing-prototypes]
void InitBMDStreamingAPI(void)
 ^
3 errors generated.
make: *** [libavdevice/decklink_common.o] Error 1

> 
> On 6/26/16, Rick Kern  wrote:
>> decklink_common.cpp includes a .cpp file from the DeckLink API which fails
>> to build because there are non-static functions in the included .cpp file.
>> This disables the missing-prototypes error so the file can be included.
>> 
>> Signed-off-by: Rick Kern 
>> ---
>> libavdevice/Makefile | 2 ++
>> 1 file changed, 2 insertions(+)
>> 
>> diff --git a/libavdevice/Makefile b/libavdevice/Makefile
>> index 585827b..e281825 100644
>> --- a/libavdevice/Makefile
>> +++ b/libavdevice/Makefile
>> @@ -19,6 +19,8 @@ OBJS-$(CONFIG_BKTR_INDEV)+= bktr.o
>> OBJS-$(CONFIG_CACA_OUTDEV)   += caca.o
>> OBJS-$(CONFIG_DECKLINK_OUTDEV)   += decklink_enc.o decklink_enc_c.o
>> decklink_common.o
>> OBJS-$(CONFIG_DECKLINK_INDEV)+= decklink_dec.o decklink_dec_c.o
>> decklink_common.o
>> +$(SUBDIR)decklink_common.o: CXXFLAGS += -Wno-error=missing-prototypes
>> +
>> OBJS-$(CONFIG_DSHOW_INDEV)   += dshow_crossbar.o dshow.o
>> dshow_enummediatypes.o \
>> dshow_enumpins.o dshow_filter.o
>> \
>> dshow_pin.o dshow_common.o
>> --
>> 2.9.0
>> 
>> ___
>> 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 mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 02/10] diracdsp: add dequantization SIMD

2016-06-27 Thread Rostislav Pehlivanov
On 24 June 2016 at 16:38, James Almer  wrote:

> On 6/24/2016 8:43 AM, Rostislav Pehlivanov wrote:
> > From 154e4312b09f568108dd97089e394c10bb3c28a9 Mon Sep 17 00:00:00 2001
> > From: Rostislav Pehlivanov 
> > Date: Thu, 23 Jun 2016 18:06:56 +0100
> > Subject: [PATCH 2/2] diracdsp: add dequantization SIMD
> >
> > Currently unused, to be used in the following commits.
> >
> > Signed-off-by: Rostislav Pehlivanov 
> > ---
> >  libavcodec/diracdsp.c  | 24 
> >  libavcodec/diracdsp.h  |  4 
> >  libavcodec/x86/diracdsp.asm| 36 
> >  libavcodec/x86/diracdsp_init.c |  2 ++
> >  4 files changed, 66 insertions(+)
> >
> > diff --git a/libavcodec/diracdsp.c b/libavcodec/diracdsp.c
> > index ab8d149..cd1209e 100644
> > --- a/libavcodec/diracdsp.c
> > +++ b/libavcodec/diracdsp.c
> > @@ -189,6 +189,27 @@ static void add_rect_clamped_c(uint8_t *dst, const
> uint16_t *src, int stride,
> >  }
> >  }
> >
> > +#define DEQUANT_SUBBAND(PX)
> \
> > +static void dequant_subband_ ## PX ## _c(uint8_t *src, uint8_t *dst,
> ptrdiff_t stride, \
> > + const int qf, const int qs,
> int tot_v, int tot_h) \
> > +{
> \
> > +int i, y;
> \
> > +for (y = 0; y < tot_v; y++) {
> \
> > +PX c, sign, *src_r = (PX *)src, *dst_r = (PX *)dst;
> \
> > +for (i = 0; i < tot_h; i++) {
> \
> > +c = *src_r++;
> \
> > +sign = FFSIGN(c)*(!!c);
> \
> > +c = (FFABS(c)*qf + qs) >> 2;
>\
> > +*dst_r++ = c*sign;
>\
> > +}
> \
> > +src += tot_h << (sizeof(PX) >> 1);
>\
> > +dst += stride;
>\
> > +}
> \
> > +}
> > +
> > +DEQUANT_SUBBAND(int16_t)
> > +DEQUANT_SUBBAND(int32_t)
> > +
> >  #define PIXFUNC(PFX, WIDTH)
>  \
> >  c->PFX ## _dirac_pixels_tab[WIDTH>>4][0] = ff_ ## PFX ##
> _dirac_pixels ## WIDTH ## _c; \
> >  c->PFX ## _dirac_pixels_tab[WIDTH>>4][1] = ff_ ## PFX ##
> _dirac_pixels ## WIDTH ## _l2_c; \
> > @@ -214,6 +235,9 @@ av_cold void ff_diracdsp_init(DiracDSPContext *c)
> >  c->biweight_dirac_pixels_tab[1] = biweight_dirac_pixels16_c;
> >  c->biweight_dirac_pixels_tab[2] = biweight_dirac_pixels32_c;
> >
> > +c->dequant_subband[0] = c->dequant_subband[2] =
> dequant_subband_int16_t_c;
> > +c->dequant_subband[1] = c->dequant_subband[3] =
> dequant_subband_int32_t_c;
> > +
> >  PIXFUNC(put, 8);
> >  PIXFUNC(put, 16);
> >  PIXFUNC(put, 32);
> > diff --git a/libavcodec/diracdsp.h b/libavcodec/diracdsp.h
> > index 25a872d..224828d 100644
> > --- a/libavcodec/diracdsp.h
> > +++ b/libavcodec/diracdsp.h
> > @@ -22,6 +22,7 @@
> >  #define AVCODEC_DIRACDSP_H
> >
> >  #include 
> > +#include 
> >
> >  typedef void (*dirac_weight_func)(uint8_t *block, int stride, int
> log2_denom, int weight, int h);
> >  typedef void (*dirac_biweight_func)(uint8_t *dst, const uint8_t *src,
> int stride, int log2_denom, int weightd, int weights, int h);
> > @@ -46,6 +47,9 @@ typedef struct {
> >  void (*add_rect_clamped)(uint8_t *dst/*align 16*/, const uint16_t
> *src/*align 16*/, int stride, const int16_t *idwt/*align 16*/, int
> idwt_stride, int width, int height/*mod 2*/);
> >  void (*add_dirac_obmc[3])(uint16_t *dst, const uint8_t *src, int
> stride, const uint8_t *obmc_weight, int yblen);
> >
> > +/* 0-1: int16_t and int32_t asm/c, 2-3: int16 and int32_t, C only */
> > +void (*dequant_subband[4])(uint8_t *src, uint8_t *dst, ptrdiff_t
> stride, const int qf, const int qs, int tot_v, int tot_h);
> > +
> >  dirac_weight_func weight_dirac_pixels_tab[3];
> >  dirac_biweight_func biweight_dirac_pixels_tab[3];
> >  } DiracDSPContext;
> > diff --git a/libavcodec/x86/diracdsp.asm b/libavcodec/x86/diracdsp.asm
> > index a0d6788..a764706 100644
> > --- a/libavcodec/x86/diracdsp.asm
> > +++ b/libavcodec/x86/diracdsp.asm
> > @@ -307,4 +307,40 @@ cglobal put_signed_rect_clamped_10, 6, 9, 6, dst,
> dst_stride, src, src_stride, w
> >
> >  RET
> >
> > +; void dequant_subband_32(uint8_t *src, uint8_t *dst, ptrdiff_t stride,
> const int qf, const int qs, int tot_v, int tot_h)
> > +cglobal dequant_subband_32, 7, 9, 4, src, dst, stride, qf, qs, tot_v,
> tot_h
> > +
> > +movd   m2, qfd
> > +movd   m3, qsd
> > +SPLATD m2
> > +SPLATD m3
> > +movr7, dstq
> > +movr8, tot_hq
>
> Replace every r7 and r8 with r3 and r4, make the cglobal line 7, 7, 4
> and the function will work on x86_32.
>
> > +
> > +.loop_v:
> > +movdstq,   r7
> > +movtot_hq, r8
> > +
> > +.loop_h:
> > +movu   m0, [srcq]
> > +
> > +pabsd  m1, m0
> > +pmulld m1, m2
> > +paddd  m1, m3
> > +psrld  m1

Re: [FFmpeg-devel] [PATCH v3] lavd/decklink_common: Fix error caused by -Werror=missing-prototypes

2016-06-27 Thread Richard Kern

> On Jun 27, 2016, at 4:58 AM, Michael Niedermayer  
> wrote:
> 
> On Sun, Jun 26, 2016 at 08:24:49PM -0400, Rick Kern wrote:
>> decklink_common.cpp includes a .cpp file from the DeckLink API which fails
>> to build because there are non-static functions in the included .cpp file.
>> This disables the missing-prototypes error so the file can be included.
>> 
>> Signed-off-by: Rick Kern 
>> ---
>> libavdevice/Makefile | 2 ++
>> 1 file changed, 2 insertions(+)
>> 
>> diff --git a/libavdevice/Makefile b/libavdevice/Makefile
>> index 585827b..e281825 100644
>> --- a/libavdevice/Makefile
>> +++ b/libavdevice/Makefile
>> @@ -19,6 +19,8 @@ OBJS-$(CONFIG_BKTR_INDEV)+= bktr.o
>> OBJS-$(CONFIG_CACA_OUTDEV)   += caca.o
>> OBJS-$(CONFIG_DECKLINK_OUTDEV)   += decklink_enc.o decklink_enc_c.o 
>> decklink_common.o
>> OBJS-$(CONFIG_DECKLINK_INDEV)+= decklink_dec.o decklink_dec_c.o 
>> decklink_common.o
> 
>> +$(SUBDIR)decklink_common.o: CXXFLAGS += -Wno-error=missing-prototypes
> 
> Is this portable ?
> is there some posix document or similar that says that this
> is supported by all compilers ?

configure adds the -Werror=missing-prototypes only if it’s supported by the 
compiler. Instead, I could add -Wno-error=… to CFLAGS only if it’s supported.

> 
> and in what directory are these system headers that cause the problem?
> is this directory a system header directory ?
> what compiler fails to suppress warnings from system headers ?

They’re not in a system header directory. It fails to build with clang when 
it’s added as a user include directory, but it does build with -isystem. I’ve 
seen this issue floating around the internet, so this would make building the 
decklink code a little easier.

> 
> also:
> http://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-in-system-headers
> 
> [...]
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> The real ebay dictionary, page 1
> "Used only once"- "Some unspecified defect prevented a second use"
> "In good condition" - "Can be repaird by experienced expert"
> "As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
> ___
> 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] release/3.1

2016-06-27 Thread Amancio Hasty
On June 26, 2016 at 5:49:30 PM, Michael Niedermayer (mich...@niedermayer.cc)
wrote:

On Sun, Jun 26, 2016 at 03:36:33AM +0200, Michael Niedermayer wrote:
> Hi all
>
> ive branched release/3.1 off from master
> i will make the 3.1 release from HEAD of this branch tomorrow
> If there are any last minute changes that should go in, thats your
> very last chance to put them in !

3.1 release made

3.1.1 will be made from release/3.1 in 1-2 weeks probably, please
backport all clean bugfixes which affect 3.1

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Cool.

You can close ticket #3518 which states that ffmpeg does not support RPI’s
hardware h264 encoding.

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


Re: [FFmpeg-devel] release/3.1

2016-06-27 Thread Carl Eugen Hoyos
Amancio Hasty  gmail.com> writes:

> You can close ticket #3518 which states that ffmpeg does not 
> support RPI’s hardware h264 encoding.

Which commit fixed #3518?

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


Re: [FFmpeg-devel] [PATCH v3] lavd/decklink_common: Fix error caused by -Werror=missing-prototypes

2016-06-27 Thread Michael Niedermayer
On Mon, Jun 27, 2016 at 07:59:00AM -0400, Richard Kern wrote:
> 
> > On Jun 27, 2016, at 4:58 AM, Michael Niedermayer  
> > wrote:
> > 
> > On Sun, Jun 26, 2016 at 08:24:49PM -0400, Rick Kern wrote:
> >> decklink_common.cpp includes a .cpp file from the DeckLink API which fails
> >> to build because there are non-static functions in the included .cpp file.
> >> This disables the missing-prototypes error so the file can be included.
> >> 
> >> Signed-off-by: Rick Kern 
> >> ---
> >> libavdevice/Makefile | 2 ++
> >> 1 file changed, 2 insertions(+)
> >> 
> >> diff --git a/libavdevice/Makefile b/libavdevice/Makefile
> >> index 585827b..e281825 100644
> >> --- a/libavdevice/Makefile
> >> +++ b/libavdevice/Makefile
> >> @@ -19,6 +19,8 @@ OBJS-$(CONFIG_BKTR_INDEV)+= bktr.o
> >> OBJS-$(CONFIG_CACA_OUTDEV)   += caca.o
> >> OBJS-$(CONFIG_DECKLINK_OUTDEV)   += decklink_enc.o 
> >> decklink_enc_c.o decklink_common.o
> >> OBJS-$(CONFIG_DECKLINK_INDEV)+= decklink_dec.o 
> >> decklink_dec_c.o decklink_common.o
> > 
> >> +$(SUBDIR)decklink_common.o: CXXFLAGS += -Wno-error=missing-prototypes
> > 
> > Is this portable ?
> > is there some posix document or similar that says that this
> > is supported by all compilers ?
> 
> configure adds the -Werror=missing-prototypes only if it’s supported by the 
> compiler. Instead, I could add -Wno-error=… to CFLAGS only if it’s supported.

if you wish to support these files as non system headers and noone
is against it then thats an option


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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


[FFmpeg-devel] [PATCH] H264ParamSets: make sps const

2016-06-27 Thread Benoit Fouet

Hi,

First patch change decode_scaling_matrices function, so that it does not 
affect the SPS structure it gets, and marks SPS and PPS const in its 
arguments.


Second patch straightens the check for macroblock sizes in 
ff_h264_decode_seq_parameter_set and removes the unneeded check in H.264 
slice init_dimensions.


Last patch make SPS const in H264ParamSets and fixes its usages.

Cheers,
--
Ben

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


[FFmpeg-devel] [PATCH 1/3] h264_ps: change decode_scaling_matrices so that it takes

2016-06-27 Thread Benoit Fouet


From c2606da98ecd04762305734f4f45ca8eaf266459 Mon Sep 17 00:00:00 2001
From: Benoit Fouet 
Date: Mon, 27 Jun 2016 12:00:39 +0200
Subject: [PATCH 1/3] h264_ps: change decode_scaling_matrices so that it takes
 const {s,p}ps

In order to be able to make SPS const in H264ParamSets,
modify decode_scaling_matrices so that it returns if the scaling
matrix are present in the SPS, instead of altering the input SPS
structure.
---
 libavcodec/h264_ps.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 943d953..5d4ddea 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -265,8 +265,8 @@ static void decode_scaling_list(GetBitContext *gb, uint8_t 
*factors, int size,
 }
 }
 
-static void decode_scaling_matrices(GetBitContext *gb, SPS *sps,
-PPS *pps, int is_sps,
+static int decode_scaling_matrices(GetBitContext *gb, const SPS *sps,
+const PPS *pps, int is_sps,
 uint8_t(*scaling_matrix4)[16],
 uint8_t(*scaling_matrix8)[64])
 {
@@ -277,8 +277,9 @@ static void decode_scaling_matrices(GetBitContext *gb, SPS 
*sps,
 fallback_sps ? sps->scaling_matrix8[0] : default_scaling8[0],
 fallback_sps ? sps->scaling_matrix8[3] : default_scaling8[1]
 };
+int ret = 0;
 if (get_bits1(gb)) {
-sps->scaling_matrix_present |= is_sps;
+ret = is_sps;
 decode_scaling_list(gb, scaling_matrix4[0], 16, default_scaling4[0], 
fallback[0]);// Intra, Y
 decode_scaling_list(gb, scaling_matrix4[1], 16, default_scaling4[0], 
scaling_matrix4[0]); // Intra, Cr
 decode_scaling_list(gb, scaling_matrix4[2], 16, default_scaling4[0], 
scaling_matrix4[1]); // Intra, Cb
@@ -296,6 +297,8 @@ static void decode_scaling_matrices(GetBitContext *gb, SPS 
*sps,
 }
 }
 }
+
+return ret;
 }
 
 void ff_h264_ps_uninit(H264ParamSets *ps)
@@ -401,7 +404,7 @@ int ff_h264_decode_seq_parameter_set(GetBitContext *gb, 
AVCodecContext *avctx,
 goto fail;
 }
 sps->transform_bypass = get_bits1(gb);
-decode_scaling_matrices(gb, sps, NULL, 1,
+sps->scaling_matrix_present |= decode_scaling_matrices(gb, sps, NULL, 
1,
 sps->scaling_matrix4, sps->scaling_matrix8);
 } else {
 sps->chroma_format_idc = 1;
-- 
2.9.0.37.g6d523a3

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


[FFmpeg-devel] [PATCH 3/3] h264: make H264ParamSets sps const

2016-06-27 Thread Benoit Fouet


From 735362df589eb5f8b05063c56862ff18589475ad Mon Sep 17 00:00:00 2001
From: Benoit Fouet 
Date: Tue, 21 Jun 2016 14:17:13 +0200
Subject: [PATCH 3/3] h264: make H264ParamSets sps const

---
 libavcodec/h264.h| 3 +--
 libavcodec/h264_parser.c | 2 +-
 libavcodec/h264_ps.c | 4 ++--
 libavcodec/h264_sei.c| 4 ++--
 libavcodec/h264_slice.c  | 4 ++--
 5 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index efe3555..ce4f8bf 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -234,8 +234,7 @@ typedef struct H264ParamSets {
 AVBufferRef *sps_ref;
 /* currently active parameters sets */
 const PPS *pps;
-// FIXME this should properly be const
-SPS *sps;
+const SPS *sps;
 } H264ParamSets;
 
 /**
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index ce4bab2..7af2a8d 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -373,7 +373,7 @@ static inline int parse_nal_units(AVCodecParserContext *s,
"non-existing SPS %u referenced\n", p->ps.pps->sps_id);
 goto fail;
 }
-p->ps.sps = (SPS*)p->ps.sps_list[p->ps.pps->sps_id]->data;
+p->ps.sps = (const SPS*)p->ps.sps_list[p->ps.pps->sps_id]->data;
 
 sps = p->ps.sps;
 
diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 0a97649..fdbe548 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -711,7 +711,7 @@ int ff_h264_decode_picture_parameter_set(GetBitContext *gb, 
AVCodecContext *avct
  H264ParamSets *ps, int bit_length)
 {
 AVBufferRef *pps_buf;
-SPS *sps;
+const SPS *sps;
 unsigned int pps_id = get_ue_golomb(gb);
 PPS *pps;
 int qp_bd_offset;
@@ -742,7 +742,7 @@ int ff_h264_decode_picture_parameter_set(GetBitContext *gb, 
AVCodecContext *avct
 ret = AVERROR_INVALIDDATA;
 goto fail;
 }
-sps = (SPS*)ps->sps_list[pps->sps_id]->data;
+sps = (const SPS*)ps->sps_list[pps->sps_id]->data;
 if (sps->bit_depth_luma > 14) {
 av_log(avctx, AV_LOG_ERROR,
"Invalid luma bit depth=%d\n",
diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index 0bbd7e5..3bdbaa0 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -278,7 +278,7 @@ static int decode_buffering_period(H264SEIBufferingPeriod 
*h, GetBitContext *gb,
 {
 unsigned int sps_id;
 int sched_sel_idx;
-SPS *sps;
+const SPS *sps;
 
 sps_id = get_ue_golomb_31(gb);
 if (sps_id > 31 || !ps->sps_list[sps_id]) {
@@ -286,7 +286,7 @@ static int decode_buffering_period(H264SEIBufferingPeriod 
*h, GetBitContext *gb,
"non-existing SPS %d referenced in buffering period\n", sps_id);
 return sps_id > 31 ? AVERROR_INVALIDDATA : AVERROR_PS_NOT_FOUND;
 }
-sps = (SPS*)ps->sps_list[sps_id]->data;
+sps = (const SPS*)ps->sps_list[sps_id]->data;
 
 // NOTE: This is really so duplicated in the standard... See H.264, D.1.1
 if (sps->nal_hrd_parameters_present_flag) {
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index a470da6..afda9cd 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -356,7 +356,7 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
 h->ps.sps_ref = av_buffer_ref(h1->ps.sps_ref);
 if (!h->ps.sps_ref)
 return AVERROR(ENOMEM);
-h->ps.sps = (SPS*)h->ps.sps_ref->data;
+h->ps.sps = (const SPS*)h->ps.sps_ref->data;
 }
 
 if (need_reinit || !inited) {
@@ -873,7 +873,7 @@ static enum AVPixelFormat get_pixel_format(H264Context *h, 
int force_callback)
 /* export coded and cropped frame dimensions to AVCodecContext */
 static int init_dimensions(H264Context *h)
 {
-SPS *sps = h->ps.sps;
+const SPS *sps = (const SPS*)h->ps.sps;
 int width  = h->width  - (sps->crop_right + sps->crop_left);
 int height = h->height - (sps->crop_top   + sps->crop_bottom);
 av_assert0(sps->crop_right + sps->crop_left < (unsigned)h->width);
-- 
2.9.0.37.g6d523a3

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


[FFmpeg-devel] [PATCH 2/3] h264: straighten dimensions check

2016-06-27 Thread Benoit Fouet


From 91b000bf2e0b01695803c5ef98cfb06590f5f409 Mon Sep 17 00:00:00 2001
From: Benoit Fouet 
Date: Mon, 27 Jun 2016 13:31:21 +0200
Subject: [PATCH 2/3] h264: straighten dimensions check
 ff_h264_decode_seq_parameter_set

The MBS only flag was not taken into account when checking macroblock 
dimensions.
Also removes the unneeded check in init_dimensions for slices.
---
 libavcodec/h264_ps.c| 15 ---
 libavcodec/h264_slice.c | 17 -
 2 files changed, 8 insertions(+), 24 deletions(-)

diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 5d4ddea..0a97649 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -463,13 +463,6 @@ int ff_h264_decode_seq_parameter_set(GetBitContext *gb, 
AVCodecContext *avctx,
 sps->gaps_in_frame_num_allowed_flag = get_bits1(gb);
 sps->mb_width   = get_ue_golomb(gb) + 1;
 sps->mb_height  = get_ue_golomb(gb) + 1;
-if ((unsigned)sps->mb_width  >= INT_MAX / 16 ||
-(unsigned)sps->mb_height >= INT_MAX / 16 ||
-av_image_check_size(16 * sps->mb_width,
-16 * sps->mb_height, 0, avctx)) {
-av_log(avctx, AV_LOG_ERROR, "mb_width/height overflow\n");
-goto fail;
-}
 
 sps->frame_mbs_only_flag = get_bits1(gb);
 if (!sps->frame_mbs_only_flag)
@@ -477,6 +470,14 @@ int ff_h264_decode_seq_parameter_set(GetBitContext *gb, 
AVCodecContext *avctx,
 else
 sps->mb_aff = 0;
 
+if ((unsigned)sps->mb_width  >= INT_MAX / 16 ||
+(unsigned)sps->mb_height >= INT_MAX / (16 * (2 - 
sps->frame_mbs_only_flag)) ||
+av_image_check_size(16 * sps->mb_width,
+16 * sps->mb_height * (2 - 
sps->frame_mbs_only_flag), 0, avctx)) {
+av_log(avctx, AV_LOG_ERROR, "mb_width/height overflow\n");
+goto fail;
+}
+
 sps->direct_8x8_inference_flag = get_bits1(gb);
 
 #ifndef ALLOW_INTERLACE
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 474400b..a470da6 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -889,23 +889,6 @@ static int init_dimensions(H264Context *h)
 height = h->avctx->height;
 }
 
-if (width <= 0 || height <= 0) {
-av_log(h->avctx, AV_LOG_ERROR, "Invalid cropped dimensions: %dx%d.\n",
-   width, height);
-if (h->avctx->err_recognition & AV_EF_EXPLODE)
-return AVERROR_INVALIDDATA;
-
-av_log(h->avctx, AV_LOG_WARNING, "Ignoring cropping information.\n");
-sps->crop_bottom =
-sps->crop_top=
-sps->crop_right  =
-sps->crop_left   =
-sps->crop= 0;
-
-width  = h->width;
-height = h->height;
-}
-
 h->avctx->coded_width  = h->width;
 h->avctx->coded_height = h->height;
 h->avctx->width= width;
-- 
2.9.0.37.g6d523a3

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


Re: [FFmpeg-devel] [PATCH] lavc/mediacodec: add hwaccel support

2016-06-27 Thread Matthieu Bouron
On Fri, Jun 24, 2016 at 06:18:02PM +0200, Michael Niedermayer wrote:
> On Fri, Jun 24, 2016 at 11:17:41AM +0200, Matthieu Bouron wrote:
> > On Thu, Apr 07, 2016 at 02:51:44PM +0200, Matthieu Bouron wrote:
> > > On Wed, Mar 23, 2016 at 6:16 PM, Matthieu Bouron 
> > > 
> > > wrote:
> > > 
> > > >
> > > >
> > > > On Tue, Mar 22, 2016 at 10:04 AM, Matthieu Bouron <
> > > > matthieu.bou...@gmail.com> wrote:
> > > >
> > > >>
> > > >>
> > > >> On Fri, Mar 18, 2016 at 5:50 PM, Matthieu Bouron <
> > > >> matthieu.bou...@gmail.com> wrote:
> > > >>
> > > >>> From: Matthieu Bouron 
> > > >>>
> > > >>> ---
> > > >>>
> > > >>> Hello,
> > > >>>
> > > >>> The following patch add hwaccel support to the mediacodec (h264) 
> > > >>> decoder
> > > >>> by allowing
> > > >>> the user to render the output frames directly on a surface.
> > > >>>
> > > >>> In order to do so the user needs to initialize the hwaccel through the
> > > >>> use of
> > > >>> av_mediacodec_alloc_context and av_mediacodec_default_init functions.
> > > >>> The later
> > > >>> takes a reference to an android/view/Surface as parameter.
> > > >>>
> > > >>> If the hwaccel successfully initialize, the decoder output frames pix
> > > >>> fmt will be
> > > >>> AV_PIX_FMT_MEDIACODEC. The following snippet of code demonstrate how 
> > > >>> to
> > > >>> render
> > > >>> the frames on the surface:
> > > >>>
> > > >>> AVMediaCodecBuffer *buffer = (AVMediaCodecBuffer *)frame->data[3];
> > > >>> av_mediacodec_release_buffer(buffer, 1);
> > > >>>
> > > >>> The last argument of av_mediacodec_release_buffer enable rendering of 
> > > >>> the
> > > >>> buffer on the surface (or not if set to 0).
> > > >>>
> > > >>> Regarding the internal changes in the mediacodec decoder:
> > > >>>
> > > >>> MediaCodec.flush() discards both input and output buffers meaning 
> > > >>> that if
> > > >>> MediaCodec.flush() is called all output buffers the user has a 
> > > >>> reference
> > > >>> on are
> > > >>> now invalid (and cannot be used).
> > > >>> This behaviour does not fit well in the avcodec API.
> > > >>>
> > > >>> When the decoder is configured to output software buffers, there is no
> > > >>> issue as
> > > >>> the buffers are copied.
> > > >>>
> > > >>> Now when the decoder is configured to output to a surface, the user
> > > >>> might not
> > > >>> want to render all the frames as fast as the decoder can go and might
> > > >>> want to
> > > >>> control *when* the frame are rendered, so we need to make sure that 
> > > >>> the
> > > >>> MediaCodec.flush() call is delayed until all the frames the user 
> > > >>> retains
> > > >>> has
> > > >>> been released or rendered.
> > > >>>
> > > >>> Delaying the call to MediaCodec.flush() means buffering any inputs 
> > > >>> that
> > > >>> come
> > > >>> the decoder until the user has released/renderer the frame he retains.
> > > >>>
> > > >>> This is a limitation of this hwaccel implementation, if the user 
> > > >>> retains
> > > >>> a
> > > >>> frame (a), then issue a flush command to the decoder, the packets he
> > > >>> feeds to
> > > >>> the decoder at that point will be queued in the internal decoder 
> > > >>> packet
> > > >>> queue
> > > >>> (until he releases the frame (a)). This scenario leads to a memory 
> > > >>> usage
> > > >>> increase to say the least.
> > > >>>
> > > >>> Currently there is no limitation on the size of the internal decoder
> > > >>> packet
> > > >>> queue but this is something that can be added easily. Then, if the 
> > > >>> queue
> > > >>> is
> > > >>> full, what would be the behaviour of the decoder ? Can it block ? Or
> > > >>> should it
> > > >>> returns something like AVERROR(EAGAIN) ?
> > > >>>
> > > >>> About the other internal decoder changes I introduced:
> > > >>>
> > > >>> The MediaCodecDecContext is now refcounted (using the lavu/atomic api)
> > > >>> since
> > > >>> the (hwaccel) frames can be retained by the user, we need to delay the
> > > >>> destruction of the codec until the user has released all the frames he
> > > >>> has a
> > > >>> reference on.
> > > >>> The reference counter of the MediaCodecDecContext is incremented each
> > > >>> time an
> > > >>> (hwaccel) frame is outputted by the decoder and decremented each time 
> > > >>> a
> > > >>> (hwaccel) frame is released.
> > > >>>
> > > >>> Also, when the decoder is configured to output to a surface the pts 
> > > >>> that
> > > >>> are
> > > >>> given to the MediaCodec API are now rescaled based on the 
> > > >>> codec_timebase
> > > >>> as
> > > >>> those timestamps values are propagated to the frames rendered on the
> > > >>> surface
> > > >>> since Android M. Not sure if it's really useful though.
> > > >>>
> > > >>> On the performance side:
> > > >>>
> > > >>> On a nexus 5, decoding an h264 stream (main profile) 1080p@60fps:
> > > >>>   - software output + rgba conversion goes at 59~60fps
> > > >>>   - surface output + render on a surface goes at 100~110fps
> > > >>>
> > > >>>
> > > >> [...]
> > > >>
> > > >> Patch up

Re: [FFmpeg-devel] [PATCH 02/10] diracdsp: add dequantization SIMD

2016-06-27 Thread Michael Niedermayer
On Mon, Jun 27, 2016 at 12:53:47PM +0100, Rostislav Pehlivanov wrote:
> On 24 June 2016 at 16:38, James Almer  wrote:
> 
> > On 6/24/2016 8:43 AM, Rostislav Pehlivanov wrote:
> > > From 154e4312b09f568108dd97089e394c10bb3c28a9 Mon Sep 17 00:00:00 2001
> > > From: Rostislav Pehlivanov 
> > > Date: Thu, 23 Jun 2016 18:06:56 +0100
> > > Subject: [PATCH 2/2] diracdsp: add dequantization SIMD
> > >
> > > Currently unused, to be used in the following commits.
> > >
> > > Signed-off-by: Rostislav Pehlivanov 
> > > ---
> > >  libavcodec/diracdsp.c  | 24 
> > >  libavcodec/diracdsp.h  |  4 
> > >  libavcodec/x86/diracdsp.asm| 36 
> > >  libavcodec/x86/diracdsp_init.c |  2 ++
> > >  4 files changed, 66 insertions(+)
> > >
> > > diff --git a/libavcodec/diracdsp.c b/libavcodec/diracdsp.c
> > > index ab8d149..cd1209e 100644
> > > --- a/libavcodec/diracdsp.c
> > > +++ b/libavcodec/diracdsp.c
> > > @@ -189,6 +189,27 @@ static void add_rect_clamped_c(uint8_t *dst, const
> > uint16_t *src, int stride,
> > >  }
> > >  }
> > >
> > > +#define DEQUANT_SUBBAND(PX)
> > \
> > > +static void dequant_subband_ ## PX ## _c(uint8_t *src, uint8_t *dst,
> > ptrdiff_t stride, \
> > > + const int qf, const int qs,
> > int tot_v, int tot_h) \
> > > +{
> > \
> > > +int i, y;
> > \
> > > +for (y = 0; y < tot_v; y++) {
> > \
> > > +PX c, sign, *src_r = (PX *)src, *dst_r = (PX *)dst;
> > \
> > > +for (i = 0; i < tot_h; i++) {
> > \
> > > +c = *src_r++;
> > \
> > > +sign = FFSIGN(c)*(!!c);
> > \
> > > +c = (FFABS(c)*qf + qs) >> 2;
> >\
> > > +*dst_r++ = c*sign;
> >\
> > > +}
> > \
> > > +src += tot_h << (sizeof(PX) >> 1);
> >\
> > > +dst += stride;
> >\
> > > +}
> > \
> > > +}
> > > +
> > > +DEQUANT_SUBBAND(int16_t)
> > > +DEQUANT_SUBBAND(int32_t)
> > > +
> > >  #define PIXFUNC(PFX, WIDTH)
> >  \
> > >  c->PFX ## _dirac_pixels_tab[WIDTH>>4][0] = ff_ ## PFX ##
> > _dirac_pixels ## WIDTH ## _c; \
> > >  c->PFX ## _dirac_pixels_tab[WIDTH>>4][1] = ff_ ## PFX ##
> > _dirac_pixels ## WIDTH ## _l2_c; \
> > > @@ -214,6 +235,9 @@ av_cold void ff_diracdsp_init(DiracDSPContext *c)
> > >  c->biweight_dirac_pixels_tab[1] = biweight_dirac_pixels16_c;
> > >  c->biweight_dirac_pixels_tab[2] = biweight_dirac_pixels32_c;
> > >
> > > +c->dequant_subband[0] = c->dequant_subband[2] =
> > dequant_subband_int16_t_c;
> > > +c->dequant_subband[1] = c->dequant_subband[3] =
> > dequant_subband_int32_t_c;
> > > +
> > >  PIXFUNC(put, 8);
> > >  PIXFUNC(put, 16);
> > >  PIXFUNC(put, 32);
> > > diff --git a/libavcodec/diracdsp.h b/libavcodec/diracdsp.h
> > > index 25a872d..224828d 100644
> > > --- a/libavcodec/diracdsp.h
> > > +++ b/libavcodec/diracdsp.h
> > > @@ -22,6 +22,7 @@
> > >  #define AVCODEC_DIRACDSP_H
> > >
> > >  #include 
> > > +#include 
> > >
> > >  typedef void (*dirac_weight_func)(uint8_t *block, int stride, int
> > log2_denom, int weight, int h);
> > >  typedef void (*dirac_biweight_func)(uint8_t *dst, const uint8_t *src,
> > int stride, int log2_denom, int weightd, int weights, int h);
> > > @@ -46,6 +47,9 @@ typedef struct {
> > >  void (*add_rect_clamped)(uint8_t *dst/*align 16*/, const uint16_t
> > *src/*align 16*/, int stride, const int16_t *idwt/*align 16*/, int
> > idwt_stride, int width, int height/*mod 2*/);
> > >  void (*add_dirac_obmc[3])(uint16_t *dst, const uint8_t *src, int
> > stride, const uint8_t *obmc_weight, int yblen);
> > >
> > > +/* 0-1: int16_t and int32_t asm/c, 2-3: int16 and int32_t, C only */
> > > +void (*dequant_subband[4])(uint8_t *src, uint8_t *dst, ptrdiff_t
> > stride, const int qf, const int qs, int tot_v, int tot_h);
> > > +
> > >  dirac_weight_func weight_dirac_pixels_tab[3];
> > >  dirac_biweight_func biweight_dirac_pixels_tab[3];
> > >  } DiracDSPContext;
> > > diff --git a/libavcodec/x86/diracdsp.asm b/libavcodec/x86/diracdsp.asm
> > > index a0d6788..a764706 100644
> > > --- a/libavcodec/x86/diracdsp.asm
> > > +++ b/libavcodec/x86/diracdsp.asm
> > > @@ -307,4 +307,40 @@ cglobal put_signed_rect_clamped_10, 6, 9, 6, dst,
> > dst_stride, src, src_stride, w
> > >
> > >  RET
> > >
> > > +; void dequant_subband_32(uint8_t *src, uint8_t *dst, ptrdiff_t stride,
> > const int qf, const int qs, int tot_v, int tot_h)
> > > +cglobal dequant_subband_32, 7, 9, 4, src, dst, stride, qf, qs, tot_v,
> > tot_h
> > > +
> > > +movd   m2, qfd
> > > +movd   m3, qsd
> > > +SPLATD m2
> > > +SPLATD m3
> > > +movr7, dstq
> > > +movr8, tot_hq
> >
> > 

Re: [FFmpeg-devel] ffmpeg_vdpau: Re-add ability to ignore level check

2016-06-27 Thread Mark Thompson
On 26/06/16 23:49, Michael Niedermayer wrote:
> On Tue, Jun 07, 2016 at 07:51:18PM +0100, Mark Thompson wrote:
>> Fixes ticket 5286.
>>
>> Uses the global -hwaccel_lax_profile_check option (may be misnamed
>> for this purpose, but it has the right spirit).
>> ---
>> Only compile tested (no hardware).
>>
>> Maybe -hwaccel_lax_profile_check should be renamed to something a bit more 
>> general - it was named for the specific VAAPI case, but this is really the 
>> same type of issue.  (-hwaccel_ignore_capabilities or something like that?)
>>
>>  ffmpeg_vdpau.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> is anyone against applying this ?

I would prefer the option to have a more sensible name: see 
 and 
followup.

Thanks,

- Mark

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


[FFmpeg-devel] [PATCH] web/index: add 3.1

2016-06-27 Thread Michael Niedermayer
Some entries from the changelog are used
---
 src/index |   27 +++
 1 file changed, 27 insertions(+)

diff --git a/src/index b/src/index
index ff0caf2..79a71e8 100644
--- a/src/index
+++ b/src/index
@@ -37,6 +37,33 @@
 News
   
 
+  June 27th, 2016, FFmpeg 3.1 "Laplace"
+  
+FFmpeg 3.1 "Laplace", a new
+major release, is now available! Some of the highlights:
+  
+  
+DXVA2-accelerated HEVC Main10 decoding
+Many new filters have been added
+MediaCodec H264 decoding
+AudioToolbox audio codec
+VAAPI-accelerated format conversion and scaling
+libnpp/CUDA-accelerated format conversion and scaling
+VAAPI-accelerated H.264/HEVC/MJPEG encoding
+DTS Express (LBR) decoder
+Generic OpenMAX IL encoder with support for Raspberry Pi
+IFF ANIM demuxer & decoder
+Direct Stream Transfer (DST) decoder
+CUDA CUVID H264/HEVC decoder
+10-bit depth support in native utvideo decoder
+YUY2 Lossless Codec decoder
+See the https://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=Changelog;hb=n3.1";>Changelog
 for a list of more updates
+  
+  
+We strongly recommend users, distributors, and system integrators to
+upgrade unless they use current git master.
+  
+
   March 16th, 2016, Google Summer of Code
   
 FFmpeg has been accepted as a https://summerofcode.withgoogle.com/";>Google Summer of Code open 
source organization. If you wish to
-- 
1.7.9.5

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


Re: [FFmpeg-devel] [PATCH] web/index: add 3.1

2016-06-27 Thread Richard Kern

> On Jun 27, 2016, at 10:29 AM, Michael Niedermayer  
> wrote:
> 
> Some entries from the changelog are used
> ---
> src/index |   27 +++
> 1 file changed, 27 insertions(+)
> 
> diff --git a/src/index b/src/index
> index ff0caf2..79a71e8 100644
> --- a/src/index
> +++ b/src/index
> @@ -37,6 +37,33 @@
> News
>   
> 
> +  June 27th, 2016, FFmpeg 3.1 "Laplace"
> +  
> +FFmpeg 3.1 "Laplace", a new
> +major release, is now available! Some of the highlights:
> +  
> +  
> +DXVA2-accelerated HEVC Main10 decoding
> +Many new filters have been added
> +MediaCodec H264 decoding
> +AudioToolbox audio codec
> +VAAPI-accelerated format conversion and scaling
> +libnpp/CUDA-accelerated format conversion and scaling
> +VAAPI-accelerated H.264/HEVC/MJPEG encoding
> +DTS Express (LBR) decoder
> +Generic OpenMAX IL encoder with support for Raspberry Pi
> +IFF ANIM demuxer & decoder
> +Direct Stream Transfer (DST) decoder
> +CUDA CUVID H264/HEVC decoder
> +10-bit depth support in native utvideo decoder
> +YUY2 Lossless Codec decoder
> +See the  href="https://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=Changelog;hb=n3.1";>Changelog
>  for a list of more updates
> +  
> +  
> +We strongly recommend users, distributors, and system integrators to
> +upgrade unless they use current git master.
> +  
> +
>   March 16th, 2016, Google Summer of Code
>   
> FFmpeg has been accepted as a  href="https://summerofcode.withgoogle.com/";>Google Summer of Code open 
> source organization. If you wish to
> -- 
> 1.7.9.5
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Can you add the VideoToolbox H.264 encoder? It wasn’t in the changelog.

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


Re: [FFmpeg-devel] [PATCH] web/index: add 3.1

2016-06-27 Thread Thomas Volkert
On 27.06.2016 16:29, Michael Niedermayer wrote:
> Some entries from the changelog are used
> ---
>  src/index |   27 +++
>  1 file changed, 27 insertions(+)
>
>

Can't we use all changelog entries for version 3.1?

Best regards,
Thomas.

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


Re: [FFmpeg-devel] [PATCH] web/index: add 3.1

2016-06-27 Thread Paul B Mahol
On 6/27/16, Thomas Volkert  wrote:
> On 27.06.2016 16:29, Michael Niedermayer wrote:
>> Some entries from the changelog are used
>> ---
>>  src/index |   27 +++
>>  1 file changed, 27 insertions(+)
>>
>>
>
> Can't we use all changelog entries for version 3.1?

Yes, or we need to censor stuff?

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


Re: [FFmpeg-devel] ffmpeg_vdpau: Re-add ability to ignore level check

2016-06-27 Thread Carl Eugen Hoyos
Michael Niedermayer  niedermayer.cc> writes:

> is anyone against applying this ?

As explained by Philip, this patch is not ok:
We need a patch that changes the default to "no check 
of level".

Carl Eugen

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


Re: [FFmpeg-devel] ffmpeg_vdpau: Re-add ability to ignore level check

2016-06-27 Thread Hendrik Leppkes
On Mon, Jun 27, 2016 at 5:06 PM, Carl Eugen Hoyos  wrote:
> Michael Niedermayer  niedermayer.cc> writes:
>
>> is anyone against applying this ?
>
> As explained by Philip, this patch is not ok:
> We need a patch that changes the default to "no check
> of level".
>

Changing the default is unrelated to offering an option to override,
and another discussion entirely.

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


[FFmpeg-devel] [PATCH] web/index: add 3.1

2016-06-27 Thread Michael Niedermayer
Some entries from the changelog are used
---
 src/index |   56 
 1 file changed, 56 insertions(+)

diff --git a/src/index b/src/index
index ff0caf2..eb66060 100644
--- a/src/index
+++ b/src/index
@@ -37,6 +37,62 @@
 News
   
 
+  June 27th, 2016, FFmpeg 3.1 "Laplace"
+  
+FFmpeg 3.1 "Laplace", a new
+major release, is now available! Some of the highlights:
+  
+  
+DXVA2-accelerated HEVC Main10 decoding
+fieldhint filter
+loop video filter and aloop audio filter
+Bob Weaver deinterlacing filter
+firequalizer filter
+datascope filter
+bench and abench filters
+ciescope filter
+protocol blacklisting API
+MediaCodec H264 decoding
+VC-2 HQ RTP payload format (draft v1) depacketizer and packetizer
+VP9 RTP payload format (draft v2) packetizer
+AudioToolbox audio decoders
+AudioToolbox audio encoders
+coreimage filter (GPU based image filtering on OSX)
+libdcadec removed
+bitstream filter for extracting DTS core
+ADPCM IMA DAT4 decoder
+musx demuxer
+aix demuxer
+remap filter
+hash and framehash muxers
+colorspace filter
+hdcd filter
+readvitc filter
+VAAPI-accelerated format conversion and scaling
+libnpp/CUDA-accelerated format conversion and scaling
+Duck TrueMotion 2.0 Real Time decoder
+Wideband Single-bit Data (WSD) demuxer
+VAAPI-accelerated H.264/HEVC/MJPEG encoding
+DTS Express (LBR) decoder
+Generic OpenMAX IL encoder with support for Raspberry Pi
+IFF ANIM demuxer & decoder
+Direct Stream Transfer (DST) decoder
+loudnorm filter
+MTAF demuxer and decoder
+MagicYUV decoder
+OpenExr improvements (tile data and B44/B44A support)
+BitJazz SheerVideo decoder
+CUDA CUVID H264/HEVC decoder
+10-bit depth support in native utvideo decoder
+libutvideo wrapper removed
+YUY2 Lossless Codec decoder
+VideoToolbox H.264 encoder
+  
+  
+We strongly recommend users, distributors, and system integrators to
+upgrade unless they use current git master.
+  
+
   March 16th, 2016, Google Summer of Code
   
 FFmpeg has been accepted as a https://summerofcode.withgoogle.com/";>Google Summer of Code open 
source organization. If you wish to
-- 
1.7.9.5

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


[FFmpeg-devel] [PATCH] Changed metadata print option to accept general urls

2016-06-27 Thread sami . hult
From: Sami Hult 

---
 Changelog|  1 +
 doc/filters.texi | 23 +--
 libavfilter/f_metadata.c | 48 
 3 files changed, 46 insertions(+), 26 deletions(-)

diff --git a/Changelog b/Changelog
index 4a85925..8541091 100644
--- a/Changelog
+++ b/Changelog
@@ -48,6 +48,7 @@ version 3.1:
 - 10-bit depth support in native utvideo decoder
 - libutvideo wrapper removed
 - YUY2 Lossless Codec decoder
+- Changed metadata print option to accept general urls
 
 
 version 3.0:
diff --git a/doc/filters.texi b/doc/filters.texi
index 3cf3d7c..dba3a5c 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -9375,13 +9375,14 @@ Float representation of @code{value} from metadata key.
 
 @item VALUE2
 Float representation of @code{value} as supplied by user in @code{value} 
option.
-@end table
 
 @item file
-If specified in @code{print} mode, output is written to the named file. When
-filename equals "-" data is written to standard output.
-If @code{file} option is not set, output is written to the log with AV_LOG_INFO
-loglevel.
+If specified in @code{print} mode, output is written to the named file. 
Instead of
+plain filename any writable url can be specified. Filename ``-'' is a shorthand
+for standard output. If @code{file} option is not set, output is written to 
the log
+with AV_LOG_INFO loglevel.
+@end table
+
 @end table
 
 @subsection Examples
@@ -9391,8 +9392,18 @@ loglevel.
 Print all metadata values for frames with key @code{lavfi.singnalstats.YDIF} 
with values
 between 0 and 1.
 @example
-@end example
 
signalstats,metadata=print:key=lavfi.signalstats.YDIF:value=0:function=expr:expr='between(VALUE1,0,1)'
+@end example
+@item
+Print silencedetect output to file @file{metadata.txt}.
+@example
+silencedetect,ametadata=mode=print:file=metadata.txt
+@end example
+@item
+Direct all metadata to a pipe with file descriptor 4.
+@example
+metadata=mode=print:file='pipe\:4'
+@end example
 @end itemize
 
 @section mpdecimate
diff --git a/libavfilter/f_metadata.c b/libavfilter/f_metadata.c
index ab07ccf..97064ea 100644
--- a/libavfilter/f_metadata.c
+++ b/libavfilter/f_metadata.c
@@ -31,6 +31,7 @@
 #include "libavutil/internal.h"
 #include "libavutil/opt.h"
 #include "libavutil/timestamp.h"
+#include "libavformat/avio.h"
 #include "avfilter.h"
 #include "audio.h"
 #include "formats.h"
@@ -80,7 +81,7 @@ typedef struct MetadataContext {
 AVExpr *expr;
 double var_values[VAR_VARS_NB];
 
-FILE *file;
+AVIOContext* avio_context;
 char *file_str;
 
 int (*compare)(struct MetadataContext *s,
@@ -180,8 +181,11 @@ static void print_file(AVFilterContext *ctx, const char 
*msg, ...)
 va_list argument_list;
 
 va_start(argument_list, msg);
-if (msg)
-vfprintf(s->file, msg, argument_list);
+if (msg) {
+char buf[128];
+vsnprintf(buf, sizeof(buf), msg, argument_list);
+avio_put_str(s->avio_context, buf);
+}
 va_end(argument_list);
 }
 
@@ -236,25 +240,29 @@ static av_cold int init(AVFilterContext *ctx)
 }
 }
 
-if (s->file_str) {
-if (!strcmp(s->file_str, "-")) {
-s->file = stdout;
-} else {
-s->file = fopen(s->file_str, "w");
-if (!s->file) {
-int err = AVERROR(errno);
-char buf[128];
-av_strerror(err, buf, sizeof(buf));
-av_log(ctx, AV_LOG_ERROR, "Could not open file %s: %s\n",
-   s->file_str, buf);
-return err;
-}
-}
+if (s->mode == METADATA_PRINT && s->file_str) {
 s->print = print_file;
 } else {
 s->print = print_log;
 }
 
+s->avio_context = NULL;
+if (s->file_str) {
+if (!strcmp("-", s->file_str)) {
+ret = avio_open(&s->avio_context, "pipe:2", AVIO_FLAG_WRITE);
+} else {
+ret = avio_open(&s->avio_context, s->file_str, AVIO_FLAG_WRITE);
+}
+
+if (ret < 0) {
+char buf[128];
+av_strerror(ret, buf, sizeof(buf));
+av_log(ctx, AV_LOG_ERROR, "Could not open %s: %s\n",
+   s->file_str, buf);
+return ret;
+}
+}
+
 return 0;
 }
 
@@ -262,9 +270,9 @@ static av_cold void uninit(AVFilterContext *ctx)
 {
 MetadataContext *s = ctx->priv;
 
-if (s->file && s->file != stdout)
-fclose(s->file);
-s->file = NULL;
+if (s->avio_context) {
+avio_closep(&s->avio_context);
+}
 }
 
 static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
-- 
2.1.4

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


Re: [FFmpeg-devel] ffmpeg_vdpau: Re-add ability to ignore level check

2016-06-27 Thread Carl Eugen Hoyos
Hendrik Leppkes  gmail.com> writes:

> > We need a patch that changes the default to "no check
> > of level".
> 
> Changing the default is unrelated to offering an option 
> to override, and another discussion entirely.

It may be another discussion, it certainly is the most 
relevant discussion of all related to this subject.

Please remember that users reported the same issue 
years ago immediately after the initial VDPAU patches:
It is known since a long time that the discussed check 
is very inconvenient for users.

Carl Eugen



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


Re: [FFmpeg-devel] [PATCH] web/index: add 3.1

2016-06-27 Thread Thomas Volkert
On 27.06.2016 17:17, Michael Niedermayer wrote:
> Some entries from the changelog are used
> ---
>  src/index |   56 
>  1 file changed, 56 insertions(+)
>
> diff --git a/src/index b/src/index
> index ff0caf2..eb66060 100644
> --- a/src/index
> +++ b/src/index
> @@ -37,6 +37,62 @@
>  News
>
>  
> +  June 27th, 2016, FFmpeg 3.1 "Laplace"
> +  
> +FFmpeg 3.1 "Laplace", a new
> +major release, is now available! Some of the highlights:
> +  
> +  
> +DXVA2-accelerated HEVC Main10 decoding
> +fieldhint filter
> +loop video filter and aloop audio filter
> +Bob Weaver deinterlacing filter
> +firequalizer filter
> +datascope filter
> +bench and abench filters
> +ciescope filter
> +protocol blacklisting API
> +MediaCodec H264 decoding
> +VC-2 HQ RTP payload format (draft v1) depacketizer and 
> packetizer
> +VP9 RTP payload format (draft v2) packetizer
> +AudioToolbox audio decoders
> +AudioToolbox audio encoders
> +coreimage filter (GPU based image filtering on OSX)
> +libdcadec removed
> +bitstream filter for extracting DTS core
> +ADPCM IMA DAT4 decoder
> +musx demuxer
> +aix demuxer
> +remap filter
> +hash and framehash muxers
> +colorspace filter
> +hdcd filter
> +readvitc filter
> +VAAPI-accelerated format conversion and scaling
> +libnpp/CUDA-accelerated format conversion and scaling
> +Duck TrueMotion 2.0 Real Time decoder
> +Wideband Single-bit Data (WSD) demuxer
> +VAAPI-accelerated H.264/HEVC/MJPEG encoding
> +DTS Express (LBR) decoder
> +Generic OpenMAX IL encoder with support for Raspberry Pi
> +IFF ANIM demuxer & decoder
> +Direct Stream Transfer (DST) decoder
> +loudnorm filter
> +MTAF demuxer and decoder
> +MagicYUV decoder
> +OpenExr improvements (tile data and B44/B44A support)
> +BitJazz SheerVideo decoder
> +CUDA CUVID H264/HEVC decoder
> +10-bit depth support in native utvideo decoder
> +libutvideo wrapper removed
> +YUY2 Lossless Codec decoder
> +VideoToolbox H.264 encoder
> +  
> +  
> +We strongly recommend users, distributors, and system integrators to
> +upgrade unless they use current git master.
> +  
> +
>March 16th, 2016, Google Summer of Code
>
>  FFmpeg has been accepted as a  href="https://summerofcode.withgoogle.com/";>Google Summer of Code open 
> source organization. If you wish to

LGTM

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


[FFmpeg-devel] [PATCH] web/download: Make the 3.1 changelog link point to its changelog instead of the messy git history

2016-06-27 Thread Michael Niedermayer
Signed-off-by: Michael Niedermayer 
---
 src/download |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/download b/src/download
index ceeb2f9..acee9d7 100644
--- a/src/download
+++ b/src/download
@@ -303,7 +303,7 @@ libpostproc54.  0.100
   PGP signature
  
 
-  https://git.ffmpeg.org/gitweb/ffmpeg.git/shortlog/n3.1";>Changelog
+  https://git.ffmpeg.org/gitweb/ffmpeg.git/blob_plain/n3.1:/Changelog";>Changelog
   https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/release/3.1:/RELEASE_NOTES";>Release
 Notes
  

-- 
1.7.9.5

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


Re: [FFmpeg-devel] [PATCH] web/index: add 3.1

2016-06-27 Thread Michael Niedermayer
On Mon, Jun 27, 2016 at 10:55:08AM -0400, Richard Kern wrote:
> 
> > On Jun 27, 2016, at 10:29 AM, Michael Niedermayer  
> > wrote:
> > 
> > Some entries from the changelog are used
> > ---
> > src/index |   27 +++
> > 1 file changed, 27 insertions(+)
> > 
> > diff --git a/src/index b/src/index
> > index ff0caf2..79a71e8 100644
> > --- a/src/index
> > +++ b/src/index
> > @@ -37,6 +37,33 @@
> > News
> >   
> > 
> > +  June 27th, 2016, FFmpeg 3.1 "Laplace"
> > +  
> > +FFmpeg 3.1 "Laplace", a new
> > +major release, is now available! Some of the highlights:
> > +  
> > +  
> > +DXVA2-accelerated HEVC Main10 decoding
> > +Many new filters have been added
> > +MediaCodec H264 decoding
> > +AudioToolbox audio codec
> > +VAAPI-accelerated format conversion and scaling
> > +libnpp/CUDA-accelerated format conversion and scaling
> > +VAAPI-accelerated H.264/HEVC/MJPEG encoding
> > +DTS Express (LBR) decoder
> > +Generic OpenMAX IL encoder with support for Raspberry Pi
> > +IFF ANIM demuxer & decoder
> > +Direct Stream Transfer (DST) decoder
> > +CUDA CUVID H264/HEVC decoder
> > +10-bit depth support in native utvideo decoder
> > +YUY2 Lossless Codec decoder
> > +See the  > href="https://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=Changelog;hb=n3.1";>Changelog
> >  for a list of more updates
> > +  
> > +  
> > +We strongly recommend users, distributors, and system integrators to
> > +upgrade unless they use current git master.
> > +  
> > +
> >   March 16th, 2016, Google Summer of Code
> >   
> > FFmpeg has been accepted as a  > href="https://summerofcode.withgoogle.com/";>Google Summer of Code open 
> > source organization. If you wish to
> > -- 
> > 1.7.9.5
> > 
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> Can you add the VideoToolbox H.264 encoder? It wasn’t in the changelog.

Please add it to the changelog to all affected branches

ill send a new patch for index

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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


Re: [FFmpeg-devel] [PATCH] web/index: add 3.1

2016-06-27 Thread Richard Kern

> On Jun 27, 2016, at 11:18 AM, Michael Niedermayer  
> wrote:
> 
> On Mon, Jun 27, 2016 at 10:55:08AM -0400, Richard Kern wrote:
>> 
>>> On Jun 27, 2016, at 10:29 AM, Michael Niedermayer  
>>> wrote:
>>> 
>>> Some entries from the changelog are used
>>> ---
>>> src/index |   27 +++
>>> 1 file changed, 27 insertions(+)
>>> 
>>> diff --git a/src/index b/src/index
>>> index ff0caf2..79a71e8 100644
>>> --- a/src/index
>>> +++ b/src/index
>>> @@ -37,6 +37,33 @@
>>>News
>>>  
>>> 
>>> +  June 27th, 2016, FFmpeg 3.1 "Laplace"
>>> +  
>>> +FFmpeg 3.1 "Laplace", a new
>>> +major release, is now available! Some of the highlights:
>>> +  
>>> +  
>>> +DXVA2-accelerated HEVC Main10 decoding
>>> +Many new filters have been added
>>> +MediaCodec H264 decoding
>>> +AudioToolbox audio codec
>>> +VAAPI-accelerated format conversion and scaling
>>> +libnpp/CUDA-accelerated format conversion and scaling
>>> +VAAPI-accelerated H.264/HEVC/MJPEG encoding
>>> +DTS Express (LBR) decoder
>>> +Generic OpenMAX IL encoder with support for Raspberry Pi
>>> +IFF ANIM demuxer & decoder
>>> +Direct Stream Transfer (DST) decoder
>>> +CUDA CUVID H264/HEVC decoder
>>> +10-bit depth support in native utvideo decoder
>>> +YUY2 Lossless Codec decoder
>>> +See the >> href="https://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=Changelog;hb=n3.1";>Changelog
>>>  for a list of more updates
>>> +  
>>> +  
>>> +We strongly recommend users, distributors, and system integrators to
>>> +upgrade unless they use current git master.
>>> +  
>>> +
>>>  March 16th, 2016, Google Summer of Code
>>>  
>>>FFmpeg has been accepted as a >> href="https://summerofcode.withgoogle.com/";>Google Summer of Code open 
>>> source organization. If you wish to
>>> -- 
>>> 1.7.9.5
>>> 
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> Can you add the VideoToolbox H.264 encoder? It wasn’t in the changelog.
> 
> Please add it to the changelog to all affected branches
> 
> ill send a new patch for index

Changelog is updated in master and release/3.1.

> 
> thx
> 
> [...]
> 
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Many that live deserve death. And some that die deserve life. Can you give
> it to them? Then do not be too eager to deal out death in judgement. For
> even the very wise cannot see all ends. -- Gandalf
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] ffmpeg_vdpau: Re-add ability to ignore level check

2016-06-27 Thread Michael Niedermayer
On Mon, Jun 27, 2016 at 02:28:16PM +0100, Mark Thompson wrote:
> On 26/06/16 23:49, Michael Niedermayer wrote:
> > On Tue, Jun 07, 2016 at 07:51:18PM +0100, Mark Thompson wrote:
> >> Fixes ticket 5286.
> >>
> >> Uses the global -hwaccel_lax_profile_check option (may be misnamed
> >> for this purpose, but it has the right spirit).
> >> ---
> >> Only compile tested (no hardware).
> >>
> >> Maybe -hwaccel_lax_profile_check should be renamed to something a bit more 
> >> general - it was named for the specific VAAPI case, but this is really the 
> >> same type of issue.  (-hwaccel_ignore_capabilities or something like that?)
> >>
> >>  ffmpeg_vdpau.c | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > is anyone against applying this ?
> 
> I would prefer the option to have a more sensible name: see 
>  and 
> followup.

Feel free to name it any way the you and the community likes
The patch in question only fixed the code though IIRC and didnt do
anything to the name.
It also may make sense to continue support the old name to not break
the command line interface between 3.1->3.2

Either way, this isnt code i maintain i just wanted to raise awareness
of this issue as the patch wasnt applied and it isnt/wasnt clear to me
why you didt apply it ...

[...]

-- 
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] release/3.1

2016-06-27 Thread Amancio Hasty
This is the commit that introduced the functionality:
f1cd9b03f3fa875eb5e394281b4b688cec611658

Amancio





On June 27, 2016 at 5:35:33 AM, Carl Eugen Hoyos (ceho...@ag.or.at) wrote:

Amancio Hasty  gmail.com> writes:

> You can close ticket #3518 which states that ffmpeg does not
> support RPI’s hardware h264 encoding.

Which commit fixed #3518?

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


Re: [FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port

2016-06-27 Thread Kyle Swanson
On Sun, Jun 19, 2016 at 2:17 AM, Kyle Swanson  wrote:
> Hi,
>
> af_loudnorm currently links libebur128. The port makes sense because
> libebur128 is tiny, MIT-licensed, has a good API, and would be useful
> in several filters. Perceptual loudness has become an important topic
> in broadcasting and audio in general, and it'd be nice to provide
> these filters to everybody without having to link an external library.
>
> FFmpeg already has some ebur128 logic in f_ebur128, which I was
> initially interested in breaking out into something reusable, but
> found libebur128 was better suited for this. This was discussed last
> month when the loudnorm filter was pushed, and also with the
> expectation that libebur128 would be ported to FFmpeg. Briefly,
> libebur128 allows several modes of measurement, custom channel
> mappings, doesn't require resampling the input stream, is faster, and
> has a reusable API.
>
> Thanks,
> Kyle
>

Hi,

I'm still not clear if I should pursue this or not, I've received
`yes` and `no` from both sides on this issue.

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


Re: [FFmpeg-devel] [PATCH] web/index: add 3.1

2016-06-27 Thread Michael Niedermayer
On Mon, Jun 27, 2016 at 05:30:28PM +0200, Thomas Volkert wrote:
> On 27.06.2016 17:17, Michael Niedermayer wrote:
> > Some entries from the changelog are used
> > ---
> >  src/index |   56 
> >  1 file changed, 56 insertions(+)
> >
> > diff --git a/src/index b/src/index
> > index ff0caf2..eb66060 100644
> > --- a/src/index
> > +++ b/src/index
> > @@ -37,6 +37,62 @@
> >  News
> >
> >  
> > +  June 27th, 2016, FFmpeg 3.1 "Laplace"
> > +  
> > +FFmpeg 3.1 "Laplace", a new
> > +major release, is now available! Some of the highlights:
> > +  
> > +  
> > +DXVA2-accelerated HEVC Main10 decoding
> > +fieldhint filter
> > +loop video filter and aloop audio filter
> > +Bob Weaver deinterlacing filter
> > +firequalizer filter
> > +datascope filter
> > +bench and abench filters
> > +ciescope filter
> > +protocol blacklisting API
> > +MediaCodec H264 decoding
> > +VC-2 HQ RTP payload format (draft v1) depacketizer and 
> > packetizer
> > +VP9 RTP payload format (draft v2) packetizer
> > +AudioToolbox audio decoders
> > +AudioToolbox audio encoders
> > +coreimage filter (GPU based image filtering on OSX)
> > +libdcadec removed
> > +bitstream filter for extracting DTS core
> > +ADPCM IMA DAT4 decoder
> > +musx demuxer
> > +aix demuxer
> > +remap filter
> > +hash and framehash muxers
> > +colorspace filter
> > +hdcd filter
> > +readvitc filter
> > +VAAPI-accelerated format conversion and scaling
> > +libnpp/CUDA-accelerated format conversion and scaling
> > +Duck TrueMotion 2.0 Real Time decoder
> > +Wideband Single-bit Data (WSD) demuxer
> > +VAAPI-accelerated H.264/HEVC/MJPEG encoding
> > +DTS Express (LBR) decoder
> > +Generic OpenMAX IL encoder with support for Raspberry Pi
> > +IFF ANIM demuxer & decoder
> > +Direct Stream Transfer (DST) decoder
> > +loudnorm filter
> > +MTAF demuxer and decoder
> > +MagicYUV decoder
> > +OpenExr improvements (tile data and B44/B44A support)
> > +BitJazz SheerVideo decoder
> > +CUDA CUVID H264/HEVC decoder
> > +10-bit depth support in native utvideo decoder
> > +libutvideo wrapper removed
> > +YUY2 Lossless Codec decoder
> > +VideoToolbox H.264 encoder
> > +  
> > +  
> > +We strongly recommend users, distributors, and system integrators to
> > +upgrade unless they use current git master.
> > +  
> > +
> >March 16th, 2016, Google Summer of Code
> >
> >  FFmpeg has been accepted as a  > href="https://summerofcode.withgoogle.com/";>Google Summer of Code open 
> > source organization. If you wish to
> 
> LGTM

applied

thanks

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

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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


Re: [FFmpeg-devel] [PATCH 1/3] h264_ps: change decode_scaling_matrices so that it takes

2016-06-27 Thread Michael Niedermayer
On Mon, Jun 27, 2016 at 02:38:50PM +0200, Benoit Fouet wrote:
> 

>  h264_ps.c |   11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> ea8cc471972e1dbaa4f4f03cd7a5fe92a3b848e9  
> 0001-h264_ps-change-decode_scaling_matrices-so-that-it-ta.patch
> From c2606da98ecd04762305734f4f45ca8eaf266459 Mon Sep 17 00:00:00 2001
> From: Benoit Fouet 
> Date: Mon, 27 Jun 2016 12:00:39 +0200
> Subject: [PATCH 1/3] h264_ps: change decode_scaling_matrices so that it takes
>  const {s,p}ps
> 
> In order to be able to make SPS const in H264ParamSets,
> modify decode_scaling_matrices so that it returns if the scaling
> matrix are present in the SPS, instead of altering the input SPS
> structure.
> ---
>  libavcodec/h264_ps.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)

please document the return value
LGTM otherwise

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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/3] h264: straighten dimensions check

2016-06-27 Thread Michael Niedermayer
On Mon, Jun 27, 2016 at 02:39:19PM +0200, Benoit Fouet wrote:
> 

>  h264_ps.c|   15 ---
>  h264_slice.c |   17 -
>  2 files changed, 8 insertions(+), 24 deletions(-)
> ff2e6c8dccd5e2010a952cade23f24c9fb832b30  
> 0002-h264-straighten-dimensions-check-ff_h264_decode_seq_.patch
> From 91b000bf2e0b01695803c5ef98cfb06590f5f409 Mon Sep 17 00:00:00 2001
> From: Benoit Fouet 
> Date: Mon, 27 Jun 2016 13:31:21 +0200
> Subject: [PATCH 2/3] h264: straighten dimensions check
>  ff_h264_decode_seq_parameter_set
> 
> The MBS only flag was not taken into account when checking macroblock 
> dimensions.
> Also removes the unneeded check in init_dimensions for slices.

should be ok

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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


Re: [FFmpeg-devel] [PATCH 3/3] h264: make H264ParamSets sps const

2016-06-27 Thread Michael Niedermayer
On Mon, Jun 27, 2016 at 02:39:44PM +0200, Benoit Fouet wrote:
> 

>  h264.h|3 +--
>  h264_parser.c |2 +-
>  h264_ps.c |4 ++--
>  h264_sei.c|4 ++--
>  h264_slice.c  |4 ++--
>  5 files changed, 8 insertions(+), 9 deletions(-)
> de8d165e9e3754aa691ebf00d5e4d91e9357442f  
> 0003-h264-make-H264ParamSets-sps-const.patch
> From 735362df589eb5f8b05063c56862ff18589475ad Mon Sep 17 00:00:00 2001
> From: Benoit Fouet 
> Date: Tue, 21 Jun 2016 14:17:13 +0200
> Subject: [PATCH 3/3] h264: make H264ParamSets sps const

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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


[FFmpeg-devel] [PATCH] Change the decklink_dec file header to reflect that this module is used for input from decklink and not output

2016-06-27 Thread Felt, Patrick
---
libavdevice/decklink_dec.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index fcb024e..7412727 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -1,5 +1,5 @@
/*
- * Blackmagic DeckLink output
+ * Blackmagic DeckLink input
  * Copyright (c) 2013-2014 Luca Barbato, Deti Fliegl
  *
  * This file is part of FFmpeg.
--
1.8.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] configure: remove -std= from c++ compilation

2016-06-27 Thread Michael Niedermayer
On Sun, Jun 26, 2016 at 07:08:06PM -0400, Rick Kern wrote:
> Pulling -std=c99 into CXXFLAGS from CFLAGS causes a compile error with c++
> files using clang on OS X.
> Adding -std=c++98 unconditionally to CXXFLAGS will generate a compile error
> on compilers that don't support the -std option.
> It works but is less readable if -std=c++98 is appended after -std=c99 when
> the -std option is supported.
> 
> Signed-off-by: Rick Kern 
> ---
>  common.mak | 2 +-
>  configure  | 1 -
>  2 files changed, 1 insertion(+), 2 deletions(-)

LGTM

thx

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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


Re: [FFmpeg-devel] [PATCH 01/10] diracdsp: add SIMD for the 10 bit version of put_signed_rect_clamped

2016-06-27 Thread James Almer
On 6/27/2016 7:27 AM, Rostislav Pehlivanov wrote:
> diff --git a/libavcodec/x86/diracdsp_init.c b/libavcodec/x86/diracdsp_init.c
> index 5fae798..7fa554e 100644
> --- a/libavcodec/x86/diracdsp_init.c
> +++ b/libavcodec/x86/diracdsp_init.c
> @@ -46,6 +46,10 @@ void ff_put_rect_clamped_sse2(uint8_t *dst, int 
> dst_stride, const int16_t *src,
>  void ff_put_signed_rect_clamped_mmx(uint8_t *dst, int dst_stride, const 
> int16_t *src, int src_stride, int width, int height);
>  void ff_put_signed_rect_clamped_sse2(uint8_t *dst, int dst_stride, const 
> int16_t *src, int src_stride, int width, int height);
>  
> +#if ARCH_X86_64
> +void ff_put_signed_rect_clamped_10_sse4(uint8_t *dst, int dst_stride, const 
> uint8_t *src, int src_stride, int width, int height);
> +#endif

Nit: No need to wrap the prototype with a preprocessor check.

> +
>  #if HAVE_YASM
>  
>  #define HPEL_FILTER(MMSIZE, EXT) 
> \
> @@ -184,4 +188,10 @@ void ff_diracdsp_init_x86(DiracDSPContext* c)
>  c->put_dirac_pixels_tab[2][0] = ff_put_dirac_pixels32_sse2;
>  c->avg_dirac_pixels_tab[2][0] = ff_avg_dirac_pixels32_sse2;
>  }
> +
> +#if ARCH_X86_64
> +if (EXTERNAL_SSE4(mm_flags)) {
> +c->put_signed_rect_clamped[1] = ff_put_signed_rect_clamped_10_sse4;
> +}
> +#endif
>  }
> -- 2.8.1.369.geae769a

FATE seems to pass now. Feel free to push with or without the above nit
since it's something that will be gone once the function is changed to
work on x86_32 anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] tests/checkasm/pixblockdsp: Test only aligned by 8 diff/get pixels

2016-06-27 Thread Michael Niedermayer
On Sun, Jun 26, 2016 at 01:59:05PM +0200, Hendrik Leppkes wrote:
> On Sun, Jun 26, 2016 at 11:16 AM, Michael Niedermayer
>  wrote:
> > They are documented as requiring 8 byte aligned source
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  tests/checkasm/pixblockdsp.c |4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/tests/checkasm/pixblockdsp.c b/tests/checkasm/pixblockdsp.c
> > index 66bfdb7..28ee500 100644
> > --- a/tests/checkasm/pixblockdsp.c
> > +++ b/tests/checkasm/pixblockdsp.c
> > @@ -49,7 +49,7 @@
> >  int i; 
> > \
> >  declare_func_emms(AV_CPU_FLAG_MMX, void, int16_t *block, const 
> > uint8_t *pixels, ptrdiff_t line_size);\
> > 
> > \
> > -for (i = 0; i < BUF_UNITS; i++) {  
> > \
> > +for (i = 0; i < BUF_UNITS; i+=8) { 
> >  \
> >  int src_offset = i * 64 * sizeof(type) + i; /* Test various 
> > alignments */  \
> >  int dst_offset = i * 64; /* dst must be aligned */ 
> > \
> >  randomize_buffers();   
> > \
> > @@ -66,7 +66,7 @@
> >  int i; 
> > \
> >  declare_func_emms(AV_CPU_FLAG_MMX, void, int16_t *av_restrict 
> > block, const uint8_t *s1, const uint8_t *s2, int stride); \
> > 
> > \
> > -for (i = 0; i < BUF_UNITS; i++) {  
> > \
> > +for (i = 0; i < BUF_UNITS; i+=8) { 
> >  \
> >  int src_offset = i * 64 * sizeof(type) + i; /* Test various 
> > alignments */  \
> >  int dst_offset = i * 64; /* dst must be aligned */ 
> > \
> >  randomize_buffers();   
> > \
> > --
> > 1.7.9.5
> >
> 
> BUF_UNITS is 8, so that change would entirely eliminate the loop.
> Maybe src_offset should just be changed to be aligned properly,
> keeping the loop? Or is the only purpose of the loop to test
> alignment?

you mean something like this? :
commit e3ff4df1c0a83a178d0aaf102486d7fbc97994d1
Author: Michael Niedermayer 
Date:   Mon Jun 27 22:03:14 2016 +0200

tests/checkasm/pixblockdsp: Test 8 byte aligned positions

The code is documented as to require 8byte alignment

Signed-off-by: Michael Niedermayer 

diff --git a/tests/checkasm/pixblockdsp.c b/tests/checkasm/pixblockdsp.c
index 66bfdb7..2b88e7d 100644
--- a/tests/checkasm/pixblockdsp.c
+++ b/tests/checkasm/pixblockdsp.c
@@ -26,7 +26,7 @@
 #include "libavutil/intreadwrite.h"

 #define BUF_UNITS 8
-#define BUF_SIZE (BUF_UNITS * 128 + BUF_UNITS)
+#define BUF_SIZE (BUF_UNITS * 128 + 8 * BUF_UNITS)

 #define randomize_buffers() \
 do {\
@@ -50,7 +50,7 @@
 declare_func_emms(AV_CPU_FLAG_MMX, void, int16_t *block, const uint8_t 
*pixels, ptrdiff_t line_size);\

\
 for (i = 0; i < BUF_UNITS; i++) {  
\
-int src_offset = i * 64 * sizeof(type) + i; /* Test various 
alignments */  \
+int src_offset = i * 64 * sizeof(type) + 8 * i; /* Test various 
alignments */  \
 int dst_offset = i * 64; /* dst must be aligned */ 
\
 randomize_buffers();   
\
 call_ref(dst0 + dst_offset, src10 + src_offset, 8);
\
@@ -67,7 +67,7 @@
 declare_func_emms(AV_CPU_FLAG_MMX, void, int16_t *av_restrict block, 
const uint8_t *s1, const uint8_t *s2, int stride); \

\
 for (i = 0; i < BUF_UNITS; i++) {  
\
-int src_offset = i * 64 * sizeof(type) + i; /* Test various 
alignments */  \
+int src_offset = i * 64 * sizeof(type) + 8 * i; /* Test various 
alignments */  \
 int dst_offset = i * 64; /* dst must be aligned */ 
\
 randomize_buffers();   
\
 call_ref(dst0 + dst_offset, src10 + src_offset, src20 + 
src_offset, 8);\


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It re

[FFmpeg-devel] [PATCH] Remove last deprecated calls

2016-06-27 Thread Felt, Patrick
---
libavdevice/decklink_dec.cpp | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 7412727..9c5d5f9 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -120,10 +120,6 @@ static int avpacket_queue_put(AVPacketQueue *q, AVPacket 
*pkt)
 av_log(q->avctx, AV_LOG_WARNING,  "Decklink input buffer overrun!\n");
 return -1;
 }
-/* duplicate the packet */
-if (av_dup_packet(pkt) < 0) {
-return -1;
-}

 pkt1 = (AVPacketList *)av_malloc(sizeof(AVPacketList));
 if (!pkt1) {
@@ -582,6 +578,12 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
 st->codecpar->codec_tag   = MKTAG('U', 'Y', 'V', 'Y');
 st->codecpar->bit_rate= av_rescale(ctx->bmd_width * 
ctx->bmd_height * 16, st->time_base.den, st->time_base.num);
 }
+/* set up the interlacing settings */
+if (ctx->bmd_field_dominance == bmdLowerFieldFirst) {
+st->codecpar->field_order = AV_FIELD_BB;
+} else if (ctx->bmd_field_dominance == bmdUpperFieldFirst) {
+st->codecpar->field_order = AV_FIELD_TT;
+}

 avpriv_set_pts_info(st, 64, 1, 100);  /* 64 bits pts in us */

@@ -640,15 +642,8 @@ int ff_decklink_read_packet(AVFormatContext *avctx, 
AVPacket *pkt)
{
 struct decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;
 struct decklink_ctx *ctx = (struct decklink_ctx *) cctx->ctx;
-AVFrame *frame = ctx->video_st->codec->coded_frame;

 avpacket_queue_get(&ctx->queue, pkt, 1);
-if (frame && (ctx->bmd_field_dominance == bmdUpperFieldFirst || 
ctx->bmd_field_dominance == bmdLowerFieldFirst)) {
-frame->interlaced_frame = 1;
-if (ctx->bmd_field_dominance == bmdUpperFieldFirst) {
-frame->top_field_first = 1;
-}
-}

 return 0;
}
--
1.8.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Remove last deprecated calls

2016-06-27 Thread Hendrik Leppkes
On Mon, Jun 27, 2016 at 11:11 PM, Felt, Patrick
 wrote:
> ---
> libavdevice/decklink_dec.cpp | 17 ++---
> 1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> index 7412727..9c5d5f9 100644
> --- a/libavdevice/decklink_dec.cpp
> +++ b/libavdevice/decklink_dec.cpp
> @@ -120,10 +120,6 @@ static int avpacket_queue_put(AVPacketQueue *q, AVPacket 
> *pkt)
>  av_log(q->avctx, AV_LOG_WARNING,  "Decklink input buffer 
> overrun!\n");
>  return -1;
>  }
> -/* duplicate the packet */
> -if (av_dup_packet(pkt) < 0) {
> -return -1;
> -}
>
>  pkt1 = (AVPacketList *)av_malloc(sizeof(AVPacketList));
>  if (!pkt1) {
> @@ -582,6 +578,12 @@ av_cold int ff_decklink_read_header(AVFormatContext 
> *avctx)
>  st->codecpar->codec_tag   = MKTAG('U', 'Y', 'V', 'Y');
>  st->codecpar->bit_rate= av_rescale(ctx->bmd_width * 
> ctx->bmd_height * 16, st->time_base.den, st->time_base.num);
>  }
> +/* set up the interlacing settings */
> +if (ctx->bmd_field_dominance == bmdLowerFieldFirst) {
> +st->codecpar->field_order = AV_FIELD_BB;
> +} else if (ctx->bmd_field_dominance == bmdUpperFieldFirst) {
> +st->codecpar->field_order = AV_FIELD_TT;
> +}
>
>  avpriv_set_pts_info(st, 64, 1, 100);  /* 64 bits pts in us */
>
> @@ -640,15 +642,8 @@ int ff_decklink_read_packet(AVFormatContext *avctx, 
> AVPacket *pkt)
> {
>  struct decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;
>  struct decklink_ctx *ctx = (struct decklink_ctx *) cctx->ctx;
> -AVFrame *frame = ctx->video_st->codec->coded_frame;
>
>  avpacket_queue_get(&ctx->queue, pkt, 1);
> -if (frame && (ctx->bmd_field_dominance == bmdUpperFieldFirst || 
> ctx->bmd_field_dominance == bmdLowerFieldFirst)) {
> -frame->interlaced_frame = 1;
> -if (ctx->bmd_field_dominance == bmdUpperFieldFirst) {
> -frame->top_field_first = 1;
> -}
> -}
>
>  return 0;
> }

decklink should probably be updated eventually to use wrapped_avframe
output or something like that, then you could properly output
interlaced and field order flags on a per-frame basis.
Especially since the AVFMT_RAWPICTURE mode it uses is deprecated.

This applies to both decklink_dec and decklink_enc, fwiw.

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


Re: [FFmpeg-devel] [PATCH] Remove last deprecated calls

2016-06-27 Thread Felt, Patrick
Agreed.  I was headed to fixing up the input mode autodetection next as that’s 
still outstanding in my queue.  I wanted/needed to clean up those errors first 
though so i didn’t have to wrap those calls in FF_DISABLE_DEPRECATION_WARNINGS 
and subsequently forgetting to remove them when I submit my patch to the list.

On 6/27/16, 3:17 PM, "ffmpeg-devel on behalf of Hendrik Leppkes" 
 wrote:

decklink should probably be updated eventually to use wrapped_avframe
output or something like that, then you could properly output
interlaced and field order flags on a per-frame basis.
Especially since the AVFMT_RAWPICTURE mode it uses is deprecated.

This applies to both decklink_dec and decklink_enc, fwiw.

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


Re: [FFmpeg-devel] [PATCH 02/10] diracdsp: add dequantization SIMD

2016-06-27 Thread James Almer
On 6/27/2016 8:53 AM, Rostislav Pehlivanov wrote:
> I've attached another patch which should work fine now.
> I did this after the put_signed_rect so it does require the first patch,
> but if this patch is okay I'll amend and tidy things before I push.
> For some reason changing dstq to be stored at r4 or r3 broke it and I've no
> idea why. Neither is used after loading m2 and m3. Should work on x86_32
> now, but I'm wondering why I can't save that register.

[...]

> diff --git a/libavcodec/x86/diracdsp.asm b/libavcodec/x86/diracdsp.asm
> index c5cc530..4bc8b2d 100644
> --- a/libavcodec/x86/diracdsp.asm
> +++ b/libavcodec/x86/diracdsp.asm
> @@ -266,9 +266,45 @@ HPEL_FILTER sse2
>  ADD_OBMC 32, sse2
>  ADD_OBMC 16, sse2
>  
> -%if ARCH_X86_64 == 1
>  INIT_XMM sse4
>  
> +; void dequant_subband_32(uint8_t *src, uint8_t *dst, ptrdiff_t stride, 
> const int qf, const int qs, int tot_v, int tot_h)
> +cglobal dequant_subband_32, 7, 8, 4, src, dst, stride, qf, qs, tot_v, tot_h

x86_32 has 8 gprs but you can only use 7 as the last one is reserved
to keep the stack pointer.

> +
> +movd   m2, qfd
> +movd   m3, qsd
> +SPLATD m2
> +SPLATD m3
> +movr4, tot_hq
> +movr7, dstq
> +
> +.loop_v:
> +movtot_hq, r4
> +movdstq,   r7
> +
> +.loop_h:
> +movu   m0, [srcq]
> +
> +pabsd  m1, m0
> +pmulld m1, m2
> +paddd  m1, m3
> +psrld  m1,  2
> +psignd m1, m0
> +
> +movu   [dstq], m1
> +
> +addsrcq, mmsize
> +adddstq, mmsize
> +subtot_hd, 4
> +jg .loop_h
> +
> +addr7, strideq
> +dectot_vd
> +jg .loop_v
> +
> +RET

I'm not sure why you say using r3 instead of r7 here didn't work for
you. I just tried it (after applying all patches up to 6/10) and fate
at least still passes, on both x86_64 and x86_32.

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


[FFmpeg-devel] libavcodec/exr : add support for gray and gray A file

2016-06-27 Thread Martin Vignali
Hello,

in attach a patch to add support for Y and YA exr file
(ticket #5621)

sample can be found in this ticket,
https://trac.ffmpeg.org/ticket/5621

or in the official samples
http://download.savannah.nongnu.org/releases/openexr/openexr-images-1.7.0.tar.gz

pass exr fate test.


The second patch is only indent.


Comments welcome

Martin
Jokyo Images
From 949e4fa6571229d7253a90fdd8ca3946f8cc54ac Mon Sep 17 00:00:00 2001
From: Martin Vignali 
Date: Mon, 27 Jun 2016 23:52:39 +0200
Subject: [PATCH 1/2] libavodec/exr : add support for Y and YA file (ticket
 #5621)

a gray channel in exr, is named Y
we admit that the file need to be interpreted as gray
only if no other channel match (except alpha)

to manage RGB and Y in the color conversion part of decode_block,
the color processing is now made with a for loop.
---
 libavcodec/exr.c | 103 ---
 1 file changed, 61 insertions(+), 42 deletions(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index c87187c..46e8312 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -129,6 +129,8 @@ typedef struct EXRContext {
 EXRTileAttribute tile_attr; /* header data attribute of tile */
 int is_tile; /* 0 if scanline, 1 if tile */
 
+int is_luma;/* 1 if there is an Y plane */
+
 GetByteContext gb;
 const uint8_t *buf;
 int buf_size;
@@ -1016,6 +1018,7 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 int axmax = (avctx->width - (s->xmax + 1)) * 2 * s->desc->nb_components; /* nb pixel to add at the right of the datawindow */
 int bxmin = s->xmin * 2 * s->desc->nb_components; /* nb pixel to add at the left of the datawindow */
 int i, x, buf_size = s->buf_size;
+int c, rgb_channel_count;
 float one_gamma = 1.0f / s->gamma;
 avpriv_trc_function trc_func = avpriv_get_trc_function_from_trc(s->apply_trc_type);
 int ret;
@@ -1125,9 +1128,15 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 src = td->uncompressed_data;
 }
 
+if (!s->is_luma) {
 channel_buffer[0] = src + td->xsize * s->channel_offsets[0];
 channel_buffer[1] = src + td->xsize * s->channel_offsets[1];
 channel_buffer[2] = src + td->xsize * s->channel_offsets[2];
+rgb_channel_count = 3;
+} else { /* put y data in the first channel_buffer */
+channel_buffer[0] = src + td->xsize * s->channel_offsets[1];
+rgb_channel_count = 1;
+}
 if (s->channel_offsets[3] >= 0)
 channel_buffer[3] = src + td->xsize * s->channel_offsets[3];
 
@@ -1136,11 +1145,13 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 for (i = 0;
  i < td->ysize; i++, ptr += p->linesize[0]) {
 
-const uint8_t *r, *g, *b, *a;
+const uint8_t * a;
+const uint8_t *rgb[3];
+
+for (c = 0; c < rgb_channel_count; c++){
+rgb[c] = channel_buffer[c];
+}
 
-r = channel_buffer[0];
-g = channel_buffer[1];
-b = channel_buffer[2];
 if (channel_buffer[3])
 a = channel_buffer[3];
 
@@ -1155,37 +1166,26 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 if (trc_func) {
 for (x = 0; x < td->xsize; x++) {
 union av_intfloat32 t;
-t.i = bytestream_get_le32(&r);
-t.f = trc_func(t.f);
-*ptr_x++ = exr_flt2uint(t.i);
-
-t.i = bytestream_get_le32(&g);
-t.f = trc_func(t.f);
-*ptr_x++ = exr_flt2uint(t.i);
 
-t.i = bytestream_get_le32(&b);
-t.f = trc_func(t.f);
-*ptr_x++ = exr_flt2uint(t.i);
+for (c = 0; c < rgb_channel_count; c++) {
+t.i = bytestream_get_le32(&rgb[c]);
+t.f = trc_func(t.f);
+*ptr_x++ = exr_flt2uint(t.i);
+}
 if (channel_buffer[3])
 *ptr_x++ = exr_flt2uint(bytestream_get_le32(&a));
 }
 } else {
 for (x = 0; x < td->xsize; x++) {
 union av_intfloat32 t;
-t.i = bytestream_get_le32(&r);
-if (t.f > 0.0f)  /* avoid negative values */
-t.f = powf(t.f, one_gamma);
-*ptr_x++ = exr_flt2uint(t.i);
-
-t.i = bytestream_get_le32(&g);
-if (t.f > 0.0f)
-t.f = powf(t.f, one_gamma);
-*ptr_x++ = exr_flt2uint(t.i);
-
-t.i = bytestream_get_le32(&b);
-if (t.f > 0.0f)
-t.f = powf(t.f, one_gamma);
-*ptr_x++ = exr_flt2uint(t.i);
+
+for (int c = 0; c < rgb_channel_count; c++) {
+t.i = bytestream_get_le32(&rgb[c]);
+  

Re: [FFmpeg-devel] [PATCH] Remove last deprecated calls

2016-06-27 Thread Marton Balint


On Mon, 27 Jun 2016, Felt, Patrick wrote:


---
libavdevice/decklink_dec.cpp | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 7412727..9c5d5f9 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -120,10 +120,6 @@ static int avpacket_queue_put(AVPacketQueue *q, AVPacket 
*pkt)
av_log(q->avctx, AV_LOG_WARNING,  "Decklink input buffer overrun!\n");
return -1;
}
-/* duplicate the packet */
-if (av_dup_packet(pkt) < 0) {
-return -1;
-}


I don't think you can remove this, pkt.data needs to be memcpy-ed to a 
newly allocated buffer.


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


Re: [FFmpeg-devel] [PATCH 2/5] avcodec/ccaption_dec: implement tab offset commands

2016-06-27 Thread Michael Niedermayer
On Tue, Jun 14, 2016 at 11:57:42AM -0700, Aman Gupta wrote:
> From: Aman Gupta 
> 
> ---
>  libavcodec/ccaption_dec.c | 5 +
>  1 file changed, 5 insertions(+)

applied

thanks

[...]

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


Re: [FFmpeg-devel] [PATCH] Remove last deprecated calls

2016-06-27 Thread Felt, Patrick


From: ffmpeg-devel  on behalf of Marton Balint 

Reply-To: FFmpeg development discussions and patches 
Date: Monday, June 27, 2016 at 6:01 PM
To: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] [PATCH] Remove last deprecated calls


On Mon, 27 Jun 2016, Felt, Patrick wrote:

---
libavdevice/decklink_dec.cpp | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 7412727..9c5d5f9 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -120,10 +120,6 @@ static int avpacket_queue_put(AVPacketQueue *q, AVPacket 
*pkt)
 av_log(q->avctx, AV_LOG_WARNING,  "Decklink input buffer overrun!\n");
 return -1;
 }
-/* duplicate the packet */
-if (av_dup_packet(pkt) < 0) {
-return -1;
-}

I don't think you can remove this, pkt.data needs to be memcpy-ed to a
newly allocated buffer.

It appears to run cleanly on my test system, but I’d be happy to put it back.  
Would the following be the right thing in this case?  (I don’t fully understand 
what that function was intending to do originally; the replacement makes a bit 
more sense to me).

if (av_packet_ref(pkt, pkt) < 0) {
  return -1;
}

though it seems that might only be valid if the whole of decklink was using 
reference counted packets?  Does that function do the memcpy() you were 
thinking we needed?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] how to download specific track data of a m3u8 content?

2016-06-27 Thread aihua zhao
Hi Experts:

I use ffmpeg to parse/demux media content, and created a player basing on
it.

here is a m3u8 content:
http://asp.cntv.lxdns.com/asp/hls/main/0303000a/3/default/438eb7a818b246c187e72f1cd4e1bc4c/main.m3u8

there are three video track in it.

I found all video/audio tracks are downloaded during playback, and I can
switch different track on the fly.
however, it consumes much bandwidth since all tracks are downloaded.

even when I append bandwidth to the url; still the same result:
http://asp.cntv.lxdns.com/asp/hls/main/0303000a/3/default/438eb7a818b246c187e72f1cd4e1bc4c/main.m3u8?maxbr=1200

Is there any way to download the specified track only to save bandwidth?

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