Re: [FFmpeg-devel] 2.9/3.0, 2.8.5, ...

[Ganesh Ajjanagadde]

On Fri, Jan 1, 2016 at 6:19 AM, Michael Niedermayer
 wrote:
> Hi all
>
> Its a while since 2.8 so unless there are objections i will make a
> 2.9 or if people prefer a 3.0 within the next month or so

No opinion on 2.9 vs 3.0.
If going with 3.0, I propose the release name "Boole" or "Shannon" -
http://www.rle.mit.edu/ncrc/boole-shannon-lecture-series/ (200 years
of Boole, 100 years of Shannon +/- 1 year).

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

Re: [FFmpeg-devel] [PATCH] lavf/qtpalette: Ignore greyscale bit in certain cases

[Mats Peterson]

On 01/02/2016 06:40 AM, Mats Peterson wrote:

The text with the links got lost. And the second file is not Animation, 
but Graphics (smc). It's irrelevant, though.


Sample file 1 (1-bit QuickTime Animation):
https://drive.google.com/open?id=0B3_pEBoLs0faTThSek1EeXQ0ZHM

Sample file 2 (8-bit QuickTime Graphics):
https://drive.google.com/open?id=0B3_pEBoLs0fad2s0V1YzUWo5aDA

Mats

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

Re: [FFmpeg-devel] [RFC v4] libbavcodec: add a native decoder for the Daala video codec

[Rostislav Pehlivanov]

>To the very best of my knowledge you are allowed
>to relicense code that was published under a two-
>(or three-) clause BSD license under the GPL (and
>the LGPL) as long as you keep the copyright
>notice.

Yes, that's what I've concluded as well.
Basically, the license says:
>Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
Which means as long as I keep all the copyright notice of previous
contributors (e.g. Copyright 2001-2015 Xiph.org) I am allowed to change the
license. I was under the impression I was unable to remove the BSD license

So for the next RFC I'll just use the project's LGPL license, which is what
I prefer.

Thanks for the help.

On 2 January 2016 at 00:41, Carl Eugen Hoyos  wrote:

> Rostislav Pehlivanov  gmail.com> writes:
>
> > Fair enough, I will leave only the BSD-2 clause license
> > and I'll put the files as an exception when I send the
> > decoder as another RFC.
>
> This would be fine but please see below: If you prefer
> the LGPL, please use it!
>
> > Ronald has agreed to review the decoder (on a technical
> > side of things) if he has time this weekend so I'll wait
> > for him to try to finish his review.
>
> Sounds great to me!
>
> > In any case, can you check out ./libavcodec/mips/aac* ?
> > They have both the BSD license and the FFmpeg license at
> > the top, which is what I did. If that's not valid then
> > we should probably consider doing something about that.
>
> You are right that there is something (imo very) wrong;-(
>
> > >but as said please choose one license and use (only)
> > >the one you choose for the newly added files.
> >
> > I would have used the LGPL license but unfortunately
> > since there are no specifications and only a reference
> > decoder I had to reuse parts of it (DCT and PVQ parts
> > of the code) and although you can argue that really
> > there is no other way to actually write a decoder the
> > BSD license states that whatever happens to the code
> > the license needs to stay.
>
> To the very best of my knowledge you are allowed
> to relicense code that was published under a two-
> (or three-) clause BSD license under the GPL (and
> the LGPL) as long as you keep the copyright
> notice.
>
> Carl Eugen
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC v4] libbavcodec: add a native decoder for the Daala video codec

[Carl Eugen Hoyos]

Carl Eugen Hoyos  ag.or.at> writes:

[...]

We were apparently both wrong:
https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html

So please place the original (two-clause BSD) license 
including the copyright statement under your (new) LGPL 
license.

Sorry for the noise, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: replace log2 by faster variant

[Ganesh Ajjanagadde]

On Wed, Dec 30, 2015 at 1:01 AM, Hendrik Leppkes  wrote:
> On Wed, Dec 30, 2015 at 4:39 AM, Ganesh Ajjanagadde
>  wrote:
>> The log is anyway rounded to an integer, so one may use an frexp
>> based approach. Note that this may be made frexpf; if arguments are less than
>> 2^24 there is no loss. Kept as double precision for simplicity; 2^32 is
>> exactly representable as a double.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  ffmpeg.c | 13 -
>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/ffmpeg.c b/ffmpeg.c
>> index 6d01987..ee72f91 100644
>> --- a/ffmpeg.c
>> +++ b/ffmpeg.c
>> @@ -1486,6 +1486,17 @@ static void print_final_stats(int64_t total_size)
>>  }
>>  }
>>
>> +static inline int log2i(double d)
>> +{
>> +int exp;
>> +double mant;
>> +
>> +mant = frexp(d, );
>> +if (mant >= M_SQRT1_2)
>> +return exp;
>> +return exp-1;
>> +}
>> +
>>  static void print_report(int is_last_report, int64_t timer_start, int64_t 
>> cur_time)
>>  {
>>  char buf[1024];
>> @@ -1559,7 +1570,7 @@ static void print_report(int is_last_report, int64_t 
>> timer_start, int64_t cur_ti
>>  if (qp >= 0 && qp < FF_ARRAY_ELEMS(qp_histogram))
>>  qp_histogram[qp]++;
>>  for (j = 0; j < 32; j++)
>> -snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), 
>> "%X", (int)lrintf(log2(qp_histogram[j] + 1)));
>> +snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), 
>> "%X", log2i(qp_histogram[j] + 1));
>>  }
>>
>>  if ((enc->flags & AV_CODEC_FLAG_PSNR) && (ost->pict_type != 
>> AV_PICTURE_TYPE_NONE || is_last_report)) {
>> --
>> 2.6.4
>
> This isn't exactly a performance critical area, and defining a custom
> function just for this seems somewhat like over-optimization.
> Just my opinion, of course, I'll leave the decision up to the
> maintainers of ffmpeg.c

Ping: based on the above, final decision left to you, Michael.

> ___
> 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] doc: make apidoc output independent of SRC_PATH

[Michael Niedermayer]

On Sun, Dec 20, 2015 at 11:31:29PM +0100, Andreas Cadhalpun wrote:
> Previously it included the SRC_PATH in every title.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  doc/Makefile|  7 ---
>  doc/doxy-wrapper.sh | 11 ++-
>  2 files changed, 10 insertions(+), 8 deletions(-)

should be ok if tested

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

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


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

Re: [FFmpeg-devel] [PATCH] avcodec/utils: Add case for mp3 to av_get_audio_frame_duration()

[Michael Niedermayer]

On Fri, Jan 01, 2016 at 07:33:58PM +0100, Hendrik Leppkes wrote:
> On Fri, Jan 1, 2016 at 7:29 PM, Ronald S. Bultje  wrote:
> > Hi,
> >
> > On Fri, Jan 1, 2016 at 11:43 AM, Michael Niedermayer 
> > wrote:
> >
> >> From: Michael Niedermayer 
> >>
> >> This is not guranteed to be correct but only the encoder or the packet
> >> headers
> >> can really provide the correct value. And before the first packet there is
> >> no alternative to receiving the value from the encoder by some means
> >>
> >> other codecs like AAC are still missing and are left for voluteers
> >>
> >> Signed-off-by: Michael Niedermayer 
> >> ---
> >>  libavcodec/utils.c |6 ++
> >>  1 file changed, 6 insertions(+)
> >>
> >> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> >> index 4b4aea0..6ed47ef 100644
> >> --- a/libavcodec/utils.c
> >> +++ b/libavcodec/utils.c
> >> @@ -3042,6 +3042,12 @@ int av_get_audio_frame_duration(AVCodecContext
> >> *avctx, int frame_bytes)
> >>  if (id == AV_CODEC_ID_TTA)
> >>  return 256 * sr / 245;
> >>
> >> +// When frame_bytes is set then the headers can be parsed to find
> >> the
> >> +// frame size
> >> +if (id == AV_CODEC_ID_MP3 && !frame_bytes) {
> >> +return sr <= 24000 ? 576 : 1152;
> >> +}
> >> +
> >>  if (ch > 0) {
> >>  /* calc from sample rate and channels */
> >>  if (id == AV_CODEC_ID_BINKAUDIO_DCT)
> >> --
> >> 1.7.9.5
> >
> >
> > Please, no more codec-specific hacks in generic code.
> >
> 
> This whole function is codec specific crazy.

yes, i surely would not mind if someone would split this function
into codecs or parsers or a callback in codec descriptors

AVCodecs is semantically wrong though as this is not specific to a
codec implementation

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [RFC v4] libbavcodec: add a native decoder for the Daala video codec

[Carl Eugen Hoyos]

Rostislav Pehlivanov  gmail.com> writes:

> >this would fail on beos acording to doc/errno.txt
> Fixed, replaced with EINVAL in my private tree (

> https://github.com/atomnuker/FFmpeg

Sorry but the licensing simply makes no sense now:
The files should be - at you choice - either 
licensed under the LGPL or the license that 
libdaala uses.
It is not necessary to "double-license" it: You 
could switch to LGPL any time, if you want a 
less restrictive license, keep the libdaala 
license, no need to add the LGPL.

Thank you, Carl Eugen

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

Re: [FFmpeg-devel] [RFC v4] libbavcodec: add a native decoder for the Daala video codec

[Rostislav Pehlivanov]

The reason why the FFmpeg license was added as well was to keep FATE happy
and not have to put an exception for it (since all the exceptions are just
for empty template files). The way I understand it is that the license
above is the license for the file and all the code within it, while the
license below is the FFmpeg project license alone. Not a dual license.
Anyone wishing to use the decoder outside FFmpeg is free to do so under the
BSD 2 clause license while anyone wishing to use it as it is in FFmpeg
would still need to respect the LGPL.
At least that's my understanding of how the AAC Fixed point contributions
are licensed. In case this is really what happens (and I am not a lawyer)
then we could prevent the confusion from happening by putting a comment
above the FFmpeg license which says that the license below is void in case
the decoder is used outside FFmpeg.

On 1 January 2016 at 23:18, Carl Eugen Hoyos  wrote:

> Rostislav Pehlivanov  gmail.com> writes:
>
> > >this would fail on beos acording to doc/errno.txt
> > Fixed, replaced with EINVAL in my private tree (
>
> > https://github.com/atomnuker/FFmpeg
>
> Sorry but the licensing simply makes no sense now:
> The files should be - at you choice - either
> licensed under the LGPL or the license that
> libdaala uses.
> It is not necessary to "double-license" it: You
> could switch to LGPL any time, if you want a
> less restrictive license, keep the libdaala
> license, no need to add the LGPL.
>
> Thank you, Carl Eugen
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC v4] libbavcodec: add a native decoder for the Daala video codec

[Rostislav Pehlivanov]

Fair enough, I will leave only the BSD-2 clause license and I'll put the
files as an exception when I send the decoder as another RFC.
Ronald has agreed to review the decoder (on a technical side of things) if
he has time this weekend so I'll wait for him to try to finish his review.

In any case, can you check out ./libavcodec/mips/aac* ?
They have both the BSD license and the FFmpeg license at the top, which is
what I did. If that's not valid then we should probably consider doing
something about that.

>but as said please choose one license and use (only)
>the one you choose for the newly added files.
I would have used the LGPL license but unfortunately since there are no
specifications and only a reference decoder I had to reuse parts of it (DCT
and PVQ parts of the code) and although you can argue that really there is
no other way to actually write a decoder the BSD license states that
whatever happens to the code the license needs to stay.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/utils: fix AVPacket lifetime in seek_frame_generic

[Hendrik Leppkes]

Fixes ticket #5117
---
 libavformat/utils.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 95acbf3..7606502 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2142,15 +2142,18 @@ static int seek_frame_generic(AVFormatContext *s, int 
stream_index,
 } while (read_status == AVERROR(EAGAIN));
 if (read_status < 0)
 break;
-av_packet_unref();
 if (stream_index == pkt.stream_index && pkt.dts > timestamp) {
-if (pkt.flags & AV_PKT_FLAG_KEY)
+if (pkt.flags & AV_PKT_FLAG_KEY) {
+av_packet_unref();
 break;
+}
 if (nonkey++ > 1000 && st->codec->codec_id != 
AV_CODEC_ID_CDGRAPHICS) {
 av_log(s, AV_LOG_ERROR,"seek_frame_generic failed as this 
stream seems to contain no keyframes after the target timestamp, %d non 
keyframes found\n", nonkey);
+av_packet_unref();
 break;
 }
 }
+av_packet_unref();
 }
 index = av_index_search_timestamp(st, timestamp, flags);
 }
-- 
2.6.2.windows.1

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

Re: [FFmpeg-devel] [PATCH] oggparsedaala: reject too large gpshift

[Michael Niedermayer]

On Wed, Dec 30, 2015 at 01:00:43AM +0100, Andreas Cadhalpun wrote:
> On 29.12.2015 22:27, Rostislav Pehlivanov wrote:
> > oggparsetheora has the same bit of code to read the gpshift, so it would
> > probably be a good idea to add it to this patch as well.
> 
> No, oggparsetheora only reads 5 bits for gpshift.
> The only thing from this patch that also applies there is the (theoretical)
> issue of 1<<31 not being defined for int32_t.
> 
> On 29.12.2015 22:32, Hendrik Leppkes wrote:
> > 1U << hdr->gpshift?
> 
> Sure. Updated patch attached.
> 
> Best regards,
> Andreas

>  oggparsedaala.c  |7 ++-
>  oggparsetheora.c |2 +-
>  2 files changed, 7 insertions(+), 2 deletions(-)
> ced39ad8585220f35fcac769d9fa0244c5a28aed  
> 0001-oggparsedaala-reject-too-large-gpshift.patch
> From 4380123388f38eb9bbd11db34b0ac82a9ec18d5a Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun 
> Date: Tue, 29 Dec 2015 18:32:01 +0100
> Subject: [PATCH] oggparsedaala: reject too large gpshift
> 
> Also use a unsigned constant for the shift calculation, as 1 << 31 is
> undefined for int32_t. This is also fixed oggparsetheora.
> 
> This fixes ubsan runtime error: shift exponent is too large for
> 32-bit type 'int'
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/oggparsedaala.c  | 7 ++-
>  libavformat/oggparsetheora.c | 2 +-
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/oggparsedaala.c b/libavformat/oggparsedaala.c
> index 24567f9..3651ca1 100644
> --- a/libavformat/oggparsedaala.c
> +++ b/libavformat/oggparsedaala.c
> @@ -123,7 +123,12 @@ static int daala_header(AVFormatContext *s, int idx)
>  
>  hdr->frame_duration = bytestream2_get_ne32();
>  hdr->gpshift = bytestream2_get_byte();
> -hdr->gpmask  = (1 << hdr->gpshift) - 1;
> +if (hdr->gpshift >= 32) {
> +av_log(s, AV_LOG_ERROR, "Too large gpshift %d (>= 32).\n",
> +   hdr->gpshift);
> +return AVERROR_INVALIDDATA;
> +}
> +hdr->gpmask  = (1U << hdr->gpshift) - 1;
>  
>  hdr->format.depth  = 8 + 2*(bytestream2_get_byte()-1);
>  

> diff --git a/libavformat/oggparsetheora.c b/libavformat/oggparsetheora.c
> index 6e6a362..5f057c3 100644
> --- a/libavformat/oggparsetheora.c
> +++ b/libavformat/oggparsetheora.c
> @@ -108,7 +108,7 @@ static int theora_header(AVFormatContext *s, int idx)
>  skip_bits(, 2);
>  
>  thp->gpshift = get_bits(, 5);
> -thp->gpmask  = (1 << thp->gpshift) - 1;
> +thp->gpmask  = (1U << thp->gpshift) - 1;
>  
>  st->codec->codec_type = AVMEDIA_TYPE_VIDEO;
>  st->codec->codec_id   = AV_CODEC_ID_THEORA;

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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

Re: [FFmpeg-devel] [RFC v4] libbavcodec: add a native decoder for the Daala video codec

[Ganesh Ajjanagadde]

On Fri, Jan 1, 2016 at 12:16 PM, Rostislav Pehlivanov
 wrote:
> Thanks for the feedback.
> Fixed all the issues you reported. The new revision is in this email.
>
> I've replaced the daalaent_cphase with a macro instead. Saves a few lines.
>
> I don't think it's a problem having large functions marked as inline.
> Sure they won't be inlined (not with current GCC version anyway) but
> I've always though it was best to leave it up for the compiler to know
> how big is too big.

At O3, small functions get inlined anyway based on the judgement of
the compiler regardless of inline/no inline keyword. Thus, why bother
with the keyword?

> Although if you still think they should be just left as  or
> moved to a C file then just say so.

Please get rid of the inlines where pointed out by others. Whether to
do it as  or moved to a C file is really up to you.

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

Re: [FFmpeg-devel] [RFC v4] libbavcodec: add a native decoder for the Daala video codec

[Rostislav Pehlivanov]

I'm not sure about that, the page doesn't list what happens if an LGPL
project uses some parts of a BSD project. The decoder was started from
scratch and the parts which were taken from libdaala (DCTs, PVQ and the
entropy decoder) have had major modifications done to them. So I still
think it's fine to just state the Xiph copyright and use only the LGPL
license.

I found this page which states that I'm allowed to do this:
http://lucumr.pocoo.org/2009/2/12/are-you-sure-you-want-to-use-gpl/

And it does make sense, the license says to always keep the copyright but
does not say to retain the BSD license nor what would happen should major
modifications be done to it. Hence why it's GPL compatible.

On 2 January 2016 at 00:51, Carl Eugen Hoyos  wrote:

> Carl Eugen Hoyos  ag.or.at> writes:
>
> [...]
>
> We were apparently both wrong:
>
> https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
>
> So please place the original (two-clause BSD) license
> including the copyright statement under your (new) LGPL
> license.
>
> Sorry for the noise, Carl Eugen
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC v4] libbavcodec: add a native decoder for the Daala video codec

[Carl Eugen Hoyos]

Rostislav Pehlivanov  gmail.com> writes:

> The reason why the FFmpeg license was added as well 
> was to keep FATE happy

Then please add the new license to FATE but remove 
the unintended license from the new source files.

You could also leave the test broken: I believe that 
this should not be normally done but intentionally 
adding a new license and fixing the test afterward 
sounds ok to me.

[...]

I simply don't understand your reasoning and this 
may absolutely be my fault not being a native speaker 
but as said please choose one license and use (only) 
the one you choose for the newly added files.

Thank you, Carl Eugen

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

[FFmpeg-devel] [PATCH] libavcodec/ccaption_dec: remove unnecessary buffering of closed caption packets

[Aman Gupta]

From: Aman Gupta 

CC data is fed to in small chunks (usually 60 bytes at a time)
and is parsed fully by the eia608 decoder. There is no reason to copy it
into a secondary buffer first.
---
 libavcodec/ccaption_dec.c | 22 +-
 1 file changed, 1 insertion(+), 21 deletions(-)

diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index 9f67caa..4b1d376 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -167,8 +167,6 @@ typedef struct CCaptionSubContext {
 int64_t startv_time;
 int64_t end_time;
 char prev_cmd[2];
-/* buffer to store pkt data */
-AVBufferRef *pktbuf;
 }CCaptionSubContext;
 
 
@@ -185,11 +183,6 @@ static av_cold int init_decoder(AVCodecContext *avctx)
 if(ret < 0) {
 return ret;
 }
-/* allocate pkt buffer */
-ctx->pktbuf = av_buffer_alloc(128);
-if( !ctx->pktbuf) {
-ret = AVERROR(ENOMEM);
-}
 return ret;
 }
 
@@ -197,7 +190,6 @@ static av_cold int close_decoder(AVCodecContext *avctx)
 {
 CCaptionSubContext *ctx = avctx->priv_data;
 av_bprint_finalize( >buffer, NULL);
-av_buffer_unref(>pktbuf);
 return 0;
 }
 
@@ -524,23 +516,11 @@ static int decode(AVCodecContext *avctx, void *data, int 
*got_sub, AVPacket *avp
 {
 CCaptionSubContext *ctx = avctx->priv_data;
 AVSubtitle *sub = data;
-uint8_t *bptr = NULL;
+uint8_t *bptr = avpkt->data;
 int len = avpkt->size;
 int ret = 0;
 int i;
 
-if ( ctx->pktbuf->size < len) {
-ret = av_buffer_realloc(>pktbuf, len);
- if(ret < 0) {
-av_log(ctx, AV_LOG_WARNING, "Insufficient Memory of %d truncated 
to %d\n",len, ctx->pktbuf->size);
-len = ctx->pktbuf->size;
-ret = 0;
-}
-}
-memcpy(ctx->pktbuf->data, avpkt->data, len);
-bptr = ctx->pktbuf->data;
-
-
 for (i  = 0; i < len; i += 3) {
 uint8_t cc_type = *(bptr + i) & 3;
 if (validate_cc_data_pair( bptr + i) )
-- 
2.5.3

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

Re: [FFmpeg-devel] [RFC v4] libbavcodec: add a native decoder for the Daala video codec

[Carl Eugen Hoyos]

Rostislav Pehlivanov  gmail.com> writes:

> Fair enough, I will leave only the BSD-2 clause license 
> and I'll put the files as an exception when I send the 
> decoder as another RFC.

This would be fine but please see below: If you prefer 
the LGPL, please use it!

> Ronald has agreed to review the decoder (on a technical 
> side of things) if he has time this weekend so I'll wait 
> for him to try to finish his review.

Sounds great to me!

> In any case, can you check out ./libavcodec/mips/aac* ?
> They have both the BSD license and the FFmpeg license at 
> the top, which is what I did. If that's not valid then 
> we should probably consider doing something about that.

You are right that there is something (imo very) wrong;-(

> >but as said please choose one license and use (only)
> >the one you choose for the newly added files.
>
> I would have used the LGPL license but unfortunately 
> since there are no specifications and only a reference 
> decoder I had to reuse parts of it (DCT and PVQ parts 
> of the code) and although you can argue that really 
> there is no other way to actually write a decoder the 
> BSD license states that whatever happens to the code 
> the license needs to stay.

To the very best of my knowledge you are allowed 
to relicense code that was published under a two- 
(or three-) clause BSD license under the GPL (and 
the LGPL) as long as you keep the copyright 
notice.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] avcodec/utils: fix AVPacket lifetime in seek_frame_generic

[Michael Niedermayer]

On Sat, Jan 02, 2016 at 01:21:04AM +0100, Hendrik Leppkes wrote:
> Fixes ticket #5117
> ---
>  libavformat/utils.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)

LGTM

thx

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


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

[FFmpeg-devel] [PATCH] lavf/qtpalette: Ignore greyscale bit in certain cases

[Mats Peterson]

The QuickTime File Format Specification states the following:

"Depth: A 16-bit integer that indicates the pixel depth of the
compressed image. Values of 1, 2, 4, 8 ,16, 24, and 32 indicate the
depth of color images. The value 32 should be used only if the image
contains an alpha channel. Values of 34, 36, and 40 indicate 2-, 4-, and
8-bit grayscale, respectively, for grayscale images."

There is no mention of value 33, i.e. 1-bit video (0x01) with the
greyscale bit (0x20) set. I therefore suggest that we ignore the
greyscale bit when processing 1-bit video. Another reason to do this is
that the first 1-bit sample file below will be displayed properly with
blue colors in QuickTime in Windows or Mac *in spite of* the greyscale
bit being set.

Also, QuickTime in Windows or Mac ignores the greyscale bit if the
video sample description contains a palette, regardless of bit depth.
This is undocumented behaviour, but I think we should do the same, and
it seems pretty logical after all, since one wouldn't really bother
putting a customized palette into a grayscale file anyway. See the
second 8-bit sample file below, which has the greyscale bit set, and
which contains a palette in the video sample description. In Windows or
Mac, it will be displayed with the palette in the sample description, in
spite of the greyscale bit being set.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From f7e156da9c9cd7a878fb79faf54751ebb71f1527 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sat, 2 Jan 2016 06:30:22 +0100
Subject: [PATCH] lavf/qtpalette: Ignore greyscale bit in certain cases

The QuickTime File Format Specification states the following:

"Depth: A 16-bit integer that indicates the pixel depth of the
compressed image. Values of 1, 2, 4, 8 ,16, 24, and 32 indicate the
depth of color images. The value 32 should be used only if the image
contains an alpha channel. Values of 34, 36, and 40 indicate 2-, 4-, and
8-bit grayscale, respectively, for grayscale images."

There is no mention of value 33, i.e. 1-bit video (0x01) with the
greyscale bit (0x20) set. I therefore suggest that we ignore the
greyscale bit when processing 1-bit video. Another reason to do this is
that the first 1-bit sample file below will be displayed properly with
blue colors in QuickTime in Windows or Mac *in spite of* the greyscale
bit being set.

Also, QuickTime in Windows or Mac ignores the greyscale bit if the
video sample description contains a palette, regardless of bit depth.
This is undocumented behaviour, but I think we should do the same, and
it seems pretty logical after all, since one wouldn't really bother
putting a customized palette into a grayscale file anyway. See the
second 8-bit sample file below, which has the greyscale bit set, and
which contains a palette in the video sample description. In Windows or
Mac, it will be displayed with the palette in the sample description, in
spite of the greyscale bit being set.

Sample file 1 (1-bit QuickTime Animation):
https://drive.google.com/open?id=0B3_pEBoLs0faTThSek1EeXQ0ZHM

Sample file 2 (8-bit QuickTime Animation):
https://drive.google.com/open?id=0B3_pEBoLs0fad2s0V1YzUWo5aDA

Mats

---
 libavformat/qtpalette.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/qtpalette.c b/libavformat/qtpalette.c
index 6544a55..a78b6af 100644
--- a/libavformat/qtpalette.c
+++ b/libavformat/qtpalette.c
@@ -51,7 +51,9 @@ int ff_get_qtpalette(int codec_id, AVIOContext *pb, uint32_t *palette)
 int color_count, color_start, color_end;
 uint32_t a, r, g, b;
 
-if (greyscale) {
+/* Ignore the greyscale bit for 1-bit video and sample
+ * descriptions containing a color table. */
+if (greyscale && bit_depth > 1 && color_table_id) {
 int color_index, color_dec;
 /* compute the greyscale palette */
 color_count = 1 << bit_depth;
-- 
1.7.10.4

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

[FFmpeg-devel] PATCH] lavf/qtpalette: Ignore greyscale bit in certain cases

[Mats Peterson]

The QuickTime File Format Specification states the following:

"Depth: A 16-bit integer that indicates the pixel depth of the
compressed image. Values of 1, 2, 4, 8 ,16, 24, and 32 indicate the
depth of color images. The value 32 should be used only if the image
contains an alpha channel. Values of 34, 36, and 40 indicate 2-, 4-, and
8-bit grayscale, respectively, for grayscale images."

There is no mention of value 33, i.e. 1-bit video (0x01) with the
greyscale bit (0x20) set. I therefore suggest that we ignore the
greyscale bit when processing 1-bit video. Another reason to do this is
that the first 1-bit sample file below will be displayed properly with
blue colors in QuickTime in Windows or Mac *in spite of* the greyscale
bit being set.

Also, QuickTime in Windows or Mac ignores the greyscale bit if the
video sample description contains a palette, regardless of bit depth.
This is undocumented behaviour, but I think we should do the same, and
it seems pretty logical after all, since one wouldn't really bother
putting a customized palette into a grayscale file anyway. See the
second 8-bit sample file below, which has the greyscale bit set, and
which contains a palette in the video sample description. In Windows or
Mac, it will be displayed with the palette in the sample description, in
spite of the greyscale bit being set.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From f7e156da9c9cd7a878fb79faf54751ebb71f1527 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sat, 2 Jan 2016 06:30:22 +0100
Subject: [PATCH] lavf/qtpalette: Ignore greyscale bit in certain cases

The QuickTime File Format Specification states the following:

"Depth: A 16-bit integer that indicates the pixel depth of the
compressed image. Values of 1, 2, 4, 8 ,16, 24, and 32 indicate the
depth of color images. The value 32 should be used only if the image
contains an alpha channel. Values of 34, 36, and 40 indicate 2-, 4-, and
8-bit grayscale, respectively, for grayscale images."

There is no mention of value 33, i.e. 1-bit video (0x01) with the
greyscale bit (0x20) set. I therefore suggest that we ignore the
greyscale bit when processing 1-bit video. Another reason to do this is
that the first 1-bit sample file below will be displayed properly with
blue colors in QuickTime in Windows or Mac *in spite of* the greyscale
bit being set.

Also, QuickTime in Windows or Mac ignores the greyscale bit if the
video sample description contains a palette, regardless of bit depth.
This is undocumented behaviour, but I think we should do the same, and
it seems pretty logical after all, since one wouldn't really bother
putting a customized palette into a grayscale file anyway. See the
second 8-bit sample file below, which has the greyscale bit set, and
which contains a palette in the video sample description. In Windows or
Mac, it will be displayed with the palette in the sample description, in
spite of the greyscale bit being set.

Sample file 1 (1-bit QuickTime Animation):
https://drive.google.com/open?id=0B3_pEBoLs0faTThSek1EeXQ0ZHM

Sample file 2 (8-bit QuickTime Animation):
https://drive.google.com/open?id=0B3_pEBoLs0fad2s0V1YzUWo5aDA

Mats

---
 libavformat/qtpalette.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/qtpalette.c b/libavformat/qtpalette.c
index 6544a55..a78b6af 100644
--- a/libavformat/qtpalette.c
+++ b/libavformat/qtpalette.c
@@ -51,7 +51,9 @@ int ff_get_qtpalette(int codec_id, AVIOContext *pb, uint32_t *palette)
 int color_count, color_start, color_end;
 uint32_t a, r, g, b;
 
-if (greyscale) {
+/* Ignore the greyscale bit for 1-bit video and sample
+ * descriptions containing a color table. */
+if (greyscale && bit_depth > 1 && color_table_id) {
 int color_index, color_dec;
 /* compute the greyscale palette */
 color_count = 1 << bit_depth;
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] lavfi/af_sofalizer: remove exp2 and replace clz by ff_clz

[Ganesh Ajjanagadde]

On Fri, Jan 1, 2016 at 11:08 AM, Paul B Mahol  wrote:
> On 1/1/16, Ganesh Ajjanagadde  wrote:
>> On Tue, Dec 29, 2015 at 1:17 PM, Ganesh Ajjanagadde
>>  wrote:
>>> ff_clz is faster, and uses an intrinsic (at the moment on GCC). exp2 is
>>> a wasteful function for a simple integer exponentiation.
>>>
>>> Untested.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavfilter/af_sofalizer.c | 5 +++--
>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/libavfilter/af_sofalizer.c b/libavfilter/af_sofalizer.c
>>> index 6a24cbc..0bd1931 100644
>>> --- a/libavfilter/af_sofalizer.c
>>> +++ b/libavfilter/af_sofalizer.c
>>> @@ -30,6 +30,7 @@
>>>
>>>  #include "libavcodec/avfft.h"
>>>  #include "libavutil/float_dsp.h"
>>> +#include "libavutil/intmath.h"
>>>  #include "libavutil/opt.h"
>>>  #include "avfilter.h"
>>>  #include "internal.h"
>>> @@ -996,8 +997,8 @@ static int config_input(AVFilterLink *inlink)
>>>  }
>>>  /* buffer length is longest IR plus max. delay -> next power of 2
>>> (32 - count leading zeros gives required exponent)  */
>>> -s->buffer_length = exp2(32 - clz((uint32_t)n_max));
>>> -s->n_fft = exp2(32 - clz((uint32_t)(n_max +
>>> inlink->sample_rate)));
>>> +s->buffer_length = 1 << (32 - ff_clz(n_max));
>>> +s->n_fft = 1 << (32 - ff_clz(n_max + inlink->sample_rate));
>>>
>>>  if (s->type == FREQUENCY_DOMAIN) {
>>>  av_fft_end(s->fft[0]);
>>> --
>>> 2.6.4
>>>
>>
>> ping
>
> OK if you remove dead code, clz() function.

Done, pushed, thanks.

>
>> ___
>> 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] [RFC v4] libbavcodec: add a native decoder for the Daala video codec

[Michael Niedermayer]

On Fri, Jan 01, 2016 at 08:16:12PM +, Rostislav Pehlivanov wrote:
[...]

> +static av_cold int daala_decode_init(AVCodecContext *avctx)
> +{
> +int i, r_w, r_h, err = 0;
> +DaalaContext *s = avctx->priv_data;
> +
> +/* Inits a default QM, if the file isn't using the default it will be 
> reinit */
> +s->last_qm = 1;
> +daala_init_qmatrix(s->pvq.qmatrix, s->pvq.qmatrix_inv, s->last_qm);
> +
> +s->fmt = find_pix_fmt(avctx->pix_fmt);
> +if (!s->fmt) {
> +av_log(avctx, AV_LOG_ERROR, "Unsupported pixel format - %s!\n",
> +   av_get_pix_fmt_name(avctx->pix_fmt));

> +return AVERROR(ENOTSUP);

this would fail on beos acording to doc/errno.txt

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

It is what and why we do it that matters, not just one of them.


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

Re: [FFmpeg-devel] [RFC v4] libbavcodec: add a native decoder for the Daala video codec

[Rostislav Pehlivanov]

>this would fail on beos acording to doc/errno.txt
Fixed, replaced with EINVAL in my private tree (
https://github.com/atomnuker/FFmpeg) and in the patch attached with this
email. Not sure how appropriate EINVAL is but other decoders use it too.

Also as suggested moved the vector functions to daala_pvq and unmarked the
larger functions as inline.

On 1 January 2016 at 20:44, Michael Niedermayer 
wrote:

> On Fri, Jan 01, 2016 at 08:16:12PM +, Rostislav Pehlivanov wrote:
> [...]
>
> > +static av_cold int daala_decode_init(AVCodecContext *avctx)
> > +{
> > +int i, r_w, r_h, err = 0;
> > +DaalaContext *s = avctx->priv_data;
> > +
> > +/* Inits a default QM, if the file isn't using the default it will
> be reinit */
> > +s->last_qm = 1;
> > +daala_init_qmatrix(s->pvq.qmatrix, s->pvq.qmatrix_inv, s->last_qm);
> > +
> > +s->fmt = find_pix_fmt(avctx->pix_fmt);
> > +if (!s->fmt) {
> > +av_log(avctx, AV_LOG_ERROR, "Unsupported pixel format - %s!\n",
> > +   av_get_pix_fmt_name(avctx->pix_fmt));
>
> > +return AVERROR(ENOTSUP);
>
> this would fail on beos acording to doc/errno.txt
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> It is what and why we do it that matters, not just one of them.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
From 7c18bb441fe993e855d7dc931edc19c0ccc6dbaa Mon Sep 17 00:00:00 2001
From: Rostislav Pehlivanov 
Date: Fri, 1 Jan 2016 21:15:32 +
Subject: [PATCH] Fixed errors on BeOS, moved functions and unmarked some as
 inline

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/daala_entropy.h | 110 +---
 libavcodec/daala_pvq.h | 136 +++--
 libavcodec/daaladec.c  |  22 
 3 files changed, 132 insertions(+), 136 deletions(-)

diff --git a/libavcodec/daala_entropy.h b/libavcodec/daala_entropy.h
index 11912d8..ace404f 100644
--- a/libavcodec/daala_entropy.h
+++ b/libavcodec/daala_entropy.h
@@ -58,12 +58,6 @@
 #define DAALAENT_WSIZE  (int)sizeof(ent_win)*CHAR_BIT
 #define DAALAENT_CDF_ACCESS(n)  (_daalaent_cdf_tab[((n)*((n) - 1) >> 1) - 1])
 
-#define DAALAENT_PVQ_COUNT  2
-#define DAALAENT_PVQ_COUNT_EX   3
-#define DAALAENT_PVQ_K  0
-#define DAALAENT_PVQ_SUM_EX 1
-#define DAALAENT_PVQ_NOVAL  INT32_MIN
-
 enum DaalaCDFDecodeType {
 CDF_NORM = 0,
 CDF_Q15,
@@ -174,9 +168,9 @@ static inline uint8_t daalaent_decode_bool(DaalaEntropy *e, uint32_t p,
 }
 
 /* Decodes a symbol from a CDF table */
-static inline int daalaent_decode_cdf(DaalaEntropy *e, const ent_rng *cdf,
-  int cdf_size, uint32_t p_tot,
-  enum DaalaCDFDecodeType type)
+static int daalaent_decode_cdf(DaalaEntropy *e, const ent_rng *cdf,
+   int cdf_size, uint32_t p_tot,
+   enum DaalaCDFDecodeType type)
 {
 int d, lim, g, scale, ret = 0;
 ent_rng range = e->range;
@@ -360,104 +354,6 @@ static inline int daalaent_decode_laplace_pvq(DaalaEntropy *e, unsigned int exp_
 return (sym << shift) + lsb;
 }
 
-static inline void daalaent_decode_laplace_delta(DaalaEntropy *e, dctcoef *y,
- int n, int k, dctcoef *curr,
- const dctcoef *means)
-{
-int i, k0 = k, k_left = k;
-int prev = 0, sum_ex = 0, sum_c = 0, pos = 0;
-int coef = 256*means[DAALAENT_PVQ_COUNT]/(1 + means[DAALAENT_PVQ_COUNT_EX]);
-memset(y, 0, n*sizeof(dctcoef));
-coef = FFMAX(coef, 1);
-for (i = 0; i < k0; i++) {
-int count;
-if (!i) {
-int decay;
-int ex = coef*(n - prev)/k_left;
-if (ex > 65280)
-decay = 255;
-else
-decay = FFMIN(255, (int)((256*ex/(ex + 256) + (ex>>5)*ex/((n + 1)*(n - 1)*(n - 1);
-count = daalaent_decode_laplace(e, decay, n - 1);
-}
-else
-count = daalaent_decode_laplace_pvq(e, coef*(n - prev)/k_left, n - prev - 1);
-sum_ex += 256*(n - prev);
-sum_c += count*k_left;
-pos += count;
-av_assert0(pos < n);
-y[pos] += daalaent_cphase(e, !y[pos]);
-prev = pos;
-k_left--;
-if (!k_left)
-break;
-}
-if (k > 0) {
-curr[DAALAENT_PVQ_COUNT] = 256*sum_c;
-curr[DAALAENT_PVQ_COUNT_EX] = sum_ex;
-}
-else {
-curr[DAALAENT_PVQ_COUNT] = -1;
-curr[DAALAENT_PVQ_COUNT_EX] = 0;
-}
-curr[DAALAENT_PVQ_K] = 0;
-curr[DAALAENT_PVQ_SUM_EX] = 0;
-}
-
-/* Decodes quantized coefficients from  the bitsteam */
-static inline void 

Re: [FFmpeg-devel] [RFC v4] libbavcodec: add a native decoder for the Daala video codec

[Rostislav Pehlivanov]

Oh and by the way the title of the article is "Maintaining
Permissive-Licensed Files in a GPL-Licensed Project: Guidelines for
Developers". I read most of it and I'm under the impression that this is
about keeping BSD code inside LGPL code but still allowing the BSD code to
be used outside of the project as BSD. What we want to do here is taking
BSD code, modifying it and distributing it under the LGPL without actually
having to keep the code as BSD.
The page discusses quite a lot about keeping the copyright of the original
code which is something that we do. We wouldn't alter the original
copyright but only the conditions which the code is distributed with. And
since we keep all the original conditions and add new ones as per the LGPL,
we should be allowed to do this since the BSD license does not say anything
about it, as long as the copyright, not the license, remains intact.

On 2 January 2016 at 00:51, Carl Eugen Hoyos  wrote:

> Carl Eugen Hoyos  ag.or.at> writes:
>
> [...]
>
> We were apparently both wrong:
>
> https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
>
> So please place the original (two-clause BSD) license
> including the copyright statement under your (new) LGPL
> license.
>
> Sorry for the noise, Carl Eugen
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Michael Niedermayer]

On Tue, Dec 08, 2015 at 12:58:15PM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi  |  54 ++
>  libavfilter/Makefile  |   1 +
>  libavfilter/allfilters.c  |   1 +
>  libavfilter/vf_swaprect.c | 267 
> ++
>  4 files changed, 323 insertions(+)
>  create mode 100644 libavfilter/vf_swaprect.c
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 274532d..37c9c2b 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -10897,6 +10897,60 @@ Interpolate) pixel art scaling algorithm.
>  
>  Useful for enlarging pixel art images without reducing sharpness.
>  
> +@section swaprect
> +
> +Swap two rectangular objects in video.
> +
> +This filter accepts the following options:
> +
> +@table @option
> +@item w
> +Set object width.
> +
> +@item h
> +Set object height.
> +
> +@item x1
> +Set 1st rect x coordinate.
> +
> +@item y1
> +Set 1st rect y coordinate.
> +
> +@item x2
> +Set 2nd rect x coordinate.
> +
> +@item y2
> +Set 2nd rect y coordinate.
> +
> +All expressions are evaluated once for each frame.
> +@end table
> +
> +The all options are expressions containing the following constants:
> +
> +@table @option
> +@item w
> +@item h
> +The input width and height.
> +
> +@item a
> +same as @var{w} / @var{h}
> +
> +@item sar
> +input sample aspect ratio
> +
> +@item dar
> +input display aspect ratio, it is the same as (@var{w} / @var{h}) * @var{sar}
> +
> +@item n
> +The number of the input frame, starting from 0.
> +
> +@item t
> +The timestamp expressed in seconds. It's NAN if the input timestamp is 
> unknown.
> +
> +@item pos
> +the position in the file of the input frame, NAN if unknown
> +@end table
> +
>  @section swapuv
>  Swap U & V plane.
>  
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 8884d1d..4d1376b 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -233,6 +233,7 @@ OBJS-$(CONFIG_SSIM_FILTER)   += vf_ssim.o 
> dualinput.o framesync.
>  OBJS-$(CONFIG_STEREO3D_FILTER)   += vf_stereo3d.o
>  OBJS-$(CONFIG_SUBTITLES_FILTER)  += vf_subtitles.o
>  OBJS-$(CONFIG_SUPER2XSAI_FILTER) += vf_super2xsai.o
> +OBJS-$(CONFIG_SWAPRECT_FILTER)   += vf_swaprect.o
>  OBJS-$(CONFIG_SWAPUV_FILTER) += vf_swapuv.o
>  OBJS-$(CONFIG_TBLEND_FILTER) += vf_blend.o dualinput.o 
> framesync.o
>  OBJS-$(CONFIG_TELECINE_FILTER)   += vf_telecine.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 0eeef53..94a951b 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -254,6 +254,7 @@ void avfilter_register_all(void)
>  REGISTER_FILTER(STEREO3D,   stereo3d,   vf);
>  REGISTER_FILTER(SUBTITLES,  subtitles,  vf);
>  REGISTER_FILTER(SUPER2XSAI, super2xsai, vf);
> +REGISTER_FILTER(SWAPRECT,   swaprect,   vf);
>  REGISTER_FILTER(SWAPUV, swapuv, vf);
>  REGISTER_FILTER(TBLEND, tblend, vf);
>  REGISTER_FILTER(TELECINE,   telecine,   vf);
> diff --git a/libavfilter/vf_swaprect.c b/libavfilter/vf_swaprect.c
> new file mode 100644
> index 000..a5e1fab
> --- /dev/null
> +++ b/libavfilter/vf_swaprect.c
> @@ -0,0 +1,267 @@
> +/*
> + * Copyright (c) 2015 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 "libavutil/avstring.h"
> +#include "libavutil/eval.h"
> +#include "libavutil/imgutils.h"
> +#include "libavutil/opt.h"
> +#include "libavutil/pixdesc.h"
> +
> +#include "avfilter.h"
> +#include "formats.h"
> +#include "internal.h"
> +#include "video.h"
> +
> +typedef struct SwapRectContext {
> +const AVClass *class;
> +char *w, *h;
> +char *x1, *y1;
> +char *x2, *y2;
> +
> +int nb_planes;
> +int pixsteps[4];
> +
> +const AVPixFmtDescriptor *desc;
> +uint8_t *temp;
> +} SwapRectContext;
> +
> +#define OFFSET(x) offsetof(SwapRectContext, x)
> +#define FLAGS AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM
> +static const AVOption swaprect_options[] = {
> +{ "w",  "set rect width", 

[FFmpeg-devel] [PATCH 2/2] avfilter: add showspectrumpic filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi   | 106 +++
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/avf_showspectrum.c | 233 ++---
 4 files changed, 326 insertions(+), 15 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 8aa3b47..224099d 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14704,6 +14704,112 @@ ffplay -f lavfi 'amovie=input.mp3, asplit [a][out1];
 @end example
 @end itemize
 
+@section showspectrumpic
+
+Convert input audio to a single video frame, representing the audio frequency
+spectrum.
+
+The filter accepts the following options:
+
+@table @option
+@item size, s
+Specify the video size for the output. For the syntax of this option, check the
+@ref{video size syntax,,"Video size" section in the ffmpeg-utils 
manual,ffmpeg-utils}.
+Default value is @code{640x512}.
+
+@item mode
+Specify display mode.
+
+It accepts the following values:
+@table @samp
+@item combined
+all channels are displayed in the same row
+@item separate
+all channels are displayed in separate rows
+@end table
+Default value is @samp{combined}.
+
+@item color
+Specify display color mode.
+
+It accepts the following values:
+@table @samp
+@item channel
+each channel is displayed in a separate color
+@item intensity
+each channel is displayed using the same color scheme
+@item rainbow
+each channel is displayed using the rainbow color scheme
+@item moreland
+each channel is displayed using the moreland color scheme
+@item nebulae
+each channel is displayed using the nebulae color scheme
+@item fire
+each channel is displayed using the fire color scheme
+@end table
+Default value is @samp{channel}.
+
+@item scale
+Specify scale used for calculating intensity color values.
+
+It accepts the following values:
+@table @samp
+@item lin
+linear
+@item sqrt
+square root, default
+@item cbrt
+cubic root
+@item log
+logarithmic
+@end table
+Default value is @samp{sqrt}.
+
+@item saturation
+Set saturation modifier for displayed colors. Negative values provide
+alternative color scheme. @code{0} is no saturation at all.
+Saturation must be in [-10.0, 10.0] range.
+Default value is @code{1}.
+
+@item win_func
+Set window function.
+
+It accepts the following values:
+@table @samp
+@item rect
+@item bartlett
+@item hann
+@item hanning
+@item hamming
+@item blackman
+@item welch
+@item flattop
+@item bharris
+@item bnuttall
+@item bhann
+@item sine
+@item nuttall
+@item lanczos
+@item gauss
+@end table
+Default value is @code{hann}.
+
+@item orientation
+Set orientation of time vs frequency axis. Can be @code{vertical} or
+@code{horizontal}. Default is @code{vertical}.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Extract an audio spectrogram of a whole audio track
+in a 1024x1024 picture using @command{ffmpeg}:
+@example
+ffmpeg -i audio.flac -lavfi showspectrumpic=s=1024x1024 spectrogram.png
+@end example
+@end itemize
+
 @section showvolume
 
 Convert input audio volume to a video output.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e334016..689da73 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -286,6 +286,7 @@ OBJS-$(CONFIG_CONCAT_FILTER) += avf_concat.o
 OBJS-$(CONFIG_SHOWCQT_FILTER)+= avf_showcqt.o lswsutils.o 
lavfutils.o
 OBJS-$(CONFIG_SHOWFREQS_FILTER)  += avf_showfreqs.o window_func.o
 OBJS-$(CONFIG_SHOWSPECTRUM_FILTER)   += avf_showspectrum.o 
window_func.o
+OBJS-$(CONFIG_SHOWSPECTRUMPIC_FILTER)+= avf_showspectrum.o 
window_func.o
 OBJS-$(CONFIG_SHOWVOLUME_FILTER) += avf_showvolume.o
 OBJS-$(CONFIG_SHOWWAVES_FILTER)  += avf_showwaves.o
 OBJS-$(CONFIG_SHOWWAVESPIC_FILTER)   += avf_showwaves.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index a039a39..2267e88 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -306,6 +306,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(SHOWCQT,showcqt,avf);
 REGISTER_FILTER(SHOWFREQS,  showfreqs,  avf);
 REGISTER_FILTER(SHOWSPECTRUM,   showspectrum,   avf);
+REGISTER_FILTER(SHOWSPECTRUMPIC, showspectrumpic, avf);
 REGISTER_FILTER(SHOWVOLUME, showvolume, avf);
 REGISTER_FILTER(SHOWWAVES,  showwaves,  avf);
 REGISTER_FILTER(SHOWWAVESPIC,   showwavespic,   avf);
diff --git a/libavfilter/avf_showspectrum.c b/libavfilter/avf_showspectrum.c
index 0fa1be1..2992c2f 100644
--- a/libavfilter/avf_showspectrum.c
+++ b/libavfilter/avf_showspectrum.c
@@ -63,6 +63,7 @@ typedef struct {
 int rdft_bits;  ///< number of bits (RDFT window size = 
1<

Re: [FFmpeg-devel] [PATCH] avcodec/put_bits: Always check buffer end before writing

[Paul B Mahol]

On 1/1/16, Michael Niedermayer  wrote:
> From: Michael Niedermayer 
>
> This causes a overall slowdown of 0.1 % (tested with mpeg4 single thread
> encoding of matrixbench at QP=3)
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/put_bits.h |   16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/put_bits.h b/libavcodec/put_bits.h
> index 5b1bc8b..69a3049 100644
> --- a/libavcodec/put_bits.h
> +++ b/libavcodec/put_bits.h
> @@ -163,9 +163,11 @@ static inline void put_bits(PutBitContext *s, int n,
> unsigned int value)
>  #ifdef BITSTREAM_WRITER_LE
>  bit_buf |= value << (32 - bit_left);
>  if (n >= bit_left) {
> -av_assert2(s->buf_ptr+3buf_end);
> -AV_WL32(s->buf_ptr, bit_buf);
> -s->buf_ptr += 4;
> +if (3 < s->buf_end - s->buf_ptr) {
> +AV_WL32(s->buf_ptr, bit_buf);
> +s->buf_ptr += 4;
> +} else
> +av_assert0(0);
>  bit_buf = value >> bit_left;
>  bit_left   += 32;
>  }
> @@ -177,9 +179,11 @@ static inline void put_bits(PutBitContext *s, int n,
> unsigned int value)
>  } else {
>  bit_buf   <<= bit_left;
>  bit_buf|= value >> (n - bit_left);
> -av_assert2(s->buf_ptr+3buf_end);
> -AV_WB32(s->buf_ptr, bit_buf);
> -s->buf_ptr += 4;
> +if (3 < s->buf_end - s->buf_ptr) {
> +AV_WB32(s->buf_ptr, bit_buf);
> +s->buf_ptr += 4;
> +} else
> +av_assert0(0);
>  bit_left   += 32 - n;
>  bit_buf = value;
>  }

If this can happen, using assert0 is bad idea.
If this should not happen add if under assert2.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avfilter/avf_showspectrum: store win_size in private context and calculate it only once

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavfilter/avf_showspectrum.c | 39 +--
 1 file changed, 17 insertions(+), 22 deletions(-)

diff --git a/libavfilter/avf_showspectrum.c b/libavfilter/avf_showspectrum.c
index 5380994..0fa1be1 100644
--- a/libavfilter/avf_showspectrum.c
+++ b/libavfilter/avf_showspectrum.c
@@ -64,6 +64,7 @@ typedef struct {
 FFTSample **rdft_data;  ///< bins holder for each (displayed) channels
 float *window_func_lut; ///< Window function LUT
 int win_func;
+int win_size;
 double win_scale;
 float overlap;
 int skip_samples;
@@ -225,7 +226,7 @@ static int config_output(AVFilterLink *outlink)
 AVFilterContext *ctx = outlink->src;
 AVFilterLink *inlink = ctx->inputs[0];
 ShowSpectrumContext *s = ctx->priv;
-int i, rdft_bits, win_size, h, w;
+int i, rdft_bits, h, w;
 float overlap;
 
 outlink->w = s->w;
@@ -243,7 +244,7 @@ static int config_output(AVFilterLink *outlink)
 /* RDFT window size (precision) according to the requested output 
frame width */
 for (rdft_bits = 1; 1 << rdft_bits < 2 * w; rdft_bits++);
 }
-win_size = 1 << rdft_bits;
+s->win_size = 1 << rdft_bits;
 
 /* (re-)configuration if the video output changed (or first init) */
 if (rdft_bits != s->rdft_bits) {
@@ -270,27 +271,27 @@ static int config_output(AVFilterLink *outlink)
 if (!s->rdft_data)
 return AVERROR(ENOMEM);
 for (i = 0; i < s->nb_display_channels; i++) {
-s->rdft_data[i] = av_calloc(win_size, sizeof(**s->rdft_data));
+s->rdft_data[i] = av_calloc(s->win_size, sizeof(**s->rdft_data));
 if (!s->rdft_data[i])
 return AVERROR(ENOMEM);
 }
 
 /* pre-calc windowing function */
 s->window_func_lut =
-av_realloc_f(s->window_func_lut, win_size,
+av_realloc_f(s->window_func_lut, s->win_size,
  sizeof(*s->window_func_lut));
 if (!s->window_func_lut)
 return AVERROR(ENOMEM);
-ff_generate_window_func(s->window_func_lut, win_size, s->win_func, 
);
+ff_generate_window_func(s->window_func_lut, s->win_size, s->win_func, 
);
 if (s->overlap == 1)
 s->overlap = overlap;
-s->skip_samples = (1. - s->overlap) * win_size;
+s->skip_samples = (1. - s->overlap) * s->win_size;
 if (s->skip_samples < 1) {
 av_log(ctx, AV_LOG_ERROR, "overlap %f too big\n", s->overlap);
 return AVERROR(EINVAL);
 }
 
-for (s->win_scale = 0, i = 0; i < win_size; i++) {
+for (s->win_scale = 0, i = 0; i < s->win_size; i++) {
 s->win_scale += s->window_func_lut[i] * s->window_func_lut[i];
 }
 s->win_scale = 1. / (sqrt(s->win_scale) * 32768.);
@@ -313,7 +314,7 @@ static int config_output(AVFilterLink *outlink)
 (s->orientation == HORIZONTAL && s->xpos >= outlink->h))
 s->xpos = 0;
 
-outlink->frame_rate = av_make_q(inlink->sample_rate, win_size * 
(1.-s->overlap));
+outlink->frame_rate = av_make_q(inlink->sample_rate, s->win_size * 
(1.-s->overlap));
 if (s->orientation == VERTICAL && s->sliding == FULLFRAME)
 outlink->frame_rate.den *= outlink->w;
 if (s->orientation == HORIZONTAL && s->sliding == FULLFRAME)
@@ -330,10 +331,10 @@ static int config_output(AVFilterLink *outlink)
 }
 
 av_log(ctx, AV_LOG_VERBOSE, "s:%dx%d RDFT window size:%d\n",
-   s->w, s->h, win_size);
+   s->w, s->h, s->win_size);
 
 av_audio_fifo_free(s->fifo);
-s->fifo = av_audio_fifo_alloc(inlink->format, inlink->channels, win_size);
+s->fifo = av_audio_fifo_alloc(inlink->format, inlink->channels, 
s->win_size);
 if (!s->fifo)
 return AVERROR(ENOMEM);
 return 0;
@@ -376,23 +377,18 @@ static int plot_spectrum_column(AVFilterLink *inlink, 
AVFrame *insamples)
 AVFilterLink *outlink = ctx->outputs[0];
 ShowSpectrumContext *s = ctx->priv;
 AVFrame *outpicref = s->outpicref;
-
-/* nb_freq contains the power of two superior or equal to the output image
- * height (or half the RDFT window size) */
-const int nb_freq = 1 << (s->rdft_bits - 1);
-const int win_size = nb_freq << 1;
 const double w = s->win_scale;
 int h = s->orientation == VERTICAL ? s->channel_height : s->channel_width;
 
 int ch, plane, n, x, y;
 
-av_assert0(insamples->nb_samples == win_size);
+av_assert0(insamples->nb_samples == s->win_size);
 
 /* fill RDFT input with the number of samples available */
 for (ch = 0; ch < s->nb_display_channels; ch++) {
 const int16_t *p = (int16_t *)insamples->extended_data[ch];
 
-for (n = 0; n < win_size; n++)
+for (n = 0; n < s->win_size; n++)
 s->rdft_data[ch][n] = p[n] * s->window_func_lut[n];
 }
 
@@ -610,21 +606,20 @@ static int 

Re: [FFmpeg-devel] [PATCH] libi264: Add Hardware Accelerated H.264 Encoder based on libVA

[Hendrik Leppkes]

On Thu, Dec 31, 2015 at 6:35 PM, ha...@mayartech.com
 wrote:
> From: Bryan Christ 
>

I see you are not the author of this patch. Will you be maintaining it
in the future?
Such huge patches and complicated features do need a maintainer, or
it'll likely result in breaking sooner or later.

> This commit adds a hardware accelerated H.264 encoder which utilizes
> libVA (open source implementation of VA-API). Information about libva
> is available at: https://en.wikipedia.org/wiki/Video_Acceleration_API
> This encoder is only availbale on linux and supported hardware which
> can be viewed at:
> https://en.wikipedia.org/wiki/Video_Acceleration_API#Supported_hardware_and_drivers
>
> The short name for encoder is "libi264". The encoder must be enablde at
> configure time using the --enable-libi264 switch. By default it is
> turned off.
> ---
>  Changelog   |1 +
>  MAINTAINERS |1 +
>  configure   |8 +-
>  doc/general.texi|   11 +
>  libavcodec/Makefile |1 +
>  libavcodec/allcodecs.c  |1 +
>  libavcodec/libi264.c| 1476 
> +++
>  libavcodec/libi264.h|  107 +++
>  libavcodec/libi264_param_set.c  |  425 ++
>  libavcodec/libi264_param_set.h  |   81 ++
>  libavcodec/libi264_va_display.c |  104 +++
>  libavcodec/libi264_va_display.h |   77 ++
>  libavcodec/libi264_va_display_drm.c |   96 +++
>  libavcodec/libi264_va_display_x11.c |  171 
>  libavcodec/version.h|2 +-
>  15 files changed, 2560 insertions(+), 2 deletions(-)
>  create mode 100644 libavcodec/libi264.c
>  create mode 100644 libavcodec/libi264.h
>  create mode 100644 libavcodec/libi264_param_set.c
>  create mode 100644 libavcodec/libi264_param_set.h
>  create mode 100644 libavcodec/libi264_va_display.c
>  create mode 100644 libavcodec/libi264_va_display.h
>  create mode 100644 libavcodec/libi264_va_display_drm.c
>  create mode 100644 libavcodec/libi264_va_display_x11.c
>
> diff --git a/Changelog b/Changelog
> index d9c2ea8..99acb56 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -49,6 +49,7 @@ version :
>  - VAAPI VP9 hwaccel
>  - audio high-order multiband parametric equalizer
>  - automatic bitstream filtering
> +- H.264 hwaccelerated encoding through libVA
>
>
>  version 2.8:
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9add13d..e37cb6f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -203,6 +203,7 @@ Codecs:
>libcelt_dec.c Nicolas George
>libdirac* David Conrad
>libgsm.c  Michel Bardiaux
> +  libi264*  Bryan Christ
>libkvazaar.c  Arttu Ylä-Outinen
>libopenjpeg.c Jaikrishnan Menon
>libopenjpegenc.c  Michael Bradshaw
> diff --git a/configure b/configure
> index da74ccd..335c172 100755
> --- a/configure
> +++ b/configure
> @@ -265,6 +265,7 @@ External library support:
>--enable-libwavpack  enable wavpack encoding via libwavpack [no]
>--enable-libwebp enable WebP encoding via libwebp [no]
>--enable-libx264 enable H.264 encoding via x264 [no]
> +  --enable-libi264 enable H.264 encoding via Intel's libva [no]

Please don't invent arbitrary names. There is no "libi264", just call
it what it is, vaapi or libva, whichever you prefer.

>--enable-libx265 enable HEVC encoding via x265 [no]
>--enable-libxavs enable AVS encoding via xavs [no]
>--enable-libxcb  enable X11 grabbing using XCB [autodetect]
> @@ -1484,6 +1485,9 @@ EXTERNAL_LIBRARY_LIST="
>  libtwolame
>  libutvideo
>  libv4l2
> +libva
> +libva-drm
> +libva-x11
>  libvidstab
>  libvo_aacenc
>  libvo_amrwbenc
> @@ -1491,6 +1495,7 @@ EXTERNAL_LIBRARY_LIST="
>  libvpx
>  libwavpack
>  libwebp
> +libX11
>  libx264
>  libx265
>  libxavs
> @@ -2658,7 +2663,7 @@ libwebp_anim_encoder_deps="libwebp"
>  libx262_encoder_deps="libx262"
>  libx264_encoder_deps="libx264"
>  libx264rgb_encoder_deps="libx264"
> -libx264rgb_encoder_select="libx264_encoder"

Clearly this removal is not intended?

> +libi264_encoder_deps="libi264"
>  libx265_encoder_deps="libx265"
>  libxavs_encoder_deps="libxavs"
>  libxvid_encoder_deps="libxvid"
> @@ -5528,6 +5533,7 @@ enabled libx264   && { use_pkg_config x264 
> "stdint.h x264.h" x264_encode
> die "ERROR: libx264 must be installed and 
> version must be >= 0.118."; } &&
>   { check_cpp_condition x264.h "X264_MPEG2" &&
> enable libx262; }
> +enabled libi264   && require libva va/va.h vaInitialize -lva -lX11 
> -lva-x11 -lva-drm
>  enabled libx265 

Re: [FFmpeg-devel] [PATCH 2/2] avfilter: add showspectrumpic filter

[Paul B Mahol]

On 1/1/16, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi   | 106 +++
>  libavfilter/Makefile   |   1 +
>  libavfilter/allfilters.c   |   1 +
>  libavfilter/avf_showspectrum.c | 233
> ++---
>  4 files changed, 326 insertions(+), 15 deletions(-)
>

[...]

> +if (samples / sz < s->win_size) {
> +spf = lrint(ceil(samples / (float)sz)) % s->win_size;
> +spb = samples / sz;
> +} else {
> +spf = samples % s->win_size;
> +spb = samples / sz;

Fixed those calculations locally.

> +}
> +
> +if (!spf)
> +spf = s->win_size;
> +s->sliding = FULLFRAME;
> +fin = ff_get_audio_buffer(inlink, s->win_size);
> +if (!fin)

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

Re: [FFmpeg-devel] [PATCH][WIP] lavc/cbrt_tablegen: speed up tablegen

[Ronald S. Bultje]

Hi,

On Thu, Dec 31, 2015 at 9:55 PM, Ganesh Ajjanagadde 
wrote:

> This exploits an approach based on the sieve of Eratosthenes, a popular
> method for generating prime numbers.
>
> Tables are identical to previous ones.
>
> Tested with FATE. Does not work yet with --enable-hardcoded-tables due
> to the union and lack of proper WRITE_ARRAY for it. Want to get feedback
> on this; if we always dynamically init it this won't need addressing.


I think you're getting ahead of yourself here. Assume for now that the
hardcoded-tables feature will continue to exist for a while.

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

[FFmpeg-devel] [PATCH] avcodec/put_bits: Always check buffer end before writing

[Michael Niedermayer]

From: Michael Niedermayer 

This causes a overall slowdown of 0.1 % (tested with mpeg4 single thread 
encoding of matrixbench at QP=3)

Signed-off-by: Michael Niedermayer 
---
 libavcodec/put_bits.h |   20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/libavcodec/put_bits.h b/libavcodec/put_bits.h
index 5b1bc8b..0db8a03 100644
--- a/libavcodec/put_bits.h
+++ b/libavcodec/put_bits.h
@@ -163,9 +163,13 @@ static inline void put_bits(PutBitContext *s, int n, 
unsigned int value)
 #ifdef BITSTREAM_WRITER_LE
 bit_buf |= value << (32 - bit_left);
 if (n >= bit_left) {
-av_assert2(s->buf_ptr+3buf_end);
-AV_WL32(s->buf_ptr, bit_buf);
-s->buf_ptr += 4;
+if (3 < s->buf_end - s->buf_ptr) {
+AV_WL32(s->buf_ptr, bit_buf);
+s->buf_ptr += 4;
+} else {
+av_log(NULL, AV_LOG_ERROR, "Internal error, put_bits buffer too 
small\n");
+av_assert2(0);
+}
 bit_buf = value >> bit_left;
 bit_left   += 32;
 }
@@ -177,9 +181,13 @@ static inline void put_bits(PutBitContext *s, int n, 
unsigned int value)
 } else {
 bit_buf   <<= bit_left;
 bit_buf|= value >> (n - bit_left);
-av_assert2(s->buf_ptr+3buf_end);
-AV_WB32(s->buf_ptr, bit_buf);
-s->buf_ptr += 4;
+if (3 < s->buf_end - s->buf_ptr) {
+AV_WB32(s->buf_ptr, bit_buf);
+s->buf_ptr += 4;
+} else {
+av_log(NULL, AV_LOG_ERROR, "Internal error, put_bits buffer too 
small\n");
+av_assert2(0);
+}
 bit_left   += 32 - n;
 bit_buf = value;
 }
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH][WIP] lavc/cbrt_tablegen: speed up tablegen

[Ronald S. Bultje]

Hi,

On Fri, Jan 1, 2016 at 10:40 AM, Ganesh Ajjanagadde 
wrote:

> On Fri, Jan 1, 2016 at 6:54 AM, Ronald S. Bultje 
> wrote:
> > Hi,
> >
> > On Thu, Dec 31, 2015 at 9:55 PM, Ganesh Ajjanagadde <
> gajjanaga...@gmail.com>
> > wrote:
> >>
> >> This exploits an approach based on the sieve of Eratosthenes, a popular
> >> method for generating prime numbers.
> >>
> >> Tables are identical to previous ones.
> >>
> >> Tested with FATE. Does not work yet with --enable-hardcoded-tables due
> >> to the union and lack of proper WRITE_ARRAY for it. Want to get feedback
> >> on this; if we always dynamically init it this won't need addressing.
> >
> >
> > I think you're getting ahead of yourself here. Assume for now that the
> > hardcoded-tables feature will continue to exist for a while.
>
> I was referring to just this one, not to the question in general.


I was also referring to this case specifically. Assume, for now, that
hardcoded tables for this specific case, will continue to exist.

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

Re: [FFmpeg-devel] [PATCH][WIP] lavc/cbrt_tablegen: speed up tablegen

[Ronald S. Bultje]

Hi,

On Fri, Jan 1, 2016 at 10:46 AM, Ganesh Ajjanagadde 
wrote:

> On Fri, Jan 1, 2016 at 7:43 AM, Ronald S. Bultje 
> wrote:
> > Hi,
> >
> > On Fri, Jan 1, 2016 at 10:40 AM, Ganesh Ajjanagadde <
> gajjanaga...@gmail.com>
> > wrote:
> >>
> >> On Fri, Jan 1, 2016 at 6:54 AM, Ronald S. Bultje 
> >> wrote:
> >> > Hi,
> >> >
> >> > On Thu, Dec 31, 2015 at 9:55 PM, Ganesh Ajjanagadde
> >> > 
> >> > wrote:
> >> >>
> >> >> This exploits an approach based on the sieve of Eratosthenes, a
> popular
> >> >> method for generating prime numbers.
> >> >>
> >> >> Tables are identical to previous ones.
> >> >>
> >> >> Tested with FATE. Does not work yet with --enable-hardcoded-tables
> due
> >> >> to the union and lack of proper WRITE_ARRAY for it. Want to get
> >> >> feedback
> >> >> on this; if we always dynamically init it this won't need addressing.
> >> >
> >> >
> >> > I think you're getting ahead of yourself here. Assume for now that the
> >> > hardcoded-tables feature will continue to exist for a while.
> >>
> >> I was referring to just this one, not to the question in general.
> >
> >
> > I was also referring to this case specifically. Assume, for now, that
> > hardcoded tables for this specific case, will continue to exist.
>
> Then defend it technically please. For instance, you have not
> addressed the fundamental amortization of table init cost.


No. It is the status quo, and remains that until it changes. That's why
it's called the status quo. I've encouraged you several times to have this
debate in the open, but you keep jumping away when that comes up.

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

Re: [FFmpeg-devel] [PATCH] lavf/qtpalette: Ignore greyscale bit in 1-bit video

[Carl Eugen Hoyos]

Michael Niedermayer  niedermayer.cc> writes:

> On Thu, Dec 31, 2015 at 03:59:53PM +, Carl Eugen Hoyos wrote:
> > Mats Peterson  ffmpeg.org> writes:
> > 
> > > And this patch doesn't affect the current state of 
> > > the qtrle decoder
> > 
> > Then there is no need for this patch to be 
> > committed yet.
> 
> if the patch is fixing incorrect code then it should 
> be commited if it doesnt then it should not

I doubt that code that has no effect can fix 
incorrect code.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH][WIP] lavc/cbrt_tablegen: speed up tablegen

[Ganesh Ajjanagadde]

On Fri, Jan 1, 2016 at 7:56 AM, Ronald S. Bultje  wrote:
> Hi,
>
> On Fri, Jan 1, 2016 at 10:52 AM, Ganesh Ajjanagadde 
> wrote:
>>
>> On Fri, Jan 1, 2016 at 7:51 AM, Ronald S. Bultje 
>> wrote:
>> > Hi,
>> >
>> > On Fri, Jan 1, 2016 at 10:46 AM, Ganesh Ajjanagadde
>> > 
>> > wrote:
>> >>
>> >> On Fri, Jan 1, 2016 at 7:43 AM, Ronald S. Bultje 
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > On Fri, Jan 1, 2016 at 10:40 AM, Ganesh Ajjanagadde
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> On Fri, Jan 1, 2016 at 6:54 AM, Ronald S. Bultje
>> >> >> 
>> >> >> wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > On Thu, Dec 31, 2015 at 9:55 PM, Ganesh Ajjanagadde
>> >> >> > 
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> This exploits an approach based on the sieve of Eratosthenes, a
>> >> >> >> popular
>> >> >> >> method for generating prime numbers.
>> >> >> >>
>> >> >> >> Tables are identical to previous ones.
>> >> >> >>
>> >> >> >> Tested with FATE. Does not work yet with
>> >> >> >> --enable-hardcoded-tables
>> >> >> >> due
>> >> >> >> to the union and lack of proper WRITE_ARRAY for it. Want to get
>> >> >> >> feedback
>> >> >> >> on this; if we always dynamically init it this won't need
>> >> >> >> addressing.
>> >> >> >
>> >> >> >
>> >> >> > I think you're getting ahead of yourself here. Assume for now that
>> >> >> > the
>> >> >> > hardcoded-tables feature will continue to exist for a while.
>> >> >>
>> >> >> I was referring to just this one, not to the question in general.
>> >> >
>> >> >
>> >> > I was also referring to this case specifically. Assume, for now, that
>> >> > hardcoded tables for this specific case, will continue to exist.
>> >>
>> >> Then defend it technically please. For instance, you have not
>> >> addressed the fundamental amortization of table init cost.
>> >
>> >
>> > No. It is the status quo, and remains that until it changes. That's why
>> > it's
>> > called the status quo. I've encouraged you several times to have this
>> > debate
>> > in the open, but you keep jumping away when that comes up.
>>
>> What is this if not "open"? Where does this "jumping away" come from?
>
>
> Open is an identifiable thread where people interested in that subject can
> participate. "[PATCH] cbrt: improve" is barely anything like that. Call it
> "[RFC] Disable compile-time tablegen if total cyclecount < $threshold".

You did not address the second question and your baseless attack. You
also never did "several times" define what you mean by "open" until
just now.

All that being said, thread created, with a modified subject line as
your proposed subject line is more general than the specific question
I am raising.

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

Re: [FFmpeg-devel] [PATCH][WIP] lavc/cbrt_tablegen: speed up tablegen

[Ganesh Ajjanagadde]

On Fri, Jan 1, 2016 at 6:54 AM, Ronald S. Bultje  wrote:
> Hi,
>
> On Thu, Dec 31, 2015 at 9:55 PM, Ganesh Ajjanagadde 
> wrote:
>>
>> This exploits an approach based on the sieve of Eratosthenes, a popular
>> method for generating prime numbers.
>>
>> Tables are identical to previous ones.
>>
>> Tested with FATE. Does not work yet with --enable-hardcoded-tables due
>> to the union and lack of proper WRITE_ARRAY for it. Want to get feedback
>> on this; if we always dynamically init it this won't need addressing.
>
>
> I think you're getting ahead of yourself here. Assume for now that the
> hardcoded-tables feature will continue to exist for a while.

I was referring to just this one, not to the question in general.

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

Re: [FFmpeg-devel] [PATCH] Revert "Merge commit '9f1eccb97bf8894cb18b14f642500686505ef186'"

[Hendrik Leppkes]

On Fri, Jan 1, 2016 at 4:37 PM, Michael Niedermayer  wrote:
> From: Michael Niedermayer 
>
> This unbreaks encoding
> Example:
> ffmpeg -i matrixbench_mpeg2.mpg new.avi
>
> -rw-r- 1 michael michael 226035354 Jan  1 16:27 new.avi
> -rw-r- 1 michael michael  10016802 Jan  1 16:28 ref.avi
>
> Also av_get_audio_frame_duration() itself uses frame_size
>
> This reverts commit 29e6606e9b42aa811be995e2fcdea4806911bc9f, reversing
> changes made to 53448461a7720afab0d1f1234af79573fd2e020d.
> ---
>  libavformat/riffenc.c |5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
> index 250cf41..ceb27f2 100644
> --- a/libavformat/riffenc.c
> +++ b/libavformat/riffenc.c
> @@ -242,7 +242,12 @@ void ff_parse_specific_params(AVStream *st, int *au_rate,
>  int gcd;
>  int audio_frame_size;
>
> +/* We use the known constant frame size for the codec if known, otherwise
> + * fall back on using AVCodecContext.frame_size, which is not as reliable
> + * for indicating packet duration. */
>  audio_frame_size = av_get_audio_frame_duration(codec, 0);
> +if (!audio_frame_size)
> +audio_frame_size = codec->frame_size;
>
>  *au_ssize = codec->block_align;
>  if (audio_frame_size && codec->sample_rate) {
> --

Using the AVCodecContext from a muxer is deprecated, and sooner or
later this code will have to be "fixed" again to no longer rely on
this parameter when calling code no longer provides this parameter. So
better would be to figure out why it needs special handling here.
The comment above it even says that its not reliable.

Feel free to commit in the meantime, but this is going to break again
in the future if not fixed properly.

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

Re: [FFmpeg-devel] [PATCH] libi264: Add Hardware Accelerated H.264 Encoder based on libVA

[Carl Eugen Hoyos]

hamza  mayartech.com  mayartech.com> writes:

> +  --enable-libi264 enable H.264 encoding via Intel's libva [no]

What is the difference between (your) libva 
and the (existing) libvaapi?
If they are the same external library, please 
do not add a new configure switch.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH][WIP] lavc/cbrt_tablegen: speed up tablegen

[Ronald S. Bultje]

Hi,

On Fri, Jan 1, 2016 at 10:52 AM, Ganesh Ajjanagadde 
wrote:

> On Fri, Jan 1, 2016 at 7:51 AM, Ronald S. Bultje 
> wrote:
> > Hi,
> >
> > On Fri, Jan 1, 2016 at 10:46 AM, Ganesh Ajjanagadde <
> gajjanaga...@gmail.com>
> > wrote:
> >>
> >> On Fri, Jan 1, 2016 at 7:43 AM, Ronald S. Bultje 
> >> wrote:
> >> > Hi,
> >> >
> >> > On Fri, Jan 1, 2016 at 10:40 AM, Ganesh Ajjanagadde
> >> > 
> >> > wrote:
> >> >>
> >> >> On Fri, Jan 1, 2016 at 6:54 AM, Ronald S. Bultje  >
> >> >> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > On Thu, Dec 31, 2015 at 9:55 PM, Ganesh Ajjanagadde
> >> >> > 
> >> >> > wrote:
> >> >> >>
> >> >> >> This exploits an approach based on the sieve of Eratosthenes, a
> >> >> >> popular
> >> >> >> method for generating prime numbers.
> >> >> >>
> >> >> >> Tables are identical to previous ones.
> >> >> >>
> >> >> >> Tested with FATE. Does not work yet with --enable-hardcoded-tables
> >> >> >> due
> >> >> >> to the union and lack of proper WRITE_ARRAY for it. Want to get
> >> >> >> feedback
> >> >> >> on this; if we always dynamically init it this won't need
> >> >> >> addressing.
> >> >> >
> >> >> >
> >> >> > I think you're getting ahead of yourself here. Assume for now that
> >> >> > the
> >> >> > hardcoded-tables feature will continue to exist for a while.
> >> >>
> >> >> I was referring to just this one, not to the question in general.
> >> >
> >> >
> >> > I was also referring to this case specifically. Assume, for now, that
> >> > hardcoded tables for this specific case, will continue to exist.
> >>
> >> Then defend it technically please. For instance, you have not
> >> addressed the fundamental amortization of table init cost.
> >
> >
> > No. It is the status quo, and remains that until it changes. That's why
> it's
> > called the status quo. I've encouraged you several times to have this
> debate
> > in the open, but you keep jumping away when that comes up.
>
> What is this if not "open"? Where does this "jumping away" come from?


Open is an identifiable thread where people interested in that subject can
participate. "[PATCH] cbrt: improve" is barely anything like that. Call it
"[RFC] Disable compile-time tablegen if total cyclecount < $threshold".

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

[FFmpeg-devel] [RFC] Disable compile-time tablegen for cbrt if total cycle count < 200000

[Ganesh Ajjanagadde]

Hi all,

Motivated by a remark by Ronald:
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186200.html,
this is a request for comment on disabling compile time tablegen for
cbrt if the total cycle count < 20. Note that cbrt tables are only
used in aacdec.

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

Re: [FFmpeg-devel] [PATCH] avcodec/put_bits: Always check buffer end before writing

[Michael Niedermayer]

On Fri, Jan 01, 2016 at 08:59:23AM +, Paul B Mahol wrote:
> On 1/1/16, Michael Niedermayer  wrote:
> > From: Michael Niedermayer 
> >
> > This causes a overall slowdown of 0.1 % (tested with mpeg4 single thread
> > encoding of matrixbench at QP=3)
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/put_bits.h |   16 ++--
> >  1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavcodec/put_bits.h b/libavcodec/put_bits.h
> > index 5b1bc8b..69a3049 100644
> > --- a/libavcodec/put_bits.h
> > +++ b/libavcodec/put_bits.h
> > @@ -163,9 +163,11 @@ static inline void put_bits(PutBitContext *s, int n,
> > unsigned int value)
> >  #ifdef BITSTREAM_WRITER_LE
> >  bit_buf |= value << (32 - bit_left);
> >  if (n >= bit_left) {
> > -av_assert2(s->buf_ptr+3buf_end);
> > -AV_WL32(s->buf_ptr, bit_buf);
> > -s->buf_ptr += 4;
> > +if (3 < s->buf_end - s->buf_ptr) {
> > +AV_WL32(s->buf_ptr, bit_buf);
> > +s->buf_ptr += 4;
> > +} else
> > +av_assert0(0);
> >  bit_buf = value >> bit_left;
> >  bit_left   += 32;
> >  }
> > @@ -177,9 +179,11 @@ static inline void put_bits(PutBitContext *s, int n,
> > unsigned int value)
> >  } else {
> >  bit_buf   <<= bit_left;
> >  bit_buf|= value >> (n - bit_left);
> > -av_assert2(s->buf_ptr+3buf_end);
> > -AV_WB32(s->buf_ptr, bit_buf);
> > -s->buf_ptr += 4;
> > +if (3 < s->buf_end - s->buf_ptr) {
> > +AV_WB32(s->buf_ptr, bit_buf);
> > +s->buf_ptr += 4;
> > +} else
> > +av_assert0(0);
> >  bit_left   += 32 - n;
> >  bit_buf = value;
> >  }
> 
> If this can happen, using assert0 is bad idea.

Its a internal bug if it happens, it should not happen ...


> If this should not happen add if under assert2.

I tried doing the assert0 without the if() yestarday before sending
the patch but it doubbled the speedloss

Using assert2 instead of assert0 could be done but then there is
no indication of this fault with default configuration.

so i ended up with this a bit funny looking variant as it was the
fastest in my testing

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

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


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

Re: [FFmpeg-devel] [PATCH] avcodec/put_bits: Always check buffer end before writing

[Hendrik Leppkes]

On Fri, Jan 1, 2016 at 1:39 PM, Michael Niedermayer
 wrote:
> On Fri, Jan 01, 2016 at 08:59:23AM +, Paul B Mahol wrote:
>> On 1/1/16, Michael Niedermayer  wrote:
>> > From: Michael Niedermayer 
>> >
>> > This causes a overall slowdown of 0.1 % (tested with mpeg4 single thread
>> > encoding of matrixbench at QP=3)
>> >
>> > Signed-off-by: Michael Niedermayer 
>> > ---
>> >  libavcodec/put_bits.h |   16 ++--
>> >  1 file changed, 10 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/libavcodec/put_bits.h b/libavcodec/put_bits.h
>> > index 5b1bc8b..69a3049 100644
>> > --- a/libavcodec/put_bits.h
>> > +++ b/libavcodec/put_bits.h
>> > @@ -163,9 +163,11 @@ static inline void put_bits(PutBitContext *s, int n,
>> > unsigned int value)
>> >  #ifdef BITSTREAM_WRITER_LE
>> >  bit_buf |= value << (32 - bit_left);
>> >  if (n >= bit_left) {
>> > -av_assert2(s->buf_ptr+3buf_end);
>> > -AV_WL32(s->buf_ptr, bit_buf);
>> > -s->buf_ptr += 4;
>> > +if (3 < s->buf_end - s->buf_ptr) {
>> > +AV_WL32(s->buf_ptr, bit_buf);
>> > +s->buf_ptr += 4;
>> > +} else
>> > +av_assert0(0);
>> >  bit_buf = value >> bit_left;
>> >  bit_left   += 32;
>> >  }
>> > @@ -177,9 +179,11 @@ static inline void put_bits(PutBitContext *s, int n,
>> > unsigned int value)
>> >  } else {
>> >  bit_buf   <<= bit_left;
>> >  bit_buf|= value >> (n - bit_left);
>> > -av_assert2(s->buf_ptr+3buf_end);
>> > -AV_WB32(s->buf_ptr, bit_buf);
>> > -s->buf_ptr += 4;
>> > +if (3 < s->buf_end - s->buf_ptr) {
>> > +AV_WB32(s->buf_ptr, bit_buf);
>> > +s->buf_ptr += 4;
>> > +} else
>> > +av_assert0(0);
>> >  bit_left   += 32 - n;
>> >  bit_buf = value;
>> >  }
>>
>> If this can happen, using assert0 is bad idea.
>
> Its a internal bug if it happens, it should not happen ...
>
>
>> If this should not happen add if under assert2.
>
> I tried doing the assert0 without the if() yestarday before sending
> the patch but it doubbled the speedloss
>
> Using assert2 instead of assert0 could be done but then there is
> no indication of this fault with default configuration.
>
> so i ended up with this a bit funny looking variant as it was the
> fastest in my testing
>

asserts should generally track things that cannot happen.
If this is a legit error case, it should be checked as such -  and if
it cannot happen, it might as well use assert2 so there is no slowdown
for normal execution.

Anyone working on this particular code is then advised to build with
assert level 2 to avoid introducing bugs that might trigger this.

In general a "release" build should really not contain any asserts, as
they should be present only to double-check internal assumptions and
avoid breakage, not something for users (CLI or API alike) to concern
themself with.

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

Re: [FFmpeg-devel] [PATCH] avcodec/put_bits: Always check buffer end before writing

[Michael Niedermayer]

On Fri, Jan 01, 2016 at 02:07:34PM +0100, Hendrik Leppkes wrote:
> On Fri, Jan 1, 2016 at 1:39 PM, Michael Niedermayer
>  wrote:
> > On Fri, Jan 01, 2016 at 08:59:23AM +, Paul B Mahol wrote:
> >> On 1/1/16, Michael Niedermayer  wrote:
> >> > From: Michael Niedermayer 
> >> >
> >> > This causes a overall slowdown of 0.1 % (tested with mpeg4 single thread
> >> > encoding of matrixbench at QP=3)
> >> >
> >> > Signed-off-by: Michael Niedermayer 
> >> > ---
> >> >  libavcodec/put_bits.h |   16 ++--
> >> >  1 file changed, 10 insertions(+), 6 deletions(-)
> >> >
> >> > diff --git a/libavcodec/put_bits.h b/libavcodec/put_bits.h
> >> > index 5b1bc8b..69a3049 100644
> >> > --- a/libavcodec/put_bits.h
> >> > +++ b/libavcodec/put_bits.h
> >> > @@ -163,9 +163,11 @@ static inline void put_bits(PutBitContext *s, int n,
> >> > unsigned int value)
> >> >  #ifdef BITSTREAM_WRITER_LE
> >> >  bit_buf |= value << (32 - bit_left);
> >> >  if (n >= bit_left) {
> >> > -av_assert2(s->buf_ptr+3buf_end);
> >> > -AV_WL32(s->buf_ptr, bit_buf);
> >> > -s->buf_ptr += 4;
> >> > +if (3 < s->buf_end - s->buf_ptr) {
> >> > +AV_WL32(s->buf_ptr, bit_buf);
> >> > +s->buf_ptr += 4;
> >> > +} else
> >> > +av_assert0(0);
> >> >  bit_buf = value >> bit_left;
> >> >  bit_left   += 32;
> >> >  }
> >> > @@ -177,9 +179,11 @@ static inline void put_bits(PutBitContext *s, int n,
> >> > unsigned int value)
> >> >  } else {
> >> >  bit_buf   <<= bit_left;
> >> >  bit_buf|= value >> (n - bit_left);
> >> > -av_assert2(s->buf_ptr+3buf_end);
> >> > -AV_WB32(s->buf_ptr, bit_buf);
> >> > -s->buf_ptr += 4;
> >> > +if (3 < s->buf_end - s->buf_ptr) {
> >> > +AV_WB32(s->buf_ptr, bit_buf);
> >> > +s->buf_ptr += 4;
> >> > +} else
> >> > +av_assert0(0);
> >> >  bit_left   += 32 - n;
> >> >  bit_buf = value;
> >> >  }
> >>
> >> If this can happen, using assert0 is bad idea.
> >
> > Its a internal bug if it happens, it should not happen ...
> >
> >
> >> If this should not happen add if under assert2.
> >
> > I tried doing the assert0 without the if() yestarday before sending
> > the patch but it doubbled the speedloss
> >
> > Using assert2 instead of assert0 could be done but then there is
> > no indication of this fault with default configuration.
> >
> > so i ended up with this a bit funny looking variant as it was the
> > fastest in my testing
> >
> 
> asserts should generally track things that cannot happen.
> If this is a legit error case, it should be checked as such -  and if
> it cannot happen, it might as well use assert2 so there is no slowdown
> for normal execution.
> 
> Anyone working on this particular code is then advised to build with
> assert level 2 to avoid introducing bugs that might trigger this.
> 
> In general a "release" build should really not contain any asserts, as
> they should be present only to double-check internal assumptions and
> avoid breakage, not something for users (CLI or API alike) to concern
> themself with.

The assert0 here is used to turn a out of array WRITE into an ABORT
thus preventing the possibility of an arbitrary code execution exploit
it is not a legit error condition if this happens nor does it
achive its purpose if its disabled in user builds

That is what av_assert0() is for, something that is always checked
because the consequences of a bug and failure to check
are worse than an abort()

It would be possible to skip the write and continue, silently
generating a corrupted output, this seems strictly worse to me than
loudly aborting and pointing to a internal bug.
Bugs in the code should be pointed at with some noise so they are
seen, reported and corrected quickly.

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

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


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

[FFmpeg-devel] 2.9/3.0, 2.8.5, ...

[Michael Niedermayer]

Hi all

Its a while since 2.8 so unless there are objections i will make a
2.9 or if people prefer a 3.0 within the next month or so

Also ill likely make another round of point releases from the
2.8/2.7/2.6/2.5 branches soon, that is if someone wants to backport
something or fix and backport ...

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] 2.9/3.0, 2.8.5, ...

[Paul B Mahol]

On 1/1/16, Michael Niedermayer  wrote:
> Hi all
>
> Its a while since 2.8 so unless there are objections i will make a
> 2.9 or if people prefer a 3.0 within the next month or so
>
> Also ill likely make another round of point releases from the
> 2.8/2.7/2.6/2.5 branches soon, that is if someone wants to backport
> something or fix and backport ...

There were major bump, so 3.0 makes more sense
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] 2.9/3.0, 2.8.5, ...

[Rostislav Pehlivanov]

I think a 3.0 release needs more major things, so a 2.9 would make more
sense IMO.

On 1 January 2016 at 14:28, Paul B Mahol  wrote:

> On 1/1/16, Michael Niedermayer  wrote:
> > Hi all
> >
> > Its a while since 2.8 so unless there are objections i will make a
> > 2.9 or if people prefer a 3.0 within the next month or so
> >
> > Also ill likely make another round of point releases from the
> > 2.8/2.7/2.6/2.5 branches soon, that is if someone wants to backport
> > something or fix and backport ...
>
> There were major bump, so 3.0 makes more sense
> ___
> 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] Revert "Merge commit '9f1eccb97bf8894cb18b14f642500686505ef186'"

[Michael Niedermayer]

From: Michael Niedermayer 

This unbreaks encoding
Example:
ffmpeg -i matrixbench_mpeg2.mpg new.avi

-rw-r- 1 michael michael 226035354 Jan  1 16:27 new.avi
-rw-r- 1 michael michael  10016802 Jan  1 16:28 ref.avi

Also av_get_audio_frame_duration() itself uses frame_size

This reverts commit 29e6606e9b42aa811be995e2fcdea4806911bc9f, reversing
changes made to 53448461a7720afab0d1f1234af79573fd2e020d.
---
 libavformat/riffenc.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index 250cf41..ceb27f2 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -242,7 +242,12 @@ void ff_parse_specific_params(AVStream *st, int *au_rate,
 int gcd;
 int audio_frame_size;
 
+/* We use the known constant frame size for the codec if known, otherwise
+ * fall back on using AVCodecContext.frame_size, which is not as reliable
+ * for indicating packet duration. */
 audio_frame_size = av_get_audio_frame_duration(codec, 0);
+if (!audio_frame_size)
+audio_frame_size = codec->frame_size;
 
 *au_ssize = codec->block_align;
 if (audio_frame_size && codec->sample_rate) {
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH][WIP] lavc/cbrt_tablegen: speed up tablegen

[Ganesh Ajjanagadde]

On Fri, Jan 1, 2016 at 7:43 AM, Ronald S. Bultje  wrote:
> Hi,
>
> On Fri, Jan 1, 2016 at 10:40 AM, Ganesh Ajjanagadde 
> wrote:
>>
>> On Fri, Jan 1, 2016 at 6:54 AM, Ronald S. Bultje 
>> wrote:
>> > Hi,
>> >
>> > On Thu, Dec 31, 2015 at 9:55 PM, Ganesh Ajjanagadde
>> > 
>> > wrote:
>> >>
>> >> This exploits an approach based on the sieve of Eratosthenes, a popular
>> >> method for generating prime numbers.
>> >>
>> >> Tables are identical to previous ones.
>> >>
>> >> Tested with FATE. Does not work yet with --enable-hardcoded-tables due
>> >> to the union and lack of proper WRITE_ARRAY for it. Want to get
>> >> feedback
>> >> on this; if we always dynamically init it this won't need addressing.
>> >
>> >
>> > I think you're getting ahead of yourself here. Assume for now that the
>> > hardcoded-tables feature will continue to exist for a while.
>>
>> I was referring to just this one, not to the question in general.
>
>
> I was also referring to this case specifically. Assume, for now, that
> hardcoded tables for this specific case, will continue to exist.

Then defend it technically please. For instance, you have not
addressed the fundamental amortization of table init cost.

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

Re: [FFmpeg-devel] 2.9/3.0, 2.8.5, ...

[Carl Eugen Hoyos]

Paul B Mahol  gmail.com> writes:

> On 1/1/16, Michael Niedermayer  niedermayer.cc> wrote:
> > Hi all
> >
> > Its a while since 2.8 so unless there are objections i will make a
> > 2.9 or if people prefer a 3.0 within the next month or so

The number of open regressions is quite high atm...

> There were major bump, so 3.0 makes more sense

+1

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH][WIP] lavc/cbrt_tablegen: speed up tablegen

[Ganesh Ajjanagadde]

On Fri, Jan 1, 2016 at 7:51 AM, Ronald S. Bultje  wrote:
> Hi,
>
> On Fri, Jan 1, 2016 at 10:46 AM, Ganesh Ajjanagadde 
> wrote:
>>
>> On Fri, Jan 1, 2016 at 7:43 AM, Ronald S. Bultje 
>> wrote:
>> > Hi,
>> >
>> > On Fri, Jan 1, 2016 at 10:40 AM, Ganesh Ajjanagadde
>> > 
>> > wrote:
>> >>
>> >> On Fri, Jan 1, 2016 at 6:54 AM, Ronald S. Bultje 
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > On Thu, Dec 31, 2015 at 9:55 PM, Ganesh Ajjanagadde
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> This exploits an approach based on the sieve of Eratosthenes, a
>> >> >> popular
>> >> >> method for generating prime numbers.
>> >> >>
>> >> >> Tables are identical to previous ones.
>> >> >>
>> >> >> Tested with FATE. Does not work yet with --enable-hardcoded-tables
>> >> >> due
>> >> >> to the union and lack of proper WRITE_ARRAY for it. Want to get
>> >> >> feedback
>> >> >> on this; if we always dynamically init it this won't need
>> >> >> addressing.
>> >> >
>> >> >
>> >> > I think you're getting ahead of yourself here. Assume for now that
>> >> > the
>> >> > hardcoded-tables feature will continue to exist for a while.
>> >>
>> >> I was referring to just this one, not to the question in general.
>> >
>> >
>> > I was also referring to this case specifically. Assume, for now, that
>> > hardcoded tables for this specific case, will continue to exist.
>>
>> Then defend it technically please. For instance, you have not
>> addressed the fundamental amortization of table init cost.
>
>
> No. It is the status quo, and remains that until it changes. That's why it's
> called the status quo. I've encouraged you several times to have this debate
> in the open, but you keep jumping away when that comes up.

What is this if not "open"? Where does this "jumping away" come from?
Please refrain from baseless comments.

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

Re: [FFmpeg-devel] [PATCH] Revert "Merge commit '9f1eccb97bf8894cb18b14f642500686505ef186'"

[Michael Niedermayer]

On Fri, Jan 01, 2016 at 04:48:12PM +0100, Hendrik Leppkes wrote:
> On Fri, Jan 1, 2016 at 4:37 PM, Michael Niedermayer  wrote:
> > From: Michael Niedermayer 
> >
> > This unbreaks encoding
> > Example:
> > ffmpeg -i matrixbench_mpeg2.mpg new.avi
> >
> > -rw-r- 1 michael michael 226035354 Jan  1 16:27 new.avi
> > -rw-r- 1 michael michael  10016802 Jan  1 16:28 ref.avi
> >
> > Also av_get_audio_frame_duration() itself uses frame_size
> >
> > This reverts commit 29e6606e9b42aa811be995e2fcdea4806911bc9f, reversing
> > changes made to 53448461a7720afab0d1f1234af79573fd2e020d.
> > ---
> >  libavformat/riffenc.c |5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
> > index 250cf41..ceb27f2 100644
> > --- a/libavformat/riffenc.c
> > +++ b/libavformat/riffenc.c
> > @@ -242,7 +242,12 @@ void ff_parse_specific_params(AVStream *st, int 
> > *au_rate,
> >  int gcd;
> >  int audio_frame_size;
> >
> > +/* We use the known constant frame size for the codec if known, 
> > otherwise
> > + * fall back on using AVCodecContext.frame_size, which is not as 
> > reliable
> > + * for indicating packet duration. */
> >  audio_frame_size = av_get_audio_frame_duration(codec, 0);
> > +if (!audio_frame_size)
> > +audio_frame_size = codec->frame_size;
> >
> >  *au_ssize = codec->block_align;
> >  if (audio_frame_size && codec->sample_rate) {
> > --
> 
> Using the AVCodecContext from a muxer is deprecated, and sooner or
> later this code will have to be "fixed" again to no longer rely on
> this parameter when calling code no longer provides this parameter. So
> better would be to figure out why it needs special handling here.
> The comment above it even says that its not reliable.
> 
> Feel free to commit in the meantime, but this is going to break again
> in the future if not fixed properly.

applied
thx

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

No snowflake in an avalanche ever feels responsible. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH] avcodec/utils: Add case for mp3 to av_get_audio_frame_duration()

[Ronald S. Bultje]

Hi,

On Fri, Jan 1, 2016 at 11:43 AM, Michael Niedermayer 
wrote:

> From: Michael Niedermayer 
>
> This is not guranteed to be correct but only the encoder or the packet
> headers
> can really provide the correct value. And before the first packet there is
> no alternative to receiving the value from the encoder by some means
>
> other codecs like AAC are still missing and are left for voluteers
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/utils.c |6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 4b4aea0..6ed47ef 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -3042,6 +3042,12 @@ int av_get_audio_frame_duration(AVCodecContext
> *avctx, int frame_bytes)
>  if (id == AV_CODEC_ID_TTA)
>  return 256 * sr / 245;
>
> +// When frame_bytes is set then the headers can be parsed to find
> the
> +// frame size
> +if (id == AV_CODEC_ID_MP3 && !frame_bytes) {
> +return sr <= 24000 ? 576 : 1152;
> +}
> +
>  if (ch > 0) {
>  /* calc from sample rate and channels */
>  if (id == AV_CODEC_ID_BINKAUDIO_DCT)
> --
> 1.7.9.5


Please, no more codec-specific hacks in generic code.

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

Re: [FFmpeg-devel] [PATCH] avcodec/utils: Add case for mp3 to av_get_audio_frame_duration()

[Hendrik Leppkes]

On Fri, Jan 1, 2016 at 7:29 PM, Ronald S. Bultje  wrote:
> Hi,
>
> On Fri, Jan 1, 2016 at 11:43 AM, Michael Niedermayer 
> wrote:
>
>> From: Michael Niedermayer 
>>
>> This is not guranteed to be correct but only the encoder or the packet
>> headers
>> can really provide the correct value. And before the first packet there is
>> no alternative to receiving the value from the encoder by some means
>>
>> other codecs like AAC are still missing and are left for voluteers
>>
>> Signed-off-by: Michael Niedermayer 
>> ---
>>  libavcodec/utils.c |6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>> index 4b4aea0..6ed47ef 100644
>> --- a/libavcodec/utils.c
>> +++ b/libavcodec/utils.c
>> @@ -3042,6 +3042,12 @@ int av_get_audio_frame_duration(AVCodecContext
>> *avctx, int frame_bytes)
>>  if (id == AV_CODEC_ID_TTA)
>>  return 256 * sr / 245;
>>
>> +// When frame_bytes is set then the headers can be parsed to find
>> the
>> +// frame size
>> +if (id == AV_CODEC_ID_MP3 && !frame_bytes) {
>> +return sr <= 24000 ? 576 : 1152;
>> +}
>> +
>>  if (ch > 0) {
>>  /* calc from sample rate and channels */
>>  if (id == AV_CODEC_ID_BINKAUDIO_DCT)
>> --
>> 1.7.9.5
>
>
> Please, no more codec-specific hacks in generic code.
>

This whole function is codec specific crazy.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/utils: Add case for mp3 to av_get_audio_frame_duration()

[Derek Buitenhuis]

On 1/1/2016 6:29 PM, Ronald S. Bultje wrote:
> Please, no more codec-specific hacks in generic code.

Eh, how is being generic even possible for audio frame size?

What defines an audio "frame", if not the codec?

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

Re: [FFmpeg-devel] [PATCH] lavfi/af_sofalizer: remove exp2 and replace clz by ff_clz

[Ganesh Ajjanagadde]

On Tue, Dec 29, 2015 at 1:17 PM, Ganesh Ajjanagadde
 wrote:
> ff_clz is faster, and uses an intrinsic (at the moment on GCC). exp2 is
> a wasteful function for a simple integer exponentiation.
>
> Untested.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavfilter/af_sofalizer.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/af_sofalizer.c b/libavfilter/af_sofalizer.c
> index 6a24cbc..0bd1931 100644
> --- a/libavfilter/af_sofalizer.c
> +++ b/libavfilter/af_sofalizer.c
> @@ -30,6 +30,7 @@
>
>  #include "libavcodec/avfft.h"
>  #include "libavutil/float_dsp.h"
> +#include "libavutil/intmath.h"
>  #include "libavutil/opt.h"
>  #include "avfilter.h"
>  #include "internal.h"
> @@ -996,8 +997,8 @@ static int config_input(AVFilterLink *inlink)
>  }
>  /* buffer length is longest IR plus max. delay -> next power of 2
> (32 - count leading zeros gives required exponent)  */
> -s->buffer_length = exp2(32 - clz((uint32_t)n_max));
> -s->n_fft = exp2(32 - clz((uint32_t)(n_max + 
> inlink->sample_rate)));
> +s->buffer_length = 1 << (32 - ff_clz(n_max));
> +s->n_fft = 1 << (32 - ff_clz(n_max + inlink->sample_rate));
>
>  if (s->type == FREQUENCY_DOMAIN) {
>  av_fft_end(s->fft[0]);
> --
> 2.6.4
>

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

Re: [FFmpeg-devel] [PATCH 2/2] avfilter: add showspectrumpic filter

[Paul B Mahol]

Latest version attached.
From d9517bc3d07bd1d4ca939198f8da44f36dd3319f Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Thu, 31 Dec 2015 20:45:37 +0100
Subject: [PATCH 2/2] avfilter: add showspectrumpic filter

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi   | 106 +++
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/avf_showspectrum.c | 234 ++---
 4 files changed, 327 insertions(+), 15 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 7839daa..e93463d 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14704,6 +14704,112 @@ ffplay -f lavfi 'amovie=input.mp3, asplit [a][out1];
 @end example
 @end itemize
 
+@section showspectrumpic
+
+Convert input audio to a single video frame, representing the audio frequency
+spectrum.
+
+The filter accepts the following options:
+
+@table @option
+@item size, s
+Specify the video size for the output. For the syntax of this option, check the
+@ref{video size syntax,,"Video size" section in the ffmpeg-utils manual,ffmpeg-utils}.
+Default value is @code{640x512}.
+
+@item mode
+Specify display mode.
+
+It accepts the following values:
+@table @samp
+@item combined
+all channels are displayed in the same row
+@item separate
+all channels are displayed in separate rows
+@end table
+Default value is @samp{combined}.
+
+@item color
+Specify display color mode.
+
+It accepts the following values:
+@table @samp
+@item channel
+each channel is displayed in a separate color
+@item intensity
+each channel is displayed using the same color scheme
+@item rainbow
+each channel is displayed using the rainbow color scheme
+@item moreland
+each channel is displayed using the moreland color scheme
+@item nebulae
+each channel is displayed using the nebulae color scheme
+@item fire
+each channel is displayed using the fire color scheme
+@end table
+Default value is @samp{channel}.
+
+@item scale
+Specify scale used for calculating intensity color values.
+
+It accepts the following values:
+@table @samp
+@item lin
+linear
+@item sqrt
+square root, default
+@item cbrt
+cubic root
+@item log
+logarithmic
+@end table
+Default value is @samp{sqrt}.
+
+@item saturation
+Set saturation modifier for displayed colors. Negative values provide
+alternative color scheme. @code{0} is no saturation at all.
+Saturation must be in [-10.0, 10.0] range.
+Default value is @code{1}.
+
+@item win_func
+Set window function.
+
+It accepts the following values:
+@table @samp
+@item rect
+@item bartlett
+@item hann
+@item hanning
+@item hamming
+@item blackman
+@item welch
+@item flattop
+@item bharris
+@item bnuttall
+@item bhann
+@item sine
+@item nuttall
+@item lanczos
+@item gauss
+@end table
+Default value is @code{hann}.
+
+@item orientation
+Set orientation of time vs frequency axis. Can be @code{vertical} or
+@code{horizontal}. Default is @code{vertical}.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Extract an audio spectrogram of a whole audio track
+in a 1024x1024 picture using @command{ffmpeg}:
+@example
+ffmpeg -i audio.flac -lavfi showspectrumpic=s=1024x1024 spectrogram.png
+@end example
+@end itemize
+
 @section showvolume
 
 Convert input audio volume to a video output.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e334016..689da73 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -286,6 +286,7 @@ OBJS-$(CONFIG_CONCAT_FILTER) += avf_concat.o
 OBJS-$(CONFIG_SHOWCQT_FILTER)+= avf_showcqt.o lswsutils.o lavfutils.o
 OBJS-$(CONFIG_SHOWFREQS_FILTER)  += avf_showfreqs.o window_func.o
 OBJS-$(CONFIG_SHOWSPECTRUM_FILTER)   += avf_showspectrum.o window_func.o
+OBJS-$(CONFIG_SHOWSPECTRUMPIC_FILTER)+= avf_showspectrum.o window_func.o
 OBJS-$(CONFIG_SHOWVOLUME_FILTER) += avf_showvolume.o
 OBJS-$(CONFIG_SHOWWAVES_FILTER)  += avf_showwaves.o
 OBJS-$(CONFIG_SHOWWAVESPIC_FILTER)   += avf_showwaves.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index a039a39..2267e88 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -306,6 +306,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(SHOWCQT,showcqt,avf);
 REGISTER_FILTER(SHOWFREQS,  showfreqs,  avf);
 REGISTER_FILTER(SHOWSPECTRUM,   showspectrum,   avf);
+REGISTER_FILTER(SHOWSPECTRUMPIC, showspectrumpic, avf);
 REGISTER_FILTER(SHOWVOLUME, showvolume, avf);
 REGISTER_FILTER(SHOWWAVES,  showwaves,  avf);
 REGISTER_FILTER(SHOWWAVESPIC,   showwavespic,   avf);
diff --git a/libavfilter/avf_showspectrum.c b/libavfilter/avf_showspectrum.c
index 0fa1be1..4b6e71c 100644
--- a/libavfilter/avf_showspectrum.c
+++ b/libavfilter/avf_showspectrum.c
@@ -63,6 +63,7 @@ typedef struct {
 int rdft_bits;  ///< number of bits (RDFT window size = 1<

Re: [FFmpeg-devel] [PATCH 2/2] avfilter: add showspectrumpic filter

[Clément Bœsch]

On Fri, Jan 01, 2016 at 10:00:31AM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi   | 106 +++
>  libavfilter/Makefile   |   1 +
>  libavfilter/allfilters.c   |   1 +
>  libavfilter/avf_showspectrum.c | 233 
> ++---
>  4 files changed, 326 insertions(+), 15 deletions(-)
> 
[...]
> diff --git a/libavfilter/avf_showspectrum.c b/libavfilter/avf_showspectrum.c
> index 0fa1be1..2992c2f 100644
> --- a/libavfilter/avf_showspectrum.c
> +++ b/libavfilter/avf_showspectrum.c
> @@ -63,6 +63,7 @@ typedef struct {
>  int rdft_bits;  ///< number of bits (RDFT window size = 
> 1<  FFTSample **rdft_data;  ///< bins holder for each (displayed) 
> channels
>  float *window_func_lut; ///< Window function LUT
> +float **magnitudes;
>  int win_func;
>  int win_size;
>  double win_scale;
> @@ -186,6 +187,9 @@ static av_cold void uninit(AVFilterContext *ctx)
>  av_freep(>rdft_data[i]);
>  av_freep(>rdft_data);
>  av_freep(>window_func_lut);
> +for (i = 0; i < s->nb_display_channels; i++)
> +av_freep(>magnitudes[i]);
> +av_freep(>magnitudes);
>  av_frame_free(>outpicref);
>  av_audio_fifo_free(s->fifo);
>  }
> @@ -267,6 +271,15 @@ static int config_output(AVFilterLink *outlink)
>  av_freep(>rdft_data);
>  s->nb_display_channels = inlink->channels;
>  
> +s->magnitudes = av_calloc(s->nb_display_channels, 
> sizeof(*s->magnitudes));
> +if (!s->magnitudes)
> +return AVERROR(ENOMEM);
> +for (i = 0; i < s->nb_display_channels; i++) {
> +s->magnitudes[i] = av_calloc(s->orientation == VERTICAL ? s->h: 
> s->w, sizeof(**s->magnitudes));

nit: space before ':' (you have the same typo later on for some reason)

[...]
> +static const AVOption showspectrumpic_options[] = {
> +{ "size", "set video size", OFFSET(w), AV_OPT_TYPE_IMAGE_SIZE, {.str = 
> "640x512"}, 0, 0, FLAGS },
> +{ "s","set video size", OFFSET(w), AV_OPT_TYPE_IMAGE_SIZE, {.str = 
> "640x512"}, 0, 0, FLAGS },
> +{ "mode", "set channel display mode", OFFSET(mode), AV_OPT_TYPE_INT, 
> {.i64=COMBINED}, COMBINED, NB_MODES-1, FLAGS, "mode" },
> +{ "combined", "combined mode", 0, AV_OPT_TYPE_CONST, 
> {.i64=COMBINED}, 0, 0, FLAGS, "mode" },
> +{ "separate", "separate mode", 0, AV_OPT_TYPE_CONST, 
> {.i64=SEPARATE}, 0, 0, FLAGS, "mode" },
> +{ "color", "set channel coloring", OFFSET(color_mode), AV_OPT_TYPE_INT, 
> {.i64=CHANNEL}, CHANNEL, NB_CLMODES-1, FLAGS, "color" },
> +{ "channel",   "separate color for each channel", 0, 
> AV_OPT_TYPE_CONST, {.i64=CHANNEL},   0, 0, FLAGS, "color" },
> +{ "intensity", "intensity based coloring",0, 
> AV_OPT_TYPE_CONST, {.i64=INTENSITY}, 0, 0, FLAGS, "color" },
> +{ "rainbow",   "rainbow based coloring",  0, 
> AV_OPT_TYPE_CONST, {.i64=RAINBOW},   0, 0, FLAGS, "color" },
> +{ "moreland",  "moreland based coloring", 0, 
> AV_OPT_TYPE_CONST, {.i64=MORELAND},  0, 0, FLAGS, "color" },
> +{ "nebulae",   "nebulae based coloring",  0, 
> AV_OPT_TYPE_CONST, {.i64=NEBULAE},   0, 0, FLAGS, "color" },
> +{ "fire",  "fire based coloring", 0, 
> AV_OPT_TYPE_CONST, {.i64=FIRE},  0, 0, FLAGS, "color" },
> +{ "scale", "set display scale", OFFSET(scale), AV_OPT_TYPE_INT, 
> {.i64=SQRT}, LINEAR, NB_SCALES-1, FLAGS, "scale" },
> +{ "sqrt", "square root", 0, AV_OPT_TYPE_CONST, {.i64=SQRT},   0, 0, 
> FLAGS, "scale" },
> +{ "cbrt", "cubic root",  0, AV_OPT_TYPE_CONST, {.i64=CBRT},   0, 0, 
> FLAGS, "scale" },
> +{ "log",  "logarithmic", 0, AV_OPT_TYPE_CONST, {.i64=LOG},0, 0, 
> FLAGS, "scale" },
> +{ "lin",  "linear",  0, AV_OPT_TYPE_CONST, {.i64=LINEAR}, 0, 0, 
> FLAGS, "scale" },
> +{ "saturation", "color saturation multiplier", OFFSET(saturation), 
> AV_OPT_TYPE_FLOAT, {.dbl = 1}, -10, 10, FLAGS },
> +{ "win_func", "set window function", OFFSET(win_func), AV_OPT_TYPE_INT, 
> {.i64 = WFUNC_HANNING}, 0, NB_WFUNC-1, FLAGS, "win_func" },
> +{ "rect", "Rectangular",  0, AV_OPT_TYPE_CONST, 
> {.i64=WFUNC_RECT}, 0, 0, FLAGS, "win_func" },
> +{ "bartlett", "Bartlett", 0, AV_OPT_TYPE_CONST, 
> {.i64=WFUNC_BARTLETT}, 0, 0, FLAGS, "win_func" },
> +{ "hann", "Hann", 0, AV_OPT_TYPE_CONST, 
> {.i64=WFUNC_HANNING},  0, 0, FLAGS, "win_func" },
> +{ "hanning",  "Hanning",  0, AV_OPT_TYPE_CONST, 
> {.i64=WFUNC_HANNING},  0, 0, FLAGS, "win_func" },
> +{ "hamming",  "Hamming",  0, AV_OPT_TYPE_CONST, 
> {.i64=WFUNC_HAMMING},  0, 0, FLAGS, "win_func" },
> +{ "blackman", "Blackman", 0, AV_OPT_TYPE_CONST, 
> {.i64=WFUNC_BLACKMAN}, 0, 0, FLAGS, "win_func" },
> +{ "welch","Welch",0, 

Re: [FFmpeg-devel] [PATCH 2/2] avfilter: add showspectrumpic filter

[Paul B Mahol]

On 1/1/16, Clement Boesch  wrote:
> On Fri, Jan 01, 2016 at 10:00:31AM +0100, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol 
>> ---
>>  doc/filters.texi   | 106 +++
>>  libavfilter/Makefile   |   1 +
>>  libavfilter/allfilters.c   |   1 +
>>  libavfilter/avf_showspectrum.c | 233
>> ++---
>>  4 files changed, 326 insertions(+), 15 deletions(-)
>>
> [...]
>> diff --git a/libavfilter/avf_showspectrum.c
>> b/libavfilter/avf_showspectrum.c
>> index 0fa1be1..2992c2f 100644
>> --- a/libavfilter/avf_showspectrum.c
>> +++ b/libavfilter/avf_showspectrum.c
>> @@ -63,6 +63,7 @@ typedef struct {
>>  int rdft_bits;  ///< number of bits (RDFT window size =
>> 1<>  FFTSample **rdft_data;  ///< bins holder for each (displayed)
>> channels
>>  float *window_func_lut; ///< Window function LUT
>> +float **magnitudes;
>>  int win_func;
>>  int win_size;
>>  double win_scale;
>> @@ -186,6 +187,9 @@ static av_cold void uninit(AVFilterContext *ctx)
>>  av_freep(>rdft_data[i]);
>>  av_freep(>rdft_data);
>>  av_freep(>window_func_lut);
>> +for (i = 0; i < s->nb_display_channels; i++)
>> +av_freep(>magnitudes[i]);
>> +av_freep(>magnitudes);
>>  av_frame_free(>outpicref);
>>  av_audio_fifo_free(s->fifo);
>>  }
>> @@ -267,6 +271,15 @@ static int config_output(AVFilterLink *outlink)
>>  av_freep(>rdft_data);
>>  s->nb_display_channels = inlink->channels;
>>
>> +s->magnitudes = av_calloc(s->nb_display_channels,
>> sizeof(*s->magnitudes));
>> +if (!s->magnitudes)
>> +return AVERROR(ENOMEM);
>> +for (i = 0; i < s->nb_display_channels; i++) {
>> +s->magnitudes[i] = av_calloc(s->orientation == VERTICAL ?
>> s->h: s->w, sizeof(**s->magnitudes));
>
> nit: space before ':' (you have the same typo later on for some reason)
>
> [...]
>> +static const AVOption showspectrumpic_options[] = {
>> +{ "size", "set video size", OFFSET(w), AV_OPT_TYPE_IMAGE_SIZE, {.str
>> = "640x512"}, 0, 0, FLAGS },
>> +{ "s","set video size", OFFSET(w), AV_OPT_TYPE_IMAGE_SIZE, {.str
>> = "640x512"}, 0, 0, FLAGS },
>> +{ "mode", "set channel display mode", OFFSET(mode), AV_OPT_TYPE_INT,
>> {.i64=COMBINED}, COMBINED, NB_MODES-1, FLAGS, "mode" },
>> +{ "combined", "combined mode", 0, AV_OPT_TYPE_CONST,
>> {.i64=COMBINED}, 0, 0, FLAGS, "mode" },
>> +{ "separate", "separate mode", 0, AV_OPT_TYPE_CONST,
>> {.i64=SEPARATE}, 0, 0, FLAGS, "mode" },
>> +{ "color", "set channel coloring", OFFSET(color_mode),
>> AV_OPT_TYPE_INT, {.i64=CHANNEL}, CHANNEL, NB_CLMODES-1, FLAGS, "color" },
>> +{ "channel",   "separate color for each channel", 0,
>> AV_OPT_TYPE_CONST, {.i64=CHANNEL},   0, 0, FLAGS, "color" },
>> +{ "intensity", "intensity based coloring",0,
>> AV_OPT_TYPE_CONST, {.i64=INTENSITY}, 0, 0, FLAGS, "color" },
>> +{ "rainbow",   "rainbow based coloring",  0,
>> AV_OPT_TYPE_CONST, {.i64=RAINBOW},   0, 0, FLAGS, "color" },
>> +{ "moreland",  "moreland based coloring", 0,
>> AV_OPT_TYPE_CONST, {.i64=MORELAND},  0, 0, FLAGS, "color" },
>> +{ "nebulae",   "nebulae based coloring",  0,
>> AV_OPT_TYPE_CONST, {.i64=NEBULAE},   0, 0, FLAGS, "color" },
>> +{ "fire",  "fire based coloring", 0,
>> AV_OPT_TYPE_CONST, {.i64=FIRE},  0, 0, FLAGS, "color" },
>> +{ "scale", "set display scale", OFFSET(scale), AV_OPT_TYPE_INT,
>> {.i64=SQRT}, LINEAR, NB_SCALES-1, FLAGS, "scale" },
>> +{ "sqrt", "square root", 0, AV_OPT_TYPE_CONST, {.i64=SQRT},   0,
>> 0, FLAGS, "scale" },
>> +{ "cbrt", "cubic root",  0, AV_OPT_TYPE_CONST, {.i64=CBRT},   0,
>> 0, FLAGS, "scale" },
>> +{ "log",  "logarithmic", 0, AV_OPT_TYPE_CONST, {.i64=LOG},0,
>> 0, FLAGS, "scale" },
>> +{ "lin",  "linear",  0, AV_OPT_TYPE_CONST, {.i64=LINEAR}, 0,
>> 0, FLAGS, "scale" },
>> +{ "saturation", "color saturation multiplier", OFFSET(saturation),
>> AV_OPT_TYPE_FLOAT, {.dbl = 1}, -10, 10, FLAGS },
>> +{ "win_func", "set window function", OFFSET(win_func),
>> AV_OPT_TYPE_INT, {.i64 = WFUNC_HANNING}, 0, NB_WFUNC-1, FLAGS, "win_func"
>> },
>> +{ "rect", "Rectangular",  0, AV_OPT_TYPE_CONST,
>> {.i64=WFUNC_RECT}, 0, 0, FLAGS, "win_func" },
>> +{ "bartlett", "Bartlett", 0, AV_OPT_TYPE_CONST,
>> {.i64=WFUNC_BARTLETT}, 0, 0, FLAGS, "win_func" },
>> +{ "hann", "Hann", 0, AV_OPT_TYPE_CONST,
>> {.i64=WFUNC_HANNING},  0, 0, FLAGS, "win_func" },
>> +{ "hanning",  "Hanning",  0, AV_OPT_TYPE_CONST,
>> {.i64=WFUNC_HANNING},  0, 0, FLAGS, "win_func" },
>> +{ "hamming",  "Hamming",  0, AV_OPT_TYPE_CONST,
>> {.i64=WFUNC_HAMMING},  0, 0, FLAGS, "win_func" },
>> +{ "blackman", "Blackman", 0, 

Re: [FFmpeg-devel] [PATCH] lavfi/af_sofalizer: remove exp2 and replace clz by ff_clz

[Paul B Mahol]

On 1/1/16, Ganesh Ajjanagadde  wrote:
> On Tue, Dec 29, 2015 at 1:17 PM, Ganesh Ajjanagadde
>  wrote:
>> ff_clz is faster, and uses an intrinsic (at the moment on GCC). exp2 is
>> a wasteful function for a simple integer exponentiation.
>>
>> Untested.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavfilter/af_sofalizer.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavfilter/af_sofalizer.c b/libavfilter/af_sofalizer.c
>> index 6a24cbc..0bd1931 100644
>> --- a/libavfilter/af_sofalizer.c
>> +++ b/libavfilter/af_sofalizer.c
>> @@ -30,6 +30,7 @@
>>
>>  #include "libavcodec/avfft.h"
>>  #include "libavutil/float_dsp.h"
>> +#include "libavutil/intmath.h"
>>  #include "libavutil/opt.h"
>>  #include "avfilter.h"
>>  #include "internal.h"
>> @@ -996,8 +997,8 @@ static int config_input(AVFilterLink *inlink)
>>  }
>>  /* buffer length is longest IR plus max. delay -> next power of 2
>> (32 - count leading zeros gives required exponent)  */
>> -s->buffer_length = exp2(32 - clz((uint32_t)n_max));
>> -s->n_fft = exp2(32 - clz((uint32_t)(n_max +
>> inlink->sample_rate)));
>> +s->buffer_length = 1 << (32 - ff_clz(n_max));
>> +s->n_fft = 1 << (32 - ff_clz(n_max + inlink->sample_rate));
>>
>>  if (s->type == FREQUENCY_DOMAIN) {
>>  av_fft_end(s->fft[0]);
>> --
>> 2.6.4
>>
>
> ping

OK if you remove dead code, clz() function.

> ___
> 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] [RFC v3 1/2] libavcodec: add a native decoder for the Daala video codec

[James Almer]

On 1/1/2016 1:22 PM, Rostislav Pehlivanov wrote:
> +/* Gets a single bit if !!cond and returns ±1 */
> +static av_always_inline int _daalaent_cphase(DaalaEntropy *e, int cond)

Don't start function names with a _ prefix.

> +{
> +if (cond)
> +return 1 - 2*daalaent_decode_bits(e, 1);
> +return 1;
> +}
> +#define daalaent_cphase(x,y) _daalaent_cphase(x, !!y)

Just do

static av_always_inline int daalaent_cphase(DaalaEntropy *e, int cond)
{
if (cond)
return 1 - 2*daalaent_decode_bits(e, 1);
return 1;
}

Instead.

[...]

> +static inline void daalaent_decode_laplace_delta(DaalaEntropy *e, dctcoef *y,
> + int n, int k, dctcoef *curr,
> + const dctcoef *means)

I didn't check but i'm guessing compilers will ignore the inline attribute on 
big
functions like this that are used more than once.

[...]

> +/* Segments frame && decodes */
> +static inline int decode_block_rec(DaalaContext *s, HaarGradient g,
> +   int x, int y, uint8_t p, enum DaalaBsize 
> bsize)
> +{
> +int i, j, lc_skip, cbs;
> +const int sx = x << bsize;
> +const int sy = y << bsize;
> +const int llim = 1 << bsize;
> +const int off  = 2*bsize + !!p;
> +const int bst  = s->bsizes_stride;
> +const int xdec = s->fmt->dec[p][0];
> +const int aw   = s->width >> xdec;
> +enum DaalaBsize obsize = DAALA_BSIZE4x4(s->bsizes, bst, sx, sy);
> +
> +if (s->h.haar) {
> +obsize = bsize;
> +} else if (!p) {
> +lc_skip = daalaent_decode_cdf_adapt(>e, >skip_cdf, off,
> +4 + (bsize > 0));
> +obsize = lc_skip < 4 ? bsize : -1;
> +}
> +
> +if ((cbs = FFMAX(obsize, xdec)) == bsize) {
> +cbs -= xdec;
> +if (!p) {
> +for (i = 0; i < llim; i++)
> +for (j = 0; j < llim; j++)
> +DAALA_BSIZE4x4(s->bsizes, bst, sx + i, sy + j) = bsize;
> +}
> +if (p && s->dsp.cfl) {
> +s->dsp.cfl((uint8_t *)s->lcoef, 1 << (cbs + DAALA_LOG_BSIZE0),
> +   (uint8_t *)(s->dcoef[0] + (y << (2 + bsize))*s->width 
> + (x << (2 + bsize))),
> +   s->width, xdec, s->fmt->dec[p][1], cbs, obsize);
> +}
> +if (p && !s->h.haar) {
> +lc_skip = daalaent_decode_cdf_adapt(>e, >skip_cdf, off, 4);
> +}
> +if (s->h.haar)
> +decode_block_haar(s, x, y, p, cbs);
> +else
> +decode_block_pvq(s, x, y, p, cbs, lc_skip);
> +} else {
> +int bs = bsize - s->fmt->dec[p][0];
> +int bo = (y << (DAALA_LOG_BSIZE0 + bs))*aw + (x << (DAALA_LOG_BSIZE0 
> + bs));
> +int hfilter = (x + 1) << (DAALA_LOG_BSIZE0 + bs) <= s->width;
> +int vfilter = (y + 1) << (DAALA_LOG_BSIZE0 + bs) <= s->height;
> +if (!s->h.key_frame && s->dsp.pre_split_filter)
> +s->dsp.pre_split_filter((uint8_t *)(s->ccoef + bo), aw, bs,
> +hfilter, vfilter);
> +if (s->h.key_frame)
> +get_haar_dc_lvl(s, , s->dcoef[p], 2*x, 2*y, p, bsize - 1);
> +decode_block_rec(s, g, 2*x + 0, 2*y + 0, p, bsize - 1);

All this is definitely not going to be inlined.

> +decode_block_rec(s, g, 2*x + 1, 2*y + 0, p, bsize - 1);
> +decode_block_rec(s, g, 2*x + 0, 2*y + 1, p, bsize - 1);
> +decode_block_rec(s, g, 2*x + 1, 2*y + 1, p, bsize - 1);
> +if (s->dsp.post_split_filter)
> +s->dsp.post_split_filter((uint8_t *)(s->ccoef[p] + bo), aw, bs,
> + hfilter, vfilter);
> +}
> +
> +return 0;
> +}

[...]

> +av_cold int daaladsp_init(DaalaDSP *d, int bit_depth)

non static functions need to have an ff_ prefix (or avpriv_ if they need to be
used by other libraries).

> +{
> +switch(bit_depth) {
> +case 8:
> +daaladsp_init_8bit(d);
> +break;
> +case 10:
> +case 12:
> +default:
> +return 1;
> +break;
> +}
> +return 0;
> +}
> \ No newline at end of file

This should be fixed.

[...]

> diff --git a/libavcodec/daalatab.c b/libavcodec/daalatab.c
> new file mode 100644
> index 000..3994387
> --- /dev/null
> +++ b/libavcodec/daalatab.c
> @@ -0,0 +1,1563 @@
> +/*
> + * Copyright 2001-2015 Xiph.Org and contributors.
> + * Copyright 2015 Rostislav Pehlivanov 
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + *
> + * - Redistributions of source code must retain the above copyright
> + *   notice, this list of conditions and the following disclaimer.
> + *
> + * - Redistributions in binary form must reproduce the above copyright
> + *   notice, this list of conditions and the following disclaimer in the
> + *   

Re: [FFmpeg-devel] [PATCHv2] lavf/srtdec: rewrite parsing logic

[Clément Bœsch]

On Sat, Dec 26, 2015 at 06:51:00PM +0100, Clément Bœsch wrote:
> Fixes Ticket #5032
> 
> The samples in Ticket #5032 is using \r\r\n as line breaks.  Since we
> already are handling \r, or \n, or \r\n as line breaks, \r\n\n will be
> considered as a double line breaks. This is an issue because
> ff_subtitles_read_text_chunk() will as a result stop extracting a chunk
> after just one line.
> 
> So instead of parsing the SRT by "chunks" (which means splitting every
> double LB), this new parser is detecting timing lines, and split the
> events on this basis. While this sounds safe and simple, it needs to
> take into account the event number preceding the timing line while
> handling situations such as:
> 
>  - event number starting at 0 or actually any number instead of 1
>  - event numbers not being ordered at all
>  - event number being followed by text garbage (this really happened,
>see Ticket #4898)
>  - event payload containing one or multiple number (a protagonist saying
>a count-down, a date or whatever) which could be confused with a
>chapter number
>  - event number being empty (see Ticket #2167)
>  - all kind of weird line breaks can appear randomly like wild pokémons
>  - untrustable line breaks (Ticket #5032)
> 
> The sample madness.srt tries to sum up most of this into one sample,
> ticket5032-rrn.srt is the file containing \r\r\n line breaks. and
> empty-events-2167.srt contains empty events.
> ---
> Now handling empty events, and with a new FATE test
> ---
>  libavformat/srtdec.c |  164 ++-
>  tests/fate/subtitles.mak |9 +
>  tests/ref/fate/sub-srt-empty-events  |   24 +
>  tests/ref/fate/sub-srt-madness-timeshift |   36 +
>  tests/ref/fate/sub-srt-rrn-remux | 2113 
> ++
>  5 files changed, 2296 insertions(+), 50 deletions(-)
>  create mode 100644 tests/ref/fate/sub-srt-empty-events
>  create mode 100644 tests/ref/fate/sub-srt-madness-timeshift
>  create mode 100644 tests/ref/fate/sub-srt-rrn-remux
> 

Applied.

[...]

-- 
Clément B.


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

[FFmpeg-devel] [RFC v3 2/2] oggenc: add support for remuxing of files with the Daala video codec

[Rostislav Pehlivanov]

Requires the parser from the decoder (previous commit).

Signed-off-by: Rostislav Pehlivanov 
---
 libavformat/oggenc.c | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/libavformat/oggenc.c b/libavformat/oggenc.c
index 4907512..7f0cfc1 100644
--- a/libavformat/oggenc.c
+++ b/libavformat/oggenc.c
@@ -452,7 +452,8 @@ static int ogg_write_header(AVFormatContext *s)
 st->codec->codec_id != AV_CODEC_ID_THEORA &&
 st->codec->codec_id != AV_CODEC_ID_SPEEX  &&
 st->codec->codec_id != AV_CODEC_ID_FLAC   &&
-st->codec->codec_id != AV_CODEC_ID_OPUS) {
+st->codec->codec_id != AV_CODEC_ID_OPUS   &&
+st->codec->codec_id != AV_CODEC_ID_DAALA) {
 av_log(s, AV_LOG_ERROR, "Unsupported codec id in stream %d\n", i);
 return AVERROR(EINVAL);
 }
@@ -510,13 +511,19 @@ static int ogg_write_header(AVFormatContext *s)
 }
 } else {
 uint8_t *p;
-const char *cstr = st->codec->codec_id == AV_CODEC_ID_VORBIS ? 
"vorbis" : "theora";
-int header_type = st->codec->codec_id == AV_CODEC_ID_VORBIS ? 3 : 
0x81;
-int framing_bit = st->codec->codec_id == AV_CODEC_ID_VORBIS ? 1 : 
0;
-
-if (avpriv_split_xiph_headers(st->codec->extradata, 
st->codec->extradata_size,
-  st->codec->codec_id == 
AV_CODEC_ID_VORBIS ? 30 : 42,
-  (const uint8_t**)oggstream->header, 
oggstream->header_len) < 0) {
+enum AVCodecID cid = st->codec->codec_id;
+const char *cstr = cid == AV_CODEC_ID_VORBIS ? "vorbis" :
+   cid == AV_CODEC_ID_DAALA  ? "daala" : "theora";
+int f_hdr_size =   cid == AV_CODEC_ID_VORBIS ? 30 :
+   cid == AV_CODEC_ID_DAALA  ? 47 : 42;
+int header_type =  cid == AV_CODEC_ID_VORBIS ? 3 : 0x81;
+int framing_bit =  cid == AV_CODEC_ID_VORBIS ? 1 : 0;
+
+if (avpriv_split_xiph_headers(st->codec->extradata,
+  st->codec->extradata_size,
+  f_hdr_size,
+  (const uint8_t**)oggstream->header,
+  oggstream->header_len) < 0) {
 av_log(s, AV_LOG_ERROR, "Extradata corrupted\n");
 av_freep(>priv_data);
 return AVERROR_INVALIDDATA;
@@ -530,7 +537,7 @@ static int ogg_write_header(AVFormatContext *s)
 return AVERROR(ENOMEM);
 
 bytestream_put_byte(, header_type);
-bytestream_put_buffer(, cstr, 6);
+bytestream_put_buffer(, cstr, strlen(cstr));
 
 if (st->codec->codec_id == AV_CODEC_ID_THEORA) {
 /** KFGSHIFT is the width of the less significant section of 
the granule position
-- 
2.6.4

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

[FFmpeg-devel] [PATCH] avcodec/utils: Add case for mp3 to av_get_audio_frame_duration()

[Michael Niedermayer]

From: Michael Niedermayer 

This is not guranteed to be correct but only the encoder or the packet headers
can really provide the correct value. And before the first packet there is
no alternative to receiving the value from the encoder by some means

other codecs like AAC are still missing and are left for voluteers

Signed-off-by: Michael Niedermayer 
---
 libavcodec/utils.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 4b4aea0..6ed47ef 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -3042,6 +3042,12 @@ int av_get_audio_frame_duration(AVCodecContext *avctx, 
int frame_bytes)
 if (id == AV_CODEC_ID_TTA)
 return 256 * sr / 245;
 
+// When frame_bytes is set then the headers can be parsed to find the
+// frame size
+if (id == AV_CODEC_ID_MP3 && !frame_bytes) {
+return sr <= 24000 ? 576 : 1152;
+}
+
 if (ch > 0) {
 /* calc from sample rate and channels */
 if (id == AV_CODEC_ID_BINKAUDIO_DCT)
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH] avcodec/codec_desc: Add ff_aac_profiles to aac_latm

[Michael Niedermayer]

From: Michael Niedermayer 

Signed-off-by: Michael Niedermayer 
---
 libavcodec/codec_desc.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index e814507..5fbe624 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -2446,6 +2446,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .name  = "aac_latm",
 .long_name = NULL_IF_CONFIG_SMALL("AAC LATM (Advanced Audio Coding 
LATM syntax)"),
 .props = AV_CODEC_PROP_LOSSY,
+.profiles  = NULL_IF_CONFIG_SMALL(ff_aac_profiles),
 },
 {
 .id= AV_CODEC_ID_QDMC,
-- 
1.7.9.5

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