Re: [FFmpeg-devel] [PATCH] avfilter/vf_shuffleframes: Assert that the case of an uninitialized ret does not occur

[Michael Niedermayer]

On Tue, Dec 01, 2015 at 07:21:19PM +, Paul B Mahol wrote:
> On 12/1/15, Michael Niedermayer  wrote:
> > From: Michael Niedermayer 
> >
> > Fixes CID1258479
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavfilter/vf_shuffleframes.c |8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> 
> ok

applied

thx

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

Avoid a single point of failure, be that a person or equipment.


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

Re: [FFmpeg-devel] request for feedback on video codec idea

[Roger Pack]

On 10/14/15, Hendrik Leppkes  wrote:
> On Wed, Oct 14, 2015 at 8:08 PM, Roger Pack  wrote:
>> Lacking a better place to debate this, I would like to ask some
>> questions on a video codec idea...
>>
>> The goal is basically to create a very fast lossless screen capture
>> codec (i.e. in the input there will be lots of repeated "colors" of
>> neighboring pixels, not a lot of dynamic content between frames).
>>
>> I have become aware of some "fast" compression tools like LZO, LZ4,
>> density, etc.  It seems like they all basically compress "the first
>> 64KB then the next 64KB" or something like that [1].
>>
>> My idea is to basically put pixels of the same position, from multiple
>> frames, "together" in a stream, then apply normal (fast) compression
>> algorithms to the stream.  The hope being that if the pixels are the
>> "same" between frames (presumed to be so because of not much dynamic
>> content), the compression will be able to detect the similarity and
>> compress it well.
>>
>> For instance, given 3 frames of video ("one after another" from the
>> incoming video stream), "combine them" into one stream like:
>> pixel 1 frame 1, pixel 1 frame 2, pixel 1 frame 3, pixel 2 frame 2,
>> pixel 2 frame 2, pixel 2 frame 3 ...
>>
>> then basically apply LZ4 or density algorithm to those bytes.
>>
>> The theory being that if there is a lot of repeated content between
>> frames, it will compress well.
>>
>> The basic need/desire for this was that huffyuv, though super fast at
>> encoding (it basically zips the frame), seems to create *huge* files,
>> I assume because "each frame is an I-frame" so it has to re encode
>> everything each frame.   And also the egotistical desire to create the
>> "fastest video codec in existence" in case the same were useful in
>> other situations (i.e. use very little cpu--even huffyuv uses quite a
>> bit of cpu) :)
>>
>> Any feedback on the concept?
>> Also does anything similar to this already exist? (though should I
>> create my new codec, it would be open source of course, which is
>> already different than many [probably efficient] screen capture codecs
>> out there).
>>
>> Thanks.
>> -roger-
>>
>
> I can't really comment on the merits of this compression scheme, but
> note that you might have trouble with the ffmpeg API when handling
> such a codec, since every single data packet would result in X output
> frames (3 in your example) - this is not a scheme that avcodec can
> really represent well.
> On top of that, containers might have troubles timestamping this properly.

True, I had hoped that FFmpeg would have some "b frame" type
functionality that I could leverage somehow...or perhaps I can fake it
by using null frames or something along those lines.
Cheers!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] request for feedback on video codec idea

[Roger Pack]

On 10/14/15, Nicolas George  wrote:
> Le tridi 23 vendémiaire, an CCXXIV, Roger Pack a écrit :
>> For instance, given 3 frames of video ("one after another" from the
>> incoming video stream), "combine them" into one stream like:
>> pixel 1 frame 1, pixel 1 frame 2, pixel 1 frame 3, pixel 2 frame 2,
>> pixel 2 frame 2, pixel 2 frame 3 ...
>>
>> then basically apply LZ4 or density algorithm to those bytes.
>>
>> The theory being that if there is a lot of repeated content between
>> frames, it will compress well.
>
> Standard answer: profile, don't speculate.
>
> I have no idea if this can prove promising, but I am pretty sure you could
> implement enough of it to get an estimate in just a few minutes with your
> language of choice.
>
> Choose a test clip that has convenient properties (frame size multiple of
> your chosen block size, number of frames multiple of the frame group size,
> etc.).
>
> In the program, hardcode the frame size, pixel format, etc., and forego
> error checks. Read a group of frames from standard input, assuming rawvideo
> format, then output the pixels to standard output in the order you want.
>
> Run with standard input piped from ffmpeg to get the rawvideo contents and
> standard output piped to your favorite command-line stream compression
> utility (gzip, xz).
>
> If the result looks promising, enhance. If not, you know you tried.

Great idea.  I think I will do that.
I did get as far as "single frame" encoding using lzo.
It works *great* for synthetically generated data like testsrc.  I
mean like twice as fast as anything else, with better compression LOL.
With real data, not so much.  I'm attaching it here not for it to be
committed but for followers in case it saves anybody some time that
also wants to go down this path.
I will hopefully find time to work on the "multi frame" aspect soon,
and probably save time by doing what you suggested there.
Thanks!
diff --git a/configure b/configure
index a30d831..43108e4 100755
--- a/configure
+++ b/configure
@@ -1961,6 +1961,8 @@ CONFIG_EXTRA="
 hpeldsp
 huffman
 huffyuvdsp
+rzipenc
+rzipdec
 huffyuvencdsp
 idctdsp
 iirfilter
@@ -2283,6 +2285,8 @@ hevc_qsv_decoder_select="hevc_mp4toannexb_bsf hevc_parser 
qsvdec hevc_qsv_hwacce
 hevc_qsv_encoder_select="qsvenc"
 huffyuv_decoder_select="bswapdsp huffyuvdsp llviddsp"
 huffyuv_encoder_select="bswapdsp huffman huffyuvencdsp llviddsp"
+rzip_encoder_select="lzo"
+#rzip_decoder_select="lzo"
 iac_decoder_select="imc_decoder"
 imc_decoder_select="bswapdsp fft mdct sinewin"
 indeo3_decoder_select="hpeldsp"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index d85215d..d54d0ff 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -310,6 +310,8 @@ OBJS-$(CONFIG_HNM4_VIDEO_DECODER)  += hnm4video.o
 OBJS-$(CONFIG_HQ_HQA_DECODER)  += hq_hqa.o hq_hqadata.o hq_hqadsp.o \
   canopus.o
 OBJS-$(CONFIG_HQX_DECODER) += hqx.o hqxvlc.o hqxdsp.o canopus.o
+OBJS-$(CONFIG_RZIP_DECODER)+= rzip.o rzipdec.o
+OBJS-$(CONFIG_RZIP_ENCODER)+= rzip.o rzipenc.o
 OBJS-$(CONFIG_HUFFYUV_DECODER) += huffyuv.o huffyuvdec.o
 OBJS-$(CONFIG_HUFFYUV_ENCODER) += huffyuv.o huffyuvenc.o
 OBJS-$(CONFIG_IDCIN_DECODER)   += idcinvideo.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 9f60d7c..7335b24 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -203,6 +203,7 @@ void avcodec_register_all(void)
 REGISTER_DECODER(HQ_HQA,hq_hqa);
 REGISTER_DECODER(HQX,   hqx);
 REGISTER_ENCDEC (HUFFYUV,   huffyuv);
+REGISTER_ENCDEC (RZIP,  rzip);
 REGISTER_DECODER(IDCIN, idcin);
 REGISTER_DECODER(IFF_ILBM,  iff_ilbm);
 REGISTER_DECODER(INDEO2,indeo2);
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5e36c94..33c3cd6 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -130,6 +130,7 @@ enum AVCodecID {
 AV_CODEC_ID_SVQ3,
 AV_CODEC_ID_DVVIDEO,
 AV_CODEC_ID_HUFFYUV,
+AV_CODEC_ID_RZIP,
 AV_CODEC_ID_CYUV,
 AV_CODEC_ID_H264,
 AV_CODEC_ID_INDEO3,
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 9cad3e6..616069b 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -188,6 +188,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
 },
 {
+.id= AV_CODEC_ID_RZIP,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "RZIP",
+.long_name = NULL_IF_CONFIG_SMALL("Rzip"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
+},
+{
 .id= AV_CODEC_ID_HUFFYUV,
 .type  = AVMEDIA_TYPE_VIDEO,
 .name  = "huffyuv",
diff --git a/libavcodec/rzip.c b/libavcodec/rzip.c
new file mode 100644
index 

Re: [FFmpeg-devel] [PATCH] AAC encoder: improve SF range utilization

[Hendrik Leppkes]

On Tue, Dec 1, 2015 at 7:35 AM, Claudio Freire  wrote:
> On Mon, Nov 30, 2015 at 1:04 PM, Hendrik Leppkes  wrote:
>> On Mon, Nov 30, 2015 at 4:50 PM, Claudio Freire  
>> wrote:
>>> On Mon, Nov 30, 2015 at 12:27 PM, Rostislav Pehlivanov
>>>  wrote:
 On Sun, 2015-11-29 at 16:54 -0300, Claudio Freire wrote:
> Before pushing this, I'd like some feedback,
> especially about
> the implementation of point 3. I'm not sure the AAC encoder
> setting the cutoff in the encoder context like this is legal or
> desirable.
 I think setting the cutoff is necessary. You can't avoid holes and yet
 keep a full bandwidth as you decrease bits unless you like the sound of 
 massive quantization errors.
>>>
>>> My point was more about whether a codec should write into the context
>>> struct like that or not. Basically an API technicality that's unclear
>>> to me.
>>>
>>
>> It seems slightly odd to write into that variable, since thats the
>> cutoff the user requests.
>> Maybe you can use/write into a private variable instead? ac3enc seems
>> to use a private variable for similar purposes.
>
> Attached patch does that.
>
> I'm far more comfortable with this implementation, so if all agree, I'll push.

This part looks good to me now, thanks! I'll leave the other parts for
atomnuker to judge. ;)

>
> On Mon, Nov 30, 2015 at 2:20 PM, Rostislav Pehlivanov
>  wrote:
>> On Mon, 2015-11-30 at 12:50 -0300, Claudio Freire wrote:
>>> Also I don't see how a static var would help or even be correct here.
>>> Perhaps you meant something else?
>> static uint8_t cond1 = param1 && param2;
>> static uint8_t cond2 = param3 && !param4;
>> ...etc
>> return cond1 && cond2;
>
> I didn't do that since it would not short circuit some terms that
> ought to be short-circuited.
>
> But I did split lines and it does read better. In fact, maybe that was
> all that was needed?
>
> ___
> 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] doc/filters/drawtext: fix centering example

[Andrey Utkin]

Signed-off-by: Andrey Utkin 
---
 doc/filters.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index fc71a99..06686bd 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -5605,7 +5605,7 @@ within the parameter list.
 @item
 Show the text at the center of the video frame:
 @example
-drawtext="fontsize=30:fontfile=FreeSerif.ttf:text='hello 
world':x=(w-text_w)/2:y=(h-text_h-line_h)/2"
+drawtext="fontsize=30:fontfile=FreeSerif.ttf:text='hello 
world':x=(w-text_w)/2:y=(h-text_h)/2"
 @end example
 
 @item
-- 
2.6.3

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

Re: [FFmpeg-devel] [PATCH] Fix sample_aspect_ratio computation for stereo matroska content.

[Aaron Colwell]

On Mon, Nov 30, 2015 at 4:35 PM wm4  wrote:

>
> I tried your patch, and it actually makes it work better (looks correct
> with the patch). The patch itself also LGTM.
>
>
Ok. Great. Thanks for the review. What do I need to do next to get this
checked in. I don't have commit access.

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

[FFmpeg-devel] [PATCH 8/9] avcodec/wavpackenc: use lrint instead of floor hack

[Ganesh Ajjanagadde]

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/wavpackenc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/wavpackenc.c b/libavcodec/wavpackenc.c
index 977bcf0..6a9b716 100644
--- a/libavcodec/wavpackenc.c
+++ b/libavcodec/wavpackenc.c
@@ -954,7 +954,7 @@ static void analyze_mono(WavPackEncodeContext *s, int32_t 
*samples, int do_sampl
 memcpy(s->sampleptrs[info.nterms + 1][0], s->sampleptrs[i][0], 
s->block_samples * 4);
 
 if (s->extra_flags & EXTRA_BRANCHES)
-recurse_mono(s, , 0, (int) floor(s->delta_decay + 0.5),
+recurse_mono(s, , 0, lrint(s->delta_decay),
  log2mono(s->sampleptrs[0][0], s->block_samples, 0));
 
 if (s->extra_flags & EXTRA_SORT_FIRST)
@@ -1773,7 +1773,7 @@ static void analyze_stereo(WavPackEncodeContext *s,
 memcpy(s->sampleptrs[info.nterms + 1][1], s->sampleptrs[i][1], 
s->block_samples * 4);
 
 if (s->extra_flags & EXTRA_BRANCHES)
-recurse_stereo(s, , 0, (int) floor(s->delta_decay + 0.5),
+recurse_stereo(s, , 0, lrint(s->delta_decay),
log2stereo(s->sampleptrs[0][0], s->sampleptrs[0][1],
   s->block_samples, 0));
 
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 9/9] avcodec/sonic: use lrint instead of floor hack

[Ganesh Ajjanagadde]

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/sonic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/sonic.c b/libavcodec/sonic.c
index 4ec7d89..0a848d1 100644
--- a/libavcodec/sonic.c
+++ b/libavcodec/sonic.c
@@ -537,7 +537,7 @@ static int modified_levinson_durbin(int *window, int 
window_entries,
 if (xx == 0.0)
 k = 0;
 else
-k = (int)(floor(-xy/xx * (double)LATTICE_FACTOR / 
(double)(tap_quant[i]) + 0.5));
+k = lrint(-xy/xx * LATTICE_FACTOR / tap_quant[i]);
 
 if (k > (LATTICE_FACTOR/tap_quant[i]))
 k = LATTICE_FACTOR/tap_quant[i];
-- 
2.6.2

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

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

[Ganesh Ajjanagadde]

On Tue, Dec 1, 2015 at 2:14 PM, Paul B Mahol  wrote:
> On 12/1/15, Nicolas George  wrote:
>> Le primidi 11 frimaire, an CCXXIV, Paul B Mahol a ecrit :
>>> Similar how its freed when no longer used.
>>
>> Please elaborate. I know the API, I do not see what you suggest.
>>
>> (Thanks for trimming.)
>>
>> Regards,
>
> After carefully looking at this functon, I see no leaking at all.

Care to elaborate on this? My question is: what happens when e.g
layouts get set and allocated/ref'ed correctly, but while trying to
allocate formats, ENOMEM occurs? Or in other words, where does the
formats get deallocated in such a case? And why does Coverity flag
these things?

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

Re: [FFmpeg-devel] [PATCH 3/4] avcodec/mpegaudio_tablegen: more dynamic table creation speedups

[Ganesh Ajjanagadde]

On Sat, Nov 28, 2015 at 4:47 PM, Ganesh Ajjanagadde  wrote:
> On Sat, Nov 28, 2015 at 4:35 PM, Derek Buitenhuis
>  wrote:
>> On 11/28/2015 9:26 PM, Derek Buitenhuis wrote:
>>> Changing all of them sounds fine to me.
>>
>> [21:31] <@ubitux> re: i%4 vs i&3; you should ask him to make sure the 
>> compiler is smart enough regarding the signess of i
>
> No idea, actually GCC even to this day has issues with signed vs unsigned.
>
> Trivial example (unrelated),
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 which is still
> open. Lesson for FFmpeg - make sure looping is done with int i instead
> of unsigned i. I have not done an extensive audit, but FFmpeg seems
> mostly good in this respect.
>
> So I will follow Derek's suggestion and use i & 3 uniformly here; I
> lack the energy to investigate and will err on the safe side wrt
> performance.

pushed with the i & 3.

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

Re: [FFmpeg-devel] [PATCH 1/4] avutil/tablegen: add tablegen libm compatibility shims

[Ganesh Ajjanagadde]

On Sat, Nov 28, 2015 at 4:23 PM, Ganesh Ajjanagadde  wrote:
> On Sat, Nov 28, 2015 at 3:19 PM, Derek Buitenhuis
>  wrote:
>> On 11/28/2015 7:51 PM, Ganesh Ajjanagadde wrote:
>>> In principle of course, e.g with more ifdefry, configure, or something
>>> of that sort. I do not believe this is what he meant.
>>
>> I will await his reply to clarify, then. Perhaps do not write so 
>> matter-of-factly.
>>
>>> In any case, the point is moot - the implementations are not broken -
>>> if they are, avutil/libm needs fixing as well.
>>
>> Now, yes. It would certainly be nice if this was noted somewhere in the 
>> patch notes
>> (not necessarily in the commit messages). There are quite a few threads on 
>> the list
>> from you now regarding tablegen, and it can be a pain in the butt / tedious 
>> to figure
>> out how the current version differs from the N others.
>
> I assumed from the cover letter that this supersedes all such prior
> stuff. Anyway, will attempt but can't guarantee improvements in
> future.
>
>>
 Anyway, shouldn't this patce dropped, since 
 79abf2d0ded860acf505de22c4f7a750e5e98446
 removed hardcoded tables anyway?
>>>
>>> No, if you actually read even the first line of the commit message,
>>> you can see it was only for aac, not for this patch series.
>>
>> Indeed, I misread, and missed the 'aac_'. You could certainly be less of
>> an ass about it, though.
>
> Sorry about that. Please do continue to call me out on such things; I
> do not like unpleasantness on ffmpeg-devel.

pushed, thanks

>
>>
>> - Derek
>> ___
>> 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 7/9] avcodec/mdct_template: use lrint instead of floor hack

[Ganesh Ajjanagadde]

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/mdct_template.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavcodec/mdct_template.c b/libavcodec/mdct_template.c
index e7e5f62..ecdeb54 100644
--- a/libavcodec/mdct_template.c
+++ b/libavcodec/mdct_template.c
@@ -23,6 +23,7 @@
 #include 
 #include "libavutil/common.h"
 #include "libavutil/mathematics.h"
+#include "libavutil/libm.h"
 #include "fft.h"
 #include "fft-internal.h"
 
@@ -82,8 +83,8 @@ av_cold int ff_mdct_init(FFTContext *s, int nbits, int 
inverse, double scale)
 for(i=0;itcos[i*tstep] = (FFTSample)floor(-cos(alpha) * 2147483648.0 + 0.5);
-s->tsin[i*tstep] = (FFTSample)floor(-sin(alpha) * 2147483648.0 + 0.5);
+s->tcos[i*tstep] = lrint(-cos(alpha) * 2147483648.0);
+s->tsin[i*tstep] = lrint(-sin(alpha) * 2147483648.0);
 #else
 s->tcos[i*tstep] = FIX15(-cos(alpha) * scale);
 s->tsin[i*tstep] = FIX15(-sin(alpha) * scale);
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 5/9] avcodec/cos_tablegen: use rint instead of floor hack

[Ganesh Ajjanagadde]

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/cos_tablegen.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/cos_tablegen.c b/libavcodec/cos_tablegen.c
index dbd0cc0..332216c 100644
--- a/libavcodec/cos_tablegen.c
+++ b/libavcodec/cos_tablegen.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 
+#include "libavutil/libm.h"
 #include "libavutil/mathematics.h"
 
 #define BITS 16
@@ -40,10 +41,9 @@ static int clip_f15(int v)
 static void printval(double val, int fixed)
 {
 if (fixed) {
-/* lrint() isn't always available, so round and cast manually. */
 double new_val = val * (double) (1 << 15);
 
-new_val = new_val >= 0 ? floor(new_val + 0.5) : ceil(new_val - 0.5);
+new_val = rint(new_val);
 
 printf(" "FIXEDFMT",", clip_f15((long int) new_val));
 } else {
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 6/9] avcodec/kbdwin: use lrint instead of floor hack

[Ganesh Ajjanagadde]

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/kbdwin.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/kbdwin.c b/libavcodec/kbdwin.c
index bf32aeb..77d5e2b 100644
--- a/libavcodec/kbdwin.c
+++ b/libavcodec/kbdwin.c
@@ -17,6 +17,7 @@
  */
 
 #include "libavutil/avassert.h"
+#include "libavutil/libm.h"
 #include "libavutil/mathematics.h"
 #include "libavutil/attributes.h"
 #include "kbdwin.h"
@@ -53,5 +54,5 @@ av_cold void ff_kbd_window_init_fixed(int32_t *window, float 
alpha, int n)
 
 ff_kbd_window_init(local_window, alpha, n);
 for (i = 0; i < n; i++)
-window[i] = (int)floor(2147483647.0 * local_window[i] + 0.5);
+window[i] = lrint(2147483647.0 * local_window[i]);
 }
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH 2/4] avcodec/mpegaudio_tablegen: speed up dynamic table creation

[Ganesh Ajjanagadde]

On Sat, Nov 28, 2015 at 12:03 PM, Ganesh Ajjanagadde
 wrote:
> This does some miscellaneous stuff mainly avoiding the usage of pow to
> achieve significant speedups. This is not speed critical, but is
> unnecessary latency and cycles wasted for a user.
>
> All tables tested and are identical to the old ones
> (bit-exact even in floating point case).
>
> Sample benchmark (x86-64, Haswell, GNU/Linux):
> old:
> 102329530 decicycles in mpegaudio_tableinit,   1 runs,  0 skips
>
> new:
> 34111900 decicycles in mpegaudio_tableinit,   1 runs,  0 skips
>
> Reviewed-by: Ronald S. Bultje 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/mpegaudio_tablegen.c |  1 +
>  libavcodec/mpegaudio_tablegen.h | 19 +--
>  2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/mpegaudio_tablegen.c b/libavcodec/mpegaudio_tablegen.c
> index 90c9de4..9a9bb4d 100644
> --- a/libavcodec/mpegaudio_tablegen.c
> +++ b/libavcodec/mpegaudio_tablegen.c
> @@ -23,6 +23,7 @@
>  #include 
>  #define CONFIG_HARDCODED_TABLES 0
>  #include "mpegaudio_tablegen.h"
> +#include "libavutil/tablegen.h"
>  #include "tableprint.h"
>
>  int main(void)
> diff --git a/libavcodec/mpegaudio_tablegen.h b/libavcodec/mpegaudio_tablegen.h
> index 86b2cd3..dd67a09 100644
> --- a/libavcodec/mpegaudio_tablegen.h
> +++ b/libavcodec/mpegaudio_tablegen.h
> @@ -45,12 +45,21 @@ static float expval_table_float[512][16];
>  static av_cold void mpegaudio_tableinit(void)
>  {
>  int i, value, exponent;
> +double exp2_lut[4] = {
> +1., /* 2 ^ (0 * 0.25) */
> +1.18920711500272106672, /* 2 ^ (1 * 0.25) */
> +M_SQRT2   , /* 2 ^ (2 * 0.25) */
> +1.68179283050742908606, /* 2 ^ (3 * 0.25) */
> +};
> +double cbrt_lut[16];
> +for (i = 0; i < 16; ++i)
> +cbrt_lut[i] = cbrt(i);
> +
>  for (i = 1; i < TABLE_4_3_SIZE; i++) {
>  double value = i / 4;
>  double f, fm;
>  int e, m;
> -/* cbrtf() isn't available on all systems, so we use powf(). */
> -f  = value / IMDCT_SCALAR * pow(value, 1.0 / 3.0) * pow(2, (i & 3) * 
> 0.25);
> +f  = value / IMDCT_SCALAR * cbrt(value) * exp2_lut[i & 3];
>  fm = frexp(f, );
>  m  = (uint32_t)(fm * (1LL << 31) + 0.5);
>  e += FRAC_BITS - 31 + 5 - 100;
> @@ -61,10 +70,8 @@ static av_cold void mpegaudio_tableinit(void)
>  }
>  for (exponent = 0; exponent < 512; exponent++) {
>  for (value = 0; value < 16; value++) {
> -/* cbrtf() isn't available on all systems, so we use powf(). */
> -double f = (double)value * pow(value, 1.0 / 3.0) * pow(2, 
> (exponent - 400) * 0.25 + FRAC_BITS + 5) / IMDCT_SCALAR;
> -/* llrint() isn't always available, so round and cast manually. 
> */
> -expval_table_fixed[exponent][value] = (long long int) (f < 
> 0x ? floor(f + 0.5) : 0x);
> +double f = value * cbrt_lut[value] * pow(2, (exponent - 400) * 
> 0.25 + FRAC_BITS + 5) / IMDCT_SCALAR;
> +expval_table_fixed[exponent][value] = (f < 0x ? 
> llrint(f) : 0x);
>  expval_table_float[exponent][value] = f;
>  }
>  exp_table_fixed[exponent] = expval_table_fixed[exponent][1];
> --
> 2.6.2
>

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

Re: [FFmpeg-devel] [PATCH 4/4] avcodec/cbrt_tablegen: speed up dynamic table creation

[Ganesh Ajjanagadde]

On Sat, Nov 28, 2015 at 12:03 PM, Ganesh Ajjanagadde
 wrote:
> On systems having cbrt, there is no reason to use the slow pow function.
>
> Sample benchmark (x86-64, Haswell, GNU/Linux):
> new:
> 5124920 decicycles in cbrt_tableinit,   1 runs,  0 skips
>
> old:
> 12321680 decicycles in cbrt_tableinit,   1 runs,  0 skips
>
> Reviewed-by: Ronald S. Bultje 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/cbrt_tablegen.h  | 5 ++---
>  libavcodec/cbrt_tablegen_template.c | 1 +
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/cbrt_tablegen.h b/libavcodec/cbrt_tablegen.h
> index 27a3e3a..59b5a1d 100644
> --- a/libavcodec/cbrt_tablegen.h
> +++ b/libavcodec/cbrt_tablegen.h
> @@ -29,7 +29,7 @@
>  #include "libavcodec/aac_defines.h"
>
>  #if USE_FIXED
> -#define CBRT(x) (int)floor((x).f * 8192 + 0.5)
> +#define CBRT(x) lrint((x).f * 8192)
>  #else
>  #define CBRT(x) x.i
>  #endif
> @@ -49,13 +49,12 @@ static av_cold void AAC_RENAME(cbrt_tableinit)(void)
>  {
>  if (!cbrt_tab[(1<<13) - 1]) {
>  int i;
> -/* cbrtf() isn't available on all systems, so we use powf(). */
>  for (i = 0; i < 1<<13; i++) {
>  union {
>  float f;
>  uint32_t i;
>  } f;
> -f.f = pow(i, 1.0 / 3.0) * i;
> +f.f = cbrt(i) * i;
>  cbrt_tab[i] = CBRT(f);
>  }
>  }
> diff --git a/libavcodec/cbrt_tablegen_template.c 
> b/libavcodec/cbrt_tablegen_template.c
> index 9dd2cf5..1d71d34 100644
> --- a/libavcodec/cbrt_tablegen_template.c
> +++ b/libavcodec/cbrt_tablegen_template.c
> @@ -23,6 +23,7 @@
>  #include 
>  #define CONFIG_HARDCODED_TABLES 0
>  #include "cbrt_tablegen.h"
> +#include "libavutil/tablegen.h"
>  #include "tableprint.h"
>
>  int main(void)
> --
> 2.6.2
>

pushed, identical stand-alone patch reviewed by Ronald.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/filters/drawtext: fix centering example

[Lou Logan]

On Tue,  1 Dec 2015 21:15:53 +0200, Andrey Utkin wrote:

> Signed-off-by: Andrey Utkin 
> ---
>  doc/filters.texi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM and applied.

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

[FFmpeg-devel] [PATCH 4/9] avfilter/af_flanger: use rint instead of floor hack

[Ganesh Ajjanagadde]

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/af_flanger.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/af_flanger.c b/libavfilter/af_flanger.c
index f8ec830..a92367c 100644
--- a/libavfilter/af_flanger.c
+++ b/libavfilter/af_flanger.c
@@ -130,7 +130,7 @@ static int config_input(AVFilterLink *inlink)
 return AVERROR(ENOMEM);
 
 ff_generate_wave_table(s->wave_shape, AV_SAMPLE_FMT_FLT, s->lfo, 
s->lfo_length,
-   floor(s->delay_min * inlink->sample_rate + 0.5),
+   rint(s->delay_min * inlink->sample_rate),
s->max_samples - 2., 3 * M_PI_2);
 
 return av_samples_alloc_array_and_samples(>delay_buffer, NULL,
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 2/9] avfilter/vf_perspective: use lrint instead of floor hack

[Ganesh Ajjanagadde]

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/vf_perspective.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavfilter/vf_perspective.c b/libavfilter/vf_perspective.c
index 970870c..13053f1 100644
--- a/libavfilter/vf_perspective.c
+++ b/libavfilter/vf_perspective.c
@@ -213,10 +213,10 @@ static int config_input(AVFilterLink *inlink)
 for (x = 0; x < w; x++){
 int u, v;
 
-u = (int)floor(SUB_PIXELS * (x0 * x + x1 * y + x2) /
-(x6 * x + x7 * y + x8) + 0.5);
-v = (int)floor(SUB_PIXELS * (x3 * x + x4 * y + x5) /
-(x6 * x + x7 * y + x8) + 0.5);
+u =  lrint(SUB_PIXELS * (x0 * x + x1 * y + x2) /
+(x6 * x + x7 * y + x8));
+v =  lrint(SUB_PIXELS * (x3 * x + x4 * y + x5) /
+(x6 * x + x7 * y + x8));
 
 s->pv[x + y * w][0] = u;
 s->pv[x + y * w][1] = v;
@@ -235,7 +235,7 @@ static int config_input(AVFilterLink *inlink)
 sum += temp[j];
 
 for (j = 0; j < 4; j++)
-s->coeff[i][j] = (int)floor((1 << COEFF_BITS) * temp[j] / sum + 
0.5);
+s->coeff[i][j] = lrint((1 << COEFF_BITS) * temp[j] / sum);
 }
 
 return 0;
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 3/9] avfilter/af_stereotools: use lrint instead of floor hack

[Ganesh Ajjanagadde]

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/af_stereotools.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavfilter/af_stereotools.c b/libavfilter/af_stereotools.c
index a22efb0..e878824 100644
--- a/libavfilter/af_stereotools.c
+++ b/libavfilter/af_stereotools.c
@@ -139,10 +139,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 const double sc_level = s->sc_level;
 const double delay = s->delay;
 const int length = s->length;
-const int mute_l = floor(s->mute_l + 0.5);
-const int mute_r = floor(s->mute_r + 0.5);
-const int phase_l = floor(s->phase_l + 0.5);
-const int phase_r = floor(s->phase_r + 0.5);
+const int mute_l = lrint(s->mute_l);
+const int mute_r = lrint(s->mute_r);
+const int phase_l = lrint(s->phase_l);
+const int phase_r = lrint(s->phase_r);
 double *buffer = s->buffer;
 AVFrame *out;
 double *dst;
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH 3/4] avcodec/ppc/fdctdsp: use more accurate constants

[Ganesh Ajjanagadde]

On Mon, Nov 16, 2015 at 1:58 PM, Ganesh Ajjanagadde  wrote:
> On Mon, Nov 16, 2015 at 1:20 PM, Hendrik Leppkes  wrote:
>> On Mon, Nov 16, 2015 at 6:24 PM, Ganesh Ajjanagadde  wrote:
>>> On Mon, Nov 16, 2015 at 9:48 AM, Daniel Serpell  wrote:
 Hi!,

 El Fri, Nov 13, 2015 at 11:42:30AM -0500, Ganesh Ajjanagadde escribio:
> Whoever wrote this stuff had a pretty bad libm - digits differ pretty
> quickly.

 They where correctly rounded to 24bit precision. I don't know if that
 was intentional, so I can't comment on the correctness of the patch.
>>>
>>> Unless I am off here, doing things at 24 bits makes very little sense:
>>> float itself offers 32 bits
>>
>> Actually floats offer 23-bits of precision for the significand (with 8
>> for mantissa and one sign bit) - 7-8 digits, so any more precision
>> than that couldn't be stored accurately anymore, so when using single
>> precision like this code, more precision is not needed.
>
> Point taken. However, the general remark still applies: precision is
> being lost unnecessarily at an intermediate computation stage since it
> is anyway a static computation.
>
>> Maybe it was even specifically wanted to have values that are
>> represented accurately, but I do not know the history of this code
>> either.

pushed

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

Re: [FFmpeg-devel] [PATCH 05/10] avfilter/avf_showcqt: use hypot()

[Ganesh Ajjanagadde]

On Mon, Nov 30, 2015 at 11:15 PM, Muhammad Faiz  wrote:
> On Sun, Nov 22, 2015 at 9:05 AM, Ganesh Ajjanagadde
>  wrote:
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavfilter/avf_showcqt.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
>> index d6e2928..cd90c88 100644
>> --- a/libavfilter/avf_showcqt.c
>> +++ b/libavfilter/avf_showcqt.c
>> @@ -170,7 +170,7 @@ static double a_weighting(void *p, double f)
>>  static double b_weighting(void *p, double f)
>>  {
>>  double ret = 12200.0*12200.0 * (f*f*f);
>> -ret /= (f*f + 20.6*20.6) * (f*f + 12200.0*12200.0) * sqrt(f*f + 
>> 158.5*158.5);
>> +ret /= (f*f + 20.6*20.6) * (f*f + 12200.0*12200.0) * hypot(f, 158.5);
>>  return ret;
>>  }
>>
>
> I prefer sqrt in this code, because extra precision and range is not required.

I assume by this you don't consider this a readability improvement
either. Since you are the maintainer ultimately, patch dropped.
Thanks.

>
> Thank's.
> ___
> 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 06/11] avfilter/af_volumedetect: use log10 instead of hardcoded constant

[Ganesh Ajjanagadde]

On Sat, Oct 31, 2015 at 6:12 PM, Ganesh Ajjanagadde
 wrote:
> On Sat, Oct 31, 2015 at 6:02 PM, Mark Harris  wrote:
>> On Wed, Oct 28, 2015 at 9:20 PM, Ganesh Ajjanagadde
>>  wrote:
>>> This is likely more precise and conveys the intent better.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavfilter/af_volumedetect.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
>>> index 01f24ba..ad5fef3 100644
>>> --- a/libavfilter/af_volumedetect.c
>>> +++ b/libavfilter/af_volumedetect.c
>>> @@ -78,7 +78,7 @@ static inline double logdb(uint64_t v)
>>>  double d = v / (double)(0x8000 * 0x8000);
>>>  if (!v)
>>>  return MAX_DB;
>>> -return log(d) * -4.3429448190325182765112891891660508229; /* 
>>> -10/log(10) */
>>> +return log10(d) * 10;
>>
>> Wouldn't this reverse the sign of the result?
>
> Missed the sign, of course you are right. Thanks. I dropped this stuff
> on my end due to the whole log episode, and don't mind if it gets
> included or not. Will leave it to the maintainer to decide.

pushed, thanks.

>
>>
>>>  }
>>>
>>>  static void print_stats(AVFilterContext *ctx)
>>> --
>>> 2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] AAC encoder: improve SF range utilization

[Rostislav Pehlivanov]

On Tue, 2015-12-01 at 03:35 -0300, Claudio Freire wrote:
> 
> Attached patch does that.
> 
Went over the patch, everything me and other people said has been
addressed, so LGTM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/9] improve rounding across FFmpeg

[Lou Logan]

On Tue,  1 Dec 2015 19:27:49 -0500, Ganesh Ajjanagadde wrote:

> The slowness comes from the generate code, e.g llrint compiles down to
> a single asm instruction cvttsd2si, while floor(x + 0.5) needs to do
> multiple things.

How much slower is it?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [patch] AV_CH_LAYOUT_6POINT1_BACK not reachable in parsing

[Martin Cracauer]

[bug submit webpage seems to be down, sending directly]

Trying to make heads and tails out of DTS 6.1 I can across this typo.

I also noticed that this wiki page is incorrect or misleading, the
channel order for 6.1 given does not match the source code.  At the
least it should be clarified that the layout given does not apply to
DTS.  https://trac.ffmpeg.org/wiki/AudioChannelManipulation

Thanks
Martin

diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 601c7e6..26c87c9 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -94,7 +94,7 @@ static const struct {
 { "6.0(front)",  6,  AV_CH_LAYOUT_6POINT0_FRONT },
 { "hexagonal",   6,  AV_CH_LAYOUT_HEXAGONAL },
 { "6.1", 7,  AV_CH_LAYOUT_6POINT1 },
-{ "6.1", 7,  AV_CH_LAYOUT_6POINT1_BACK },
+{ "6.1(back)",   7,  AV_CH_LAYOUT_6POINT1_BACK },
 { "6.1(front)",  7,  AV_CH_LAYOUT_6POINT1_FRONT },
 { "7.0", 7,  AV_CH_LAYOUT_7POINT0 },
 { "7.0(front)",  7,  AV_CH_LAYOUT_7POINT0_FRONT },

-- 
%%%
Martin Cracauer    http://www.cons.org/cracauer/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/9] avfilter/vsrc_mptestsrc: use lrint instead of floor hack

[Ganesh Ajjanagadde]

lrint is faster, and is more consistent across the codebase.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/vsrc_mptestsrc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vsrc_mptestsrc.c b/libavfilter/vsrc_mptestsrc.c
index 668a001..1cdd3a4 100644
--- a/libavfilter/vsrc_mptestsrc.c
+++ b/libavfilter/vsrc_mptestsrc.c
@@ -121,7 +121,7 @@ static void idct(uint8_t *dst, int dst_linesize, int 
src[64])
 for (k = 0; k < 8; k++)
 sum += c[k*8+i]*tmp[8*k+j];
 
-dst[dst_linesize*i + j] = av_clip_uint8((int)floor(sum+0.5));
+dst[dst_linesize*i + j] = av_clip_uint8(lrint(sum));
 }
 }
 }
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 0/9] improve rounding across FFmpeg

[Ganesh Ajjanagadde]

Currently, there are numerous instances where the appropriate libm rounding
functions lrint, llrint, rint, etc are not used and instead ad-hoc, slow, and 
sometimes
risky floor(x + 0.5) and the like are being used. The risk comes from the fact
that such a thing is broken for negative values and values close to the 0.5 
fractional
part boundary. The ad-hoc nature comes from the fact that we anyway have compat
hacks in avutil/libm for broken platforms, and they are not being used. The
slowness comes from the generate code, e.g llrint compiles down to a single asm
instruction cvttsd2si, while floor(x + 0.5) needs to do multiple things.

Note that the audit may have missed some things; essentially this was found by
doing a grep for 'floor' across the codebase and checking.

Patches split per file.

Ganesh Ajjanagadde (9):
  avfilter/vsrc_mptestsrc: use lrint instead of floor hack
  avfilter/vf_perspective: use lrint instead of floor hack
  avfilter/af_stereotools: use lrint instead of floor hack
  avfilter/af_flanger: use rint instead of floor hack
  avcodec/cos_tablegen: use rint instead of floor hack
  avcodec/kbdwin: use lrint instead of floor hack
  avcodec/mdct_template: use lrint instead of floor hack
  avcodec/wavpackenc: use lrint instead of floor hack
  avcodec/sonic: use lrint instead of floor hack

 libavcodec/cos_tablegen.c|  4 ++--
 libavcodec/kbdwin.c  |  3 ++-
 libavcodec/mdct_template.c   |  5 +++--
 libavcodec/sonic.c   |  2 +-
 libavcodec/wavpackenc.c  |  4 ++--
 libavfilter/af_flanger.c |  2 +-
 libavfilter/af_stereotools.c |  8 
 libavfilter/vf_perspective.c | 10 +-
 libavfilter/vsrc_mptestsrc.c |  2 +-
 9 files changed, 21 insertions(+), 19 deletions(-)

-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH 0/9] improve rounding across FFmpeg

[Ganesh Ajjanagadde]

On Tue, Dec 1, 2015 at 7:39 PM, Lou Logan  wrote:
> On Tue,  1 Dec 2015 19:27:49 -0500, Ganesh Ajjanagadde wrote:
>
>> The slowness comes from the generate code, e.g llrint compiles down to
>> a single asm instruction cvttsd2si, while floor(x + 0.5) needs to do
>> multiple things.
>
> How much slower is it?

I don't know and honestly don't care myself as it is not really the
selling point of the patch since AFAIK these are not performance
critical. The point is really moot - I merely claimed that it is
slower, which is obvious from the asm. The more serious reasons for
avoiding it are also given in the message.

> ___
> 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] [PATCHv2] avutil/crc: avoid needless space wastage of hardcoded crc table

[James Almer]

On 12/1/2015 9:53 PM, Ganesh Ajjanagadde wrote:
> There was no reason AFAIK for making AV_CRC_24_IEEE 12. This simply
> resulted in wasted space under --enable-hardcoded-tables:
> dynamic: 1318672 libavutil/libavutil.so.55
> old: 1330680 libavutil/libavutil.so.55
> new: 1326488 libavutil/libavutil.so.55
> 
> Minor version number is bumped, with ifdefry due to API breakage.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/crc.h | 4 
>  libavutil/version.h | 5 -
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/libavutil/crc.h b/libavutil/crc.h
> index e86bf1d..9af4421 100644
> --- a/libavutil/crc.h
> +++ b/libavutil/crc.h
> @@ -40,7 +40,11 @@ typedef enum {
>  AV_CRC_32_IEEE,
>  AV_CRC_32_IEEE_LE,  /*< reversed bitorder version of AV_CRC_32_IEEE */
>  AV_CRC_16_ANSI_LE,  /*< reversed bitorder version of AV_CRC_16_ANSI */
> +#if FF_API_CRC_BIG_TABLE
>  AV_CRC_24_IEEE = 12,
> +#else
> +AV_CRC_24_IEEE,
> +#endif /* FF_API_CRC_BIG_TABLE */
>  AV_CRC_MAX, /*< Not part of public API! Do not use outside 
> libavutil. */
>  }AVCRCId;
>  
> diff --git a/libavutil/version.h b/libavutil/version.h
> index e0ddfd2..67e778a 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -56,7 +56,7 @@
>   */
>  
>  #define LIBAVUTIL_VERSION_MAJOR  55
> -#define LIBAVUTIL_VERSION_MINOR   9
> +#define LIBAVUTIL_VERSION_MINOR  10
>  #define LIBAVUTIL_VERSION_MICRO 100
>  
>  #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
> @@ -108,6 +108,9 @@
>  #ifndef FF_API_ERROR_FRAME
>  #define FF_API_ERROR_FRAME  (LIBAVUTIL_VERSION_MAJOR < 56)
>  #endif
> +#ifndef FF_API_CRC_BIG_TABLE
> +#define FF_API_CRC_BIG_TABLE(LIBAVUTIL_VERSION_INT < 
> AV_VERSION_INT(55, 10, 100))

This is wrong. With this check, FF_API_CRC_BIG_TABLE is false. The point
of these FF_API defines is to make sure they are true until the next major
bump. That's why you use LIBAVUTIL_VERSION_MAJOR < 56, like it's being
done for the rest.

> +#endif
>  
>  
>  /**
> 

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

Re: [FFmpeg-devel] [PATCH] avformat/mp3dec: prefer "fast_seek" to TOC seek for CBR files.

[Michael Niedermayer]

On Tue, Dec 01, 2015 at 10:47:53AM -0800, Chris Cunningham wrote:
> Thanks wm4, next patch will fix that declaration.
> 
> Michael, any concerns?

iam fine with the patch


>
> On Mon, Nov 30, 2015 at 2:51 PM, wm4  wrote:
[...]
> > Other than that LGTM.

wm4, your replies are missing from the mailing list
(and i dont know what "Other" was meant for so dunno if i should apply
 or wait)

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

Re: [FFmpeg-devel] [PATCHv2] avutil/crc: avoid needless space wastage of hardcoded crc table

[Ganesh Ajjanagadde]

On Tue, Dec 1, 2015 at 8:08 PM, James Almer  wrote:
> On 12/1/2015 9:53 PM, Ganesh Ajjanagadde wrote:
>> There was no reason AFAIK for making AV_CRC_24_IEEE 12. This simply
>> resulted in wasted space under --enable-hardcoded-tables:
>> dynamic: 1318672 libavutil/libavutil.so.55
>> old: 1330680 libavutil/libavutil.so.55
>> new: 1326488 libavutil/libavutil.so.55
>>
>> Minor version number is bumped, with ifdefry due to API breakage.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavutil/crc.h | 4 
>>  libavutil/version.h | 5 -
>>  2 files changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavutil/crc.h b/libavutil/crc.h
>> index e86bf1d..9af4421 100644
>> --- a/libavutil/crc.h
>> +++ b/libavutil/crc.h
>> @@ -40,7 +40,11 @@ typedef enum {
>>  AV_CRC_32_IEEE,
>>  AV_CRC_32_IEEE_LE,  /*< reversed bitorder version of AV_CRC_32_IEEE */
>>  AV_CRC_16_ANSI_LE,  /*< reversed bitorder version of AV_CRC_16_ANSI */
>> +#if FF_API_CRC_BIG_TABLE
>>  AV_CRC_24_IEEE = 12,
>> +#else
>> +AV_CRC_24_IEEE,
>> +#endif /* FF_API_CRC_BIG_TABLE */
>>  AV_CRC_MAX, /*< Not part of public API! Do not use outside 
>> libavutil. */
>>  }AVCRCId;
>>
>> diff --git a/libavutil/version.h b/libavutil/version.h
>> index e0ddfd2..67e778a 100644
>> --- a/libavutil/version.h
>> +++ b/libavutil/version.h
>> @@ -56,7 +56,7 @@
>>   */
>>
>>  #define LIBAVUTIL_VERSION_MAJOR  55
>> -#define LIBAVUTIL_VERSION_MINOR   9
>> +#define LIBAVUTIL_VERSION_MINOR  10
>>  #define LIBAVUTIL_VERSION_MICRO 100
>>
>>  #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
>> @@ -108,6 +108,9 @@
>>  #ifndef FF_API_ERROR_FRAME
>>  #define FF_API_ERROR_FRAME  (LIBAVUTIL_VERSION_MAJOR < 56)
>>  #endif
>> +#ifndef FF_API_CRC_BIG_TABLE
>> +#define FF_API_CRC_BIG_TABLE(LIBAVUTIL_VERSION_INT < 
>> AV_VERSION_INT(55, 10, 100))
>
> This is wrong. With this check, FF_API_CRC_BIG_TABLE is false. The point
> of these FF_API defines is to make sure they are true until the next major
> bump. That's why you use LIBAVUTIL_VERSION_MAJOR < 56, like it's being
> done for the rest.

Finally getting a sense for these things, thanks. Barring that, does
it look fine?

>
>> +#endif
>>
>>
>>  /**
>>
>
> ___
> 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] AAC encoder: improve SF range utilization

[Michael Niedermayer]

On Tue, Dec 01, 2015 at 03:35:40AM -0300, Claudio Freire wrote:
> On Mon, Nov 30, 2015 at 1:04 PM, Hendrik Leppkes  wrote:
> > On Mon, Nov 30, 2015 at 4:50 PM, Claudio Freire  
> > wrote:
> >> On Mon, Nov 30, 2015 at 12:27 PM, Rostislav Pehlivanov
> >>  wrote:
> >>> On Sun, 2015-11-29 at 16:54 -0300, Claudio Freire wrote:
>  Before pushing this, I'd like some feedback,
>  especially about
>  the implementation of point 3. I'm not sure the AAC encoder
>  setting the cutoff in the encoder context like this is legal or
>  desirable.
> >>> I think setting the cutoff is necessary. You can't avoid holes and yet
> >>> keep a full bandwidth as you decrease bits unless you like the sound of 
> >>> massive quantization errors.
> >>
> >> My point was more about whether a codec should write into the context
> >> struct like that or not. Basically an API technicality that's unclear
> >> to me.
> >>
> >
> > It seems slightly odd to write into that variable, since thats the
> > cutoff the user requests.
> > Maybe you can use/write into a private variable instead? ac3enc seems
> > to use a private variable for similar purposes.
> 
> Attached patch does that.
> 
> I'm far more comfortable with this implementation, so if all agree, I'll push.
> 
> On Mon, Nov 30, 2015 at 2:20 PM, Rostislav Pehlivanov
>  wrote:
> > On Mon, 2015-11-30 at 12:50 -0300, Claudio Freire wrote:
> >> Also I don't see how a static var would help or even be correct here.
> >> Perhaps you meant something else?
> > static uint8_t cond1 = param1 && param2;
> > static uint8_t cond2 = param3 && !param4;
> > ...etc
> > return cond1 && cond2;
> 
> I didn't do that since it would not short circuit some terms that
> ought to be short-circuited.
> 
> But I did split lines and it does read better. In fact, maybe that was
> all that was needed?

>  libavcodec/aaccoder.c |   60 --
>  libavcodec/aaccoder_twoloop.h |  136 
> --
>  libavcodec/aacenc.c   |2 
>  libavcodec/aacenc_is.c|   11 ++-
>  libavcodec/aacenc_utils.h |   63 +++
>  libavcodec/aacpsy.c   |   20 --
>  libavcodec/psymodel.c |1 
>  libavcodec/psymodel.h |1 
>  tests/fate/aac.mak|   18 ++---
>  9 files changed, 231 insertions(+), 81 deletions(-)
> 404ff616bb267619be431a7c45afa4db82070b65  
> 0001-AAC-encoder-improve-SF-range-utilization.patch

some stuff in mips will need to be updated by someone or disabled
after this is pushed:
CC  libavcodec/aacpsy.o
/ffmpeg/libavcodec/aacpsy.c: In function ‘psy_3gpp_analyze_channel’:
/ffmpeg/libavcodec/aacpsy.c:666: error: too many arguments to function 
‘calc_thr_3gpp_mips’
make: *** [libavcodec/aacpsy.o] Error 1
make: Target `all' not remade because of errors.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCHv2] avutil/crc: avoid needless space wastage of hardcoded crc table

[Ganesh Ajjanagadde]

On Tue, Dec 1, 2015 at 8:38 PM, James Almer  wrote:
> On 12/1/2015 10:35 PM, Ganesh Ajjanagadde wrote:
>> On Tue, Dec 1, 2015 at 8:08 PM, James Almer  wrote:
>>> On 12/1/2015 9:53 PM, Ganesh Ajjanagadde wrote:
 There was no reason AFAIK for making AV_CRC_24_IEEE 12. This simply
 resulted in wasted space under --enable-hardcoded-tables:
 dynamic: 1318672 libavutil/libavutil.so.55
 old: 1330680 libavutil/libavutil.so.55
 new: 1326488 libavutil/libavutil.so.55

 Minor version number is bumped, with ifdefry due to API breakage.

 Signed-off-by: Ganesh Ajjanagadde 
 ---
  libavutil/crc.h | 4 
  libavutil/version.h | 5 -
  2 files changed, 8 insertions(+), 1 deletion(-)

 diff --git a/libavutil/crc.h b/libavutil/crc.h
 index e86bf1d..9af4421 100644
 --- a/libavutil/crc.h
 +++ b/libavutil/crc.h
 @@ -40,7 +40,11 @@ typedef enum {
  AV_CRC_32_IEEE,
  AV_CRC_32_IEEE_LE,  /*< reversed bitorder version of AV_CRC_32_IEEE */
  AV_CRC_16_ANSI_LE,  /*< reversed bitorder version of AV_CRC_16_ANSI */
 +#if FF_API_CRC_BIG_TABLE
  AV_CRC_24_IEEE = 12,
 +#else
 +AV_CRC_24_IEEE,
 +#endif /* FF_API_CRC_BIG_TABLE */
  AV_CRC_MAX, /*< Not part of public API! Do not use outside 
 libavutil. */
  }AVCRCId;

 diff --git a/libavutil/version.h b/libavutil/version.h
 index e0ddfd2..67e778a 100644
 --- a/libavutil/version.h
 +++ b/libavutil/version.h
 @@ -56,7 +56,7 @@
   */

  #define LIBAVUTIL_VERSION_MAJOR  55
 -#define LIBAVUTIL_VERSION_MINOR   9
 +#define LIBAVUTIL_VERSION_MINOR  10
  #define LIBAVUTIL_VERSION_MICRO 100

  #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
 @@ -108,6 +108,9 @@
  #ifndef FF_API_ERROR_FRAME
  #define FF_API_ERROR_FRAME  (LIBAVUTIL_VERSION_MAJOR < 56)
  #endif
 +#ifndef FF_API_CRC_BIG_TABLE
 +#define FF_API_CRC_BIG_TABLE(LIBAVUTIL_VERSION_INT < 
 AV_VERSION_INT(55, 10, 100))
>>>
>>> This is wrong. With this check, FF_API_CRC_BIG_TABLE is false. The point
>>> of these FF_API defines is to make sure they are true until the next major
>>> bump. That's why you use LIBAVUTIL_VERSION_MAJOR < 56, like it's being
>>> done for the rest.
>>
>> Finally getting a sense for these things, thanks. Barring that, does
>> it look fine?
>
> Yes. You can also skip bumping minor. You're scheduling a change for the next
> major bump and not making any changes with immediate effects, so a minor bump
> is not necessary.

Would like to ask for comments regarding always hard or always soft
tables. Clearly, with this change (to be pushed soon), the space cost
of hardcoded tables is reduced once we do a major bump, and the
overhead of --enable-hardcoded-tables here is ~8 kB, down from ~ 12
kB.

I personally have a very slight preference for runtime tables here
(the default configure), since the runtime generation code anyway
needs to be present for nonstandard crc's but am definitely ok with
hardcoded as well. In any case, as the size is small, we should be
able to come to a decision here, and not continue to be on the fence
for this one unlike e.g mpegaudio_tablegen.

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

Re: [FFmpeg-devel] [PATCH 2/9] avfilter/vf_perspective: use lrint instead of floor hack

[Michael Niedermayer]

On Tue, Dec 01, 2015 at 07:27:51PM -0500, Ganesh Ajjanagadde wrote:
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavfilter/vf_perspective.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

should be ok

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

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


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

Re: [FFmpeg-devel] [PATCH] AAC encoder: improve SF range utilization

[Claudio Freire]

On Tue, Dec 1, 2015 at 10:47 PM, Michael Niedermayer  wrote:
>>  libavcodec/aaccoder.c |   60 --
>>  libavcodec/aaccoder_twoloop.h |  136 
>> --
>>  libavcodec/aacenc.c   |2
>>  libavcodec/aacenc_is.c|   11 ++-
>>  libavcodec/aacenc_utils.h |   63 +++
>>  libavcodec/aacpsy.c   |   20 --
>>  libavcodec/psymodel.c |1
>>  libavcodec/psymodel.h |1
>>  tests/fate/aac.mak|   18 ++---
>>  9 files changed, 231 insertions(+), 81 deletions(-)
>> 404ff616bb267619be431a7c45afa4db82070b65  
>> 0001-AAC-encoder-improve-SF-range-utilization.patch
>
> some stuff in mips will need to be updated by someone or disabled
> after this is pushed:
> CC  libavcodec/aacpsy.o
> /ffmpeg/libavcodec/aacpsy.c: In function ‘psy_3gpp_analyze_channel’:
> /ffmpeg/libavcodec/aacpsy.c:666: error: too many arguments to function 
> ‘calc_thr_3gpp_mips’
> make: *** [libavcodec/aacpsy.o] Error 1
> make: Target `all' not remade because of errors.


Oh, didn't realize mips had an alternative calc_thr_3gpp.

I'll see about updating it as I push.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] ffprobe: Do not print profile names in -bitexact

[Timothy Gu]

On Fri, Nov 27, 2015 at 02:33:02PM -0800, Timothy Gu wrote:
> Instead, print "unknown" if it's unknown, or their numerical values if
> they are known.
> ---
> 
> Addresses Nicholas's comment.
> 
> ---
>  ffprobe.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)

Ping.

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

Re: [FFmpeg-devel] [PATCH] tests/api: Fix API test build on windows with --enable-shared

[Michael Niedermayer]

On Tue, Dec 01, 2015 at 08:04:22PM +0100, Hendrik Leppkes wrote:
> On Mon, Nov 30, 2015 at 10:50 PM, Hendrik Leppkes  wrote:
> > ---
> > I'm not quite sure if this fix is 100% correct, but it works here.
> >
> > The problem is that FF_DEP_LIBS points to the .dll files, but you can't 
> > link to the .dll files,
> > you need to point to the import libraries. Unfortunately there is no 
> > variable which simply
> > holds all import libraries - but they do appear to be part of FF_EXTRALIBS, 
> > so thats used instead.
> >
> > tests/api/Makefile | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tests/api/Makefile b/tests/api/Makefile
> > index c48c34a..a6d8e42 100644
> > --- a/tests/api/Makefile
> > +++ b/tests/api/Makefile
> > @@ -14,7 +14,7 @@ $(APITESTOBJS) $(APITESTOBJS:.o=.i): CPPFLAGS += -DTEST
> >  $(APITESTOBJS) $(APITESTOBJS:.o=.i): CFLAGS += -Umain
> >
> >  $(APITESTPROGS): %$(EXESUF): %.o $(EXEOBJS) $(FF_DEP_LIBS)
> > -   $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) 
> > $(FF_DEP_LIBS) $(FFEXTRALIBS) $(ELIBS)
> > +   $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) 
> > $(FF_EXTRALIBS) $(ELIBS)
> >
> >  testclean::
> > $(RM) $(addprefix $(APITESTSDIR)/,$(CLEANSUFFIXES) *-test$(EXESUF))
> > --
> > 2.6.2.windows.1
> >
> 
> Anyone that knows the build system a bit more? Or maybe anyone that

> just feels like testing on some other systems than mine? :)

seems to work on everything i tried but that probably is a small
subset of what is out there

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH] avfilter: add audio pulsator filter

[Ganesh Ajjanagadde]

On Tue, Dec 1, 2015 at 7:04 AM, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi   |  57 +
>  libavfilter/Makefile   |   1 +
>  libavfilter/af_apulsator.c | 279 
> +
>  libavfilter/allfilters.c   |   1 +
>  4 files changed, 338 insertions(+)
>  create mode 100644 libavfilter/af_apulsator.c
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index fc71a99..a4afcac 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -1030,6 +1030,63 @@ It accepts the following values:
>  @end table
>  @end table
>
> +@section apulsator
> +
> +Audio pulsator is something between an autopanner and a tremolo.
> +But it can produce funny stereo effects as well. Pulsator changes the volume
> +of the left and right channel based on a LFO (low frequency oscillator) with
> +different waveforms and shifted phases.
> +This filter have the ability to define an offset between left and right
> +channel. An offset of 0 means that both LFO shapes match each other.
> +The left and right channel are altered equally - a conventional tremolo.
> +An offset of 50% means that the shape of the right channel is exactly shifted
> +in phase (or moved backwards about half of the frequency) - pulsator acts as
> +an autopanner. At 1 both curves match again. Every setting in between moves 
> the
> +phase shift gapless between all stages and produces some "bypassing" sounds 
> with
> +sine and triangle waveforms. The more you set the offset near 1 (starting 
> from
> +the 0.5) the faster the signal passes from the left to the right speaker.
> +
> +The filter accepts the following options:
> +
> +@table @option
> +@item level_in
> +Set input gain. By default it is 1. Range is [0.015625 - 64].
> +
> +@item level_out
> +Set output gain. By default it is 1. Range is [0.015625 - 64].
> +
> +@item mode
> +Set waveform shape the LFO will use. Can be one of: sine, triangle, square,
> +sawup or sawdown. Default is sine.
> +
> +@item amount
> +Set modulation. Define how much of original signal is affected by the LFO.
> +
> +@item offset_l
> +Set left channel offset. Default is 0. Allowed range is [0 - 1].
> +
> +@item offset_r
> +Set right channel offset. Default is 0.5. Allowed range is [0 - 1].
> +
> +@item width
> +Set pulse width.
> +
> +@item timing
> +Set possible timing mode. Can be one of: bpm, ms or hz. Default is hz.
> +
> +@item bpm
> +Set bpm. Default is 120. Allowed range is [30 - 300]. Only used if timing
> +is set to bpm.
> +
> +@item ms
> +Set ms. Default is 500. Allowed range is [10 - 2000]. Only used if timing
> +is set to ms.
> +
> +@item hz
> +Set frequency in Hz. Default is 2. Allowed range is [0.01 - 100]. Only used
> +if timing is set to hz.
> +@end table
> +
>  @anchor{aresample}
>  @section aresample
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index e31bdaa..b6c0d7b 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -40,6 +40,7 @@ OBJS-$(CONFIG_ANULL_FILTER)  += af_anull.o
>  OBJS-$(CONFIG_APAD_FILTER)   += af_apad.o
>  OBJS-$(CONFIG_APERMS_FILTER) += f_perms.o
>  OBJS-$(CONFIG_APHASER_FILTER)+= af_aphaser.o 
> generate_wave_table.o
> +OBJS-$(CONFIG_APULSATOR_FILTER)  += af_apulsator.o
>  OBJS-$(CONFIG_AREALTIME_FILTER)  += f_realtime.o
>  OBJS-$(CONFIG_ARESAMPLE_FILTER)  += af_aresample.o
>  OBJS-$(CONFIG_AREVERSE_FILTER)   += f_reverse.o
> diff --git a/libavfilter/af_apulsator.c b/libavfilter/af_apulsator.c
> new file mode 100644
> index 000..9100eff
> --- /dev/null
> +++ b/libavfilter/af_apulsator.c
> @@ -0,0 +1,279 @@
> +/*
> + * Copyright (c) 2001-2010 Krzysztof Foltman, Markus Schmidt, Thor Harald 
> Johansen and others
> + *
> + * 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/opt.h"
> +#include "avfilter.h"
> +#include "internal.h"
> +#include "audio.h"
> +
> +enum PulsatorModes { SINE, TRIANGLE, SQUARE, SAWUP, SAWDOWN, NB_MODES };
> +enum PulsatorTimings { UNIT_BPM, UNIT_MS, UNIT_HZ, NB_TIMINGS };
> +
> +typedef struct SimpleLFO {
> +double phase;
> +double freq;

[FFmpeg-devel] [PATCHv2] avutil/crc: avoid needless space wastage of hardcoded crc table

[Ganesh Ajjanagadde]

There was no reason AFAIK for making AV_CRC_24_IEEE 12. This simply
resulted in wasted space under --enable-hardcoded-tables:
dynamic: 1318672 libavutil/libavutil.so.55
old: 1330680 libavutil/libavutil.so.55
new: 1326488 libavutil/libavutil.so.55

Minor version number is bumped, with ifdefry due to API breakage.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavutil/crc.h | 4 
 libavutil/version.h | 5 -
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/libavutil/crc.h b/libavutil/crc.h
index e86bf1d..9af4421 100644
--- a/libavutil/crc.h
+++ b/libavutil/crc.h
@@ -40,7 +40,11 @@ typedef enum {
 AV_CRC_32_IEEE,
 AV_CRC_32_IEEE_LE,  /*< reversed bitorder version of AV_CRC_32_IEEE */
 AV_CRC_16_ANSI_LE,  /*< reversed bitorder version of AV_CRC_16_ANSI */
+#if FF_API_CRC_BIG_TABLE
 AV_CRC_24_IEEE = 12,
+#else
+AV_CRC_24_IEEE,
+#endif /* FF_API_CRC_BIG_TABLE */
 AV_CRC_MAX, /*< Not part of public API! Do not use outside 
libavutil. */
 }AVCRCId;
 
diff --git a/libavutil/version.h b/libavutil/version.h
index e0ddfd2..67e778a 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -56,7 +56,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  55
-#define LIBAVUTIL_VERSION_MINOR   9
+#define LIBAVUTIL_VERSION_MINOR  10
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
@@ -108,6 +108,9 @@
 #ifndef FF_API_ERROR_FRAME
 #define FF_API_ERROR_FRAME  (LIBAVUTIL_VERSION_MAJOR < 56)
 #endif
+#ifndef FF_API_CRC_BIG_TABLE
+#define FF_API_CRC_BIG_TABLE(LIBAVUTIL_VERSION_INT < 
AV_VERSION_INT(55, 10, 100))
+#endif
 
 
 /**
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] tests/api: Fix API test build on windows with --enable-shared

[Ganesh Ajjanagadde]

On Tue, Dec 1, 2015 at 8:29 PM, Michael Niedermayer  wrote:
> On Tue, Dec 01, 2015 at 08:04:22PM +0100, Hendrik Leppkes wrote:
>> On Mon, Nov 30, 2015 at 10:50 PM, Hendrik Leppkes  
>> wrote:
>> > ---
>> > I'm not quite sure if this fix is 100% correct, but it works here.
>> >
>> > The problem is that FF_DEP_LIBS points to the .dll files, but you can't 
>> > link to the .dll files,
>> > you need to point to the import libraries. Unfortunately there is no 
>> > variable which simply
>> > holds all import libraries - but they do appear to be part of 
>> > FF_EXTRALIBS, so thats used instead.
>> >
>> > tests/api/Makefile | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/tests/api/Makefile b/tests/api/Makefile
>> > index c48c34a..a6d8e42 100644
>> > --- a/tests/api/Makefile
>> > +++ b/tests/api/Makefile
>> > @@ -14,7 +14,7 @@ $(APITESTOBJS) $(APITESTOBJS:.o=.i): CPPFLAGS += -DTEST
>> >  $(APITESTOBJS) $(APITESTOBJS:.o=.i): CFLAGS += -Umain
>> >
>> >  $(APITESTPROGS): %$(EXESUF): %.o $(EXEOBJS) $(FF_DEP_LIBS)
>> > -   $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) 
>> > $(FF_DEP_LIBS) $(FFEXTRALIBS) $(ELIBS)
>> > +   $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) 
>> > $(FF_EXTRALIBS) $(ELIBS)
>> >
>> >  testclean::
>> > $(RM) $(addprefix $(APITESTSDIR)/,$(CLEANSUFFIXES) *-test$(EXESUF))
>> > --
>> > 2.6.2.windows.1
>> >
>>
>> Anyone that knows the build system a bit more? Or maybe anyone that
>
>> just feels like testing on some other systems than mine? :)
>
> seems to work on everything i tried but that probably is a small
> subset of what is out there

that is still a far larger set than what anyone else actively working
on FFmpeg has AFAIK, and definitely supersedes what I have :). In
other words, it is a best effort wrt development, and we can't hope
for much more.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> it is not once nor twice but times without number that the same ideas make
> their appearance in the world. -- Aristotle
>
> ___
> 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] [PATCHv2] avutil/crc: avoid needless space wastage of hardcoded crc table

[James Almer]

On 12/1/2015 10:35 PM, Ganesh Ajjanagadde wrote:
> On Tue, Dec 1, 2015 at 8:08 PM, James Almer  wrote:
>> On 12/1/2015 9:53 PM, Ganesh Ajjanagadde wrote:
>>> There was no reason AFAIK for making AV_CRC_24_IEEE 12. This simply
>>> resulted in wasted space under --enable-hardcoded-tables:
>>> dynamic: 1318672 libavutil/libavutil.so.55
>>> old: 1330680 libavutil/libavutil.so.55
>>> new: 1326488 libavutil/libavutil.so.55
>>>
>>> Minor version number is bumped, with ifdefry due to API breakage.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavutil/crc.h | 4 
>>>  libavutil/version.h | 5 -
>>>  2 files changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavutil/crc.h b/libavutil/crc.h
>>> index e86bf1d..9af4421 100644
>>> --- a/libavutil/crc.h
>>> +++ b/libavutil/crc.h
>>> @@ -40,7 +40,11 @@ typedef enum {
>>>  AV_CRC_32_IEEE,
>>>  AV_CRC_32_IEEE_LE,  /*< reversed bitorder version of AV_CRC_32_IEEE */
>>>  AV_CRC_16_ANSI_LE,  /*< reversed bitorder version of AV_CRC_16_ANSI */
>>> +#if FF_API_CRC_BIG_TABLE
>>>  AV_CRC_24_IEEE = 12,
>>> +#else
>>> +AV_CRC_24_IEEE,
>>> +#endif /* FF_API_CRC_BIG_TABLE */
>>>  AV_CRC_MAX, /*< Not part of public API! Do not use outside 
>>> libavutil. */
>>>  }AVCRCId;
>>>
>>> diff --git a/libavutil/version.h b/libavutil/version.h
>>> index e0ddfd2..67e778a 100644
>>> --- a/libavutil/version.h
>>> +++ b/libavutil/version.h
>>> @@ -56,7 +56,7 @@
>>>   */
>>>
>>>  #define LIBAVUTIL_VERSION_MAJOR  55
>>> -#define LIBAVUTIL_VERSION_MINOR   9
>>> +#define LIBAVUTIL_VERSION_MINOR  10
>>>  #define LIBAVUTIL_VERSION_MICRO 100
>>>
>>>  #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
>>> @@ -108,6 +108,9 @@
>>>  #ifndef FF_API_ERROR_FRAME
>>>  #define FF_API_ERROR_FRAME  (LIBAVUTIL_VERSION_MAJOR < 56)
>>>  #endif
>>> +#ifndef FF_API_CRC_BIG_TABLE
>>> +#define FF_API_CRC_BIG_TABLE(LIBAVUTIL_VERSION_INT < 
>>> AV_VERSION_INT(55, 10, 100))
>>
>> This is wrong. With this check, FF_API_CRC_BIG_TABLE is false. The point
>> of these FF_API defines is to make sure they are true until the next major
>> bump. That's why you use LIBAVUTIL_VERSION_MAJOR < 56, like it's being
>> done for the rest.
> 
> Finally getting a sense for these things, thanks. Barring that, does
> it look fine?

Yes. You can also skip bumping minor. You're scheduling a change for the next
major bump and not making any changes with immediate effects, so a minor bump
is not necessary.

> 
>>
>>> +#endif
>>>
>>>
>>>  /**
>>>
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

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

[FFmpeg-devel] [PATCH] vp9: always keep s->bytesperpixel and ctx->pix_fmt in sync.

[Ronald S. Bultje]

Fixes mozilla bug 1229128.
---
 libavcodec/vp9.c | 43 ++-
 1 file changed, 22 insertions(+), 21 deletions(-)

diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index d4061e2..dc0 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -69,6 +69,7 @@ typedef struct VP9Context {
 uint8_t ss_h, ss_v;
 uint8_t last_bpp, bpp, bpp_index, bytesperpixel;
 uint8_t last_keyframe;
+enum AVPixelFormat pix_fmt, last_fmt;
 ThreadFrame next_refs[8];
 
 struct {
@@ -211,7 +212,7 @@ static int vp9_ref_frame(AVCodecContext *ctx, VP9Frame 
*dst, VP9Frame *src)
 return 0;
 }
 
-static int update_size(AVCodecContext *ctx, int w, int h, enum AVPixelFormat 
fmt)
+static int update_size(AVCodecContext *ctx, int w, int h)
 {
 VP9Context *s = ctx->priv_data;
 uint8_t *p;
@@ -219,12 +220,12 @@ static int update_size(AVCodecContext *ctx, int w, int h, 
enum AVPixelFormat fmt
 
 av_assert0(w > 0 && h > 0);
 
-if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height && 
ctx->pix_fmt == fmt)
+if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height && 
s->pix_fmt == s->last_fmt)
 return 0;
 
 if ((res = ff_set_dimensions(ctx, w, h)) < 0)
 return res;
-ctx->pix_fmt = fmt;
+s->last_fmt  = ctx->pix_fmt = s->pix_fmt;
 s->sb_cols   = (w + 63) >> 6;
 s->sb_rows   = (h + 63) >> 6;
 s->cols  = (w + 7) >> 3;
@@ -383,14 +384,13 @@ static int update_prob(VP56RangeCoder *c, int p)
 255 - inv_recenter_nonneg(inv_map_table[d], 255 - p);
 }
 
-static enum AVPixelFormat read_colorspace_details(AVCodecContext *ctx)
+static int read_colorspace_details(AVCodecContext *ctx)
 {
 static const enum AVColorSpace colorspaces[8] = {
 AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709, 
AVCOL_SPC_SMPTE170M,
 AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED, 
AVCOL_SPC_RGB,
 };
 VP9Context *s = ctx->priv_data;
-enum AVPixelFormat res;
 int bits = ctx->profile <= 1 ? 0 : 1 + get_bits1(>gb); // 0:8, 1:10, 
2:12
 
 s->bpp_index = bits;
@@ -401,10 +401,10 @@ static enum AVPixelFormat 
read_colorspace_details(AVCodecContext *ctx)
 static const enum AVPixelFormat pix_fmt_rgb[3] = {
 AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12
 };
+s->ss_h = s->ss_v = 0;
+ctx->color_range = AVCOL_RANGE_JPEG;
+s->pix_fmt = pix_fmt_rgb[bits];
 if (ctx->profile & 1) {
-s->ss_h = s->ss_v = 0;
-res = pix_fmt_rgb[bits];
-ctx->color_range = AVCOL_RANGE_JPEG;
 if (get_bits1(>gb)) {
 av_log(ctx, AV_LOG_ERROR, "Reserved bit set in RGB\n");
 return AVERROR_INVALIDDATA;
@@ -427,7 +427,8 @@ static enum AVPixelFormat 
read_colorspace_details(AVCodecContext *ctx)
 if (ctx->profile & 1) {
 s->ss_h = get_bits1(>gb);
 s->ss_v = get_bits1(>gb);
-if ((res = pix_fmt_for_ss[bits][s->ss_v][s->ss_h]) == 
AV_PIX_FMT_YUV420P) {
+s->pix_fmt = pix_fmt_for_ss[bits][s->ss_v][s->ss_h];
+if (s->pix_fmt == AV_PIX_FMT_YUV420P) {
 av_log(ctx, AV_LOG_ERROR, "YUV 4:2:0 not supported in profile 
%d\n",
ctx->profile);
 return AVERROR_INVALIDDATA;
@@ -438,11 +439,11 @@ static enum AVPixelFormat 
read_colorspace_details(AVCodecContext *ctx)
 }
 } else {
 s->ss_h = s->ss_v = 1;
-res = pix_fmt_for_ss[bits][1][1];
+s->pix_fmt = pix_fmt_for_ss[bits][1][1];
 }
 }
 
-return res;
+return 0;
 }
 
 static int decode_frame_header(AVCodecContext *ctx,
@@ -450,7 +451,6 @@ static int decode_frame_header(AVCodecContext *ctx,
 {
 VP9Context *s = ctx->priv_data;
 int c, i, j, k, l, m, n, w, h, max, size2, res, sharp;
-enum AVPixelFormat fmt = ctx->pix_fmt;
 int last_invisible;
 const uint8_t *data2;
 
@@ -486,8 +486,8 @@ static int decode_frame_header(AVCodecContext *ctx,
 av_log(ctx, AV_LOG_ERROR, "Invalid sync code\n");
 return AVERROR_INVALIDDATA;
 }
-if ((fmt = read_colorspace_details(ctx)) < 0)
-return fmt;
+if ((res = read_colorspace_details(ctx)) < 0)
+return res;
 // for profile 1, here follows the subsampling bits
 s->s.h.refreshrefmask = 0xff;
 w = get_bits(>gb, 16) + 1;
@@ -503,14 +503,14 @@ static int decode_frame_header(AVCodecContext *ctx,
 return AVERROR_INVALIDDATA;
 }
 if (ctx->profile >= 1) {
-if ((fmt = read_colorspace_details(ctx)) < 0)
-return fmt;
+if ((res = read_colorspace_details(ctx)) < 0)
+return res;
 } else {
 s->ss_h = s->ss_v = 1;
 s->bpp = 8;
 s->bpp_index = 

Re: [FFmpeg-devel] [PATCH] vp9: always keep s->bytesperpixel and ctx->pix_fmt in sync.

[Ronald S. Bultje]

Hi,

On Tue, Dec 1, 2015 at 11:09 AM, Hendrik Leppkes 
wrote:

> On Tue, Dec 1, 2015 at 4:08 PM, Ronald S. Bultje 
> wrote:
> > Fixes mozilla bug 1229128.
> > ---
> >  libavcodec/vp9.c | 43 ++-
> >  1 file changed, 22 insertions(+), 21 deletions(-)
> >
> > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> > index d4061e2..9bf746c 100644
> > --- a/libavcodec/vp9.c
> > +++ b/libavcodec/vp9.c
> > @@ -69,6 +69,7 @@ typedef struct VP9Context {
> >  uint8_t ss_h, ss_v;
> >  uint8_t last_bpp, bpp, bpp_index, bytesperpixel;
> >  uint8_t last_keyframe;
> > +enum AVPixelFormat last_fmt;
> >  ThreadFrame next_refs[8];
> >
> >  struct {
> > @@ -211,7 +212,7 @@ static int vp9_ref_frame(AVCodecContext *ctx,
> VP9Frame *dst, VP9Frame *src)
> >  return 0;
> >  }
> >
> > -static int update_size(AVCodecContext *ctx, int w, int h, enum
> AVPixelFormat fmt)
> > +static int update_size(AVCodecContext *ctx, int w, int h)
> >  {
> >  VP9Context *s = ctx->priv_data;
> >  uint8_t *p;
> > @@ -219,12 +220,12 @@ static int update_size(AVCodecContext *ctx, int w,
> int h, enum AVPixelFormat fmt
> >
> >  av_assert0(w > 0 && h > 0);
> >
> > -if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height &&
> ctx->pix_fmt == fmt)
> > +if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height &&
> ctx->pix_fmt == s->last_fmt)
> >  return 0;
> >
> >  if ((res = ff_set_dimensions(ctx, w, h)) < 0)
> >  return res;
> > -ctx->pix_fmt = fmt;
> > +s->last_fmt  = ctx->pix_fmt;
> >  s->sb_cols   = (w + 63) >> 6;
> >  s->sb_rows   = (h + 63) >> 6;
> >  s->cols  = (w + 7) >> 3;
> > @@ -383,14 +384,13 @@ static int update_prob(VP56RangeCoder *c, int p)
> >  255 - inv_recenter_nonneg(inv_map_table[d], 255 -
> p);
> >  }
> >
> > -static enum AVPixelFormat read_colorspace_details(AVCodecContext *ctx)
> > +static int read_colorspace_details(AVCodecContext *ctx)
> >  {
> >  static const enum AVColorSpace colorspaces[8] = {
> >  AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709,
> AVCOL_SPC_SMPTE170M,
> >  AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED,
> AVCOL_SPC_RGB,
> >  };
> >  VP9Context *s = ctx->priv_data;
> > -enum AVPixelFormat res;
> >  int bits = ctx->profile <= 1 ? 0 : 1 + get_bits1(>gb); // 0:8,
> 1:10, 2:12
> >
> >  s->bpp_index = bits;
> > @@ -401,10 +401,10 @@ static enum AVPixelFormat
> read_colorspace_details(AVCodecContext *ctx)
> >  static const enum AVPixelFormat pix_fmt_rgb[3] = {
> >  AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12
> >  };
> > +s->ss_h = s->ss_v = 0;
> > +ctx->color_range = AVCOL_RANGE_JPEG;
> > +ctx->pix_fmt = pix_fmt_rgb[bits];
> >  if (ctx->profile & 1) {
> > -s->ss_h = s->ss_v = 0;
> > -res = pix_fmt_rgb[bits];
> > -ctx->color_range = AVCOL_RANGE_JPEG;
> >  if (get_bits1(>gb)) {
> >  av_log(ctx, AV_LOG_ERROR, "Reserved bit set in RGB\n");
> >  return AVERROR_INVALIDDATA;
> > @@ -427,7 +427,8 @@ static enum AVPixelFormat
> read_colorspace_details(AVCodecContext *ctx)
> >  if (ctx->profile & 1) {
> >  s->ss_h = get_bits1(>gb);
> >  s->ss_v = get_bits1(>gb);
> > -if ((res = pix_fmt_for_ss[bits][s->ss_v][s->ss_h]) ==
> AV_PIX_FMT_YUV420P) {
> > +ctx->pix_fmt = pix_fmt_for_ss[bits][s->ss_v][s->ss_h];
> > +if (ctx->pix_fmt == AV_PIX_FMT_YUV420P) {
> >  av_log(ctx, AV_LOG_ERROR, "YUV 4:2:0 not supported in
> profile %d\n",
> > ctx->profile);
> >  return AVERROR_INVALIDDATA;
> > @@ -438,11 +439,11 @@ static enum AVPixelFormat
> read_colorspace_details(AVCodecContext *ctx)
> >  }
> >  } else {
> >  s->ss_h = s->ss_v = 1;
> > -res = pix_fmt_for_ss[bits][1][1];
> > +ctx->pix_fmt = pix_fmt_for_ss[bits][1][1];
> >  }
> >  }
> >
> > -return res;
> > +return 0;
> >  }
> >
> >  static int decode_frame_header(AVCodecContext *ctx,
> > @@ -450,7 +451,6 @@ static int decode_frame_header(AVCodecContext *ctx,
> >  {
> >  VP9Context *s = ctx->priv_data;
> >  int c, i, j, k, l, m, n, w, h, max, size2, res, sharp;
> > -enum AVPixelFormat fmt = ctx->pix_fmt;
> >  int last_invisible;
> >  const uint8_t *data2;
> >
> > @@ -486,8 +486,8 @@ static int decode_frame_header(AVCodecContext *ctx,
> >  av_log(ctx, AV_LOG_ERROR, "Invalid sync code\n");
> >  return AVERROR_INVALIDDATA;
> >  }
> > -if ((fmt = read_colorspace_details(ctx)) < 0)
> > -return fmt;
> > +if ((res = read_colorspace_details(ctx)) < 0)
> > +return res;
> >  // for profile 1, 

Re: [FFmpeg-devel] [PATCH] vp9: always keep s->bytesperpixel and ctx->pix_fmt in sync.

[Hendrik Leppkes]

On Tue, Dec 1, 2015 at 6:24 PM, Ronald S. Bultje  wrote:
> Fixes mozilla bug 1229128.
> ---
>  libavcodec/vp9.c | 43 ++-
>  1 file changed, 22 insertions(+), 21 deletions(-)
>
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index d4061e2..dc0 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -69,6 +69,7 @@ typedef struct VP9Context {
>  uint8_t ss_h, ss_v;
>  uint8_t last_bpp, bpp, bpp_index, bytesperpixel;
>  uint8_t last_keyframe;
> +enum AVPixelFormat pix_fmt, last_fmt;
>  ThreadFrame next_refs[8];
>
>  struct {
> @@ -211,7 +212,7 @@ static int vp9_ref_frame(AVCodecContext *ctx, VP9Frame 
> *dst, VP9Frame *src)
>  return 0;
>  }
>
> -static int update_size(AVCodecContext *ctx, int w, int h, enum AVPixelFormat 
> fmt)
> +static int update_size(AVCodecContext *ctx, int w, int h)
>  {
>  VP9Context *s = ctx->priv_data;
>  uint8_t *p;
> @@ -219,12 +220,12 @@ static int update_size(AVCodecContext *ctx, int w, int 
> h, enum AVPixelFormat fmt
>
>  av_assert0(w > 0 && h > 0);
>
> -if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height && 
> ctx->pix_fmt == fmt)
> +if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height && 
> s->pix_fmt == s->last_fmt)
>  return 0;
>
>  if ((res = ff_set_dimensions(ctx, w, h)) < 0)
>  return res;
> -ctx->pix_fmt = fmt;
> +s->last_fmt  = ctx->pix_fmt = s->pix_fmt;
>  s->sb_cols   = (w + 63) >> 6;
>  s->sb_rows   = (h + 63) >> 6;
>  s->cols  = (w + 7) >> 3;
> @@ -383,14 +384,13 @@ static int update_prob(VP56RangeCoder *c, int p)
>  255 - inv_recenter_nonneg(inv_map_table[d], 255 - p);
>  }
>
> -static enum AVPixelFormat read_colorspace_details(AVCodecContext *ctx)
> +static int read_colorspace_details(AVCodecContext *ctx)
>  {
>  static const enum AVColorSpace colorspaces[8] = {
>  AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709, 
> AVCOL_SPC_SMPTE170M,
>  AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED, 
> AVCOL_SPC_RGB,
>  };
>  VP9Context *s = ctx->priv_data;
> -enum AVPixelFormat res;
>  int bits = ctx->profile <= 1 ? 0 : 1 + get_bits1(>gb); // 0:8, 1:10, 
> 2:12
>
>  s->bpp_index = bits;
> @@ -401,10 +401,10 @@ static enum AVPixelFormat 
> read_colorspace_details(AVCodecContext *ctx)
>  static const enum AVPixelFormat pix_fmt_rgb[3] = {
>  AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12
>  };
> +s->ss_h = s->ss_v = 0;
> +ctx->color_range = AVCOL_RANGE_JPEG;
> +s->pix_fmt = pix_fmt_rgb[bits];
>  if (ctx->profile & 1) {
> -s->ss_h = s->ss_v = 0;
> -res = pix_fmt_rgb[bits];
> -ctx->color_range = AVCOL_RANGE_JPEG;
>  if (get_bits1(>gb)) {
>  av_log(ctx, AV_LOG_ERROR, "Reserved bit set in RGB\n");
>  return AVERROR_INVALIDDATA;
> @@ -427,7 +427,8 @@ static enum AVPixelFormat 
> read_colorspace_details(AVCodecContext *ctx)
>  if (ctx->profile & 1) {
>  s->ss_h = get_bits1(>gb);
>  s->ss_v = get_bits1(>gb);
> -if ((res = pix_fmt_for_ss[bits][s->ss_v][s->ss_h]) == 
> AV_PIX_FMT_YUV420P) {
> +s->pix_fmt = pix_fmt_for_ss[bits][s->ss_v][s->ss_h];
> +if (s->pix_fmt == AV_PIX_FMT_YUV420P) {
>  av_log(ctx, AV_LOG_ERROR, "YUV 4:2:0 not supported in 
> profile %d\n",
> ctx->profile);
>  return AVERROR_INVALIDDATA;
> @@ -438,11 +439,11 @@ static enum AVPixelFormat 
> read_colorspace_details(AVCodecContext *ctx)
>  }
>  } else {
>  s->ss_h = s->ss_v = 1;
> -res = pix_fmt_for_ss[bits][1][1];
> +s->pix_fmt = pix_fmt_for_ss[bits][1][1];
>  }
>  }
>
> -return res;
> +return 0;
>  }
>
>  static int decode_frame_header(AVCodecContext *ctx,
> @@ -450,7 +451,6 @@ static int decode_frame_header(AVCodecContext *ctx,
>  {
>  VP9Context *s = ctx->priv_data;
>  int c, i, j, k, l, m, n, w, h, max, size2, res, sharp;
> -enum AVPixelFormat fmt = ctx->pix_fmt;
>  int last_invisible;
>  const uint8_t *data2;
>
> @@ -486,8 +486,8 @@ static int decode_frame_header(AVCodecContext *ctx,
>  av_log(ctx, AV_LOG_ERROR, "Invalid sync code\n");
>  return AVERROR_INVALIDDATA;
>  }
> -if ((fmt = read_colorspace_details(ctx)) < 0)
> -return fmt;
> +if ((res = read_colorspace_details(ctx)) < 0)
> +return res;
>  // for profile 1, here follows the subsampling bits
>  s->s.h.refreshrefmask = 0xff;
>  w = get_bits(>gb, 16) + 1;
> @@ -503,14 +503,14 @@ static int decode_frame_header(AVCodecContext *ctx,
>  return AVERROR_INVALIDDATA;
>  }
>  if (ctx->profile >= 1) 

Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()

[Nicolas George]

Le primidi 11 frimaire, an CCXXIV, Clement Boesch a écrit :
> Ah. Well then the user can not do it himself since he has no way of
> acquiring the queue lock (AVThreadMessageQueue is opaque)

Yes, but why does it matter, if the elements are to be discarded anyway.

Ah, I think I see a point: this API is for the sender, not the receiver, and
you are afraid that the receiver can read one element in the middle while
the sender is flushing. Is that it?

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] vp9: always keep s->bytesperpixel and ctx->pix_fmt in sync.

[Ronald S. Bultje]

Hi,

On Tue, Dec 1, 2015 at 12:34 PM, Hendrik Leppkes 
wrote:

> On Tue, Dec 1, 2015 at 6:24 PM, Ronald S. Bultje 
> wrote:
> > Fixes mozilla bug 1229128.
> > ---
> >  libavcodec/vp9.c | 43 ++-
> >  1 file changed, 22 insertions(+), 21 deletions(-)
> >
> > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> > index d4061e2..dc0 100644
> > --- a/libavcodec/vp9.c
> > +++ b/libavcodec/vp9.c
> > @@ -69,6 +69,7 @@ typedef struct VP9Context {
> >  uint8_t ss_h, ss_v;
> >  uint8_t last_bpp, bpp, bpp_index, bytesperpixel;
> >  uint8_t last_keyframe;
> > +enum AVPixelFormat pix_fmt, last_fmt;
> >  ThreadFrame next_refs[8];
> >
> >  struct {
> > @@ -211,7 +212,7 @@ static int vp9_ref_frame(AVCodecContext *ctx,
> VP9Frame *dst, VP9Frame *src)
> >  return 0;
> >  }
> >
> > -static int update_size(AVCodecContext *ctx, int w, int h, enum
> AVPixelFormat fmt)
> > +static int update_size(AVCodecContext *ctx, int w, int h)
> >  {
> >  VP9Context *s = ctx->priv_data;
> >  uint8_t *p;
> > @@ -219,12 +220,12 @@ static int update_size(AVCodecContext *ctx, int w,
> int h, enum AVPixelFormat fmt
> >
> >  av_assert0(w > 0 && h > 0);
> >
> > -if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height &&
> ctx->pix_fmt == fmt)
> > +if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height &&
> s->pix_fmt == s->last_fmt)
> >  return 0;
> >
> >  if ((res = ff_set_dimensions(ctx, w, h)) < 0)
> >  return res;
> > -ctx->pix_fmt = fmt;
> > +s->last_fmt  = ctx->pix_fmt = s->pix_fmt;
> >  s->sb_cols   = (w + 63) >> 6;
> >  s->sb_rows   = (h + 63) >> 6;
> >  s->cols  = (w + 7) >> 3;
> > @@ -383,14 +384,13 @@ static int update_prob(VP56RangeCoder *c, int p)
> >  255 - inv_recenter_nonneg(inv_map_table[d], 255 -
> p);
> >  }
> >
> > -static enum AVPixelFormat read_colorspace_details(AVCodecContext *ctx)
> > +static int read_colorspace_details(AVCodecContext *ctx)
> >  {
> >  static const enum AVColorSpace colorspaces[8] = {
> >  AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709,
> AVCOL_SPC_SMPTE170M,
> >  AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED,
> AVCOL_SPC_RGB,
> >  };
> >  VP9Context *s = ctx->priv_data;
> > -enum AVPixelFormat res;
> >  int bits = ctx->profile <= 1 ? 0 : 1 + get_bits1(>gb); // 0:8,
> 1:10, 2:12
> >
> >  s->bpp_index = bits;
> > @@ -401,10 +401,10 @@ static enum AVPixelFormat
> read_colorspace_details(AVCodecContext *ctx)
> >  static const enum AVPixelFormat pix_fmt_rgb[3] = {
> >  AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12
> >  };
> > +s->ss_h = s->ss_v = 0;
> > +ctx->color_range = AVCOL_RANGE_JPEG;
> > +s->pix_fmt = pix_fmt_rgb[bits];
> >  if (ctx->profile & 1) {
> > -s->ss_h = s->ss_v = 0;
> > -res = pix_fmt_rgb[bits];
> > -ctx->color_range = AVCOL_RANGE_JPEG;
> >  if (get_bits1(>gb)) {
> >  av_log(ctx, AV_LOG_ERROR, "Reserved bit set in RGB\n");
> >  return AVERROR_INVALIDDATA;
> > @@ -427,7 +427,8 @@ static enum AVPixelFormat
> read_colorspace_details(AVCodecContext *ctx)
> >  if (ctx->profile & 1) {
> >  s->ss_h = get_bits1(>gb);
> >  s->ss_v = get_bits1(>gb);
> > -if ((res = pix_fmt_for_ss[bits][s->ss_v][s->ss_h]) ==
> AV_PIX_FMT_YUV420P) {
> > +s->pix_fmt = pix_fmt_for_ss[bits][s->ss_v][s->ss_h];
> > +if (s->pix_fmt == AV_PIX_FMT_YUV420P) {
> >  av_log(ctx, AV_LOG_ERROR, "YUV 4:2:0 not supported in
> profile %d\n",
> > ctx->profile);
> >  return AVERROR_INVALIDDATA;
> > @@ -438,11 +439,11 @@ static enum AVPixelFormat
> read_colorspace_details(AVCodecContext *ctx)
> >  }
> >  } else {
> >  s->ss_h = s->ss_v = 1;
> > -res = pix_fmt_for_ss[bits][1][1];
> > +s->pix_fmt = pix_fmt_for_ss[bits][1][1];
> >  }
> >  }
> >
> > -return res;
> > +return 0;
> >  }
> >
> >  static int decode_frame_header(AVCodecContext *ctx,
> > @@ -450,7 +451,6 @@ static int decode_frame_header(AVCodecContext *ctx,
> >  {
> >  VP9Context *s = ctx->priv_data;
> >  int c, i, j, k, l, m, n, w, h, max, size2, res, sharp;
> > -enum AVPixelFormat fmt = ctx->pix_fmt;
> >  int last_invisible;
> >  const uint8_t *data2;
> >
> > @@ -486,8 +486,8 @@ static int decode_frame_header(AVCodecContext *ctx,
> >  av_log(ctx, AV_LOG_ERROR, "Invalid sync code\n");
> >  return AVERROR_INVALIDDATA;
> >  }
> > -if ((fmt = read_colorspace_details(ctx)) < 0)
> > -return fmt;
> > +if ((res = read_colorspace_details(ctx)) < 0)
> > +return res;
> >  // for 

Re: [FFmpeg-devel] [PATCH] avfilter: add audio pulsator filter

[Paul B Mahol]

On 12/2/15, Ganesh Ajjanagadde  wrote:
>> +static void lfo_advance(SimpleLFO *lfo, unsigned count)
>> +{
>> +lfo->phase = fabs(lfo->phase + count * lfo->freq / lfo->srate);
>> +if (lfo->phase >= 1)
>> +lfo->phase = fmod(lfo->phase, 1);
>> +}
>> +
>> +static double lfo_get_value(SimpleLFO *lfo)
>> +{
>> +double phs = FFMIN(100, lfo->phase / FFMIN(1.99, FFMAX(0.01,
>> lfo->pwidth)) + lfo->offset);
>> +double val;
>> +
>> +if (phs > 1)
>> +phs = fmod(phs, 1.);
>> +
>> +switch (lfo->mode) {
>> +case SINE:
>> +val = sin(phs * 2 * M_PI);
>> +break;
>> +case TRIANGLE:
>> +if (phs > 0.75)
>> +val = (phs - 0.75) * 4 - 1;
>> +else if (phs > 0.5)
>> +val = (phs - 0.5) * 4 * -1;
>> +else if (phs > 0.25)
>> +val = 1 - (phs - 0.25) * 4;
>> +else
>> +val = phs * 4;
>
> Why didn't you remove the useless branch and replace with a simple
> -4*phs + 2 for 0.25 to 0.75 case?
>
> I guess you did not remove the branch because you believed (but have
> not substantiated) that some notion of "bit-exactness" (highly dubious
> since floating point is not reproducible exactly across all platforms)
> with respect to some reference is violated. This "reference" is copied
> over from some other source code with no link whatsoever in the commit
> message or for the reviewer; only a simple copyright notice, making it
> impossible for a reviewer to do a proper review.
>
> [...]

In both cases the output is different and that is for s16 output case.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/9] avfilter/af_flanger: use rint instead of floor hack

[Paul B Mahol]

On 12/2/15, Ganesh Ajjanagadde  wrote:
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavfilter/af_flanger.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/af_flanger.c b/libavfilter/af_flanger.c
> index f8ec830..a92367c 100644
> --- a/libavfilter/af_flanger.c
> +++ b/libavfilter/af_flanger.c
> @@ -130,7 +130,7 @@ static int config_input(AVFilterLink *inlink)
>  return AVERROR(ENOMEM);
>
>  ff_generate_wave_table(s->wave_shape, AV_SAMPLE_FMT_FLT, s->lfo,
> s->lfo_length,
> -   floor(s->delay_min * inlink->sample_rate + 0.5),
> +   rint(s->delay_min * inlink->sample_rate),
> s->max_samples - 2., 3 * M_PI_2);
>
>  return av_samples_alloc_array_and_samples(>delay_buffer, NULL,
> --
> 2.6.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Have you checked that output is same?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/9] avfilter/af_stereotools: use lrint instead of floor hack

[Paul B Mahol]

On 12/2/15, Ganesh Ajjanagadde  wrote:
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavfilter/af_stereotools.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavfilter/af_stereotools.c b/libavfilter/af_stereotools.c
> index a22efb0..e878824 100644
> --- a/libavfilter/af_stereotools.c
> +++ b/libavfilter/af_stereotools.c
> @@ -139,10 +139,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *in)
>  const double sc_level = s->sc_level;
>  const double delay = s->delay;
>  const int length = s->length;
> -const int mute_l = floor(s->mute_l + 0.5);
> -const int mute_r = floor(s->mute_r + 0.5);
> -const int phase_l = floor(s->phase_l + 0.5);
> -const int phase_r = floor(s->phase_r + 0.5);
> +const int mute_l = lrint(s->mute_l);
> +const int mute_r = lrint(s->mute_r);
> +const int phase_l = lrint(s->phase_l);
> +const int phase_r = lrint(s->phase_r);
>  double *buffer = s->buffer;
>  AVFrame *out;
>  double *dst;
> --
> 2.6.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

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

[Paul B Mahol]

On 12/2/15, Ganesh Ajjanagadde  wrote:
> On Tue, Dec 1, 2015 at 2:14 PM, Paul B Mahol  wrote:
>> On 12/1/15, Nicolas George  wrote:
>>> Le primidi 11 frimaire, an CCXXIV, Paul B Mahol a ecrit :
 Similar how its freed when no longer used.
>>>
>>> Please elaborate. I know the API, I do not see what you suggest.
>>>
>>> (Thanks for trimming.)
>>>
>>> Regards,
>>
>> After carefully looking at this functon, I see no leaking at all.
>
> Care to elaborate on this? My question is: what happens when e.g
> layouts get set and allocated/ref'ed correctly, but while trying to
> allocate formats, ENOMEM occurs? Or in other words, where does the
> formats get deallocated in such a case? And why does Coverity flag
> these things?

Maybe it is for test program: libavfilter/filtfmts.c
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 8/9] avcodec/wavpackenc: use lrint instead of floor hack

[Paul B Mahol]

On 12/2/15, Ganesh Ajjanagadde  wrote:
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/wavpackenc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/wavpackenc.c b/libavcodec/wavpackenc.c
> index 977bcf0..6a9b716 100644
> --- a/libavcodec/wavpackenc.c
> +++ b/libavcodec/wavpackenc.c
> @@ -954,7 +954,7 @@ static void analyze_mono(WavPackEncodeContext *s,
> int32_t *samples, int do_sampl
>  memcpy(s->sampleptrs[info.nterms + 1][0], s->sampleptrs[i][0],
> s->block_samples * 4);
>
>  if (s->extra_flags & EXTRA_BRANCHES)
> -recurse_mono(s, , 0, (int) floor(s->delta_decay + 0.5),
> +recurse_mono(s, , 0, lrint(s->delta_decay),
>   log2mono(s->sampleptrs[0][0], s->block_samples, 0));
>
>  if (s->extra_flags & EXTRA_SORT_FIRST)
> @@ -1773,7 +1773,7 @@ static void analyze_stereo(WavPackEncodeContext *s,
>  memcpy(s->sampleptrs[info.nterms + 1][1], s->sampleptrs[i][1],
> s->block_samples * 4);
>
>  if (s->extra_flags & EXTRA_BRANCHES)
> -recurse_stereo(s, , 0, (int) floor(s->delta_decay + 0.5),
> +recurse_stereo(s, , 0, lrint(s->delta_decay),
> log2stereo(s->sampleptrs[0][0], s->sampleptrs[0][1],
>s->block_samples, 0));
>
> --
> 2.6.2

OK if and only if the output is lossless when using those flags.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Timothy Gu]

CCFLAGS is equivalent to CPPFLAGS + CFLAGS.
---
 common.mak | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common.mak b/common.mak
index d611ef8..05836ba 100644
--- a/common.mak
+++ b/common.mak
@@ -63,7 +63,7 @@ COMPILE_HOSTC = $(call COMPILE,HOSTCC)
$(COMPILE_C)
 
 %.s: %.c
-   $(CC) $(CPPFLAGS) $(CFLAGS) -S -o $@ $<
+   $(CC) $(CCFLAGS) -S -o $@ $<
 
 %.o: %.S
$(COMPILE_S)
-- 
2.1.4

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

[FFmpeg-devel] [PATCH 2/3] decklink: Header cleanup

[Timothy Gu]

---
 libavdevice/decklink_common.cpp | 4 
 libavdevice/decklink_common.h   | 8 +++-
 libavdevice/decklink_common_c.h | 2 ++
 libavdevice/decklink_dec.cpp| 4 
 libavdevice/decklink_dec.h  | 2 ++
 libavdevice/decklink_enc.cpp| 4 
 libavdevice/decklink_enc.h  | 2 ++
 7 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index ac7964c..58502ee 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -26,11 +26,7 @@
 #include 
 #endif
 
-#include 
-#include 
-
 extern "C" {
-#include "libavformat/avformat.h"
 #include "libavformat/internal.h"
 #include "libavutil/imgutils.h"
 }
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 3bc30f0..c7e3ef2 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -19,9 +19,15 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
-#include 
+#include 
+#include 
+#include 
+
+extern "C" {
+#include "libavformat/avformat.h"
 
 #include "decklink_common_c.h"
+}
 
 class decklink_output_callback;
 class decklink_input_callback;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index fb2b788..3644fb4 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -19,6 +19,8 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include "libavutil/log.h"
+
 struct decklink_cctx {
 const AVClass *cclass;
 
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 89f93de..da8e42b 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -21,11 +21,7 @@
 
 #include 
 
-#include 
-#include 
-
 extern "C" {
-#include "libavformat/avformat.h"
 #include "libavformat/internal.h"
 #include "libavutil/imgutils.h"
 }
diff --git a/libavdevice/decklink_dec.h b/libavdevice/decklink_dec.h
index 6bd9226..c499bc9 100644
--- a/libavdevice/decklink_dec.h
+++ b/libavdevice/decklink_dec.h
@@ -23,6 +23,8 @@
 extern "C" {
 #endif
 
+#include "libavformat/avformat.h"
+
 int ff_decklink_read_header(AVFormatContext *avctx);
 int ff_decklink_read_packet(AVFormatContext *avctx, AVPacket *pkt);
 int ff_decklink_read_close(AVFormatContext *avctx);
diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index 6c5450f..334c3dc 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -21,11 +21,7 @@
 
 #include 
 
-#include 
-#include 
-
 extern "C" {
-#include "libavformat/avformat.h"
 #include "libavformat/internal.h"
 #include "libavutil/imgutils.h"
 }
diff --git a/libavdevice/decklink_enc.h b/libavdevice/decklink_enc.h
index 6086947..23c59a2 100644
--- a/libavdevice/decklink_enc.h
+++ b/libavdevice/decklink_enc.h
@@ -23,6 +23,8 @@
 extern "C" {
 #endif
 
+#include "libavformat/avformat.h"
+
 int ff_decklink_write_header(AVFormatContext *avctx);
 int ff_decklink_write_packet(AVFormatContext *avctx, AVPacket *pkt);
 int ff_decklink_write_trailer(AVFormatContext *avctx);
-- 
2.1.4

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

[FFmpeg-devel] [PATCH 3/3] avdevice: Mark decklink_common.h as unconditional SKIPHEADER

[Timothy Gu]

It is a C++ file, incompatible with the checkheaders infrastructure.
---
 libavdevice/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavdevice/Makefile b/libavdevice/Makefile
index f57ec0b..8394e87 100644
--- a/libavdevice/Makefile
+++ b/libavdevice/Makefile
@@ -58,8 +58,9 @@ OBJS-$(HAVE_LIBC_MSVCRT) += file_open.o
 # Windows resource file
 SLIBOBJS-$(HAVE_GNU_WINDRES) += avdeviceres.o
 
+SKIPHEADERS  += decklink_common.h
 SKIPHEADERS-$(CONFIG_DECKLINK)   += decklink_enc.h decklink_dec.h \
-decklink_common.h 
decklink_common_c.h
+decklink_common_c.h
 SKIPHEADERS-$(CONFIG_DSHOW_INDEV)+= dshow_capture.h
 SKIPHEADERS-$(CONFIG_FBDEV_INDEV)+= fbdev_common.h
 SKIPHEADERS-$(CONFIG_FBDEV_OUTDEV)   += fbdev_common.h
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH] avformat/mp3dec: prefer "fast_seek" to TOC seek for CBR files.

[Chris Cunningham]

Thanks wm4, next patch will fix that declaration.

Michael, any concerns?

On Mon, Nov 30, 2015 at 2:51 PM, wm4  wrote:

> On Mon, 30 Nov 2015 14:29:50 -0800
> chcunning...@chromium.org wrote:
>
> > From: Chris Cunningham 
> >
> > "Fast seek" uses linear interpolation to find the position of the
> > requested seek time. For CBR this is more direct than using the
> > mp3 TOC and bypassing the TOC avoids problems with TOC precision.
> > (see https://crbug.com/545914#c13)
> >
> > For VBR, fast seek is not precise, so continue to prefer the TOC
> > when available (the lesser of two evils).
> >
> > Also, some re-ordering of the logic in mp3_seek to simplify and
> > give usetoc=1 precedence over fastseek flag.
> > ---
> >  libavformat/mp3dec.c| 42 --
> >  libavformat/seek-test.c |  8 +---
> >  tests/fate/seek.mak |  2 +-
> >  3 files changed, 26 insertions(+), 26 deletions(-)
> >
> > diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> > index 32ca00c..3dc2b5c 100644
> > --- a/libavformat/mp3dec.c
> > +++ b/libavformat/mp3dec.c
> > @@ -115,7 +115,8 @@ static void read_xing_toc(AVFormatContext *s,
> int64_t filesize, int64_t duration
> >  {
> >  int i;
> >  MP3DecContext *mp3 = s->priv_data;
> > -int fill_index = mp3->usetoc == 1 && duration > 0;
> > +int fast_seek = s->flags & AVFMT_FLAG_FAST_SEEK;
> > +int fill_index = (mp3->usetoc || fast_seek) && duration > 0;
> >
> >  if (!filesize &&
> >  !(filesize = avio_size(s->pb))) {
> > @@ -344,9 +345,6 @@ static int mp3_read_header(AVFormatContext *s)
> >  int ret;
> >  int i;
> >
> > -if (mp3->usetoc < 0)
> > -mp3->usetoc = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 2;
> > -
> >  st = avformat_new_stream(s, NULL);
> >  if (!st)
> >  return AVERROR(ENOMEM);
> > @@ -501,38 +499,38 @@ static int mp3_seek(AVFormatContext *s, int
> stream_index, int64_t timestamp,
> >  MP3DecContext *mp3 = s->priv_data;
> >  AVIndexEntry *ie, ie1;
> >  AVStream *st = s->streams[0];
> > -int64_t ret  = av_index_search_timestamp(st, timestamp, flags);
> > -int64_t best_pos;
> > -int fast_seek = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 0;
> > +int fast_seek = s->flags & AVFMT_FLAG_FAST_SEEK;
> >  int64_t filesize = mp3->header_filesize;
> >
> > -if (mp3->usetoc == 2)
> > -return -1; // generic index code
> > -
> >  if (filesize <= 0) {
> >  int64_t size = avio_size(s->pb);
> >  if (size > 0 && size > s->internal->data_offset)
> >  filesize = size - s->internal->data_offset;
> >  }
> >
> > -if (   (mp3->is_cbr || fast_seek)
> > -&& (mp3->usetoc == 0 || !mp3->xing_toc)
> > -&& st->duration > 0
> > -&& filesize > 0) {
> > -ie = 
> > -timestamp = av_clip64(timestamp, 0, st->duration);
> > -ie->timestamp = timestamp;
> > -ie->pos   = av_rescale(timestamp, filesize, st->duration) +
> s->internal->data_offset;
> > -} else if (mp3->xing_toc) {
> > +if (mp3->xing_toc && (mp3->usetoc || (fast_seek && !mp3->is_cbr))) {
> > +// NOTE: The MP3 TOC is not a precise lookup table. Accuracy is
> worse
> > +// for bigger files.
> > +av_log(s, AV_LOG_WARNING, "Using MP3 TOC to seek; may be
> imprecise.\n");
> > +
> > +int64_t ret  = av_index_search_timestamp(st, timestamp, flags);
> >  if (ret < 0)
> >  return ret;
> >
> >  ie = >index_entries[ret];
> > +} else if (fast_seek && st->duration > 0 && filesize > 0) {
> > +if (!mp3->is_cbr)
> > +av_log(s, AV_LOG_WARNING, "Using scaling to seek VBR MP3;
> may be imprecise.\n");
> > +
> > +ie = 
> > +timestamp = av_clip64(timestamp, 0, st->duration);
> > +ie->timestamp = timestamp;
> > +ie->pos   = av_rescale(timestamp, filesize, st->duration) +
> s->internal->data_offset;
> >  } else {
> > -return -1;
> > +return -1; // generic index code
> >  }
> >
> > -best_pos = mp3_sync(s, ie->pos, flags);
> > +int64_t best_pos = mp3_sync(s, ie->pos, flags);
>
> We don't like having declarations after statements.
>
> >  if (best_pos < 0)
> >  return best_pos;
> >
> > @@ -546,7 +544,7 @@ static int mp3_seek(AVFormatContext *s, int
> stream_index, int64_t timestamp,
> >  }
> >
> >  static const AVOption options[] = {
> > -{ "usetoc", "use table of contents", offsetof(MP3DecContext,
> usetoc), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 2, AV_OPT_FLAG_DECODING_PARAM},
> > +{ "usetoc", "use table of contents", offsetof(MP3DecContext,
> usetoc), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM},
> >  { NULL },
> >  };
> >
> > diff --git a/libavformat/seek-test.c b/libavformat/seek-test.c
> > index 1926f21..bfd06db 100644
> > --- a/libavformat/seek-test.c
> > +++ b/libavformat/seek-test.c
> 

[FFmpeg-devel] [PATCH] avformat/mp3dec: prefer "fast_seek" to TOC seek for CBR files.

[chcunningham]

From: Chris Cunningham 

"Fast seek" uses linear interpolation to find the position of the
requested seek time. For CBR this is more direct than using the
mp3 TOC and bypassing the TOC avoids problems with TOC precision.
(see https://crbug.com/545914#c13)

For VBR, fast seek is not precise, so continue to prefer the TOC
when available (the lesser of two evils).

Also, some re-ordering of the logic in mp3_seek to simplify and
give usetoc=1 precedence over fastseek flag.
---
 libavformat/mp3dec.c| 39 +++
 libavformat/seek-test.c |  8 +---
 tests/fate/seek.mak |  2 +-
 3 files changed, 25 insertions(+), 24 deletions(-)

diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 32ca00c..04c9861 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -115,7 +115,8 @@ static void read_xing_toc(AVFormatContext *s, int64_t 
filesize, int64_t duration
 {
 int i;
 MP3DecContext *mp3 = s->priv_data;
-int fill_index = mp3->usetoc == 1 && duration > 0;
+int fast_seek = s->flags & AVFMT_FLAG_FAST_SEEK;
+int fill_index = (mp3->usetoc || fast_seek) && duration > 0;
 
 if (!filesize &&
 !(filesize = avio_size(s->pb))) {
@@ -344,9 +345,6 @@ static int mp3_read_header(AVFormatContext *s)
 int ret;
 int i;
 
-if (mp3->usetoc < 0)
-mp3->usetoc = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 2;
-
 st = avformat_new_stream(s, NULL);
 if (!st)
 return AVERROR(ENOMEM);
@@ -501,35 +499,36 @@ static int mp3_seek(AVFormatContext *s, int stream_index, 
int64_t timestamp,
 MP3DecContext *mp3 = s->priv_data;
 AVIndexEntry *ie, ie1;
 AVStream *st = s->streams[0];
-int64_t ret  = av_index_search_timestamp(st, timestamp, flags);
 int64_t best_pos;
-int fast_seek = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 0;
+int fast_seek = s->flags & AVFMT_FLAG_FAST_SEEK;
 int64_t filesize = mp3->header_filesize;
 
-if (mp3->usetoc == 2)
-return -1; // generic index code
-
 if (filesize <= 0) {
 int64_t size = avio_size(s->pb);
 if (size > 0 && size > s->internal->data_offset)
 filesize = size - s->internal->data_offset;
 }
 
-if (   (mp3->is_cbr || fast_seek)
-&& (mp3->usetoc == 0 || !mp3->xing_toc)
-&& st->duration > 0
-&& filesize > 0) {
-ie = 
-timestamp = av_clip64(timestamp, 0, st->duration);
-ie->timestamp = timestamp;
-ie->pos   = av_rescale(timestamp, filesize, st->duration) + 
s->internal->data_offset;
-} else if (mp3->xing_toc) {
+if (mp3->xing_toc && (mp3->usetoc || (fast_seek && !mp3->is_cbr))) {
+// NOTE: The MP3 TOC is not a precise lookup table. Accuracy is worse
+// for bigger files.
+av_log(s, AV_LOG_WARNING, "Using MP3 TOC to seek; may be 
imprecise.\n");
+
+int64_t ret = av_index_search_timestamp(st, timestamp, flags);
 if (ret < 0)
 return ret;
 
 ie = >index_entries[ret];
+} else if (fast_seek && st->duration > 0 && filesize > 0) {
+if (!mp3->is_cbr)
+av_log(s, AV_LOG_WARNING, "Using scaling to seek VBR MP3; may be 
imprecise.\n");
+
+ie = 
+timestamp = av_clip64(timestamp, 0, st->duration);
+ie->timestamp = timestamp;
+ie->pos   = av_rescale(timestamp, filesize, st->duration) + 
s->internal->data_offset;
 } else {
-return -1;
+return -1; // generic index code
 }
 
 best_pos = mp3_sync(s, ie->pos, flags);
@@ -546,7 +545,7 @@ static int mp3_seek(AVFormatContext *s, int stream_index, 
int64_t timestamp,
 }
 
 static const AVOption options[] = {
-{ "usetoc", "use table of contents", offsetof(MP3DecContext, usetoc), 
AV_OPT_TYPE_INT, {.i64 = -1}, -1, 2, AV_OPT_FLAG_DECODING_PARAM},
+{ "usetoc", "use table of contents", offsetof(MP3DecContext, usetoc), 
AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM},
 { NULL },
 };
 
diff --git a/libavformat/seek-test.c b/libavformat/seek-test.c
index 1926f21..bfd06db 100644
--- a/libavformat/seek-test.c
+++ b/libavformat/seek-test.c
@@ -56,7 +56,7 @@ static void ts_str(char buffer[60], int64_t ts, AVRational 
base)
 int main(int argc, char **argv)
 {
 const char *filename;
-AVFormatContext *ic = NULL;
+AVFormatContext *ic = avformat_alloc_context();
 int i, ret, stream_id;
 int j;
 int64_t timestamp;
@@ -76,8 +76,10 @@ int main(int argc, char **argv)
 frame_count = atoi(argv[i+1]);
 } else if(!strcmp(argv[i], "-duration")){
 duration = atoi(argv[i+1]);
-} else if(!strcmp(argv[i], "-usetoc")) {
-av_dict_set(_opts, "usetoc", argv[i+1], 0);
+} else if(!strcmp(argv[i], "-fastseek")) {
+if (atoi(argv[i+1])) {
+ic->flags |= AVFMT_FLAG_FAST_SEEK;
+}
 } else {
 argc = 1;
 }
diff --git 

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

[Paul B Mahol]

On 12/1/15, Nicolas George  wrote:
> Le primidi 11 frimaire, an CCXXIV, Paul B Mahol a ecrit :
>> Similar how its freed when no longer used.
>
> Please elaborate. I know the API, I do not see what you suggest.
>
> (Thanks for trimming.)
>
> Regards,

After carefully looking at this functon, I see no leaking at all.

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

[FFmpeg-devel] [PATCH] avfilter/vf_shuffleframes: Assert that the case of an uninitialized ret does not occur

[Michael Niedermayer]

From: Michael Niedermayer 

Fixes CID1258479

Signed-off-by: Michael Niedermayer 
---
 libavfilter/vf_shuffleframes.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_shuffleframes.c b/libavfilter/vf_shuffleframes.c
index 041429f..f49c9c6 100644
--- a/libavfilter/vf_shuffleframes.c
+++ b/libavfilter/vf_shuffleframes.c
@@ -18,6 +18,7 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include "libavutil/avassert.h"
 #include "libavutil/avstring.h"
 #include "libavutil/common.h"
 #include "libavutil/internal.h"
@@ -90,9 +91,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
 s->pts[s->in_frames] = frame->pts;
 s->in_frames++;
 ret = 0;
-}
-
-if (s->in_frames == s->nb_frames) {
+} else if (s->in_frames == s->nb_frames) {
 int n, x;
 
 for (n = 0; n < s->nb_frames; n++) {
@@ -109,7 +108,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 
 for (n = 0; n < s->nb_frames; n++)
 av_frame_free(>frames[n]);
-}
+} else
+av_assert0(0);
 
 return ret;
 }
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_shuffleframes: Assert that the case of an uninitialized ret does not occur

[Paul B Mahol]

On 12/1/15, Michael Niedermayer  wrote:
> From: Michael Niedermayer 
>
> Fixes CID1258479
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavfilter/vf_shuffleframes.c |8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>

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

[FFmpeg-devel] Does FFplay support HEVC interlaced bitstream display?

[Fan Yingming]

Hi, everyone.

I noticed that HEVC support interlaced field encoding, but FFplay didn't
support HEVC interlaced bitstream display.

We know FFplay play h264 interlaced bitstream perfectly.

I'd like to know if FFplay support HEVC interlaced bitstream display.
And will FFmpeg support that?

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

Re: [FFmpeg-devel] [PATCH 1/7] lavf: add API to apply a list of bsfs to a packet

[Moritz Barsnick]

On Mon, Nov 30, 2015 at 18:05:25 -0600, Rodger Combs wrote:
>  libavformat/avformat.h | 11 +++
>  libavformat/utils.c| 49 +
>  2 files changed, 60 insertions(+)

I would find it useful to have an informational message (at least in
loglevel debug, perhaps even in loglevel default) about automatically
inserted bitstream filters.

OTOH (unrelated), currently, even explicitly inserted bitstream filters
don't mention themselves in logs at all. Whereas, in loglevel debug, I
can observe every implicit and explicit video/audio filter and its
connections.

Thanks for the patchset, BTW. I think it removes one of my biggest
personal grudges against ffmpeg and its usage. ;-)

(Untested, BTW.)

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

[FFmpeg-devel] [PATCH] vp9: always keep s->bytesperpixel and ctx->pix_fmt in sync.

[Ronald S. Bultje]

Fixes mozilla bug 1229128.
---
 libavcodec/vp9.c | 43 ++-
 1 file changed, 22 insertions(+), 21 deletions(-)

diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index d4061e2..9bf746c 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -69,6 +69,7 @@ typedef struct VP9Context {
 uint8_t ss_h, ss_v;
 uint8_t last_bpp, bpp, bpp_index, bytesperpixel;
 uint8_t last_keyframe;
+enum AVPixelFormat last_fmt;
 ThreadFrame next_refs[8];
 
 struct {
@@ -211,7 +212,7 @@ static int vp9_ref_frame(AVCodecContext *ctx, VP9Frame 
*dst, VP9Frame *src)
 return 0;
 }
 
-static int update_size(AVCodecContext *ctx, int w, int h, enum AVPixelFormat 
fmt)
+static int update_size(AVCodecContext *ctx, int w, int h)
 {
 VP9Context *s = ctx->priv_data;
 uint8_t *p;
@@ -219,12 +220,12 @@ static int update_size(AVCodecContext *ctx, int w, int h, 
enum AVPixelFormat fmt
 
 av_assert0(w > 0 && h > 0);
 
-if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height && 
ctx->pix_fmt == fmt)
+if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height && 
ctx->pix_fmt == s->last_fmt)
 return 0;
 
 if ((res = ff_set_dimensions(ctx, w, h)) < 0)
 return res;
-ctx->pix_fmt = fmt;
+s->last_fmt  = ctx->pix_fmt;
 s->sb_cols   = (w + 63) >> 6;
 s->sb_rows   = (h + 63) >> 6;
 s->cols  = (w + 7) >> 3;
@@ -383,14 +384,13 @@ static int update_prob(VP56RangeCoder *c, int p)
 255 - inv_recenter_nonneg(inv_map_table[d], 255 - p);
 }
 
-static enum AVPixelFormat read_colorspace_details(AVCodecContext *ctx)
+static int read_colorspace_details(AVCodecContext *ctx)
 {
 static const enum AVColorSpace colorspaces[8] = {
 AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709, 
AVCOL_SPC_SMPTE170M,
 AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED, 
AVCOL_SPC_RGB,
 };
 VP9Context *s = ctx->priv_data;
-enum AVPixelFormat res;
 int bits = ctx->profile <= 1 ? 0 : 1 + get_bits1(>gb); // 0:8, 1:10, 
2:12
 
 s->bpp_index = bits;
@@ -401,10 +401,10 @@ static enum AVPixelFormat 
read_colorspace_details(AVCodecContext *ctx)
 static const enum AVPixelFormat pix_fmt_rgb[3] = {
 AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12
 };
+s->ss_h = s->ss_v = 0;
+ctx->color_range = AVCOL_RANGE_JPEG;
+ctx->pix_fmt = pix_fmt_rgb[bits];
 if (ctx->profile & 1) {
-s->ss_h = s->ss_v = 0;
-res = pix_fmt_rgb[bits];
-ctx->color_range = AVCOL_RANGE_JPEG;
 if (get_bits1(>gb)) {
 av_log(ctx, AV_LOG_ERROR, "Reserved bit set in RGB\n");
 return AVERROR_INVALIDDATA;
@@ -427,7 +427,8 @@ static enum AVPixelFormat 
read_colorspace_details(AVCodecContext *ctx)
 if (ctx->profile & 1) {
 s->ss_h = get_bits1(>gb);
 s->ss_v = get_bits1(>gb);
-if ((res = pix_fmt_for_ss[bits][s->ss_v][s->ss_h]) == 
AV_PIX_FMT_YUV420P) {
+ctx->pix_fmt = pix_fmt_for_ss[bits][s->ss_v][s->ss_h];
+if (ctx->pix_fmt == AV_PIX_FMT_YUV420P) {
 av_log(ctx, AV_LOG_ERROR, "YUV 4:2:0 not supported in profile 
%d\n",
ctx->profile);
 return AVERROR_INVALIDDATA;
@@ -438,11 +439,11 @@ static enum AVPixelFormat 
read_colorspace_details(AVCodecContext *ctx)
 }
 } else {
 s->ss_h = s->ss_v = 1;
-res = pix_fmt_for_ss[bits][1][1];
+ctx->pix_fmt = pix_fmt_for_ss[bits][1][1];
 }
 }
 
-return res;
+return 0;
 }
 
 static int decode_frame_header(AVCodecContext *ctx,
@@ -450,7 +451,6 @@ static int decode_frame_header(AVCodecContext *ctx,
 {
 VP9Context *s = ctx->priv_data;
 int c, i, j, k, l, m, n, w, h, max, size2, res, sharp;
-enum AVPixelFormat fmt = ctx->pix_fmt;
 int last_invisible;
 const uint8_t *data2;
 
@@ -486,8 +486,8 @@ static int decode_frame_header(AVCodecContext *ctx,
 av_log(ctx, AV_LOG_ERROR, "Invalid sync code\n");
 return AVERROR_INVALIDDATA;
 }
-if ((fmt = read_colorspace_details(ctx)) < 0)
-return fmt;
+if ((res = read_colorspace_details(ctx)) < 0)
+return res;
 // for profile 1, here follows the subsampling bits
 s->s.h.refreshrefmask = 0xff;
 w = get_bits(>gb, 16) + 1;
@@ -503,14 +503,14 @@ static int decode_frame_header(AVCodecContext *ctx,
 return AVERROR_INVALIDDATA;
 }
 if (ctx->profile >= 1) {
-if ((fmt = read_colorspace_details(ctx)) < 0)
-return fmt;
+if ((res = read_colorspace_details(ctx)) < 0)
+return res;
 } else {
 s->ss_h = s->ss_v = 1;
 s->bpp = 8;
 s->bpp_index = 0;
  

[FFmpeg-devel] [PATCH] avutil/threadmessage: fix condition broadcasting

[Clément Bœsch]

From: Clément Bœsch 

Fix a dead lock under certain conditions. Let's assume we have a queue of 1
message max, 2 senders, and 1 receiver.

Scenario (real record obtained with debug added):
[...]
SENDER #0: acquired lock
SENDER #0: queue is full, wait
SENDER #1: acquired lock
SENDER #1: queue is full, wait
RECEIVER: acquired lock
RECEIVER: reading a msg from the queue
RECEIVER: signal the cond
RECEIVER: acquired lock
RECEIVER: queue is empty, wait
SENDER #0: writing a msg the queue
SENDER #0: signal the cond
SENDER #0: acquired lock
SENDER #0: queue is full, wait
SENDER #1: queue is full, wait

Translated:
 - initially the queue contains 1/1 message with 2 senders blocking on
   it, waiting to push another message.
 - Meanwhile the receiver is obtaining the lock, read the message,
   signal & release the lock. For some reason it is able to acquire the
   lock again before the signal wakes up one of the sender. Since it
   just emptied the queue, the reader waits for the queue to fill up
   again.
 - The signal finally reaches one of the sender, which writes a message
   and then signal the condition. Unfortunately, instead of waking up
   the reader, it actually wakes up the other worker (signal = notify
   the condition just for 1 waiter), who can't push another message in
   the queue because it's full.
 - Meanwhile, the receiver is still waiting. Deadlock.

This scenario can be triggered with for example:
tests/api/api-threadmessage-test 2 1 100 100 999

The fix is simply to make sure to notify everyone when work is done (be
it reading or writing). Another solution would be to use 2 distincts
conditions.
---
 libavutil/threadmessage.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c
index b7fcbe2..2089c6d 100644
--- a/libavutil/threadmessage.c
+++ b/libavutil/threadmessage.c
@@ -107,7 +107,7 @@ static int 
av_thread_message_queue_send_locked(AVThreadMessageQueue *mq,
 if (mq->err_send)
 return mq->err_send;
 av_fifo_generic_write(mq->fifo, msg, mq->elsize, NULL);
-pthread_cond_signal(>cond);
+pthread_cond_broadcast(>cond);
 return 0;
 }
 
@@ -123,7 +123,7 @@ static int 
av_thread_message_queue_recv_locked(AVThreadMessageQueue *mq,
 if (av_fifo_size(mq->fifo) < mq->elsize)
 return mq->err_recv;
 av_fifo_generic_read(mq->fifo, msg, mq->elsize, NULL);
-pthread_cond_signal(>cond);
+pthread_cond_broadcast(>cond);
 return 0;
 }
 
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double

[Michael Niedermayer]

On Mon, Nov 30, 2015 at 08:03:41PM -0800, Muhammad Faiz wrote:
> On Mon, Nov 30, 2015 at 12:06 PM, Michael Niedermayer  
> wrote:
> > On Mon, Nov 30, 2015 at 07:02:47PM +0100, Nicolas George wrote:
> >> Le decadi 10 frimaire, an CCXXIV, Michael Niedermayer a écrit :
> >> > > ISO/IEC 9899:TC3
> >> > > 5.2.4.2.2 Characteristics of floating types 
> >> > >
> >> > > 8 Except for assignment and cast (which remove all extra range and 
> >> > > precision), the values
> >> > > of operations with floating operands and values subject to the 
> >> > > usual arithmetic
> >> > > conversions and of floating constants are evaluated to a format 
> >> > > whose range and precision
> >> > > may be greater than required by the type. The use of evaluation 
> >> > > formats is characterized
> >> > > by the implementation-defined value of FLT_EVAL_METHOD:19)
> >> > > -1   indeterminable;
> >> > > 0   evaluate all operations and constants just to the 
> >> > > range and precision of the
> >> > > type;
> >> > > 1   evaluate operations and constants of type float and 
> >> > > double to the
> >> > > range and precision of the double type, evaluate long 
> >> > > double
> >> > > operations and constants to the range and precision of 
> >> > > the long double
> >> > > type;
> >> > > 2   evaluate all operations and constants to the range and 
> >> > > precision of the
> >> > > long double type.
> >> > > All other negative values for FLT_EVAL_METHOD characterize 
> >> > > implementation-defined
> >> > > behavior.
> >> >
> >> > a few more related parts:
> >> > 5 The accuracy of the floating-point operations (+, -, *, /) and of 
> >> > the library functions in
> >> >  and  that return floating-point results is 
> >> > implementation-
> >> > defined, as is the accuracy of the conversion between floating-point 
> >> > internal
> >> > representations and string representations performed by the library 
> >> > functions in
> >> > , , and . The implementation may state 
> >> > that the
> >> > accuracy is unknown.
> >> >
> >> > 6.4.4.2 Floating constants
> >> > 7 The translation-time conversion of floating constants should match 
> >> > the execution-time
> >> > conversion of character strings by library functions, such as 
> >> > strtod, given matching
> >> > inputs suitable for both conversions, the same result format, and 
> >> > default execution-time
> >> > rounding.64)
> >>
> >> I am not sure why you quoting this. Are you implying this is not a compiler
> >> bug, the compiler is actually allowed to do that? Possible. But still, I do
> >
> > yes, i suspect that is not a compiler bug but i certainly do not have
> > deep enough knowledge of C to say that for sure
> >
> >
> >> not think we should apply this unless we actually understand what is going
> >> on here, why a cast that should not change anything does change the result.
> >> Otherwise, it could just be a coincidence, and break in a different way on 
> >> a
> >> different compiler.
> >
> > I would not be surprised if a strict and litteral reading of C would
> > allow that still to fail, but then theres the question if such
> > equals check is even possible in C in such a strict reading of the
> > standard.
> > and theres also IEEE ...
> 
> But at least the standard said:
> 'Except for assignment and cast (which remove all extra range and precision)'
> so we can be sure that BASEFREQ is in double precision
> when casted to double.
> So, this patch should be OK
> 
> >
> > One could use a special value as default like -1 and check for that
> > which may be less likely to cause problems with float accuracy and
> > rounding in case the cast does not work on some real world case or
> > if the risk of it failing on some obscure plaform should be avoided
> 
> Unless the platform which makes this patch useless is reported,
> the patch should be OK for workaround.

yes
nicolas are you ok with this being applied ? (IIRC you objected to it)

language lawyering note: in a strict reading the standard the 2
occurances of the constant do probably not need to be parsed with teh
same precission nor with precission better or equal than "double".
In that case the code from the patch can fail and probably more or
less every clean alternative could too

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

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


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

Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double

[Nicolas George]

Le primidi 11 frimaire, an CCXXIV, Michael Niedermayer a écrit :
> nicolas are you ok with this being applied ? (IIRC you objected to it)

I am not really satisfied but I do not object. Hopefully it will not break
again.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double

[Ganesh Ajjanagadde]

On Tue, Dec 1, 2015 at 10:38 AM, Nicolas George  wrote:
> Le primidi 11 frimaire, an CCXXIV, Michael Niedermayer a écrit :
>> nicolas are you ok with this being applied ? (IIRC you objected to it)
>
> I am not really satisfied but I do not object. Hopefully it will not break
> again.

same here - it seems like the heart of the matter is really not well
understood, and someone down the road may see the code and wonder why
the cast is being done. Hopefully the git blame still points to this
change.

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

[FFmpeg-devel] [PATCH] avfilter: add audio emphasis filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 configure  |   3 +
 doc/filters.texi   |  46 ++
 libavfilter/Makefile   |   1 +
 libavfilter/af_aemphasis.c | 354 +
 libavfilter/allfilters.c   |   1 +
 5 files changed, 405 insertions(+)
 create mode 100644 libavfilter/af_aemphasis.c

diff --git a/configure b/configure
index a30d831..7f3d3de 100755
--- a/configure
+++ b/configure
@@ -1771,8 +1771,10 @@ INTRINSICS_LIST="
 MATH_FUNCS="
 atanf
 atan2f
+cabs
 cbrt
 cbrtf
+cexp
 copysign
 cosf
 erf
@@ -2785,6 +2787,7 @@ unix_protocol_deps="sys_un_h"
 unix_protocol_select="network"
 
 # filters
+aemphasis_filter_deps="cabs cexp"
 amovie_filter_deps="avcodec avformat"
 aresample_filter_deps="swresample"
 ass_filter_deps="libass"
diff --git a/doc/filters.texi b/doc/filters.texi
index fc71a99..1303045 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -528,6 +528,52 @@ aecho=0.8:0.9:1000|1800:0.3|0.25
 @end example
 @end itemize
 
+@section aemphasis
+Audio emphasis filter creates or restores material directly taken from LPs or
+emphased CDs with different filter curves. E.g. to store music on vinyl the
+signal has to be altered by a filter first to even out the disadvantages of
+this recording medium.
+Once the material is played back the inverse filter has to be applied to
+restore the distortion of the frequency response.
+
+The filter accepts the following options:
+
+@table @option
+@item level_in
+Set input gain.
+
+@item level_out
+Set output gain.
+
+@item mode
+Set filter mode. For restoring material use @code{reproduction} mode, otherwise
+use @code{production} mode. Default is @code{reproduction} mode.
+
+@item type
+Set filter type. Selects medium. Can be one of the following:
+
+@table @option
+@item col
+select Columbia.
+@item emi
+select EMI.
+@item bsi
+select BSI (78RPM).
+@item riaa
+select RIAA.
+@item cd
+select Compat Disc (CD).
+@item 50fm
+select 50µs (FM).
+@item 75fm
+select 75µs (FM).
+@item 50kf
+select 50µs (FM-KF).
+@item 75kf
+select 75µs (FM-KF).
+@end table
+@end table
+
 @section aeval
 
 Modify an audio signal according to the specified expressions.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e31bdaa..7a42948 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -27,6 +27,7 @@ OBJS-$(CONFIG_ACOMPRESSOR_FILTER)+= 
af_sidechaincompress.o
 OBJS-$(CONFIG_ACROSSFADE_FILTER) += af_afade.o
 OBJS-$(CONFIG_ADELAY_FILTER) += af_adelay.o
 OBJS-$(CONFIG_AECHO_FILTER)  += af_aecho.o
+OBJS-$(CONFIG_AEMPHASIS_FILTER)  += af_aemphasis.o
 OBJS-$(CONFIG_AEVAL_FILTER)  += aeval.o
 OBJS-$(CONFIG_AFADE_FILTER)  += af_afade.o
 OBJS-$(CONFIG_AFORMAT_FILTER)+= af_aformat.o
diff --git a/libavfilter/af_aemphasis.c b/libavfilter/af_aemphasis.c
new file mode 100644
index 000..80c65d0
--- /dev/null
+++ b/libavfilter/af_aemphasis.c
@@ -0,0 +1,354 @@
+/*
+ * Copyright (c) 2001-2010 Krzysztof Foltman, Markus Schmidt, Thor Harald 
Johansen, Damien Zammit and others
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "internal.h"
+#include "audio.h"
+
+typedef struct BiquadCoeffs {
+double a0, a1, a2, b1, b2;
+} BiquadCoeffs;
+
+typedef struct BiquadD2 {
+double a0, a1, a2, b1, b2, w1, w2;
+} BiquadD2;
+
+typedef struct RIAACurve {
+BiquadD2 r1;
+BiquadD2 brickw;
+int use_brickw;
+} RIAACurve;
+
+typedef struct AudioEmphasisContext {
+const AVClass *class;
+int mode, type;
+double level_in, level_out;
+
+RIAACurve *rc;
+} AudioEmphasisContext;
+
+#define OFFSET(x) offsetof(AudioEmphasisContext, x)
+#define FLAGS AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption aemphasis_options[] = {
+{ "level_in",  "set input gain", OFFSET(level_in),  
AV_OPT_TYPE_DOUBLE, {.dbl=1}, 0, 64, FLAGS },
+{ "level_out","set output gain", OFFSET(level_out), 
AV_OPT_TYPE_DOUBLE, {.dbl=1}, 0, 64, FLAGS },
+{ "mode", "set filter mode", OFFSET(mode), AV_OPT_TYPE_INT,   
{.i64=0}, 0, 1, FLAGS, 

[FFmpeg-devel] [PATCH 1/2] avutil/mathematics: return INT64_MIN (=AV_NOPTS_VALUE) from av_rescale_rnd() for overflows

[Michael Niedermayer]

From: Michael Niedermayer 

Fixes integer overflow
Fixes: mozilla bug 1229167

Found-by: Tyson Smith
Signed-off-by: Michael Niedermayer 
---
 libavutil/mathematics.c |   13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/libavutil/mathematics.c b/libavutil/mathematics.c
index 689325f..c12c73e 100644
--- a/libavutil/mathematics.c
+++ b/libavutil/mathematics.c
@@ -72,7 +72,7 @@ int64_t av_rescale_rnd(int64_t a, int64_t b, int64_t c, enum 
AVRounding rnd)
 }
 
 if (a < 0)
-return -av_rescale_rnd(-FFMAX(a, -INT64_MAX), b, c, rnd ^ ((rnd >> 1) 
& 1));
+return -(uint64_t)av_rescale_rnd(-FFMAX(a, -INT64_MAX), b, c, rnd ^ 
((rnd >> 1) & 1));
 
 if (rnd == AV_ROUND_NEAR_INF)
 r = c / 2;
@@ -82,8 +82,13 @@ int64_t av_rescale_rnd(int64_t a, int64_t b, int64_t c, enum 
AVRounding rnd)
 if (b <= INT_MAX && c <= INT_MAX) {
 if (a <= INT_MAX)
 return (a * b + r) / c;
-else
-return a / c * b + (a % c * b + r) / c;
+else {
+int64_t ad = a / c;
+int64_t a2 = (a % c * b + r) / c;
+if (ad >= INT32_MAX && ad > (INT64_MAX - a2) / b)
+return INT64_MIN;
+return ad * b + a2;
+}
 } else {
 #if 1
 uint64_t a0  = a & 0x;
@@ -107,6 +112,8 @@ int64_t av_rescale_rnd(int64_t a, int64_t b, int64_t c, 
enum AVRounding rnd)
 t1++;
 }
 }
+if (t1 > INT64_MAX)
+return INT64_MIN;
 return t1;
 }
 #else
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH 2/2] avutil/rational: Test av_rescale_rnd() with combinations of "special" values

[Michael Niedermayer]

From: Michael Niedermayer 

Signed-off-by: Michael Niedermayer 
---
 libavutil/Makefile   |1 +
 libavutil/rational.c |   44 
 2 files changed, 45 insertions(+)

diff --git a/libavutil/Makefile b/libavutil/Makefile
index 1bac2b9..b43cede 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -106,6 +106,7 @@ OBJS = adler32.o
\
hash.o   \
hmac.o   \
imgutils.o   \
+   integer.o\
intmath.o\
lfg.o\
lls.o\
diff --git a/libavutil/rational.c b/libavutil/rational.c
index 81a9402..6b3f50a 100644
--- a/libavutil/rational.c
+++ b/libavutil/rational.c
@@ -183,9 +183,18 @@ uint32_t av_q2intfloat(AVRational q) {
 }
 
 #ifdef TEST
+
+#include "integer.h"
+
 int main(void)
 {
 AVRational a,b,r;
+int i,j,k;
+static const int64_t numlist[] = {
+INT64_MIN, INT64_MIN+1, INT64_MAX, INT32_MIN, INT32_MAX, 1,0,-1,
+123456789, INT32_MAX-1, INT32_MAX+1LL, UINT32_MAX-1, UINT32_MAX, 
UINT32_MAX+1LL
+};
+
 for (a.num = -2; a.num <= 2; a.num++) {
 for (a.den = -2; a.den <= 2; a.den++) {
 for (b.num = -2; b.num <= 2; b.num++) {
@@ -207,6 +216,41 @@ int main(void)
 }
 }
 
+for (i = 0; i < FF_ARRAY_ELEMS(numlist); i++) {
+int64_t a = numlist[i];
+
+for (j = 0; j < FF_ARRAY_ELEMS(numlist); j++) {
+int64_t b = numlist[j];
+if (b<=0)
+continue;
+for (k = 0; k < FF_ARRAY_ELEMS(numlist); k++) {
+int64_t c = numlist[k];
+int64_t res;
+AVInteger ai;
+
+if (c<=0)
+continue;
+res = av_rescale_rnd(a,b,c, AV_ROUND_ZERO);
+
+ai = av_mul_i(av_int2i(a), av_int2i(b));
+ai = av_div_i(ai, av_int2i(c));
+
+if (av_cmp_i(ai, av_int2i(INT64_MAX)) > 0 && res == INT64_MIN)
+continue;
+if (av_cmp_i(ai, av_int2i(INT64_MIN)) < 0 && res == INT64_MIN)
+continue;
+if (av_cmp_i(ai, av_int2i(res)) == 0)
+continue;
+
+// Special exception for INT64_MIN, remove this in case 
INT64_MIN is handled without off by 1 error
+if (av_cmp_i(ai, av_int2i(res-1)) == 0 && a == INT64_MIN)
+continue;
+
+av_log(NULL, AV_LOG_ERROR, "%"PRId64" * %"PRId64" / %"PRId64" 
= %"PRId64" or %"PRId64"\n", a,b,c, res, av_i2int(ai));
+}
+}
+}
+
 for (a.num = 1; a.num <= 10; a.num++) {
 for (a.den = 1; a.den <= 10; a.den++) {
 if (av_gcd(a.num, a.den) > 1)
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH] avfilter: add audio pulsator filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi   |  57 +
 libavfilter/Makefile   |   1 +
 libavfilter/af_apulsator.c | 279 +
 libavfilter/allfilters.c   |   1 +
 4 files changed, 338 insertions(+)
 create mode 100644 libavfilter/af_apulsator.c

diff --git a/doc/filters.texi b/doc/filters.texi
index fc71a99..a4afcac 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -1030,6 +1030,63 @@ It accepts the following values:
 @end table
 @end table
 
+@section apulsator
+
+Audio pulsator is something between an autopanner and a tremolo.
+But it can produce funny stereo effects as well. Pulsator changes the volume
+of the left and right channel based on a LFO (low frequency oscillator) with
+different waveforms and shifted phases.
+This filter have the ability to define an offset between left and right
+channel. An offset of 0 means that both LFO shapes match each other.
+The left and right channel are altered equally - a conventional tremolo.
+An offset of 50% means that the shape of the right channel is exactly shifted
+in phase (or moved backwards about half of the frequency) - pulsator acts as
+an autopanner. At 1 both curves match again. Every setting in between moves the
+phase shift gapless between all stages and produces some "bypassing" sounds 
with
+sine and triangle waveforms. The more you set the offset near 1 (starting from
+the 0.5) the faster the signal passes from the left to the right speaker.
+
+The filter accepts the following options:
+
+@table @option
+@item level_in
+Set input gain. By default it is 1. Range is [0.015625 - 64].
+
+@item level_out
+Set output gain. By default it is 1. Range is [0.015625 - 64].
+
+@item mode
+Set waveform shape the LFO will use. Can be one of: sine, triangle, square,
+sawup or sawdown. Default is sine.
+
+@item amount
+Set modulation. Define how much of original signal is affected by the LFO.
+
+@item offset_l
+Set left channel offset. Default is 0. Allowed range is [0 - 1].
+
+@item offset_r
+Set right channel offset. Default is 0.5. Allowed range is [0 - 1].
+
+@item width
+Set pulse width.
+
+@item timing
+Set possible timing mode. Can be one of: bpm, ms or hz. Default is hz.
+
+@item bpm
+Set bpm. Default is 120. Allowed range is [30 - 300]. Only used if timing
+is set to bpm.
+
+@item ms
+Set ms. Default is 500. Allowed range is [10 - 2000]. Only used if timing
+is set to ms.
+
+@item hz
+Set frequency in Hz. Default is 2. Allowed range is [0.01 - 100]. Only used
+if timing is set to hz.
+@end table
+
 @anchor{aresample}
 @section aresample
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e31bdaa..b6c0d7b 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -40,6 +40,7 @@ OBJS-$(CONFIG_ANULL_FILTER)  += af_anull.o
 OBJS-$(CONFIG_APAD_FILTER)   += af_apad.o
 OBJS-$(CONFIG_APERMS_FILTER) += f_perms.o
 OBJS-$(CONFIG_APHASER_FILTER)+= af_aphaser.o 
generate_wave_table.o
+OBJS-$(CONFIG_APULSATOR_FILTER)  += af_apulsator.o
 OBJS-$(CONFIG_AREALTIME_FILTER)  += f_realtime.o
 OBJS-$(CONFIG_ARESAMPLE_FILTER)  += af_aresample.o
 OBJS-$(CONFIG_AREVERSE_FILTER)   += f_reverse.o
diff --git a/libavfilter/af_apulsator.c b/libavfilter/af_apulsator.c
new file mode 100644
index 000..9100eff
--- /dev/null
+++ b/libavfilter/af_apulsator.c
@@ -0,0 +1,279 @@
+/*
+ * Copyright (c) 2001-2010 Krzysztof Foltman, Markus Schmidt, Thor Harald 
Johansen and others
+ *
+ * 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/opt.h"
+#include "avfilter.h"
+#include "internal.h"
+#include "audio.h"
+
+enum PulsatorModes { SINE, TRIANGLE, SQUARE, SAWUP, SAWDOWN, NB_MODES };
+enum PulsatorTimings { UNIT_BPM, UNIT_MS, UNIT_HZ, NB_TIMINGS };
+
+typedef struct SimpleLFO {
+double phase;
+double freq;
+double offset;
+double amount;
+double pwidth;
+int mode;
+int srate;
+} SimpleLFO;
+
+typedef struct AudioPulsatorContext {
+const AVClass *class;
+int mode;
+double level_in;
+double level_out;
+double amount;
+double offset_l;
+double offset_r;
+double pwidth;
+double bpm;
+ 

Re: [FFmpeg-devel] Does FFplay support HEVC interlaced bitstream display?

[Andy Furniss]

Fan Yingming wrote:

Hi, everyone.

I noticed that HEVC support interlaced field encoding, but FFplay
didn't support HEVC interlaced bitstream display.

We know FFplay play h264 interlaced bitstream perfectly.

I'd like to know if FFplay support HEVC interlaced bitstream
display. And will FFmpeg support that?


I don't think so.

It is possible to play hevc interlaced with ffmpeg via mpv but you'll
have to set up your own filter chain and possibly adjust for field order.

I've done it on a homemade (libx265) test. libx265 only takes a certain
field order and expects fields, plus interlaced support is (was) flagged
as experimental. It did seem to work though, it was a while ago so this
is just a paste from notes on the playback side - basically you need to
weave the fields that the decoder outputs as weaved frames is what other
decoders output.

mpv -fs --vf=lavfi=[tinterlace=merge,setsar=1/1,yadif=1] hevc-interl-5M.mkv

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

[FFmpeg-devel] FFMPEG API

[Yosef B]

Hi,
I'm new with ffmpeg, I'm using the (XX-57) version.

I have the following old code but I can't find the *avcodec_alloc_frame*:
AVPicture* pConvertedFrame = *avcodec_alloc_frame*();

*I get:  *
*error C3861: 'avcodec_alloc_frame': identifier not found *

I tried the *"*
*get_frame_defaults(pConvertedFrame);" *with no luck!!!

Any idea?

-- 

Best regards,

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

Re: [FFmpeg-devel] Does FFplay support HEVC interlaced bitstream display?

[wm4]

On Tue, 1 Dec 2015 12:12:13 +
Andy Furniss  wrote:

> Fan Yingming wrote:
> > Hi, everyone.
> >
> > I noticed that HEVC support interlaced field encoding, but FFplay
> > didn't support HEVC interlaced bitstream display.
> >
> > We know FFplay play h264 interlaced bitstream perfectly.
> >
> > I'd like to know if FFplay support HEVC interlaced bitstream
> > display. And will FFmpeg support that?  
> 
> I don't think so.
> 
> It is possible to play hevc interlaced with ffmpeg via mpv but you'll
> have to set up your own filter chain and possibly adjust for field order.
> 
> I've done it on a homemade (libx265) test. libx265 only takes a certain
> field order and expects fields, plus interlaced support is (was) flagged
> as experimental. It did seem to work though, it was a while ago so this
> is just a paste from notes on the playback side - basically you need to
> weave the fields that the decoder outputs as weaved frames is what other
> decoders output.
> 
> mpv -fs --vf=lavfi=[tinterlace=merge,setsar=1/1,yadif=1] hevc-interl-5M.mkv

Exactly the same (without the lavfi wrapper of course) should work on
ffplay.

So does this mean the HEVC decoder outputs separate fields only? This
is really odd, although I can understand why.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Does FFplay support HEVC interlaced bitstream display?

[Andy Furniss]

Hendrik Leppkes wrote:

On Tue, Dec 1, 2015 at 1:36 PM, wm4  wrote:

On Tue, 1 Dec 2015 12:12:13 + Andy Furniss
 wrote:


Fan Yingming wrote:

Hi, everyone.

I noticed that HEVC support interlaced field encoding, but
FFplay didn't support HEVC interlaced bitstream display.

We know FFplay play h264 interlaced bitstream perfectly.

I'd like to know if FFplay support HEVC interlaced bitstream
display. And will FFmpeg support that?


I don't think so.

It is possible to play hevc interlaced with ffmpeg via mpv but
you'll have to set up your own filter chain and possibly adjust
for field order.

I've done it on a homemade (libx265) test. libx265 only takes a
certain field order and expects fields, plus interlaced support
is (was) flagged as experimental. It did seem to work though, it
was a while ago so this is just a paste from notes on the
playback side - basically you need to weave the fields that the
decoder outputs as weaved frames is what other decoders output.

mpv -fs --vf=lavfi=[tinterlace=merge,setsar=1/1,yadif=1]
hevc-interl-5M.mkv


Exactly the same (without the lavfi wrapper of course) should work
on ffplay.


Yea, I guess, just posting what I new worked for me.



So does this mean the HEVC decoder outputs separate fields only?
This is really odd, although I can understand why.


The reason for that is that HEVC doesn't actually have any
interlaced coding tools, just some metadata to flag a stream as
interlaced. So an interlaced stream is just a stream of half-height
frames at twice the fps.

I thought there was a patch to assemble them back into frames,
though. Maybe it was never applied.


With very recent mpv/ffmpeg my test still outputs fields.

On the "just metadata" comment - you do have to feed (IIRC) top field
first so I would hope there is some spatial handling of the bobbing in
there somewhere, but then "my hope" may not match with reality :-)

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

Re: [FFmpeg-devel] Does FFplay support HEVC interlaced bitstream display?

[Hendrik Leppkes]

On Tue, Dec 1, 2015 at 1:36 PM, wm4  wrote:
> On Tue, 1 Dec 2015 12:12:13 +
> Andy Furniss  wrote:
>
>> Fan Yingming wrote:
>> > Hi, everyone.
>> >
>> > I noticed that HEVC support interlaced field encoding, but FFplay
>> > didn't support HEVC interlaced bitstream display.
>> >
>> > We know FFplay play h264 interlaced bitstream perfectly.
>> >
>> > I'd like to know if FFplay support HEVC interlaced bitstream
>> > display. And will FFmpeg support that?
>>
>> I don't think so.
>>
>> It is possible to play hevc interlaced with ffmpeg via mpv but you'll
>> have to set up your own filter chain and possibly adjust for field order.
>>
>> I've done it on a homemade (libx265) test. libx265 only takes a certain
>> field order and expects fields, plus interlaced support is (was) flagged
>> as experimental. It did seem to work though, it was a while ago so this
>> is just a paste from notes on the playback side - basically you need to
>> weave the fields that the decoder outputs as weaved frames is what other
>> decoders output.
>>
>> mpv -fs --vf=lavfi=[tinterlace=merge,setsar=1/1,yadif=1] hevc-interl-5M.mkv
>
> Exactly the same (without the lavfi wrapper of course) should work on
> ffplay.
>
> So does this mean the HEVC decoder outputs separate fields only? This
> is really odd, although I can understand why.

The reason for that is that HEVC doesn't actually have any interlaced
coding tools, just some metadata to flag a stream as interlaced.
So an interlaced stream is just a stream of half-height frames at twice the fps.

I thought there was a patch to assemble them back into frames, though.
Maybe it was never applied.

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

Re: [FFmpeg-devel] Does FFplay support HEVC interlaced bitstream display?

[Andy Furniss]

Andy Furniss wrote:


On the "just metadata" comment - you do have to feed (IIRC) top field
first so I would hope there is some spatial handling of the bobbing in
there somewhere, but then "my hope" may not match with reality :-)


Of course I am thinking of libx265 here - maybe the spec says nothing.


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

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

[Nicolas George]

Le primidi 11 frimaire, an CCXXIV, Paul B Mahol a écrit :
> Similar how its freed when no longer used.

Please elaborate. I know the API, I do not see what you suggest.

(Thanks for trimming.)

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] avfilter: add audio emphasis filter

[Moritz Barsnick]

On Tue, Dec 01, 2015 at 12:22:43 +0100, Paul B Mahol wrote:
> +select Compat Disc (CD).

Compact

> +@item 50fm
> +select 50??s (FM).

a) I'm not sure whether you're allowed or encouraged to use UTF-8
   characters in ffmpeg's code. If encouraged, then okay. Riddles me
   though how you managed to send the UTF-8 patch in an ascii-encoded
   e-mail. ;-)
   ("??" as quoted above is mutt's interpretation in this response.
   When I saved the content of your mail as a patch, mutt was so kind
   to retain the UTF-8 characters.)

I didn't really check much except the docs, sorry.

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

Re: [FFmpeg-devel] [PATCH] vp9: reinit internal buffers on bpp change.

[Ronald S. Bultje]

Hi,

On Tue, Dec 1, 2015 at 9:21 AM, Hendrik Leppkes  wrote:

> On Tue, Dec 1, 2015 at 3:13 PM, Ronald S. Bultje 
> wrote:
> > Fixes mozilla bug 1229128.
> > ---
> >  libavcodec/vp9.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> > index d4061e2..858d561 100644
> > --- a/libavcodec/vp9.c
> > +++ b/libavcodec/vp9.c
> > @@ -219,7 +219,8 @@ static int update_size(AVCodecContext *ctx, int w,
> int h, enum AVPixelFormat fmt
> >
> >  av_assert0(w > 0 && h > 0);
> >
> > -if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height &&
> ctx->pix_fmt == fmt)
> > +if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height &&
> > +ctx->pix_fmt == fmt && s->bpp == s->last_bpp)
> >  return 0;
>
> Doesn't the pixfmt change when bitdepth changes?


Hm, yes, let me dig some deeper, I think there's something more shitty
hiding in there...

Patch withdrawn, for now.

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

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

[Paul B Mahol]

Dana 1. 12. 2015. 15:08 osoba "Nicolas George"  napisala
je:
>
> Le primidi 11 frimaire, an CCXXIV, Paul B Mahol a écrit :
> > I don't think API is needed for this. Just one call in right place IIRC.
>
> Can you show an example? That would be more useful than handwaving. I must
> say I have no idea what the "right place" would be.

Similar how its freed when no longer used.

>
> Also, I would appreciate if Ganesh and you took the habit of trimming your
> email: 460+ lines of quote for 2 lines of reply, that makes a very poor
> signal/noise ratio.
>
> Regards,
>
> --
>   Nicolas George
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Ganesh Ajjanagadde]

On Tue, Dec 1, 2015 at 3:50 AM, Paul B Mahol  wrote:
> On 12/1/15, Ganesh Ajjanagadde  wrote:
>> On Sun, Nov 29, 2015 at 6:03 PM, Paul B Mahol  wrote:
>>> Signed-off-by: Paul B Mahol 
>>> ---
>>>  doc/filters.texi |  61 +
>>>  libavfilter/Makefile |   1 +
>>>  libavfilter/af_agate.c   | 170
>>> ++-
>>>  libavfilter/allfilters.c |   1 +
>>>  4 files changed, 230 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/doc/filters.texi b/doc/filters.texi
>>> index 0395c7a..ed4a376 100644
>>> --- a/doc/filters.texi
>>> +++ b/doc/filters.texi
>>> @@ -2531,6 +2531,67 @@ ffmpeg -i main.flac -i sidechain.flac
>>> -filter_complex "[1:a]asplit=2[sc][mix];[0
>>>  @end example
>>>  @end itemize
>>>
>>> +@section sidechaingate
>>> +
>>> +A sidechain gate acts like a normal (wideband) gate but has the ability
>>> to
>>> +filter the detected signal before sending it to the gain reduction stage.
>>> +Normally a gate uses the full range signal to detect a level above the
>>> +threshold.
>>> +For example: If you cut all lower frequencies from your sidechain signal
>>> +the gate will decrease the volume of your track only if not enough highs
>>> +appear. With this technique you are able to reduce the resonation of a
>>> +natural drum or remove "rumbling" of muted strokes from a heavily
>>> distorted
>>> +guitar.
>>> +It needs two input streams and returns one output stream.
>>> +First input stream will be processed depending on second stream signal.
>>> +
>>> +The filter accepts the following options:
>>> +
>>> +@table @option
>>> +@item level_in
>>> +Set input level before filtering.
>>> +Default is 1. Allowed range is from 0.015625 to 64.
>>> +
>>> +@item range
>>> +Set the level of gain reduction when the signal is below the threshold.
>>> +Default is 0.06125. Allowed range is from 0 to 1.
>>> +
>>> +@item threshold
>>> +If a signal rises above this level the gain reduction is released.
>>> +Default is 0.125. Allowed range is from 0 to 1.
>>> +
>>> +@item ratio
>>> +Set a ratio about which the signal is reduced.
>>> +Default is 2. Allowed range is from 1 to 9000.
>>> +
>>> +@item attack
>>> +Amount of milliseconds the signal has to rise above the threshold before
>>> gain
>>> +reduction stops.
>>> +Default is 20 milliseconds. Allowed range is from 0.01 to 9000.
>>> +
>>> +@item release
>>> +Amount of milliseconds the signal has to fall below the threshold before
>>> the
>>> +reduction is increased again. Default is 250 milliseconds.
>>> +Allowed range is from 0.01 to 9000.
>>> +
>>> +@item makeup
>>> +Set amount of amplification of signal after processing.
>>> +Default is 1. Allowed range is from 1 to 64.
>>> +
>>> +@item knee
>>> +Curve the sharp knee around the threshold to enter gain reduction more
>>> softly.
>>> +Default is 2.828427125. Allowed range is from 1 to 8.
>>> +
>>> +@item detection
>>> +Choose if exact signal should be taken for detection or an RMS like one.
>>> +Default is peak. Can be peak or rms.
>>> +
>>> +@item link
>>> +Choose if the average level between all channels or the louder channel
>>> affects
>>> +the reduction.
>>> +Default is average. Can be average or maximum.
>>> +@end table
>>> +
>>>  @section silencedetect
>>>
>>>  Detect silence in an audio stream.
>>> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
>>> index e31bdaa..582fd0e 100644
>>> --- a/libavfilter/Makefile
>>> +++ b/libavfilter/Makefile
>>> @@ -82,6 +82,7 @@ OBJS-$(CONFIG_REPLAYGAIN_FILTER) +=
>>> af_replaygain.o
>>>  OBJS-$(CONFIG_RESAMPLE_FILTER)   += af_resample.o
>>>  OBJS-$(CONFIG_RUBBERBAND_FILTER) += af_rubberband.o
>>>  OBJS-$(CONFIG_SIDECHAINCOMPRESS_FILTER)  += af_sidechaincompress.o
>>> +OBJS-$(CONFIG_SIDECHAINGATE_FILTER)  += af_agate.o
>>>  OBJS-$(CONFIG_SILENCEDETECT_FILTER)  += af_silencedetect.o
>>>  OBJS-$(CONFIG_SILENCEREMOVE_FILTER)  += af_silenceremove.o
>>>  OBJS-$(CONFIG_STEREOTOOLS_FILTER)+= af_stereotools.o
>>> diff --git a/libavfilter/af_agate.c b/libavfilter/af_agate.c
>>> index d3f74fb..23e45c6 100644
>>> --- a/libavfilter/af_agate.c
>>> +++ b/libavfilter/af_agate.c
>>> @@ -18,6 +18,12 @@
>>>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>>> 02110-1301 USA
>>>   */
>>>
>>> +/**
>>> + * @file
>>> + * Audio (Sidechain) Gate filter
>>> + */
>>> +
>>> +#include "libavutil/avassert.h"
>>>  #include "libavutil/channel_layout.h"
>>>  #include "libavutil/opt.h"
>>>  #include "avfilter.h"
>>> @@ -46,12 +52,14 @@ typedef struct AudioGateContext {
>>>  double lin_slope;
>>>  double attack_coeff;
>>>  double release_coeff;
>>> +
>>> +AVFrame *input_frame[2];
>>>  } AudioGateContext;
>>>
>>>  #define OFFSET(x) offsetof(AudioGateContext, x)
>>>  #define A AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
>>>
>>> -static const AVOption agate_options[] = {

Re: [FFmpeg-devel] FFMPEG API

[Yosef B]

only add the include 
and
AVPicture* pConvertedFrame = (AVPicture*)*av_frame_alloc*();

On Tue, Dec 1, 2015 at 2:33 PM, Yosef B  wrote:

> Hi,
> I'm new with ffmpeg, I'm using the (XX-57) version.
>
> I have the following old code but I can't find the *avcodec_alloc_frame*:
> AVPicture* pConvertedFrame = *avcodec_alloc_frame*();
>
> *I get:  *
> *error C3861: 'avcodec_alloc_frame': identifier not found *
>
> I tried the *"*
> *get_frame_defaults(pConvertedFrame);" *with no luck!!!
>
> Any idea?
>
> --
>
> Best regards,
>
> J.B.
>



-- 

Best regards,

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

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

[Paul B Mahol]

On 12/1/15, Ganesh Ajjanagadde  wrote:
> On Tue, Dec 1, 2015 at 3:50 AM, Paul B Mahol  wrote:
>> On 12/1/15, Ganesh Ajjanagadde  wrote:
>>> On Sun, Nov 29, 2015 at 6:03 PM, Paul B Mahol  wrote:
 Signed-off-by: Paul B Mahol 
 ---
  doc/filters.texi |  61 +
  libavfilter/Makefile |   1 +
  libavfilter/af_agate.c   | 170
 ++-
  libavfilter/allfilters.c |   1 +
  4 files changed, 230 insertions(+), 3 deletions(-)

 diff --git a/doc/filters.texi b/doc/filters.texi
 index 0395c7a..ed4a376 100644
 --- a/doc/filters.texi
 +++ b/doc/filters.texi
 @@ -2531,6 +2531,67 @@ ffmpeg -i main.flac -i sidechain.flac
 -filter_complex "[1:a]asplit=2[sc][mix];[0
  @end example
  @end itemize

 +@section sidechaingate
 +
 +A sidechain gate acts like a normal (wideband) gate but has the ability
 to
 +filter the detected signal before sending it to the gain reduction
 stage.
 +Normally a gate uses the full range signal to detect a level above the
 +threshold.
 +For example: If you cut all lower frequencies from your sidechain
 signal
 +the gate will decrease the volume of your track only if not enough
 highs
 +appear. With this technique you are able to reduce the resonation of a
 +natural drum or remove "rumbling" of muted strokes from a heavily
 distorted
 +guitar.
 +It needs two input streams and returns one output stream.
 +First input stream will be processed depending on second stream signal.
 +
 +The filter accepts the following options:
 +
 +@table @option
 +@item level_in
 +Set input level before filtering.
 +Default is 1. Allowed range is from 0.015625 to 64.
 +
 +@item range
 +Set the level of gain reduction when the signal is below the threshold.
 +Default is 0.06125. Allowed range is from 0 to 1.
 +
 +@item threshold
 +If a signal rises above this level the gain reduction is released.
 +Default is 0.125. Allowed range is from 0 to 1.
 +
 +@item ratio
 +Set a ratio about which the signal is reduced.
 +Default is 2. Allowed range is from 1 to 9000.
 +
 +@item attack
 +Amount of milliseconds the signal has to rise above the threshold
 before
 gain
 +reduction stops.
 +Default is 20 milliseconds. Allowed range is from 0.01 to 9000.
 +
 +@item release
 +Amount of milliseconds the signal has to fall below the threshold
 before
 the
 +reduction is increased again. Default is 250 milliseconds.
 +Allowed range is from 0.01 to 9000.
 +
 +@item makeup
 +Set amount of amplification of signal after processing.
 +Default is 1. Allowed range is from 1 to 64.
 +
 +@item knee
 +Curve the sharp knee around the threshold to enter gain reduction more
 softly.
 +Default is 2.828427125. Allowed range is from 1 to 8.
 +
 +@item detection
 +Choose if exact signal should be taken for detection or an RMS like
 one.
 +Default is peak. Can be peak or rms.
 +
 +@item link
 +Choose if the average level between all channels or the louder channel
 affects
 +the reduction.
 +Default is average. Can be average or maximum.
 +@end table
 +
  @section silencedetect

  Detect silence in an audio stream.
 diff --git a/libavfilter/Makefile b/libavfilter/Makefile
 index e31bdaa..582fd0e 100644
 --- a/libavfilter/Makefile
 +++ b/libavfilter/Makefile
 @@ -82,6 +82,7 @@ OBJS-$(CONFIG_REPLAYGAIN_FILTER) +=
 af_replaygain.o
  OBJS-$(CONFIG_RESAMPLE_FILTER)   += af_resample.o
  OBJS-$(CONFIG_RUBBERBAND_FILTER) += af_rubberband.o
  OBJS-$(CONFIG_SIDECHAINCOMPRESS_FILTER)  += af_sidechaincompress.o
 +OBJS-$(CONFIG_SIDECHAINGATE_FILTER)  += af_agate.o
  OBJS-$(CONFIG_SILENCEDETECT_FILTER)  += af_silencedetect.o
  OBJS-$(CONFIG_SILENCEREMOVE_FILTER)  += af_silenceremove.o
  OBJS-$(CONFIG_STEREOTOOLS_FILTER)+= af_stereotools.o
 diff --git a/libavfilter/af_agate.c b/libavfilter/af_agate.c
 index d3f74fb..23e45c6 100644
 --- a/libavfilter/af_agate.c
 +++ b/libavfilter/af_agate.c
 @@ -18,6 +18,12 @@
   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
 02110-1301 USA
   */

 +/**
 + * @file
 + * Audio (Sidechain) Gate filter
 + */
 +
 +#include "libavutil/avassert.h"
  #include "libavutil/channel_layout.h"
  #include "libavutil/opt.h"
  #include "avfilter.h"
 @@ -46,12 +52,14 @@ typedef struct AudioGateContext {
  double lin_slope;
  double attack_coeff;
  double release_coeff;
 +
 +AVFrame 

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

[Nicolas George]

Le primidi 11 frimaire, an CCXXIV, Paul B Mahol a écrit :
> I don't think API is needed for this. Just one call in right place IIRC.

Can you show an example? That would be more useful than handwaving. I must
say I have no idea what the "right place" would be.

Also, I would appreciate if Ganesh and you took the habit of trimming your
email: 460+ lines of quote for 2 lines of reply, that makes a very poor
signal/noise ratio.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] vp9: reinit internal buffers on bpp change.

[Hendrik Leppkes]

On Tue, Dec 1, 2015 at 3:13 PM, Ronald S. Bultje  wrote:
> Fixes mozilla bug 1229128.
> ---
>  libavcodec/vp9.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index d4061e2..858d561 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -219,7 +219,8 @@ static int update_size(AVCodecContext *ctx, int w, int h, 
> enum AVPixelFormat fmt
>
>  av_assert0(w > 0 && h > 0);
>
> -if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height && 
> ctx->pix_fmt == fmt)
> +if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height &&
> +ctx->pix_fmt == fmt && s->bpp == s->last_bpp)
>  return 0;

Doesn't the pixfmt change when bitdepth changes?

Also, someone yell at Mozilla for having "hidden" bug reports.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFMPEG API

[wm4]

On Tue, 1 Dec 2015 14:33:09 +0200
Yosef B  wrote:

> Hi,
> I'm new with ffmpeg, I'm using the (XX-57) version.
> 
> I have the following old code but I can't find the *avcodec_alloc_frame*:
> AVPicture* pConvertedFrame = *avcodec_alloc_frame*();
> 
> *I get:  *
> *error C3861: 'avcodec_alloc_frame': identifier not found *
> 
> I tried the *"*
> *get_frame_defaults(pConvertedFrame);" *with no luck!!!
> 
> Any idea?
> 

The correct mailing list for such question is: libav-u...@ffmpeg.org
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] vp9: reinit internal buffers on bpp change.

[Ronald S. Bultje]

Fixes mozilla bug 1229128.
---
 libavcodec/vp9.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index d4061e2..858d561 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -219,7 +219,8 @@ static int update_size(AVCodecContext *ctx, int w, int h, 
enum AVPixelFormat fmt
 
 av_assert0(w > 0 && h > 0);
 
-if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height && 
ctx->pix_fmt == fmt)
+if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height &&
+ctx->pix_fmt == fmt && s->bpp == s->last_bpp)
 return 0;
 
 if ((res = ff_set_dimensions(ctx, w, h)) < 0)
-- 
2.1.2

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

Re: [FFmpeg-devel] [PATCH] vp9: always keep s->bytesperpixel and ctx->pix_fmt in sync.

[Hendrik Leppkes]

On Tue, Dec 1, 2015 at 4:08 PM, Ronald S. Bultje  wrote:
> Fixes mozilla bug 1229128.
> ---
>  libavcodec/vp9.c | 43 ++-
>  1 file changed, 22 insertions(+), 21 deletions(-)
>
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index d4061e2..9bf746c 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -69,6 +69,7 @@ typedef struct VP9Context {
>  uint8_t ss_h, ss_v;
>  uint8_t last_bpp, bpp, bpp_index, bytesperpixel;
>  uint8_t last_keyframe;
> +enum AVPixelFormat last_fmt;
>  ThreadFrame next_refs[8];
>
>  struct {
> @@ -211,7 +212,7 @@ static int vp9_ref_frame(AVCodecContext *ctx, VP9Frame 
> *dst, VP9Frame *src)
>  return 0;
>  }
>
> -static int update_size(AVCodecContext *ctx, int w, int h, enum AVPixelFormat 
> fmt)
> +static int update_size(AVCodecContext *ctx, int w, int h)
>  {
>  VP9Context *s = ctx->priv_data;
>  uint8_t *p;
> @@ -219,12 +220,12 @@ static int update_size(AVCodecContext *ctx, int w, int 
> h, enum AVPixelFormat fmt
>
>  av_assert0(w > 0 && h > 0);
>
> -if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height && 
> ctx->pix_fmt == fmt)
> +if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height && 
> ctx->pix_fmt == s->last_fmt)
>  return 0;
>
>  if ((res = ff_set_dimensions(ctx, w, h)) < 0)
>  return res;
> -ctx->pix_fmt = fmt;
> +s->last_fmt  = ctx->pix_fmt;
>  s->sb_cols   = (w + 63) >> 6;
>  s->sb_rows   = (h + 63) >> 6;
>  s->cols  = (w + 7) >> 3;
> @@ -383,14 +384,13 @@ static int update_prob(VP56RangeCoder *c, int p)
>  255 - inv_recenter_nonneg(inv_map_table[d], 255 - p);
>  }
>
> -static enum AVPixelFormat read_colorspace_details(AVCodecContext *ctx)
> +static int read_colorspace_details(AVCodecContext *ctx)
>  {
>  static const enum AVColorSpace colorspaces[8] = {
>  AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709, 
> AVCOL_SPC_SMPTE170M,
>  AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED, 
> AVCOL_SPC_RGB,
>  };
>  VP9Context *s = ctx->priv_data;
> -enum AVPixelFormat res;
>  int bits = ctx->profile <= 1 ? 0 : 1 + get_bits1(>gb); // 0:8, 1:10, 
> 2:12
>
>  s->bpp_index = bits;
> @@ -401,10 +401,10 @@ static enum AVPixelFormat 
> read_colorspace_details(AVCodecContext *ctx)
>  static const enum AVPixelFormat pix_fmt_rgb[3] = {
>  AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12
>  };
> +s->ss_h = s->ss_v = 0;
> +ctx->color_range = AVCOL_RANGE_JPEG;
> +ctx->pix_fmt = pix_fmt_rgb[bits];
>  if (ctx->profile & 1) {
> -s->ss_h = s->ss_v = 0;
> -res = pix_fmt_rgb[bits];
> -ctx->color_range = AVCOL_RANGE_JPEG;
>  if (get_bits1(>gb)) {
>  av_log(ctx, AV_LOG_ERROR, "Reserved bit set in RGB\n");
>  return AVERROR_INVALIDDATA;
> @@ -427,7 +427,8 @@ static enum AVPixelFormat 
> read_colorspace_details(AVCodecContext *ctx)
>  if (ctx->profile & 1) {
>  s->ss_h = get_bits1(>gb);
>  s->ss_v = get_bits1(>gb);
> -if ((res = pix_fmt_for_ss[bits][s->ss_v][s->ss_h]) == 
> AV_PIX_FMT_YUV420P) {
> +ctx->pix_fmt = pix_fmt_for_ss[bits][s->ss_v][s->ss_h];
> +if (ctx->pix_fmt == AV_PIX_FMT_YUV420P) {
>  av_log(ctx, AV_LOG_ERROR, "YUV 4:2:0 not supported in 
> profile %d\n",
> ctx->profile);
>  return AVERROR_INVALIDDATA;
> @@ -438,11 +439,11 @@ static enum AVPixelFormat 
> read_colorspace_details(AVCodecContext *ctx)
>  }
>  } else {
>  s->ss_h = s->ss_v = 1;
> -res = pix_fmt_for_ss[bits][1][1];
> +ctx->pix_fmt = pix_fmt_for_ss[bits][1][1];
>  }
>  }
>
> -return res;
> +return 0;
>  }
>
>  static int decode_frame_header(AVCodecContext *ctx,
> @@ -450,7 +451,6 @@ static int decode_frame_header(AVCodecContext *ctx,
>  {
>  VP9Context *s = ctx->priv_data;
>  int c, i, j, k, l, m, n, w, h, max, size2, res, sharp;
> -enum AVPixelFormat fmt = ctx->pix_fmt;
>  int last_invisible;
>  const uint8_t *data2;
>
> @@ -486,8 +486,8 @@ static int decode_frame_header(AVCodecContext *ctx,
>  av_log(ctx, AV_LOG_ERROR, "Invalid sync code\n");
>  return AVERROR_INVALIDDATA;
>  }
> -if ((fmt = read_colorspace_details(ctx)) < 0)
> -return fmt;
> +if ((res = read_colorspace_details(ctx)) < 0)
> +return res;
>  // for profile 1, here follows the subsampling bits
>  s->s.h.refreshrefmask = 0xff;
>  w = get_bits(>gb, 16) + 1;
> @@ -503,14 +503,14 @@ static int decode_frame_header(AVCodecContext *ctx,
>  return AVERROR_INVALIDDATA;
>  }
>  if (ctx->profile >= 1) {
> -   

Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()

[Nicolas George]

Le decadi 10 frimaire, an CCXXIV, Clement Boesch a écrit :
> From: Clément Bœsch 
> 
> ---
>  libavutil/threadmessage.c | 37 ++---
>  libavutil/threadmessage.h | 21 ++---
>  2 files changed, 52 insertions(+), 6 deletions(-)
> 
> diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c
> index b7fcbe2..87ce8dc 100644
> --- a/libavutil/threadmessage.c
> +++ b/libavutil/threadmessage.c
> @@ -40,14 +40,16 @@ struct AVThreadMessageQueue {
>  int err_send;
>  int err_recv;
>  unsigned elsize;
> +void (*free_func)(void *msg);
>  #else
>  int dummy;
>  #endif
>  };
>  
> -int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
> -  unsigned nelem,
> -  unsigned elsize)

> +int av_thread_message_queue_alloc2(AVThreadMessageQueue **mq,
> +   unsigned nelem,
> +   unsigned elsize,
> +   void (*free_func)(void *msg))

I must say I am not very fond of this aspect of the change, because of
foobar2 and numerous function arguments.

What about having the application set queue->free_func with a second
function if needed, either directly or through
av_thread_message_queue_set_free_func()?

>  {
>  #if HAVE_THREADS
>  AVThreadMessageQueue *rmq;
> @@ -73,6 +75,7 @@ int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
>  return AVERROR(ret);
>  }
>  rmq->elsize = elsize;
> +rmq->free_func = free_func;
>  *mq = rmq;
>  return 0;
>  #else
> @@ -81,10 +84,18 @@ int av_thread_message_queue_alloc(AVThreadMessageQueue 
> **mq,
>  #endif /* HAVE_THREADS */
>  }
>  
> +int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
> +  unsigned nelem,
> +  unsigned elsize)
> +{
> +return av_thread_message_queue_alloc2(mq, nelem, elsize, NULL);
> +}
> +
>  void av_thread_message_queue_free(AVThreadMessageQueue **mq)
>  {
>  #if HAVE_THREADS
>  if (*mq) {
> +av_thread_message_flush(*mq);
>  av_fifo_freep(&(*mq)->fifo);
>  pthread_cond_destroy(&(*mq)->cond);
>  pthread_mutex_destroy(&(*mq)->lock);
> @@ -182,3 +193,23 @@ void 
> av_thread_message_queue_set_err_recv(AVThreadMessageQueue *mq,
>  pthread_mutex_unlock(>lock);
>  #endif /* HAVE_THREADS */
>  }
> +
> +void av_thread_message_flush(AVThreadMessageQueue *mq)
> +{
> +#if HAVE_THREADS
> +int used, off;
> +
> +pthread_mutex_lock(>lock);
> +used = av_fifo_size(mq->fifo);
> +if (mq->free_func) {
> +for (off = 0; off < used; off += mq->elsize) {
> +void *msg;
> +av_fifo_generic_peek_at(mq->fifo, , off, mq->elsize, NULL);
> +mq->free_func(msg);
> +}
> +}
> +av_fifo_drain(mq->fifo, used);
> +pthread_cond_broadcast(>cond);
> +pthread_mutex_unlock(>lock);
> +#endif /* HAVE_THREADS */
> +}
> diff --git a/libavutil/threadmessage.h b/libavutil/threadmessage.h
> index a8481d8..f9004a8 100644
> --- a/libavutil/threadmessage.h
> +++ b/libavutil/threadmessage.h
> @@ -33,17 +33,27 @@ typedef enum AVThreadMessageFlags {
>  } AVThreadMessageFlags;
>  
>  /**
> + * @deprecated use av_thread_message_queue_alloc2 instead
> + */
> +attribute_deprecated
> +int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
> +  unsigned nelem,
> +  unsigned elsize);
> +
> +/**
>   * Allocate a new message queue.
>   *
>   * @param mq  pointer to the message queue
>   * @param nelem   maximum number of elements in the queue
>   * @param elsize  size of each element in the queue
> + * @param free_func free message callback function, can be NULL
>   * @return  >=0 for success; <0 for error, in particular AVERROR(ENOSYS) if
>   *  lavu was built without thread support
>   */
> -int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
> -  unsigned nelem,
> -  unsigned elsize);
> +int av_thread_message_queue_alloc2(AVThreadMessageQueue **mq,
> +   unsigned nelem,
> +   unsigned elsize,
> +   void (*free_func)(void *msg));
>  
>  /**
>   * Free a message queue.
> @@ -88,4 +98,9 @@ void 
> av_thread_message_queue_set_err_send(AVThreadMessageQueue *mq,
>  void av_thread_message_queue_set_err_recv(AVThreadMessageQueue *mq,
>int err);
>  

> +/**
> + * Flush the message queue
> + */
> +void av_thread_message_flush(AVThreadMessageQueue *mq);

Can you explain in the doxy (and to me) how it is better than:

while (av_thread_message_queue_recv_locked(mq, msg, 
AV_THREAD_MESSAGE_NONBLOCK))
free_func(msg);

?

> +
>  #endif /* 

Re: [FFmpeg-devel] [PATCH 5/5] lavfi: make request_frame() non-recursive.

[Nicolas George]

Le decadi 10 frimaire, an CCXXIV, Hendrik Leppkes a écrit :
> We generally just use ints for boolean properties, any particular
> reason this uses unsigned instead?

Just a matter of personal habit, justified below. But as I look at it, I see
it is rather inconsistent with other fields in the struct that are int
although they really would be better unsigned. Will change.


When it does not matter, I usually use unsigned instead of signed because
that often leaves the compiler more room for optimization. For example,
"type half(type x) { return x / 2; }" compiles into this for unsigned:

movl%edi, %eax
shrl%eax
ret

And this for signed:

movl%edi, %eax
movl$2, %ecx
cltd
idivl   %ecx
ret

In other words, "x / 2" can be optimized into "x >> 1" for unsigned, but not
for signed because the rounding is not the same for negative.

I suppose in fact you already knew that. Of course it does not make a
difference here, but I prefer this habit instead of the other way around.
For booleans, I feel that int gives the impression there is a third case,
possibly error: think of ssize_t for the return value of syscalls. And if it
becomes a counter, then it should naturally be unsigned.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()

[Clément Bœsch]

On Tue, Dec 01, 2015 at 05:11:06PM +0100, Nicolas George wrote:
> Le decadi 10 frimaire, an CCXXIV, Clement Boesch a écrit :
> > From: Clément Bœsch 
> > 
> > ---
> >  libavutil/threadmessage.c | 37 ++---
> >  libavutil/threadmessage.h | 21 ++---
> >  2 files changed, 52 insertions(+), 6 deletions(-)
> > 
> > diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c
> > index b7fcbe2..87ce8dc 100644
> > --- a/libavutil/threadmessage.c
> > +++ b/libavutil/threadmessage.c
> > @@ -40,14 +40,16 @@ struct AVThreadMessageQueue {
> >  int err_send;
> >  int err_recv;
> >  unsigned elsize;
> > +void (*free_func)(void *msg);
> >  #else
> >  int dummy;
> >  #endif
> >  };
> >  
> > -int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
> > -  unsigned nelem,
> > -  unsigned elsize)
> 
> > +int av_thread_message_queue_alloc2(AVThreadMessageQueue **mq,
> > +   unsigned nelem,
> > +   unsigned elsize,
> > +   void (*free_func)(void *msg))
> 
> I must say I am not very fond of this aspect of the change, because of
> foobar2 and numerous function arguments.
> 
> What about having the application set queue->free_func with a second
> function if needed, either directly or through
> av_thread_message_queue_set_free_func()?
> 

Yeah, sure, no opinion really. Will send a new patch.

[...]
> > +/**
> > + * Flush the message queue
> > + */
> > +void av_thread_message_flush(AVThreadMessageQueue *mq);
> 
> Can you explain in the doxy (and to me) how it is better than:
> 
>   while (av_thread_message_queue_recv_locked(mq, msg, 
> AV_THREAD_MESSAGE_NONBLOCK))
>   free_func(msg);
> 


current:
int used, off;

pthread_mutex_lock(>lock);
used = av_fifo_size(mq->fifo);
if (mq->free_func) {
for (off = 0; off < used; off += mq->elsize) {
void *msg;
av_fifo_generic_peek_at(mq->fifo, , off, mq->elsize, NULL);
mq->free_func(msg);
}
}
av_fifo_drain(mq->fifo, used);
pthread_cond_broadcast(>cond);
pthread_mutex_unlock(>lock);

yours:
void *msg;

pthread_mutex_lock(>lock);
while (av_thread_message_queue_recv_locked(mq, msg, 
AV_THREAD_MESSAGE_NONBLOCK))
if (mq->free_func)
mq->free_func(msg);
pthread_mutex_unlock(>lock);

Your suggestion is twice smaller.  I don't mind that much but I guess I like
saving a few checks and preventing a bunch of signal broadcasting. Also,
passing the AV_THREAD_MESSAGE_NONBLOCK seems a bit like a (smart) hack to me. I
will pick your solution (which I admit haven't thought of initially) if you
insist, but I prefer my version.

[...]

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()

[Nicolas George]

Le primidi 11 frimaire, an CCXXIV, Clement Boesch a écrit :
> Your suggestion is twice smaller.

I guess I was not clear enough: I was not asking about merits of this
implementations over yours, but about the usefulness of the function for the
application compared to reading and discarding each message in turn. I guess
it is more efficient, but there are probably others, otherwise you would not
have bothered.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 5/5] lavfi: make request_frame() non-recursive.

[Clément Bœsch]

On Tue, Dec 01, 2015 at 05:26:23PM +0100, Nicolas George wrote:
> Le decadi 10 frimaire, an CCXXIV, Hendrik Leppkes a écrit :
> > We generally just use ints for boolean properties, any particular
> > reason this uses unsigned instead?
> 
> Just a matter of personal habit, justified below. But as I look at it, I see
> it is rather inconsistent with other fields in the struct that are int
> although they really would be better unsigned. Will change.
> 
> 
> When it does not matter, I usually use unsigned instead of signed because
> that often leaves the compiler more room for optimization. For example,
> "type half(type x) { return x / 2; }" compiles into this for unsigned:
> 
> movl%edi, %eax
> shrl%eax
> ret
> 
> And this for signed:
> 
> movl%edi, %eax
> movl$2, %ecx
> cltd
> idivl   %ecx
> ret
> 
> In other words, "x / 2" can be optimized into "x >> 1" for unsigned, but not
> for signed because the rounding is not the same for negative.
> 
> I suppose in fact you already knew that. Of course it does not make a
> difference here, but I prefer this habit instead of the other way around.
> For booleans, I feel that int gives the impression there is a third case,
> possibly error: think of ssize_t for the return value of syscalls. And if it
> becomes a counter, then it should naturally be unsigned.
> 

There is at least one case where you actually want it signed, which is
when you loop over it. Typically, in the case of a width/height, you
actually want it signed because it indicates the compiler that an overflow
will not happen since a signed overflow is undefined.

  for (x = x_start; x < width; x++)

Here, if we are dealing with signed, the compiler can simply assume that x
will not overflow, go back to 0 and then reach width. See
-Wstrict-overflow compiler option.

Regards,

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()

[Clément Bœsch]

On Tue, Dec 01, 2015 at 05:34:39PM +0100, Nicolas George wrote:
> Le primidi 11 frimaire, an CCXXIV, Clement Boesch a écrit :
> > Your suggestion is twice smaller.
> 
> I guess I was not clear enough: I was not asking about merits of this
> implementations over yours, but about the usefulness of the function for the
> application compared to reading and discarding each message in turn. I guess
> it is more efficient, but there are probably others, otherwise you would not
> have bothered.
> 

Ah. Well then the user can not do it himself since he has no way of
acquiring the queue lock (AVThreadMessageQueue is opaque)

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH 5/5] lavfi: make request_frame() non-recursive.

[Ganesh Ajjanagadde]

On Tue, Dec 1, 2015 at 11:26 AM, Nicolas George  wrote:
> Le decadi 10 frimaire, an CCXXIV, Hendrik Leppkes a écrit :
>> We generally just use ints for boolean properties, any particular
>> reason this uses unsigned instead?
>
> Just a matter of personal habit, justified below. But as I look at it, I see
> it is rather inconsistent with other fields in the struct that are int
> although they really would be better unsigned. Will change.
>
>
> When it does not matter, I usually use unsigned instead of signed because
> that often leaves the compiler more room for optimization. For example,
> "type half(type x) { return x / 2; }" compiles into this for unsigned:
>
> movl%edi, %eax
> shrl%eax
> ret
>
> And this for signed:
>
> movl%edi, %eax
> movl$2, %ecx
> cltd
> idivl   %ecx
> ret
>
> In other words, "x / 2" can be optimized into "x >> 1" for unsigned, but not
> for signed because the rounding is not the same for negative.
>
> I suppose in fact you already knew that. Of course it does not make a
> difference here, but I prefer this habit instead of the other way around.
> For booleans, I feel that int gives the impression there is a third case,
> possibly error: think of ssize_t for the return value of syscalls. And if it
> becomes a counter, then it should naturally be unsigned.

All true, but note the bizarre GCC bug I posted regarding perf
regression for unsigned vs signed counters:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052

May be related to Clement's point below.

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