[FFmpeg-devel] [PATCH] avformat/latmenc: automatically insert aac_adtstoasc bitstream filter when needed

[James Almer]

Signed-off-by: James Almer 
---
 libavformat/latmenc.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/libavformat/latmenc.c b/libavformat/latmenc.c
index db6977e..9713b1b 100644
--- a/libavformat/latmenc.c
+++ b/libavformat/latmenc.c
@@ -25,6 +25,7 @@
 #include "libavcodec/mpeg4audio.h"
 #include "libavutil/opt.h"
 #include "avformat.h"
+#include "internal.h"
 #include "rawenc.h"
 
 #define MAX_EXTRADATA_SIZE 1024
@@ -153,11 +154,6 @@ static int latm_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 if (s->streams[0]->codec->codec_id == AV_CODEC_ID_AAC_LATM)
 return ff_raw_write_packet(s, pkt);
 
-if (pkt->size > 2 && pkt->data[0] == 0xff && (pkt->data[1] >> 4) == 0xf) {
-av_log(s, AV_LOG_ERROR, "ADTS header detected - ADTS will not be 
incorrectly muxed into LATM\n");
-return AVERROR_INVALIDDATA;
-}
-
 if (!s->streams[0]->codec->extradata) {
 if(pkt->size > 2 && pkt->data[0] == 0x56 && (pkt->data[1] >> 4) == 0xe 
&&
 (AV_RB16(pkt->data + 1) & 0x1FFF) + 3 == pkt->size)
@@ -217,6 +213,19 @@ too_large:
 return AVERROR_INVALIDDATA;
 }
 
+static int latm_check_bitstream(struct AVFormatContext *s, const AVPacket *pkt)
+{
+int ret = 1;
+AVStream *st = s->streams[pkt->stream_index];
+
+if (st->codec->codec_id == AV_CODEC_ID_AAC) {
+if (pkt->size > 2 && (AV_RB16(pkt->data) & 0xfff0) == 0xfff0)
+ret = ff_stream_add_bitstream_filter(st, "aac_adtstoasc", NULL);
+}
+
+return ret;
+}
+
 AVOutputFormat ff_latm_muxer = {
 .name   = "latm",
 .long_name  = NULL_IF_CONFIG_SMALL("LOAS/LATM"),
@@ -228,5 +237,6 @@ AVOutputFormat ff_latm_muxer = {
 .write_header   = latm_write_header,
 .write_packet   = latm_write_packet,
 .priv_class = _muxer_class,
+.check_bitstream= latm_check_bitstream,
 .flags  = AVFMT_NOTIMESTAMPS,
 };
-- 
2.7.3

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

Re: [FFmpeg-devel] [PATCH 1/4] avfilter/vf_colormatrix: increase precision

[Michael Niedermayer]

On Sat, Mar 26, 2016 at 01:14:36AM +, Thomas Mundt wrote:
> >>>Michael Niedermayer  schrieb am Sa, 26.3.2016:
> > missing fate update
> Sorry!
> Updated patch attached. Now fate passes.

>  libavfilter/vf_colormatrix.c   |   34 --
>  tests/ref/fate/filter-colormatrix1 |2 +-
>  tests/ref/fate/filter-colormatrix2 |2 +-
>  3 files changed, 22 insertions(+), 16 deletions(-)
> 956ca148618f4b3656dc768e09de9b0fd6e10072  
> 0001-avfilter-vf_colormatrix-increase-precision.patch
> From 2fd8369efe9f04fa86d1b5b63a3b204f0beef64a Mon Sep 17 00:00:00 2001
> From: Thomas Mundt 
> Date: Sat, 26 Mar 2016 02:00:57 +0100
> Subject: [PATCH 1/4 v2] avfilter/vf_colormatrix: increase precision

this causes some compiler warnings

libavfilter/vf_colormatrix.c: In function ‘calc_coefficients’:
libavfilter/vf_colormatrix.c:163:9: warning: passing argument 2 of ‘inverse3x3’ 
from incompatible pointer type [enabled by default]
libavfilter/vf_colormatrix.c:117:13: note: expected ‘const double (*)[3]’ but 
argument is of type ‘double (*)[3]’
libavfilter/vf_colormatrix.c:166:13: warning: passing argument 3 of 
‘solve_coefficients’ from incompatible pointer type [enabled by default]
libavfilter/vf_colormatrix.c:132:13: note: expected ‘const double (*)[3]’ but 
argument is of type ‘double (*)[3]’

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes


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/4] avfilter/vf_colormatrix: increase precision

[Thomas Mundt]

>>>Michael Niedermayer  schrieb am Sa, 26.3.2016:
> missing fate update
Sorry!
Updated patch attached. Now fate passes.

0001-avfilter-vf_colormatrix-increase-precision.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 06/10] swscale/arm/yuv2rgb: only process one line at a time for the yuv420p and nv{12, 21} formats

[Michael Niedermayer]

On Fri, Mar 25, 2016 at 11:46:01PM +0100, Matthieu Bouron wrote:
> From: Matthieu Bouron 
> 
> ---
>  libswscale/arm/yuv2rgb_neon.S | 89 
> ---
>  1 file changed, 24 insertions(+), 65 deletions(-)

breaks build

 make distclean ; ../configure --cross-prefix=/usr/arm-linux-gnueabi/bin/ 
--cc='ccache arm-linux-gnueabi-gcc-4.5' --extra-cflags='-mfpu=neon 
-mfloat-abi=softfp' --cpu=cortex-a8 --arch=armv7 --target-os=linux 
--enable-cross-compile && make -j12

CC  libavutil/arm/float_dsp_init_arm.o
src/libswscale/arm/yuv2rgb_neon.S: Assembler messages:
src/libswscale/arm/yuv2rgb_neon.S:269: Error: thumb conditional instruction 
should be in IT block -- `subeq r6,r6,r0'
src/libswscale/arm/yuv2rgb_neon.S:269: Error: thumb conditional instruction 
should be in IT block -- `addne r6,r7'
src/libswscale/arm/yuv2rgb_neon.S:269: Error: thumb conditional instruction 
should be in IT block -- `subeq r6,r6,r0'
src/libswscale/arm/yuv2rgb_neon.S:269: Error: thumb conditional instruction 
should be in IT block -- `addne r6,r7'
src/libswscale/arm/yuv2rgb_neon.S:269: Error: thumb conditional instruction 
should be in IT block -- `subeq r6,r6,r0'
src/libswscale/arm/yuv2rgb_neon.S:269: Error: thumb conditional instruction 
should be in IT block -- `addne r6,r7'
src/libswscale/arm/yuv2rgb_neon.S:269: Error: thumb conditional instruction 
should be in IT block -- `subeq r6,r6,r0'
src/libswscale/arm/yuv2rgb_neon.S:269: Error: thumb conditional instruction 
should be in IT block -- `addne r6,r7'
src/libswscale/arm/yuv2rgb_neon.S:270: Error: thumb conditional instruction 
should be in IT block -- `subeq r6,r6,r0'
src/libswscale/arm/yuv2rgb_neon.S:270: Error: thumb conditional instruction 
should be in IT block -- `addne r6,r7'
CC  libavutil/arm/float_dsp_init_vfp.o
src/libswscale/arm/yuv2rgb_neon.S:270: Error: thumb conditional instruction 
should be in IT block -- `subeq r6,r6,r0'
src/libswscale/arm/yuv2rgb_neon.S:270: Error: thumb conditional instruction 
should be in IT block -- `addne r6,r7'ASlibavutil/arm/float_dsp_neon.o

CC  libavutil/arm/float_dsp_init_neon.o
src/libswscale/arm/yuv2rgb_neon.S:270: Error: thumb conditional instruction 
should be in IT block -- `subeq r6,r6,r0'
src/libswscale/arm/yuv2rgb_neon.S:270: Error: thumb conditional instruction 
should be in IT block -- `addne r6,r7'
AS  libavutil/arm/float_dsp_vfp.o
src/libswscale/arm/yuv2rgb_neon.S:270: Error: thumb conditional instruction 
should be in IT block -- `subeq r6,r6,r0'
src/libswscale/arm/yuv2rgb_neon.S:270: Error: thumb conditional instruction 
should be in IT block -- `addne r6,r7'
src/libswscale/arm/yuv2rgb_neon.S:271: Error: thumb conditional instruction 
should be in IT block -- `subeq r6,r6,r0,lsr#1'
src/libswscale/arm/yuv2rgb_neon.S:271: Error: thumb conditional instruction 
should be in IT block -- `addne r6,r7'
src/libswscale/arm/yuv2rgb_neon.S:271: Error: thumb conditional instruction 
should be in IT block -- `subeq r10,r10,r0,lsr#1'
src/libswscale/arm/yuv2rgb_neon.S:271: Error: thumb conditional instruction 
should be in IT block -- `addne r10,r12'
src/libswscale/arm/yuv2rgb_neon.S:271: Error: thumb conditional instruction 
should be in IT block -- `subeq r6,r6,r0,lsr#1'
src/libswscale/arm/yuv2rgb_neon.S:271: Error: thumb conditional instruction 
should be in IT block -- `addne r6,r7'
src/libswscale/arm/yuv2rgb_neon.S:271: Error: thumb conditional instruction 
should be in IT block -- `subeq r10,r10,r0,lsr#1'
src/libswscale/arm/yuv2rgb_neon.S:271: Error: thumb conditional instruction 
should be in IT block -- `addne r10,r12'
src/libswscale/arm/yuv2rgb_neon.S:271: Error: thumb conditional instruction 
should be in IT block -- `subeq r6,r6,r0,lsr#1'
src/libswscale/arm/yuv2rgb_neon.S:271: Error: thumb conditional instruction 
should be in IT block -- `addne r6,r7'
src/libswscale/arm/yuv2rgb_neon.S:271: Error: thumb conditional instruction 
should be in IT block -- `subeq r10,r10,r0,lsr#1'
src/libswscale/arm/yuv2rgb_neon.S:271: Error: thumb conditional instruction 
should be in IT block -- `addne r10,r12'
CC  libavutil/audio_fifo.o
CC  libavutil/avstring.o
src/libswscale/arm/yuv2rgb_neon.S:271: Error: thumb conditional instruction 
should be in IT block -- `subeq r6,r6,r0,lsr#1'
src/libswscale/arm/yuv2rgb_neon.S:271: Error: thumb conditional instruction 
should be in IT block -- `addne r6,r7'
src/libswscale/arm/yuv2rgb_neon.S:271: Error: thumb conditional instruction 
should be in IT block -- `subeq r10,r10,r0,lsr#1'
src/libswscale/arm/yuv2rgb_neon.S:271: Error: thumb conditional instruction 
should be in IT block -- `addne r10,r12'
CC  libavutil/base64.o
CC  libavutil/blowfish.o
CC  libavutil/bprint.o
CC  libavutil/buffer.o
CC  libavutil/camellia.o
make: *** [libswscale/arm/yuv2rgb_neon.o] Error 1
make: *** Waiting for unfinished jobs

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

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Hendrik Leppkes]

On Sat, Mar 26, 2016 at 1:12 AM, Thilo Borgmann  wrote:
>>
>> When you go from talking about a developers concerns to just pushing,
>> then how else do you think someone should feel?
>
> You are again ignoring what I did and what I've written in the previous
> mails to explain what I did and why I did it.
> Basically you're just repeating that in your opinion I "just pushed". As
> long as you don't explain why you think that way with respect to what
> I've written there will be no progress in this discussion.
> That's a pity because we both are obviously thinking that this is an
> important topic. Unfortunately, I think I did what you demand - I pinged
> after there was a significant silence after the last review.
> It is on you to prove me wrong for convincing me that I made a mistake
> by pushing too early.

None of the posts in this thread are a ping, all I see is back and
forth between two developers.
A ping would generally explictily ask for further feedback after a
time of silence, or anything like that, I don't see that here. For all
I knew, you were waiting for a response from wm4 on the last mail, it
was only a few days ago afterall.

This way, it would be clear to everyone reading, and someone else
might comment, instead I was thinking wm4 gave criticism, and this
would be hashed out before its pushed, especially since the general
rule is that when a developer has an issue with a patch, it shouldn't
be pushed until he was convinced otherwise or the patch adjusted, if
appropriate.

This also doesn't answer the question that this patch was never
excplicitly OK'ed.

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

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Thilo Borgmann]

Am 25.03.16 um 21:59 schrieb Hendrik Leppkes:
> On Fri, Mar 25, 2016 at 7:41 PM, Thilo Borgmann  
> wrote:
>> Am 25.03.16 um 18:48 schrieb Hendrik Leppkes:
>>> On Fri, Mar 25, 2016 at 6:26 PM, Thilo Borgmann  
>>> wrote:
 Am 25.03.16 um 17:56 schrieb Hendrik Leppkes:
> On Fri, Mar 25, 2016 at 5:48 PM, Thilo Borgmann  
> wrote:
>> Am 22.03.16 um 12:20 schrieb Thilo Borgmann:
>>> Am 22.03.16 um 11:45 schrieb wm4:
 On Sun, 13 Mar 2016 21:00:23 +0100
 Thilo Borgmann  wrote:

> Am 13.03.16 um 15:08 schrieb wm4:
>> On Sat, 12 Mar 2016 15:13:21 +0100
>> Thilo Borgmann  wrote:
>>
>>> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 
>>> 2001
>>> From: Thilo Borgmann 
>>> Date: Sat, 12 Mar 2016 14:52:17 +0100
>>> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple 
>>> equal keys.
>>> [...]
>>
>> Changing the semantics of AVDictionary just like this seems rather
>> questionable...
>
> It changes nothing for existing code, just adds a new feature. I don't
> think it hurts anyone or anything...

 It only breaks basic assumptions about a basic data type...
>>>
>>> Although I don't share your thought about breaking a basic data type 
>>> with that,
>>> what would you suggest instead?
>>
>> Pushed for no further suggestions and nobody else objected.
>>
>
> Just pushing without addressing concerns is not the way we usually try
> to work here, just saying.

 I think I have quite a good idea about the usual way we try to handle
 things here and I think I've addressed his concerns.
>>>
>>> If by addressing you mean disagreeing with the concern and doing nothing.
>>
>> Not at all. I proposed alternatives (alternatives which I don't like
>> much but anyway) and I explicitly asked for his suggestions. Means, I
>> actually tried to satisfy his concerns. Thus, I can't understand that
>> you are saying I've ignored anything.
>>
>>
 He didn't like it which is of course ok. He did not continue discussing
 it nor did he proposed any alternative. He also did not pick up any of
 my thoughts. He also did not explicitly state that he thinks that it is
 not ok to apply it. He said it "seems rather questionable". Without
 further discussion (what I tried) and nobody else complaining about it,
 what do you think would be more appropriate than to wait for quite a
 long time until continuing?

 The usual way for him to prevent me pushing it would just have been to
 ask me to wait and I would have waited. Have you checked the dates of
 the replies and what I wrote before accusing me to just ignore concerns?

>>>
>>> Timing makes no difference. Its the only review you got, so even if
>>> you ignore that, you didn't even get a "OK" from anyone else, which
>>> for generic API should be mandatory.
>>
>> I can't see why you accuse me ignoring something again.
> 
> I didn't, I just stated that noone ever OKed your patch.
> 
>>
>>
>>> The least that would have been appropriate would be to ping the patch
>>> asking for further comments, instead of just practically saying "I'm
>>> done waiting and just pushing"
>>>
>>> Not everyone has the time to answer within a day, so if someone
>>> expressed a concern, the least one could do before pushing is asking
>>> again, everything else feels rather disingenuous.
>>
>> First concern about this was stated on 13th.
>> After my reply, there was silence for nine days.
>> What would have been your assumption about his concerns after my reply?
>> Mine was that he considers this not to be as critical enough for further
>> discussion - means he might still dislike having multikey dictionaries
>> but sees no reason in struggling about it.
> 
> I wouldn't make assumptions, I would explicitly ask.

Sorry I missed that in my previous answer.

I asked: "Although I don't share your thought about breaking a basic
data type with that, what would you suggest instead?"

Maybe this is not explicit enough. Maybe silence form wm4 on that
question was not explicit enough.

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

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Thilo Borgmann]

Am 25.03.16 um 21:59 schrieb Hendrik Leppkes:
> On Fri, Mar 25, 2016 at 7:41 PM, Thilo Borgmann  
> wrote:
>> Am 25.03.16 um 18:48 schrieb Hendrik Leppkes:
>>> On Fri, Mar 25, 2016 at 6:26 PM, Thilo Borgmann  
>>> wrote:
 Am 25.03.16 um 17:56 schrieb Hendrik Leppkes:
> On Fri, Mar 25, 2016 at 5:48 PM, Thilo Borgmann  
> wrote:
>> Am 22.03.16 um 12:20 schrieb Thilo Borgmann:
>>> Am 22.03.16 um 11:45 schrieb wm4:
 On Sun, 13 Mar 2016 21:00:23 +0100
 Thilo Borgmann  wrote:

> Am 13.03.16 um 15:08 schrieb wm4:
>> On Sat, 12 Mar 2016 15:13:21 +0100
>> Thilo Borgmann  wrote:
>>
>>> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 
>>> 2001
>>> From: Thilo Borgmann 
>>> Date: Sat, 12 Mar 2016 14:52:17 +0100
>>> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple 
>>> equal keys.
>>> [...]
>>
>> Changing the semantics of AVDictionary just like this seems rather
>> questionable...
>
> It changes nothing for existing code, just adds a new feature. I don't
> think it hurts anyone or anything...

 It only breaks basic assumptions about a basic data type...
>>>
>>> Although I don't share your thought about breaking a basic data type 
>>> with that,
>>> what would you suggest instead?
>>
>> Pushed for no further suggestions and nobody else objected.
>>
>
> Just pushing without addressing concerns is not the way we usually try
> to work here, just saying.

 I think I have quite a good idea about the usual way we try to handle
 things here and I think I've addressed his concerns.
>>>
>>> If by addressing you mean disagreeing with the concern and doing nothing.
>>
>> Not at all. I proposed alternatives (alternatives which I don't like
>> much but anyway) and I explicitly asked for his suggestions. Means, I
>> actually tried to satisfy his concerns. Thus, I can't understand that
>> you are saying I've ignored anything.
>>
>>
 He didn't like it which is of course ok. He did not continue discussing
 it nor did he proposed any alternative. He also did not pick up any of
 my thoughts. He also did not explicitly state that he thinks that it is
 not ok to apply it. He said it "seems rather questionable". Without
 further discussion (what I tried) and nobody else complaining about it,
 what do you think would be more appropriate than to wait for quite a
 long time until continuing?

 The usual way for him to prevent me pushing it would just have been to
 ask me to wait and I would have waited. Have you checked the dates of
 the replies and what I wrote before accusing me to just ignore concerns?

>>>
>>> Timing makes no difference. Its the only review you got, so even if
>>> you ignore that, you didn't even get a "OK" from anyone else, which
>>> for generic API should be mandatory.
>>
>> I can't see why you accuse me ignoring something again.
> 
> I didn't, I just stated that noone ever OKed your patch.
> 
>>
>>
>>> The least that would have been appropriate would be to ping the patch
>>> asking for further comments, instead of just practically saying "I'm
>>> done waiting and just pushing"
>>>
>>> Not everyone has the time to answer within a day, so if someone
>>> expressed a concern, the least one could do before pushing is asking
>>> again, everything else feels rather disingenuous.
>>
>> First concern about this was stated on 13th.
>> After my reply, there was silence for nine days.
>> What would have been your assumption about his concerns after my reply?
>> Mine was that he considers this not to be as critical enough for further
>> discussion - means he might still dislike having multikey dictionaries
>> but sees no reason in struggling about it.
> 
> I wouldn't make assumptions, I would explicitly ask.
> 
>>
>> I pinged the patch again on 22nd, and it took about one minute for wm4
>> to address his concerns again. However, after me asking for his
>> suggestions there was again silence for days. Also note that he did not
>> stated his concerns more specifically than before.
>>
>> So I waiting for around 12 days (including a ping) to get a more
>> specific remark, counter-proposal, discussion or anything else than a
>> basic concern. During that time wm4 was active and very well capable of
>> immediate reply. Thus I assume that his attitude about this patch is not
>> as bad as insisting not to apply.
>>
>> I still really can't see a "I'm done waiting and just pushing" attitude
>> from my side.
>>
> 
> When you go from talking about a developers concerns to just pushing,
> then how else do you think someone should feel?

You are again ignoring what I did and what 

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Thilo Borgmann]

Am 25.03.16 um 21:12 schrieb wm4:
> On Fri, 25 Mar 2016 19:41:40 +0100
> Thilo Borgmann  wrote:
> 
>> Am 25.03.16 um 18:48 schrieb Hendrik Leppkes:
>>> On Fri, Mar 25, 2016 at 6:26 PM, Thilo Borgmann  
>>> wrote:  
 Am 25.03.16 um 17:56 schrieb Hendrik Leppkes:  
> On Fri, Mar 25, 2016 at 5:48 PM, Thilo Borgmann  
> wrote:  
>> Am 22.03.16 um 12:20 schrieb Thilo Borgmann:  
>>> Am 22.03.16 um 11:45 schrieb wm4:  
 On Sun, 13 Mar 2016 21:00:23 +0100
 Thilo Borgmann  wrote:
  
> Am 13.03.16 um 15:08 schrieb wm4:  
>> On Sat, 12 Mar 2016 15:13:21 +0100
>> Thilo Borgmann  wrote:
>>  
>>> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 
>>> 2001
>>> From: Thilo Borgmann 
>>> Date: Sat, 12 Mar 2016 14:52:17 +0100
>>> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple 
>>> equal keys.
>>> [...]  
>>
>> Changing the semantics of AVDictionary just like this seems rather
>> questionable...  
>
> It changes nothing for existing code, just adds a new feature. I don't
> think it hurts anyone or anything...  

 It only breaks basic assumptions about a basic data type...  
>>>
>>> Although I don't share your thought about breaking a basic data type 
>>> with that,
>>> what would you suggest instead?  
>>
>> Pushed for no further suggestions and nobody else objected.
>>  
>
> Just pushing without addressing concerns is not the way we usually try
> to work here, just saying.  

 I think I have quite a good idea about the usual way we try to handle
 things here and I think I've addressed his concerns.  
>>>
>>> If by addressing you mean disagreeing with the concern and doing nothing.  
>>
>> Not at all. I proposed alternatives (alternatives which I don't like
>> much but anyway) and I explicitly asked for his suggestions. Means, I
>> actually tried to satisfy his concerns. Thus, I can't understand that
>> you are saying I've ignored anything.
>>
>>
 He didn't like it which is of course ok. He did not continue discussing
 it nor did he proposed any alternative. He also did not pick up any of
 my thoughts. He also did not explicitly state that he thinks that it is
 not ok to apply it. He said it "seems rather questionable". Without
 further discussion (what I tried) and nobody else complaining about it,
 what do you think would be more appropriate than to wait for quite a
 long time until continuing?

 The usual way for him to prevent me pushing it would just have been to
 ask me to wait and I would have waited. Have you checked the dates of
 the replies and what I wrote before accusing me to just ignore concerns?
  
>>>
>>> Timing makes no difference. Its the only review you got, so even if
>>> you ignore that, you didn't even get a "OK" from anyone else, which
>>> for generic API should be mandatory.  
>>
>> I can't see why you accuse me ignoring something again.
>>
>>
>>> The least that would have been appropriate would be to ping the patch
>>> asking for further comments, instead of just practically saying "I'm
>>> done waiting and just pushing"
>>>
>>> Not everyone has the time to answer within a day, so if someone
>>> expressed a concern, the least one could do before pushing is asking
>>> again, everything else feels rather disingenuous.  
>>
>> First concern about this was stated on 13th.
>> After my reply, there was silence for nine days.
>> What would have been your assumption about his concerns after my reply?
>> Mine was that he considers this not to be as critical enough for further
>> discussion - means he might still dislike having multikey dictionaries
>> but sees no reason in struggling about it.
>>
>> I pinged the patch again on 22nd, and it took about one minute for wm4
>> to address his concerns again. However, after me asking for his
>> suggestions there was again silence for days. Also note that he did not
>> stated his concerns more specifically than before.
>>
>> So I waiting for around 12 days (including a ping) to get a more
>> specific remark, counter-proposal, discussion or anything else than a
>> basic concern. During that time wm4 was active and very well capable of
>> immediate reply. Thus I assume that his attitude about this patch is not
>> as bad as insisting not to apply.
>>
>> I still really can't see a "I'm done waiting and just pushing" attitude
>> from my side.
> 
> You were adding weird new public API just to internally parse some
> really weird syntax. I hoped other would voice their concern too, but
> nobody did, so who cares, I guess.

Which means my assumption about your attitude to this patch was not
totally wrong. Also 

Re: [FFmpeg-devel] [PATCH 1/4] avfilter/vf_colormatrix: increase precision

[Michael Niedermayer]

On Fri, Mar 25, 2016 at 11:31:12PM +0100, Thomas Mundt wrote:
> Signed-off-by: Thomas Mundt 
> ---
>  libavfilter/vf_colormatrix.c | 34 --
>  1 file changed, 20 insertions(+), 14 deletions(-)

missing fate update

--- ./tests/ref/fate/filter-colormatrix12016-03-24 23:07:08.269790655 
+0100
+++ tests/data/fate/filter-colormatrix1 2016-03-26 01:03:09.463757520 +0100
@@ -1 +1 @@
-colormatrix10a0640b2d4ccd4e793f4919d82a89523
+colormatrix11593e24a71db42d07781b92665cf99a9
--- ./tests/ref/fate/filter-colormatrix22016-03-24 23:07:08.269790655 
+0100
+++ tests/data/fate/filter-colormatrix2 2016-03-26 01:03:09.463757520 +0100
@@ -1 +1 @@
-colormatrix25eb17671c03496ae43723e49832ab17a
+colormatrix2cafba294debb89f59143b519f3cd1673
Test filter-colormatrix1 failed. Look at 
tests/data/fate/filter-colormatrix1.err for details.
make: *** [fate-filter-colormatrix1] Error 1
make: *** Waiting for unfinished jobs
Test filter-colormatrix2 failed. Look at 
tests/data/fate/filter-colormatrix2.err for details.
make: *** [fate-filter-colormatrix2] Error 1


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

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


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

[FFmpeg-devel] [PATCH] configure: Fail if CUDA enabled but not found

[Timo Rothenpieler]

Without this patch, configure still passes and enables CUDA, no matter
if it was actually found, breaking the build in case it was not.
---
 configure | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index feb0bc2..2b16198 100755
--- a/configure
+++ b/configure
@@ -5516,7 +5516,8 @@ enabled avfoundation_indev && { check_lib2 
CoreGraphics/CoreGraphics.h CGGetActi
 enabled avisynth  && { { check_lib2 "windows.h" LoadLibrary; } ||
{ check_lib2 "dlfcn.h" dlopen -ldl; } ||
die "ERROR: LoadLibrary/dlopen not found for 
avisynth"; }
-enabled cuda  && check_lib cuda.h cuInit -lcuda
+enabled cuda  && { check_lib cuda.h cuInit -lcuda ||
+   die "ERROR: CUDA not found"; }
 enabled chromaprint   && require chromaprint chromaprint.h 
chromaprint_get_version -lchromaprint
 enabled coreimage_filter  && { check_header_objcc QuartzCore/CoreImage.h || 
disable coreimage_filter; }
 enabled coreimagesrc_filter && { check_header_objcc QuartzCore/CoreImage.h || 
disable coreimagesrc_filter; }
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 06/10] swscale/arm/yuv2rgb: only process one line at a time for the yuv420p and nv{12, 21} formats

[Matthieu Bouron]

From: Matthieu Bouron 

---
 libswscale/arm/yuv2rgb_neon.S | 89 ---
 1 file changed, 24 insertions(+), 65 deletions(-)

diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index ef7b0a6..8abb986 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -105,16 +105,6 @@
 compute_16pxr2, d14, d15, \ofmt
 .endm
 
-.macro process_2l_16px ofmt
-compute_premult d28, d29, d30, d31
-
-vld1.8  {q7}, [r4]!@ first 
line of luma
-compute_16pxr2, d14, d15, \ofmt
-
-vld1.8  {q7}, [r12]!   @ 
second line of luma
-compute_16pxr11, d14, d15, \ofmt
-.endm
-
 .macro load_args_nvx
 push{r4-r12, lr}
 vpush   {q4-q7}
@@ -127,13 +117,9 @@
 ldr r10,[sp, #128] @ r10 = 
y_coeff
 vdup.16 d0, r10@ d0  = 
y_coeff
 vld1.16 {d1}, [r8] @ d1  = 
*table
-add r11, r2, r3@ r11 = 
dst + linesize (dst2)
-add r12, r4, r5@ r12 = 
srcY + linesizeY (srcY2)
-lsl r3, r3, #1
-lsl r5, r5, #1
-sub r3, r3, r0, lsl #2 @ r3 = 
linesize  * 2 - width * 4 (padding)
-sub r5, r5, r0 @ r5 = 
linesizeY * 2 - width (paddingY)
-sub r7, r7, r0 @ r7 = 
linesizeC - width (paddingC)
+sub r3, r3, r0, lsl #2 @ r3 = 
linesize  - width * 4 (padding)
+sub r5, r5, r0 @ r5 = 
linesizeY - width (paddingY)
+sub r7, r7, r0 @ r7 = 
linesizeC - width (paddingC)
 .endm
 
 .macro load_args_yuv420p
@@ -142,26 +128,6 @@
 ldr r4, [sp, #104] @ r4  = 
srcY
 ldr r5, [sp, #108] @ r5  = 
linesizeY
 ldr r6, [sp, #112] @ r6  = 
srcU
-ldr r8, [sp, #128] @ r8  = 
table
-ldr r9, [sp, #132] @ r9  = 
y_offset
-ldr r10,[sp, #136] @ r10 = 
y_coeff
-vdup.16 d0, r10@ d0  = 
y_coeff
-vld1.16 {d1}, [r8] @ d1  = 
*table
-add r11, r2, r3@ r11 = 
dst + linesize (dst2)
-add r12, r4, r5@ r12 = 
srcY + linesizeY (srcY2)
-lsl r3, r3, #1
-lsl r5, r5, #1
-sub r3, r3, r0, lsl #2 @ r3 = 
linesize  * 2 - width * 4 (padding)
-sub r5, r5, r0 @ r5 = 
linesizeY * 2 - width (paddingY)
-ldr r10,[sp, #120] @ r10 = 
srcV
-.endm
-
-.macro load_args_yuv422p
-push{r4-r12, lr}
-vpush   {q4-q7}
-ldr r4, [sp, #104] @ r4  = 
srcY
-ldr r5, [sp, #108] @ r5  = 
linesizeY
-ldr r6, [sp, #112] @ r6  = 
srcU
 ldr r7, [sp, #116] @ r7  = 
linesizeU
 ldr r12,[sp, #124] @ r12 = 
linesizeV
 ldr r8, [sp, #128] @ r8  = 
table
@@ -176,6 +142,10 @@
 ldr r10,[sp, #120] @ r10 = 
srcV
 .endm
 
+.macro load_args_yuv422p
+load_args_yuv420p
+.endm
+
 .macro declare_func ifmt ofmt
 function ff_\ifmt\()_to_\ofmt\()_neon, export=1
 
@@ -205,35 +175,30 @@ function ff_\ifmt\()_to_\ofmt\()_neon, export=1
 vmov.i8 d10, #128
 
 .ifc \ifmt,nv12
-pld [r12, #64*3]
-
 vld2.8  {d2, d3}, [r6]!@ q1: 
interleaved chroma line
 vsubl.u8q14, d2, d10   @ q14 = 
U - 128
 vsubl.u8q15, d3, d10   @ q15 = 
V - 128
 
-process_2l_16px \ofmt
+process_1l_16px \ofmt
 .endif
 
 .ifc \ifmt,nv21
-pld [r12, #64*3]
-
 vld2.8  {d2, d3}, [r6]! 

[FFmpeg-devel] [PATCH 04/10] swscale/arm/yuv2rgb: factorize lsl in load_args_yuv420p

[Matthieu Bouron]

From: Matthieu Bouron 

---
 libswscale/arm/yuv2rgb_neon.S | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index 22864ec..4601a79 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -152,8 +152,7 @@
 add r12, r4, r5@ r12 = 
srcY + linesizeY (srcY2)
 lsl r3, r3, #1
 lsl r5, r5, #1
-lsl r8, r0, #2
-sub r3, r3, r8 @ r3 = 
linesize  * 2 - width * 4 (padding)
+sub r3, r3, r0, lsl #2 @ r3 = 
linesize  * 2 - width * 4 (padding)
 sub r5, r5, r0 @ r5 = 
linesizeY * 2 - width (paddingY)
 ldr r10,[sp, #120] @ r10 = 
srcV
 .endm
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 03/10] swscale/arm/yuv2rgb: remove unused store of dst + linesize in load_args_yuv422p

[Matthieu Bouron]

From: Matthieu Bouron 

---
 libswscale/arm/yuv2rgb_neon.S | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index aac0773..22864ec 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -171,7 +171,6 @@
 ldr r10,[sp, #136] @ r10 = 
y_coeff
 vdup.16 d0, r10@ d0  = 
y_coeff
 vld1.16 {d1}, [r8] @ d1  = 
*table
-add r11, r2, r3@ r11 = 
dst + linesize (dst2)
 sub r3, r3, r0, lsl #2 @ r3  = 
linesize  - width * 4 (padding)
 sub r5, r5, r0 @ r5  = 
linesizeY - width (paddingY)
 sub r7, r7, r0, lsr #1 @ r7  = 
linesizeU - width / 2 (paddingU)
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 08/10] swscale/arm/yuv2rgb: re-organize the code like its aarch64 counter part

[Matthieu Bouron]

From: Matthieu Bouron 

---
 libswscale/arm/yuv2rgb_neon.S | 154 +++---
 1 file changed, 69 insertions(+), 85 deletions(-)

diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index f77f534..03d15cb 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -21,90 +21,6 @@
 
 #include "libavutil/arm/asm.S"
 
-
-.macro compute_premult half_u1, half_u2, half_v1, half_v2
-vmovd2, \half_u1   @ copy 
left q14 to left q1
-vmovd3, \half_u1   @ copy 
left q14 to right q1
-vmovd4, \half_u2   @ copy 
right q14 to left q2
-vmovd5, \half_u2   @ copy 
right q14 to right q2
-
-vmovd6, \half_v1   @ copy 
left q15 to left q3
-vmovd7, \half_v1   @ copy 
left q15 to right q3
-vmovd8, \half_v2   @ copy 
right q15 to left q4
-vmovd9, \half_v2   @ copy 
right q15 to right q4
-
-vzip.16 d2, d3 @ 
U1U1U2U2U3U3U4U4
-vzip.16 d4, d5 @ 
U5U5U6U6U7U7U8U8
-
-vzip.16 d6, d7 @ 
V1V1V2V2V3V3V4V4
-vzip.16 d8, d9 @ 
V5V5V6V6V7V7V8V8
-
-vmul.s16q8,  q3, d1[0] @  V * 
v2r (left,  red)
-vmul.s16q9,  q4, d1[0] @  V * 
v2r (right, red)
-vmul.s16q10, q1, d1[1] @  U * 
u2g
-vmul.s16q11, q2, d1[1] @  U * 
u2g
-vmla.s16q10, q3, d1[2] @  U * 
u2g + V * v2g   (left,  green)
-vmla.s16q11, q4, d1[2] @  U * 
u2g + V * v2g   (right, green)
-vmul.s16q12, q1, d1[3] @  U * 
u2b (left,  blue)
-vmul.s16q13, q2, d1[3] @  U * 
u2b (right, blue)
-.endm
-
-.macro compute_color dst_comp1 dst_comp2 pre1 pre2
-vadd.s16q1, q14, \pre1
-vadd.s16q2, q15, \pre2
-vqrshrun.s16\dst_comp1, q1, #6
-vqrshrun.s16\dst_comp2, q2, #6
-.endm
-
-.macro compute_rgba r1 r2 g1 g2 b1 b2 a1 a2
-compute_color   \r1, \r2, q8,  q9
-compute_color   \g1, \g2, q10, q11
-compute_color   \b1, \b2, q12, q13
-vmov.u8 \a1, #255
-vmov.u8 \a2, #255
-.endm
-
-.macro compute_16px dst y0 y1 ofmt
-vmovl.u8q14, \y0   @ 8px 
of y
-vmovl.u8q15, \y1   @ 8px 
of y
-
-vdup.16 q5, r9 @ q5  = 
y_offset
-vmovd14, d0@ q7  = 
y_coeff
-vmovd15, d0@ q7  = 
y_coeff
-
-vsub.s16q14, q5
-vsub.s16q15, q5
-
-vmul.s16q14, q7@ q14 = 
(srcY - y_offset) * y_coeff (left)
-vmul.s16q15, q7@ q15 = 
(srcY - y_offset) * y_coeff (right)
-
-
-.ifc \ofmt,argb
-compute_rgbad7, d11, d8, d12, d9, d13, d6, d10
-.endif
-
-.ifc \ofmt,rgba
-compute_rgbad6, d10, d7, d11, d8, d12, d9, d13
-.endif
-
-.ifc \ofmt,abgr
-compute_rgbad9, d13, d8, d12, d7, d11, d6, d10
-.endif
-
-.ifc \ofmt,bgra
-compute_rgbad8, d12, d7, d11, d6, d10, d9, d13
-.endif
-vst4.8  {q3, q4}, [\dst,:128]!
-vst4.8  {q5, q6}, [\dst,:128]!
-
-.endm
-
-.macro process_1l_16px ofmt
-compute_premult d28, d29, d30, d31
-vld1.8  {q7}, [r4]!
-compute_16pxr2, d14, d15, \ofmt
-.endm
-
 .macro load_args_nv12
 push{r4-r12, lr}
 vpush   {q4-q7}
@@ -198,6 +114,21 @@
 add r10,r10,r12@ srcV  
+= paddingV
 .endm
 
+.macro compute_color dst_comp1 dst_comp2 pre1 pre2
+vadd.s16q1, q14, \pre1
+vadd.s16q2, q15, \pre2
+vqrshrun.s16\dst_comp1, q1, #6
+vqrshrun.s16\dst_comp2, q2, #6
+.endm
+
+.macro compute_rgba r1 r2 g1 g2 b1 b2 a1 a2
+compute_color   \r1, \r2, q8,  q9
+compute_color   \g1, \g2, q10, q11
+compute_color   \b1, 

[FFmpeg-devel] [PATCH 10/10] swscale/arm/yuv2rgb: make the code bitexact with its aarch64 counter part

[Matthieu Bouron]

From: Matthieu Bouron 

---
 libswscale/arm/swscale_unscaled.c | 16 +++
 libswscale/arm/yuv2rgb_neon.S | 89 +--
 2 files changed, 47 insertions(+), 58 deletions(-)

diff --git a/libswscale/arm/swscale_unscaled.c 
b/libswscale/arm/swscale_unscaled.c
index 149208c..1986d65 100644
--- a/libswscale/arm/swscale_unscaled.c
+++ b/libswscale/arm/swscale_unscaled.c
@@ -62,10 +62,10 @@ static int rgbx_to_nv12_neon_16_wrapper(SwsContext 
*context, const uint8_t *src[
 }
 
 #define YUV_TO_RGB_TABLE   
 \
-c->yuv2rgb_v2r_coeff / (1 << 7),   
 \
-c->yuv2rgb_u2g_coeff / (1 << 7),   
 \
-c->yuv2rgb_v2g_coeff / (1 << 7),   
 \
-c->yuv2rgb_u2b_coeff / (1 << 7),   
 \
+c->yuv2rgb_v2r_coeff,  
 \
+c->yuv2rgb_u2g_coeff,  
 \
+c->yuv2rgb_v2g_coeff,  
 \
+c->yuv2rgb_u2b_coeff,  
 \
 
 #define DECLARE_FF_YUVX_TO_RGBX_FUNCS(ifmt, ofmt)  
 \
 int ff_##ifmt##_to_##ofmt##_neon(int w, int h, 
 \
@@ -88,8 +88,8 @@ static int ifmt##_to_##ofmt##_neon_wrapper(SwsContext *c, 
const uint8_t *src[],
  src[1], srcStride[1], 
 \
  src[2], srcStride[2], 
 \
  yuv2rgb_table,
 \
- c->yuv2rgb_y_offset >> 9, 
 \
- c->yuv2rgb_y_coeff / (1 << 7));   
 \
+ c->yuv2rgb_y_offset >> 6, 
 \
+ c->yuv2rgb_y_coeff);  
 \

 \
 return 0;  
 \
 }  
 \
@@ -121,8 +121,8 @@ static int ifmt##_to_##ofmt##_neon_wrapper(SwsContext *c, 
const uint8_t *src[],
  dst[0] + srcSliceY * dstStride[0], 
dstStride[0],   \
  src[0], srcStride[0], src[1], srcStride[1],   
 \
  yuv2rgb_table,
 \
- c->yuv2rgb_y_offset >> 9, 
 \
- c->yuv2rgb_y_coeff / (1 << 7));   
 \
+ c->yuv2rgb_y_offset >> 6, 
 \
+ c->yuv2rgb_y_coeff);  
 \

 \
 return 0;  
 \
 }  
 \
diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index fe5dd04..9345bae 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -68,14 +68,14 @@
 
 .macro load_chroma_nv12
 vld2.8  {d2, d3}, [r6]!@ q1: 
interleaved chroma line
-vsubl.u8q14, d2, d10   @ q14 = 
U - 128
-vsubl.u8q15, d3, d10   @ q15 = 
V - 128
+vshll.u8q14, d2, #3@ q14 = 
U * (1 << 3)
+vshll.u8q15, d3, #3@ q15 = 
V * (1 << 3)
 .endm
 
 .macro load_chroma_nv21
 vld2.8  {d2, d3}, [r6]!@ q1: 
interleaved chroma line
-vsubl.u8q14, d3, d10   @ q14 = 
U - 128
-vsubl.u8q15, d2, d10   @ q15 = 
V - 128
+vshll.u8q14, d3, #3@ q14 = 
U * (1 << 3)
+vshll.u8q15, d2, #3@ q15 = 
V * (1 << 3)
 .endm
 
 .macro load_chroma_yuv420p
@@ -83,8 +83,8 @@
 
 vld1.8  

[FFmpeg-devel] [PATCH 07/10] swscale/arm/yuv2rgb: macro-ify

[Matthieu Bouron]

From: Matthieu Bouron 

---
 libswscale/arm/yuv2rgb_neon.S | 115 ++
 1 file changed, 39 insertions(+), 76 deletions(-)

diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index 8abb986..f77f534 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -105,7 +105,7 @@
 compute_16pxr2, d14, d15, \ofmt
 .endm
 
-.macro load_args_nvx
+.macro load_args_nv12
 push{r4-r12, lr}
 vpush   {q4-q7}
 ldr r4, [sp, #104] @ r4  = 
srcY
@@ -122,6 +122,10 @@
 sub r7, r7, r0 @ r7 = 
linesizeC - width (paddingC)
 .endm
 
+.macro load_args_nv21
+load_args_nv12
+.endm
+
 .macro load_args_yuv420p
 push{r4-r12, lr}
 vpush   {q4-q7}
@@ -146,113 +150,72 @@
 load_args_yuv420p
 .endm
 
-.macro declare_func ifmt ofmt
-function ff_\ifmt\()_to_\ofmt\()_neon, export=1
-
-.ifc \ifmt,nv12
-load_args_nvx
-.endif
-
-.ifc \ifmt,nv21
-load_args_nvx
-.endif
-
-.ifc \ifmt,yuv420p
-load_args_yuv420p
-.endif
-
-
-.ifc \ifmt,yuv422p
-load_args_yuv422p
-.endif
-
-1:
-mov r8, r0 @ r8 = 
width
-2:
-pld [r6, #64*3]
-pld [r4, #64*3]
-
-vmov.i8 d10, #128
-
-.ifc \ifmt,nv12
+.macro load_chroma_nv12
 vld2.8  {d2, d3}, [r6]!@ q1: 
interleaved chroma line
 vsubl.u8q14, d2, d10   @ q14 = 
U - 128
 vsubl.u8q15, d3, d10   @ q15 = 
V - 128
+.endm
 
-process_1l_16px \ofmt
-.endif
-
-.ifc \ifmt,nv21
+.macro load_chroma_nv21
 vld2.8  {d2, d3}, [r6]!@ q1: 
interleaved chroma line
 vsubl.u8q14, d3, d10   @ q14 = 
U - 128
 vsubl.u8q15, d2, d10   @ q15 = 
V - 128
+.endm
 
-process_1l_16px \ofmt
-.endif
-
-.ifc \ifmt,yuv420p
-pld [r10, #64*3]
-
-vld1.8  d2, [r6]!  @ d2: 
chroma red line
-vld1.8  d3, [r10]! @ d3: 
chroma blue line
-vsubl.u8q14, d2, d10   @ q14 = 
U - 128
-vsubl.u8q15, d3, d10   @ q15 = 
V - 128
-
-process_1l_16px \ofmt
-.endif
-
-.ifc \ifmt,yuv422p
+.macro load_chroma_yuv420p
 pld [r10, #64*3]
 
 vld1.8  d2, [r6]!  @ d2: 
chroma red line
 vld1.8  d3, [r10]! @ d3: 
chroma blue line
 vsubl.u8q14, d2, d10   @ q14 = 
U - 128
 vsubl.u8q15, d3, d10   @ q15 = 
V - 128
+.endm
 
-process_1l_16px \ofmt
-.endif
-
-subsr8, r8, #16@ width 
-= 16
-bgt 2b
-
-add r2, r2, r3 @ dst   
+= padding
-add r4, r4, r5 @ srcY  
+= paddingY
-
-.ifc \ifmt,nv12
-tst r1, #1
-subeq   r6, r6, r0 @ if 
(height % 2 == 0) paddingU -= width
-addne   r6, r7 @ else  
   paddingU += linesizeU - width
-
-subsr1, r1, #1 @ 
height -= 1
-.endif
+.macro load_chroma_yuv422p
+load_chroma_yuv420p
+.endm
 
-.ifc \ifmt,nv21
+.macro increment_nv12
 tst r1, #1
 subeq   r6, r6, r0 @ if 
(height % 2 == 0) paddingU -= width
 addne   r6, r7 @ else  
   paddingU += linesizeU - width
+.endm
 
-subsr1, r1, #1 @ 
height -= 1
-.endif
+.macro increment_nv21
+increment_nv12
+.endm
 
-.ifc \ifmt,yuv420p
+.macro increment_yuv420p
 tst r1, #1
 subeq   r6, r6, r0, lsr #1 @ if 
(height % 2 == 0) paddingU -= (width / 2)
 addne   r6, r7 @ else  
   paddingU += linesizeU - (width / 2)
 subeq   r10, r10, r0, lsr #1   @ if 
(height % 2 == 0) paddingU -= (width / 2)
 addne   r10, r12   @ else  
   paddingV = linesizeV - (width / 2)
+.endm
 
-subsr1, r1, #1 

[FFmpeg-devel] [PATCH 09/10] swscale/arm/yuv2rgb: re-order arguments of the compute_rgba macro

[Matthieu Bouron]

From: Matthieu Bouron 

---
 libswscale/arm/yuv2rgb_neon.S | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index 03d15cb..fe5dd04 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -121,7 +121,7 @@
 vqrshrun.s16\dst_comp2, q2, #6
 .endm
 
-.macro compute_rgba r1 r2 g1 g2 b1 b2 a1 a2
+.macro compute_rgba r1 g1 b1 a1 r2 g2 b2 a2
 compute_color   \r1, \r2, q8,  q9
 compute_color   \g1, \g2, q10, q11
 compute_color   \b1, \b2, q12, q13
@@ -176,19 +176,19 @@ function ff_\ifmt\()_to_\ofmt\()_neon, export=1
 vmul.s16q15, q7@ q15 = 
(srcY - y_offset) * y_coeff (right)
 
 .ifc \ofmt,argb
-compute_rgbad7, d11, d8, d12, d9, d13, d6, d10
+compute_rgbad7, d8, d9, d6, d11, d12, d13, d10
 .endif
 
 .ifc \ofmt,rgba
-compute_rgbad6, d10, d7, d11, d8, d12, d9, d13
+compute_rgbad6, d7, d8, d9, d10, d11, d12, d13
 .endif
 
 .ifc \ofmt,abgr
-compute_rgbad9, d13, d8, d12, d7, d11, d6, d10
+compute_rgbad9, d8, d7, d6, d13, d12, d11, d10
 .endif
 
 .ifc \ofmt,bgra
-compute_rgbad8, d12, d7, d11, d6, d10, d9, d13
+compute_rgbad8, d7, d6, d9, d12, d11, d10, d13
 .endif
 
 vst4.8  {q3, q4}, [r2,:128]!
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 02/10] swscale/arm/yuv2rgb: fix comments and factorize lsl in load_args_yuv422p

[Matthieu Bouron]

From: Matthieu Bouron 

---
 libswscale/arm/yuv2rgb_neon.S | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index f40327b..aac0773 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -172,11 +172,10 @@
 vdup.16 d0, r10@ d0  = 
y_coeff
 vld1.16 {d1}, [r8] @ d1  = 
*table
 add r11, r2, r3@ r11 = 
dst + linesize (dst2)
-lsl r8, r0, #2
-sub r3, r3, r8 @ r3 = 
linesize  * 2 - width * 4 (padding)
-sub r5, r5, r0 @ r5 = 
linesizeY * 2 - width (paddingY)
-sub r7, r7, r0, lsr #1 @ r7 = 
linesizeU - width / 2 (paddingU)
-sub r12,r12,r0, lsr #1 @ r12 = 
linesizeV- width / 2 (paddingV)
+sub r3, r3, r0, lsl #2 @ r3  = 
linesize  - width * 4 (padding)
+sub r5, r5, r0 @ r5  = 
linesizeY - width (paddingY)
+sub r7, r7, r0, lsr #1 @ r7  = 
linesizeU - width / 2 (paddingU)
+sub r12,r12,r0, lsr #1 @ r12 = 
linesizeV - width / 2 (paddingV)
 ldr r10,[sp, #120] @ r10 = 
srcV
 .endm
 
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 05/10] swscale/arm/yuv2rgb: factorize lsl in load_args_nvx

[Matthieu Bouron]

From: Matthieu Bouron 

---
 libswscale/arm/yuv2rgb_neon.S | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index 4601a79..ef7b0a6 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -131,8 +131,7 @@
 add r12, r4, r5@ r12 = 
srcY + linesizeY (srcY2)
 lsl r3, r3, #1
 lsl r5, r5, #1
-lsl r8, r0, #2
-sub r3, r3, r8 @ r3 = 
linesize  * 2 - width * 4 (padding)
+sub r3, r3, r0, lsl #2 @ r3 = 
linesize  * 2 - width * 4 (padding)
 sub r5, r5, r0 @ r5 = 
linesizeY * 2 - width (paddingY)
 sub r7, r7, r0 @ r7 = 
linesizeC - width (paddingC)
 .endm
-- 
2.7.4

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

[FFmpeg-devel] swscale/arm/yuv2rgb: make the code bitexact with its aarch64 counter part

[Matthieu Bouron]

The following patchset aims to make bitexact the yuv->rgba armv7 neon code path
with the aarch64 one. It also aims to make the two code bases as close as
possible.

[PATCH 01/10] swscale/arm/yuv2rgb: remove 32bit code path

The current 32bit code path which is unused is removed.

[PATCH 06/10] swscale/arm/yuv2rgb: only process one line at a time

The code process only one line at a time for the yuv420p,nv12 and nv21 formats
with no regression in performance observed on a rpi2 (I've even observed a
slight increase of performance for the nv12 and nv21 formats).

[PATCH 10/10] swscale/arm/yuv2rgb: make the code bitexact with its

The last patch of the serie makes the code bitexact with the aarch64 version.
The increase of precision (which introduces a performance loss) is compensated
by a refactor/optimisation that saves quite a few mov,vdup and vqdmulh.

./ffmpeg_g -nostats -f lavfi -i 
testsrc2=1920x1080:d=5,format=nv12,bench=start,format=bgra,bench=stop -f null -

without patchset :
[bench @ 0x3eb6a0] t:0.020660 avg:0.020813 max:0.039399 min:0.020605

with patchset:
[bench @ 0xe5f6a0] t:0.018924 avg:0.019075 max:0.037472 min:0.018846

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

[FFmpeg-devel] [PATCH 0/4] avfilter/vf_colormatrix: add UHD support

[Thomas Mundt]

These patches add bt.2020 colorspace and 10 and 12 bit depth support.
The calculation of the Y component is simplified but with identical results.
Some unused variables are removed.
The YUV croma coefficients are calculated instead of taken from a rough rounded 
table.
Since these calculations happen only once the increased precision is worth it.
Please comment.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/4] avfilter/vf_colormatrix: clean up and simplify calculations

[Thomas Mundt]

Signed-off-by: Thomas Mundt 
---
 libavfilter/vf_colormatrix.c | 49 +++-
 1 file changed, 21 insertions(+), 28 deletions(-)

diff --git a/libavfilter/vf_colormatrix.c b/libavfilter/vf_colormatrix.c
index 6840b91..5fe9ce3 100644
--- a/libavfilter/vf_colormatrix.c
+++ b/libavfilter/vf_colormatrix.c
@@ -38,7 +38,6 @@
 #include "libavutil/avstring.h"
 
 #define NS(n) ((n) < 0 ? (int)((n)*65536.0-0.5+DBL_EPSILON) : 
(int)((n)*65536.0+0.5))
-#define CB(n) av_clip_uint8(n)
 
 static const double yuv_coeff_luma[5][3] = { 
 { +0.7152, +0.0722, +0.2126 }, // Rec.709 (0)
@@ -61,10 +60,8 @@ enum ColorMode {
 typedef struct {
 const AVClass *class;
 int yuv_convert[25][3][3];
-int interlaced;
 int source, dest;///< ColorMode
 int mode;
-int hsub, vsub;
 } ColorMatrixContext;
 
 typedef struct ThreadData {
@@ -227,11 +224,11 @@ static int process_slice_uyvy422(AVFilterContext *ctx, 
void *arg, int jobnr, int
 for (x = 0; x < width; x += 4) {
 const int u = srcp[x + 0] - 128;
 const int v = srcp[x + 2] - 128;
-const int uvval = c2 * u + c3 * v + 1081344;
-dstp[x + 0] = CB((c4 * u + c5 * v + 8421376) >> 16);
-dstp[x + 1] = CB((65536 * (srcp[x + 1] - 16) + uvval) >> 16);
-dstp[x + 2] = CB((c6 * u + c7 * v + 8421376) >> 16);
-dstp[x + 3] = CB((65536 * (srcp[x + 3] - 16) + uvval) >> 16);
+const int uvval = (c2 * u + c3 * v + 32768) >> 16;
+dstp[x + 0] = av_clip_uint8((c4 * u + c5 * v + 8421376) >> 16);
+dstp[x + 1] = av_clip_uint8(srcp[x + 1] + uvval);
+dstp[x + 2] = av_clip_uint8((c6 * u + c7 * v + 8421376) >> 16);
+dstp[x + 3] = av_clip_uint8(srcp[x + 3] + uvval);
 }
 srcp += src_pitch;
 dstp += dst_pitch;
@@ -271,10 +268,10 @@ static int process_slice_yuv444p(AVFilterContext *ctx, 
void *arg, int jobnr, int
 for (x = 0; x < width; x++) {
 const int u = srcpU[x] - 128;
 const int v = srcpV[x] - 128;
-const int uvval = c2 * u + c3 * v + 1081344;
-dstpY[x] = CB((65536 * (srcpY[x] - 16) + uvval) >> 16);
-dstpU[x] = CB((c4 * u + c5 * v + 8421376) >> 16);
-dstpV[x] = CB((c6 * u + c7 * v + 8421376) >> 16);
+const int uvval = (c2 * u + c3 * v + 32768) >> 16;
+dstpY[x] = av_clip_uint8(srcpY[x] + uvval);
+dstpU[x] = av_clip_uint8((c4 * u + c5 * v + 8421376) >> 16);
+dstpV[x] = av_clip_uint8((c6 * u + c7 * v + 8421376) >> 16);
 }
 srcpY += src_pitchY;
 dstpY += dst_pitchY;
@@ -318,11 +315,11 @@ static int process_slice_yuv422p(AVFilterContext *ctx, 
void *arg, int jobnr, int
 for (x = 0; x < width; x += 2) {
 const int u = srcpU[x >> 1] - 128;
 const int v = srcpV[x >> 1] - 128;
-const int uvval = c2 * u + c3 * v + 1081344;
-dstpY[x + 0] = CB((65536 * (srcpY[x + 0] - 16) + uvval) >> 16);
-dstpY[x + 1] = CB((65536 * (srcpY[x + 1] - 16) + uvval) >> 16);
-dstpU[x >> 1] = CB((c4 * u + c5 * v + 8421376) >> 16);
-dstpV[x >> 1] = CB((c6 * u + c7 * v + 8421376) >> 16);
+const int uvval = (c2 * u + c3 * v + 32768) >> 16;
+dstpY[x + 0] = av_clip_uint8(srcpY[x + 0] + uvval);
+dstpY[x + 1] = av_clip_uint8(srcpY[x + 1] + uvval);
+dstpU[x >> 1] = av_clip_uint8((c4 * u + c5 * v + 8421376) >> 16);
+dstpV[x >> 1] = av_clip_uint8((c6 * u + c7 * v + 8421376) >> 16);
 }
 srcpY += src_pitchY;
 dstpY += dst_pitchY;
@@ -368,13 +365,13 @@ static int process_slice_yuv420p(AVFilterContext *ctx, 
void *arg, int jobnr, int
 for (x = 0; x < width; x += 2) {
 const int u = srcpU[x >> 1] - 128;
 const int v = srcpV[x >> 1] - 128;
-const int uvval = c2 * u + c3 * v + 1081344;
-dstpY[x + 0] = CB((65536 * (srcpY[x + 0] - 16) + uvval) >> 16);
-dstpY[x + 1] = CB((65536 * (srcpY[x + 1] - 16) + uvval) >> 16);
-dstpN[x + 0] = CB((65536 * (srcpN[x + 0] - 16) + uvval) >> 16);
-dstpN[x + 1] = CB((65536 * (srcpN[x + 1] - 16) + uvval) >> 16);
-dstpU[x >> 1] = CB((c4 * u + c5 * v + 8421376) >> 16);
-dstpV[x >> 1] = CB((c6 * u + c7 * v + 8421376) >> 16);
+const int uvval = (c2 * u + c3 * v + 32768) >> 16;
+dstpY[x + 0] = av_clip_uint8(srcpY[x + 0] + uvval);
+dstpY[x + 1] = av_clip_uint8(srcpY[x + 1] + uvval);
+dstpN[x + 0] = av_clip_uint8(srcpN[x + 0] + uvval);
+dstpN[x + 1] = av_clip_uint8(srcpN[x + 1] + uvval);
+dstpU[x >> 1] = av_clip_uint8((c4 * u + c5 * v + 8421376) >> 16);
+dstpV[x >> 1] = av_clip_uint8((c6 * u + c7 * v + 8421376) >> 16);
 }
 srcpY += src_pitchY << 1;
 

[FFmpeg-devel] [PATCH 4/4] avfilter/vf_colormatrix: add 10 & 12 bit depth support

[Thomas Mundt]

Signed-off-by: Thomas Mundt 
---
 libavfilter/vf_colormatrix.c | 182 ++-
 1 file changed, 179 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_colormatrix.c b/libavfilter/vf_colormatrix.c
index 5fe9ce3..92224b6 100644
--- a/libavfilter/vf_colormatrix.c
+++ b/libavfilter/vf_colormatrix.c
@@ -59,6 +59,7 @@ enum ColorMode {
 
 typedef struct {
 const AVClass *class;
+const AVPixFmtDescriptor *csp;
 int yuv_convert[25][3][3];
 int source, dest;///< ColorMode
 int mode;
@@ -386,11 +387,177 @@ static int process_slice_yuv420p(AVFilterContext *ctx, 
void *arg, int jobnr, int
 return 0;
 }
 
+static int process_slice_yuv444p_16bit(AVFilterContext *ctx, void *arg, int 
jobnr, int nb_jobs)
+{
+const ThreadData *td = arg;
+const AVFrame *src = td->src;
+AVFrame *dst = td->dst;
+ColorMatrixContext *color = ctx->priv;
+const int numbits = 1 << color->csp->comp[0].depth;
+const int height = src->height;
+const int width = src->width;
+const int slice_start = (height *  jobnr   ) / nb_jobs;
+const int slice_end   = (height * (jobnr+1)) / nb_jobs;
+const int src_pitchY  = src->linesize[0] / 2;
+const int src_pitchUV = src->linesize[1] / 2;
+const uint16_t *srcpU = (const uint16_t *)src->data[1] + slice_start * 
src_pitchUV;
+const uint16_t *srcpV = (const uint16_t *)src->data[2] + slice_start * 
src_pitchUV;
+const uint16_t *srcpY = (const uint16_t *)src->data[0] + slice_start * 
src_pitchY;
+const int dst_pitchY  = dst->linesize[0] / 2;
+const int dst_pitchUV = dst->linesize[1] / 2;
+uint16_t *dstpU = (uint16_t *)dst->data[1] + slice_start * dst_pitchUV;
+uint16_t *dstpV = (uint16_t *)dst->data[2] + slice_start * dst_pitchUV;
+uint16_t *dstpY = (uint16_t *)dst->data[0] + slice_start * dst_pitchY;
+const int c2 = td->c2;
+const int c3 = td->c3;
+const int c4 = td->c4;
+const int c5 = td->c5;
+const int c6 = td->c6;
+const int c7 = td->c7;
+const int cin_shift  = numbits >> 1;
+const int cout_shift = (numbits + 1) << 15;
+const int clip_max   = numbits - 1;
+int x, y;
+
+for (y = slice_start; y < slice_end; y++) {
+for (x = 0; x < width; x++) {
+const int u = srcpU[x] - cin_shift;
+const int v = srcpV[x] - cin_shift;
+const int uvval = (c2 * u + c3 * v + 32768) >> 16;
+dstpY[x] = av_clip(srcpY[x] + uvval, 0, clip_max);
+dstpU[x] = av_clip((c4 * u + c5 * v + cout_shift) >> 16, 0, 
clip_max);
+dstpV[x] = av_clip((c6 * u + c7 * v + cout_shift) >> 16, 0, 
clip_max);
+}
+srcpY += src_pitchY;
+dstpY += dst_pitchY;
+srcpU += src_pitchUV;
+srcpV += src_pitchUV;
+dstpU += dst_pitchUV;
+dstpV += dst_pitchUV;
+}
+
+return 0;
+}
+
+static int process_slice_yuv422p_16bit(AVFilterContext *ctx, void *arg, int 
jobnr, int nb_jobs)
+{
+const ThreadData *td = arg;
+const AVFrame *src = td->src;
+AVFrame *dst = td->dst;
+ColorMatrixContext *color = ctx->priv;
+const int numbits = 1 << color->csp->comp[0].depth;
+const int height = src->height;
+const int width = src->width;
+const int slice_start = (height *  jobnr   ) / nb_jobs;
+const int slice_end   = (height * (jobnr+1)) / nb_jobs;
+const int src_pitchY  = src->linesize[0] / 2;
+const int src_pitchUV = src->linesize[1] / 2;
+const uint16_t *srcpU = (const uint16_t *)src->data[1] + slice_start * 
src_pitchUV;
+const uint16_t *srcpV = (const uint16_t *)src->data[2] + slice_start * 
src_pitchUV;
+const uint16_t *srcpY = (const uint16_t *)src->data[0] + slice_start * 
src_pitchY;
+const int dst_pitchY  = dst->linesize[0] / 2;
+const int dst_pitchUV = dst->linesize[1] / 2;
+uint16_t *dstpU = (uint16_t *)dst->data[1] + slice_start * dst_pitchUV;
+uint16_t *dstpV = (uint16_t *)dst->data[2] + slice_start * dst_pitchUV;
+uint16_t *dstpY = (uint16_t *)dst->data[0] + slice_start * dst_pitchY;
+const int c2 = td->c2;
+const int c3 = td->c3;
+const int c4 = td->c4;
+const int c5 = td->c5;
+const int c6 = td->c6;
+const int c7 = td->c7;
+const int cin_shift  = numbits >> 1;
+const int cout_shift = (numbits + 1) << 15;
+const int clip_max   = numbits - 1;
+int x, y;
+
+for (y = slice_start; y < slice_end; y++) {
+for (x = 0; x < width; x += 2) {
+const int u = srcpU[x >> 1] - cin_shift;
+const int v = srcpV[x >> 1] - cin_shift;
+const int uvval = (c2 * u + c3 * v + 32768) >> 16;
+dstpY[x + 0] = av_clip(srcpY[x + 0] + uvval, 0, clip_max);
+dstpY[x + 1] = av_clip(srcpY[x + 1] + uvval, 0, clip_max);
+dstpU[x >> 1] = av_clip((c4 * u + c5 * v + cout_shift) >> 16, 0, 
clip_max);
+dstpV[x >> 1] = av_clip((c6 * u + c7 * v + cout_shift) >> 16, 

[FFmpeg-devel] [PATCH 2/4] avfilter/vf_colormatrix: add bt.2020 colorspace

[Thomas Mundt]

Signed-off-by: Thomas Mundt 
---
 doc/filters.texi |  3 +++
 libavfilter/vf_colormatrix.c | 38 ++
 2 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 528e0f8..a438f6d 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4880,6 +4880,9 @@ SMPTE-240M
 
 @item fcc
 FCC
+
+@item bt2020
+BT.2020
 @end table
 @end table
 
diff --git a/libavfilter/vf_colormatrix.c b/libavfilter/vf_colormatrix.c
index ecd7a97..6840b91 100644
--- a/libavfilter/vf_colormatrix.c
+++ b/libavfilter/vf_colormatrix.c
@@ -40,11 +40,12 @@
 #define NS(n) ((n) < 0 ? (int)((n)*65536.0-0.5+DBL_EPSILON) : 
(int)((n)*65536.0+0.5))
 #define CB(n) av_clip_uint8(n)
 
-static const double yuv_coeff_luma[4][3] = { 
+static const double yuv_coeff_luma[5][3] = { 
 { +0.7152, +0.0722, +0.2126 }, // Rec.709 (0)
 { +0.5900, +0.1100, +0.3000 }, // FCC (1)
 { +0.5870, +0.1140, +0.2990 }, // Rec.601 (ITU-R BT.470-2/SMPTE 170M) (2)
 { +0.7010, +0.0870, +0.2120 }, // SMPTE 240M (3)
+{ +0.6780, +0.0593, +0.2627 }, // Rec.2020 (4)
 };
 
 enum ColorMode {
@@ -53,12 +54,13 @@ enum ColorMode {
 COLOR_MODE_FCC,
 COLOR_MODE_BT601,
 COLOR_MODE_SMPTE240M,
+COLOR_MODE_BT2020,
 COLOR_MODE_COUNT
 };
 
 typedef struct {
 const AVClass *class;
-int yuv_convert[16][3][3];
+int yuv_convert[25][3][3];
 int interlaced;
 int source, dest;///< ColorMode
 int mode;
@@ -89,6 +91,7 @@ static const AVOption colormatrix_options[] = {
 { "bt470bg",   "set BT.470 colorspace",  0, AV_OPT_TYPE_CONST, 
{.i64=COLOR_MODE_BT601},   .flags=FLAGS, .unit="color_mode" },
 { "smpte170m", "set SMTPE-170M colorspace",  0, AV_OPT_TYPE_CONST, 
{.i64=COLOR_MODE_BT601},   .flags=FLAGS, .unit="color_mode" },
 { "smpte240m", "set SMPTE-240M colorspace",  0, AV_OPT_TYPE_CONST, 
{.i64=COLOR_MODE_SMPTE240M},   .flags=FLAGS, .unit="color_mode" },
+{ "bt2020","set BT.2020 colorspace", 0, AV_OPT_TYPE_CONST, 
{.i64=COLOR_MODE_BT2020},  .flags=FLAGS, .unit="color_mode" },
 { NULL }
 };
 
@@ -140,13 +143,13 @@ static void solve_coefficients(double cm[3][3], double 
rgb[3][3], const double y
 static void calc_coefficients(AVFilterContext *ctx)
 {
 ColorMatrixContext *color = ctx->priv;
-double yuv_coeff[4][3][3];
-double rgb_coeffd[4][3][3];
-double yuv_convertd[16][3][3];
+double yuv_coeff[5][3][3];
+double rgb_coeffd[5][3][3];
+double yuv_convertd[25][3][3];
 double bscale, rscale;
 int v = 0;
 int i, j, k;
-for (i = 0; i < 4; i++) {
+for (i = 0; i < 5; i++) {
 yuv_coeff[i][0][0] = yuv_coeff_luma[i][0];
 yuv_coeff[i][0][1] = yuv_coeff_luma[i][1];
 yuv_coeff[i][0][2] = yuv_coeff_luma[i][2];
@@ -159,10 +162,10 @@ static void calc_coefficients(AVFilterContext *ctx)
 yuv_coeff[i][2][1] = rscale * yuv_coeff[i][0][1];
 yuv_coeff[i][2][2] = 0.5;
 }
-for (i = 0; i < 4; i++)
+for (i = 0; i < 5; i++)
 inverse3x3(rgb_coeffd[i], yuv_coeff[i]);
-for (i = 0; i < 4; i++) {
-for (j = 0; j < 4; j++) {
+for (i = 0; i < 5; i++) {
+for (j = 0; j < 5; j++) {
 solve_coefficients(yuv_convertd[v], rgb_coeffd[i], yuv_coeff[j]);
 for (k = 0; k < 3; k++) {
 color->yuv_convert[v][k][0] = NS(yuv_convertd[v][k][0]);
@@ -178,7 +181,7 @@ static void calc_coefficients(AVFilterContext *ctx)
 }
 }
 
-static const char * const color_modes[] = {"bt709", "fcc", "bt601", 
"smpte240m"};
+static const char * const color_modes[] = {"bt709", "fcc", "bt601", 
"smpte240m", "bt2020"};
 
 static av_cold int init(AVFilterContext *ctx)
 {
@@ -441,20 +444,23 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 case AVCOL_SPC_SMPTE240M : source = COLOR_MODE_SMPTE240M ; break;
 case AVCOL_SPC_BT470BG   : source = COLOR_MODE_BT601 ; break;
 case AVCOL_SPC_SMPTE170M : source = COLOR_MODE_BT601 ; break;
+case AVCOL_SPC_BT2020_NCL: source = COLOR_MODE_BT2020; break;
+case AVCOL_SPC_BT2020_CL : source = COLOR_MODE_BT2020; break;
 default :
 av_log(ctx, AV_LOG_ERROR, "Input frame does not specify a 
supported colorspace, and none has been specified as source either\n");
 av_frame_free();
 return AVERROR(EINVAL);
 }
-color->mode = source * 4 + color->dest;
+color->mode = source * 5 + color->dest;
 } else
-color->mode = color->source * 4 + color->dest;
+color->mode = color->source * 5 + color->dest;
 
 switch(color->dest) {
-case COLOR_MODE_BT709: av_frame_set_colorspace(out, AVCOL_SPC_BT709)   
 ; break;
-case COLOR_MODE_FCC  : av_frame_set_colorspace(out, AVCOL_SPC_FCC) 
 ; break;
-case COLOR_MODE_SMPTE240M: av_frame_set_colorspace(out, 
AVCOL_SPC_SMPTE240M); break;
-case 

[FFmpeg-devel] [PATCH 1/4] avfilter/vf_colormatrix: increase precision

[Thomas Mundt]

Signed-off-by: Thomas Mundt 
---
 libavfilter/vf_colormatrix.c | 34 --
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/libavfilter/vf_colormatrix.c b/libavfilter/vf_colormatrix.c
index 4a57fe0..ecd7a97 100644
--- a/libavfilter/vf_colormatrix.c
+++ b/libavfilter/vf_colormatrix.c
@@ -40,19 +40,11 @@
 #define NS(n) ((n) < 0 ? (int)((n)*65536.0-0.5+DBL_EPSILON) : 
(int)((n)*65536.0+0.5))
 #define CB(n) av_clip_uint8(n)
 
-static const double yuv_coeff[4][3][3] = {
-{ { +0.7152, +0.0722, +0.2126 }, // Rec.709 (0)
-  { -0.3850, +0.5000, -0.1150 },
-  { -0.4540, -0.0460, +0.5000 } },
-{ { +0.5900, +0.1100, +0.3000 }, // FCC (1)
-  { -0.3310, +0.5000, -0.1690 },
-  { -0.4210, -0.0790, +0.5000 } },
-{ { +0.5870, +0.1140, +0.2990 }, // Rec.601 (ITU-R BT.470-2/SMPTE 170M) (2)
-  { -0.3313, +0.5000, -0.1687 },
-  { -0.4187, -0.0813, +0.5000 } },
-{ { +0.7010, +0.0870, +0.2120 }, // SMPTE 240M (3)
-  { -0.3840, +0.5000, -0.1160 },
-  { -0.4450, -0.0550, +0.5000 } },
+static const double yuv_coeff_luma[4][3] = { 
+{ +0.7152, +0.0722, +0.2126 }, // Rec.709 (0)
+{ +0.5900, +0.1100, +0.3000 }, // FCC (1)
+{ +0.5870, +0.1140, +0.2990 }, // Rec.601 (ITU-R BT.470-2/SMPTE 170M) (2)
+{ +0.7010, +0.0870, +0.2120 }, // SMPTE 240M (3)
 };
 
 enum ColorMode {
@@ -148,11 +140,25 @@ static void solve_coefficients(double cm[3][3], double 
rgb[3][3], const double y
 static void calc_coefficients(AVFilterContext *ctx)
 {
 ColorMatrixContext *color = ctx->priv;
+double yuv_coeff[4][3][3];
 double rgb_coeffd[4][3][3];
 double yuv_convertd[16][3][3];
+double bscale, rscale;
 int v = 0;
 int i, j, k;
-
+for (i = 0; i < 4; i++) {
+yuv_coeff[i][0][0] = yuv_coeff_luma[i][0];
+yuv_coeff[i][0][1] = yuv_coeff_luma[i][1];
+yuv_coeff[i][0][2] = yuv_coeff_luma[i][2];
+bscale = 0.5 / (yuv_coeff[i][0][1] - 1.0);
+rscale = 0.5 / (yuv_coeff[i][0][2] - 1.0);
+yuv_coeff[i][1][0] = bscale * yuv_coeff[i][0][0];
+yuv_coeff[i][1][1] = 0.5;
+yuv_coeff[i][1][2] = bscale * yuv_coeff[i][0][2];
+yuv_coeff[i][2][0] = rscale * yuv_coeff[i][0][0];
+yuv_coeff[i][2][1] = rscale * yuv_coeff[i][0][1];
+yuv_coeff[i][2][2] = 0.5;
+}
 for (i = 0; i < 4; i++)
 inverse3x3(rgb_coeffd[i], yuv_coeff[i]);
 for (i = 0; i < 4; i++) {
-- 
2.7.4.windows.1


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

Re: [FFmpeg-devel] [WIP] GSoC P frame support for FFV1 codec

[Michael Niedermayer]

On Fri, Mar 25, 2016 at 09:38:37PM +0300, Станислав Долганов wrote:
> New formula for residual calculation, which reduced compressed sized
> significantly, but it is still a bit larger then in case if all frames are
> I. I think it because of coder context changes to much from I frame pixel
> value to P ones.
> 
> Also more fate test references were generated.

fails with threads

make -j12 `make fate-list | grep ffv1` THREADS=2

*** glibc detected *** ffmpeg/ffmpeg: double free or corruption (!prev): 
0x035d22c0 ***
*** glibc detected *** ffmpeg/ffmpeg: corrupted double-linked list: 
0x02cfdec0 ***
--- ./tests/ref/vsynth/vsynth1-ffv1 2016-03-25 21:39:42.883500361 +0100
+++ tests/data/fate/vsynth1-ffv12016-03-25 23:09:15.935613556 +0100
@@ -1,4 +1,2 @@
 04297f9a747548818ceed86edf356957 *tests/data/fate/vsynth1-ffv1.avi
 3288706 tests/data/fate/vsynth1-ffv1.avi
-c5ccac874dbf808e9088bc3107860042 *tests/data/fate/vsynth1-ffv1.out.rawvideo
-stddev:0.00 PSNR:999.99 MAXDIFF:0 bytes:  7603200/  7603200
*** glibc detected *** ffmpeg/ffmpeg: corrupted double-linked list: 
0x02e7d300 ***
Test vsynth1-ffv1 failed. Look at tests/data/fate/vsynth1-ffv1.err for details.
make: *** [fate-vsynth1-ffv1] Error 139
make: *** Waiting for unfinished jobs
*** glibc detected *** ffmpeg/ffmpeg: corrupted double-linked list: 
0x03ae2820 ***
*** glibc detected *** ffmpeg/ffmpeg: corrupted double-linked list: 
0x02453480 ***
*** glibc detected *** ffmpeg/ffmpeg: corrupted double-linked list: 
0x02704580 ***

[...]

-- 
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] avcodec: Remove libdcadec, we already have it merged internally

[Moritz Barsnick]

On Fri, Mar 25, 2016 at 21:34:45 +, Kieran Kunhya wrote:
> +- libfaac removed

Well, this is most certainly a typo. ;-)

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

[FFmpeg-devel] [PATCH] avcodec: Remove libdcadec, we already have it merged internally

[Kieran Kunhya]

---
 Changelog  |   2 +-
 configure  |   4 -
 libavcodec/Makefile|   1 -
 libavcodec/allcodecs.c |   1 -
 libavcodec/libdcadec.c | 311 -
 libavcodec/version.h   |   2 +-
 6 files changed, 2 insertions(+), 319 deletions(-)
 delete mode 100644 libavcodec/libdcadec.c

diff --git a/Changelog b/Changelog
index aaf4c96..3dd49f7 100644
--- a/Changelog
+++ b/Changelog
@@ -16,7 +16,7 @@ version :
 - AudioToolbox audio decoders
 - AudioToolbox audio encoders
 - coreimage filter (GPU based image filtering on OSX)
-
+- libfaac removed
 
 version 3.0:
 - Common Encryption (CENC) MP4 encoding and decoding support
diff --git a/configure b/configure
index feb0bc2..5aa8c1f 100755
--- a/configure
+++ b/configure
@@ -219,7 +219,6 @@ External library support:
   --enable-libcdio enable audio CD grabbing with libcdio [no]
   --enable-libdc1394   enable IIDC-1394 grabbing using libdc1394
and libraw1394 [no]
-  --enable-libdcadec   enable DCA decoding via libdcadec [no]
   --enable-libfaac enable AAC encoding via libfaac [no]
   --enable-libfdk-aac  enable AAC de/encoding via libfdk-aac [no]
   --enable-libfliteenable flite (voice synthesis) support via libflite 
[no]
@@ -1468,7 +1467,6 @@ EXTERNAL_LIBRARY_LIST="
 libcdio
 libcelt
 libdc1394
-libdcadec
 libfaac
 libfdk_aac
 libflite
@@ -2674,7 +2672,6 @@ pcm_mulaw_at_encoder_select="audio_frame_queue"
 chromaprint_muxer_deps="chromaprint"
 h264_videotoolbox_encoder_deps="videotoolbox_encoder pthreads"
 libcelt_decoder_deps="libcelt"
-libdcadec_decoder_deps="libdcadec"
 libfaac_encoder_deps="libfaac"
 libfaac_encoder_select="audio_frame_queue"
 libfdk_aac_decoder_deps="libfdk_aac"
@@ -5535,7 +5532,6 @@ enabled libcelt   && require libcelt celt/celt.h 
celt_decode -lcelt0 &&
  { check_lib celt/celt.h 
celt_decoder_create_custom -lcelt0 ||
die "ERROR: libcelt must be installed and 
version must be >= 0.11.0."; }
 enabled libcaca   && require_pkg_config caca caca.h caca_create_canvas
-enabled libdcadec && require_pkg_config "dcadec >= 0.1.0" 
libdcadec/dca_context.h dcadec_context_create
 enabled libfaac   && require2 libfaac "stdint.h faac.h" 
faacEncGetVersion -lfaac
 enabled libfdk_aac&& { use_pkg_config fdk-aac "fdk-aac/aacenc_lib.h" 
aacEncOpen ||
{ require libfdk_aac fdk-aac/aacenc_lib.h 
aacEncOpen -lfdk-aac &&
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index ef9eb98..b926b79 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -821,7 +821,6 @@ OBJS-$(CONFIG_ILBC_AT_ENCODER)+= 
audiotoolboxenc.o
 OBJS-$(CONFIG_PCM_ALAW_AT_ENCODER)+= audiotoolboxenc.o
 OBJS-$(CONFIG_PCM_MULAW_AT_ENCODER)   += audiotoolboxenc.o
 OBJS-$(CONFIG_LIBCELT_DECODER)+= libcelt_dec.o
-OBJS-$(CONFIG_LIBDCADEC_DECODER)  += libdcadec.o dca.o
 OBJS-$(CONFIG_LIBFAAC_ENCODER)+= libfaac.o
 OBJS-$(CONFIG_LIBFDK_AAC_DECODER) += libfdk-aacdec.o
 OBJS-$(CONFIG_LIBFDK_AAC_ENCODER) += libfdk-aacenc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index a953a16..e3c4f07 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -578,7 +578,6 @@ void avcodec_register_all(void)
 REGISTER_DECODER(QDMC_AT,   qdmc_at);
 REGISTER_DECODER(QDM2_AT,   qdm2_at);
 REGISTER_DECODER(LIBCELT,   libcelt);
-REGISTER_DECODER(LIBDCADEC, libdcadec)
 REGISTER_ENCODER(LIBFAAC,   libfaac);
 REGISTER_ENCDEC (LIBFDK_AAC,libfdk_aac);
 REGISTER_ENCDEC (LIBGSM,libgsm);
diff --git a/libavcodec/libdcadec.c b/libavcodec/libdcadec.c
deleted file mode 100644
index 7d1f931..000
--- a/libavcodec/libdcadec.c
+++ /dev/null
@@ -1,311 +0,0 @@
-/*
- * libdcadec decoder wrapper
- * Copyright (C) 2015 Hendrik Leppkes
- *
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * FFmpeg is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with FFmpeg; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
- */
-
-#include 
-
-#include "libavutil/channel_layout.h"
-#include "libavutil/common.h"
-#include "libavutil/opt.h"
-
-#include "avcodec.h"
-#include "dca.h"
-#include 

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Hendrik Leppkes]

On Fri, Mar 25, 2016 at 7:41 PM, Thilo Borgmann  wrote:
> Am 25.03.16 um 18:48 schrieb Hendrik Leppkes:
>> On Fri, Mar 25, 2016 at 6:26 PM, Thilo Borgmann  
>> wrote:
>>> Am 25.03.16 um 17:56 schrieb Hendrik Leppkes:
 On Fri, Mar 25, 2016 at 5:48 PM, Thilo Borgmann  
 wrote:
> Am 22.03.16 um 12:20 schrieb Thilo Borgmann:
>> Am 22.03.16 um 11:45 schrieb wm4:
>>> On Sun, 13 Mar 2016 21:00:23 +0100
>>> Thilo Borgmann  wrote:
>>>
 Am 13.03.16 um 15:08 schrieb wm4:
> On Sat, 12 Mar 2016 15:13:21 +0100
> Thilo Borgmann  wrote:
>
>> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 
>> 2001
>> From: Thilo Borgmann 
>> Date: Sat, 12 Mar 2016 14:52:17 +0100
>> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal 
>> keys.
>> [...]
>
> Changing the semantics of AVDictionary just like this seems rather
> questionable...

 It changes nothing for existing code, just adds a new feature. I don't
 think it hurts anyone or anything...
>>>
>>> It only breaks basic assumptions about a basic data type...
>>
>> Although I don't share your thought about breaking a basic data type 
>> with that,
>> what would you suggest instead?
>
> Pushed for no further suggestions and nobody else objected.
>

 Just pushing without addressing concerns is not the way we usually try
 to work here, just saying.
>>>
>>> I think I have quite a good idea about the usual way we try to handle
>>> things here and I think I've addressed his concerns.
>>
>> If by addressing you mean disagreeing with the concern and doing nothing.
>
> Not at all. I proposed alternatives (alternatives which I don't like
> much but anyway) and I explicitly asked for his suggestions. Means, I
> actually tried to satisfy his concerns. Thus, I can't understand that
> you are saying I've ignored anything.
>
>
>>> He didn't like it which is of course ok. He did not continue discussing
>>> it nor did he proposed any alternative. He also did not pick up any of
>>> my thoughts. He also did not explicitly state that he thinks that it is
>>> not ok to apply it. He said it "seems rather questionable". Without
>>> further discussion (what I tried) and nobody else complaining about it,
>>> what do you think would be more appropriate than to wait for quite a
>>> long time until continuing?
>>>
>>> The usual way for him to prevent me pushing it would just have been to
>>> ask me to wait and I would have waited. Have you checked the dates of
>>> the replies and what I wrote before accusing me to just ignore concerns?
>>>
>>
>> Timing makes no difference. Its the only review you got, so even if
>> you ignore that, you didn't even get a "OK" from anyone else, which
>> for generic API should be mandatory.
>
> I can't see why you accuse me ignoring something again.

I didn't, I just stated that noone ever OKed your patch.

>
>
>> The least that would have been appropriate would be to ping the patch
>> asking for further comments, instead of just practically saying "I'm
>> done waiting and just pushing"
>>
>> Not everyone has the time to answer within a day, so if someone
>> expressed a concern, the least one could do before pushing is asking
>> again, everything else feels rather disingenuous.
>
> First concern about this was stated on 13th.
> After my reply, there was silence for nine days.
> What would have been your assumption about his concerns after my reply?
> Mine was that he considers this not to be as critical enough for further
> discussion - means he might still dislike having multikey dictionaries
> but sees no reason in struggling about it.

I wouldn't make assumptions, I would explicitly ask.

>
> I pinged the patch again on 22nd, and it took about one minute for wm4
> to address his concerns again. However, after me asking for his
> suggestions there was again silence for days. Also note that he did not
> stated his concerns more specifically than before.
>
> So I waiting for around 12 days (including a ping) to get a more
> specific remark, counter-proposal, discussion or anything else than a
> basic concern. During that time wm4 was active and very well capable of
> immediate reply. Thus I assume that his attitude about this patch is not
> as bad as insisting not to apply.
>
> I still really can't see a "I'm done waiting and just pushing" attitude
> from my side.
>

When you go from talking about a developers concerns to just pushing,
then how else do you think someone should feel?
Timing is your only reason to push today, you even explain yourself by
quoting dates and everything, so how can I see it as anything else?

- Hendrik
___
ffmpeg-devel 

[FFmpeg-devel] [PATCH] avfilter: add zoneplate video source filter

[Paul B Mahol]

Hi,

patch attached.
From 8429137e301ec15a8b1f3684ce2d9d6533ec95f2 Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Fri, 25 Mar 2016 20:40:29 +0100
Subject: [PATCH] avfilter: add zoneplate video source filter

Signed-off-by: Paul B Mahol 
---
 libavfilter/Makefile   |  1 +
 libavfilter/allfilters.c   |  1 +
 libavfilter/vsrc_testsrc.c | 91 ++
 3 files changed, 93 insertions(+)

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index b6e1999..6ff1575 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -295,6 +295,7 @@ OBJS-$(CONFIG_SMPTEBARS_FILTER)  += vsrc_testsrc.o
 OBJS-$(CONFIG_SMPTEHDBARS_FILTER)+= vsrc_testsrc.o
 OBJS-$(CONFIG_TESTSRC_FILTER)+= vsrc_testsrc.o
 OBJS-$(CONFIG_TESTSRC2_FILTER)   += vsrc_testsrc.o
+OBJS-$(CONFIG_ZONEPLATE_FILTER)  += vsrc_testsrc.o
 
 OBJS-$(CONFIG_NULLSINK_FILTER)   += vsink_nullsink.o
 
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 5c18fd1..597971f 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -315,6 +315,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(SMPTEHDBARS,smptehdbars,vsrc);
 REGISTER_FILTER(TESTSRC,testsrc,vsrc);
 REGISTER_FILTER(TESTSRC2,   testsrc2,   vsrc);
+REGISTER_FILTER(ZONEPLATE,  zoneplate,  vsrc);
 
 REGISTER_FILTER(NULLSINK,   nullsink,   vsink);
 
diff --git a/libavfilter/vsrc_testsrc.c b/libavfilter/vsrc_testsrc.c
index f0c0985..e5f419c 100644
--- a/libavfilter/vsrc_testsrc.c
+++ b/libavfilter/vsrc_testsrc.c
@@ -76,6 +76,11 @@ typedef struct TestSourceContext {
 
 /* only used by haldclut */
 int level;
+
+/* only used by zoneplate */
+float scale;
+float phase;
+float vmove, hmove;
 } TestSourceContext;
 
 #define OFFSET(x) offsetof(TestSourceContext, x)
@@ -1523,3 +1528,89 @@ AVFilter ff_vsrc_allrgb = {
 };
 
 #endif /* CONFIG_ALLRGB_FILTER */
+
+#if CONFIG_ZONEPLATE_FILTER
+
+static const AVOption zoneplate_options[] = {
+{ "scale", "set scale", OFFSET(scale), AV_OPT_TYPE_FLOAT, {.dbl=1}, 0, INT_MAX, FLAGS },
+{ "phase", "set phase speed",   OFFSET(phase), AV_OPT_TYPE_FLOAT, {.dbl=0}, 0, 512, FLAGS },
+{ "vmove", "set vertical move speed",   OFFSET(vmove), AV_OPT_TYPE_FLOAT, {.dbl=0}, 0, 512, FLAGS },
+{ "hmove", "set horizontal move speed", OFFSET(hmove), AV_OPT_TYPE_FLOAT, {.dbl=0}, 0, 512, FLAGS },
+COMMON_OPTIONS
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(zoneplate);
+
+static void zoneplate_fill_picture(AVFilterContext *ctx, AVFrame *frame)
+{
+TestSourceContext *test = ctx->priv;
+const float scale = test->scale;
+uint8_t *lum = frame->data[0];
+uint8_t *cb = frame->data[1];
+uint8_t *cr = frame->data[2];
+const int cy = frame->height / 2;
+const int cx = frame->width / 2;
+const int nb = test->nb_frame;
+const float phase = test->phase;
+const float vmove = test->vmove;
+const float hmove = test->hmove;
+int x, y, h, w;
+
+for (y = -cy + nb * vmove, h = 0; h < frame->height; y++, h++) {
+for (x = -cx + nb * hmove, w = 0; w < frame->width; x++, w++) {
+lum[w] = 127.5 * cos(M_PI * ((int)((x * x + y * y) * scale) & 0xFF) / 127.5 + nb * phase) + 127.5;
+cb[w] = cr[w] = 128;
+}
+lum += frame->linesize[0];
+cb  += frame->linesize[1];
+cr  += frame->linesize[2];
+}
+}
+
+static av_cold int zoneplate_init(AVFilterContext *ctx)
+{
+TestSourceContext *test = ctx->priv;
+
+if (test->phase == 0 && test->vmove == 0 && test->hmove == 0)
+test->draw_once = 1;
+test->fill_picture_fn = zoneplate_fill_picture;
+return init(ctx);
+}
+
+static int zoneplate_query_formats(AVFilterContext *ctx)
+{
+static const enum AVPixelFormat pix_fmts[] = {
+AV_PIX_FMT_YUV444P,
+AV_PIX_FMT_NONE
+};
+
+AVFilterFormats *fmts_list = ff_make_format_list(pix_fmts);
+if (!fmts_list)
+return AVERROR(ENOMEM);
+return ff_set_common_formats(ctx, fmts_list);
+}
+
+static const AVFilterPad avfilter_vsrc_zoneplate_outputs[] = {
+{
+.name  = "default",
+.type  = AVMEDIA_TYPE_VIDEO,
+.request_frame = request_frame,
+.config_props  = config_props,
+},
+{ NULL }
+};
+
+AVFilter ff_vsrc_zoneplate = {
+.name  = "zoneplate",
+.description   = NULL_IF_CONFIG_SMALL("Generate zone plate test pattern."),
+.priv_size = sizeof(TestSourceContext),
+.priv_class= _class,
+.init  = zoneplate_init,
+.uninit= uninit,
+.query_formats = zoneplate_query_formats,
+.inputs= NULL,
+.outputs   = avfilter_vsrc_zoneplate_outputs,
+};
+
+#endif /* CONFIG_ZONEPLATE_FILTER */
-- 
1.9.1

Re: [FFmpeg-devel] [PATCH 0/4] fftw exploration (WIP)

[Ronald S. Bultje]

Hi,

On Fri, Mar 25, 2016 at 3:55 PM, Ganesh Ajjanagadde 
wrote:

> On Fri, Mar 25, 2016 at 12:11 PM, Paul B Mahol  wrote:
> > On 3/25/16, Ganesh Ajjanagadde  wrote:
> >> On Fri, Mar 25, 2016 at 9:36 AM, Nicolas George 
> wrote:
> >>> Le sextidi 6 germinal, an CCXXIV, Ganesh Ajjanagadde a ecrit :
>  Depends on if it is small or not. Yes, in many codecs, FFT's are short
>  length ones, e.g 512. However, on long lengths, e.g 8192+, as seen
>  from the benches, there are sometimes 2x variations at the moment.
> >>>
> >>> And how much of the actual total decoding is spent in the FFT? Even a
> *50
> >>> speedup would be useless if it is for a function that never amounts to
> >>> more
> >>> than 0,01% of the actual time. The FFT is probably not that negligible,
> >>> but
> >>> this is not a  *50 speedup either, and I have no idea how frequent are
> long
> >>> lengths.
> >>
> >> Paul had some interest in 2^17 fft's at a point.
> >
> > And it was done in avfft. So feel free to improve our avfft instead.
>
> Just to be clear: I won't be working on improving avfft, but of course
> I won't oppose patches generally.
>
> Basically, it boils down to the current asm code being a mess


"I don't understand the code" is not the same as "the code is a mess".

The code is not a mess, it's highly optimized and you could ask the person
that wrote it (see copyright line) for details instead of loudly
complaining that you can't understand it.


> I can't even identify really what algo is being used.


Check the C code.


> If anyone cares here, I do not know why we can't use inline asm or
> intrinsics. The chief benefit of intrinsics is that the hard part (for
> humans) of register allocation/checks is taken care of, but optimized
> instructions get used in a readable fashion. Anyway, I know there are
> a ton of arguments against it in FFmpeg, almost none of which I buy in
> 2016 with modern toolchains.
>

Inline asm doesn't solve any problem you just mentioned, in fact it makes
things worse because it doesn't work on half of our supported compilers
(e.g. MSVC).

Intrinsics generally perform worse (or at the very least "inconsistent")
than the same sequence of operations written out in hand-written asm.

If you're interested in getting actual help in learning "hand-written"
assembly, let us know and we'll help you move on.

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

Re: [FFmpeg-devel] [PATCH] avcodec/jpeg2000dec: add slice threading support

[Michael Niedermayer]

On Fri, Mar 25, 2016 at 02:43:44PM +0100, Paul B Mahol wrote:
> Hi,
> 
> patch attached.

>  jpeg2000dec.c |   15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 1e3850de4232f98aa209581d0cf3baca9507fb76  
> 0001-avcodec-jpeg2000dec-add-slice-threading-support.patch
> From 695cd4e4c6845a3b6c74d15e07b36df30da2f1b8 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol 
> Date: Fri, 25 Mar 2016 14:33:15 +0100
> Subject: [PATCH] avcodec/jpeg2000dec: add slice threading support
> 
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/jpeg2000dec.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH 0/4] fftw exploration (WIP)

[James Almer]

On 3/25/2016 4:55 PM, Ganesh Ajjanagadde wrote:
> If anyone cares here, I do not know why we can't use inline asm or
> intrinsics

With Inline asm and intrinsics you're 100% dependent on the compiler
doing the right thing. The latter more so than the former.
So a function compiled with gcc 4.9 might be faster or slower than the
same function compiled with gcc 5.3, or msvc 2102, 2013, 2015, or icc,
or clang, or even ancient gcc toolchains that somehow keep being used.

Hand written asm guarantees the functions will perform exactly the same
and as optimally as the developer can write it regardless of compiler,
with the latter only handling things until the relevant function calls.

Inline asm and intrinsics are only acceptable for simple functionality
(single instructions or such) that actually make sense being inlined,
like intmath and intreadwrite functions in libavutil.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[wm4]

On Fri, 25 Mar 2016 19:41:40 +0100
Thilo Borgmann  wrote:

> Am 25.03.16 um 18:48 schrieb Hendrik Leppkes:
> > On Fri, Mar 25, 2016 at 6:26 PM, Thilo Borgmann  
> > wrote:  
> >> Am 25.03.16 um 17:56 schrieb Hendrik Leppkes:  
> >>> On Fri, Mar 25, 2016 at 5:48 PM, Thilo Borgmann  
> >>> wrote:  
>  Am 22.03.16 um 12:20 schrieb Thilo Borgmann:  
> > Am 22.03.16 um 11:45 schrieb wm4:  
> >> On Sun, 13 Mar 2016 21:00:23 +0100
> >> Thilo Borgmann  wrote:
> >>  
> >>> Am 13.03.16 um 15:08 schrieb wm4:  
>  On Sat, 12 Mar 2016 15:13:21 +0100
>  Thilo Borgmann  wrote:
>   
> > From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 
> > 2001
> > From: Thilo Borgmann 
> > Date: Sat, 12 Mar 2016 14:52:17 +0100
> > Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple 
> > equal keys.
> > [...]  
> 
>  Changing the semantics of AVDictionary just like this seems rather
>  questionable...  
> >>>
> >>> It changes nothing for existing code, just adds a new feature. I don't
> >>> think it hurts anyone or anything...  
> >>
> >> It only breaks basic assumptions about a basic data type...  
> >
> > Although I don't share your thought about breaking a basic data type 
> > with that,
> > what would you suggest instead?  
> 
>  Pushed for no further suggestions and nobody else objected.
>   
> >>>
> >>> Just pushing without addressing concerns is not the way we usually try
> >>> to work here, just saying.  
> >>
> >> I think I have quite a good idea about the usual way we try to handle
> >> things here and I think I've addressed his concerns.  
> > 
> > If by addressing you mean disagreeing with the concern and doing nothing.  
> 
> Not at all. I proposed alternatives (alternatives which I don't like
> much but anyway) and I explicitly asked for his suggestions. Means, I
> actually tried to satisfy his concerns. Thus, I can't understand that
> you are saying I've ignored anything.
> 
> 
> >> He didn't like it which is of course ok. He did not continue discussing
> >> it nor did he proposed any alternative. He also did not pick up any of
> >> my thoughts. He also did not explicitly state that he thinks that it is
> >> not ok to apply it. He said it "seems rather questionable". Without
> >> further discussion (what I tried) and nobody else complaining about it,
> >> what do you think would be more appropriate than to wait for quite a
> >> long time until continuing?
> >>
> >> The usual way for him to prevent me pushing it would just have been to
> >> ask me to wait and I would have waited. Have you checked the dates of
> >> the replies and what I wrote before accusing me to just ignore concerns?
> >>  
> > 
> > Timing makes no difference. Its the only review you got, so even if
> > you ignore that, you didn't even get a "OK" from anyone else, which
> > for generic API should be mandatory.  
> 
> I can't see why you accuse me ignoring something again.
> 
> 
> > The least that would have been appropriate would be to ping the patch
> > asking for further comments, instead of just practically saying "I'm
> > done waiting and just pushing"
> > 
> > Not everyone has the time to answer within a day, so if someone
> > expressed a concern, the least one could do before pushing is asking
> > again, everything else feels rather disingenuous.  
> 
> First concern about this was stated on 13th.
> After my reply, there was silence for nine days.
> What would have been your assumption about his concerns after my reply?
> Mine was that he considers this not to be as critical enough for further
> discussion - means he might still dislike having multikey dictionaries
> but sees no reason in struggling about it.
> 
> I pinged the patch again on 22nd, and it took about one minute for wm4
> to address his concerns again. However, after me asking for his
> suggestions there was again silence for days. Also note that he did not
> stated his concerns more specifically than before.
> 
> So I waiting for around 12 days (including a ping) to get a more
> specific remark, counter-proposal, discussion or anything else than a
> basic concern. During that time wm4 was active and very well capable of
> immediate reply. Thus I assume that his attitude about this patch is not
> as bad as insisting not to apply.
> 
> I still really can't see a "I'm done waiting and just pushing" attitude
> from my side.

You were adding weird new public API just to internally parse some
really weird syntax. I hoped other would voice their concern too, but
nobody did, so who cares, I guess.

I guess I'm ok with this, because it means I can easily get in my own
low quality changes as well.
___

Re: [FFmpeg-devel] [PATCH 3/3] lavf/segment: add option to write empty filler segments as needed

[Rodger Combs]

> On Mar 25, 2016, at 10:17, Stefano Sabatini  wrote:
> 
> Can you describe an use case for this (and possibly add a short
> description in the log)?

This is mostly useful when writing segmented subtitles (e.g. WebVTT in HLS). If 
there's a gap in the subtitles, you need empty segments between them.
I'll add an explanation in the commit message.

> 
>> +if (seg->times || (!seg->frames && !seg->use_clocktime) && 
>> seg->write_empty)
>> +goto calc_times;
> 
> what's the point of this goto?

This causes us to re-run the time check and segment-breaking code, so we can 
advance by multiple segments while processing a single packet (all but the last 
one being left empty).

> [...]
> -- 
> FFmpeg = Funny and Frenzy Muttering Picky Emblematic Generator
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org 
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel 
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavf/segment: slight refactor to seg_write_packet

[Rodger Combs]

> On Mar 25, 2016, at 09:45, Stefano Sabatini  wrote:
> 
> On date Sunday 2016-03-06 20:49:23 -0600, Rodger Combs encoded:
>> This reduces some code duplication, and ensures that cur_entry.last_duration 
>> is
>> always set.
>> ---
>> libavformat/segment.c | 12 +++-
>> 1 file changed, 7 insertions(+), 5 deletions(-)
>> 
>> diff --git a/libavformat/segment.c b/libavformat/segment.c
>> index 818c0c9..6ad991f 100644
>> --- a/libavformat/segment.c
>> +++ b/libavformat/segment.c
>> @@ -824,11 +824,13 @@ static int seg_write_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>> seg->cur_entry.index = seg->segment_idx + seg->segment_idx_wrap * 
>> seg->segment_idx_wrap_nb;
>> seg->cur_entry.start_time = (double)pkt->pts * av_q2d(st->time_base);
>> seg->cur_entry.start_pts = av_rescale_q(pkt->pts, st->time_base, 
>> AV_TIME_BASE_Q);
> 
>> -seg->cur_entry.end_time = seg->cur_entry.start_time +
>> -pkt->pts != AV_NOPTS_VALUE ? (double)(pkt->pts + pkt->duration) 
>> * av_q2d(st->time_base) : 0;
> 
> Unrelated, this looks wrong

Reading over the deleted code again, this confuses me a lot. In the 
segment-breaking case, if pkt->pts != AV_NOPTS_VALUE, we previously effectively 
set `seg->cur_entry.end_time = (double)(pkt->pts * 2 + pkt->duration) * 
av_q2d(st->time_base)`, if I understand correctly, and that doesn't seem to 
make any sense.

> 
>> -} else if (pkt->pts != AV_NOPTS_VALUE && pkt->stream_index == 
>> seg->reference_stream_index) {
>> -seg->cur_entry.end_time =
>> -FFMAX(seg->cur_entry.end_time, (double)(pkt->pts + 
>> pkt->duration) * av_q2d(st->time_base));
>> +seg->cur_entry.end_time = seg->cur_entry.start_time;
>> +}
>> +
>> +if (pkt->stream_index == seg->reference_stream_index) {
>> +if (pkt->pts != AV_NOPTS_VALUE)
>> +seg->cur_entry.end_time =
>> +FFMAX(seg->cur_entry.end_time, (double)(pkt->pts + 
>> pkt->duration) * av_q2d(st->time_base));
>> seg->cur_entry.last_duration = pkt->duration;
> 
> LGTM (and fixes the defect), thanks.
> -- 
> FFmpeg = Formidable and Fascinating Multimedia Powered Elegant Gnome
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org 
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel 
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]avcodec/jpeg2000dec: silence invalid error message

[Michael Niedermayer]

On Fri, Mar 25, 2016 at 11:28:30AM +0100, Paul B Mahol wrote:
> Hi,
> 
> patch attached.

>  jpeg2000dec.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> dd8b1c68a69169e00b94ecd9402f1faa9a4548ce  
> 0001-avcodec-jpeg2000dec-account-two-last-bytes-from-end-.patch
> From 155ea9e6063553b8f7db83698faf428eaa1f8c04 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol 
> Date: Fri, 25 Mar 2016 11:22:39 +0100
> Subject: [PATCH] avcodec/jpeg2000dec: account two last bytes from end of
>  bytestream as EOC marker
> 
> This silences missing EOC marker when decoding j2k files with Psot set to 0.

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH 0/4] fftw exploration (WIP)

[Ganesh Ajjanagadde]

On Fri, Mar 25, 2016 at 12:11 PM, Paul B Mahol  wrote:
> On 3/25/16, Ganesh Ajjanagadde  wrote:
>> On Fri, Mar 25, 2016 at 9:36 AM, Nicolas George  wrote:
>>> Le sextidi 6 germinal, an CCXXIV, Ganesh Ajjanagadde a ecrit :
 Depends on if it is small or not. Yes, in many codecs, FFT's are short
 length ones, e.g 512. However, on long lengths, e.g 8192+, as seen
 from the benches, there are sometimes 2x variations at the moment.
>>>
>>> And how much of the actual total decoding is spent in the FFT? Even a  *50
>>> speedup would be useless if it is for a function that never amounts to
>>> more
>>> than 0,01% of the actual time. The FFT is probably not that negligible,
>>> but
>>> this is not a  *50 speedup either, and I have no idea how frequent are long
>>> lengths.
>>
>> Paul had some interest in 2^17 fft's at a point.
>
> And it was done in avfft. So feel free to improve our avfft instead.

Just to be clear: I won't be working on improving avfft, but of course
I won't oppose patches generally.

Basically, it boils down to the current asm code being a mess so that
I can't even identify really what algo is being used. Sure, I can go
and locally optimize, insert fma's, move some 128 bit simd to 256 bit
simd, etc. But it is not even clear that the approach in FFmpeg is the
best possible among currently known FFT approaches; the only marker I
see is "based on ideas from libdjbfft".

If anyone cares here, I do not know why we can't use inline asm or
intrinsics. The chief benefit of intrinsics is that the hard part (for
humans) of register allocation/checks is taken care of, but optimized
instructions get used in a readable fashion. Anyway, I know there are
a ton of arguments against it in FFmpeg, almost none of which I buy in
2016 with modern toolchains.

> ___
> 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] [WIP] GSoC P frame support for FFV1 codec

[Paul B Mahol]

On 3/25/16, Stanislav Dolganov  wrote:
> New formula for residual calculation, which reduced compressed sized
> significantly, but it is still a bit larger then in case if all frames are
> I. I think it because of coder context changes to much from I frame pixel
> value to P ones.

Use another context for P frames?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/4] fftw exploration (WIP)

[Paul B Mahol]

On 3/25/16, Ganesh Ajjanagadde  wrote:
> On Fri, Mar 25, 2016 at 9:36 AM, Nicolas George  wrote:
>> Le sextidi 6 germinal, an CCXXIV, Ganesh Ajjanagadde a ecrit :
>>> Depends on if it is small or not. Yes, in many codecs, FFT's are short
>>> length ones, e.g 512. However, on long lengths, e.g 8192+, as seen
>>> from the benches, there are sometimes 2x variations at the moment.
>>
>> And how much of the actual total decoding is spent in the FFT? Even a  *50
>> speedup would be useless if it is for a function that never amounts to
>> more
>> than 0,01% of the actual time. The FFT is probably not that negligible,
>> but
>> this is not a  *50 speedup either, and I have no idea how frequent are long
>> lengths.
>
> Paul had some interest in 2^17 fft's at a point.

And it was done in avfft. So feel free to improve our avfft instead.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Thilo Borgmann]

Am 25.03.16 um 18:48 schrieb Hendrik Leppkes:
> On Fri, Mar 25, 2016 at 6:26 PM, Thilo Borgmann  
> wrote:
>> Am 25.03.16 um 17:56 schrieb Hendrik Leppkes:
>>> On Fri, Mar 25, 2016 at 5:48 PM, Thilo Borgmann  
>>> wrote:
 Am 22.03.16 um 12:20 schrieb Thilo Borgmann:
> Am 22.03.16 um 11:45 schrieb wm4:
>> On Sun, 13 Mar 2016 21:00:23 +0100
>> Thilo Borgmann  wrote:
>>
>>> Am 13.03.16 um 15:08 schrieb wm4:
 On Sat, 12 Mar 2016 15:13:21 +0100
 Thilo Borgmann  wrote:

> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 2001
> From: Thilo Borgmann 
> Date: Sat, 12 Mar 2016 14:52:17 +0100
> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal 
> keys.
> [...]

 Changing the semantics of AVDictionary just like this seems rather
 questionable...
>>>
>>> It changes nothing for existing code, just adds a new feature. I don't
>>> think it hurts anyone or anything...
>>
>> It only breaks basic assumptions about a basic data type...
>
> Although I don't share your thought about breaking a basic data type with 
> that,
> what would you suggest instead?

 Pushed for no further suggestions and nobody else objected.

>>>
>>> Just pushing without addressing concerns is not the way we usually try
>>> to work here, just saying.
>>
>> I think I have quite a good idea about the usual way we try to handle
>> things here and I think I've addressed his concerns.
> 
> If by addressing you mean disagreeing with the concern and doing nothing.

Not at all. I proposed alternatives (alternatives which I don't like
much but anyway) and I explicitly asked for his suggestions. Means, I
actually tried to satisfy his concerns. Thus, I can't understand that
you are saying I've ignored anything.


>> He didn't like it which is of course ok. He did not continue discussing
>> it nor did he proposed any alternative. He also did not pick up any of
>> my thoughts. He also did not explicitly state that he thinks that it is
>> not ok to apply it. He said it "seems rather questionable". Without
>> further discussion (what I tried) and nobody else complaining about it,
>> what do you think would be more appropriate than to wait for quite a
>> long time until continuing?
>>
>> The usual way for him to prevent me pushing it would just have been to
>> ask me to wait and I would have waited. Have you checked the dates of
>> the replies and what I wrote before accusing me to just ignore concerns?
>>
> 
> Timing makes no difference. Its the only review you got, so even if
> you ignore that, you didn't even get a "OK" from anyone else, which
> for generic API should be mandatory.

I can't see why you accuse me ignoring something again.


> The least that would have been appropriate would be to ping the patch
> asking for further comments, instead of just practically saying "I'm
> done waiting and just pushing"
> 
> Not everyone has the time to answer within a day, so if someone
> expressed a concern, the least one could do before pushing is asking
> again, everything else feels rather disingenuous.

First concern about this was stated on 13th.
After my reply, there was silence for nine days.
What would have been your assumption about his concerns after my reply?
Mine was that he considers this not to be as critical enough for further
discussion - means he might still dislike having multikey dictionaries
but sees no reason in struggling about it.

I pinged the patch again on 22nd, and it took about one minute for wm4
to address his concerns again. However, after me asking for his
suggestions there was again silence for days. Also note that he did not
stated his concerns more specifically than before.

So I waiting for around 12 days (including a ping) to get a more
specific remark, counter-proposal, discussion or anything else than a
basic concern. During that time wm4 was active and very well capable of
immediate reply. Thus I assume that his attitude about this patch is not
as bad as insisting not to apply.

I still really can't see a "I'm done waiting and just pushing" attitude
from my side.

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

[FFmpeg-devel] [WIP] GSoC P frame support for FFV1 codec

[Станислав Долганов]

New formula for residual calculation, which reduced compressed sized
significantly, but it is still a bit larger then in case if all frames are
I. I think it because of coder context changes to much from I frame pixel
value to P ones.

Also more fate test references were generated.

-- 
Stanislav Dolganov


0001-simple-P-frame-support.patch
Description: Binary data


0002-more-tests-and-residual-formula.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/flicvideo: Implement padding in COPY chunks.

[Reimar Döffinger]

On Thu, Mar 24, 2016 at 01:40:07AM +0100, Carl Eugen Hoyos wrote:
> @@ -432,6 +432,8 @@ static int flic_decode_frame_8BPP(AVCodecContext *avctx,
>   y_ptr += s->frame->linesize[0]) {
>  bytestream2_get_buffer(, [y_ptr],
> s->avctx->width);
> +if (s->avctx->width & 3)
> +bytestream2_skip(, 4 - (s->avctx->width & 3));

Maybe it's more reliable/clear to keep like that, but I think
this could also be written as
bytestream2_skip(, -s->avctx->width & 3);
Should be fine otherwise I think.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/flicvideo: Implement padding in COPY chunks.

[Carl Eugen Hoyos]

Carl Eugen Hoyos  ag.or.at> writes:

> Attached patch fixes ticket #5364 for me.

Fixes several different samples, I'll push if 
nobody objects.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Hendrik Leppkes]

On Fri, Mar 25, 2016 at 6:26 PM, Thilo Borgmann  wrote:
> Am 25.03.16 um 17:56 schrieb Hendrik Leppkes:
>> On Fri, Mar 25, 2016 at 5:48 PM, Thilo Borgmann  
>> wrote:
>>> Am 22.03.16 um 12:20 schrieb Thilo Borgmann:
 Am 22.03.16 um 11:45 schrieb wm4:
> On Sun, 13 Mar 2016 21:00:23 +0100
> Thilo Borgmann  wrote:
>
>> Am 13.03.16 um 15:08 schrieb wm4:
>>> On Sat, 12 Mar 2016 15:13:21 +0100
>>> Thilo Borgmann  wrote:
>>>
 From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 2001
 From: Thilo Borgmann 
 Date: Sat, 12 Mar 2016 14:52:17 +0100
 Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal 
 keys.

 ---
  libavutil/dict.c | 5 -
  libavutil/dict.h | 5 +++--
  2 files changed, 7 insertions(+), 3 deletions(-)

 diff --git a/libavutil/dict.c b/libavutil/dict.c
 index 8bb65a1..70c0184 100644
 --- a/libavutil/dict.c
 +++ b/libavutil/dict.c
 @@ -70,9 +70,12 @@ int av_dict_set(AVDictionary **pm, const char *key, 
 const char *value,
  int flags)
  {
  AVDictionary *m = *pm;
 -AVDictionaryEntry *tag = av_dict_get(m, key, NULL, flags);
 +AVDictionaryEntry *tag = NULL;
  char *oldval = NULL, *copy_key = NULL, *copy_value = NULL;

 +if (!(flags & AV_DICT_MULTIKEY)) {
 +tag = av_dict_get(m, key, NULL, flags);
 +}
  if (flags & AV_DICT_DONT_STRDUP_KEY)
  copy_key = (void *)key;
  else
 diff --git a/libavutil/dict.h b/libavutil/dict.h
 index b0aa784..c589bcd 100644
 --- a/libavutil/dict.h
 +++ b/libavutil/dict.h
 @@ -76,6 +76,7 @@
  #define AV_DICT_DONT_OVERWRITE 16   ///< Don't overwrite existing 
 entries.
  #define AV_DICT_APPEND 32   /**< If the entry already exists, 
 append to it.  Note that no
delimiter is added, the strings 
 are simply concatenated. */
 +#define AV_DICT_MULTIKEY   64   /**< Allow to store several equal 
 keys in the dictionary */

  typedef struct AVDictionaryEntry {
  char *key;
 @@ -118,8 +119,8 @@ int av_dict_count(const AVDictionary *m);
   *
   * @param pm pointer to a pointer to a dictionary struct. If *pm is 
 NULL
   * a dictionary struct is allocated and put in *pm.
 - * @param key entry key to add to *pm (will be av_strduped depending 
 on flags)
 - * @param value entry value to add to *pm (will be av_strduped 
 depending on flags).
 + * @param key entry key to add to *pm (will either be av_strduped or 
 added as a new key depending on flags)
 + * @param value entry value to add to *pm (will be av_strduped or 
 added as a new key depending on flags).
   *Passing a NULL value will cause an existing entry to be 
 deleted.
   * @return >= 0 on success otherwise an error code <0
   */
>>>
>>> Changing the semantics of AVDictionary just like this seems rather
>>> questionable...
>>
>> It changes nothing for existing code, just adds a new feature. I don't
>> think it hurts anyone or anything...
>
> It only breaks basic assumptions about a basic data type...

 Although I don't share your thought about breaking a basic data type with 
 that,
 what would you suggest instead?
>>>
>>> Pushed for no further suggestions and nobody else objected.
>>>
>>
>> Just pushing without addressing concerns is not the way we usually try
>> to work here, just saying.
>
> I think I have quite a good idea about the usual way we try to handle
> things here and I think I've addressed his concerns.

If by addressing you mean disagreeing with the concern and doing nothing.

>
> He didn't like it which is of course ok. He did not continue discussing
> it nor did he proposed any alternative. He also did not pick up any of
> my thoughts. He also did not explicitly state that he thinks that it is
> not ok to apply it. He said it "seems rather questionable". Without
> further discussion (what I tried) and nobody else complaining about it,
> what do you think would be more appropriate than to wait for quite a
> long time until continuing?
>
> The usual way for him to prevent me pushing it would just have been to
> ask me to wait and I would have waited. Have you checked the dates of
> the replies and what I wrote before accusing me to just ignore concerns?
>

Timing makes no difference. Its the only review you got, so even if
you ignore that, you didn't even get a "OK" from 

Re: [FFmpeg-devel] [PATCH] lavc/aacenc_utils: unroll abs_pow34_v loop

[Ganesh Ajjanagadde]

On Tue, Mar 22, 2016 at 4:42 PM, Michael Niedermayer
 wrote:
> On Tue, Mar 22, 2016 at 11:37:16AM -0700, Ganesh Ajjanagadde wrote:
>> On Tue, Mar 22, 2016 at 11:30 AM, Rostislav Pehlivanov
>>  wrote:
>> > On 22 March 2016 at 18:14, Ganesh Ajjanagadde  wrote:
>> >>
>> >>
>> >> Per doc/optimization.txt, aac is a widely used codec, so even a 0.1%
>> >> improvement in aac is fair game for optimizations, assuming it is a
>> >> small code change. Of course, one can debate whether this is small or
>> >> not. I view it as simple and clean, others may disagree.
>> >
>> >
>> > Nope, I still doubt that that 0.1% is a definite performance improvement.
>>
>> Then change doc/optimization.txt.
>>
>> > Sure it might be on your machine but who knows, maybe for someone else
>> > it'll be a 0.1% decrease in performance or hell, a 1% decrease.
>>
>> Don't speculate, show evidence. This is something that can be said
>> about essentially all patches that affect performance. For example,
>> who knows, a compiler may actually omit worse code on a certain
>> architecture for something that should be an improvement. This just
>> highlights the ridiculousness of this line of reasoning.
>
> if no consense can be found on this ...
> maybe theres an easy way out of this problem ?
> git makes it easy for 2 people to keep some differences
>
> If one doubts changes improve speed and another belives they do
> the 2 can just keep their git trees different.
> And once there are 50 disputed 0.1% improvments one git tree will
> either be 5% faster or not.
> would anyone object to applying 50 small changes which together make
> the code 5% faster ?

That is a very good idea. In fact, it is kind of what is happening
right now; I keep some stuff like this, fclose return checks, etc in
my tree.
The only problem, which can get annoying, is then dumping those 50
changes and getting remarks like they are too many of them, they are
all useless (which may be true individually) etc forcing lots of
refactoring.

>
> of course if people agree on changes in the first place that would
> be even better
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many things microsoft did are stupid, but not doing something just because
> microsoft did it is even more stupid. If everything ms did were stupid they
> would be bankrupt already.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] configure: add fftw3 detection

[Ganesh Ajjanagadde]

On Fri, Mar 25, 2016 at 9:32 AM, James Almer  wrote:
> On 3/24/2016 9:50 PM, Ganesh Ajjanagadde wrote:
>> Useful for fast FFT computation: http://www.fftw.org/.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  configure | 4 
>>  1 file changed, 4 insertions(+)
>
> fftw brings nothing we don't already have. It's simply faster in some cases
> and slower in others.
>
> Some projects use libavcodec for their FFT needs because of our 
> implementation.

Indeed, Firefox does in recent times as well:
https://bugzilla.mozilla.org/show_bug.cgi?id=1157768.

> In some cases they switched to another because, as pointed above, we're 
> lacking
> assembly optimizations for some codepaths. See ticket #3921.
> So instead of giving them more reason to not use our implementation, we should
> address its few shortcomings.

Depends if one views it as "few" or not, but whatever.

At the very least, this showed something. For instance, it shows that
for short lengths, avfft is reasonably ok, but performance degrades
relative to alternatives for long lengths. It also showed the large
amount of time spent permuting.

And furthermore, regardless of whether we use FFTW or not, I view it
as useful to keep in a working tree. That way, as avfft improves, we
have a comparison point to test against.

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

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Thilo Borgmann]

Am 25.03.16 um 17:56 schrieb Hendrik Leppkes:
> On Fri, Mar 25, 2016 at 5:48 PM, Thilo Borgmann  
> wrote:
>> Am 22.03.16 um 12:20 schrieb Thilo Borgmann:
>>> Am 22.03.16 um 11:45 schrieb wm4:
 On Sun, 13 Mar 2016 21:00:23 +0100
 Thilo Borgmann  wrote:

> Am 13.03.16 um 15:08 schrieb wm4:
>> On Sat, 12 Mar 2016 15:13:21 +0100
>> Thilo Borgmann  wrote:
>>
>>> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 2001
>>> From: Thilo Borgmann 
>>> Date: Sat, 12 Mar 2016 14:52:17 +0100
>>> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal 
>>> keys.
>>>
>>> ---
>>>  libavutil/dict.c | 5 -
>>>  libavutil/dict.h | 5 +++--
>>>  2 files changed, 7 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/libavutil/dict.c b/libavutil/dict.c
>>> index 8bb65a1..70c0184 100644
>>> --- a/libavutil/dict.c
>>> +++ b/libavutil/dict.c
>>> @@ -70,9 +70,12 @@ int av_dict_set(AVDictionary **pm, const char *key, 
>>> const char *value,
>>>  int flags)
>>>  {
>>>  AVDictionary *m = *pm;
>>> -AVDictionaryEntry *tag = av_dict_get(m, key, NULL, flags);
>>> +AVDictionaryEntry *tag = NULL;
>>>  char *oldval = NULL, *copy_key = NULL, *copy_value = NULL;
>>>
>>> +if (!(flags & AV_DICT_MULTIKEY)) {
>>> +tag = av_dict_get(m, key, NULL, flags);
>>> +}
>>>  if (flags & AV_DICT_DONT_STRDUP_KEY)
>>>  copy_key = (void *)key;
>>>  else
>>> diff --git a/libavutil/dict.h b/libavutil/dict.h
>>> index b0aa784..c589bcd 100644
>>> --- a/libavutil/dict.h
>>> +++ b/libavutil/dict.h
>>> @@ -76,6 +76,7 @@
>>>  #define AV_DICT_DONT_OVERWRITE 16   ///< Don't overwrite existing 
>>> entries.
>>>  #define AV_DICT_APPEND 32   /**< If the entry already exists, 
>>> append to it.  Note that no
>>>delimiter is added, the strings 
>>> are simply concatenated. */
>>> +#define AV_DICT_MULTIKEY   64   /**< Allow to store several equal 
>>> keys in the dictionary */
>>>
>>>  typedef struct AVDictionaryEntry {
>>>  char *key;
>>> @@ -118,8 +119,8 @@ int av_dict_count(const AVDictionary *m);
>>>   *
>>>   * @param pm pointer to a pointer to a dictionary struct. If *pm is 
>>> NULL
>>>   * a dictionary struct is allocated and put in *pm.
>>> - * @param key entry key to add to *pm (will be av_strduped depending 
>>> on flags)
>>> - * @param value entry value to add to *pm (will be av_strduped 
>>> depending on flags).
>>> + * @param key entry key to add to *pm (will either be av_strduped or 
>>> added as a new key depending on flags)
>>> + * @param value entry value to add to *pm (will be av_strduped or 
>>> added as a new key depending on flags).
>>>   *Passing a NULL value will cause an existing entry to be 
>>> deleted.
>>>   * @return >= 0 on success otherwise an error code <0
>>>   */
>>
>> Changing the semantics of AVDictionary just like this seems rather
>> questionable...
>
> It changes nothing for existing code, just adds a new feature. I don't
> think it hurts anyone or anything...

 It only breaks basic assumptions about a basic data type...
>>>
>>> Although I don't share your thought about breaking a basic data type with 
>>> that,
>>> what would you suggest instead?
>>
>> Pushed for no further suggestions and nobody else objected.
>>
> 
> Just pushing without addressing concerns is not the way we usually try
> to work here, just saying.

I think I have quite a good idea about the usual way we try to handle
things here and I think I've addressed his concerns.

He didn't like it which is of course ok. He did not continue discussing
it nor did he proposed any alternative. He also did not pick up any of
my thoughts. He also did not explicitly state that he thinks that it is
not ok to apply it. He said it "seems rather questionable". Without
further discussion (what I tried) and nobody else complaining about it,
what do you think would be more appropriate than to wait for quite a
long time until continuing?

The usual way for him to prevent me pushing it would just have been to
ask me to wait and I would have waited. Have you checked the dates of
the replies and what I wrote before accusing me to just ignore concerns?

-Thilo


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

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Hendrik Leppkes]

On Fri, Mar 25, 2016 at 5:48 PM, Thilo Borgmann  wrote:
> Am 22.03.16 um 12:20 schrieb Thilo Borgmann:
>> Am 22.03.16 um 11:45 schrieb wm4:
>>> On Sun, 13 Mar 2016 21:00:23 +0100
>>> Thilo Borgmann  wrote:
>>>
 Am 13.03.16 um 15:08 schrieb wm4:
> On Sat, 12 Mar 2016 15:13:21 +0100
> Thilo Borgmann  wrote:
>
>> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 2001
>> From: Thilo Borgmann 
>> Date: Sat, 12 Mar 2016 14:52:17 +0100
>> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal 
>> keys.
>>
>> ---
>>  libavutil/dict.c | 5 -
>>  libavutil/dict.h | 5 +++--
>>  2 files changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavutil/dict.c b/libavutil/dict.c
>> index 8bb65a1..70c0184 100644
>> --- a/libavutil/dict.c
>> +++ b/libavutil/dict.c
>> @@ -70,9 +70,12 @@ int av_dict_set(AVDictionary **pm, const char *key, 
>> const char *value,
>>  int flags)
>>  {
>>  AVDictionary *m = *pm;
>> -AVDictionaryEntry *tag = av_dict_get(m, key, NULL, flags);
>> +AVDictionaryEntry *tag = NULL;
>>  char *oldval = NULL, *copy_key = NULL, *copy_value = NULL;
>>
>> +if (!(flags & AV_DICT_MULTIKEY)) {
>> +tag = av_dict_get(m, key, NULL, flags);
>> +}
>>  if (flags & AV_DICT_DONT_STRDUP_KEY)
>>  copy_key = (void *)key;
>>  else
>> diff --git a/libavutil/dict.h b/libavutil/dict.h
>> index b0aa784..c589bcd 100644
>> --- a/libavutil/dict.h
>> +++ b/libavutil/dict.h
>> @@ -76,6 +76,7 @@
>>  #define AV_DICT_DONT_OVERWRITE 16   ///< Don't overwrite existing 
>> entries.
>>  #define AV_DICT_APPEND 32   /**< If the entry already exists, 
>> append to it.  Note that no
>>delimiter is added, the strings 
>> are simply concatenated. */
>> +#define AV_DICT_MULTIKEY   64   /**< Allow to store several equal 
>> keys in the dictionary */
>>
>>  typedef struct AVDictionaryEntry {
>>  char *key;
>> @@ -118,8 +119,8 @@ int av_dict_count(const AVDictionary *m);
>>   *
>>   * @param pm pointer to a pointer to a dictionary struct. If *pm is NULL
>>   * a dictionary struct is allocated and put in *pm.
>> - * @param key entry key to add to *pm (will be av_strduped depending on 
>> flags)
>> - * @param value entry value to add to *pm (will be av_strduped 
>> depending on flags).
>> + * @param key entry key to add to *pm (will either be av_strduped or 
>> added as a new key depending on flags)
>> + * @param value entry value to add to *pm (will be av_strduped or added 
>> as a new key depending on flags).
>>   *Passing a NULL value will cause an existing entry to be 
>> deleted.
>>   * @return >= 0 on success otherwise an error code <0
>>   */
>
> Changing the semantics of AVDictionary just like this seems rather
> questionable...

 It changes nothing for existing code, just adds a new feature. I don't
 think it hurts anyone or anything...
>>>
>>> It only breaks basic assumptions about a basic data type...
>>
>> Although I don't share your thought about breaking a basic data type with 
>> that,
>> what would you suggest instead?
>
> Pushed for no further suggestions and nobody else objected.
>

Just pushing without addressing concerns is not the way we usually try
to work here, just saying.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] mpegts: pcr period option for variable bitrate multiplexing

[Predrag Filipovic]

Enable proper PCR insertion for VBR multiplexing (muxrate not specified).
Insertion timing is based on video frame keys and frame period, consequently
pcr period precision is limited to +/- one video frame period.

Signed-off-by: Predrag Filipovic 
---
 libavformat/mpegtsenc.c | 80 +
 1 file changed, 61 insertions(+), 19 deletions(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 7656720..7ed9076 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -105,6 +105,7 @@ typedef struct MpegTSWrite {
 int tables_version;
 double pat_period;
 double sdt_period;
+int64_t last_pcr_ts;
 int64_t last_pat_ts;
 int64_t last_sdt_ts;
 
@@ -903,6 +904,9 @@ static int mpegts_init(AVFormatContext *s)
 ts_st = pcr_st->priv_data;
 
 if (ts->mux_rate > 1) {
+if (ts->pcr_period >= INT_MAX/2) {
+ts->pcr_period = PCR_RETRANS_TIME;
+}
 service->pcr_packet_period = (int64_t)ts->mux_rate * ts->pcr_period /
  (TS_PACKET_SIZE * 8 * 1000);
 ts->sdt_packet_period  = (int64_t)ts->mux_rate * SDT_RETRANS_TIME /
@@ -931,10 +935,19 @@ static int mpegts_init(AVFormatContext *s)
 service->pcr_packet_period =
 ts_st->user_tb.den / (10 * ts_st->user_tb.num);
 }
-if (!service->pcr_packet_period)
+/* if pcr_period specified, mark pcr_packet_period as NA (=INT_MAX) */
+if (ts->pcr_period < INT_MAX/2) {
+service->pcr_packet_period = INT_MAX;
+} else {
+if (!service->pcr_packet_period) {
 service->pcr_packet_period = 1;
+} else if (service->pcr_packet_period == INT_MAX) {
+service->pcr_packet_period--;
+}
+}
 }
 
+ts->last_pcr_ts = AV_NOPTS_VALUE;
 ts->last_pat_ts = AV_NOPTS_VALUE;
 ts->last_sdt_ts = AV_NOPTS_VALUE;
 // The user specified a period, use only it
@@ -1032,10 +1045,9 @@ static void mpegts_insert_null_packet(AVFormatContext *s)
 avio_write(s->pb, buf, TS_PACKET_SIZE);
 }
 
-/* Write a single transport stream packet with a PCR and no payload */
-static void mpegts_insert_pcr_only(AVFormatContext *s, AVStream *st)
+/* Write a single transport stream packet with a PCR (value in arg) and no 
payload */
+static void mpegts_insert_pcr_only(AVFormatContext *s, AVStream *st, int64_t 
pcr)
 {
-MpegTSWrite *ts = s->priv_data;
 MpegTSWriteStream *ts_st = st->priv_data;
 uint8_t *q;
 uint8_t buf[TS_PACKET_SIZE];
@@ -1050,7 +1062,7 @@ static void mpegts_insert_pcr_only(AVFormatContext *s, 
AVStream *st)
 *q++ = 0x10;   /* Adaptation flags: PCR present */
 
 /* PCR coded into 6 bytes */
-q += write_pcr_bits(q, get_pcr(ts, s->pb));
+q += write_pcr_bits(q, pcr);
 
 /* stuffing bytes */
 memset(q, 0xFF, TS_PACKET_SIZE - (q - buf));
@@ -1109,6 +1121,9 @@ static uint8_t *get_ts_payload_start(uint8_t *pkt)
  * number of TS packets. The final TS packet is padded using an oversized
  * adaptation header to exactly fill the last TS packet.
  * NOTE: 'payload' contains a complete PES payload. */
+/* PCR insertion for VBR TS is based on video frames time and key frames
+ * which leaves non-video TS with PCR insertion at key frames only.
+ * NOTE: PCR period "precision" for VBR TS is +/- one video frame period. */
 static void mpegts_write_pes(AVFormatContext *s, AVStream *st,
  const uint8_t *payload, int payload_size,
  int64_t pts, int64_t dts, int key)
@@ -1135,26 +1150,53 @@ static void mpegts_write_pes(AVFormatContext *s, 
AVStream *st,
 
 write_pcr = 0;
 if (ts_st->pid == ts_st->service->pcr_pid) {
-if (ts->mux_rate > 1 || is_start) // VBR pcr period is based on 
frames
-ts_st->service->pcr_packet_count++;
+if (ts->mux_rate > 1 || is_start)
+if (ts_st->service->pcr_packet_period != INT_MAX) 
ts_st->service->pcr_packet_count++;
 if (ts_st->service->pcr_packet_count >=
-ts_st->service->pcr_packet_period) {
+ts_st->service->pcr_packet_period) { /* case is NA for VBR TS 
with specified pcr period*/
 ts_st->service->pcr_packet_count = 0;
-write_pcr = 1;
+if (ts_st->service->pcr_packet_period != INT_MAX) write_pcr = 
1;
 }
 }
 
+if (ts->mux_rate > 1) {
+pcr = get_pcr(ts, s->pb);
+} else {
+pcr = (dts - delay) * 300;
+}
+if (pcr < 0) {
+av_log(s, AV_LOG_WARNING, "calculated pcr < 0, TS is invalid\n");
+pcr = 0;
+}
+
 if (ts->mux_rate > 1 && dts != AV_NOPTS_VALUE &&
-(dts - get_pcr(ts, s->pb) / 300) > delay) {
+(dts - pcr / 300) > delay) {
 /* pcr insert gets 

Re: [FFmpeg-devel] [PATCH 1/4] configure: add fftw3 detection

[James Almer]

On 3/24/2016 9:50 PM, Ganesh Ajjanagadde wrote:
> Useful for fast FFT computation: http://www.fftw.org/.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  configure | 4 
>  1 file changed, 4 insertions(+)

fftw brings nothing we don't already have. It's simply faster in some cases
and slower in others.

Some projects use libavcodec for their FFT needs because of our implementation.
In some cases they switched to another because, as pointed above, we're lacking
assembly optimizations for some codepaths. See ticket #3921.
So instead of giving them more reason to not use our implementation, we should
address its few shortcomings.

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

Re: [FFmpeg-devel] [PATCH 0/4] fftw exploration (WIP)

[Reimar Döffinger]

On Fri, Mar 25, 2016 at 09:29:56AM -0700, Ganesh Ajjanagadde wrote:
> On Fri, Mar 25, 2016 at 8:23 AM, Hendrik Leppkes  wrote:
> > If performance is the only reason one might want an external library,
> > then its a much better idea to try to optimize the code we have, that
> > way more people automatically benefit from this, and we avoid this
> > complexity.
> 
> I see some points to this, but note also that ensuring that avfft
> remains fast as new instruction sets roll along (e.g AVX-512) is also
> a maintainence burden. Assuming FFTW is still actively developed
> (which it is atm: https://github.com/FFTW/fftw3), they take care of
> this aspect of the burden.

IMHO not really. FFT is a fairly core part of FFmpeg, so I don't believe
100% depending on an external solution is an option.
So we still need to reasonably maintain our implementations.

> It is even available on windows AFAIK, since Julia uses it.

I'd like to point out that I would only use the word "even" for
Solaris, OS/2, Haiku or BeOS support. I think Windows, Linux,
BSD and OSX support count as "basic OS support" for us.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering on OSX.

[Thilo Borgmann]

Am 22.03.16 um 11:44 schrieb Thilo Borgmann:
> Am 19.03.16 um 18:26 schrieb Michael Niedermayer:
>> On Sat, Mar 19, 2016 at 04:31:56PM +0100, Thilo Borgmann wrote:
>>> All comments addressed,
>>
>>> linux compilation fixed.
>>
>> confirmed, thx
> 
> If there are no more comments I'll apply soon.

Applied.

Thanks,
Thilo

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

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Thilo Borgmann]

Am 22.03.16 um 12:20 schrieb Thilo Borgmann:
> Am 22.03.16 um 11:45 schrieb wm4:
>> On Sun, 13 Mar 2016 21:00:23 +0100
>> Thilo Borgmann  wrote:
>>
>>> Am 13.03.16 um 15:08 schrieb wm4:
 On Sat, 12 Mar 2016 15:13:21 +0100
 Thilo Borgmann  wrote:
   
> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 2001
> From: Thilo Borgmann 
> Date: Sat, 12 Mar 2016 14:52:17 +0100
> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.
>
> ---
>  libavutil/dict.c | 5 -
>  libavutil/dict.h | 5 +++--
>  2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/libavutil/dict.c b/libavutil/dict.c
> index 8bb65a1..70c0184 100644
> --- a/libavutil/dict.c
> +++ b/libavutil/dict.c
> @@ -70,9 +70,12 @@ int av_dict_set(AVDictionary **pm, const char *key, 
> const char *value,
>  int flags)
>  {
>  AVDictionary *m = *pm;
> -AVDictionaryEntry *tag = av_dict_get(m, key, NULL, flags);
> +AVDictionaryEntry *tag = NULL;
>  char *oldval = NULL, *copy_key = NULL, *copy_value = NULL;
>  
> +if (!(flags & AV_DICT_MULTIKEY)) {
> +tag = av_dict_get(m, key, NULL, flags);
> +}
>  if (flags & AV_DICT_DONT_STRDUP_KEY)
>  copy_key = (void *)key;
>  else
> diff --git a/libavutil/dict.h b/libavutil/dict.h
> index b0aa784..c589bcd 100644
> --- a/libavutil/dict.h
> +++ b/libavutil/dict.h
> @@ -76,6 +76,7 @@
>  #define AV_DICT_DONT_OVERWRITE 16   ///< Don't overwrite existing 
> entries.
>  #define AV_DICT_APPEND 32   /**< If the entry already exists, 
> append to it.  Note that no
>delimiter is added, the strings 
> are simply concatenated. */
> +#define AV_DICT_MULTIKEY   64   /**< Allow to store several equal 
> keys in the dictionary */
>  
>  typedef struct AVDictionaryEntry {
>  char *key;
> @@ -118,8 +119,8 @@ int av_dict_count(const AVDictionary *m);
>   *
>   * @param pm pointer to a pointer to a dictionary struct. If *pm is NULL
>   * a dictionary struct is allocated and put in *pm.
> - * @param key entry key to add to *pm (will be av_strduped depending on 
> flags)
> - * @param value entry value to add to *pm (will be av_strduped depending 
> on flags).
> + * @param key entry key to add to *pm (will either be av_strduped or 
> added as a new key depending on flags)
> + * @param value entry value to add to *pm (will be av_strduped or added 
> as a new key depending on flags).
>   *Passing a NULL value will cause an existing entry to be 
> deleted.
>   * @return >= 0 on success otherwise an error code <0
>   */  

 Changing the semantics of AVDictionary just like this seems rather
 questionable...  
>>>
>>> It changes nothing for existing code, just adds a new feature. I don't
>>> think it hurts anyone or anything...
>>
>> It only breaks basic assumptions about a basic data type...
> 
> Although I don't share your thought about breaking a basic data type with 
> that,
> what would you suggest instead?

Pushed for no further suggestions and nobody else objected.

-Thilo

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

Re: [FFmpeg-devel] [PATCH 0/4] fftw exploration (WIP)

[James Almer]

On 3/25/2016 12:25 PM, Hendrik Leppkes wrote:
> Also for the record, most of the external libraries that duplicate
> internal functionality existed before the internal functionality was
> improved/implemented, or the current internal variant is still not
> quite on the level.
> Sometimes its just cruft that should probably be purged, just noone
> did it yet. Sometimes we use the library for encoding, and also offer

Speaking of which, the libdcadec wrapper should be removed since foo86
ported it fully already.

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

Re: [FFmpeg-devel] [PATCH 1/4] configure: add fftw3 detection

[Ganesh Ajjanagadde]

On Fri, Mar 25, 2016 at 9:23 AM, Reimar Döffinger
 wrote:
> On Fri, Mar 25, 2016 at 07:50:22AM -0700, Ganesh Ajjanagadde wrote:
>> On Fri, Mar 25, 2016 at 2:32 AM, Reimar Döffinger
>>  wrote:
>> >> Big NO from me. Please refrain from doing such silly things.
>> >> Either improve our implementation or do nothing.
>> >
>> > I don't disagree with the basic objections, but
>> > I'd appreciate more diplomacy and kindness (and
>> > space for people to explain there motivations)
>> > in the responses.
>>
>> To see if I understand the objections a bit better, how is this for a
>> one line summary:
>> FFmpeg does not like external libs, no matter how good or bad they are
>> relative to its own code, when it has internal code that does roughly
>> the same thing.
>
> Short: It's probably not that far off. Though I think we simply
> don't like external libraries in general :)
>
> Much longer:
> At least for me it is mostly
> 1) Improving our code is the top priority
> 2) external libs always add maintenance effort, so there
> must be a relevant enough advantage. We are not too
> consistent in what we require, but often it is things
> like that it's too complex for us to do, or it is new
> and it will take some time to get it done ourselves
> or it is there for us to be able to compare in a shared
> environment (can make debugging/testing easier).
>
> x264 is an example of code that was good enough to win
> simply on being "too good" so "no matter how good or bad"
> is not true.
>
> But there's a lot of external projects we sometimes
> with effort, sometimes easily managed to be (much) better.
>
> Also, nobody reviews external libraries, and quite
> a few of them have horrible portability or code quality
> issues. Nothing obvious on FFTW, but check major libraries
> like (not relevant to us) libLLVM, not offering a stable API
> is one thing I can excuse, but they export symbols like
> ConvertUTF8toUTF16 and isLegalUTF8String (!!!).
> If compiler guys don't manage to follow basic best
> practices, what do you think what kind of crap you can find
> in most other random libs?
> What about boost for example, knowingly including files
> licensed under an incompatible license or not at all
> in a tarball claiming to be licensed under the boost license?
> Or the lagarith "lossless" codec relying on bitexact
> x87 FPU operations so it can't decode unless compiled
> for 32 bit x86 with specific compiler options?
> Also always a question:  Will the upstream project be able to
> handle security issues in a timely manner?
> It's easy to be negatively surprised by libraries,
> and it leaves a mark.
> Which circles back to "no matter how good the code
> of the external library". I don't know if the FFTW
> code is in fact good, and it is not easy to find
> out that kind of thing.

Very fair. I personally know people who worked with Matteo Frigo and
the FFTW project, as it grew out of MIT. This has likely influenced my
perceptions about what they do. I also know pretty big projects use
it, e.g the Julia language. I think it is fair to say it is above your
average library. How far above will be subjective.

>
> Not that we don't have enough issues with our code,
> but it's at least our code and we deserve the blame
> we get from it :)
>
>> > I am in the habit of liking to call things silly
>> > myself, but honestly almost all patches here
>> > exist for a good reason, even if including
>> > them is not a good idea, and I don't want to
>> > discourage people from sending in interesting
>> > but "silly" things just because they might be derided.
>>
>> BTW, in case you want to know for e.g improving communication, this is
>> not the first time. This has happened on multiple occassions before. I
>
> Oh, I know it is quite common. I'm not the list policeman,
> I just sometimes think it might be a good idea to complain a bit.
>
>> actually very much appreciate Paul's and Clement's responses here.
>> Unlike others here, they actually point out their fundamental
>> objections at the beginning instead of showing some "fake interest",
>
> No time to read the example and it sure happens, but
> 1) I don't mean to say people should pretend to agree, it's quite
> possible to be firm and polite (but I'm not really angry with people
> if they aren't, I just want to push things a bit).
> 2) "fake interest" might just be a case of it taking time.
> If FFTW made some codec (not just the FFT part) 2x faster and
> implementing the same optimizations in FFmpeg would mean adding
> 2000 lines of code I'd probably be in favour. Though based on
> nothing I assume it's not even remotely like that.

Maybe not for codecs, but long length FFT's used for filters. Paul at
one point was interested in 2^17 length FFT's, for which assuming the
FFT is the bulk of the compute, FFmpeg's is > 2x slower.

Not saying that we should include FFTW or not, just pointing out possibilities.

> 

Re: [FFmpeg-devel] [PATCH 0/4] fftw exploration (WIP)

[Ganesh Ajjanagadde]

On Fri, Mar 25, 2016 at 9:36 AM, Nicolas George  wrote:
> Le sextidi 6 germinal, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> Depends on if it is small or not. Yes, in many codecs, FFT's are short
>> length ones, e.g 512. However, on long lengths, e.g 8192+, as seen
>> from the benches, there are sometimes 2x variations at the moment.
>
> And how much of the actual total decoding is spent in the FFT? Even a ×50
> speedup would be useless if it is for a function that never amounts to more
> than 0,01% of the actual time. The FFT is probably not that negligible, but
> this is not a ×50 speedup either, and I have no idea how frequent are long
> lengths.

Paul had some interest in 2^17 fft's at a point.

>
> You often do your benchmark like that, please try to be more careful and
> benchmark spans of code that are actually relevant for FFmpeg's tasks.

Will keep in mind, thanks.

>
> Regards,
>
> --
>   Nicolas George
>
> ___
> 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 4/4] lavc/fft-test: update benchmark code

[Reimar Döffinger]

On Fri, Mar 25, 2016 at 09:11:10AM -0700, Ganesh Ajjanagadde wrote:
> On Fri, Mar 25, 2016 at 7:53 AM, Michael Niedermayer
>  wrote:
> > On Thu, Mar 24, 2016 at 05:50:52PM -0700, Ganesh Ajjanagadde wrote:
> >> 1. The most important change is the addition of a permute call to ensure
> >> that the comparison between fftw and avfft is fair, since fftw does not
> >> require the call. This is evident from the test code additions in the
> >> previous commit, and also from http://www.fftw.org/benchfft/.
> >
> > So FFTW is slower than AVFFT
> > but FFTW is faster than AVFFT + fft_permute ?
> 
> As can be seen from the benchmarks above, with  fft_permute it is not
> a clear cut case, i.e for small lengths (< 512) they are roughly
> similar, but performance of avfft tanks for longer lengths relative to
> fftw.
> 
> BTW, fftw has multithreading options, these benches don't exercise them.

Note: from what I see their multithreading uses OpenMP.
OpenMP is really great in many ways, but one trick that
really helps it get the performance is using futexes.
futexes can be really bad on non-dedicated systems as
they can end up spinning a lot, stealing CPU time
for no benefit from the whole system.
So excluding that _might_ in fact be quite fair.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/4] fftw exploration (WIP)

[Nicolas George]

Le sextidi 6 germinal, an CCXXIV, Ganesh Ajjanagadde a écrit :
> Depends on if it is small or not. Yes, in many codecs, FFT's are short
> length ones, e.g 512. However, on long lengths, e.g 8192+, as seen
> from the benches, there are sometimes 2x variations at the moment.

And how much of the actual total decoding is spent in the FFT? Even a ×50
speedup would be useless if it is for a function that never amounts to more
than 0,01% of the actual time. The FFT is probably not that negligible, but
this is not a ×50 speedup either, and I have no idea how frequent are long
lengths.

You often do your benchmark like that, please try to be more careful and
benchmark spans of code that are actually relevant for FFmpeg's tasks.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH] avcodec/h264_slice: Update first_slice when updating current_slice for 2nd fields

[Michael Niedermayer]

This fixes Ticket 4389 differently
Fixes Ticket5371
Fixes null pointer dereference

Signed-off-by: Michael Niedermayer 
---
 libavcodec/h264_slice.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 9a5bc3f..c4340dc 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1188,6 +1188,7 @@ int ff_h264_decode_slice_header(H264Context *h, 
H264SliceContext *sl)
 if (h->cur_pic_ptr && FIELD_PICTURE(h) && h->first_field) {
 ret = ff_h264_field_end(h, h->slice_ctx, 1);
 h->current_slice = 0;
+first_slice = 1;
 if (ret < 0)
 return ret;
 } else if (h->cur_pic_ptr && !FIELD_PICTURE(h) && !h->first_field 
&& h->nal_unit_type  == NAL_IDR_SLICE) {
@@ -1422,7 +1423,7 @@ int ff_h264_decode_slice_header(H264Context *h, 
H264SliceContext *sl)
 }
 }
 
-if (!h->current_slice && h->dequant_coeff_pps != pps_id) {
+if (first_slice && h->dequant_coeff_pps != pps_id) {
 h->dequant_coeff_pps = pps_id;
 ff_h264_init_dequant_tables(h);
 }
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH 0/4] fftw exploration (WIP)

[Ganesh Ajjanagadde]

On Fri, Mar 25, 2016 at 8:23 AM, Hendrik Leppkes  wrote:
> On Fri, Mar 25, 2016 at 3:34 PM, Ganesh Ajjanagadde  
> wrote:
>> On Fri, Mar 25, 2016 at 12:35 AM, Clément Bœsch  wrote:
>>> On Thu, Mar 24, 2016 at 05:50:48PM -0700, Ganesh Ajjanagadde wrote:
 Ganesh Ajjanagadde (4):
   configure: add fftw3 detection
   lavc/fftw: add initial fftw wrapper
   lavc/fft-test: add FFTW3 tests
   lavc/fft-test: update benchmark code

>>>
>>> Why?
>>>
>>> Using an external library for such an essential component sounds like
>>> madness to me.
>>
>> I don't really understand. It is an opt-in dependency, and does not
>> have to be used. Seems like I don't really understand the FFmpeg
>> philosophy; there are a ton of optional libs in configure. FFT is not
>> used in all codecs, so I view it on the same lines as having things
>> like libopus based decoding instead of native FFmpeg decoding, the
>> multiple AAC encoders/decoders, the duplicate prores stuff, libnut on
>> top of the native demuxer, etc, etc.
>>
>
> The way I see it, external libraries should only be used if they
> provide actual features (for example new formats not otherwise
> supported, or access to hardware de/encoders), or a higher quality
> (ie. for encoders).
> Using external libraries for small performance gains seems rather
> overkill, resulting in code rot and maintenance burden.

Depends on if it is small or not. Yes, in many codecs, FFT's are short
length ones, e.g 512. However, on long lengths, e.g 8192+, as seen
from the benches, there are sometimes 2x variations at the moment.

>
> If performance is the only reason one might want an external library,
> then its a much better idea to try to optimize the code we have, that
> way more people automatically benefit from this, and we avoid this
> complexity.

I see some points to this, but note also that ensuring that avfft
remains fast as new instruction sets roll along (e.g AVX-512) is also
a maintainence burden. Assuming FFTW is still actively developed
(which it is atm: https://github.com/FFTW/fftw3), they take care of
this aspect of the burden. It is even available on windows AFAIK,
since Julia uses it.

Furthermore, fundamentally all projects specialize in one way or
another. FFmpeg is specialized to multimedia, fftw to the task of
computing fft's, etc. This is why we have library ecosystems, etc.

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

Re: [FFmpeg-devel] [PATCH 1/4] configure: add fftw3 detection

[Reimar Döffinger]

On Fri, Mar 25, 2016 at 07:50:22AM -0700, Ganesh Ajjanagadde wrote:
> On Fri, Mar 25, 2016 at 2:32 AM, Reimar Döffinger
>  wrote:
> >> Big NO from me. Please refrain from doing such silly things.
> >> Either improve our implementation or do nothing.
> >
> > I don't disagree with the basic objections, but
> > I'd appreciate more diplomacy and kindness (and
> > space for people to explain there motivations)
> > in the responses.
> 
> To see if I understand the objections a bit better, how is this for a
> one line summary:
> FFmpeg does not like external libs, no matter how good or bad they are
> relative to its own code, when it has internal code that does roughly
> the same thing.

Short: It's probably not that far off. Though I think we simply
don't like external libraries in general :)

Much longer:
At least for me it is mostly
1) Improving our code is the top priority
2) external libs always add maintenance effort, so there
must be a relevant enough advantage. We are not too
consistent in what we require, but often it is things
like that it's too complex for us to do, or it is new
and it will take some time to get it done ourselves
or it is there for us to be able to compare in a shared
environment (can make debugging/testing easier).

x264 is an example of code that was good enough to win
simply on being "too good" so "no matter how good or bad"
is not true.

But there's a lot of external projects we sometimes
with effort, sometimes easily managed to be (much) better.

Also, nobody reviews external libraries, and quite
a few of them have horrible portability or code quality
issues. Nothing obvious on FFTW, but check major libraries
like (not relevant to us) libLLVM, not offering a stable API
is one thing I can excuse, but they export symbols like
ConvertUTF8toUTF16 and isLegalUTF8String (!!!).
If compiler guys don't manage to follow basic best
practices, what do you think what kind of crap you can find
in most other random libs?
What about boost for example, knowingly including files
licensed under an incompatible license or not at all
in a tarball claiming to be licensed under the boost license?
Or the lagarith "lossless" codec relying on bitexact
x87 FPU operations so it can't decode unless compiled
for 32 bit x86 with specific compiler options?
Also always a question:  Will the upstream project be able to
handle security issues in a timely manner?
It's easy to be negatively surprised by libraries,
and it leaves a mark.
Which circles back to "no matter how good the code
of the external library". I don't know if the FFTW
code is in fact good, and it is not easy to find
out that kind of thing.

Not that we don't have enough issues with our code,
but it's at least our code and we deserve the blame
we get from it :)

> > I am in the habit of liking to call things silly
> > myself, but honestly almost all patches here
> > exist for a good reason, even if including
> > them is not a good idea, and I don't want to
> > discourage people from sending in interesting
> > but "silly" things just because they might be derided.
> 
> BTW, in case you want to know for e.g improving communication, this is
> not the first time. This has happened on multiple occassions before. I

Oh, I know it is quite common. I'm not the list policeman,
I just sometimes think it might be a good idea to complain a bit.

> actually very much appreciate Paul's and Clement's responses here.
> Unlike others here, they actually point out their fundamental
> objections at the beginning instead of showing some "fake interest",

No time to read the example and it sure happens, but
1) I don't mean to say people should pretend to agree, it's quite
possible to be firm and polite (but I'm not really angry with people
if they aren't, I just want to push things a bit).
2) "fake interest" might just be a case of it taking time.
If FFTW made some codec (not just the FFT part) 2x faster and
implementing the same optimizations in FFmpeg would mean adding
2000 lines of code I'd probably be in favour. Though based on
nothing I assume it's not even remotely like that.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] lavc/fft-test: update benchmark code

[Ganesh Ajjanagadde]

On Fri, Mar 25, 2016 at 7:53 AM, Michael Niedermayer
 wrote:
> On Thu, Mar 24, 2016 at 05:50:52PM -0700, Ganesh Ajjanagadde wrote:
>> 1. The most important change is the addition of a permute call to ensure
>> that the comparison between fftw and avfft is fair, since fftw does not
>> require the call. This is evident from the test code additions in the
>> previous commit, and also from http://www.fftw.org/benchfft/.
>
> So FFTW is slower than AVFFT
> but FFTW is faster than AVFFT + fft_permute ?

As can be seen from the benchmarks above, with  fft_permute it is not
a clear cut case, i.e for small lengths (< 512) they are roughly
similar, but performance of avfft tanks for longer lengths relative to
fftw.

BTW, fftw has multithreading options, these benches don't exercise them.

>
> or do i misunderstand ?

I did not give detailed info on this front, sorry. Turns out the
conclusions change, at least on my Haswell, fixed clock to 1.9 GHz
(same settings as for benches above). Without fft_permute, avfft is
faster throughout:
FFT 4 test
Checking...
max:0.00 e:0
Speed test...
time: 0.10 us/transform [total time=1.71 s its=16777216]
FFTW 4 test
Checking...
max:0.00 e:0
Speed test...
time: 0.11 us/transform [total time=1.86 s its=16777216]
FFT 8 test
Checking...
max:0.00 e:5.21541e-08
Speed test...
time: 0.11 us/transform [total time=1.88 s its=16777216]
FFTW 8 test
Checking...
max:0.00 e:6.70552e-08
Speed test...
time: 0.13 us/transform [total time=1.10 s its=8388608]
FFT 16 test
Checking...
max:0.00 e:8.73796e-08
Speed test...
time: 0.13 us/transform [total time=1.10 s its=8388608]
FFTW 16 test
Checking...
max:0.00 e:1.0382e-07
Speed test...
time: 0.17 us/transform [total time=1.40 s its=8388608]
FFT 32 test
Checking...
max:0.00 e:1.63922e-07
Speed test...
time: 0.07 us/transform [total time=1.10 s its=16777216]
FFTW 32 test
Checking...
max:0.00 e:1.92857e-07
Speed test...
time: 0.17 us/transform [total time=1.40 s its=8388608]
FFT 64 test
Checking...
max:0.01 e:3.09466e-07
Speed test...
time: 0.12 us/transform [total time=1.05 s its=8388608]
FFTW 64 test
Checking...
max:0.01 e:3.12211e-07
Speed test...
time: 0.24 us/transform [total time=1.03 s its=4194304]
FFT 128 test
Checking...
max:0.02 e:4.97895e-07
Speed test...
time: 0.26 us/transform [total time=1.11 s its=4194304]
FFTW 128 test
Checking...
max:0.02 e:6.00477e-07
Speed test...
time: 0.51 us/transform [total time=1.08 s its=2097152]
FFT 256 test
Checking...
max:0.03 e:8.80516e-07
Speed test...
time: 0.62 us/transform [total time=1.30 s its=2097152]
FFTW 256 test
Checking...
max:0.04 e:8.57262e-07
Speed test...
time: 0.80 us/transform [total time=1.67 s its=2097152]
FFT 512 test
Checking...
max:0.08 e:1.25487e-06
Speed test...
time: 1.28 us/transform [total time=1.35 s its=1048576]
FFTW 512 test
Checking...
max:0.04 e:1.31007e-06
Speed test...
time: 1.36 us/transform [total time=1.43 s its=1048576]
FFT 1024 test
Checking...
max:0.08 e:1.90538e-06
Speed test...
time: 2.75 us/transform [total time=1.44 s its=524288]
FFTW 1024 test
Checking...
max:0.10 e:1.94271e-06
Speed test...
time: 2.81 us/transform [total time=1.47 s its=524288]
FFT 2048 test
Checking...
max:0.15 e:2.83741e-06
Speed test...
time: 6.19 us/transform [total time=1.62 s its=262144]
FFTW 2048 test
Checking...
max:0.15 e:3.02253e-06
Speed test...
time: 7.18 us/transform [total time=1.88 s its=262144]
FFT 4096 test
Checking...
max:0.23 e:4.2942e-06
Speed test...
time: 15.24 us/transform [total time=2.00 s its=131072]
FFTW 4096 test
Checking...
max:0.23 e:4.43059e-06
Speed test...
time: 16.20 us/transform [total time=1.06 s its=65536]
FFT 8192 test
Checking...
max:0.31 e:6.37783e-06
Speed test...
time: 32.57 us/transform [total time=1.07 s its=32768]
FFTW 8192 test
Checking...
max:0.37 e:6.65281e-06
Speed test...
time: 37.62 us/transform [total time=1.23 s its=32768]
FFT 16384 test
Checking...
max:0.46 e:9.52666e-06
Speed test...
time: 70.86 us/transform [total time=1.16 s its=16384]
FFTW 16384 test
Checking...
max:0.46 e:1.00169e-05
Speed test...
time: 87.51 us/transform [total time=1.43 s its=16384]
FFT 32768 test
Checking...
max:0.76 e:1.39189e-05
Speed test...
time: 158.88 us/transform [total time=1.30 s its=8192]
FFTW 32768 test
Checking...
max:0.76 e:1.47434e-05
Speed test...
time: 196.77 us/transform [total time=1.61 s its=8192]

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> You can kill me, but you cannot change the truth.
>
> ___
> 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 0/4] fftw exploration (WIP)

[Hendrik Leppkes]

On Fri, Mar 25, 2016 at 4:23 PM, Hendrik Leppkes  wrote:
> On Fri, Mar 25, 2016 at 3:34 PM, Ganesh Ajjanagadde  
> wrote:
>> On Fri, Mar 25, 2016 at 12:35 AM, Clément Bœsch  wrote:
>>> On Thu, Mar 24, 2016 at 05:50:48PM -0700, Ganesh Ajjanagadde wrote:
 Ganesh Ajjanagadde (4):
   configure: add fftw3 detection
   lavc/fftw: add initial fftw wrapper
   lavc/fft-test: add FFTW3 tests
   lavc/fft-test: update benchmark code

>>>
>>> Why?
>>>
>>> Using an external library for such an essential component sounds like
>>> madness to me.
>>
>> I don't really understand. It is an opt-in dependency, and does not
>> have to be used. Seems like I don't really understand the FFmpeg
>> philosophy; there are a ton of optional libs in configure. FFT is not
>> used in all codecs, so I view it on the same lines as having things
>> like libopus based decoding instead of native FFmpeg decoding, the
>> multiple AAC encoders/decoders, the duplicate prores stuff, libnut on
>> top of the native demuxer, etc, etc.
>>
>
> The way I see it, external libraries should only be used if they
> provide actual features (for example new formats not otherwise
> supported, or access to hardware de/encoders), or a higher quality
> (ie. for encoders).
> Using external libraries for small performance gains seems rather
> overkill, resulting in code rot and maintenance burden.
>
> If performance is the only reason one might want an external library,
> then its a much better idea to try to optimize the code we have, that
> way more people automatically benefit from this, and we avoid this
> complexity.
>

Also for the record, most of the external libraries that duplicate
internal functionality existed before the internal functionality was
improved/implemented, or the current internal variant is still not
quite on the level.
Sometimes its just cruft that should probably be purged, just noone
did it yet. Sometimes we use the library for encoding, and also offer
decoding through the same (ie. fdk-aac, or libopus), which doesn't add
a "new" external library, just uses more of it.

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

Re: [FFmpeg-devel] [PATCH 0/4] fftw exploration (WIP)

[Hendrik Leppkes]

On Fri, Mar 25, 2016 at 3:34 PM, Ganesh Ajjanagadde  wrote:
> On Fri, Mar 25, 2016 at 12:35 AM, Clément Bœsch  wrote:
>> On Thu, Mar 24, 2016 at 05:50:48PM -0700, Ganesh Ajjanagadde wrote:
>>> Ganesh Ajjanagadde (4):
>>>   configure: add fftw3 detection
>>>   lavc/fftw: add initial fftw wrapper
>>>   lavc/fft-test: add FFTW3 tests
>>>   lavc/fft-test: update benchmark code
>>>
>>
>> Why?
>>
>> Using an external library for such an essential component sounds like
>> madness to me.
>
> I don't really understand. It is an opt-in dependency, and does not
> have to be used. Seems like I don't really understand the FFmpeg
> philosophy; there are a ton of optional libs in configure. FFT is not
> used in all codecs, so I view it on the same lines as having things
> like libopus based decoding instead of native FFmpeg decoding, the
> multiple AAC encoders/decoders, the duplicate prores stuff, libnut on
> top of the native demuxer, etc, etc.
>

The way I see it, external libraries should only be used if they
provide actual features (for example new formats not otherwise
supported, or access to hardware de/encoders), or a higher quality
(ie. for encoders).
Using external libraries for small performance gains seems rather
overkill, resulting in code rot and maintenance burden.

If performance is the only reason one might want an external library,
then its a much better idea to try to optimize the code we have, that
way more people automatically benefit from this, and we avoid this
complexity.

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

Re: [FFmpeg-devel] [PATCH 0/4] fftw exploration (WIP)

[Rostislav Pehlivanov]

On 25 March 2016 at 14:34, Ganesh Ajjanagadde  wrote:
>
> like libopus based decoding instead of native FFmpeg decoding,
>

The decoders differ in output on broken/invalid files made using libopusenc
(at extremely low bitrates, way below the 5k minimum the spec says).


> the multiple AAC encoders/decoders


Only one encoder (but has MIPS optimizations), 2 decoders mostly sharing
the same code - fixed and float. mp3 also has a fixed and float decoders.
The external libraries were mostly all dropped now, only libfdk-aac remains
because AAC-HE.


> the duplicate prores stuff,


Will be removed as soon as someone sends a patch to do so.


> libnut on top of the native demuxer, etc, etc.


I don't think libnut has seen any development in 3 or so years
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] license

[Carl Eugen Hoyos]

Chew Lam Tan  bes.com.sg> writes:

> We'd like to know how does the license work for the 
> above-mentioned development?

See https://www.ffmpeg.org/legal.html for the only 
license(s) that are available for the distribution 
of FFmpeg.
Don't forget to ask you lawyer all additional questions.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH 3/3] lavf/segment: add option to write empty filler segments as needed

[Stefano Sabatini]

On date Sunday 2016-03-06 20:49:24 -0600, Rodger Combs encoded:
> ---
>  doc/muxers.texi   | 5 +
>  libavformat/segment.c | 8 +++-
>  2 files changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index f2ad7fe..700ec88 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1224,6 +1224,11 @@ muxers/codecs. It is set to @code{0} by default.
>  @item initial_offset @var{offset}
>  Specify timestamp offset to apply to the output packet timestamps. The
>  argument must be a time duration specification, and defaults to 0.
> +
> +@item write_empty_segments @var{1|0}
> +If enabled, write an empty segment if there are no packets during the period 
> a
> +segment would usually span. Otherwise, the segment will be filled with the 
> next
> +packet written. Defaults to @code{0}.
>  @end table

Can you describe an use case for this (and possibly add a short
description in the log)?

>  
>  @subsection Examples
> diff --git a/libavformat/segment.c b/libavformat/segment.c
> index 6ad991f..df1514f 100644
> --- a/libavformat/segment.c
> +++ b/libavformat/segment.c
> @@ -116,6 +116,7 @@ typedef struct SegmentContext {
>  char *reference_stream_specifier; ///< reference stream specifier
>  int   reference_stream_index;
>  int   break_non_keyframes;
> +int   write_empty;
>  
>  int use_rename;
>  char temp_list_filename[1024];
> @@ -774,6 +775,7 @@ static int seg_write_packet(AVFormatContext *s, AVPacket 
> *pkt)
>  if (!seg->avf)
>  return AVERROR(EINVAL);
>  
> +calc_times:
>  if (seg->times) {
>  end_pts = seg->segment_count < seg->nb_times ?
>  seg->times[seg->segment_count] : INT64_MAX;
> @@ -805,7 +807,7 @@ static int seg_write_packet(AVFormatContext *s, AVPacket 
> *pkt)
>  
>  if (pkt->stream_index == seg->reference_stream_index &&
>  (pkt->flags & AV_PKT_FLAG_KEY || seg->break_non_keyframes) &&
> -seg->segment_frame_count > 0 &&
> +(seg->segment_frame_count > 0 || seg->write_empty) &&
>  (seg->cut_pending || seg->frame_count >= start_frame ||
>   (pkt->pts != AV_NOPTS_VALUE &&
>av_compare_ts(pkt->pts, st->time_base,
> @@ -825,6 +827,9 @@ static int seg_write_packet(AVFormatContext *s, AVPacket 
> *pkt)
>  seg->cur_entry.start_time = (double)pkt->pts * av_q2d(st->time_base);
>  seg->cur_entry.start_pts = av_rescale_q(pkt->pts, st->time_base, 
> AV_TIME_BASE_Q);
>  seg->cur_entry.end_time = seg->cur_entry.start_time;
> +

> +if (seg->times || (!seg->frames && !seg->use_clocktime) && 
> seg->write_empty)
> +goto calc_times;

what's the point of this goto?

[...]
-- 
FFmpeg = Funny and Frenzy Muttering Picky Emblematic Generator
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] lavc/fft-test: update benchmark code

[Michael Niedermayer]

On Fri, Mar 25, 2016 at 03:53:29PM +0100, Michael Niedermayer wrote:
> On Thu, Mar 24, 2016 at 05:50:52PM -0700, Ganesh Ajjanagadde wrote:
> > 1. The most important change is the addition of a permute call to ensure
> > that the comparison between fftw and avfft is fair, since fftw does not
> > require the call. This is evident from the test code additions in the
> > previous commit, and also from http://www.fftw.org/benchfft/.
> 
> So FFTW is slower than AVFFT
> but FFTW is faster than AVFFT + fft_permute ?
> 
> or do i misunderstand ?

iam raising this question mostly because if it is so then the question
if fft_permute is actually needed becomes very relevant to the
question, which is faster

also testing the FFT in an actual mainstream codec to see the overall
speed effect would be quite interresting.


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


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

Re: [FFmpeg-devel] [PATCH 4/4] lavc/fft-test: update benchmark code

[Michael Niedermayer]

On Thu, Mar 24, 2016 at 05:50:52PM -0700, Ganesh Ajjanagadde wrote:
> 1. The most important change is the addition of a permute call to ensure
> that the comparison between fftw and avfft is fair, since fftw does not
> require the call. This is evident from the test code additions in the
> previous commit, and also from http://www.fftw.org/benchfft/.

So FFTW is slower than AVFFT
but FFTW is faster than AVFFT + fft_permute ?

or do i misunderstand ?

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

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


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

Re: [FFmpeg-devel] [PATCH 1/4] configure: add fftw3 detection

[Ganesh Ajjanagadde]

On Fri, Mar 25, 2016 at 2:32 AM, Reimar Döffinger
 wrote:
> On Fri, Mar 25, 2016 at 10:05:09AM +0100, Paul B Mahol wrote:
>> On 3/25/16, Ganesh Ajjanagadde  wrote:
>> > { require libfdk_aac fdk-aac/aacenc_lib.h
>> > aacEncOpen -lfdk-aac &&
>> >   warn "using libfdk without pkg-config"; }
>> > }
>> > +enabled libfftw3  && require2 libfftw3f "fftw3.h" fftwf_execute
>> > -lfftw3f -lm
>> >  flite_libs="-lflite_cmu_time_awb -lflite_cmu_us_awb -lflite_cmu_us_kal
>> > -lflite_cmu_us_kal16 -lflite_cmu_us_rms -lflite_cmu_us_slt 
>> > -lflite_usenglish
>> > -lflite_cmulex -lflite"
>> >  enabled libflite  && require2 libflite "flite/flite.h" flite_init
>> > $flite_libs
>> >  enabled fontconfig&& enable libfontconfig
>> > --
>> > 2.7.4
>>
>> Big NO from me. Please refrain from doing such silly things.
>> Either improve our implementation or do nothing.
>
> I don't disagree with the basic objections, but
> I'd appreciate more diplomacy and kindness (and
> space for people to explain there motivations)
> in the responses.

To see if I understand the objections a bit better, how is this for a
one line summary:
FFmpeg does not like external libs, no matter how good or bad they are
relative to its own code, when it has internal code that does roughly
the same thing.

> I am in the habit of liking to call things silly
> myself, but honestly almost all patches here
> exist for a good reason, even if including
> them is not a good idea, and I don't want to
> discourage people from sending in interesting
> but "silly" things just because they might be derided.

BTW, in case you want to know for e.g improving communication, this is
not the first time. This has happened on multiple occassions before. I
actually very much appreciate Paul's and Clement's responses here.
Unlike others here, they actually point out their fundamental
objections at the beginning instead of showing some "fake interest",
wait until a thread completely develops before saying "no way":
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/184877.html.

Or also have a look at
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/184610.html.

> Sorry for the long off-topic.

Maybe off-topic, but it is good to get the record straight on this.

>
> Thanks,
> Reimar
> ___
> 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 0/4] fftw exploration (WIP)

[Ganesh Ajjanagadde]

On Fri, Mar 25, 2016 at 12:35 AM, Clément Bœsch  wrote:
> On Thu, Mar 24, 2016 at 05:50:48PM -0700, Ganesh Ajjanagadde wrote:
>> Ganesh Ajjanagadde (4):
>>   configure: add fftw3 detection
>>   lavc/fftw: add initial fftw wrapper
>>   lavc/fft-test: add FFTW3 tests
>>   lavc/fft-test: update benchmark code
>>
>
> Why?
>
> Using an external library for such an essential component sounds like
> madness to me.

I don't really understand. It is an opt-in dependency, and does not
have to be used. Seems like I don't really understand the FFmpeg
philosophy; there are a ton of optional libs in configure. FFT is not
used in all codecs, so I view it on the same lines as having things
like libopus based decoding instead of native FFmpeg decoding, the
multiple AAC encoders/decoders, the duplicate prores stuff, libnut on
top of the native demuxer, etc, etc.

>
> If you just want to do benchmarks, add a tool without a dependency in the
> configure, because otherwise it will end up being used in the codebase.

The intent was to see if it could be integrated into the codebase.
Seems like people here have knee jerk reactions to external libs for
whatever reason. I would be curious to hear a bit more so that I
understand this philo and avoid these things.

I recall some here interested in comparing FFTW with our
implementation. These patches have enabled reproduction of benchmarks.

>
> Regards,
>
> --
> Clément B.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavf/segment: slight refactor to seg_write_packet

[Stefano Sabatini]

On date Sunday 2016-03-06 20:49:23 -0600, Rodger Combs encoded:
> This reduces some code duplication, and ensures that cur_entry.last_duration 
> is
> always set.
> ---
>  libavformat/segment.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/libavformat/segment.c b/libavformat/segment.c
> index 818c0c9..6ad991f 100644
> --- a/libavformat/segment.c
> +++ b/libavformat/segment.c
> @@ -824,11 +824,13 @@ static int seg_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  seg->cur_entry.index = seg->segment_idx + seg->segment_idx_wrap * 
> seg->segment_idx_wrap_nb;
>  seg->cur_entry.start_time = (double)pkt->pts * av_q2d(st->time_base);
>  seg->cur_entry.start_pts = av_rescale_q(pkt->pts, st->time_base, 
> AV_TIME_BASE_Q);

> -seg->cur_entry.end_time = seg->cur_entry.start_time +
> -pkt->pts != AV_NOPTS_VALUE ? (double)(pkt->pts + pkt->duration) 
> * av_q2d(st->time_base) : 0;

Unrelated, this looks wrong

> -} else if (pkt->pts != AV_NOPTS_VALUE && pkt->stream_index == 
> seg->reference_stream_index) {
> -seg->cur_entry.end_time =
> -FFMAX(seg->cur_entry.end_time, (double)(pkt->pts + 
> pkt->duration) * av_q2d(st->time_base));
> +seg->cur_entry.end_time = seg->cur_entry.start_time;
> +}
> +
> +if (pkt->stream_index == seg->reference_stream_index) {
> +if (pkt->pts != AV_NOPTS_VALUE)
> +seg->cur_entry.end_time =
> +FFMAX(seg->cur_entry.end_time, (double)(pkt->pts + 
> pkt->duration) * av_q2d(st->time_base));
>  seg->cur_entry.last_duration = pkt->duration;

LGTM (and fixes the defect), thanks.
-- 
FFmpeg = Formidable and Fascinating Multimedia Powered Elegant Gnome
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] lavf/segment: style nit

[Stefano Sabatini]

On date Sunday 2016-03-06 20:49:22 -0600, Rodger Combs encoded:
> ---
>  libavformat/segment.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/segment.c b/libavformat/segment.c
> index dd3b092..818c0c9 100644
> --- a/libavformat/segment.c
> +++ b/libavformat/segment.c
> @@ -809,7 +809,7 @@ static int seg_write_packet(AVFormatContext *s, AVPacket 
> *pkt)
>  (seg->cut_pending || seg->frame_count >= start_frame ||
>   (pkt->pts != AV_NOPTS_VALUE &&
>av_compare_ts(pkt->pts, st->time_base,
> -end_pts-seg->time_delta, AV_TIME_BASE_Q) >= 0))) {
> +end_pts - seg->time_delta, AV_TIME_BASE_Q) >= 0))) {
>  /* sanitize end time in case last packet didn't have a defined 
> duration */
>  if (seg->cur_entry.last_duration == 0)
>  seg->cur_entry.end_time = (double)pkt->pts * 
> av_q2d(st->time_base);

LGTM.
-- 
FFmpeg = Faithful & Frenzy Multimedia Philosofic Emblematic Geek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/jpeg2000dec: add slice threading support

[Paul B Mahol]

Hi,

patch attached.
From 695cd4e4c6845a3b6c74d15e07b36df30da2f1b8 Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Fri, 25 Mar 2016 14:33:15 +0100
Subject: [PATCH] avcodec/jpeg2000dec: add slice threading support

Signed-off-by: Paul B Mahol 
---
 libavcodec/jpeg2000dec.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 962b7bc..e9f5f51 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -1755,9 +1755,12 @@ WRITE_FRAME(16, uint16_t)
 
 #undef WRITE_FRAME
 
-static int jpeg2000_decode_tile(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
-AVFrame *picture)
+static int jpeg2000_decode_tile(AVCodecContext *avctx, void *td,
+int jobnr, int threadnr)
 {
+Jpeg2000DecoderContext *s = avctx->priv_data;
+AVFrame *picture = td;
+Jpeg2000Tile *tile = s->tile + jobnr;
 int x;
 
 tile_codeblocks(s, tile);
@@ -2067,7 +2070,7 @@ static int jpeg2000_decode_frame(AVCodecContext *avctx, void *data,
 Jpeg2000DecoderContext *s = avctx->priv_data;
 ThreadFrame frame = { .f = data };
 AVFrame *picture = data;
-int tileno, ret;
+int ret;
 
 s->avctx = avctx;
 bytestream2_init(>g, avpkt->data, avpkt->size);
@@ -2114,9 +2117,7 @@ static int jpeg2000_decode_frame(AVCodecContext *avctx, void *data,
 if (ret = jpeg2000_read_bitstream_packets(s))
 goto end;
 
-for (tileno = 0; tileno < s->numXtiles * s->numYtiles; tileno++)
-if (ret = jpeg2000_decode_tile(s, s->tile + tileno, picture))
-goto end;
+avctx->execute2(avctx, jpeg2000_decode_tile, picture, NULL, s->numXtiles * s->numYtiles);
 
 jpeg2000_dec_cleanup(s);
 
@@ -2159,7 +2160,7 @@ AVCodec ff_jpeg2000_decoder = {
 .long_name= NULL_IF_CONFIG_SMALL("JPEG 2000"),
 .type = AVMEDIA_TYPE_VIDEO,
 .id   = AV_CODEC_ID_JPEG2000,
-.capabilities = AV_CODEC_CAP_FRAME_THREADS | AV_CODEC_CAP_DR1,
+.capabilities = AV_CODEC_CAP_SLICE_THREADS | AV_CODEC_CAP_FRAME_THREADS | AV_CODEC_CAP_DR1,
 .priv_data_size   = sizeof(Jpeg2000DecoderContext),
 .init_static_data = jpeg2000_init_static_data,
 .init = jpeg2000_decode_init,
-- 
1.9.1

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

[FFmpeg-devel] [PATCH]avcodec/jpeg2000dec: silence invalid error message

[Paul B Mahol]

Hi,

patch attached.
From 155ea9e6063553b8f7db83698faf428eaa1f8c04 Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Fri, 25 Mar 2016 11:22:39 +0100
Subject: [PATCH] avcodec/jpeg2000dec: account two last bytes from end of
 bytestream as EOC marker

This silences missing EOC marker when decoding j2k files with Psot set to 0.

Signed-off-by: Paul B Mahol 
---
 libavcodec/jpeg2000dec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index c13670e..962b7bc 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -737,9 +737,9 @@ static int get_sot(Jpeg2000DecoderContext *s, int n)
 bytestream2_get_byteu(>g);   // TNsot
 
 if (!Psot)
-Psot = bytestream2_get_bytes_left(>g) + n + 2;
+Psot = bytestream2_get_bytes_left(>g) - 2 + n + 2;
 
-if (Psot > bytestream2_get_bytes_left(>g) + n + 2) {
+if (Psot > bytestream2_get_bytes_left(>g) - 2 + n + 2) {
 av_log(s->avctx, AV_LOG_ERROR, "Psot %"PRIu32" too big\n", Psot);
 return AVERROR_INVALIDDATA;
 }
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH 1/4] configure: add fftw3 detection

[Reimar Döffinger]

On Fri, Mar 25, 2016 at 10:05:09AM +0100, Paul B Mahol wrote:
> On 3/25/16, Ganesh Ajjanagadde  wrote:
> > { require libfdk_aac fdk-aac/aacenc_lib.h
> > aacEncOpen -lfdk-aac &&
> >   warn "using libfdk without pkg-config"; }
> > }
> > +enabled libfftw3  && require2 libfftw3f "fftw3.h" fftwf_execute
> > -lfftw3f -lm
> >  flite_libs="-lflite_cmu_time_awb -lflite_cmu_us_awb -lflite_cmu_us_kal
> > -lflite_cmu_us_kal16 -lflite_cmu_us_rms -lflite_cmu_us_slt -lflite_usenglish
> > -lflite_cmulex -lflite"
> >  enabled libflite  && require2 libflite "flite/flite.h" flite_init
> > $flite_libs
> >  enabled fontconfig&& enable libfontconfig
> > --
> > 2.7.4
> 
> Big NO from me. Please refrain from doing such silly things.
> Either improve our implementation or do nothing.

I don't disagree with the basic objections, but
I'd appreciate more diplomacy and kindness (and
space for people to explain there motivations)
in the responses.
I am in the habit of liking to call things silly
myself, but honestly almost all patches here
exist for a good reason, even if including
them is not a good idea, and I don't want to
discourage people from sending in interesting
but "silly" things just because they might be derided.
Sorry for the long off-topic.

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

Re: [FFmpeg-devel] [PATCH] avformat/segment: set format options for all segments

[Stefano Sabatini]

On date Tuesday 2016-03-15 19:21:23 +0100, Marton Balint encoded:
> Fixes ticket #5318.
> 
> Signed-off-by: Marton Balint 
> ---
>  libavformat/segment.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/segment.c b/libavformat/segment.c
> index ccedd04..70590b4 100644
> --- a/libavformat/segment.c
> +++ b/libavformat/segment.c
> @@ -256,7 +256,11 @@ static int segment_start(AVFormatContext *s, int 
> write_header)
>  av_opt_set(oc->priv_data, "mpegts_flags", "+resend_headers", 0);
>  
>  if (write_header) {
> -if ((err = avformat_write_header(oc, NULL)) < 0)
> +AVDictionary *options = NULL;
> +av_dict_copy(, seg->format_options, 0);
> +err = avformat_write_header(oc, );
> +av_dict_free();
> +if (err < 0)
>  return err;
>  }

LGTM, missed the patch, thanks.
-- 
FFmpeg = Formidable and Forgiving Minimal Proud Ecumenical Gorilla
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] lavc/audiotoolboxdec: fix a number of config and timestamp issues

[pon pon]

2016-03-25 0:40 GMT+09:00 Rodger Combs :

> Fixed with this patch:
>
> i tested

there are some errors patch decoding and encoding.

patch error
patch -p1 < "audiotoolboxenc_fixed_1_remove unneeded packet metadata.patch"
patch unexpectedly ends in middle of line

decoding error (aac and ac3 are tested)
ac3 2ch and ac3 5.1ch is false.

encoding error (aac, alac, pcm_alaw, pcm_mulaw  are tested. 5.1->5.1 and
5.1->2. channel mapping isn't examined)
aac from 5.1ch to 5.1ch. alac from 5.1ch to 5.1ch, and alac from 5.1ch to
2ch are false.

logs are attached

ponpon


ac3_2ch.log
Description: Binary data


ac3_51ch.log
Description: Binary data


to_aac_5ch_to_5ch.log
Description: Binary data


to_alac_5ch_to_2ch.log
Description: Binary data


to_alac_5ch_to_5ch.log
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] configure: add fftw3 detection

[Paul B Mahol]

On 3/25/16, Ganesh Ajjanagadde  wrote:
> Useful for fast FFT computation: http://www.fftw.org/.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  configure | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/configure b/configure
> index 0987bcd..9a9a36d 100755
> --- a/configure
> +++ b/configure
> @@ -222,6 +222,7 @@ External library support:
>--enable-libdcadec   enable DCA decoding via libdcadec [no]
>--enable-libfaac enable AAC encoding via libfaac [no]
>--enable-libfdk-aac  enable AAC de/encoding via libfdk-aac [no]
> +  --enable-libfftw3enable FFT computation via libfftw3 [no]
>--enable-libfliteenable flite (voice synthesis) support via
> libflite [no]
>--enable-libfreetype enable libfreetype, needed for drawtext filter
> [no]
>--enable-libfribidi  enable libfribidi, improves drawtext filter [no]
> @@ -1471,6 +1472,7 @@ EXTERNAL_LIBRARY_LIST="
>  libdcadec
>  libfaac
>  libfdk_aac
> +libfftw3
>  libflite
>  libfontconfig
>  libfreetype
> @@ -4937,6 +4939,7 @@ die_license_disabled_gpl() {
>
>  die_license_disabled gpl frei0r
>  die_license_disabled gpl libcdio
> +die_license_disabled gpl libfftw3
>  die_license_disabled gpl librubberband
>  die_license_disabled gpl libsmbclient
>  die_license_disabled gpl libutvideo
> @@ -5536,6 +5539,7 @@ enabled libfaac   && require2 libfaac
> "stdint.h faac.h" faacEncGetVersio
>  enabled libfdk_aac&& { use_pkg_config fdk-aac
> "fdk-aac/aacenc_lib.h" aacEncOpen ||
> { require libfdk_aac fdk-aac/aacenc_lib.h
> aacEncOpen -lfdk-aac &&
>   warn "using libfdk without pkg-config"; }
> }
> +enabled libfftw3  && require2 libfftw3f "fftw3.h" fftwf_execute
> -lfftw3f -lm
>  flite_libs="-lflite_cmu_time_awb -lflite_cmu_us_awb -lflite_cmu_us_kal
> -lflite_cmu_us_kal16 -lflite_cmu_us_rms -lflite_cmu_us_slt -lflite_usenglish
> -lflite_cmulex -lflite"
>  enabled libflite  && require2 libflite "flite/flite.h" flite_init
> $flite_libs
>  enabled fontconfig&& enable libfontconfig
> --
> 2.7.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Big NO from me. Please refrain from doing such silly things.
Either improve our implementation or do nothing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/4] fftw exploration (WIP)

[Clément Bœsch]

On Thu, Mar 24, 2016 at 05:50:48PM -0700, Ganesh Ajjanagadde wrote:
> Ganesh Ajjanagadde (4):
>   configure: add fftw3 detection
>   lavc/fftw: add initial fftw wrapper
>   lavc/fft-test: add FFTW3 tests
>   lavc/fft-test: update benchmark code
> 

Why?

Using an external library for such an essential component sounds like
madness to me.

If you just want to do benchmarks, add a tool without a dependency in the
configure, because otherwise it will end up being used in the codebase.

Regards,

-- 
Clément B.


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