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

[pon pon]

2016-03-28 2:20 GMT+09:00 Rodger Combs :

> - ADTS-formatted AAC didn't work
> - Channel layouts were never exported
> - Channel mappings were incorrect beyond stereo
> - Channel counts weren't updated after packets were decoded
> - Timestamps were exported incorrectly
> ---
>
>

patching is fixed and all errors of encoding are fixed but there are errors
of ac3 decoding.
logs are attached

ponpon


ac3_file_2ch.log
Description: Binary data


ac3_file_51ch.log
Description: Binary data


ac3_in_mkv_2ch.log
Description: Binary data


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

Re: [FFmpeg-devel] [PATCH 3/6] lavc/audiotoolboxenc: fix iOS build

[crossle song]

Work well on iPhone 6, but on  iPhone 4S iOS 9.0, return  [aac_at @
0x1702a400] Encode error: -50, can not work

On Mon, Mar 28, 2016 at 8:47 AM, Michael Niedermayer  wrote:

> On Sun, Mar 27, 2016 at 12:20:24PM -0500, Rodger Combs wrote:
> > ---
> >  libavcodec/audiotoolboxenc.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
>
> does this fix?
>
> http://fate.ffmpeg.org/report.cgi?time=20160323070044=arm64-darwin-clang-apple-6.0
>
> should be ok
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> When the tyrant has disposed of foreign enemies by conquest or treaty, and
> there is nothing more to fear from them, then he is always stirring up
> some war or other, in order that the people may require a leader. -- Plato
>
> ___
> 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 3/6] lavc/audiotoolboxenc: fix iOS build

[Michael Niedermayer]

On Sun, Mar 27, 2016 at 12:20:24PM -0500, Rodger Combs wrote:
> ---
>  libavcodec/audiotoolboxenc.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

does this fix?
http://fate.ffmpeg.org/report.cgi?time=20160323070044=arm64-darwin-clang-apple-6.0

should be ok

thx

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

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


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

[FFmpeg-devel] [PATCH] doc/developer.texi: Add a code of conduct

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 doc/developer.texi |   29 +
 1 file changed, 29 insertions(+)

diff --git a/doc/developer.texi b/doc/developer.texi
index 6db93ce..b3928d3 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -403,6 +403,35 @@ finding a new maintainer and also don't forget to update 
the @file{MAINTAINERS}
 
 We think our rules are not too hard. If you have comments, contact us.
 
+@section Code of conduct
+
+Be friendly and respectful towards others and third parties.
+Treat others the way you yourself want to be treated.
+
+Be considerate. Not everyone shares the same viewpoint and priorities as you 
do.
+Different opinions and interpretations help the project.
+Looking at issues from a different perspective assists development.
+
+Do not assume malice for things that can be attributed to incompetence. Even if
+it is malice its rarely good to start with that as initial assumption.
+
+Stay friendly even if someone acts contrarily. Everyone has a bad day
+once in a while.
+If you yourself have a bad day or are angry then try to take a break and reply
+once you are calm and without anger if you have to.
+
+Try to help other team members and cooperate if you can.
+
+The goal of Software development is to create technical excellence, not for any
+individual to be better and "win" against the others. Large software projects
+are only possible and successful through teamwork.
+
+If someone struggles do not put them down. Give them a helping hand
+instead and point them in the right direction.
+
+Finally, keep in mind the immortal words of Bill and Ted,
+"Be excellent to each other."
+
 @anchor{Submitting patches}
 @section Submitting patches
 
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH] doc/developer.texi: Add a code of conduct

[Michael Niedermayer]

Hi

On Sat, Mar 26, 2016 at 09:28:08PM +0100, Thilo Borgmann wrote:
> Am 26.03.16 um 15:00 schrieb Josh de Kock:
> > On 26/03/2016 13:28, Michael Niedermayer wrote:
> >> +@section Code of conduct
> >> +
> >> +Respect other people, treat others the way you yourself want to be 
> >> treated.
> > The Code of Conduct is simple, and is based around a few key points:
> 
> No ',', I think, just plain "and".
> 
> 
> > *insert goal of project here*
> > 
> > Be friendly & respectful.
> 
> ... and ...
> 
> 
> > This is the most simple point; treat others the way you would like to be
> > treated.
> 
> ... point: Treat others...
> 
> 
> >> +Be tolerant to differences in oppinion, people often have different 
> >> priorities
> >> +and may see a problem from a different viewpoint.
> >> +Do not assume mallice for things that can be attributed to incompetence. 
> >> Even if
> >> +it is mallice its rarely good to start with that as initial assumtation.
> 
> > Be considerate.
> > Not everyone has the viewpoint as you; different opinions, and
> > interpretations help the project, as looking at issues from a different
> > angle can assist development.
> 
> Be considerate. Not everyone shares the same viewpoint as you do.
> Different opinions and interpretations help the project.
> Looking at issues from a different perspective assists development.
> 
> 
> >> +Act friendly towards others and about 3rd parties.
> 
> Act friendly towards others and third parties.
> 
> 
> >> +Be friendly when someone once has a bad day or is angry and acts 
> >> unfriendly.
> >> +Everyone has a bad day once in a while.
> 
> Stay friendly even if someone acts contrarily. Everyone has a bad day
> once in a while.
> 
> 
> >> +If you yourself have a bad day or are angry then try to take a break and 
> >> reply
> >> +once you are calm and without anger if you have to.
> 
> If it is you who misbehaved in such a way, try to take a break and
> continue to reply once you are in a good mood again.
> 
> 
> >> +Help other teammembers if you can instead of trying to personally gain 
> >> from not helping.
> 
> Try to help other team members and cooperate if you can.
> 
> 
> >> +The goal of Software development is to create technical excellence, not 
> >> for any
> >> +individual to be better and "win" against the others. Large software 
> >> projects
> >> +are only possible and successfull through teamwork.
> > This is open source, it's for the common good.
> 
> This is open source and it is for the common good.
> 
> 
> > Remember that there are others who try to benefit from the project, and
> > in different ways. Some want to use it, some want to contribute to it,
> > but the main thing is that we all have a goal--to help each other. 
> 
> Remember that there are other who try to benefit from the project in
> different ways. There are users and contributors but everyone shares our
> common goal of helping each other.
> 
> 
> > If you see someone struggling with something, rather than putting them
> > down, why not help them? Give them some pointers, or show them in the
> > right direction.
> 
> If someone struggles do not put them down. Give them a helping hand
> instead and point them in the right direction.
> 
> 
> >> +Or maybe all that can be condensed into Bill and Teds words
> > However, all these point can easily be summarised using Bill & Ted's
> > words: "Be excellent to each other."
> 
> Finally, ... "Be excellent to each other."
> 
> 
> 
> I think I might have made it a little better. However, I'm far from
> being a native speaker.

ive made most suggested changes, ive left some things in though and
for example didnt add
"but everyone shares our common goal of helping each other."
as this is more an ideal than what actually is.


I also skiped some of the changes suggested at the top as they sounded
odd to me..

slight changes to remove duplication and to fit things together

will post a new patch soon

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] Linking to C++ version of openjpeg

[Aaron Boxer]

On Sun, Mar 27, 2016 at 7:35 PM, Michael Bradshaw  wrote:

> Hi Aaron,
>
> This mailing list is intended for the development of FFmpeg itself. It
> sounds like you're working on your own project or personal
> customizations (without the plan of trying to upstream the changes
> into the mainline FFmpeg code), in which case the libav-user mailing
> list sounds like the more appropriate mailing list to use.
>

Thanks, Michael. I will move this discussion to the users mailing list.

Aaron



>
> On Sun, Mar 27, 2016 at 11:49 AM, Aaron Boxer  wrote:
> > On Sun, Mar 27, 2016 at 2:39 PM, Aaron Boxer  wrote:
> >
> >> Hello Again,
> >>
> >> I have a C++ version of openjpeg that I would like to use with FFmpeg -
> >> this
> >> library is going to be statically linked, just like the C version of
> >> openjpeg.
> >>
> >> Are there any special flags I need to set to link with the C++ version,
> >> which uses the STL and C++11 ?
> >>
> >
> > I tried adding -std=c++0x  to the extra c flags, but when I looked at
> > config.log, I was these flags sent to gcc:
> >
> > -std=c++0x  -std=c99
> >
> > So, it seems that c99 is over-riding c++0x.
>
> You shouldn't be adding C++ flags to C flags (they're different
> languages, after all). You can use the --extra-cxxflags= parameter in
> ./configure to pass extra C++ flags to the compiler.
> ___
> 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.

[Hendrik Leppkes]

On Mon, Mar 28, 2016 at 12:10 AM, Thilo Borgmann  wrote:
> Am 26.03.16 um 01:49 schrieb 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.
>
> Yes there was a ping and obviously at least wm4 himself thinks so, too.
> Go ahead and tell me that wm4 replying to it a minute a minute later
> has happened by chance and not because of my ping.

Did you switch to private mails in the middle of the patch review?
Because I certainly see nothing of this sort.
There is two mails from wm4, one as a response to the original mail
with the initial concerns, and one days after one of your mails, no
response within minutes anywhere from him.

>
>
>> 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.
>
> What is exactly what has happened. From my viewpoint at least. Obviously
> wm4 and you don't think that not replying anymore leads to silent
> approval - I do. This seems to be what we are talking about.

People that don't speak up at all may approve silently (or at least
not disapprove), someone that raised issues should give an explicit
OK/Nevermind/whatever, agreeing with you or withdrawing his
complaints, there is no "silent" option there.

You seem to assume a lot about your fellow developers, maybe we can
just agree that you'll be more explicit in the future and assume less
to know what others might mean or want?

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

Re: [FFmpeg-devel] Linking to C++ version of openjpeg

[Michael Bradshaw]

Hi Aaron,

This mailing list is intended for the development of FFmpeg itself. It
sounds like you're working on your own project or personal
customizations (without the plan of trying to upstream the changes
into the mainline FFmpeg code), in which case the libav-user mailing
list sounds like the more appropriate mailing list to use.

On Sun, Mar 27, 2016 at 11:49 AM, Aaron Boxer  wrote:
> On Sun, Mar 27, 2016 at 2:39 PM, Aaron Boxer  wrote:
>
>> Hello Again,
>>
>> I have a C++ version of openjpeg that I would like to use with FFmpeg -
>> this
>> library is going to be statically linked, just like the C version of
>> openjpeg.
>>
>> Are there any special flags I need to set to link with the C++ version,
>> which uses the STL and C++11 ?
>>
>
> I tried adding -std=c++0x  to the extra c flags, but when I looked at
> config.log, I was these flags sent to gcc:
>
> -std=c++0x  -std=c99
>
> So, it seems that c99 is over-riding c++0x.

You shouldn't be adding C++ flags to C flags (they're different
languages, after all). You can use the --extra-cxxflags= parameter in
./configure to pass extra C++ flags to the compiler.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]Addition of MLP encoder

[Michael Niedermayer]

On Sun, Mar 27, 2016 at 11:01:11AM +0530, Disha Singh wrote:
> > testing this
> > ./ffmpeg -i in.m4a test.mlp
> > says it needs  'To use it anyways, you must set "-strict inofficial".'
> > thats ok if it would work:
> >
> > ./ffmpeg -i in.m4a -strict inofficial test.mlp
> > [mlp @ 0x2494740] Unable to parse option value "inofficial"
> >
> > Using :ffmpeg -i ~/input.mp3 -strict -unofficial -strict -2 -c:a mlp
> ~/output.mkv " gave me :
> 
>  [matroska @ 0x2bebe40] Timestamps are unset in a packet for stream 1. This
> is deprecated and will stop working in the future. Fix your code to set the
> timestamps properly
> [matroska @ 0x2bebe40] Encoder did not produce proper pts, making some up.
> Segmentation fault (core dumped)
> 
>  I know why segfault comes but what is the timestamp error ?

setting the AVPacket.pts should help, see how its done in other
encoders

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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

Re: [FFmpeg-devel] [PATCH] doc/developer.texi: Add a code of conduct

[Thilo Borgmann]

Am 26.03.16 um 21:28 schrieb Thilo Borgmann:
> [...]
>> Remember that there are others who try to benefit from the project, and
>> in different ways. Some want to use it, some want to contribute to it,
>> but the main thing is that we all have a goal--to help each other. 
> 
> Remember that there are other who try to benefit from the project in
  ^ -> others

-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 26.03.16 um 01:49 schrieb 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.

Yes there was a ping and obviously at least wm4 himself thinks so, too.
Go ahead and tell me that wm4 replying to it a minute a minute later
has happened by chance and not because of my ping.


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

What is exactly what has happened. From my viewpoint at least. Obviously
wm4 and you don't think that not replying anymore leads to silent
approval - I do. This seems to be what we are talking about.

After wm4's first response, I answered with stating my motivation and
concerns about the alternatives that came to mind.
Then he was silent. This I would already call to be sorted out.
After my ping he basically repeated his statement and remained silent
again although I explicitly asked him for his suggestions this time.
This is what you call in the middle of discussion?

If we were actually sorting something out I would never have pushed
anything but that was just not the case. If that would have been the
case, don't you think there would already be a tremendous shitstorm
going down on me?


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

From my point of view it was implicitly OK'ed after the last review of
patch 2 and ongoing silence after my ping.

-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 27.03.16 um 15:53 schrieb wm4:
> On Sat, 26 Mar 2016 01:12:17 +0100
> Thilo Borgmann  wrote:
> 
>> 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 

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/utils: fix packet duration of frames with discarded paddings

[Hendrik Leppkes]

On Sun, Mar 27, 2016 at 6:09 PM, Marton Balint  wrote:
> Signed-off-by: Marton Balint 
> ---
>  libavcodec/utils.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index c625bbc..073c6fa 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -2337,8 +2337,7 @@ int attribute_align_arg 
> avcodec_decode_audio4(AVCodecContext *avctx,
>  int64_t diff_ts = av_rescale_q(frame->nb_samples - 
> discard_padding,
> (AVRational){1, 
> avctx->sample_rate},
> avctx->pkt_timebase);
> -if (av_frame_get_pkt_duration(frame) >= diff_ts)
> -av_frame_set_pkt_duration(frame, 
> av_frame_get_pkt_duration(frame) - diff_ts);
> +av_frame_set_pkt_duration(frame, diff_ts);
>  } else {
>  av_log(avctx, AV_LOG_WARNING, "Could not update 
> timestamps for discarded samples.\n");
>  }
> --
> 2.6.2

Looks correct to me.

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

Re: [FFmpeg-devel] [PATCH] lavc/mediacodec: fix zero stride for OMX.allwinner.video.decoder.avc

[Kirill Gavrilov]

Hi,

on my device ("OMX.allwinner.video.decoder.avc") returned stride property
is always 0.
I have found that stride is overridden for "OMX.SEC.avc.dec" and prepared
the similar patch.
But probably it is better to change comparison at the line above to "value
> 0"?
>s->stride = value >= 0 ? value : s->width

---
Kirill Gavrilov,
Software designer.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavc/mediacodec: fix zero stride for OMX.allwinner.video.decoder.avc

[Kirill Gavrilov]

---
 libavcodec/mediacodecdec.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index d385651..b6e7c46 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -266,6 +266,8 @@ static int mediacodec_dec_parse_format(AVCodecContext 
*avctx, MediaCodecDecConte
 } else if (strstr(s->codec_name, "OMX.SEC.avc.dec")) {
 s->slice_height = avctx->height;
 s->stride = avctx->width;
+} else if (strstr(s->codec_name, "OMX.allwinner.video.decoder.avc")) {
+s->stride = avctx->width;
 }
 
 if (!ff_AMediaFormat_getInt32(s->format, "color-format", )) {
-- 
1.9.1

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

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

[Michael Niedermayer]

On Sun, Mar 27, 2016 at 07:08:00PM +0200, Timo Rothenpieler wrote:
> ping

LGTM

thx

[..]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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

Re: [FFmpeg-devel] FFmpeg code Attribution

[Aaron Boxer]

On Sun, Mar 27, 2016 at 4:10 PM, Michael Niedermayer  wrote:

> On Thu, Mar 24, 2016 at 03:03:01PM +, Carl Eugen Hoyos wrote:
> > Aaron Boxer  gmail.com> writes:
> >
> > > Anyways, the important thing here is to ensure that
> > > code from other projects gets proper attribution.
> >
> > Then please send a patch that adds the attribution,
> > remember that it is based on old libopenjpeg code,
> > Reimar already provided an appropriate line.
>
> can someone please post a patch to resolve this
>

I can do that by the end of the week.  For the patch, may I just stage the
changed files
and run

git diff --cached

?

Thanks,
Aaron


>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Everything should be made as simple as possible, but not simpler.
> -- Albert Einstein
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg code Attribution

[Michael Niedermayer]

On Thu, Mar 24, 2016 at 03:03:01PM +, Carl Eugen Hoyos wrote:
> Aaron Boxer  gmail.com> writes:
> 
> > Anyways, the important thing here is to ensure that 
> > code from other projects gets proper attribution.
> 
> Then please send a patch that adds the attribution, 
> remember that it is based on old libopenjpeg code, 
> Reimar already provided an appropriate line.

can someone please post a patch to resolve this


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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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] avfilter/vf_colormatrix: add 10 & 12 bit depth support

[Thomas Mundt]

>>>Kieran Kunhya  schrieb am So, 27.3.2016:
> On Sun, 27 Mar 2016 at 13:22 Thomas Mundt  
> wrote:
> 
>> Ronald S. Bultje  schrieb am So, 27.3.2016:
>> > On Sun, Mar 27, 2016 at 7:09 AM, Thomas Mundt > ffmpeg.org> wrote:
>> >
>> >> >>>Ronald S. Bultje  schrieb am Sa, 26.3.2016:
>> >> > On Sat, Mar 26, 2016 at 10:04 AM, Thomas Mundt > at
>> >> ffmpeg.org> wrote:
>> >> >
>> >> >Kieran Kunhya  schrieb am Sa, 26.3.2016:
>> >> >> >> On Fri, 25 Mar 2016 at 22:32 Thomas Mundt > at>
>> >> ffmpeg.org> wrote:
>> >> >> >
>> >> >> >> Signed-off-by: Thomas Mundt 
>> >> >> >> ---
>> >> >> >>  libavfilter/vf_colormatrix.c | 182
>> >> >> >> ++-
>> >> >> >>
>> >> >>> >
>> >> >> > These functions are basically the same, have you considered
>> factoring
>> >> the
>> >> >> > code out?
>> >> >> >
>> >> >> > Kieran
>> >> >>
>> >> >> I thought keeping it seperate would be easier to review.
>> >> >> But I can do that. Maybe as a subsequent patch?
>> >> >
>> >> >
>> >> > I think he means templating out typelessly like h264/hevc/vp9 do. I
>> agree
>> >> > that would probably be nicer. Binary size is same but less duplicated
>> >> code.
>> >> >
>> >> > Ronald
>> >>
>> >> Okay, I tried to solve this with the use of macros. The attached file is
>> >> the result (interesting part starting at line 203).
>> >> It works, but I´m not sure if this is what you expect.
>> >> Also I didn´t find a way factoring out the two different av_clip.
>> >> One could replace av_clip_uint8 by av_clip with limits 0 and 255. But
>> this
>> >> would have an impact on speed.
>> >> If there is a more elegant way, could you please provide a short
>> example?!
>> >
>> >
>> > We don't like macros, but you're surprisingly close. Have a look at
>> > libavcodec/bit_depth_template.c and grep for its usage in libavcodec.
>> >
>> > You'll end up with a vf_colormatrixdsp_template.c file, which includes
>> > bit_depth_template.c for types/clips etc., and it will then define full
>> > functions per bit depth. This is included in vf_colormatrixdsp.c, and
>> that
>> > defines the actual dsp functions which do the core of what this filter
>> does.
>> >
>> > Since it's now in a dsp file, it'll be trivial to write x86 simd for it
>> > (which I have also in the works).
>> >
>> > Ronald
>>
>> I looked into this and sadly have to say that this would take much more
>> time than I have atm.
>> I´m not a professional programmer so I would have to fiddle out the most
>> things.
>> Sorry, but then I think it´s maybe better to drop the high bit depht
>> support patch for now.
>>
> 
> This may help:
> http://blog.pkh.me/p/20-templating-in-c.html
> 
> Kieran

I tried to come along with this for almost 3 hours with very small progress.
The link was helpful, but I need a free mind for learning. This is not possible 
atm since I´m also involved in other things and time is short.
So again sorry, but I have to stop here.

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

Re: [FFmpeg-devel] [PATCH]lavc/fic: Be less verbose for invisible or empty cursor

[Moritz Barsnick]

On Sat, Mar 26, 2016 at 14:24:53 +0100, Carl Eugen Hoyos wrote:
> -av_log(avctx, AV_LOG_WARNING,
> +av_log(avctx, AV_LOG_DEBUG,
> "Invalid cursor position: (%d,%d). Skipping cusor.\n",
"Unrelated fix", but you might as well fix the typo:  ^

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

Re: [FFmpeg-devel] [PATCH] Added more tests to libswscale/utils.c

[Michael Niedermayer]

On Sun, Mar 27, 2016 at 04:39:39PM +, Petru Rares Sincraian wrote:
> 
>   - Added test for: swscale_license()
>   - Added test for: alphaless_fmt()
>   - Added test for: alloc_gamma_tbl()
[...]

> +static void test_alloc_gamma_tbl(void)
> +{
> +uint16_t *tbl = alloc_gamma_tbl(1.);
> +int i;
> +
> +// print only 32 elements
> +printf("e = 1.0\n");
> +for (i = 0; i < 65536; i += 2048)
> +printf("it: %d\t value: %d\n", i, tbl[i]);
> +
> +tbl = alloc_gamma_tbl(0.75);
> +printf("\ne = 0.75\n");
> +for (i = 0; i < 65536; i += 2048)
> +printf("it: %d\t value: %d\n", i, tbl[i]);
> +
> +tbl = alloc_gamma_tbl(2.8);
> +printf("\ne = 2.8\n");
> +for (i = 0; i < 65536; i += 2048)
> +printf("it: %d\t value: %d\n", i, tbl[i]);

this leaks memory

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

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


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

Re: [FFmpeg-devel] [PATCH] Added more tests to libswscale/utils.c

[Michael Niedermayer]

On Sun, Mar 27, 2016 at 04:39:39PM +, Petru Rares Sincraian wrote:
> 
>   - Added test for: swscale_license()
>   - Added test for: alphaless_fmt()
>   - Added test for: alloc_gamma_tbl()
[...]

> +static void test_alphaless_fmt(void)
> +{
> +int result;
> +
> +result = alphaless_fmt(AV_PIX_FMT_ARGB) == AV_PIX_FMT_RGB24;
> +printf("AV_PIX_FMT_ARGB == AV_PIX_FMT_RGB24 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_RGBA) == AV_PIX_FMT_RGB24;
> +printf("AV_PIX_FMT_RGBA == AV_PIX_FMT_RGB24 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_ABGR) == AV_PIX_FMT_BGR24;
> +printf("AV_PIX_FMT_ABGR == AV_PIX_FMT_BGR24 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_BGRA) == AV_PIX_FMT_BGR24;
> +printf("AV_PIX_FMT_BGRA == AV_PIX_FMT_BGR24 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_YA8) == AV_PIX_FMT_GRAY8;
> +printf("AV_PIX_FMT_YA8 == AV_PIX_FMT_GRAY8 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_YUVA420P) == AV_PIX_FMT_YUV420P;
> +printf("AV_PIX_FMT_YUVA420P == AV_PIX_FMT_YUV420P ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_YUVA422P) == AV_PIX_FMT_YUV422P;
> +printf("AV_PIX_FMT_YUVA422P == AV_PIX_FMT_YUV422P ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_YUVA444P) == AV_PIX_FMT_YUV444P;
> +printf("AV_PIX_FMT_YUVA444P == AV_PIX_FMT_YUV444P ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_GBRAP) == AV_PIX_FMT_GBRP;
> +printf("AV_PIX_FMT_GBRAP == AV_PIX_FMT_GBRP ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_GBRAP12LE) == AV_PIX_FMT_GBRP12;
> +printf("AV_PIX_FMT_GBRAP12LE == AV_PIX_FMT_GBRP12 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_GBRAP12BE) == AV_PIX_FMT_GBRP12;
> +printf("AV_PIX_FMT_GBRAP12BE == AV_PIX_FMT_GBRP12 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_RGBA64LE) == AV_PIX_FMT_RGB48;
> +printf("AV_PIX_FMT_RGBA64LE == AV_PIX_FMT_RGB48 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_RGBA64BE) == AV_PIX_FMT_RGB48;
> +printf("AV_PIX_FMT_RGBA64BE == AV_PIX_FMT_RGB48 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_BGRA64LE) == AV_PIX_FMT_BGR48;
> +printf("AV_PIX_FMT_BGRA64LE == AV_PIX_FMT_BGR48 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_BGRA64BE) == AV_PIX_FMT_BGR48;
> +printf("AV_PIX_FMT_BGRA64BE == AV_PIX_FMT_BGR48 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_YA16BE) == AV_PIX_FMT_GRAY16;
> +printf("AV_PIX_FMT_YA16LE == AV_PIX_FMT_GRAY16 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_YA16LE) == AV_PIX_FMT_GRAY16;
> +printf("AV_PIX_FMT_YA16LE == AV_PIX_FMT_GRAY16 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_YUVA420P9BE) == AV_PIX_FMT_YUV420P9;
> +printf("AV_PIX_FMT_YUVA420P9BE == AV_PIX_FMT_YUV420P9 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_YUVA422P9BE) == AV_PIX_FMT_YUV422P9;
> +printf("AV_PIX_FMT_YUVA422P9BE == AV_PIX_FMT_YUV422P9 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_YUVA444P9BE) == AV_PIX_FMT_YUV444P9;
> +printf("AV_PIX_FMT_YUVA444P9BE == AV_PIX_FMT_YUV444P9 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_YUVA420P9LE) == AV_PIX_FMT_YUV420P9;
> +printf("AV_PIX_FMT_YUVA420P9LE == AV_PIX_FMT_YUV420P9 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_YUVA422P9LE) == AV_PIX_FMT_YUV422P9;
> +printf("AV_PIX_FMT_YUVA422P9LE == AV_PIX_FMT_YUV422P9 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_YUVA444P9LE) == AV_PIX_FMT_YUV444P9;
> +printf("AV_PIX_FMT_YUVA444P9LE == AV_PIX_FMT_YUV444P9 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_YUVA420P10BE) == AV_PIX_FMT_YUV420P10;
> +printf("AV_PIX_FMT_YUVA420P10BE == AV_PIX_FMT_YUV420P10 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_YUVA422P10BE) == AV_PIX_FMT_YUV422P10;
> +printf("AV_PIX_FMT_YUVA422P10BE == AV_PIX_FMT_YUV422P10 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_YUVA444P10BE) == AV_PIX_FMT_YUV444P10;
> +printf("AV_PIX_FMT_YUVA444P10BE == AV_PIX_FMT_YUV444P10 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_YUVA420P10LE) == AV_PIX_FMT_YUV420P10;
> +printf("AV_PIX_FMT_YUVA420P10LE == AV_PIX_FMT_YUV420P10 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_YUVA422P10LE) == AV_PIX_FMT_YUV422P10;
> +printf("AV_PIX_FMT_YUVA422P10LE == AV_PIX_FMT_YUV422P10 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_YUVA444P10LE) == AV_PIX_FMT_YUV444P10;
> +printf("AV_PIX_FMT_YUVA444P10LE == AV_PIX_FMT_YUV444P10 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_YUVA444P10LE) == AV_PIX_FMT_YUV444P10;
> +printf("AV_PIX_FMT_YUVA444P10LE == AV_PIX_FMT_YUV444P10 ? %d\n", result);
> +
> +result = alphaless_fmt(AV_PIX_FMT_YUVA420P16BE) == AV_PIX_FMT_YUV420P16;
> +

Re: [FFmpeg-devel] Linking to C++ version of openjpeg

[Aaron Boxer]

On Sun, Mar 27, 2016 at 2:39 PM, Aaron Boxer  wrote:

> Hello Again,
>
> I have a C++ version of openjpeg that I would like to use with FFmpeg -
> this
> library is going to be statically linked, just like the C version of
> openjpeg.
>
> Are there any special flags I need to set to link with the C++ version,
> which uses the STL and C++11 ?
>

I tried adding -std=c++0x  to the extra c flags, but when I looked at
config.log, I was these flags sent to gcc:

-std=c++0x  -std=c99

So, it seems that c99 is over-riding c++0x.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Linking to C++ version of openjpeg

[Aaron Boxer]

Hello Again,

I have a C++ version of openjpeg that I would like to use with FFmpeg - this
library is going to be statically linked, just like the C version of
openjpeg.

Are there any special flags I need to set to link with the C++ version,
which uses the STL and C++11 ?

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

[FFmpeg-devel] [PATCH 5/6] lavc/audiotoolboxdec: support ADTS AAC input

[Rodger Combs]

---
 libavcodec/audiotoolboxdec.c | 35 ++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c
index 270e07f..1fa6f16 100644
--- a/libavcodec/audiotoolboxdec.c
+++ b/libavcodec/audiotoolboxdec.c
@@ -37,6 +37,7 @@ typedef struct ATDecodeContext {
 AudioStreamPacketDescription pkt_desc;
 AVPacket in_pkt;
 AVPacket new_in_pkt;
+AVBitStreamFilterContext *bsf;
 
 unsigned pkt_size;
 int64_t last_pts;
@@ -233,6 +234,8 @@ static int ffat_decode(AVCodecContext *avctx, void *data,
 {
 ATDecodeContext *at = avctx->priv_data;
 AVFrame *frame = data;
+int pkt_size = avpkt->size;
+AVPacket filtered_packet;
 OSStatus ret;
 
 AudioBufferList out_buffers = {
@@ -245,11 +248,41 @@ static int ffat_decode(AVCodecContext *avctx, void *data,
 }
 };
 
+if (avctx->codec_id == AV_CODEC_ID_AAC && avpkt->size > 2 &&
+(AV_RB16(avpkt->data) & 0xfff0) == 0xfff0) {
+int first = 0;
+uint8_t *p_filtered = NULL;
+int  n_filtered = 0;
+if (!at->bsf) {
+first = 1;
+if(!(at->bsf = av_bitstream_filter_init("aac_adtstoasc")))
+return AVERROR(ENOMEM);
+}
+
+ret = av_bitstream_filter_filter(at->bsf, avctx, NULL, _filtered, 
_filtered,
+ avpkt->data, avpkt->size, 0);
+if (ret >= 0 && p_filtered != avpkt->data) {
+filtered_packet = *avpkt;
+avpkt = _packet;
+avpkt->data = p_filtered;
+avpkt->size = n_filtered;
+}
+
+if (first) {
+if ((ret = ffat_set_extradata(avctx)) < 0)
+return ret;
+ffat_update_ctx(avctx);
+out_buffers.mBuffers[0].mNumberChannels = avctx->channels;
+out_buffers.mBuffers[0].mDataByteSize = 
av_get_bytes_per_sample(avctx->sample_fmt) * at->pkt_size * avctx->channels;
+}
+}
+
 av_packet_unref(>new_in_pkt);
 
 if (avpkt->size) {
 if ((ret = av_packet_ref(>new_in_pkt, avpkt)) < 0)
 return ret;
+at->new_in_pkt.data = avpkt->data;
 } else {
 at->eof = 1;
 }
@@ -275,7 +308,7 @@ static int ffat_decode(AVCodecContext *avctx, void *data,
 at->last_pts = avpkt->pts;
 }
 
-return avpkt->size;
+return pkt_size;
 }
 
 static av_cold void ffat_decode_flush(AVCodecContext *avctx)
-- 
2.7.3

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

[FFmpeg-devel] [PATCH 3/6] lavc/audiotoolboxenc: fix iOS build

[Rodger Combs]

---
 libavcodec/audiotoolboxenc.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
index 22352da..2fca15b 100644
--- a/libavcodec/audiotoolboxenc.c
+++ b/libavcodec/audiotoolboxenc.c
@@ -307,6 +307,7 @@ static av_cold int ffat_init_encoder(AVCodecContext *avctx)
   sizeof(avctx->bits_per_raw_sample),
   >bits_per_raw_sample);
 
+#if !TARGET_OS_IPHONE
 if (at->mode == -1)
 at->mode = (avctx->flags & AV_CODEC_FLAG_QSCALE) ?
kAudioCodecBitRateControlMode_Variable :
@@ -325,7 +326,9 @@ static av_cold int ffat_init_encoder(AVCodecContext *avctx)
 q = 127 - q * 9;
 AudioConverterSetProperty(at->converter, 
kAudioCodecPropertySoundQualityForVBR,
   sizeof(q), );
-} else if (avctx->bit_rate > 0) {
+} else
+#endif
+if (avctx->bit_rate > 0) {
 UInt32 rate = avctx->bit_rate;
 UInt32 size;
 status = AudioConverterGetPropertyInfo(at->converter,
@@ -553,12 +556,14 @@ static const AVProfile aac_profiles[] = {
 
 #define AE AV_OPT_FLAG_AUDIO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
 static const AVOption options[] = {
+#if !TARGET_OS_IPHONE
 {"aac_at_mode", "ratecontrol mode", offsetof(ATDecodeContext, mode), 
AV_OPT_TYPE_INT, {.i64 = -1}, -1, kAudioCodecBitRateControlMode_Variable, AE, 
"mode"},
 {"auto", "VBR if global quality is given; CBR otherwise", 0, 
AV_OPT_TYPE_CONST, {.i64 = -1}, INT_MIN, INT_MAX, AE, "mode"},
 {"cbr",  "constant bitrate", 0, AV_OPT_TYPE_CONST, {.i64 = 
kAudioCodecBitRateControlMode_Constant}, INT_MIN, INT_MAX, AE, "mode"},
 {"abr",  "long-term average bitrate", 0, AV_OPT_TYPE_CONST, {.i64 = 
kAudioCodecBitRateControlMode_LongTermAverage}, INT_MIN, INT_MAX, AE, "mode"},
 {"cvbr", "constrained variable bitrate", 0, AV_OPT_TYPE_CONST, {.i64 = 
kAudioCodecBitRateControlMode_VariableConstrained}, INT_MIN, INT_MAX, AE, 
"mode"},
 {"vbr" , "variable bitrate", 0, AV_OPT_TYPE_CONST, {.i64 = 
kAudioCodecBitRateControlMode_Variable}, INT_MIN, INT_MAX, AE, "mode"},
+#endif
 {"aac_at_quality", "quality vs speed control", offsetof(ATDecodeContext, 
quality), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 2, AE},
 { NULL },
 };
-- 
2.7.3

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

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

[Rodger Combs]

- ADTS-formatted AAC didn't work
- Channel layouts were never exported
- Channel mappings were incorrect beyond stereo
- Channel counts weren't updated after packets were decoded
- Timestamps were exported incorrectly
---
 libavcodec/audiotoolboxdec.c | 248 ---
 1 file changed, 185 insertions(+), 63 deletions(-)

diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c
index 1fa6f16..d95fc0f 100644
--- a/libavcodec/audiotoolboxdec.c
+++ b/libavcodec/audiotoolboxdec.c
@@ -39,7 +39,6 @@ typedef struct ATDecodeContext {
 AVPacket new_in_pkt;
 AVBitStreamFilterContext *bsf;
 
-unsigned pkt_size;
 int64_t last_pts;
 int eof;
 } ATDecodeContext;
@@ -81,20 +80,126 @@ static UInt32 ffat_get_format_id(enum AVCodecID codec, int 
profile)
 }
 }
 
-static void ffat_update_ctx(AVCodecContext *avctx)
+static int ffat_get_channel_id(AudioChannelLabel label)
+{
+if (label == 0)
+return -1;
+else if (label <= kAudioChannelLabel_LFEScreen)
+return label - 1;
+else if (label <= kAudioChannelLabel_RightSurround)
+return label + 4;
+else if (label <= kAudioChannelLabel_CenterSurround)
+return label + 1;
+else if (label <= kAudioChannelLabel_RightSurroundDirect)
+return label + 23;
+else if (label <= kAudioChannelLabel_TopBackRight)
+return label - 1;
+else if (label < kAudioChannelLabel_RearSurroundLeft)
+return -1;
+else if (label <= kAudioChannelLabel_RearSurroundRight)
+return label - 29;
+else if (label <= kAudioChannelLabel_RightWide)
+return label - 4;
+else if (label == kAudioChannelLabel_LFE2)
+return ff_ctzll(AV_CH_LOW_FREQUENCY_2);
+else if (label == kAudioChannelLabel_Mono)
+return ff_ctzll(AV_CH_FRONT_CENTER);
+else
+return -1;
+}
+
+static int ffat_compare_channel_descriptions(const void* a, const void* b)
+{
+const AudioChannelDescription* da = a;
+const AudioChannelDescription* db = b;
+return ffat_get_channel_id(da->mChannelLabel) - 
ffat_get_channel_id(db->mChannelLabel);
+}
+
+static AudioChannelLayout *ffat_convert_layout(AudioChannelLayout *layout, 
UInt32* size)
+{
+AudioChannelLayoutTag tag = layout->mChannelLayoutTag;
+AudioChannelLayout *new_layout;
+if (tag == kAudioChannelLayoutTag_UseChannelDescriptions)
+return layout;
+else if (tag == kAudioChannelLayoutTag_UseChannelBitmap)
+AudioFormatGetPropertyInfo(kAudioFormatProperty_ChannelLayoutForBitmap,
+   sizeof(UInt32), >mChannelBitmap, 
size);
+else
+AudioFormatGetPropertyInfo(kAudioFormatProperty_ChannelLayoutForTag,
+   sizeof(AudioChannelLayoutTag), , size);
+new_layout = av_malloc(*size);
+if (!new_layout) {
+av_free(layout);
+return NULL;
+}
+if (tag == kAudioChannelLayoutTag_UseChannelBitmap)
+AudioFormatGetProperty(kAudioFormatProperty_ChannelLayoutForBitmap,
+   sizeof(UInt32), >mChannelBitmap, size, 
new_layout);
+else
+AudioFormatGetProperty(kAudioFormatProperty_ChannelLayoutForTag,
+   sizeof(AudioChannelLayoutTag), , size, 
new_layout);
+new_layout->mChannelLayoutTag = 
kAudioChannelLayoutTag_UseChannelDescriptions;
+av_free(layout);
+return new_layout;
+}
+
+static int ffat_update_ctx(AVCodecContext *avctx)
 {
 ATDecodeContext *at = avctx->priv_data;
-AudioStreamBasicDescription in_format;
-UInt32 size = sizeof(in_format);
+AudioStreamBasicDescription format;
+UInt32 size = sizeof(format);
 if (!AudioConverterGetProperty(at->converter,

kAudioConverterCurrentInputStreamDescription,
-   , _format)) {
-avctx->channels = in_format.mChannelsPerFrame;
-at->pkt_size = in_format.mFramesPerPacket;
+   , )) {
+if (format.mSampleRate)
+avctx->sample_rate = format.mSampleRate;
+avctx->channels = format.mChannelsPerFrame;
+avctx->channel_layout = av_get_default_channel_layout(avctx->channels);
+avctx->frame_size = format.mFramesPerPacket;
 }
 
-if (!at->pkt_size)
-at->pkt_size = 2048;
+if (!AudioConverterGetProperty(at->converter,
+   
kAudioConverterCurrentOutputStreamDescription,
+   , )) {
+format.mSampleRate = avctx->sample_rate;
+format.mChannelsPerFrame = avctx->channels;
+AudioConverterSetProperty(at->converter,
+  
kAudioConverterCurrentOutputStreamDescription,
+  size, );
+}
+
+if (!AudioConverterGetPropertyInfo(at->converter, 
kAudioConverterInputChannelLayout,
+   , NULL) && size) {
+

[FFmpeg-devel] [PATCH 2/6] lavc/audiotoolboxenc: fix a number of config issues

[Rodger Combs]

- size variables were used in a confusing way
- incorrect size var use led to channel layouts not being set properly
- channel layouts were incorrectly mapped for >2-channel AAC
- bitrates not accepted by the encoder were discarded instead of being clamped
- some minor style/indentation fixes
---
 libavcodec/audiotoolboxenc.c | 198 ++-
 1 file changed, 176 insertions(+), 22 deletions(-)

diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
index 4797b2a..22352da 100644
--- a/libavcodec/audiotoolboxenc.c
+++ b/libavcodec/audiotoolboxenc.c
@@ -146,6 +146,86 @@ static int get_ilbc_mode(AVCodecContext *avctx)
 return 30;
 }
 
+static av_cold int get_channel_label(int channel)
+{
+uint64_t map = 1 << channel;
+if (map <= AV_CH_LOW_FREQUENCY)
+return channel + 1;
+else if (map <= AV_CH_BACK_RIGHT)
+return channel + 29;
+else if (map <= AV_CH_BACK_CENTER)
+return channel - 1;
+else if (map <= AV_CH_SIDE_RIGHT)
+return channel - 4;
+else if (map <= AV_CH_TOP_BACK_RIGHT)
+return channel + 1;
+else if (map <= AV_CH_STEREO_RIGHT)
+return -1;
+else if (map <= AV_CH_WIDE_RIGHT)
+return channel + 4;
+else if (map <= AV_CH_SURROUND_DIRECT_RIGHT)
+return channel - 23;
+else if (map == AV_CH_LOW_FREQUENCY_2)
+return kAudioChannelLabel_LFE2;
+else
+return -1;
+}
+
+static int remap_layout(AudioChannelLayout *layout, uint64_t in_layout, int 
count)
+{
+int i;
+int c = 0;
+layout->mChannelLayoutTag = kAudioChannelLayoutTag_UseChannelDescriptions;
+layout->mNumberChannelDescriptions = count;
+for (i = 0; i < count; i++) {
+int label;
+while (!(in_layout & (1 << c)) && c < 64)
+c++;
+if (c == 64)
+return AVERROR(EINVAL); // This should never happen
+label = get_channel_label(c);
+layout->mChannelDescriptions[i].mChannelLabel = label;
+if (label < 0)
+return AVERROR(EINVAL);
+c++;
+}
+return 0;
+}
+
+static int get_aac_tag(uint64_t in_layout)
+{
+switch (in_layout) {
+case AV_CH_LAYOUT_MONO:
+return kAudioChannelLayoutTag_Mono;
+case AV_CH_LAYOUT_STEREO:
+return kAudioChannelLayoutTag_Stereo;
+case AV_CH_LAYOUT_QUAD:
+return kAudioChannelLayoutTag_AAC_Quadraphonic;
+case AV_CH_LAYOUT_OCTAGONAL:
+return kAudioChannelLayoutTag_AAC_Octagonal;
+case AV_CH_LAYOUT_SURROUND:
+return kAudioChannelLayoutTag_AAC_3_0;
+case AV_CH_LAYOUT_4POINT0:
+return kAudioChannelLayoutTag_AAC_4_0;
+case AV_CH_LAYOUT_5POINT0:
+return kAudioChannelLayoutTag_AAC_5_0;
+case AV_CH_LAYOUT_5POINT1:
+return kAudioChannelLayoutTag_AAC_5_1;
+case AV_CH_LAYOUT_6POINT0:
+return kAudioChannelLayoutTag_AAC_6_0;
+case AV_CH_LAYOUT_6POINT1:
+return kAudioChannelLayoutTag_AAC_6_1;
+case AV_CH_LAYOUT_7POINT0:
+return kAudioChannelLayoutTag_AAC_7_0;
+case AV_CH_LAYOUT_7POINT1_WIDE_BACK:
+return kAudioChannelLayoutTag_AAC_7_1;
+case AV_CH_LAYOUT_7POINT1:
+return kAudioChannelLayoutTag_MPEG_7_1_C;
+default:
+return 0;
+}
+}
+
 static av_cold int ffat_init_encoder(AVCodecContext *avctx)
 {
 ATDecodeContext *at = avctx->priv_data;
@@ -170,11 +250,12 @@ static av_cold int ffat_init_encoder(AVCodecContext 
*avctx)
 .mFormatID = ffat_get_format_id(avctx->codec_id, avctx->profile),
 .mChannelsPerFrame = in_format.mChannelsPerFrame,
 };
-AudioChannelLayout channel_layout = {
-.mChannelLayoutTag = kAudioChannelLayoutTag_UseChannelBitmap,
-.mChannelBitmap = avctx->channel_layout,
-};
-UInt32 size = sizeof(channel_layout);
+UInt32 layout_size = sizeof(AudioChannelLayout) +
+ sizeof(AudioChannelDescription) * avctx->channels;
+AudioChannelLayout *channel_layout = av_malloc(layout_size);
+
+if (!channel_layout)
+return AVERROR(ENOMEM);
 
 if (avctx->codec_id == AV_CODEC_ID_ILBC) {
 int mode = get_ilbc_mode(avctx);
@@ -186,22 +267,45 @@ static av_cold int ffat_init_encoder(AVCodecContext 
*avctx)
 
 if (status != 0) {
 av_log(avctx, AV_LOG_ERROR, "AudioToolbox init error: %i\n", 
(int)status);
+av_free(channel_layout);
 return AVERROR_UNKNOWN;
 }
 
-size = sizeof(UInt32);
+if (!avctx->channel_layout)
+avctx->channel_layout = av_get_default_channel_layout(avctx->channels);
+
+if ((status = remap_layout(channel_layout, avctx->channel_layout, 
avctx->channels)) < 0) {
+av_log(avctx, AV_LOG_ERROR, "Invalid channel layout\n");
+av_free(channel_layout);
+return status;
+}
 
-AudioConverterSetProperty(at->converter, kAudioConverterInputChannelLayout,
-  size, _layout);
-

[FFmpeg-devel] [PATCH 1/6] lavc/audiotoolboxenc: remove unneeded packet metadata

[Rodger Combs]

This isn't necessary here, and for some reason broke only multichannel
AAC encoding when a channel layout tag was set.
---
 libavcodec/audiotoolboxenc.c | 16 +++-
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
index c4d36f5..4797b2a 100644
--- a/libavcodec/audiotoolboxenc.c
+++ b/libavcodec/audiotoolboxenc.c
@@ -38,7 +38,6 @@ typedef struct ATDecodeContext {
 int quality;
 
 AudioConverterRef converter;
-AudioStreamPacketDescription pkt_desc;
 AVFrame in_frame;
 AVFrame new_in_frame;
 
@@ -312,10 +311,6 @@ static OSStatus ffat_encode_callback(AudioConverterRef 
converter, UInt32 *nb_pac
 
 if (at->eof) {
 *nb_packets = 0;
-if (packets) {
-*packets = >pkt_desc;
-at->pkt_desc.mDataByteSize = 0;
-}
 return 0;
 }
 
@@ -328,18 +323,13 @@ static OSStatus ffat_encode_callback(AudioConverterRef 
converter, UInt32 *nb_pac
 }
 
 data->mNumberBuffers  = 1;
-data->mBuffers[0].mNumberChannels = 0;
+data->mBuffers[0].mNumberChannels = avctx->channels;
 data->mBuffers[0].mDataByteSize   = at->in_frame.nb_samples *
 
av_get_bytes_per_sample(avctx->sample_fmt) *
 avctx->channels;
 data->mBuffers[0].mData   = at->in_frame.data[0];
-*nb_packets = (at->in_frame.nb_samples + (at->frame_size - 1)) / 
at->frame_size;
-
-if (packets) {
-*packets = >pkt_desc;
-at->pkt_desc.mDataByteSize = data->mBuffers[0].mDataByteSize;
-at->pkt_desc.mVariableFramesInPacket = at->in_frame.nb_samples;
-}
+if (*nb_packets > at->in_frame.nb_samples)
+*nb_packets = at->in_frame.nb_samples;
 
 return 0;
 }
-- 
2.7.3

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

[FFmpeg-devel] [PATCH 4/6] lavc/audiotoolboxenc: allow setting maxrate with pre-10.9 deployment targets

[Rodger Combs]

The build failure here is caused by the enum value not being defined, but
as long as we're on a newer SDK that has it, it's safe to use it even
when our deployment target is older. Setting the property will error, but
we're not failing on errors there.
---
 libavcodec/audiotoolboxenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
index 2fca15b..855df0c 100644
--- a/libavcodec/audiotoolboxenc.c
+++ b/libavcodec/audiotoolboxenc.c
@@ -428,7 +428,7 @@ static av_cold int ffat_init_encoder(AVCodecContext *avctx)
 
 ffat_update_ctx(avctx);
 
-#if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1090
+#if !TARGET_OS_IPHONE && defined(__MAC_10_9)
 if (at->mode == kAudioCodecBitRateControlMode_Variable && 
avctx->rc_max_rate) {
 UInt32 max_size = avctx->rc_max_rate * avctx->frame_size / 
avctx->sample_rate;
 if (max_size)
-- 
2.7.3

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

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

[Timo Rothenpieler]

ping

Any objections/problems, or can I push this?



Timo



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

Re: [FFmpeg-devel] APNG encoder can work incorrectly

[Paul B Mahol]

On 3/27/16, Dmitriy  wrote:
> In come cases APNG encoder generate only static video.
>
> The errors are located in the apng_encode_frame function (pngenc.c file).
>
> The
> av_frame_copy(diffFrame, s->last_frame);
> and
> av_frame_copy(diffFrame, s->last_frame);
>
> functions doesn't work if the image size was changed in
> apng_do_inverse_blend function and return error code.
>
> you need insert the following codes
>
> diffFrame->width = pict->width;
> diffFrame->height = pict->height;
> av_frame_copy(diffFrame, s->last_frame);
>
> and
>
> diffFrame->width = pict->width;
> diffFrame->height = pict->height;
> av_frame_copy(diffFrame, s->last_frame);
>
> to restore image size before recovery diffFrame image.

Could you provide input file so I can reproduce this?

>
> --
> S uvazheniem,
>  Dmitriy  mailto:diz...@mail.ru
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Added more tests to libswscale/utils.c

[Petru Rares Sincraian]

- Added test for: swscale_license()
- Added test for: alphaless_fmt()
- Added test for: alloc_gamma_tbl()
---
 libswscale/Makefile   |   1 +
 libswscale/utils.c| 158 ++
 tests/Makefile|   1 +
 tests/fate/libswscale.mak |   6 ++
 tests/ref/fate/utils  | 143 +
 5 files changed, 309 insertions(+)
 create mode 100644 tests/fate/libswscale.mak
 create mode 100644 tests/ref/fate/utils

diff --git a/libswscale/Makefile b/libswscale/Makefile
index a9f9e03..a6ae81d 100644
--- a/libswscale/Makefile
+++ b/libswscale/Makefile
@@ -27,3 +27,4 @@ SLIBOBJS-$(HAVE_GNU_WINDRES) += swscaleres.o
 
 TESTPROGS = colorspace  \
 swscale \
+utils   \
diff --git a/libswscale/utils.c b/libswscale/utils.c
index ba409d6..da27808 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -2410,3 +2410,161 @@ struct SwsContext *sws_getCachedContext(struct 
SwsContext *context, int srcW,
 }
 return context;
 }
+
+#ifdef TEST
+
+static void test_swscale_license(void)
+{
+const char *license = swscale_license();
+printf("%s\n", license);
+}
+
+static void test_alloc_gamma_tbl(void)
+{
+uint16_t *tbl = alloc_gamma_tbl(1.);
+int i;
+
+// print only 32 elements
+printf("e = 1.0\n");
+for (i = 0; i < 65536; i += 2048)
+printf("it: %d\t value: %d\n", i, tbl[i]);
+
+tbl = alloc_gamma_tbl(0.75);
+printf("\ne = 0.75\n");
+for (i = 0; i < 65536; i += 2048)
+printf("it: %d\t value: %d\n", i, tbl[i]);
+
+tbl = alloc_gamma_tbl(2.8);
+printf("\ne = 2.8\n");
+for (i = 0; i < 65536; i += 2048)
+printf("it: %d\t value: %d\n", i, tbl[i]);
+
+}
+
+static void test_alphaless_fmt(void)
+{
+int result;
+
+result = alphaless_fmt(AV_PIX_FMT_ARGB) == AV_PIX_FMT_RGB24;
+printf("AV_PIX_FMT_ARGB == AV_PIX_FMT_RGB24 ? %d\n", result);
+
+result = alphaless_fmt(AV_PIX_FMT_RGBA) == AV_PIX_FMT_RGB24;
+printf("AV_PIX_FMT_RGBA == AV_PIX_FMT_RGB24 ? %d\n", result);
+
+result = alphaless_fmt(AV_PIX_FMT_ABGR) == AV_PIX_FMT_BGR24;
+printf("AV_PIX_FMT_ABGR == AV_PIX_FMT_BGR24 ? %d\n", result);
+
+result = alphaless_fmt(AV_PIX_FMT_BGRA) == AV_PIX_FMT_BGR24;
+printf("AV_PIX_FMT_BGRA == AV_PIX_FMT_BGR24 ? %d\n", result);
+
+result = alphaless_fmt(AV_PIX_FMT_YA8) == AV_PIX_FMT_GRAY8;
+printf("AV_PIX_FMT_YA8 == AV_PIX_FMT_GRAY8 ? %d\n", result);
+
+result = alphaless_fmt(AV_PIX_FMT_YUVA420P) == AV_PIX_FMT_YUV420P;
+printf("AV_PIX_FMT_YUVA420P == AV_PIX_FMT_YUV420P ? %d\n", result);
+
+result = alphaless_fmt(AV_PIX_FMT_YUVA422P) == AV_PIX_FMT_YUV422P;
+printf("AV_PIX_FMT_YUVA422P == AV_PIX_FMT_YUV422P ? %d\n", result);
+
+result = alphaless_fmt(AV_PIX_FMT_YUVA444P) == AV_PIX_FMT_YUV444P;
+printf("AV_PIX_FMT_YUVA444P == AV_PIX_FMT_YUV444P ? %d\n", result);
+
+result = alphaless_fmt(AV_PIX_FMT_GBRAP) == AV_PIX_FMT_GBRP;
+printf("AV_PIX_FMT_GBRAP == AV_PIX_FMT_GBRP ? %d\n", result);
+
+result = alphaless_fmt(AV_PIX_FMT_GBRAP12LE) == AV_PIX_FMT_GBRP12;
+printf("AV_PIX_FMT_GBRAP12LE == AV_PIX_FMT_GBRP12 ? %d\n", result);
+
+result = alphaless_fmt(AV_PIX_FMT_GBRAP12BE) == AV_PIX_FMT_GBRP12;
+printf("AV_PIX_FMT_GBRAP12BE == AV_PIX_FMT_GBRP12 ? %d\n", result);
+
+result = alphaless_fmt(AV_PIX_FMT_RGBA64LE) == AV_PIX_FMT_RGB48;
+printf("AV_PIX_FMT_RGBA64LE == AV_PIX_FMT_RGB48 ? %d\n", result);
+
+result = alphaless_fmt(AV_PIX_FMT_RGBA64BE) == AV_PIX_FMT_RGB48;
+printf("AV_PIX_FMT_RGBA64BE == AV_PIX_FMT_RGB48 ? %d\n", result);
+
+result = alphaless_fmt(AV_PIX_FMT_BGRA64LE) == AV_PIX_FMT_BGR48;
+printf("AV_PIX_FMT_BGRA64LE == AV_PIX_FMT_BGR48 ? %d\n", result);
+
+result = alphaless_fmt(AV_PIX_FMT_BGRA64BE) == AV_PIX_FMT_BGR48;
+printf("AV_PIX_FMT_BGRA64BE == AV_PIX_FMT_BGR48 ? %d\n", result);
+
+result = alphaless_fmt(AV_PIX_FMT_YA16BE) == AV_PIX_FMT_GRAY16;
+printf("AV_PIX_FMT_YA16LE == AV_PIX_FMT_GRAY16 ? %d\n", result);
+
+result = alphaless_fmt(AV_PIX_FMT_YA16LE) == AV_PIX_FMT_GRAY16;
+printf("AV_PIX_FMT_YA16LE == AV_PIX_FMT_GRAY16 ? %d\n", result);
+
+result = alphaless_fmt(AV_PIX_FMT_YUVA420P9BE) == AV_PIX_FMT_YUV420P9;
+printf("AV_PIX_FMT_YUVA420P9BE == AV_PIX_FMT_YUV420P9 ? %d\n", result);
+
+result = alphaless_fmt(AV_PIX_FMT_YUVA422P9BE) == AV_PIX_FMT_YUV422P9;
+printf("AV_PIX_FMT_YUVA422P9BE == AV_PIX_FMT_YUV422P9 ? %d\n", result);
+
+result = alphaless_fmt(AV_PIX_FMT_YUVA444P9BE) == AV_PIX_FMT_YUV444P9;
+printf("AV_PIX_FMT_YUVA444P9BE == AV_PIX_FMT_YUV444P9 ? %d\n", result);
+
+result = alphaless_fmt(AV_PIX_FMT_YUVA420P9LE) == AV_PIX_FMT_YUV420P9;
+printf("AV_PIX_FMT_YUVA420P9LE == AV_PIX_FMT_YUV420P9 ? %d\n", result);
+
+  

[FFmpeg-devel] [PATCH 2/2] avformat/mov: fix audio last packet durations

[Marton Balint]

Stream duration might not be reliable, let's not use if the frame size is known.

Signed-off-by: Marton Balint 
---
 libavformat/mov.c| 2 ++
 tests/ref/fate/gaplessenc-itunes-to-ipod-aac | 4 ++--
 tests/ref/fate/gaplessenc-pcm-to-mov-aac | 4 ++--
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 3fa8fcc..3574801 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5163,6 +5163,8 @@ static int mov_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 int64_t next_dts = (sc->current_sample < st->nb_index_entries) ?
 st->index_entries[sc->current_sample].timestamp : st->duration;
 pkt->duration = next_dts - pkt->dts;
+if (sc->current_sample >= st->nb_index_entries && 
st->codec->frame_size && st->codec->sample_rate)
+pkt->duration = av_rescale(st->codec->frame_size, sc->time_scale, 
st->codec->sample_rate);
 pkt->pts = pkt->dts;
 }
 if (st->discard == AVDISCARD_ALL)
diff --git a/tests/ref/fate/gaplessenc-itunes-to-ipod-aac 
b/tests/ref/fate/gaplessenc-itunes-to-ipod-aac
index aacb058..e04934b 100644
--- a/tests/ref/fate/gaplessenc-itunes-to-ipod-aac
+++ b/tests/ref/fate/gaplessenc-itunes-to-ipod-aac
@@ -22,7 +22,7 @@ packet|pts=98304|dts=98304|duration=1024
 packet|pts=99328|dts=99328|duration=1024
 packet|pts=100352|dts=100352|duration=1024
 packet|pts=101376|dts=101376|duration=1024
-packet|pts=102400|dts=102400|duration=1984
+packet|pts=102400|dts=102400|duration=1024
 stream|nb_read_packets=102
 
frame|pkt_pts=0|pkt_dts=0|best_effort_timestamp=0|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=1024|pkt_dts=1024|best_effort_timestamp=1024|pkt_duration=1024|nb_samples=1024
@@ -39,5 +39,5 @@ 
frame|pkt_pts=98304|pkt_dts=98304|best_effort_timestamp=98304|pkt_duration=1024|
 
frame|pkt_pts=99328|pkt_dts=99328|best_effort_timestamp=99328|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=100352|pkt_dts=100352|best_effort_timestamp=100352|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=101376|pkt_dts=101376|best_effort_timestamp=101376|pkt_duration=1024|nb_samples=1024
-frame|pkt_pts=102400|pkt_dts=102400|best_effort_timestamp=102400|pkt_duration=1984|nb_samples=1024
+frame|pkt_pts=102400|pkt_dts=102400|best_effort_timestamp=102400|pkt_duration=1024|nb_samples=1024
 stream|nb_read_frames=101
diff --git a/tests/ref/fate/gaplessenc-pcm-to-mov-aac 
b/tests/ref/fate/gaplessenc-pcm-to-mov-aac
index 05dff6e..16bed52 100644
--- a/tests/ref/fate/gaplessenc-pcm-to-mov-aac
+++ b/tests/ref/fate/gaplessenc-pcm-to-mov-aac
@@ -22,7 +22,7 @@ packet|pts=524288|dts=524288|duration=1024
 packet|pts=525312|dts=525312|duration=1024
 packet|pts=526336|dts=526336|duration=1024
 packet|pts=527360|dts=527360|duration=1024
-packet|pts=528384|dts=528384|duration=1840
+packet|pts=528384|dts=528384|duration=1024
 stream|nb_read_packets=518
 
frame|pkt_pts=0|pkt_dts=0|best_effort_timestamp=0|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=1024|pkt_dts=1024|best_effort_timestamp=1024|pkt_duration=1024|nb_samples=1024
@@ -39,5 +39,5 @@ 
frame|pkt_pts=524288|pkt_dts=524288|best_effort_timestamp=524288|pkt_duration=10
 
frame|pkt_pts=525312|pkt_dts=525312|best_effort_timestamp=525312|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=526336|pkt_dts=526336|best_effort_timestamp=526336|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=527360|pkt_dts=527360|best_effort_timestamp=527360|pkt_duration=1024|nb_samples=1024
-frame|pkt_pts=528384|pkt_dts=528384|best_effort_timestamp=528384|pkt_duration=1840|nb_samples=1024
+frame|pkt_pts=528384|pkt_dts=528384|best_effort_timestamp=528384|pkt_duration=1024|nb_samples=1024
 stream|nb_read_frames=517
-- 
2.6.2

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

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

[Matthieu Bouron]

On Fri, Mar 25, 2016 at 11:45 PM, Matthieu Bouron  wrote:

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


I've managed tu run the code on a beagle bone black board, here are the
results:

nv12->bgra
without patchset: [bench @ 0x1fc02d0] t:0.011618 avg:0.011743 max:0.032600
min:0.011513
with patches 01-06/10 applied: [bench @ 0x8052d0] t:0.013438 avg:0.013659
max:0.034427 min:0.013411
with patches 01-10/10 applied: [bench @ 0x1fbb2d0] t:0.012554 avg:0.012751
max:0.034288 min:0.012523

yuv420p->bgra
without patchset: [bench @ 0x6d42d0] t:0.012954 avg:0.013159 max:0.033866
min:0.012945
with patches 01-06/10 applied: [bench @ 0x20172d0] t:0.015154 avg:0.015358
max:0.036186 min:0.015134
with patches 01-10/10 applied: [bench @ 0x1d162d0] t:0.014623 avg:0.014784
max:0.035487 min:0.014568

So it looks like processing one line at a time as negative effect on
performance on this board (as opposed to the rpi2). I'll try to keep the
two line processing code and post some result (so we can decide, which
version to choose).

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

[FFmpeg-devel] [PATCH]avcodec: add dca_core bsf

[Paul B Mahol]

Hi,

patch attached.
From 9105f16ae41a49cf3f914a768a10959b2c4ba70e Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Sun, 27 Mar 2016 13:02:33 +0200
Subject: [PATCH] avcodec: add dca core extraction bsf

Signed-off-by: Paul B Mahol 
---
 libavcodec/Makefile   |  1 +
 libavcodec/allcodecs.c|  1 +
 libavcodec/dca_core_bsf.c | 60 +++
 3 files changed, 62 insertions(+)
 create mode 100644 libavcodec/dca_core_bsf.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index b926b79..8c14268 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -924,6 +924,7 @@ OBJS-$(CONFIG_AAC_ADTSTOASC_BSF)  += aac_adtstoasc_bsf.o aacadtsdec.o \
  mpeg4audio.o
 OBJS-$(CONFIG_CHOMP_BSF)  += chomp_bsf.o
 OBJS-$(CONFIG_DUMP_EXTRADATA_BSF) += dump_extradata_bsf.o
+OBJS-$(CONFIG_DCA_CORE_BSF)   += dca_core_bsf.o
 OBJS-$(CONFIG_H264_MP4TOANNEXB_BSF)   += h264_mp4toannexb_bsf.o
 OBJS-$(CONFIG_HEVC_MP4TOANNEXB_BSF)   += hevc_mp4toannexb_bsf.o
 OBJS-$(CONFIG_IMX_DUMP_HEADER_BSF)+= imx_dump_header_bsf.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index e3c4f07..f498041 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -670,6 +670,7 @@ void avcodec_register_all(void)
 REGISTER_BSF(AAC_ADTSTOASC, aac_adtstoasc);
 REGISTER_BSF(CHOMP, chomp);
 REGISTER_BSF(DUMP_EXTRADATA,dump_extradata);
+REGISTER_BSF(DCA_CORE,  dca_core);
 REGISTER_BSF(H264_MP4TOANNEXB,  h264_mp4toannexb);
 REGISTER_BSF(HEVC_MP4TOANNEXB,  hevc_mp4toannexb);
 REGISTER_BSF(IMX_DUMP_HEADER,   imx_dump_header);
diff --git a/libavcodec/dca_core_bsf.c b/libavcodec/dca_core_bsf.c
new file mode 100644
index 000..7d37236
--- /dev/null
+++ b/libavcodec/dca_core_bsf.c
@@ -0,0 +1,60 @@
+/*
+ * Copyright (c) 2016 Paul B Mahol
+ *
+ * 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 "avcodec.h"
+#include "bytestream.h"
+#include "dca_syncwords.h"
+#include "libavutil/mem.h"
+
+static int dca_core(AVBitStreamFilterContext *bsfc,
+AVCodecContext *avctx, const char *args,
+uint8_t **poutbuf, int *poutbuf_size,
+const uint8_t *buf, int buf_size,
+int keyframe)
+{
+GetByteContext gb;
+uint32_t syncword;
+int core_size = 0;
+
+bytestream2_init(, buf, buf_size);
+syncword = bytestream2_get_be32();
+bytestream2_skip(, 1);
+
+switch (syncword) {
+case DCA_SYNCWORD_CORE_BE:
+core_size = ((bytestream2_get_be24() >> 4) & 0x3fff) + 1;
+break;
+}
+
+*poutbuf = (uint8_t *)buf;
+
+if (core_size > 0 && core_size <= buf_size) {
+*poutbuf_size = core_size;
+} else {
+*poutbuf_size = buf_size;
+}
+
+return 0;
+}
+
+AVBitStreamFilter ff_dca_core_bsf = {
+.name   = "dca_core",
+.filter = dca_core,
+};
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] avcodec/audiotoolboxenc: Fix compile error to support iOS

[crossle song]

Fixed on a new patch

On Sun, Mar 27, 2016 at 8:54 PM, Hendrik Leppkes 
wrote:

> On Sun, Mar 27, 2016 at 1:52 PM,   wrote:
> > From: Crossle Song 
> >
> > Fix error libavcodec/audiotoolboxenc.c use of undeclared
> > 'kAudioCodecPropertyBitRateControlMode' on iOS
> >
> > AudioToolbox now support iOS
> > ---
> >  libavcodec/audiotoolboxenc.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
> > index c4d36f5..b7874e5 100644
> > --- a/libavcodec/audiotoolboxenc.c
> > +++ b/libavcodec/audiotoolboxenc.c
> > @@ -204,6 +204,7 @@ static av_cold int ffat_init_encoder(AVCodecContext
> *avctx)
> >size, >bits_per_raw_sample);
> >  }
> >
> > +#if !TARGET_OS_IPHONE
> >  if (at->mode == -1)
> >  at->mode = (avctx->flags & AV_CODEC_FLAG_QSCALE) ?
> > kAudioCodecBitRateControlMode_Variable :
> > @@ -222,7 +223,9 @@ static av_cold int ffat_init_encoder(AVCodecContext
> *avctx)
> >  q = 127 - q * 9;
> >  AudioConverterSetProperty(at->converter,
> kAudioCodecPropertySoundQualityForVBR,
> >size, );
> > -} else if (avctx->bit_rate > 0) {
> > +}
> > +#endif
> > +if (avctx->bit_rate > 0) {
>
> This changes the logic.
>
> >  UInt32 rate = avctx->bit_rate;
> >  AudioConverterSetProperty(at->converter,
> kAudioConverterEncodeBitRate,
> >size, );
> > @@ -425,12 +428,14 @@ static const AVProfile aac_profiles[] = {
> >
> >  #define AE AV_OPT_FLAG_AUDIO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
> >  static const AVOption options[] = {
> > +#if !TARGET_OS_IPHONE
> >  {"aac_at_mode", "ratecontrol mode", offsetof(ATDecodeContext,
> mode), AV_OPT_TYPE_INT, {.i64 = -1}, -1,
> kAudioCodecBitRateControlMode_Variable, AE, "mode"},
> >  {"auto", "VBR if global quality is given; CBR otherwise", 0,
> AV_OPT_TYPE_CONST, {.i64 = -1}, INT_MIN, INT_MAX, AE, "mode"},
> >  {"cbr",  "constant bitrate", 0, AV_OPT_TYPE_CONST, {.i64 =
> kAudioCodecBitRateControlMode_Constant}, INT_MIN, INT_MAX, AE, "mode"},
> >  {"abr",  "long-term average bitrate", 0, AV_OPT_TYPE_CONST,
> {.i64 = kAudioCodecBitRateControlMode_LongTermAverage}, INT_MIN, INT_MAX,
> AE, "mode"},
> >  {"cvbr", "constrained variable bitrate", 0, AV_OPT_TYPE_CONST,
> {.i64 = kAudioCodecBitRateControlMode_VariableConstrained}, INT_MIN,
> INT_MAX, AE, "mode"},
> >  {"vbr" , "variable bitrate", 0, AV_OPT_TYPE_CONST, {.i64 =
> kAudioCodecBitRateControlMode_Variable}, INT_MIN, INT_MAX, AE, "mode"},
> > +#endif
> >  {"aac_at_quality", "quality vs speed control",
> offsetof(ATDecodeContext, quality), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 2, AE},
> >  { NULL },
> >  };
> > --
> > 2.7.0
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/audiotoolboxenc: Fix compile error to support iOS

[crosslesong]

From: Crossle Song 

Fix error libavcodec/audiotoolboxenc.c use of undeclared
'kAudioCodecPropertyBitRateControlMode' on iOS

AudioToolbox now support iOS
---
 libavcodec/audiotoolboxenc.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
index c4d36f5..527e049 100644
--- a/libavcodec/audiotoolboxenc.c
+++ b/libavcodec/audiotoolboxenc.c
@@ -204,6 +204,7 @@ static av_cold int ffat_init_encoder(AVCodecContext *avctx)
   size, >bits_per_raw_sample);
 }
 
+#if !TARGET_OS_IPHONE
 if (at->mode == -1)
 at->mode = (avctx->flags & AV_CODEC_FLAG_QSCALE) ?
kAudioCodecBitRateControlMode_Variable :
@@ -227,6 +228,13 @@ static av_cold int ffat_init_encoder(AVCodecContext *avctx)
 AudioConverterSetProperty(at->converter, kAudioConverterEncodeBitRate,
   size, );
 }
+#else
+if (avctx->bit_rate > 0) {
+UInt32 rate = avctx->bit_rate;
+AudioConverterSetProperty(at->converter, kAudioConverterEncodeBitRate,
+  size, );
+}
+#endif
 
 at->quality = 96 - at->quality * 32;
 AudioConverterSetProperty(at->converter, kAudioConverterCodecQuality,
@@ -425,12 +433,14 @@ static const AVProfile aac_profiles[] = {
 
 #define AE AV_OPT_FLAG_AUDIO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
 static const AVOption options[] = {
+#if !TARGET_OS_IPHONE
 {"aac_at_mode", "ratecontrol mode", offsetof(ATDecodeContext, mode), 
AV_OPT_TYPE_INT, {.i64 = -1}, -1, kAudioCodecBitRateControlMode_Variable, AE, 
"mode"},
 {"auto", "VBR if global quality is given; CBR otherwise", 0, 
AV_OPT_TYPE_CONST, {.i64 = -1}, INT_MIN, INT_MAX, AE, "mode"},
 {"cbr",  "constant bitrate", 0, AV_OPT_TYPE_CONST, {.i64 = 
kAudioCodecBitRateControlMode_Constant}, INT_MIN, INT_MAX, AE, "mode"},
 {"abr",  "long-term average bitrate", 0, AV_OPT_TYPE_CONST, {.i64 = 
kAudioCodecBitRateControlMode_LongTermAverage}, INT_MIN, INT_MAX, AE, "mode"},
 {"cvbr", "constrained variable bitrate", 0, AV_OPT_TYPE_CONST, {.i64 = 
kAudioCodecBitRateControlMode_VariableConstrained}, INT_MIN, INT_MAX, AE, 
"mode"},
 {"vbr" , "variable bitrate", 0, AV_OPT_TYPE_CONST, {.i64 = 
kAudioCodecBitRateControlMode_Variable}, INT_MIN, INT_MAX, AE, "mode"},
+#endif
 {"aac_at_quality", "quality vs speed control", offsetof(ATDecodeContext, 
quality), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 2, AE},
 { NULL },
 };
-- 
2.7.0

___
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 Sat, 26 Mar 2016 01:12:17 +0100
Thilo Borgmann  wrote:

> 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 

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: Demux the PixelCrop* values

[wm4]

On Sat, 26 Mar 2016 16:56:55 -0600
Nic Wolfe  wrote:

> The Matroska spec defines PixelCropTop, PixelCropBottom, PixelCropLeft,
> and PixelCropRight elements: 
> https://www.matroska.org/technical/specs/index.html
> 
> This commit adds support for demuxing these values so that
> applications using libav*
> are able to use them when playing the stream. They're added to the AVStream's
> metadata if they are set to something non-zero.

That's a bad way to do it and you know it.

> 
> 
> My official patch is base64 encoded and attached but I will also

Don't do this, I doubt most mail clients provide a way to easily view
this.

> include the diff below for (hopefully) convenience.
> 
> Thanks,
> 
> Nic
> 
> 
> 
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index d788232..72537df 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -139,6 +139,10 @@ typedef struct MatroskaTrackVideo {
>  EbmlBin color_space;
>  uint64_t stereo_mode;
>  uint64_t alpha_mode;
> +uint64_t crop_bottom;
> +uint64_t crop_top;
> +uint64_t crop_left;
> +uint64_t crop_right;
>  } MatroskaTrackVideo;
> 
>  typedef struct MatroskaTrackAudio {
> @@ -364,10 +368,10 @@ static const EbmlSyntax matroska_track_video[] = {
>  { MATROSKA_ID_VIDEOPIXELHEIGHT,EBML_UINT,  0,
> offsetof(MatroskaTrackVideo, pixel_height) },
>  { MATROSKA_ID_VIDEOCOLORSPACE, EBML_BIN,   0,
> offsetof(MatroskaTrackVideo, color_space) },
>  { MATROSKA_ID_VIDEOALPHAMODE,  EBML_UINT,  0,
> offsetof(MatroskaTrackVideo, alpha_mode) },
> -{ MATROSKA_ID_VIDEOPIXELCROPB, EBML_NONE },
> -{ MATROSKA_ID_VIDEOPIXELCROPT, EBML_NONE },
> -{ MATROSKA_ID_VIDEOPIXELCROPL, EBML_NONE },
> -{ MATROSKA_ID_VIDEOPIXELCROPR, EBML_NONE },
> +{ MATROSKA_ID_VIDEOPIXELCROPB, EBML_UINT,  0,
> offsetof(MatroskaTrackVideo, crop_bottom) },
> +{ MATROSKA_ID_VIDEOPIXELCROPT, EBML_UINT,  0,
> offsetof(MatroskaTrackVideo, crop_top) },
> +{ MATROSKA_ID_VIDEOPIXELCROPL, EBML_UINT,  0,
> offsetof(MatroskaTrackVideo, crop_left) },
> +{ MATROSKA_ID_VIDEOPIXELCROPR, EBML_UINT,  0,
> offsetof(MatroskaTrackVideo, crop_right) },
>  { MATROSKA_ID_VIDEODISPLAYUNIT,EBML_NONE },
>  { MATROSKA_ID_VIDEOFLAGINTERLACED, EBML_NONE },
>  { MATROSKA_ID_VIDEOSTEREOMODE, EBML_UINT,  0,
> offsetof(MatroskaTrackVideo, stereo_mode), { .u =
> MATROSKA_VIDEO_STEREOMODE_TYPE_NB } },
> @@ -2152,6 +2156,16 @@ static int matroska_parse_tracks(AVFormatContext *s)
>  if (track->video.stereo_mode && track->video.stereo_mode
> < MATROSKA_VIDEO_STEREOMODE_TYPE_NB)
>  av_dict_set(>metadata, "stereo_mode",
> ff_matroska_video_stereo_mode[track->video.stereo_mode], 0);
> 
> +/* export the matroska crop settings as metadata */
> +if (track->video.crop_bottom != 0)
> +av_dict_set_int(>metadata, "crop_bottom",
> track->video.crop_bottom, 0);
> +if (track->video.crop_top != 0)
> +av_dict_set_int(>metadata, "crop_top",
> track->video.crop_top, 0);
> +if (track->video.crop_left != 0)
> +av_dict_set_int(>metadata, "crop_left",
> track->video.crop_left, 0);
> +if (track->video.crop_right != 0)
> +av_dict_set_int(>metadata, "crop_right",
> track->video.crop_right, 0);
> +
>  /* export alpha mode flag as metadata tag  */
>  if (track->video.alpha_mode)
>  av_dict_set(>metadata, "alpha_mode", "1", 0);

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

Re: [FFmpeg-devel] [PATCH] avcodec/audiotoolboxenc: Fix compile error to support iOS

[Hendrik Leppkes]

On Sun, Mar 27, 2016 at 1:52 PM,   wrote:
> From: Crossle Song 
>
> Fix error libavcodec/audiotoolboxenc.c use of undeclared
> 'kAudioCodecPropertyBitRateControlMode' on iOS
>
> AudioToolbox now support iOS
> ---
>  libavcodec/audiotoolboxenc.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
> index c4d36f5..b7874e5 100644
> --- a/libavcodec/audiotoolboxenc.c
> +++ b/libavcodec/audiotoolboxenc.c
> @@ -204,6 +204,7 @@ static av_cold int ffat_init_encoder(AVCodecContext 
> *avctx)
>size, >bits_per_raw_sample);
>  }
>
> +#if !TARGET_OS_IPHONE
>  if (at->mode == -1)
>  at->mode = (avctx->flags & AV_CODEC_FLAG_QSCALE) ?
> kAudioCodecBitRateControlMode_Variable :
> @@ -222,7 +223,9 @@ static av_cold int ffat_init_encoder(AVCodecContext 
> *avctx)
>  q = 127 - q * 9;
>  AudioConverterSetProperty(at->converter, 
> kAudioCodecPropertySoundQualityForVBR,
>size, );
> -} else if (avctx->bit_rate > 0) {
> +}
> +#endif
> +if (avctx->bit_rate > 0) {

This changes the logic.

>  UInt32 rate = avctx->bit_rate;
>  AudioConverterSetProperty(at->converter, 
> kAudioConverterEncodeBitRate,
>size, );
> @@ -425,12 +428,14 @@ static const AVProfile aac_profiles[] = {
>
>  #define AE AV_OPT_FLAG_AUDIO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
>  static const AVOption options[] = {
> +#if !TARGET_OS_IPHONE
>  {"aac_at_mode", "ratecontrol mode", offsetof(ATDecodeContext, mode), 
> AV_OPT_TYPE_INT, {.i64 = -1}, -1, kAudioCodecBitRateControlMode_Variable, AE, 
> "mode"},
>  {"auto", "VBR if global quality is given; CBR otherwise", 0, 
> AV_OPT_TYPE_CONST, {.i64 = -1}, INT_MIN, INT_MAX, AE, "mode"},
>  {"cbr",  "constant bitrate", 0, AV_OPT_TYPE_CONST, {.i64 = 
> kAudioCodecBitRateControlMode_Constant}, INT_MIN, INT_MAX, AE, "mode"},
>  {"abr",  "long-term average bitrate", 0, AV_OPT_TYPE_CONST, {.i64 = 
> kAudioCodecBitRateControlMode_LongTermAverage}, INT_MIN, INT_MAX, AE, "mode"},
>  {"cvbr", "constrained variable bitrate", 0, AV_OPT_TYPE_CONST, {.i64 
> = kAudioCodecBitRateControlMode_VariableConstrained}, INT_MIN, INT_MAX, AE, 
> "mode"},
>  {"vbr" , "variable bitrate", 0, AV_OPT_TYPE_CONST, {.i64 = 
> kAudioCodecBitRateControlMode_Variable}, INT_MIN, INT_MAX, AE, "mode"},
> +#endif
>  {"aac_at_quality", "quality vs speed control", offsetof(ATDecodeContext, 
> quality), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 2, AE},
>  { NULL },
>  };
> --
> 2.7.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Thomas Mundt]

>>>Kieran Kunhya  schrieb am So, 27.3.2016:
> On Sun, 27 Mar 2016 at 13:22 Thomas Mundt  
> wrote:
> 
>> Ronald S. Bultje  schrieb am So, 27.3.2016:
>> > On Sun, Mar 27, 2016 at 7:09 AM, Thomas Mundt > ffmpeg.org> wrote:
>> >
>> >> >>>Ronald S. Bultje  schrieb am Sa, 26.3.2016:
>> >> > On Sat, Mar 26, 2016 at 10:04 AM, Thomas Mundt > at
>> >> ffmpeg.org> wrote:
>> >> >
>> >> >Kieran Kunhya  schrieb am Sa, 26.3.2016:
>> >> >> >> On Fri, 25 Mar 2016 at 22:32 Thomas Mundt > at>
>> >> ffmpeg.org> wrote:
>> >> >> >
>> >> >> >> Signed-off-by: Thomas Mundt 
>> >> >> >> ---
>> >> >> >>  libavfilter/vf_colormatrix.c | 182
>> >> >> >> ++-
>> >> >> >>
>> >> >>> >
>> >> >> > These functions are basically the same, have you considered
>> factoring
>> >> the
>> >> >> > code out?
>> >> >> >
>> >> >> > Kieran
>> >> >>
>> >> >> I thought keeping it seperate would be easier to review.
>> >> >> But I can do that. Maybe as a subsequent patch?
>> >> >
>> >> >
>> >> > I think he means templating out typelessly like h264/hevc/vp9 do. I
>> agree
>> >> > that would probably be nicer. Binary size is same but less duplicated
>> >> code.
>> >> >
>> >> > Ronald
>> >>
>> >> Okay, I tried to solve this with the use of macros. The attached file is
>> >> the result (interesting part starting at line 203).
>> >> It works, but I´m not sure if this is what you expect.
>> >> Also I didn´t find a way factoring out the two different av_clip.
>> >> One could replace av_clip_uint8 by av_clip with limits 0 and 255. But
>> this
>> >> would have an impact on speed.
>> >> If there is a more elegant way, could you please provide a short
>> example?!
>> >
>> >
>> > We don't like macros, but you're surprisingly close. Have a look at
>> > libavcodec/bit_depth_template.c and grep for its usage in libavcodec.
>> >
>> > You'll end up with a vf_colormatrixdsp_template.c file, which includes
>> > bit_depth_template.c for types/clips etc., and it will then define full
>> > functions per bit depth. This is included in vf_colormatrixdsp.c, and
>> that
>> > defines the actual dsp functions which do the core of what this filter
>> does.
>> >
>> > Since it's now in a dsp file, it'll be trivial to write x86 simd for it
>> > (which I have also in the works).
>> >
>> > Ronald
>>
>> I looked into this and sadly have to say that this would take much more
>> time than I have atm.
>> I´m not a professional programmer so I would have to fiddle out the most
>> things.
>> Sorry, but then I think it´s maybe better to drop the high bit depht
>> support patch for now.
>>
> 
> This may help:
> http://blog.pkh.me/p/20-templating-in-c.html
> 
> Kieran

Okay, thanks. Maybe I´ll find some time tonight...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Kieran Kunhya]

On Sun, 27 Mar 2016 at 13:22 Thomas Mundt 
wrote:

> Ronald S. Bultje  schrieb am So, 27.3.2016:
> > On Sun, Mar 27, 2016 at 7:09 AM, Thomas Mundt  ffmpeg.org> wrote:
> >
> >> >>>Ronald S. Bultje  schrieb am Sa, 26.3.2016:
> >> > On Sat, Mar 26, 2016 at 10:04 AM, Thomas Mundt  at
> >> ffmpeg.org> wrote:
> >> >
> >> >Kieran Kunhya  schrieb am Sa, 26.3.2016:
> >> >> >> On Fri, 25 Mar 2016 at 22:32 Thomas Mundt  at>
> >> ffmpeg.org> wrote:
> >> >> >
> >> >> >> Signed-off-by: Thomas Mundt 
> >> >> >> ---
> >> >> >>  libavfilter/vf_colormatrix.c | 182
> >> >> >> ++-
> >> >> >>
> >> >>> >
> >> >> > These functions are basically the same, have you considered
> factoring
> >> the
> >> >> > code out?
> >> >> >
> >> >> > Kieran
> >> >>
> >> >> I thought keeping it seperate would be easier to review.
> >> >> But I can do that. Maybe as a subsequent patch?
> >> >
> >> >
> >> > I think he means templating out typelessly like h264/hevc/vp9 do. I
> agree
> >> > that would probably be nicer. Binary size is same but less duplicated
> >> code.
> >> >
> >> > Ronald
> >>
> >> Okay, I tried to solve this with the use of macros. The attached file is
> >> the result (interesting part starting at line 203).
> >> It works, but I´m not sure if this is what you expect.
> >> Also I didn´t find a way factoring out the two different av_clip.
> >> One could replace av_clip_uint8 by av_clip with limits 0 and 255. But
> this
> >> would have an impact on speed.
> >> If there is a more elegant way, could you please provide a short
> example?!
> >
> >
> > We don't like macros, but you're surprisingly close. Have a look at
> > libavcodec/bit_depth_template.c and grep for its usage in libavcodec.
> >
> > You'll end up with a vf_colormatrixdsp_template.c file, which includes
> > bit_depth_template.c for types/clips etc., and it will then define full
> > functions per bit depth. This is included in vf_colormatrixdsp.c, and
> that
> > defines the actual dsp functions which do the core of what this filter
> does.
> >
> > Since it's now in a dsp file, it'll be trivial to write x86 simd for it
> > (which I have also in the works).
> >
> > Ronald
>
> I looked into this and sadly have to say that this would take much more
> time than I have atm.
> I´m not a professional programmer so I would have to fiddle out the most
> things.
> Sorry, but then I think it´s maybe better to drop the high bit depht
> support patch for now.
>

This may help:
http://blog.pkh.me/p/20-templating-in-c.html

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

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

[Thomas Mundt]

Ronald S. Bultje  schrieb am So, 27.3.2016:
> On Sun, Mar 27, 2016 at 7:09 AM, Thomas Mundt  ffmpeg.org> wrote:
>
>> >>>Ronald S. Bultje  schrieb am Sa, 26.3.2016:
>> > On Sat, Mar 26, 2016 at 10:04 AM, Thomas Mundt > ffmpeg.org> wrote:
>> >
>> >Kieran Kunhya  schrieb am Sa, 26.3.2016:
>> >> >> On Fri, 25 Mar 2016 at 22:32 Thomas Mundt 
>> ffmpeg.org> wrote:
>> >> >
>> >> >> Signed-off-by: Thomas Mundt 
>> >> >> ---
>> >> >>  libavfilter/vf_colormatrix.c | 182
>> >> >> ++-
>> >> >>
>> >>> >
>> >> > These functions are basically the same, have you considered factoring
>> the
>> >> > code out?
>> >> >
>> >> > Kieran
>> >>
>> >> I thought keeping it seperate would be easier to review.
>> >> But I can do that. Maybe as a subsequent patch?
>> >
>> >
>> > I think he means templating out typelessly like h264/hevc/vp9 do. I agree
>> > that would probably be nicer. Binary size is same but less duplicated
>> code.
>> >
>> > Ronald
>>
>> Okay, I tried to solve this with the use of macros. The attached file is
>> the result (interesting part starting at line 203).
>> It works, but I´m not sure if this is what you expect.
>> Also I didn´t find a way factoring out the two different av_clip.
>> One could replace av_clip_uint8 by av_clip with limits 0 and 255. But this
>> would have an impact on speed.
>> If there is a more elegant way, could you please provide a short example?!
>
>
> We don't like macros, but you're surprisingly close. Have a look at
> libavcodec/bit_depth_template.c and grep for its usage in libavcodec.
> 
> You'll end up with a vf_colormatrixdsp_template.c file, which includes
> bit_depth_template.c for types/clips etc., and it will then define full
> functions per bit depth. This is included in vf_colormatrixdsp.c, and that
> defines the actual dsp functions which do the core of what this filter does.
> 
> Since it's now in a dsp file, it'll be trivial to write x86 simd for it
> (which I have also in the works).
> 
> Ronald

I looked into this and sadly have to say that this would take much more time 
than I have atm.
I´m not a professional programmer so I would have to fiddle out the most things.
Sorry, but then I think it´s maybe better to drop the high bit depht support 
patch for now.

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

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

[Michael Niedermayer]

On Fri, Mar 25, 2016 at 12:50:29PM -0400, Predrag Filipovic wrote:
> 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;
> +}

Currently pcr_period defaults are handled differently from
pat_period and sdt_period
after this patch its still different, why ?

ts->sdt_packet_period and ts->pat_packet_period are initiaized to
defaults, and disabled later in case of user provided parameters

for pcr_period the user provided value is overridden (this is a bit
ugly IMHO) and pcr_packet_period set to the user provided value if any
and later only conditionally overriden in the VBR case

why do you not change pcr_packet_period / pcr_period to work like
pat_period & sdt_period ?


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

this looks wrong, i suspect this should be a loop over all services
and service->last_pcr_ts = AV_NOPTS_VALUE;

its ok to change this in a seperate patch of corse if thats cleaner


>  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
> +if (ts->mux_rate > 1 || is_start)

> -

[FFmpeg-devel] [PATCH] avcodec/audiotoolboxenc: Fix compile error to support iOS

[crosslesong]

From: Crossle Song 

Fix error libavcodec/audiotoolboxenc.c use of undeclared
'kAudioCodecPropertyBitRateControlMode' on iOS

AudioToolbox now support iOS
---
 libavcodec/audiotoolboxenc.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
index c4d36f5..b7874e5 100644
--- a/libavcodec/audiotoolboxenc.c
+++ b/libavcodec/audiotoolboxenc.c
@@ -204,6 +204,7 @@ static av_cold int ffat_init_encoder(AVCodecContext *avctx)
   size, >bits_per_raw_sample);
 }
 
+#if !TARGET_OS_IPHONE
 if (at->mode == -1)
 at->mode = (avctx->flags & AV_CODEC_FLAG_QSCALE) ?
kAudioCodecBitRateControlMode_Variable :
@@ -222,7 +223,9 @@ static av_cold int ffat_init_encoder(AVCodecContext *avctx)
 q = 127 - q * 9;
 AudioConverterSetProperty(at->converter, 
kAudioCodecPropertySoundQualityForVBR,
   size, );
-} else if (avctx->bit_rate > 0) {
+}
+#endif
+if (avctx->bit_rate > 0) {
 UInt32 rate = avctx->bit_rate;
 AudioConverterSetProperty(at->converter, kAudioConverterEncodeBitRate,
   size, );
@@ -425,12 +428,14 @@ static const AVProfile aac_profiles[] = {
 
 #define AE AV_OPT_FLAG_AUDIO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
 static const AVOption options[] = {
+#if !TARGET_OS_IPHONE
 {"aac_at_mode", "ratecontrol mode", offsetof(ATDecodeContext, mode), 
AV_OPT_TYPE_INT, {.i64 = -1}, -1, kAudioCodecBitRateControlMode_Variable, AE, 
"mode"},
 {"auto", "VBR if global quality is given; CBR otherwise", 0, 
AV_OPT_TYPE_CONST, {.i64 = -1}, INT_MIN, INT_MAX, AE, "mode"},
 {"cbr",  "constant bitrate", 0, AV_OPT_TYPE_CONST, {.i64 = 
kAudioCodecBitRateControlMode_Constant}, INT_MIN, INT_MAX, AE, "mode"},
 {"abr",  "long-term average bitrate", 0, AV_OPT_TYPE_CONST, {.i64 = 
kAudioCodecBitRateControlMode_LongTermAverage}, INT_MIN, INT_MAX, AE, "mode"},
 {"cvbr", "constrained variable bitrate", 0, AV_OPT_TYPE_CONST, {.i64 = 
kAudioCodecBitRateControlMode_VariableConstrained}, INT_MIN, INT_MAX, AE, 
"mode"},
 {"vbr" , "variable bitrate", 0, AV_OPT_TYPE_CONST, {.i64 = 
kAudioCodecBitRateControlMode_Variable}, INT_MIN, INT_MAX, AE, "mode"},
+#endif
 {"aac_at_quality", "quality vs speed control", offsetof(ATDecodeContext, 
quality), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 2, AE},
 { NULL },
 };
-- 
2.7.0

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

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

[Ronald S. Bultje]

Hi,

On Sun, Mar 27, 2016 at 7:09 AM, Thomas Mundt <
loudmax-at-yahoo...@ffmpeg.org> wrote:

> >>>Ronald S. Bultje  schrieb am Sa, 26.3.2016:
> > On Sat, Mar 26, 2016 at 10:04 AM, Thomas Mundt  ffmpeg.org> wrote:
> >
> >Kieran Kunhya  schrieb am Sa, 26.3.2016:
> >> >> On Fri, 25 Mar 2016 at 22:32 Thomas Mundt 
> ffmpeg.org> wrote:
> >> >
> >> >> Signed-off-by: Thomas Mundt 
> >> >> ---
> >> >>  libavfilter/vf_colormatrix.c | 182
> >> >> ++-
> >> >>
> >>> >
> >> > These functions are basically the same, have you considered factoring
> the
> >> > code out?
> >> >
> >> > Kieran
> >>
> >> I thought keeping it seperate would be easier to review.
> >> But I can do that. Maybe as a subsequent patch?
> >
> >
> > I think he means templating out typelessly like h264/hevc/vp9 do. I agree
> > that would probably be nicer. Binary size is same but less duplicated
> code.
> >
> > Ronald
>
> Okay, I tried to solve this with the use of macros. The attached file is
> the result (interesting part starting at line 203).
> It works, but I´m not sure if this is what you expect.
> Also I didn´t find a way factoring out the two different av_clip.
> One could replace av_clip_uint8 by av_clip with limits 0 and 255. But this
> would have an impact on speed.
> If there is a more elegant way, could you please provide a short example?!


We don't like macros, but you're surprisingly close. Have a look at
libavcodec/bit_depth_template.c and grep for its usage in libavcodec.

You'll end up with a vf_colormatrixdsp_template.c file, which includes
bit_depth_template.c for types/clips etc., and it will then define full
functions per bit depth. This is included in vf_colormatrixdsp.c, and that
defines the actual dsp functions which do the core of what this filter does.

Since it's now in a dsp file, it'll be trivial to write x86 simd for it
(which I have also in the works).

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

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

[Thomas Mundt]

>>>Ronald S. Bultje  schrieb am Sa, 26.3.2016:
> On Sat, Mar 26, 2016 at 10:04 AM, Thomas Mundt  ffmpeg.org> wrote:
> 
>Kieran Kunhya  schrieb am Sa, 26.3.2016:
>> >> On Fri, 25 Mar 2016 at 22:32 Thomas Mundt  
>> >> ffmpeg.org> wrote:
>> >
>> >> Signed-off-by: Thomas Mundt 
>> >> ---
>> >>  libavfilter/vf_colormatrix.c | 182
>> >> ++-
>> >>
>>> >
>> > These functions are basically the same, have you considered factoring the
>> > code out?
>> >
>> > Kieran
>>
>> I thought keeping it seperate would be easier to review.
>> But I can do that. Maybe as a subsequent patch?
>
>
> I think he means templating out typelessly like h264/hevc/vp9 do. I agree
> that would probably be nicer. Binary size is same but less duplicated code.
> 
> Ronald

Okay, I tried to solve this with the use of macros. The attached file is the 
result (interesting part starting at line 203).
It works, but I´m not sure if this is what you expect.
Also I didn´t find a way factoring out the two different av_clip.
One could replace av_clip_uint8 by av_clip with limits 0 and 255. But this 
would have an impact on speed.
If there is a more elegant way, could you please provide a short example?!

Happy Easter!
Thomas/*
 * ColorMatrix v2.2 for Avisynth 2.5.x
 *
 * Copyright (C) 2006-2007 Kevin Stone
 *
 * ColorMatrix 1.x is Copyright (C) Wilbert Dijkhof
 *
 * This program is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License as published by the
 * Free Software Foundation; either version 2 of the License, or (at your
 * option) any later version.
 *
 * This program is distributed in the hope that it will be useful, but
 * OUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
 * or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
 * License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
 */

/**
 * @file
 * ColorMatrix 2.0 is based on the original ColorMatrix filter by Wilbert
 * Dijkhof.  It adds the ability to convert between any of: Rec.709, FCC,
 * Rec.601, and SMPTE 240M. It also makes pre and post clipping optional,
 * adds an option to use scaled or non-scaled coefficients, and more...
 */

#include 
#include "avfilter.h"
#include "formats.h"
#include "internal.h"
#include "video.h"
#include "libavutil/opt.h"
#include "libavutil/pixdesc.h"
#include "libavutil/avstring.h"

#define NS(n) ((n) < 0 ? (int)((n)*65536.0-0.5+DBL_EPSILON) : (int)((n)*65536.0+0.5))

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 {
COLOR_MODE_NONE = -1,
COLOR_MODE_BT709,
COLOR_MODE_FCC,
COLOR_MODE_BT601,
COLOR_MODE_SMPTE240M,
COLOR_MODE_BT2020,
COLOR_MODE_COUNT
};

typedef struct {
const AVClass *class;
const AVPixFmtDescriptor *csp;
int yuv_convert[25][3][3];
int source, dest;///< ColorMode
int mode;
} ColorMatrixContext;

typedef struct ThreadData {
AVFrame *dst;
const AVFrame *src;
int c2;
int c3;
int c4;
int c5;
int c6;
int c7;
} ThreadData;

#define OFFSET(x) offsetof(ColorMatrixContext, x)
#define FLAGS AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM

static const AVOption colormatrix_options[] = {
{ "src", "set source color matrix",  OFFSET(source), AV_OPT_TYPE_INT, {.i64=COLOR_MODE_NONE}, COLOR_MODE_NONE, COLOR_MODE_COUNT-1, .flags=FLAGS, .unit="color_mode" },
{ "dst", "set destination color matrix", OFFSET(dest),   AV_OPT_TYPE_INT, {.i64=COLOR_MODE_NONE}, COLOR_MODE_NONE, COLOR_MODE_COUNT-1, .flags=FLAGS, .unit="color_mode" },
{ "bt709", "set BT.709 colorspace",  0, AV_OPT_TYPE_CONST, {.i64=COLOR_MODE_BT709},   .flags=FLAGS, .unit="color_mode" },
{ "fcc",   "set FCC colorspace   ",  0, AV_OPT_TYPE_CONST, {.i64=COLOR_MODE_FCC}, .flags=FLAGS, .unit="color_mode" },
{ "bt601", "set BT.601 colorspace",  0, AV_OPT_TYPE_CONST, {.i64=COLOR_MODE_BT601},   .flags=FLAGS, .unit="color_mode" },
{ "bt470", "set BT.470 colorspace",  0, AV_OPT_TYPE_CONST, {.i64=COLOR_MODE_BT601},   .flags=FLAGS, .unit="color_mode" },
{ "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,