Re: [FFmpeg-devel] lavf: Remove duplicated latm demuxer

[Carl Eugen Hoyos]

Paul B Mahol  gmail.com> writes:

> > Attached patch reduces code duplication.
> > (There was a API-relevant change in git right now.)
> >
> > Please comment, Carl Eugen
> 
> Duplicate how? Replaced by what?

The "latm" demuxer actually works on loas file and there 
already was a loas demuxer.

I will commit tonight if there are no objections, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] avutil: install des.h, rc4.h and tree.h as public headers

[Nicolas George]

Le duodi 22 vendémiaire, an CCXXIV, James Almer a écrit :
> Since these two were never installed, we can remove the FF_API_CRYPTO_CONTEXT
> wrapper from them before applying this patch, as this would be the first time
> the API becomes public.
> 
> Now, what i want to know is what will it be in the end for the actual
> deprecation in question? Reimar and Nicolas were against making the context
> opaque as having them in stack has its uses.
> I want to know what people want, since the deprecation is not present on any
> release and we still have time to rollback. Do we keep the deprecation in
> place for des, rc4, blowfish and xtea, or remove it altogether?

The reason for my objection are that the odds that the contents of the
context change in the future are very small for low-level standardized
crypto functions (this is the reason for making structure opaques). On the
other hand, foregoing the checks for memory allocations is nice, and crypto
functions may be used in speed-critical portions of the code where memory
allocations are not negligible.

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] [PATCHv2 2/2] avfilter/formats: add av_warn_unused_result to function prototypes

[Ganesh Ajjanagadde]

On Mon, Oct 12, 2015 at 7:44 AM, Ganesh Ajjanagadde  wrote:
> On Mon, Oct 12, 2015 at 3:11 AM, Nicolas George  wrote:
>> Le nonidi 19 vendémiaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>>> This uses the av_warn_unused_result attribute liberally to catch some forms 
>>> of improper
>>> usage of functions defined in avfilter/formats.h.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavfilter/formats.h | 9 +
>>>  1 file changed, 9 insertions(+)
>>
>> No objection from me.
>
> Ok, will push after 1/2 gets finalized.

Pushed 1/2 and this as well.

>
>>
>> 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] avutil/intmath: use de Bruijn based ff_ctz

[Ganesh Ajjanagadde]

On Wed, Oct 14, 2015 at 8:34 AM, Ronald S. Bultje  wrote:
> Hi,
>
> On Mon, Oct 12, 2015 at 7:14 AM, Ganesh Ajjanagadde 
> wrote:
>
>> On Mon, Oct 12, 2015 at 12:37 AM, James Almer  wrote:
>> > On 10/11/2015 10:55 PM, Ganesh Ajjanagadde wrote:
>> >> It has already been demonstrated that the de Bruijn method has benefits
>> >> over the current implementation: commit
>> 971d12b7f9d7be3ca8eb98e6c04ed521f83cbd3c.
>> >> That commit implemented it for long long, this extends it to the 32 bit
>> >> version.
>> >>
>> >> The function is renamed from ff_ctz to ff_ctz32 since it crucially
>> >> depends on the 32 bit width of its argument. This is not an issue, as
>> the
>> >> only usage in avcodec/flacenc uses an int32_t anyway.
>> >
>> > I personally don't think the renaming is needed, for that matter. The
>> > function takes an int as argument, and as far as ffmpeg supported arches
>> > go those are 32 bits.
>> > If you really want to be sure, just add a comment that the argument
>> > absolutely needs to be 32 bits and that should be enough.
>>
>> This I don't understand. Why not make the function self documenting
>> when we achieve it with zero penalty?
>
>
> From what I can see, it's mostly a case of your patch doing two things:
> - it renames the function
> - it reimplements it
> Where possible, we prefer patches that do exactly one thing. I'd
> reimplement the function and have that go in as-is, and then renaming can
> become the eternal bikeshed that it always becomes. See, these things
> aren't technical in nature - unlike your reimplementation, which is simply
> faster because it's a better algorithm. These things are just based on
> personal preference, and so you'll never get a clean vote.
>
> So, statistically speaking, if you want your patch to have the highest
> chance of going in, make it do the minimal amount of change relative to
> status quo, and make it do so in as little code change as possible. ;-).

Got it, useful tip that I had forgotten. Patchv2 posted.

>
> Ronald
> ___
> 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] [PATCHv2] avutil/intmath: use de Bruijn based ff_ctz

[Ganesh Ajjanagadde]

It has already been demonstrated that the de Bruijn method has benefits
over the current implementation: commit 
971d12b7f9d7be3ca8eb98e6c04ed521f83cbd3c.
That commit implemented it for long long, this extends it to the int version.

Tested with FATE.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavutil/intmath.h | 32 +++-
 1 file changed, 7 insertions(+), 25 deletions(-)

diff --git a/libavutil/intmath.h b/libavutil/intmath.h
index 802abe3..5a55123 100644
--- a/libavutil/intmath.h
+++ b/libavutil/intmath.h
@@ -129,33 +129,15 @@ static av_always_inline av_const int 
ff_log2_16bit_c(unsigned int v)
  * @return   the number of trailing 0-bits
  */
 #if !defined( _MSC_VER )
+/* We use the De-Bruijn method outlined in:
+ * http://supertech.csail.mit.edu/papers/debruijn.pdf. */
 static av_always_inline av_const int ff_ctz_c(int v)
 {
-int c;
-
-if (v & 0x1)
-return 0;
-
-c = 1;
-if (!(v & 0x)) {
-v >>= 16;
-c += 16;
-}
-if (!(v & 0xff)) {
-v >>= 8;
-c += 8;
-}
-if (!(v & 0xf)) {
-v >>= 4;
-c += 4;
-}
-if (!(v & 0x3)) {
-v >>= 2;
-c += 2;
-}
-c -= v & 0x1;
-
-return c;
+static const uint8_t debruijn_ctz32[32] = {
+0, 1, 28, 2, 29, 14, 24, 3, 30, 22, 20, 15, 25, 17, 4, 8,
+31, 27, 13, 23, 21, 19, 16, 7, 26, 12, 18, 6, 11, 5, 10, 9
+};
+return debruijn_ctz32[(uint32_t)((v & -v) * 0x077CB531U) >> 27];
 }
 #else
 static av_always_inline av_const int ff_ctz_c( int v )
-- 
2.6.1

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

[FFmpeg-devel] avfilter_graph Question

[Grady Player]

Currently using:

commit af5917698bd44f136fd0ff00a9e5f8b5f92f2d58
Author: Michael Niedermayer 
Date:   Sun May 17 01:34:35 2015 +0200

I am trying to set up a small filter graph in order to use the YADIF 
implementation in libavfilter...

I have set up an avfilter_graph with 3 filters…

avfilter_register_all();
avfGraph = avfilter_graph_alloc();

AVFilter * bufferFilter, * yadifFilter, * bufferSink;

bufferFilter = avfilter_get_by_name("buffer");
yadifFilter = avfilter_get_by_name("yadif");
bufferSink = avfilter_get_by_name("buffersink”);

  /* dynamic configuration here */
   
avfilter_graph_create_filter(/*done for each filter */);

if (err >= 0) err = avfilter_link(buffer_ctx, 0, yadif_ctx, 0);
if (err >= 0) err = avfilter_link(yadif_ctx, 0, sink_ctx, 0);

if (err>=0) err = avfilter_graph_config(avfGraph, NULL);


Then I feed frames into the graph with:

err = av_buffersrc_add_frame(buffer_ctx, avf);

and pull frames out of the graph with:

  AVFrame * oframe = av_frame_alloc();
  err = av_buffersink_get_frame(sink_ctx, oframe);


 this all seems to work pretty well, except it is holding on to a lot of memory 
that is released in avfilter_graph_free()

I suspect it is something dumb, but is there something I need to be doing to 
release internal references to some resource?

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

Re: [FFmpeg-devel] [PATCHv3 1/2] avfilter/all: propagate errors of functions from avfilter/formats

[Ganesh Ajjanagadde]

On Wed, Oct 14, 2015 at 7:57 AM, Ganesh Ajjanagadde  wrote:
> On Wed, Oct 14, 2015 at 7:47 AM, Michael Niedermayer
>  wrote:
>> On Tue, Oct 13, 2015 at 08:33:33PM -0400, Ganesh Ajjanagadde wrote:
>>> Hi all,
>>>
>>> Attached is a new version reflecting all freedback received so far.
>>
>> builds and passes fate here
>> also small nitpick
>> libavfilter/vsrc_life.c: In function ‘query_formats’:
>> libavfilter/vsrc_life.c:420:9: warning: unused variable ‘ret’ 
>> [-Wunused-variable]
>>
>> no objections from me (but i didnt review most of this patch)
>
> Will change and push later today. At worst, we will have a few issues
> that need sorting out. At best, nothing needs to be done.
> Thanks all for looking at this.

pushed

>
>>
>> [...]
>>
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> Dictatorship naturally arises out of democracy, and the most aggravated
>> form of tyranny and slavery out of the most extreme liberty. -- Plato
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Nicolas George]

Le primidi 11 vendémiaire, an CCXXIV, Paul B Mahol a écrit :
> >>Ah! So, in other words, it takes input frames, totally disregads their
> >>pts/dts, and puts each one into a cfr output stream at the given fps?
> >>
> >>That solves a lot of problems and ridiculous math. :-) I will try it.
> > Can't this be accomplished by the setpts filter?
> setpts filter doesnt change framerate, so generally no.

Are you sure? It seems to be exactly one of the setpts examples:

   ·   Set fixed rate of 25 frames per second:

   setpts=N/(25*TB)

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH] avfilter/af_tremolo: clean up extra newlines

[Kyle Swanson]

Signed-off-by: Kyle Swanson 
---
 libavfilter/af_tremolo.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libavfilter/af_tremolo.c b/libavfilter/af_tremolo.c
index 0ae7a7c..50df2e4 100644
--- a/libavfilter/af_tremolo.c
+++ b/libavfilter/af_tremolo.c
@@ -131,9 +131,7 @@ static int config_input(AVFilterLink *inlink)
 
 for (i = 0; i < inlink->sample_rate; i++) {
 double env = s->freq * i / inlink->sample_rate;
-
 env = sin(2 * M_PI * fmod(env + 0.25, 1.0));
-
 s->table[i] = env * (1 - fabs(offset)) + offset;
 }
 
-- 
1.8.4

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

Re: [FFmpeg-devel] [PATCH]vc1 Autodetection

[Carl Eugen Hoyos]

Michael Niedermayer  niedermayer.cc> writes:

> >  Makefile  |2 -
> >  rawdec.c  |4 ---
> >  vc1dec.c  |   81 +++
> >  version.h |2 -
> >  4 files changed, 83 insertions(+), 6 deletions(-)
> > bdbacfecbe65093e8c50876d7ffa6eb9b8719a9d  patchvc1probe2.diff
> 
> LGTM

Patch applied.

Thank you, Carl Eugen

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

Re: [FFmpeg-devel] Integration of RTMFP

[Thomas Jammet]

Hi all,

I would like to know what do I need to do if I want to share my "librtmfp"
wrapper (something that should looks like this one
). Is
there someone I should contact? Are there licensing prerequisites for the
external library?

About an implementation in FFMpeg it should be possible in a second time if
there is someone able to help on this. Does anybody will be interested for
this? There should be a lot of work since it will be more complicated than
RTMP and we expect to add support to multicasting.

Thank you

Best Regards

*--*

*Thomas JAMMET*
http://fr.linkedin.com/pub/thomas-jammet/5a/411/60b/

2015-10-02 14:23 GMT+02:00 Thomas Jammet :

> Hi Carl,
>
> Sorry I have thought about it but it is not possible, we want a standalone
> library. In any case I will do the integration in ffmpeg.
>
> Regards
>
> *--*
>
> *Thomas JAMMET*
> Freelancer - MonaServer.ovh
> 14 Place Maschat - 19000 Tulle (France)
> Tel : *+336 23 46 39 80 <%2B336%2023%2046%2039%2080>*
> http://fr.linkedin.com/pub/thomas-jammet/5a/411/60b/
>
> 2015-10-02 12:39 GMT+02:00 Carl Eugen Hoyos :
>
>> Thomas Jammet  gmail.com> writes:
>>
>> > I am working on a new library that will implements
>> > the RTMFP protocol's client part.
>>
>> Can't this be implemented within FFmpeg?
>>
>> Carl Eugen
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Hendrik Leppkes]

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.

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

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

[Paul B Mahol]

Dana 14. 10. 2015. 16:20 osoba "Nicolas George"  napisala
je:
>
> Le primidi 11 vendémiaire, an CCXXIV, Paul B Mahol a écrit :
> > >>Ah! So, in other words, it takes input frames, totally disregads their
> > >>pts/dts, and puts each one into a cfr output stream at the given fps?
> > >>
> > >>That solves a lot of problems and ridiculous math. :-) I will try it.
> > > Can't this be accomplished by the setpts filter?
> > setpts filter doesnt change framerate, so generally no.
>
> Are you sure? It seems to be exactly one of the setpts examples:
>
>·   Set fixed rate of 25 frames per second:
>
>setpts=N/(25*TB)
>
> Regards,
>
> --
>   Nicolas George
>
>

This changes pts but framerate remains same.
___
> 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] dnxhd: interleave AC levels and flags

[Christophe Gisquet]

This allows more efficient access to the array as the level and flags
are contiguous. Around 4% faster coefficient decoding.
---
Not the cleanest, and may complicate adding new profiles. But DNxHR
just got added, so it should be ok for some years.
---
 libavcodec/dnxhddata.c | 492 ++---
 libavcodec/dnxhddata.h |   3 +-
 libavcodec/dnxhddec.c  |   7 +-
 libavcodec/dnxhdenc.c  |   6 +-
 4 files changed, 231 insertions(+), 277 deletions(-)

diff --git a/libavcodec/dnxhddata.c b/libavcodec/dnxhddata.c
index 87499c7..82fbfdf 100644
--- a/libavcodec/dnxhddata.c
+++ b/libavcodec/dnxhddata.c
@@ -334,45 +334,40 @@ static const uint8_t dnxhd_1237_ac_bits[257] = {
 };
 
 /* Used in CID 1237, 1242, 1253, 1259, 1260, 1273, 1274 */
-static const uint8_t dnxhd_1237_ac_level[257] = {
-  3,  3,  5,  0,  7,  9,  5, 11, 13, 15,  7, 17, 19, 21, 23, 25,
-  9, 11, 27, 29, 31, 33, 13, 35, 37, 39, 41, 43, 15, 45, 47, 49,
- 51, 53, 55, 17, 19, 57, 59, 61, 63, 65, 67, 69, 21, 23, 25, 71,
- 73, 75, 77, 79, 81, 83, 27, 29, 31, 33, 85, 87, 89, 91, 93, 95,
- 97, 99,101,103,105, 35, 37, 39, 41, 43,107,109,111,113,115,117,
-119,121,123,129,  3, 45, 47, 49, 51, 53, 55,125,127,  5,  7,  9,
- 11, 13, 15, 17, 19, 21, 23, 25, 27, 29, 31, 33, 35, 37, 39, 41,
- 43, 45, 47, 49, 51, 53, 55, 57, 59, 61, 63, 65, 67, 69, 71, 73,
- 75, 77, 79, 81, 83, 85, 87, 89, 91, 93, 95, 97, 99,101,103,105,
-107,109,111,113,115,117,119,121,123,125,127,129, 57, 59, 61, 63,
- 65, 67, 69, 71, 73, 75, 77, 79, 81, 83, 85, 87, 89, 91, 93, 95,
- 97, 99,101,103,105,107,109,111,113,115,117,119,121,123,125,127,
-129,  3,  5,  7,  9, 11, 13, 15, 17, 19, 21, 23, 25, 27, 29, 31,
- 33, 35, 37, 39, 41, 43, 45, 47, 49, 51, 53, 55, 57, 59, 61, 63,
- 65, 67, 69, 71, 73, 75, 77, 79, 81, 83, 85, 87, 89, 91, 93, 95,
- 97, 99,101,103,105,107,109,111,113,115,117,119,121,123,125,127,
-129,
-};
-
-/* Used in CID 1237, 1242, 1253, 1259, 1260, 1273, 1274 */
-static const uint8_t dnxhd_1237_ac_flags[257] = {
-0, 2, 0, 0, 0, 0, 2, 0, 0, 0, 2, 0, 0, 0, 0, 0,
-2, 2, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 2, 0, 0, 0,
-0, 0, 0, 2, 2, 0, 0, 0, 0, 0, 0, 0, 2, 2, 2, 0,
-0, 0, 0, 0, 0, 0, 2, 2, 2, 2, 0, 0, 0, 0, 0, 0,
-0, 0, 0, 0, 0, 2, 2, 2, 2, 2, 0, 0, 0, 0, 0, 0,
-0, 0, 0, 0, 1, 2, 2, 2, 2, 2, 2, 0, 0, 1, 1, 1,
-1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
-1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
-1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
-1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2,
-2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
-2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
-2, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
-3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
-3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
-3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
-3,
+static const uint8_t dnxhd_1237_ac_info[2*257] = {
+  3, 0,   3, 2,   5, 0,   0, 0,   7, 0,   9, 0,   5, 2,  11, 0,
+ 13, 0,  15, 0,   7, 2,  17, 0,  19, 0,  21, 0,  23, 0,  25, 0,
+  9, 2,  11, 2,  27, 0,  29, 0,  31, 0,  33, 0,  13, 2,  35, 0,
+ 37, 0,  39, 0,  41, 0,  43, 0,  15, 2,  45, 0,  47, 0,  49, 0,
+ 51, 0,  53, 0,  55, 0,  17, 2,  19, 2,  57, 0,  59, 0,  61, 0,
+ 63, 0,  65, 0,  67, 0,  69, 0,  21, 2,  23, 2,  25, 2,  71, 0,
+ 73, 0,  75, 0,  77, 0,  79, 0,  81, 0,  83, 0,  27, 2,  29, 2,
+ 31, 2,  33, 2,  85, 0,  87, 0,  89, 0,  91, 0,  93, 0,  95, 0,
+ 97, 0,  99, 0, 101, 0, 103, 0, 105, 0,  35, 2,  37, 2,  39, 2,
+ 41, 2,  43, 2, 107, 0, 109, 0, 111, 0, 113, 0, 115, 0, 117, 0,
+119, 0, 121, 0, 123, 0, 129, 0,   3, 1,  45, 2,  47, 2,  49, 2,
+ 51, 2,  53, 2,  55, 2, 125, 0, 127, 0,   5, 1,   7, 1,   9, 1,
+ 11, 1,  13, 1,  15, 1,  17, 1,  19, 1,  21, 1,  23, 1,  25, 1,
+ 27, 1,  29, 1,  31, 1,  33, 1,  35, 1,  37, 1,  39, 1,  41, 1,
+ 43, 1,  45, 1,  47, 1,  49, 1,  51, 1,  53, 1,  55, 1,  57, 1,
+ 59, 1,  61, 1,  63, 1,  65, 1,  67, 1,  69, 1,  71, 1,  73, 1,
+ 75, 1,  77, 1,  79, 1,  81, 1,  83, 1,  85, 1,  87, 1,  89, 1,
+ 91, 1,  93, 1,  95, 1,  97, 1,  99, 1, 101, 1, 103, 1, 105, 1,
+107, 1, 109, 1, 111, 1, 113, 1, 115, 1, 117, 1, 119, 1, 121, 1,
+123, 1, 125, 1, 127, 1, 129, 1,  57, 2,  59, 2,  61, 2,  63, 2,
+ 65, 2,  67, 2,  69, 2,  71, 2,  73, 2,  75, 2,  77, 2,  79, 2,
+ 81, 2,  83, 2,  85, 2,  87, 2,  89, 2,  91, 2,  93, 2,  95, 2,
+ 97, 2,  99, 2, 101, 2, 103, 2, 105, 2, 107, 2, 109, 2, 111, 2,
+113, 2, 115, 2, 117, 2, 119, 2, 121, 2, 123, 2, 125, 2, 127, 2,
+129, 2,   3, 3,   5, 3,   7, 3,   9, 3,  11, 3,  13, 3,  15, 3,
+ 17, 3,  19, 3,  21, 3,  23, 3,  25, 3,  27, 3,  29, 3,  31, 3,
+ 33, 3,  35, 3,  37, 3,  39, 3,  41, 3,  43, 3,  45, 3,  47, 3,
+ 49, 3,  51, 3,  53, 3,  55, 3,  57, 3,  59, 3,  61, 3,  63, 3,
+ 65, 3,  67, 3,  69, 3,  71, 3,  73, 3,  75, 3,  77, 3,  79, 3,
+ 81, 3,  83, 

[FFmpeg-devel] [PATCH] aac: Make codec init run under ff_thread_once

[Derek Buitenhuis]

This makes AAC init threadsafe.

Signed-off-by: Derek Buitenhuis 
---
This relies on the latest merge from Libav, which hasn't happened
yet.
---
 libavcodec/aacdec.c  |  2 ++
 libavcodec/aacdec_fixed.c|  1 +
 libavcodec/aacdec_template.c | 80 +---
 3 files changed, 49 insertions(+), 34 deletions(-)

diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index 837102f..f53803b 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -551,6 +551,7 @@ AVCodec ff_aac_decoder = {
 AV_SAMPLE_FMT_FLTP, AV_SAMPLE_FMT_NONE
 },
 .capabilities= AV_CODEC_CAP_CHANNEL_CONF | AV_CODEC_CAP_DR1,
+.caps_internal   = FF_CODEC_CAP_INIT_THREADSAFE,
 .channel_layouts = aac_channel_layout,
 .flush = flush,
 .priv_class  = _decoder_class,
@@ -575,6 +576,7 @@ AVCodec ff_aac_latm_decoder = {
 AV_SAMPLE_FMT_FLTP, AV_SAMPLE_FMT_NONE
 },
 .capabilities= AV_CODEC_CAP_CHANNEL_CONF | AV_CODEC_CAP_DR1,
+.caps_internal   = FF_CODEC_CAP_INIT_THREADSAFE,
 .channel_layouts = aac_channel_layout,
 .flush = flush,
 .profiles= profiles,
diff --git a/libavcodec/aacdec_fixed.c b/libavcodec/aacdec_fixed.c
index 875ef58..923fbe0 100644
--- a/libavcodec/aacdec_fixed.c
+++ b/libavcodec/aacdec_fixed.c
@@ -438,6 +438,7 @@ AVCodec ff_aac_fixed_decoder = {
 AV_SAMPLE_FMT_S32P, AV_SAMPLE_FMT_NONE
 },
 .capabilities= AV_CODEC_CAP_CHANNEL_CONF | AV_CODEC_CAP_DR1,
+.caps_internal   = FF_CODEC_CAP_INIT_THREADSAFE,
 .channel_layouts = aac_channel_layout,
 .flush = flush,
 };
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index c2d7d05..aabd3f0 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -89,6 +89,8 @@
Parametric Stereo.
  */
 
+#include "libavutil/thread.h"
+
 static VLC vlc_scalefactors;
 static VLC vlc_spectral[11];
 
@@ -1063,11 +1065,55 @@ static void reset_predictor_group(PredictorState *ps, 
int group_num)
 
 static void aacdec_init(AACContext *ac);
 
+static av_cold void aac_static_table_init()
+{
+AAC_INIT_VLC_STATIC( 0, 304);
+AAC_INIT_VLC_STATIC( 1, 270);
+AAC_INIT_VLC_STATIC( 2, 550);
+AAC_INIT_VLC_STATIC( 3, 300);
+AAC_INIT_VLC_STATIC( 4, 328);
+AAC_INIT_VLC_STATIC( 5, 294);
+AAC_INIT_VLC_STATIC( 6, 306);
+AAC_INIT_VLC_STATIC( 7, 268);
+AAC_INIT_VLC_STATIC( 8, 510);
+AAC_INIT_VLC_STATIC( 9, 366);
+AAC_INIT_VLC_STATIC(10, 462);
+
+AAC_RENAME(ff_aac_sbr_init)();
+
+ff_aac_tableinit();
+
+INIT_VLC_STATIC(_scalefactors, 7,
+FF_ARRAY_ELEMS(ff_aac_scalefactor_code),
+ff_aac_scalefactor_bits,
+sizeof(ff_aac_scalefactor_bits[0]),
+sizeof(ff_aac_scalefactor_bits[0]),
+ff_aac_scalefactor_code,
+sizeof(ff_aac_scalefactor_code[0]),
+sizeof(ff_aac_scalefactor_code[0]),
+352);
+
+// window initialization
+AAC_RENAME(ff_kbd_window_init)(AAC_RENAME(ff_aac_kbd_long_1024), 4.0, 
1024);
+AAC_RENAME(ff_kbd_window_init)(AAC_RENAME(ff_aac_kbd_short_128), 6.0, 128);
+AAC_RENAME(ff_init_ff_sine_windows)(10);
+AAC_RENAME(ff_init_ff_sine_windows)( 9);
+AAC_RENAME(ff_init_ff_sine_windows)( 7);
+
+AAC_RENAME(cbrt_tableinit)();
+}
+
+static AVOnce aac_init = AV_ONCE_INIT;
+
 static av_cold int aac_decode_init(AVCodecContext *avctx)
 {
 AACContext *ac = avctx->priv_data;
 int ret;
 
+ret = ff_thread_once(_init, _static_table_init);
+if (ret != 0)
+return AVERROR_UNKNOWN;
+
 ac->avctx = avctx;
 ac->oc[1].m4ac.sample_rate = avctx->sample_rate;
 
@@ -1119,20 +1165,6 @@ static av_cold int aac_decode_init(AVCodecContext *avctx)
 return AVERROR_INVALIDDATA;
 }
 
-AAC_INIT_VLC_STATIC( 0, 304);
-AAC_INIT_VLC_STATIC( 1, 270);
-AAC_INIT_VLC_STATIC( 2, 550);
-AAC_INIT_VLC_STATIC( 3, 300);
-AAC_INIT_VLC_STATIC( 4, 328);
-AAC_INIT_VLC_STATIC( 5, 294);
-AAC_INIT_VLC_STATIC( 6, 306);
-AAC_INIT_VLC_STATIC( 7, 268);
-AAC_INIT_VLC_STATIC( 8, 510);
-AAC_INIT_VLC_STATIC( 9, 366);
-AAC_INIT_VLC_STATIC(10, 462);
-
-AAC_RENAME(ff_aac_sbr_init)();
-
 #if USE_FIXED
 ac->fdsp = avpriv_alloc_fixed_dsp(avctx->flags & AV_CODEC_FLAG_BITEXACT);
 #else
@@ -1144,18 +1176,6 @@ static av_cold int aac_decode_init(AVCodecContext *avctx)
 
 ac->random_state = 0x1f2e3d4c;
 
-ff_aac_tableinit();
-
-INIT_VLC_STATIC(_scalefactors, 7,
-FF_ARRAY_ELEMS(ff_aac_scalefactor_code),
-ff_aac_scalefactor_bits,
-sizeof(ff_aac_scalefactor_bits[0]),
-sizeof(ff_aac_scalefactor_bits[0]),
-ff_aac_scalefactor_code,
-sizeof(ff_aac_scalefactor_code[0]),
-

Re: [FFmpeg-devel] [PATCH] ffmpeg_opt: rename loop option to loop2

[Ganesh Ajjanagadde]

On Wed, Oct 14, 2015 at 2:23 PM, Michael Niedermayer  wrote:
> From: Michael Niedermayer 
>
> The "loop" option is used in several demuxers (like img2dec) and muxers, 
> using the same name in ffmpeg_opt
> breaks them. Feel free to revert this and replace by any other solution or 
> rename both as preferred
> This is just as a quick fix to avoid the regression with existing command 
> lines and to have both named
> the same (which does not work)

quick alternative (based on help text) - stream_loop in ffmpeg_opt?

>
> Example:
> ./ffmpeg -loop 1 -i fate-suite/png1/lena-rgb24.png -t 1 test.avi
> will produce 25 frames with the img2dec loop but only 1 frame at 25fps with 
> the ffmpeg loop option
>
> Signed-off-by: Michael Niedermayer 
> ---
>  ffmpeg_opt.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
> index 573da72..b99a75a 100644
> --- a/ffmpeg_opt.c
> +++ b/ffmpeg_opt.c
> @@ -3158,7 +3158,7 @@ const OptionDef options[] = {
>  { "dump_attachment", HAS_ARG | OPT_STRING | OPT_SPEC |
>   OPT_EXPERT | OPT_INPUT, { .off 
> = OFFSET(dump_attachment) },
>  "extract an attachment into a file", "filename" },
> -{ "loop", OPT_INT | HAS_ARG | OPT_EXPERT | OPT_INPUT |
> +{ "loop2", OPT_INT | HAS_ARG | OPT_EXPERT | OPT_INPUT |
>  OPT_OFFSET,  { .off 
> = OFFSET(loop) }, "set number of times input stream shall be looped", "loop 
> count" },
>  { "debug_ts",   OPT_BOOL | OPT_EXPERT,   { 
> _ts },
>  "print timestamp debugging info" },
> --
> 1.7.9.5
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Nicolas George]

Le tridi 23 vendémiaire, an CCXXIV, Paul B Mahol a écrit :
> This changes pts but framerate remains same.

Care to ellaborate?

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] avfilter_graph Question

[Paul B Mahol]

Dana 14. 10. 2015. 17:36 osoba "Grady Player" <
grady.pla...@verizondigitalmedia.com> napisala je:
>
> Currently using:
>
> commit af5917698bd44f136fd0ff00a9e5f8b5f92f2d58
> Author: Michael Niedermayer 
> Date:   Sun May 17 01:34:35 2015 +0200
>
> I am trying to set up a small filter graph in order to use the YADIF
implementation in libavfilter...
>
> I have set up an avfilter_graph with 3 filters…
>
> avfilter_register_all();
> avfGraph = avfilter_graph_alloc();
>
> AVFilter * bufferFilter, * yadifFilter, * bufferSink;
>
> bufferFilter = avfilter_get_by_name("buffer");
> yadifFilter = avfilter_get_by_name("yadif");
> bufferSink = avfilter_get_by_name("buffersink”);
>
>   /* dynamic configuration here */
>
> avfilter_graph_create_filter(/*done for each filter */);
>
> if (err >= 0) err = avfilter_link(buffer_ctx, 0, yadif_ctx, 0);
> if (err >= 0) err = avfilter_link(yadif_ctx, 0, sink_ctx, 0);
>
> if (err>=0) err = avfilter_graph_config(avfGraph, NULL);
>
>
> Then I feed frames into the graph with:
>
> err = av_buffersrc_add_frame(buffer_ctx, avf);
>
> and pull frames out of the graph with:
>
>   AVFrame * oframe = av_frame_alloc();
>   err = av_buffersink_get_frame(sink_ctx, oframe);
>
>
>  this all seems to work pretty well, except it is holding on to a lot of
memory that is released in avfilter_graph_free()
>
> I suspect it is something dumb, but is there something I need to be doing
to release internal references to some resource?
>
>
>

Do you free frame you no longer need?
___
> 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/intmath: use de Bruijn based ff_ctz

[Ronald S. Bultje]

Hi,

On Wed, Oct 14, 2015 at 10:26 AM, Ganesh Ajjanagadde  wrote:

> It has already been demonstrated that the de Bruijn method has benefits
> over the current implementation: commit
> 971d12b7f9d7be3ca8eb98e6c04ed521f83cbd3c.
> That commit implemented it for long long, this extends it to the int
> version.
>
> Tested with FATE.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/intmath.h | 32 +++-
>  1 file changed, 7 insertions(+), 25 deletions(-)
>
> diff --git a/libavutil/intmath.h b/libavutil/intmath.h
> index 802abe3..5a55123 100644
> --- a/libavutil/intmath.h
> +++ b/libavutil/intmath.h
> @@ -129,33 +129,15 @@ static av_always_inline av_const int
> ff_log2_16bit_c(unsigned int v)
>   * @return   the number of trailing 0-bits
>   */
>  #if !defined( _MSC_VER )
> +/* We use the De-Bruijn method outlined in:
> + * http://supertech.csail.mit.edu/papers/debruijn.pdf. */
>  static av_always_inline av_const int ff_ctz_c(int v)
>  {
> -int c;
> -
> -if (v & 0x1)
> -return 0;
> -
> -c = 1;
> -if (!(v & 0x)) {
> -v >>= 16;
> -c += 16;
> -}
> -if (!(v & 0xff)) {
> -v >>= 8;
> -c += 8;
> -}
> -if (!(v & 0xf)) {
> -v >>= 4;
> -c += 4;
> -}
> -if (!(v & 0x3)) {
> -v >>= 2;
> -c += 2;
> -}
> -c -= v & 0x1;
> -
> -return c;
> +static const uint8_t debruijn_ctz32[32] = {
> +0, 1, 28, 2, 29, 14, 24, 3, 30, 22, 20, 15, 25, 17, 4, 8,
> +31, 27, 13, 23, 21, 19, 16, 7, 26, 12, 18, 6, 11, 5, 10, 9
> +};
> +return debruijn_ctz32[(uint32_t)((v & -v) * 0x077CB531U) >> 27];
>  }
>  #else
>  static av_always_inline av_const int ff_ctz_c( int v )
> --
> 2.6.1


lgtm. Would you like to push yourself or have me do it for you?

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

Re: [FFmpeg-devel] avfilter_graph Question

[Grady Player]

Yes, sorry this was omitted  - after I am done I call:
 
av_frame_free();

it seems to be something that is internally referenced by the graph...


On Oct 14, 2015, at 10:50 AM, Paul B Mahol  wrote:

> Dana 14. 10. 2015. 17:36 osoba "Grady Player" <
> grady.pla...@verizondigitalmedia.com> napisala je:
>> 
>> Currently using:
>> 
>> commit af5917698bd44f136fd0ff00a9e5f8b5f92f2d58
>> Author: Michael Niedermayer 
>> Date:   Sun May 17 01:34:35 2015 +0200
>> 
>> I am trying to set up a small filter graph in order to use the YADIF
> implementation in libavfilter...
>> 
>> I have set up an avfilter_graph with 3 filters…
>> 
>>avfilter_register_all();
>>avfGraph = avfilter_graph_alloc();
>> 
>>AVFilter * bufferFilter, * yadifFilter, * bufferSink;
>> 
>>bufferFilter = avfilter_get_by_name("buffer");
>>yadifFilter = avfilter_get_by_name("yadif");
>>bufferSink = avfilter_get_by_name("buffersink”);
>> 
>>  /* dynamic configuration here */
>> 
>>avfilter_graph_create_filter(/*done for each filter */);
>> 
>>if (err >= 0) err = avfilter_link(buffer_ctx, 0, yadif_ctx, 0);
>>if (err >= 0) err = avfilter_link(yadif_ctx, 0, sink_ctx, 0);
>> 
>>if (err>=0) err = avfilter_graph_config(avfGraph, NULL);
>> 
>> 
>> Then I feed frames into the graph with:
>> 
>>err = av_buffersrc_add_frame(buffer_ctx, avf);
>> 
>> and pull frames out of the graph with:
>> 
>>  AVFrame * oframe = av_frame_alloc();
>>  err = av_buffersink_get_frame(sink_ctx, oframe);
>> 
>> 
>> this all seems to work pretty well, except it is holding on to a lot of
> memory that is released in avfilter_graph_free()
>> 
>> I suspect it is something dumb, but is there something I need to be doing
> to release internal references to some resource?
>> 
>> 
>> 
> 
> Do you free frame you no longer need?
> ___
>> 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] request for feedback on video codec idea

[Roger Pack]

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-

[1] http://fastcompression.blogspot.com/2011/05/lz4-explained.html
search for "64" it has some kind of concept of a sliding window, or
perhaps that's just the frame API dunno.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil: install des.h, rc4.h and tree.h as public headers

[James Almer]

On 10/14/2015 2:16 PM, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Oct 14, 2015 at 10:50 AM, Nicolas George  wrote:
> 
>> Le duodi 22 vendémiaire, an CCXXIV, James Almer a écrit :
>>> Since these two were never installed, we can remove the
>> FF_API_CRYPTO_CONTEXT
>>> wrapper from them before applying this patch, as this would be the first
>> time
>>> the API becomes public.
>>>
>>> Now, what i want to know is what will it be in the end for the actual
>>> deprecation in question? Reimar and Nicolas were against making the
>> context
>>> opaque as having them in stack has its uses.
>>> I want to know what people want, since the deprecation is not present on
>> any
>>> release and we still have time to rollback. Do we keep the deprecation in
>>> place for des, rc4, blowfish and xtea, or remove it altogether?
>>
>> The reason for my objection are that the odds that the contents of the
>> context change in the future are very small for low-level standardized
>> crypto functions (this is the reason for making structure opaques). On the
>> other hand, foregoing the checks for memory allocations is nice, and crypto
>> functions may be used in speed-critical portions of the code where memory
>> allocations are not negligible.
> 
> 
> I think this is a reasonable argument, so +1 from me for "let's expose the
> struct and remove deprecations".
> 
> Ronald

Ok, i'll wait a bit in case someone else wants to comment then i'll send a
patch undoing the deprecations.

Thanks all for your input.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] winrt: multithreading support

[Wang Bin]

0001-winrt-multithreading-support.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] ffmpeg_opt: rename loop option to loop2

[Michael Niedermayer]

From: Michael Niedermayer 

The "loop" option is used in several demuxers (like img2dec) and muxers, using 
the same name in ffmpeg_opt
breaks them. Feel free to revert this and replace by any other solution or 
rename both as preferred
This is just as a quick fix to avoid the regression with existing command lines 
and to have both named
the same (which does not work)

Example:
./ffmpeg -loop 1 -i fate-suite/png1/lena-rgb24.png -t 1 test.avi
will produce 25 frames with the img2dec loop but only 1 frame at 25fps with the 
ffmpeg loop option

Signed-off-by: Michael Niedermayer 
---
 ffmpeg_opt.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 573da72..b99a75a 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -3158,7 +3158,7 @@ const OptionDef options[] = {
 { "dump_attachment", HAS_ARG | OPT_STRING | OPT_SPEC |
  OPT_EXPERT | OPT_INPUT, { .off = 
OFFSET(dump_attachment) },
 "extract an attachment into a file", "filename" },
-{ "loop", OPT_INT | HAS_ARG | OPT_EXPERT | OPT_INPUT |
+{ "loop2", OPT_INT | HAS_ARG | OPT_EXPERT | OPT_INPUT |
 OPT_OFFSET,  { .off = 
OFFSET(loop) }, "set number of times input stream shall be looped", "loop 
count" },
 { "debug_ts",   OPT_BOOL | OPT_EXPERT,   { 
_ts },
 "print timestamp debugging info" },
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH] fate: use PROGSSUF

[Christophe Gisquet]

May require exporting in the shell var PROGSUF when invoking a
shell script.
---
 tests/Makefile   | 14 +-
 tests/fate-run.sh| 38 +++---
 tests/fate/ffprobe.mak   |  2 +-
 tests/fate/filter-video.mak  |  4 ++--
 tests/fate/probe.mak |  2 +-
 tests/fate/vpx.mak   | 10 +-
 tests/ffserver-regression.sh |  2 +-
 tests/regression-funcs.sh|  4 ++--
 8 files changed, 40 insertions(+), 36 deletions(-)

diff --git a/tests/Makefile b/tests/Makefile
index c0c1958..7ee4a46 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -7,9 +7,12 @@ AREF = tests/data/asynth1.sw
 FATEW = 34
 FATEH = 34
 
+FFMPEG=ffmpeg$(PROGSSUF)$(EXESUF)
+
 $(AREF): CMP=
 
-ffservertest: ffserver$(EXESUF) tests/vsynth1/00.pgm tests/data/asynth1.sw
+ffservertest: export PROGSUF = $(PROGSSUF)
+ffservertest: ffserver$(PROGSSUF)$(EXESUF) tests/vsynth1/00.pgm 
tests/data/asynth1.sw
@echo
@echo "Unfortunately ffserver is broken and therefore its regression"
@echo "test fails randomly. Treat the results accordingly."
@@ -44,7 +47,7 @@ tests/test_copy.ffmeta: TAG = COPY
 tests/test_copy.ffmeta: tests/data
$(M)cp -f $(SRC_PATH)/tests/test.ffmeta tests/test_copy.ffmeta
 
-tests/data/ffprobe-test.nut: ffmpeg$(EXESUF) tests/test_copy.ffmeta
+tests/data/ffprobe-test.nut: ffmpeg$(PROGSSUF)$(EXESUF) tests/test_copy.ffmeta
$(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
 -f lavfi -i "aevalsrc=sin(400*PI*2*t):d=0.125[out0]; 
testsrc=d=0.125[out1]; testsrc=s=100x100:d=0.125[out2]" \
 -f ffmetadata -i $(TARGET_PATH)/tests/test_copy.ffmeta \
@@ -177,9 +180,9 @@ FATE += $(FATE-yes)
 RSYNC_OPTIONS-$(HAVE_RSYNC_CONTIMEOUT) += --contimeout=60
 RSYNC_OPTIONS = -vrltLW --timeout=60 $(RSYNC_OPTIONS-yes)
 
-$(FATE_FFMPEG) $(FATE_SAMPLES_AVCONV) $(FATE_SAMPLES_FFMPEG): ffmpeg$(EXESUF)
+$(FATE_FFMPEG) $(FATE_SAMPLES_AVCONV) $(FATE_SAMPLES_FFMPEG): 
ffmpeg$(PROGSSUF)$(EXESUF)
 
-$(FATE_FFPROBE) $(FATE_SAMPLES_FFPROBE): ffprobe$(EXESUF)
+$(FATE_FFPROBE) $(FATE_SAMPLES_FFPROBE): ffprobe$(PROGSSUF)$(EXESUF)
 
 ifdef SAMPLES
 FATE += $(FATE_FULL) $(FATE_FULL-yes)
@@ -201,6 +204,7 @@ TOOL = ffmpeg
 
 fate:: $(FATE)
 
+$(FATE) $(FATE_TESTS-no): export PROGSUF = $(PROGSSUF)
 $(FATE) $(FATE_TESTS-no): $(FATE_UTILS:%=tests/%$(HOSTEXESUF))
@echo "TEST$(@:fate-%=%)"
$(Q)$(SRC_PATH)/tests/fate-run.sh $@ "$(TARGET_SAMPLES)" 
"$(TARGET_EXEC)" "$(TARGET_PATH)" '$(CMD)' '$(CMP)' '$(REF)' '$(FUZZ)' 
'$(THREADS)' '$(THREAD_TYPE)' '$(CPUFLAGS)' '$(CMP_SHIFT)' '$(CMP_TARGET)' 
'$(SIZE_TOLERANCE)' '$(CMP_UNIT)' '$(GEN)' '$(HWACCEL)'
@@ -226,7 +230,7 @@ lcov-reset:
 clean:: testclean
 
 testclean::
-   $(RM) -r tests/vsynth1 tests/data tools/lavfi-showfiltfmts$(EXESUF)
+   $(RM) -r tests/vsynth1 tests/data 
tools/lavfi-showfiltfmts$(PROGSSUF)$(EXESUF)
$(RM) $(CLEANSUFFIXES:%=tests/%)
$(RM) $(TESTTOOLS:%=tests/%$(HOSTEXESUF))
$(RM) tests/pixfmts.mak tests/test_copy.ffmeta
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 76f66d3..648c67d 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -84,7 +84,7 @@ runecho(){
 }
 
 probefmt(){
-run ffprobe -show_entries format=format_name -print_format 
default=nw=1:nk=1 -v 0 "$@"
+run ffprobe${PROGSUF} -show_entries format=format_name -print_format 
default=nw=1:nk=1 -v 0 "$@"
 }
 
 runlocal(){
@@ -93,7 +93,7 @@ runlocal(){
 }
 
 probeframes(){
-run ffprobe -show_frames -v 0 "$@"
+run ffprobe${PROGSUF} -show_frames -v 0 "$@"
 }
 
 ffmpeg(){
@@ -103,33 +103,33 @@ ffmpeg(){
 [ x${arg} = x-i ] && ffmpeg_args="${ffmpeg_args} ${dec_opts}"
 ffmpeg_args="${ffmpeg_args} ${arg}"
 done
-run ffmpeg ${ffmpeg_args}
+run ./ffmpeg${PROGSUF} ${ffmpeg_args}
 }
 
 framecrc(){
-ffmpeg "$@" -flags +bitexact -fflags +bitexact -f framecrc -
+./ffmpeg${PROGSUF} "$@" -flags +bitexact -fflags +bitexact -f framecrc -
 }
 
 framemd5(){
-ffmpeg "$@" -flags +bitexact -fflags +bitexact -f framemd5 -
+./ffmpeg${PROGSUF} "$@" -flags +bitexact -fflags +bitexact -f framemd5 -
 }
 
 crc(){
-ffmpeg "$@" -f crc -
+./ffmpeg${PROGSUF} "$@" -f crc -
 }
 
 md5(){
-ffmpeg "$@" md5:
+./ffmpeg${PROGSUF} "$@" md5:
 }
 
 pcm(){
-ffmpeg "$@" -vn -f s16le -
+./ffmpeg${PROGSUF} "$@" -vn -f s16le -
 }
 
 fmtstdout(){
 fmt=$1
 shift 1
-ffmpeg -flags +bitexact -fflags +bitexact "$@" -f $fmt -
+./ffmpeg${PROGSUF} -flags +bitexact -fflags +bitexact "$@" -f $fmt -
 }
 
 enc_dec_pcm(){
@@ -141,8 +141,8 @@ enc_dec_pcm(){
 encfile="${outdir}/${test}.${out_fmt}"
 cleanfiles=$encfile
 encfile=$(target_path ${encfile})
-ffmpeg -i $src_file "$@" -f $out_fmt -y ${encfile} || return
-ffmpeg -flags +bitexact -fflags +bitexact -i ${encfile} -c:a 
pcm_${pcm_fmt} -fflags +bitexact -f ${dec_fmt} -
+./ffmpeg${PROGSUF} -i $src_file "$@" -f $out_fmt -y ${encfile} || return
+./ffmpeg${PROGSUF} 

Re: [FFmpeg-devel] [PATCHv2] avutil/intmath: use de Bruijn based ff_ctz

[Ganesh Ajjanagadde]

On Wed, Oct 14, 2015 at 1:13 PM, Ronald S. Bultje  wrote:
> Hi,
>
> On Wed, Oct 14, 2015 at 10:26 AM, Ganesh Ajjanagadde
>  wrote:
>>
>> It has already been demonstrated that the de Bruijn method has benefits
>> over the current implementation: commit
>> 971d12b7f9d7be3ca8eb98e6c04ed521f83cbd3c.
>> That commit implemented it for long long, this extends it to the int
>> version.
>>
>> Tested with FATE.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavutil/intmath.h | 32 +++-
>>  1 file changed, 7 insertions(+), 25 deletions(-)
>>
>> diff --git a/libavutil/intmath.h b/libavutil/intmath.h
>> index 802abe3..5a55123 100644
>> --- a/libavutil/intmath.h
>> +++ b/libavutil/intmath.h
>> @@ -129,33 +129,15 @@ static av_always_inline av_const int
>> ff_log2_16bit_c(unsigned int v)
>>   * @return   the number of trailing 0-bits
>>   */
>>  #if !defined( _MSC_VER )
>> +/* We use the De-Bruijn method outlined in:
>> + * http://supertech.csail.mit.edu/papers/debruijn.pdf. */
>>  static av_always_inline av_const int ff_ctz_c(int v)
>>  {
>> -int c;
>> -
>> -if (v & 0x1)
>> -return 0;
>> -
>> -c = 1;
>> -if (!(v & 0x)) {
>> -v >>= 16;
>> -c += 16;
>> -}
>> -if (!(v & 0xff)) {
>> -v >>= 8;
>> -c += 8;
>> -}
>> -if (!(v & 0xf)) {
>> -v >>= 4;
>> -c += 4;
>> -}
>> -if (!(v & 0x3)) {
>> -v >>= 2;
>> -c += 2;
>> -}
>> -c -= v & 0x1;
>> -
>> -return c;
>> +static const uint8_t debruijn_ctz32[32] = {
>> +0, 1, 28, 2, 29, 14, 24, 3, 30, 22, 20, 15, 25, 17, 4, 8,
>> +31, 27, 13, 23, 21, 19, 16, 7, 26, 12, 18, 6, 11, 5, 10, 9
>> +};
>> +return debruijn_ctz32[(uint32_t)((v & -v) * 0x077CB531U) >> 27];
>>  }
>>  #else
>>  static av_always_inline av_const int ff_ctz_c( int v )
>> --
>> 2.6.1
>
>
> lgtm. Would you like to push yourself or have me do it for you?

Either way is fine: if it is not done by tonight, I will do it.
Thanks.

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

[Nicolas George]

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.

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 3/3][RFC] avfilter/vf_chromakey: Add OpenCL acceleration

[Wei Gao]

2015-10-14 14:31 GMT+08:00 Timo Rothenpieler :

> Hi
>>
>> I have check the error, for some card, yes, just like what I said above,
>> some cards does not support double type, so we must check the opencl
>> extension: cl_khr_fp64 before the kernel compile. If the device support,
>> we use GPU, else, we use CPU or use float type, Is it OK?
>>
>> Thanks
>> Best regards
>>
>>
> Of course, if there's a way to only fall back to floats if doubles are not
> available, that'd be preferable.
>
Hi

A simple idea is that

1. Check whether the device support cl_khr_fp64
2. Set a macro in build option. you can reference the unsharp filter, the
code is as follow:

snprintf(build_opts, 96, "-D LU_RADIUS_X=%d -D LU_RADIUS_Y=%d -D
CH_RADIUS_X=%d -D CH_RADIUS_Y=%d",
2*unsharp->luma.steps_x+1, 2*unsharp->luma.steps_y+1,
2*unsharp->chroma.steps_x+1, 2*unsharp->chroma.steps_y+1);
unsharp->opencl_ctx.program = av_opencl_compile("unsharp", build_opts);

use the macro to decide whether to use double or float at the compile stage

Do you think it is OK?

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

Re: [FFmpeg-devel] [PATCH 3/3][RFC] avfilter/vf_chromakey: Add OpenCL acceleration

[Timo Rothenpieler]

Hi

I have check the error, for some card, yes, just like what I said above,
some cards does not support double type, so we must check the opencl
extension: cl_khr_fp64 before the kernel compile. If the device support,
we use GPU, else, we use CPU or use float type, Is it OK?

Thanks
Best regards



Of course, if there's a way to only fall back to floats if doubles are 
not available, that'd be preferable.




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

Re: [FFmpeg-devel] [PATCH] avfilter, swresample, swscale: use fabs, fabsf instead of FFABS

[Carl Eugen Hoyos]

Ganesh Ajjanagadde  mit.edu> writes:

> >> I think the general case, it'd be nice to figure out
> >> why Carl's results are slightly different from yours
> >
> > Why do you think they are different at all?
> > Did you look at the tables?
> 
> They are different, and our conclusions are different 
> (in a slight way). Carl claims that the old code and 
> new code are mostly the same in speed, but in the 
> cases where they differ, the old code is faster.

No.

I wrote that both the numbers you posted and the numbers 
I posted show no proof that the new code is faster.
(Contrary to my numbers, your numbers show that the old 
code may be faster but that is irrelevant.)

The more important question is if you can see the same 
changes in the disassembly of af_astats.o as what 
ubitux posted here for a short test function?

Carl Eugen

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

[FFmpeg-devel] [PATCH 1/2] avutil/fifo: add function av_fifo_generic_peek_at()

[Zhang Rui]

---
 libavutil/fifo.c| 55 +
 libavutil/fifo.h| 11 +++
 tests/ref/fate/fifo | 27 ++
 3 files changed, 93 insertions(+)

diff --git a/libavutil/fifo.c b/libavutil/fifo.c
index 07fb4ec..a7da591 100644
--- a/libavutil/fifo.c
+++ b/libavutil/fifo.c
@@ -148,6 +148,38 @@ int av_fifo_generic_write(AVFifoBuffer *f, void *src, int 
size,
 return total - size;
 }
 
+int av_fifo_generic_peek_at(AVFifoBuffer *f, void *dest, int offset, int 
buf_size, void (*func)(void*, void*, int))
+{
+uint8_t *rptr = f->rptr + offset;
+uint32_t rndx = f->rndx + offset;
+
+av_assert2(offset >= 0);
+/*
+ * *ndx are indexes modulo 2^32, they are intended to overflow,
+ * to handle *ndx greater than 4gb.
+ */
+av_assert2((uint32_t)buf_size <= f->wndx - f->rndx - (uint32_t)offset);
+while (buf_size > 0) {
+int len;
+
+if (rptr >= f->end)
+rptr -= f->end - f->buffer;
+
+len = FFMIN(f->end - rptr, buf_size);
+if (func)
+func(dest, rptr, len);
+else {
+memcpy(dest, rptr, len);
+dest = (uint8_t *)dest + len;
+}
+
+buf_size -= len;
+rptr += len;
+}
+
+return 0;
+}
+
 int av_fifo_generic_peek(AVFifoBuffer *f, void *dest, int buf_size,
  void (*func)(void *, void *, int))
 {
@@ -223,6 +255,14 @@ int main(void)
 }
 printf("\n");
 
+/* peek_at at FIFO */
+n = av_fifo_size(fifo) / sizeof(int);
+for (i = 0; i < n; i++) {
+av_fifo_generic_peek_at(fifo, , i * sizeof(int), sizeof(j), NULL);
+printf("%d: %d\n", i, j);
+}
+printf("\n");
+
 /* read data */
 for (i = 0; av_fifo_size(fifo) >= sizeof(int); i++) {
 av_fifo_generic_read(fifo, , sizeof(int), NULL);
@@ -230,6 +270,21 @@ int main(void)
 }
 printf("\n");
 
+/* test *ndx overflow */
+av_fifo_reset(fifo);
+fifo->rndx = fifo->wndx = ~(uint32_t)0 - 5;
+
+/* fill data */
+for (i = 0; av_fifo_space(fifo) >= sizeof(int); i++)
+av_fifo_generic_write(fifo, , sizeof(int), NULL);
+
+/* peek_at at FIFO */
+n = av_fifo_size(fifo) / sizeof(int);
+for (i = 0; i < n; i++) {
+av_fifo_generic_peek_at(fifo, , i * sizeof(int), sizeof(j), NULL);
+printf("%d: %d\n", i, j);
+}
+
 av_fifo_free(fifo);
 
 return 0;
diff --git a/libavutil/fifo.h b/libavutil/fifo.h
index 0e4070b..dc7bc6f 100644
--- a/libavutil/fifo.h
+++ b/libavutil/fifo.h
@@ -84,6 +84,17 @@ int av_fifo_size(const AVFifoBuffer *f);
 int av_fifo_space(const AVFifoBuffer *f);
 
 /**
+ * Feed data at specific position from an AVFifoBuffer to a user-supplied 
callback.
+ * Similar as av_fifo_gereric_read but without discarding data.
+ * @param f AVFifoBuffer to read from
+ * @param offset offset from current read position
+ * @param buf_size number of bytes to read
+ * @param func generic read function
+ * @param dest data destination
+ */
+int av_fifo_generic_peek_at(AVFifoBuffer *f, void *dest, int offset, int 
buf_size, void (*func)(void*, void*, int));
+
+/**
  * Feed data from an AVFifoBuffer to a user-supplied callback.
  * Similar as av_fifo_gereric_read but without discarding data.
  * @param f AVFifoBuffer to read from
diff --git a/tests/ref/fate/fifo b/tests/ref/fate/fifo
index 18a5691..162d754 100644
--- a/tests/ref/fate/fifo
+++ b/tests/ref/fate/fifo
@@ -24,4 +24,31 @@
 11: 11
 12: 12
 
+0: 0
+1: 1
+2: 2
+3: 3
+4: 4
+5: 5
+6: 6
+7: 7
+8: 8
+9: 9
+10: 10
+11: 11
+12: 12
+
 0 1 2 3 4 5 6 7 8 9 10 11 12
+0: 0
+1: 1
+2: 2
+3: 3
+4: 4
+5: 5
+6: 6
+7: 7
+8: 8
+9: 9
+10: 10
+11: 11
+12: 12
-- 
2.5.3

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

Re: [FFmpeg-devel] [PATCH] libavcodec/qsv.c: Re-design session control and internal allocation

[Hendrik Leppkes]

On Wed, Oct 7, 2015 at 7:07 PM, Ivan Uskov  wrote:
> Hello wm4,
>
> Wednesday, October 7, 2015, 7:40:45 PM, you wrote:
>
> w> There's no automagic way to get this done.
>
> w> Hardware accelerators like vaapi and vdpau need the same thing. These
> w> have special APIs to set an API context on the decoder. Some APIs use
> w> hwaccel_context, vdpau uses av_vdpau_bind_context().
>
> w> The hwaccel_context pointer is untyped (just a void*), and what it means
> w> is implicit to the hwaccel or the decoder that is used. It could point
> w> to some sort of qsv state, which will have to be explicitly allocated
> w> and set by the API user (which might be ffmpeg.c).
> So  if  I will implement something like ffmpeg_qsv.c (using ffmpeg_vdpau.c as
> example)   and   extend  the  hwaccels[]  into  ffmpeg_opt.c  by corresponded
> qsv entries it  would  be the acceptable solution, correct?
>
> w> For filters there is no such thing yet. New API would have to be
> w> created. For filters in particular, we will have to make sure that the
> w> API isn't overly qsv-specific, and that it is extendable to other APIs
> w> (like for example vaapi or vdpau).
> Ok,   if   VPP  could be the  issue  I  would  like  to  get  working  direct
> link qsv_decoder-qsv_encoder first.
>

Libav has a patch that does exactly this, allow direct QSV->QSV
transcoding with help of some utility code in ffmpeg.c/avconv.c
You might want to look at that instead of re-inventing it. That'll
help make everyones live easier, as I'll just merge it when the time
comes, and the codebases don't diverge too drastically.

Adding VPP on top of that would be a future step then.

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/async: cache some data for fast seek backward

[Michael Niedermayer]

On Tue, Oct 13, 2015 at 06:30:47PM +0800, Zhang Rui wrote:
> ---
>  libavformat/async.c | 123 
> 
>  1 file changed, 104 insertions(+), 19 deletions(-)

applied

thanks

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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

[Christophe Gisquet]

2015-10-14 20:08 GMT+02:00 Roger Pack :
> 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].

It's generally the size of a window or dictionary, in which the
decoder can refer past strings.
There are of course far better dictionary-based methods, the details
coming to how much you can predict which strings are going to be
useful for a particular part of the image

Not exactly like blocks, though, as looking to another image is
already farther than a lot of the window sizes used.

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

That's Zip Motion Blocks Video, see zmbv. There's also an encoder.

Or equivalent. The fact that in screen content, images are pretty
static is rather well known. For natural content too, but with
somewhat different handling.

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

It's also a matter of parallelism and quality of implementation.

Otherwise, huffyuv, lagarith, and a lot of lossless codecs (ffv1?) are
mostly for natural images (where difference from a pixel to another is
small, or smaller than screen content). There's a gsoc project to add
inter-frame compression to ffv1 (don't know the status).

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

Well, practically, I think it's a dead end. I don't know if screen
content encoders were updated to handle multithreading (using slices
of images like ffv1 & co), but that might be a start, as speed is a
concern to you.

Now, there's value for yourself in discovering what all this entails.

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

Re: [FFmpeg-devel] [PATCH] ffmpeg_opt: rename loop option to loop2

[Ganesh Ajjanagadde]

On Wed, Oct 14, 2015 at 3:08 PM, Michael Niedermayer
 wrote:
> On Wed, Oct 14, 2015 at 02:33:30PM -0400, Ganesh Ajjanagadde wrote:
>> On Wed, Oct 14, 2015 at 2:23 PM, Michael Niedermayer  
>> wrote:
>> > From: Michael Niedermayer 
>> >
>> > The "loop" option is used in several demuxers (like img2dec) and muxers, 
>> > using the same name in ffmpeg_opt
>> > breaks them. Feel free to revert this and replace by any other solution or 
>> > rename both as preferred
>> > This is just as a quick fix to avoid the regression with existing command 
>> > lines and to have both named
>> > the same (which does not work)
>>
>> quick alternative (based on help text) - stream_loop in ffmpeg_opt?
>
> ok, renamed and applied

docs may need updating as well. Will check and send patch tonight.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The educated differ from the uneducated as much as the living from the
> dead. -- 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] request for feedback on video codec idea

[Hendrik Leppkes]

On Wed, Oct 14, 2015 at 9:04 PM, Paul B Mahol  wrote:
> Dana 14. 10. 2015. 20:42 osoba "Hendrik Leppkes" 
> napisala je:
>>
>> 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.
>
> Well each packet would have several frames, I assume encode2 can handle it.
>

Encoding can, decoding has trouble.
___
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

[Moritz Barsnick]

On Wed, Oct 14, 2015 at 12:08:58 -0600, Roger Pack wrote:
> 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).

Have you benchmarked existing lossless codecs for this specific kind of
content? Do you care to share?

I am under the impression that Lagarith wants to be very suitable for
this. (Not sure about speed though.)

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

Re: [FFmpeg-devel] avfilter_graph Question

[Ganesh Ajjanagadde]

On Wed, Oct 14, 2015 at 4:13 PM, Grady Player
 wrote:
> Figured it out, sharing (if anyone were to care)…
>
> I was using
>  av_buffersrc_add_frame
> rather than:
>  av_buffersrc_write_frame
>
> which informs the buffer to retain an internal reference to the original 
> picture/frame..

Was the documentation confusing? Any suggestions for improving the docs?

>
> -Grady
>
>
> On Oct 14, 2015, at 11:50 AM, Grady Player 
>  wrote:
>
>> Yes, sorry this was omitted  - after I am done I call:
>>
>> av_frame_free();
>>
>> it seems to be something that is internally referenced by the graph...
>>
>>
>> On Oct 14, 2015, at 10:50 AM, Paul B Mahol  wrote:
>>
>>> Dana 14. 10. 2015. 17:36 osoba "Grady Player" <
>>> grady.pla...@verizondigitalmedia.com> napisala je:

 Currently using:

 commit af5917698bd44f136fd0ff00a9e5f8b5f92f2d58
 Author: Michael Niedermayer 
 Date:   Sun May 17 01:34:35 2015 +0200

 I am trying to set up a small filter graph in order to use the YADIF
>>> implementation in libavfilter...

 I have set up an avfilter_graph with 3 filters…

avfilter_register_all();
avfGraph = avfilter_graph_alloc();

AVFilter * bufferFilter, * yadifFilter, * bufferSink;

bufferFilter = avfilter_get_by_name("buffer");
yadifFilter = avfilter_get_by_name("yadif");
bufferSink = avfilter_get_by_name("buffersink”);

  /* dynamic configuration here */

avfilter_graph_create_filter(/*done for each filter */);

if (err >= 0) err = avfilter_link(buffer_ctx, 0, yadif_ctx, 0);
if (err >= 0) err = avfilter_link(yadif_ctx, 0, sink_ctx, 0);

if (err>=0) err = avfilter_graph_config(avfGraph, NULL);


 Then I feed frames into the graph with:

err = av_buffersrc_add_frame(buffer_ctx, avf);

 and pull frames out of the graph with:

  AVFrame * oframe = av_frame_alloc();
  err = av_buffersink_get_frame(sink_ctx, oframe);


 this all seems to work pretty well, except it is holding on to a lot of
>>> memory that is released in avfilter_graph_free()

 I suspect it is something dumb, but is there something I need to be doing
>>> to release internal references to some resource?



>>>
>>> Do you free frame you no longer need?
>>> ___
 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 mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Paul B Mahol]

Dana 14. 10. 2015. 20:42 osoba "Hendrik Leppkes" 
napisala je:
>
> 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.

Well each packet would have several frames, I assume encode2 can handle it.

> - 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] ffmpeg_opt: rename loop option to loop2

[Michael Niedermayer]

On Wed, Oct 14, 2015 at 02:33:30PM -0400, Ganesh Ajjanagadde wrote:
> On Wed, Oct 14, 2015 at 2:23 PM, Michael Niedermayer  wrote:
> > From: Michael Niedermayer 
> >
> > The "loop" option is used in several demuxers (like img2dec) and muxers, 
> > using the same name in ffmpeg_opt
> > breaks them. Feel free to revert this and replace by any other solution or 
> > rename both as preferred
> > This is just as a quick fix to avoid the regression with existing command 
> > lines and to have both named
> > the same (which does not work)
> 
> quick alternative (based on help text) - stream_loop in ffmpeg_opt?

ok, renamed and applied

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

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


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

Re: [FFmpeg-devel] avfilter_graph Question

[Grady Player]

Figured it out, sharing (if anyone were to care)…

I was using 
 av_buffersrc_add_frame
rather than: 
 av_buffersrc_write_frame

which informs the buffer to retain an internal reference to the original 
picture/frame..

-Grady


On Oct 14, 2015, at 11:50 AM, Grady Player 
 wrote:

> Yes, sorry this was omitted  - after I am done I call:
>  
> av_frame_free();
> 
> it seems to be something that is internally referenced by the graph...
> 
> 
> On Oct 14, 2015, at 10:50 AM, Paul B Mahol  wrote:
> 
>> Dana 14. 10. 2015. 17:36 osoba "Grady Player" <
>> grady.pla...@verizondigitalmedia.com> napisala je:
>>> 
>>> Currently using:
>>> 
>>> commit af5917698bd44f136fd0ff00a9e5f8b5f92f2d58
>>> Author: Michael Niedermayer 
>>> Date:   Sun May 17 01:34:35 2015 +0200
>>> 
>>> I am trying to set up a small filter graph in order to use the YADIF
>> implementation in libavfilter...
>>> 
>>> I have set up an avfilter_graph with 3 filters…
>>> 
>>>avfilter_register_all();
>>>avfGraph = avfilter_graph_alloc();
>>> 
>>>AVFilter * bufferFilter, * yadifFilter, * bufferSink;
>>> 
>>>bufferFilter = avfilter_get_by_name("buffer");
>>>yadifFilter = avfilter_get_by_name("yadif");
>>>bufferSink = avfilter_get_by_name("buffersink”);
>>> 
>>>  /* dynamic configuration here */
>>> 
>>>avfilter_graph_create_filter(/*done for each filter */);
>>> 
>>>if (err >= 0) err = avfilter_link(buffer_ctx, 0, yadif_ctx, 0);
>>>if (err >= 0) err = avfilter_link(yadif_ctx, 0, sink_ctx, 0);
>>> 
>>>if (err>=0) err = avfilter_graph_config(avfGraph, NULL);
>>> 
>>> 
>>> Then I feed frames into the graph with:
>>> 
>>>err = av_buffersrc_add_frame(buffer_ctx, avf);
>>> 
>>> and pull frames out of the graph with:
>>> 
>>>  AVFrame * oframe = av_frame_alloc();
>>>  err = av_buffersink_get_frame(sink_ctx, oframe);
>>> 
>>> 
>>> this all seems to work pretty well, except it is holding on to a lot of
>> memory that is released in avfilter_graph_free()
>>> 
>>> I suspect it is something dumb, but is there something I need to be doing
>> to release internal references to some resource?
>>> 
>>> 
>>> 
>> 
>> Do you free frame you no longer need?
>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

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

Re: [FFmpeg-devel] [PATCH] winrt: multithreading support

[Michael Niedermayer]

On Thu, Oct 15, 2015 at 02:46:21AM +0800, Wang Bin wrote:
> 

>  compat/w32pthreads.h |5 +
>  configure|7 +++
>  libavutil/cpu.c  |8 +++-
>  3 files changed, 19 insertions(+), 1 deletion(-)
> 252925c34c8d2b6f09ce0fd40c2923494b005a7a  
> 0001-winrt-multithreading-support.patch
> From bdf361eaaa0696e25680e5403ff7516869068587 Mon Sep 17 00:00:00 2001
> From: wang-bin 
> Date: Tue, 29 Sep 2015 18:11:03 +0800
> Subject: [PATCH] winrt: multithreading support
> 
> _beginthreadex is for desktop only. CreateThread is available for windows 
> store apps on windows (and phone) 8.1 and later. 
> http://msdn.microsoft.com/en-us/library/ms682453%28VS.85%29.aspx
> ---
>  compat/w32pthreads.h | 5 +
>  configure| 7 +++
>  libavutil/cpu.c  | 8 +++-
>  3 files changed, 19 insertions(+), 1 deletion(-)

works (build+fate) with the 2 mingw versions i have here

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

Re: [FFmpeg-devel] avfilter_graph Question

[Grady Player]

the doxygen, docs dont really point to any difference… (the prototype for 
av_buffersrc_add_frame doesn’t match my header, not sure if that is a version 
issue)

int av_buffersrc_write_frame(   AVFilterContext *   s, const 
AVFrame *  frame)  
Add a frame to the buffer source.

int av_buffersrc_add_frame (AVFilterContext *buffer_src, const AVFrame 
*frame, int flags)
Add frame data to buffer_src. 


On Oct 14, 2015, at 2:15 PM, Ganesh Ajjanagadde  wrote:

> On Wed, Oct 14, 2015 at 4:13 PM, Grady Player
>  wrote:
>> Figured it out, sharing (if anyone were to care)…
>> 
>> I was using
>> av_buffersrc_add_frame
>> rather than:
>> av_buffersrc_write_frame
>> 
>> which informs the buffer to retain an internal reference to the original 
>> picture/frame..
> 
> Was the documentation confusing? Any suggestions for improving the docs?
> 
>> 
>> -Grady
>> 
>> 
>> On Oct 14, 2015, at 11:50 AM, Grady Player 
>>  wrote:
>> 
>>> Yes, sorry this was omitted  - after I am done I call:
>>> 
>>> av_frame_free();
>>> 
>>> it seems to be something that is internally referenced by the graph...
>>> 
>>> 
>>> On Oct 14, 2015, at 10:50 AM, Paul B Mahol  wrote:
>>> 
 Dana 14. 10. 2015. 17:36 osoba "Grady Player" <
 grady.pla...@verizondigitalmedia.com> napisala je:
> 
> Currently using:
> 
> commit af5917698bd44f136fd0ff00a9e5f8b5f92f2d58
> Author: Michael Niedermayer 
> Date:   Sun May 17 01:34:35 2015 +0200
> 
> I am trying to set up a small filter graph in order to use the YADIF
 implementation in libavfilter...
> 
> I have set up an avfilter_graph with 3 filters…
> 
>   avfilter_register_all();
>   avfGraph = avfilter_graph_alloc();
> 
>   AVFilter * bufferFilter, * yadifFilter, * bufferSink;
> 
>   bufferFilter = avfilter_get_by_name("buffer");
>   yadifFilter = avfilter_get_by_name("yadif");
>   bufferSink = avfilter_get_by_name("buffersink”);
> 
> /* dynamic configuration here */
> 
>   avfilter_graph_create_filter(/*done for each filter */);
> 
>   if (err >= 0) err = avfilter_link(buffer_ctx, 0, yadif_ctx, 0);
>   if (err >= 0) err = avfilter_link(yadif_ctx, 0, sink_ctx, 0);
> 
>   if (err>=0) err = avfilter_graph_config(avfGraph, NULL);
> 
> 
> Then I feed frames into the graph with:
> 
>   err = av_buffersrc_add_frame(buffer_ctx, avf);
> 
> and pull frames out of the graph with:
> 
> AVFrame * oframe = av_frame_alloc();
> err = av_buffersink_get_frame(sink_ctx, oframe);
> 
> 
> this all seems to work pretty well, except it is holding on to a lot of
 memory that is released in avfilter_graph_free()
> 
> I suspect it is something dumb, but is there something I need to be doing
 to release internal references to some resource?
> 
> 
> 
 
 Do you free frame you no longer need?
 ___
> 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 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] w32pthreads: fix mingw build on x86 with -msse2 or higher

[Hendrik Leppkes]

When SSE2 or higher compiler optimizations are used, mingw uses
the _mm_mfence intrinsic for MemoryBarrier, however it doesn't include
the appropriate headers automatically.
---
 compat/w32pthreads.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
index 2aff72a..6b602c5 100644
--- a/compat/w32pthreads.h
+++ b/compat/w32pthreads.h
@@ -39,6 +39,11 @@
 #include 
 #include 
 
+/* MinGW requires the intrinsics header for the pthread_once fallback code */
+#if _WIN32_WINNT < 0x0600 && defined(__MINGW32__)
+#include 
+#endif
+
 #include "libavutil/attributes.h"
 #include "libavutil/common.h"
 #include "libavutil/internal.h"
-- 
2.5.3.windows.1

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

Re: [FFmpeg-devel] [PATCH 1/4] opencl: Print error string when compilation fails

[Michael Niedermayer]

On Tue, Oct 13, 2015 at 09:48:35PM -0700, Timothy Gu wrote:
> ---
>  libavutil/opencl.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

LGTM

thanks

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

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


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

Re: [FFmpeg-devel] [PATCH 1/2] vp9: split header into separate struct and expose in vp9.h

[Hendrik Leppkes]

On Wed, Oct 14, 2015 at 10:16 AM, Hendrik Leppkes  wrote:
> From: "Ronald S. Bultje" 
>
> This allows hwaccels to access the bitstream header information.
> ---
>  libavcodec/vp9.c | 717 
> +++
>  libavcodec/vp9.h | 114 +++
>  libavcodec/vp9_mc_template.c |   4 +-
>  libavcodec/vp9data.h |  14 -
>  4 files changed, 436 insertions(+), 413 deletions(-)
>

Set OK'ed by Ronald on IRC, will push tomorrow if no-one objects.

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

[FFmpeg-devel] [PATCH 3/4] avformat: add vag demuxer

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavformat/Makefile |  1 +
 libavformat/allformats.c |  1 +
 libavformat/vag.c| 83 
 3 files changed, 85 insertions(+)
 create mode 100644 libavformat/vag.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index a66bd17..9f477ac 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -441,6 +441,7 @@ OBJS-$(CONFIG_TTA_DEMUXER)   += tta.o apetag.o 
img2.o
 OBJS-$(CONFIG_TTY_DEMUXER)   += tty.o sauce.o
 OBJS-$(CONFIG_TXD_DEMUXER)   += txd.o
 OBJS-$(CONFIG_UNCODEDFRAMECRC_MUXER) += uncodedframecrcenc.o framehash.o
+OBJS-$(CONFIG_VAG_DEMUXER)   += vag.o
 OBJS-$(CONFIG_VC1_DEMUXER)   += rawdec.o
 OBJS-$(CONFIG_VC1_MUXER) += rawenc.o
 OBJS-$(CONFIG_VC1T_DEMUXER)  += vc1test.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index dbd7719..f358b96 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -308,6 +308,7 @@ void av_register_all(void)
 REGISTER_DEMUXER (TXD,  txd);
 REGISTER_DEMUXER (TTY,  tty);
 REGISTER_MUXER   (UNCODEDFRAMECRC,  uncodedframecrc);
+REGISTER_DEMUXER (VAG,  vag);
 REGISTER_MUXDEMUX(VC1,  vc1);
 REGISTER_MUXDEMUX(VC1T, vc1t);
 REGISTER_DEMUXER (VIVO, vivo);
diff --git a/libavformat/vag.c b/libavformat/vag.c
new file mode 100644
index 000..ade5913
--- /dev/null
+++ b/libavformat/vag.c
@@ -0,0 +1,83 @@
+/*
+ * VAG demuxer
+ * Copyright (c) 2015 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/channel_layout.h"
+#include "avformat.h"
+#include "internal.h"
+
+typedef struct VAGDemuxContext {
+int64_t data_end;
+} VAGDemuxContext;
+
+static int vag_probe(AVProbeData *p)
+{
+if (memcmp(p->buf, "VAGp\0\0\0\x20", 7))
+return 0;
+
+return AVPROBE_SCORE_MAX;
+}
+
+static int vag_read_header(AVFormatContext *s)
+{
+VAGDemuxContext *c = s->priv_data;
+AVStream *st;
+
+st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+
+avio_skip(s->pb, 4);
+st->codec->codec_type  = AVMEDIA_TYPE_AUDIO;
+st->codec->codec_id= AV_CODEC_ID_ADPCM_PSX;
+st->codec->channels= 1 + (avio_rb32(s->pb) == 0x0004);
+avio_skip(s->pb, 4);
+c->data_end= avio_rb32(s->pb);
+st->duration   = (c->data_end - avio_tell(s->pb)) / (16 * 
st->codec->channels) * 28;
+st->codec->sample_rate = avio_rb32(s->pb);
+if (st->codec->sample_rate <= 0)
+return AVERROR_INVALIDDATA;
+avio_skip(s->pb, 28);
+avpriv_set_pts_info(st, 64, 1, st->codec->sample_rate);
+
+return 0;
+}
+
+static int vag_read_packet(AVFormatContext *s, AVPacket *pkt)
+{
+VAGDemuxContext *c = s->priv_data;
+int size;
+
+size = FFMIN(c->data_end - avio_tell(s->pb), 1024);
+if (size <= 0)
+return AVERROR_EOF;
+
+return av_get_packet(s->pb, pkt, size);
+}
+
+AVInputFormat ff_vag_demuxer = {
+.name   = "vag",
+.long_name  = NULL_IF_CONFIG_SMALL("Sony VAG"),
+.priv_data_size = sizeof(VAGDemuxContext),
+.read_probe = vag_probe,
+.read_header= vag_read_header,
+.read_packet= vag_read_packet,
+.extensions = "vag",
+};
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] ffmpeg_opt: rename loop option to loop2

[Carl Eugen Hoyos]

Michael Niedermayer  niedermayer.cc> writes:

> > quick alternative (based on help text) - stream_loop in ffmpeg_opt?
> 
> ok, renamed and applied

Thank you both!

Carl Eugen

___
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

[Alexis Ballier]

On Wed, 14 Oct 2015 12:08:58 -0600
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).

You might want to try good old qtrle: rle is good for repeated pixels,
and qtrle has the ability to code "following N pixels come from previous
frame", which makes it good for screen capture. Not sure how it
compares these days, but 10 years ago it was still one of the best
options for screen capture iirc, esp. with low color depth (8 or 16bits
per pixel).

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

[FFmpeg-devel] [PATCH 2/4] avformat: add genh demuxer

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/genh.c   | 176 +++
 3 files changed, 178 insertions(+)
 create mode 100644 libavformat/genh.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 2971912..a66bd17 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -177,6 +177,7 @@ OBJS-$(CONFIG_G722_MUXER)+= rawenc.o
 OBJS-$(CONFIG_G723_1_DEMUXER)+= g723_1.o
 OBJS-$(CONFIG_G723_1_MUXER)  += rawenc.o
 OBJS-$(CONFIG_G729_DEMUXER)  += g729dec.o
+OBJS-$(CONFIG_GENH_DEMUXER)  += genh.o
 OBJS-$(CONFIG_H261_DEMUXER)  += h261dec.o rawdec.o
 OBJS-$(CONFIG_H261_MUXER)+= rawenc.o
 OBJS-$(CONFIG_H263_DEMUXER)  += h263dec.o rawdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0ccde9d..dbd7719 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -138,6 +138,7 @@ void av_register_all(void)
 REGISTER_MUXDEMUX(G722, g722);
 REGISTER_MUXDEMUX(G723_1,   g723_1);
 REGISTER_DEMUXER (G729, g729);
+REGISTER_DEMUXER (GENH, genh);
 REGISTER_MUXDEMUX(GIF,  gif);
 REGISTER_DEMUXER (GSM,  gsm);
 REGISTER_MUXDEMUX(GXF,  gxf);
diff --git a/libavformat/genh.c b/libavformat/genh.c
new file mode 100644
index 000..ce054b5
--- /dev/null
+++ b/libavformat/genh.c
@@ -0,0 +1,176 @@
+/*
+ * GENH demuxer
+ * Copyright (c) 2015 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/intreadwrite.h"
+#include "avformat.h"
+#include "internal.h"
+
+typedef struct GENHDemuxContext {
+unsigned dsp_int_type;
+unsigned interleave_size;
+} GENHDemuxContext;
+
+static int genh_probe(AVProbeData *p)
+{
+if (AV_RL32(p->buf) != MKTAG('G','E','N','H'))
+return 0;
+
+return AVPROBE_SCORE_MAX / 3 * 2;
+}
+
+static int genh_read_header(AVFormatContext *s)
+{
+unsigned start_offset, header_size, codec, coef_type, coef[2];
+GENHDemuxContext *c = s->priv_data;
+unsigned coef_splitted[2];
+int align, ch;
+AVStream *st;
+
+avio_skip(s->pb, 4);
+
+st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+
+st->codec->codec_type  = AVMEDIA_TYPE_AUDIO;
+st->codec->channels= avio_rl32(s->pb);
+if (st->codec->channels <= 0)
+return AVERROR_INVALIDDATA;
+if (st->codec->channels == 1)
+st->codec->channel_layout = AV_CH_LAYOUT_MONO;
+else if (st->codec->channels == 2)
+st->codec->channel_layout = AV_CH_LAYOUT_STEREO;
+align  =
+c->interleave_size = avio_rl32(s->pb);
+if (align < 0 || align > INT_MAX / st->codec->channels)
+return AVERROR_INVALIDDATA;
+st->codec->block_align = align * st->codec->channels;
+st->codec->sample_rate = avio_rl32(s->pb);
+avio_skip(s->pb, 4);
+st->duration = avio_rl32(s->pb);
+
+codec = avio_rl32(s->pb);
+switch (codec) {
+case  1:
+case 11: st->codec->bits_per_coded_sample = 4;
+ st->codec->codec_id = AV_CODEC_ID_ADPCM_IMA_WAV;break;
+case  3: st->codec->codec_id = st->codec->block_align > 0 ?
+   AV_CODEC_ID_PCM_S16BE_PLANAR :
+   AV_CODEC_ID_PCM_S16BE;break;
+case  4: st->codec->codec_id = st->codec->block_align > 0 ?
+   AV_CODEC_ID_PCM_S16LE_PLANAR :
+   AV_CODEC_ID_PCM_S16LE;break;
+case  5: st->codec->codec_id = st->codec->block_align > 0 ?
+   AV_CODEC_ID_PCM_S8_PLANAR :
+   AV_CODEC_ID_PCM_S8;   break;
+case 12: st->codec->codec_id = AV_CODEC_ID_ADPCM_THP;break;
+case 13: st->codec->codec_id = AV_CODEC_ID_PCM_U8;   break;
+default:
+ avpriv_request_sample(s, "codec %d", codec);
+ return AVERROR_PATCHWELCOME;
+}
+
+start_offset = avio_rl32(s->pb);
+header_size  = avio_rl32(s->pb);
+
+if 

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

[Paul B Mahol]

Dana 14. 10. 2015. 18:50 osoba "Nicolas George"  napisala
je:
>
> Le tridi 23 vendémiaire, an CCXXIV, Paul B Mahol a écrit :
> > This changes pts but framerate remains same.
>
> Care to ellaborate?

Timebase and stream framerate are same.

>
> 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 1/4] avcodec: add ADPCM PSX decoder

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/Makefile |  1 +
 libavcodec/adpcm.c  | 40 
 libavcodec/allcodecs.c  |  1 +
 libavcodec/avcodec.h|  1 +
 libavcodec/codec_desc.c |  7 +++
 libavcodec/utils.c  |  1 +
 6 files changed, 51 insertions(+)

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 8f7493e..1e1e479 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -687,6 +687,7 @@ OBJS-$(CONFIG_ADPCM_IMA_WAV_ENCODER)  += adpcmenc.o 
adpcm_data.o
 OBJS-$(CONFIG_ADPCM_IMA_WS_DECODER)   += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_MS_DECODER)   += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_MS_ENCODER)   += adpcmenc.o adpcm_data.o
+OBJS-$(CONFIG_ADPCM_PSX_DECODER)  += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_SBPRO_2_DECODER)  += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_SBPRO_3_DECODER)  += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_SBPRO_4_DECODER)  += adpcm.o adpcm_data.o
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index ba38041..11eb974 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -152,6 +152,7 @@ static av_cold int adpcm_decode_init(AVCodecContext * avctx)
 case AV_CODEC_ID_ADPCM_THP_LE:
 case AV_CODEC_ID_ADPCM_AFC:
 case AV_CODEC_ID_ADPCM_DTK:
+case AV_CODEC_ID_ADPCM_PSX:
 avctx->sample_fmt = AV_SAMPLE_FMT_S16P;
 break;
 case AV_CODEC_ID_ADPCM_IMA_WS:
@@ -665,6 +666,7 @@ static int get_nb_samples(AVCodecContext *avctx, 
GetByteContext *gb,
 nb_samples = (buf_size / 128) * 224 / ch;
 break;
 case AV_CODEC_ID_ADPCM_DTK:
+case AV_CODEC_ID_ADPCM_PSX:
 nb_samples = buf_size / (16 * ch) * 28;
 break;
 }
@@ -1548,6 +1550,43 @@ static int adpcm_decode_frame(AVCodecContext *avctx, 
void *data,
 bytestream2_seek(, 0, SEEK_SET);
 }
 break;
+case AV_CODEC_ID_ADPCM_PSX:
+for (channel = 0; channel < avctx->channels; channel++) {
+samples = samples_p[channel];
+
+/* Read in every sample for this channel.  */
+for (i = 0; i < nb_samples / 28; i++) {
+int filter, shift, flag, byte;
+
+filter = bytestream2_get_byteu();
+shift  = filter & 0xf;
+filter = filter >> 4;
+if (filter >= FF_ARRAY_ELEMS(xa_adpcm_table))
+return AVERROR_INVALIDDATA;
+flag   = bytestream2_get_byteu();
+
+/* Decode 28 samples.  */
+for (n = 0; n < 28; n++) {
+int sample = 0, scale;
+
+if (flag < 0x07) {
+if (n & 1) {
+scale = sign_extend(byte >> 4, 4);
+} else {
+byte  = bytestream2_get_byteu();
+scale = sign_extend(byte, 4);
+}
+
+scale  = scale << 12;
+sample = (int)((scale >> shift) + 
(c->status[channel].sample1 * xa_adpcm_table[filter][0] + 
c->status[channel].sample2 * xa_adpcm_table[filter][1]) / 64);
+}
+*samples++ = av_clip_int16(sample);
+c->status[channel].sample2 = c->status[channel].sample1;
+c->status[channel].sample1 = sample;
+}
+}
+}
+break;
 
 default:
 return -1;
@@ -1622,6 +1661,7 @@ ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_SMJPEG,  
sample_fmts_s16,  adpcm_ima_smjpeg,
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_WAV, sample_fmts_s16p, adpcm_ima_wav,  
   "ADPCM IMA WAV");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_WS,  sample_fmts_both, adpcm_ima_ws,   
   "ADPCM IMA Westwood");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_MS,  sample_fmts_s16,  adpcm_ms,   
   "ADPCM Microsoft");
+ADPCM_DECODER(AV_CODEC_ID_ADPCM_PSX, sample_fmts_s16p, adpcm_psx,  
   "ADPCM PSX");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_SBPRO_2, sample_fmts_s16,  adpcm_sbpro_2,  
   "ADPCM Sound Blaster Pro 2-bit");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_SBPRO_3, sample_fmts_s16,  adpcm_sbpro_3,  
   "ADPCM Sound Blaster Pro 2.6-bit");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_SBPRO_4, sample_fmts_s16,  adpcm_sbpro_4,  
   "ADPCM Sound Blaster Pro 4-bit");
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b506463..d62bec7 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -509,6 +509,7 @@ void avcodec_register_all(void)
 REGISTER_ENCDEC (ADPCM_IMA_WAV, adpcm_ima_wav);
 REGISTER_DECODER(ADPCM_IMA_WS,  adpcm_ima_ws);
 REGISTER_ENCDEC (ADPCM_MS,  adpcm_ms);
+REGISTER_DECODER(ADPCM_PSX, adpcm_psx);
 REGISTER_DECODER(ADPCM_SBPRO_2, adpcm_sbpro_2);
 REGISTER_DECODER(ADPCM_SBPRO_3, adpcm_sbpro_3);
 

Re: [FFmpeg-devel] [PATCH 2/4] avformat: add genh demuxer

[Paul B Mahol]

Dana 14. 10. 2015. 23:57 osoba "Carl Eugen Hoyos" 
napisala je:
>
> Hi!
>
> Paul B Mahol  gmail.com> writes:
>
> > +   case  1:
> > +   case 11: st->codec->bits_per_coded_sample = 4;
> > +st->codec->codec_id = AV_CODEC_ID_ADPCM_IMA_WAV;
>
> > +   case  3: st->codec->codec_id = st->codec->block_align > 0 ?
> > +  AV_CODEC_ID_PCM_S16BE_PLANAR :
> > +  AV_CODEC_ID_PCM_S16BE;
>
> > +   case  4: st->codec->codec_id = st->codec->block_align > 0 ?
> > +  AV_CODEC_ID_PCM_S16LE_PLANAR :
> > +  AV_CODEC_ID_PCM_S16LE;
>
> > +   case  5: st->codec->codec_id = st->codec->block_align > 0 ?
> > +  AV_CODEC_ID_PCM_S8_PLANAR :
> > +  AV_CODEC_ID_PCM_S8;
>
> > +   case 12: st->codec->codec_id = AV_CODEC_ID_ADPCM_THP;
>
> > +   case 13: st->codec->codec_id = AV_CODEC_ID_PCM_U8;
>
> I wonder if you shouldn't copy all codecs
> from the white page (or xbmc code) no matter
> if tested or not.
>
> There is for example a genh.c file in
> xbmc/cores/paplayer/vgmstream/src/meta (found with Google).

Hmm, will do, the ones we actually have decoders.

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

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

[Nicolas George]

Le quartidi 24 vendémiaire, an CCXXIV, Paul B Mahol a écrit :
> Timebase and stream framerate are same.

Not at all. For Matroska, timebase is usually 1/1000; for MPEG-[PT]S,
timebase is 1/9; timebase can also be set using settb.

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, swresample, swscale: use fabs, fabsf instead of FFABS

[Ganesh Ajjanagadde]

On Wed, Oct 14, 2015 at 2:40 AM, Carl Eugen Hoyos  wrote:
> Ganesh Ajjanagadde  mit.edu> writes:
>
>> >> I think the general case, it'd be nice to figure out
>> >> why Carl's results are slightly different from yours
>> >
>> > Why do you think they are different at all?
>> > Did you look at the tables?
>>
>> They are different, and our conclusions are different
>> (in a slight way). Carl claims that the old code and
>> new code are mostly the same in speed, but in the
>> cases where they differ, the old code is faster.
>
> No.
>
> I wrote that both the numbers you posted and the numbers
> I posted show no proof that the new code is faster.

You posted a first reply with all manner of stuff saying essentially
that "I believe the old code may be faster". You have not withdrawn
that claim, and neither have I withdrawn mine.

> (Contrary to my numbers, your numbers show that the old
> code may be faster but that is irrelevant.)

What? My numbers actually show that the new code may be faster -
again: cycle times in the best case are identical, in the worst case
they favor the new code. My random number benchmark is also clearly in
favor of the new code. How this is "irrelevant" is beyond me. Also,
please don't spin my numbers into something they are not: this is
distracting the thread. Clement and Paul have already started moving
to using the function, others are free to see the numbers themselves.
Why you are trying to derail the benchmarks I posted is beyond me.

If you continue to post such stuff that has no basis, I might actually
get tempted into finding out for which floating point values the new
code is significantly faster, craft a relevant audio file, and post it
showing a huge performance difference - my random numbers benchmark
shows there must exist such values.

>
> The more important question is if you can see the same
> changes in the disassembly of af_astats.o as what
> ubitux posted here for a short test function?

I do. He uses clang/gcc, so do I. The reason (irrelevant) is that both
of us run Arch.

What is "more relevant" is if _you_ can see the changes on some non
Linux platform.

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

Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter

[Carl Eugen Hoyos]

On Wednesday 14 October 2015 10:07:04 am Sven Dueking wrote:
> Hi all,
>
> The attached patches adds the VPP as filter module to FFMpeg.
> Looking forward to get feedback.

Just a few comments, I expect you will get a comment explaining 
what you can't do;-)
(Sorry for the partly broken quotation.)

In any case, please merge both patches, they are not independent.

>
> Many thanks,
> Sven

> From d09cff6d868bd2a0fd87e3906f8808638809494b Mon Sep 17 00:00:00 2001
> From: Sven Dueking 
> Date: Wed, 14 Oct 2015 08:13:38 +0100
> Subject: [PATCH 1/2] added QSV based VPP filter
>
> ---
>  libavfilter/vf_qsv_vpp.c | 686
> +++ 1 file changed, 686
> insertions(+)
>  create mode 100644 libavfilter/vf_qsv_vpp.c
>
> diff --git a/libavfilter/vf_qsv_vpp.c b/libavfilter/vf_qsv_vpp.c
> new file mode 100644
> index 000..629913e
> --- /dev/null
> +++ b/libavfilter/vf_qsv_vpp.c
> @@ -0,0 +1,686 @@
> +/*
> + * Intel MediaSDK Quick Sync Video VPP filter
> + *
> + * copyright (c) 2015 Sven Dueking
> + *
> + * This file is part of FFmpeg.
> + *
> + * Libav 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.
> + *
> + * Libav 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 Libav; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA + */
> +
> +#include 
> +#include 
> +
> +#include "avfilter.h"
> +#include "internal.h"
> +#include "formats.h"
> +
> +#include "libavutil/avassert.h"
> +#include "libavutil/opt.h"
> +#include "libavutil/time.h"
> +#include "libavutil/avstring.h"
> +#include "libavutil/error.h"
> +#include "libavcodec/avcodec.h"
> +#include "libavcodec/qsv_internal.h"
> +
> +#include 
> +
> +#include "avfilter.h"
> +#include "formats.h"
> +#include "internal.h"
> +#include "video.h"
> +#include "libavutil/eval.h"
> +#include "libavutil/avstring.h"
> +#include "libavutil/internal.h"
> +#include "libavutil/libm.h"
> +#include "libavutil/imgutils.h"
> +#include "libavutil/mathematics.h"
> +#include "libavutil/opt.h"
> +#include "libavutil/pixfmt.h"

Are they all necessary?

> +
> +/**
> + * ToDo :
> + *
> + * - handle empty extbuffers
> + * - cropping
> + * - allocate number of surfaces depending modules and number of b frames
> + */
> +
> +#define VPP_ZERO_MEMORY(VAR){ memset(, 0, sizeof(VAR)); }

I don't think this is more readable, but that may only be me.

> +#define VPP_ALIGN16(value)  (((value + 15) >> 4) << 4)  //
> round up to a multiple of 16 +#define VPP_ALIGN32(value)  (((value
> + 31) >> 5) << 5)  // round up to a multiple of 32 +#define

Isn't this FFALIGN()?

> VPP_CHECK_POINTER(P, ...)   {if (!(P)) {return __VA_ARGS__;}} +
> +// number of video enhancement filters (denoise, procamp, detail,
> video_analysis, image stab) +#define ENH_FILTERS_COUNT   5
> +
> +typedef struct {
> +const AVClass *class;
> +
> +AVFilterContext *ctx;
> +
> +mfxSession session;
> +QSVSession internal_qs;
> +
> +AVRational framerate;   // target framerate
> +
> +mfxFrameSurface1 **in_surface;
> +mfxFrameSurface1 **out_surface;
> +
> +mfxFrameAllocRequest req[2];// [0] - in, [1] - out
> +
> +int num_surfaces_in;// input surfaces
> +int num_surfaces_out;   // output surfaces
> +
> +unsigned char * surface_buffers_out;// output surface
> buffer +
> +char *load_plugins;
> +
> +mfxVideoParam* pVppParam;
> +
> +int cur_out_idx;
> +
> +/* VPP extension */
> +mfxExtBuffer* pExtBuf[1+ENH_FILTERS_COUNT];
> +mfxExtVppAuxData extVPPAuxData;
> +
> +/* Video Enhancement Algorithms */
> +mfxExtVPPDeinterlacing deinterlace_conf;
> +mfxExtVPPFrameRateConversion frc_conf;
> +mfxExtVPPDenoise denoise_conf;
> +mfxExtVPPDetail detail_conf;
> +
> +int out_width;
> +int out_height;
> +
> +int dpic;   // destination picture structure
> +// -1 = unknown
> +// 0 = interlaced top field first
> +// 1 = progressive
> +// 2 = interlaced bottom field first
> +
> +int deinterlace;// deinterlace mode : 0=off, 1=bob,
> 2=advanced +int denoise;// enable denoise algorithm.
> Level is the optional value from the 

Re: [FFmpeg-devel] configure: Require libkvazaar < 0.7

[Arttu Ylä-Outinen]

On 2015-10-14 13:19, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch for release/2.8 is supposed to fix ticket #4925, completely
> untested.
> 
> Please comment, Carl Eugen

> +enabled libkvazaar&& require_pkg_config "kvazaar < 0.7.0" kvazaar 
> kvazaar.h kvz_api_get

There is an extra "kvazaar" between 0.7.0 and kvazaar.h. It should be

enabled libkvazaar && require_pkg_config "kvazaar < 0.7.0" kvazaar.h 
kvz_api_get

instead. With that change, the patch seems to fix the problem in #4925.

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

Re: [FFmpeg-devel] [PATCH] avfilter, swresample, swscale: use fabs, fabsf instead of FFABS

[Ganesh Ajjanagadde]

On Wed, Oct 14, 2015 at 5:01 AM, Matt Oliver  wrote:
> On 14 October 2015 at 09:46, Ganesh Ajjanagadde  wrote:
>
>> On Tue, Oct 13, 2015 at 9:12 AM, Ganesh Ajjanagadde 
>> wrote:
>> > On Tue, Oct 13, 2015 at 4:02 AM, Clément Bœsch  wrote:
>> >> On Tue, Oct 13, 2015 at 09:25:03AM +0200, Paul B Mahol wrote:
>> >> [...]
>> >>> What about fmax/FFMAX?
>> >>
>> >> Feel free to try that out (it looks OT regarding the patch), but fmax()
>> >> looks glibc specific
>>
>> Seems they are actually ISO:
>> http://en.cppreference.com/w/c/numeric/math/fmax
>>
>> Can someone check availability on all of our platforms of interest
>> (e.g Microsoft)?
>>
>
> fmax and fmin are only available on msvc using 2013 or newer. Currently the
> only msvc version without fmax/fmin that FFmpeg supports is 2012 which uses
> the C99 to C89 converter.

And does that converter handle fmin, fmax, fmaxf, etc?
Does it need patches?
Bottom line: are they safe to use at the moment?

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

Re: [FFmpeg-devel] [PATCH] avfilter, swresample, swscale: use fabs, fabsf instead of FFABS

[Hendrik Leppkes]

On Wed, Oct 14, 2015 at 12:37 PM, Ganesh Ajjanagadde  wrote:
> On Wed, Oct 14, 2015 at 5:01 AM, Matt Oliver  wrote:
>> On 14 October 2015 at 09:46, Ganesh Ajjanagadde  wrote:
>>
>>> On Tue, Oct 13, 2015 at 9:12 AM, Ganesh Ajjanagadde 
>>> wrote:
>>> > On Tue, Oct 13, 2015 at 4:02 AM, Clément Bœsch  wrote:
>>> >> On Tue, Oct 13, 2015 at 09:25:03AM +0200, Paul B Mahol wrote:
>>> >> [...]
>>> >>> What about fmax/FFMAX?
>>> >>
>>> >> Feel free to try that out (it looks OT regarding the patch), but fmax()
>>> >> looks glibc specific
>>>
>>> Seems they are actually ISO:
>>> http://en.cppreference.com/w/c/numeric/math/fmax
>>>
>>> Can someone check availability on all of our platforms of interest
>>> (e.g Microsoft)?
>>>
>>
>> fmax and fmin are only available on msvc using 2013 or newer. Currently the
>> only msvc version without fmax/fmin that FFmpeg supports is 2012 which uses
>> the C99 to C89 converter.
>
> And does that converter handle fmin, fmax, fmaxf, etc?
> Does it need patches?
> Bottom line: are they safe to use at the moment?
>

No, they are not.

One thing I don't understand - why are we bothering with something
that at best comes out as "same speed" from tests performed? (low
number of runs are irrelevant as they are not statistically
significant).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] configure: Require libkvazaar < 0.7

[Carl Eugen Hoyos]

Hi!

Attached patch for release/2.8 is supposed to fix ticket #4925, completely 
untested.

Please comment, Carl Eugen
diff --git a/configure b/configure
index b661157..c2b58e5 100755
--- a/configure
+++ b/configure
@@ -5240,7 +5240,7 @@ enabled libgsm&& { for gsm_hdr in "gsm.h" 
"gsm/gsm.h"; do
check_lib "${gsm_hdr}" gsm_create -lgsm && 
break;
done || die "ERROR: libgsm not found"; }
 enabled libilbc   && require libilbc ilbc.h WebRtcIlbcfix_InitDecode 
-lilbc
-enabled libkvazaar&& require_pkg_config kvazaar kvazaar.h kvz_api_get
+enabled libkvazaar&& require_pkg_config "kvazaar < 0.7.0" kvazaar 
kvazaar.h kvz_api_get
 enabled libmfx&& require_pkg_config libmfx "mfx/mfxvideo.h" MFXInit
 enabled libmodplug&& require_pkg_config libmodplug 
libmodplug/modplug.h ModPlug_Load
 enabled libmp3lame&& require "libmp3lame >= 3.98.3" lame/lame.h 
lame_set_VBR_quality -lmp3lame
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter, swresample, swscale: use fabs, fabsf instead of FFABS

[Carl Eugen Hoyos]

Ganesh Ajjanagadde  mit.edu> writes:

> What? My numbers actually show that the new code may be faster -

No, you are misunderstanding the numbers you posted.
(Or I misunderstand them but nobody said so yet.)

Highest runs are most relevant, skips have to be 
avoided (afaik).

[...]

> If you continue to post such stuff that has no basis, I might actually
> get tempted into finding out for which floating point values the new
> code is significantly faster, craft a relevant audio file, and post it
> showing a huge performance difference - my random numbers benchmark
> shows there must exist such values.

Please do so!

> > The more important question is if you can see the same
> > changes in the disassembly of af_astats.o as what
> > ubitux posted here for a short test function?
> 
> I do. He uses clang/gcc, so do I.

Sorry, my understanding fails here (I am not a native speaker):
You did look at the disassembly of af_astats.o and there is 
inlined code instead of a function call?

> The reason (irrelevant) is that both
> of us run Arch.
> 
> What is "more relevant" is if _you_ can see the changes 
> on some non Linux platform.

If you could show that it is faster on any platform 
I would already be happy!

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] fate: use PROGSSUF

[Michael Niedermayer]

On Wed, Oct 14, 2015 at 07:18:27PM +0200, Christophe Gisquet wrote:
> May require exporting in the shell var PROGSUF when invoking a
> shell script.
> ---
>  tests/Makefile   | 14 +-
>  tests/fate-run.sh| 38 +++---
>  tests/fate/ffprobe.mak   |  2 +-
>  tests/fate/filter-video.mak  |  4 ++--
>  tests/fate/probe.mak |  2 +-
>  tests/fate/vpx.mak   | 10 +-
>  tests/ffserver-regression.sh |  2 +-
>  tests/regression-funcs.sh|  4 ++--
>  8 files changed, 40 insertions(+), 36 deletions(-)

tested
works fine

should i apply this or wait ?

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

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


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

Re: [FFmpeg-devel] [PATCH] dnxhd: interleave AC levels and flags

[Michael Niedermayer]

On Wed, Oct 14, 2015 at 07:20:49PM +0200, Christophe Gisquet wrote:
> This allows more efficient access to the array as the level and flags
> are contiguous. Around 4% faster coefficient decoding.
> ---
> Not the cleanest, and may complicate adding new profiles. But DNxHR
> just got added, so it should be ok for some years.
> ---
>  libavcodec/dnxhddata.c | 492 
> ++---
>  libavcodec/dnxhddata.h |   3 +-
>  libavcodec/dnxhddec.c  |   7 +-
>  libavcodec/dnxhdenc.c  |   6 +-
>  4 files changed, 231 insertions(+), 277 deletions(-)

applied

thanks

[...]
-- 
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] avfilter_graph Question

[Ganesh Ajjanagadde]

On Wed, Oct 14, 2015 at 4:48 PM, Grady Player
 wrote:
> the doxygen, docs dont really point to any difference… (the prototype for 
> av_buffersrc_add_frame doesn’t match my header, not sure if that is a version 
> issue)

Must have been the av_warn_unused_result I added recently - no need to
worry about that: it is really for user's benefit so that they check
the return codes correctly (GCC should emit a -Wunused-result error
when the return code is not used/checked).

I will look into the docs soon: there is some difference, "add a
frame" and "add frame data" are IMO clearly different things. Any
concrete rewordings based on your experience are welcome.

>
> int av_buffersrc_write_frame(   AVFilterContext *   s, const 
> AVFrame *  frame)
> Add a frame to the buffer source.
>
> int av_buffersrc_add_frame (AVFilterContext *buffer_src, const AVFrame 
> *frame, int flags)
> Add frame data to buffer_src.
>
>
> On Oct 14, 2015, at 2:15 PM, Ganesh Ajjanagadde  wrote:
>
>> On Wed, Oct 14, 2015 at 4:13 PM, Grady Player
>>  wrote:
>>> Figured it out, sharing (if anyone were to care)…
>>>
>>> I was using
>>> av_buffersrc_add_frame
>>> rather than:
>>> av_buffersrc_write_frame
>>>
>>> which informs the buffer to retain an internal reference to the original 
>>> picture/frame..
>>
>> Was the documentation confusing? Any suggestions for improving the docs?
>>
>>>
>>> -Grady
>>>
>>>
>>> On Oct 14, 2015, at 11:50 AM, Grady Player 
>>>  wrote:
>>>
 Yes, sorry this was omitted  - after I am done I call:

 av_frame_free();

 it seems to be something that is internally referenced by the graph...


 On Oct 14, 2015, at 10:50 AM, Paul B Mahol  wrote:

> Dana 14. 10. 2015. 17:36 osoba "Grady Player" <
> grady.pla...@verizondigitalmedia.com> napisala je:
>>
>> Currently using:
>>
>> commit af5917698bd44f136fd0ff00a9e5f8b5f92f2d58
>> Author: Michael Niedermayer 
>> Date:   Sun May 17 01:34:35 2015 +0200
>>
>> I am trying to set up a small filter graph in order to use the YADIF
> implementation in libavfilter...
>>
>> I have set up an avfilter_graph with 3 filters…
>>
>>   avfilter_register_all();
>>   avfGraph = avfilter_graph_alloc();
>>
>>   AVFilter * bufferFilter, * yadifFilter, * bufferSink;
>>
>>   bufferFilter = avfilter_get_by_name("buffer");
>>   yadifFilter = avfilter_get_by_name("yadif");
>>   bufferSink = avfilter_get_by_name("buffersink”);
>>
>> /* dynamic configuration here */
>>
>>   avfilter_graph_create_filter(/*done for each filter */);
>>
>>   if (err >= 0) err = avfilter_link(buffer_ctx, 0, yadif_ctx, 0);
>>   if (err >= 0) err = avfilter_link(yadif_ctx, 0, sink_ctx, 0);
>>
>>   if (err>=0) err = avfilter_graph_config(avfGraph, NULL);
>>
>>
>> Then I feed frames into the graph with:
>>
>>   err = av_buffersrc_add_frame(buffer_ctx, avf);
>>
>> and pull frames out of the graph with:
>>
>> AVFrame * oframe = av_frame_alloc();
>> err = av_buffersink_get_frame(sink_ctx, oframe);
>>
>>
>> this all seems to work pretty well, except it is holding on to a lot of
> memory that is released in avfilter_graph_free()
>>
>> I suspect it is something dumb, but is there something I need to be doing
> to release internal references to some resource?
>>
>>
>>
>
> Do you free frame you no longer need?
> ___
>> 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 mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] lavf: Remove duplicated latm demuxer

[Carl Eugen Hoyos]

Carl Eugen Hoyos  ag.or.at> writes:

> I will commit tonight if there are no objections, Carl Eugen

Patch applied.

Thank you, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] fate: use PROGSSUF

[Michael Niedermayer]

On Thu, Oct 15, 2015 at 01:31:11AM +0200, Michael Niedermayer wrote:
> On Wed, Oct 14, 2015 at 07:18:27PM +0200, Christophe Gisquet wrote:
> > May require exporting in the shell var PROGSUF when invoking a
> > shell script.
> > ---
> >  tests/Makefile   | 14 +-
> >  tests/fate-run.sh| 38 +++---
> >  tests/fate/ffprobe.mak   |  2 +-
> >  tests/fate/filter-video.mak  |  4 ++--
> >  tests/fate/probe.mak |  2 +-
> >  tests/fate/vpx.mak   | 10 +-
> >  tests/ffserver-regression.sh |  2 +-
> >  tests/regression-funcs.sh|  4 ++--
> >  8 files changed, 40 insertions(+), 36 deletions(-)
> 
> tested
> works fine
> 
> should i apply this or wait ?

i will apply in 24-48h unless someone has objections / ideas to
improve it
actually i will likely forget and do it once someone reminds me ;)

[...]

-- 
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] [PATCH] avfilter/af_tremolo: clean up extra newlines

[Michael Niedermayer]

On Wed, Oct 14, 2015 at 09:56:48AM -0500, Kyle Swanson wrote:
> Signed-off-by: Kyle Swanson 
> ---
>  libavfilter/af_tremolo.c | 2 --
>  1 file changed, 2 deletions(-)

applied

thanks

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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

Re: [FFmpeg-devel] [PATCH 2/3] simple_idct12: align C and x86

[Michael Niedermayer]

On Wed, Oct 14, 2015 at 08:46:22AM +0200, Christophe Gisquet wrote:
> Hi,
> 
> 2015-10-14 0:04 GMT+02:00 Michael Niedermayer :
> > the ome and syserr values worsen by this
> 
> I have mixed feelings about this, too.
> 
> On the one hand, omse in any case says anyway none of those idcts are
> accurate enough to some sense (inter error propagation? / per the mpeg

yes, i doubt they would work for inter frames, at least not with
GOPs a hundread frames long

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

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


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

Re: [FFmpeg-devel] [PATCHv3 1/2] avfilter/all: propagate errors of functions from avfilter/formats

[Michael Niedermayer]

On Tue, Oct 13, 2015 at 08:33:33PM -0400, Ganesh Ajjanagadde wrote:
> Hi all,
> 
> Attached is a new version reflecting all freedback received so far.

builds and passes fate here
also small nitpick
libavfilter/vsrc_life.c: In function ‘query_formats’:
libavfilter/vsrc_life.c:420:9: warning: unused variable ‘ret’ 
[-Wunused-variable]

no objections from me (but i didnt review most of this patch)

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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

Re: [FFmpeg-devel] [PATCHv3 1/2] avfilter/all: propagate errors of functions from avfilter/formats

[Ganesh Ajjanagadde]

On Wed, Oct 14, 2015 at 7:47 AM, Michael Niedermayer
 wrote:
> On Tue, Oct 13, 2015 at 08:33:33PM -0400, Ganesh Ajjanagadde wrote:
>> Hi all,
>>
>> Attached is a new version reflecting all freedback received so far.
>
> builds and passes fate here
> also small nitpick
> libavfilter/vsrc_life.c: In function ‘query_formats’:
> libavfilter/vsrc_life.c:420:9: warning: unused variable ‘ret’ 
> [-Wunused-variable]
>
> no objections from me (but i didnt review most of this patch)

Will change and push later today. At worst, we will have a few issues
that need sorting out. At best, nothing needs to be done.
Thanks all for looking at this.

>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Dictatorship naturally arises out of democracy, and the most aggravated
> form of tyranny and slavery out of the most extreme liberty. -- Plato
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/intmath: use de Bruijn based ff_ctz

[Ronald S. Bultje]

Hi,

On Mon, Oct 12, 2015 at 7:14 AM, Ganesh Ajjanagadde 
wrote:

> On Mon, Oct 12, 2015 at 12:37 AM, James Almer  wrote:
> > On 10/11/2015 10:55 PM, Ganesh Ajjanagadde wrote:
> >> It has already been demonstrated that the de Bruijn method has benefits
> >> over the current implementation: commit
> 971d12b7f9d7be3ca8eb98e6c04ed521f83cbd3c.
> >> That commit implemented it for long long, this extends it to the 32 bit
> >> version.
> >>
> >> The function is renamed from ff_ctz to ff_ctz32 since it crucially
> >> depends on the 32 bit width of its argument. This is not an issue, as
> the
> >> only usage in avcodec/flacenc uses an int32_t anyway.
> >
> > I personally don't think the renaming is needed, for that matter. The
> > function takes an int as argument, and as far as ffmpeg supported arches
> > go those are 32 bits.
> > If you really want to be sure, just add a comment that the argument
> > absolutely needs to be 32 bits and that should be enough.
>
> This I don't understand. Why not make the function self documenting
> when we achieve it with zero penalty?


From what I can see, it's mostly a case of your patch doing two things:
- it renames the function
- it reimplements it
Where possible, we prefer patches that do exactly one thing. I'd
reimplement the function and have that go in as-is, and then renaming can
become the eternal bikeshed that it always becomes. See, these things
aren't technical in nature - unlike your reimplementation, which is simply
faster because it's a better algorithm. These things are just based on
personal preference, and so you'll never get a clean vote.

So, statistically speaking, if you want your patch to have the highest
chance of going in, make it do the minimal amount of change relative to
status quo, and make it do so in as little code change as possible. ;-).

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

Re: [FFmpeg-devel] [PATCH] avutil: install des.h, rc4.h and tree.h as public headers

[Michael Niedermayer]

On Wed, Oct 14, 2015 at 12:37:31AM +0200, Andreas Cadhalpun wrote:
> These headers contain functions supposed to be public.
> 
> libavutil/des.h:
>  av_des_alloc
>  av_des_crypt
>  av_des_init
>  av_des_mac
> libavutil/rc4.h:
>  av_rc4_alloc
>  av_rc4_crypt
>  av_rc4_init
> libavutil/tree.h
>  av_tree_destroy
>  av_tree_enumerate
>  av_tree_find
>  av_tree_insert
>  av_tree_node_alloc
>  av_tree_node_size

LGTM, but maybe you want to wait a day or 2 in case others have
comments

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

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


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

Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter

[Sven Dueking]

> -Ursprüngliche Nachricht-
> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
> von Carl Eugen Hoyos
> Gesendet: Mittwoch, 14. Oktober 2015 12:43
> An: FFmpeg development discussions and patches
> Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
> 
> On Wednesday 14 October 2015 10:07:04 am Sven Dueking wrote:
> > Hi all,
> >
> > The attached patches adds the VPP as filter module to FFMpeg.
> > Looking forward to get feedback.
> 
> Just a few comments, I expect you will get a comment explaining what
> you can't do;-) (Sorry for the partly broken quotation.)
> 
> In any case, please merge both patches, they are not independent.
> 
> >
> > Many thanks,
> > Sven
> 
> > From d09cff6d868bd2a0fd87e3906f8808638809494b Mon Sep 17 00:00:00
> 2001
> > From: Sven Dueking 
> > Date: Wed, 14 Oct 2015 08:13:38 +0100
> > Subject: [PATCH 1/2] added QSV based VPP filter
> >
> > ---
> >  libavfilter/vf_qsv_vpp.c | 686
> > +++ 1 file changed, 686
> > insertions(+)
> >  create mode 100644 libavfilter/vf_qsv_vpp.c
> >
> > diff --git a/libavfilter/vf_qsv_vpp.c b/libavfilter/vf_qsv_vpp.c new
> > file mode 100644 index 000..629913e
> > --- /dev/null
> > +++ b/libavfilter/vf_qsv_vpp.c
> > @@ -0,0 +1,686 @@
> > +/*
> > + * Intel MediaSDK Quick Sync Video VPP filter
> > + *
> > + * copyright (c) 2015 Sven Dueking
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * Libav 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.
> > + *
> > + * Libav 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 Libav; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > 02110-1301 USA + */
> > +
> > +#include 
> > +#include 
> > +
> > +#include "avfilter.h"
> > +#include "internal.h"
> > +#include "formats.h"
> > +
> > +#include "libavutil/avassert.h"
> > +#include "libavutil/opt.h"
> > +#include "libavutil/time.h"
> > +#include "libavutil/avstring.h"
> > +#include "libavutil/error.h"
> > +#include "libavcodec/avcodec.h"
> > +#include "libavcodec/qsv_internal.h"
> > +
> > +#include 
> > +
> > +#include "avfilter.h"
> > +#include "formats.h"
> > +#include "internal.h"
> > +#include "video.h"
> > +#include "libavutil/eval.h"
> > +#include "libavutil/avstring.h"
> > +#include "libavutil/internal.h"
> > +#include "libavutil/libm.h"
> > +#include "libavutil/imgutils.h"
> > +#include "libavutil/mathematics.h"
> > +#include "libavutil/opt.h"
> > +#include "libavutil/pixfmt.h"
> 
> Are they all necessary?
> 
> > +
> > +/**
> > + * ToDo :
> > + *
> > + * - handle empty extbuffers
> > + * - cropping
> > + * - allocate number of surfaces depending modules and number of b
> > +frames  */
> > +
> > +#define VPP_ZERO_MEMORY(VAR){ memset(, 0, sizeof(VAR));
> }
> 
> I don't think this is more readable, but that may only be me.
> 
> > +#define VPP_ALIGN16(value)  (((value + 15) >> 4) << 4)
> //
> > round up to a multiple of 16 +#define VPP_ALIGN32(value)
> (((value
> > + 31) >> 5) << 5)  // round up to a multiple of 32 +#define
> 
> Isn't this FFALIGN()?
> 
> > VPP_CHECK_POINTER(P, ...)   {if (!(P)) {return __VA_ARGS__;}} +
> > +// number of video enhancement filters (denoise, procamp, detail,
> > video_analysis, image stab) +#define ENH_FILTERS_COUNT   5
> > +
> > +typedef struct {
> > +const AVClass *class;
> > +
> > +AVFilterContext *ctx;
> > +
> > +mfxSession session;
> > +QSVSession internal_qs;
> > +
> > +AVRational framerate;   // target
> framerate
> > +
> > +mfxFrameSurface1 **in_surface;
> > +mfxFrameSurface1 **out_surface;
> > +
> > +mfxFrameAllocRequest req[2];// [0] - in, [1]
> - out
> > +
> > +int num_surfaces_in;// input
> surfaces
> > +int num_surfaces_out;   // output
> surfaces
> > +
> > +unsigned char * surface_buffers_out;// output
> surface
> > buffer +
> > +char *load_plugins;
> > +
> > +mfxVideoParam* pVppParam;
> > +
> > +int cur_out_idx;
> > +
> > +/* VPP extension */
> > +mfxExtBuffer* pExtBuf[1+ENH_FILTERS_COUNT];
> > +mfxExtVppAuxData extVPPAuxData;
> > +
> > +/* Video Enhancement Algorithms */
> > +mfxExtVPPDeinterlacing deinterlace_conf;
> > +mfxExtVPPFrameRateConversion frc_conf;
> > +mfxExtVPPDenoise denoise_conf;
> > +

Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter

[Carl Eugen Hoyos]

Carl Eugen Hoyos  ag.or.at> writes:

> > +AV_PIX_FMT_RGB32 ,
> 
> Trailing whitespace that cannot be committed to our repo,

There is no trailing whitespace, just an (unintended?) 
whitespace, sorry.

> please use tools/patcheck.

This is still a good idea!

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] avutil/intmath: use de Bruijn based ff_ctz

[Ganesh Ajjanagadde]

On Mon, Oct 12, 2015 at 7:14 AM, Ganesh Ajjanagadde  wrote:
> On Mon, Oct 12, 2015 at 12:37 AM, James Almer  wrote:
>> On 10/11/2015 10:55 PM, Ganesh Ajjanagadde wrote:
>>> It has already been demonstrated that the de Bruijn method has benefits
>>> over the current implementation: commit 
>>> 971d12b7f9d7be3ca8eb98e6c04ed521f83cbd3c.
>>> That commit implemented it for long long, this extends it to the 32 bit
>>> version.
>>>
>>> The function is renamed from ff_ctz to ff_ctz32 since it crucially
>>> depends on the 32 bit width of its argument. This is not an issue, as the
>>> only usage in avcodec/flacenc uses an int32_t anyway.
>>
>> I personally don't think the renaming is needed, for that matter. The
>> function takes an int as argument, and as far as ffmpeg supported arches
>> go those are 32 bits.
>> If you really want to be sure, just add a comment that the argument
>> absolutely needs to be 32 bits and that should be enough.
>
> This I don't understand. Why not make the function self documenting
> when we achieve it with zero penalty? I consider it ridiculous to add
> a comment when the name tells what it does better and more succinctly.
> We could add both, but I do not want to do that as generally FFmpeg
> favors a slightly terse style common to many  C projects. Thus, if
> adding the width, it should be to the function name, not to a comment.

What is the objection to the patch as it stands? IIRC Michael said he
does not like bit width specific stuff (in particular int = 32 bits),
to which I replied saying that the old code anyway made that
assumption on non GCC platforms. Thus, I argued that this patch
represents a strict improvement over existing code. If Michael (or
others) want a proper non "int = 32" function, that is a separate
concern which I can address in a follow-up patch.

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

Re: [FFmpeg-devel] [PATCH] avfilter, swresample, swscale: use fabs, fabsf instead of FFABS

[Ganesh Ajjanagadde]

On Wed, Oct 14, 2015 at 6:49 AM, Carl Eugen Hoyos  wrote:
> Ganesh Ajjanagadde  mit.edu> writes:
>
>> What? My numbers actually show that the new code may be faster -
>
> No, you are misunderstanding the numbers you posted.
> (Or I misunderstand them but nobody said so yet.)
>
> Highest runs are most relevant, skips have to be
> avoided (afaik).

Usually yes, but for such a small function, even the low runs should
be important.
Explain to me why I get consistently lower numbers with the new code
(on low runs) - if you are inclined to believe that they are
irrelevant, then why do I see a consistent trend there and not simply
"noise"?

>
> [...]
>
>> If you continue to post such stuff that has no basis, I might actually
>> get tempted into finding out for which floating point values the new
>> code is significantly faster, craft a relevant audio file, and post it
>> showing a huge performance difference - my random numbers benchmark
>> shows there must exist such values.
>
> Please do so!
>
>> > The more important question is if you can see the same
>> > changes in the disassembly of af_astats.o as what
>> > ubitux posted here for a short test function?
>>
>> I do. He uses clang/gcc, so do I.
>
> Sorry, my understanding fails here (I am not a native speaker):
> You did look at the disassembly of af_astats.o and there is
> inlined code instead of a function call?
>
>> The reason (irrelevant) is that both
>> of us run Arch.
>>
>> What is "more relevant" is if _you_ can see the changes
>> on some non Linux platform.
>
> If you could show that it is faster on any platform
> I would already be happy!

I already have with my random number benchmark. The original glibc
link I posted (which you essentially dismissed as irrelevant) also
shows why they switched away from their macros to fabs, fabsf, etc.

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

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

[Moritz Barsnick]

On Tue, Sep 29, 2015 at 23:39:10 +0200, Paul B Mahol wrote:
> +static const AVOption setfps_options[] = {
> +{ "fps", "A string describing desired output framerate", 
> OFFSET(framerate), AV_OPT_TYPE_VIDEO_RATE, { .str = "25" }, .flags = V|F },

I know this is taken 1:1 from the fps filter, but it seems more verbose
than what other filters care to say about this. The longer I think
about it, this is probably better than what the others say. :-)

General grudge: Not a single filter's documentation points to section
"Video rate", which describes the strings and ratios, while "Video
size" is referenced very often:
@ref{video size syntax,,"Video size" section in the ffmpeg-utils 
manual,ffmpeg-utils}. 
I think this calls for some improvement. (OT, sorry.)

> +.description = NULL_IF_CONFIG_SMALL("Set framerate for video output 
> link."),

Also perhaps too verbose here. Don't video filters (x->V) always do
something for the video output link? Seems redundant.

At least an entry in doc/filters.texi would be needed, saying
approximately what you told me in the thread (i.e. what's the use and
what's the difference to the fps filter).

Otherwise: Works fine for me on CFR input, nice way of speeding up or
slowing down without doing PTS math. Not tested on VFR input (where it
probably makes even more sense in many cases).

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

Re: [FFmpeg-devel] configure: Require libkvazaar < 0.7

[Carl Eugen Hoyos]

Arttu Ylä-Outinen  tut.fi> writes:

> > Attached patch for release/2.8 is supposed to fix 
> > ticket #4925, completely untested.

> > +enabled libkvazaar&&
> >  require_pkg_config "kvazaar < 0.7.0" kvazaar kvazaar.h kvz_api_get
> 
> There is an extra "kvazaar" between 0.7.0 and kvazaar.h. 
> It should be
> enabled libkvazaar && 
> require_pkg_config "kvazaar < 0.7.0" kvazaar.h kvz_api_get
> 
> instead. With that change, the patch seems to fix 
> the problem in #4925.

I fixed and pushed the patch, lets hope it works!

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

[FFmpeg-devel] lavf: Remove duplicated latm demuxer

[Carl Eugen Hoyos]

Hi!

Attached patch reduces code duplication.
(There was a API-relevant change in git right now.)

Please comment, Carl Eugen
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 2971912..953b55d 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -227,7 +227,6 @@ OBJS-$(CONFIG_IVF_MUXER) += ivfenc.o
 OBJS-$(CONFIG_JACOSUB_DEMUXER)   += jacosubdec.o subtitles.o
 OBJS-$(CONFIG_JACOSUB_MUXER) += jacosubenc.o rawenc.o
 OBJS-$(CONFIG_JV_DEMUXER)+= jvdec.o
-OBJS-$(CONFIG_LATM_DEMUXER)  += rawdec.o
 OBJS-$(CONFIG_LATM_MUXER)+= latmenc.o rawenc.o
 OBJS-$(CONFIG_LMLM4_DEMUXER) += lmlm4.o
 OBJS-$(CONFIG_LOAS_DEMUXER)  += loasdec.o rawdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0ccde9d..5a18eeb 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -167,7 +167,7 @@ void av_register_all(void)
 REGISTER_MUXDEMUX(IVF,  ivf);
 REGISTER_MUXDEMUX(JACOSUB,  jacosub);
 REGISTER_DEMUXER (JV,   jv);
-REGISTER_MUXDEMUX(LATM, latm);
+REGISTER_MUXER   (LATM, latm);
 REGISTER_DEMUXER (LMLM4,lmlm4);
 REGISTER_DEMUXER (LOAS, loas);
 REGISTER_MUXDEMUX(LRC,  lrc);
diff --git a/libavformat/rawdec.c b/libavformat/rawdec.c
index 16fb221..3738daf 100644
--- a/libavformat/rawdec.c
+++ b/libavformat/rawdec.c
@@ -123,19 +123,6 @@ AVInputFormat ff_data_demuxer = {
 };
 #endif
 
-#if CONFIG_LATM_DEMUXER
-
-AVInputFormat ff_latm_demuxer = {
-.name   = "latm",
-.long_name  = NULL_IF_CONFIG_SMALL("raw LOAS/LATM"),
-.read_header= ff_raw_audio_read_header,
-.read_packet= ff_raw_read_partial_packet,
-.flags  = AVFMT_GENERIC_INDEX | AVFMT_NOTIMESTAMPS,
-.extensions = "latm",
-.raw_codec_id   = AV_CODEC_ID_AAC_LATM,
-};
-#endif
-
 #if CONFIG_MJPEG_DEMUXER
 static int mjpeg_probe(AVProbeData *p)
 {
diff --git a/libavformat/version.h b/libavformat/version.h
index f7a2e09..92483b5 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -30,7 +30,7 @@
 #include "libavutil/version.h"
 
 #define LIBAVFORMAT_VERSION_MAJOR  57
-#define LIBAVFORMAT_VERSION_MINOR   3
+#define LIBAVFORMAT_VERSION_MINOR   4
 #define LIBAVFORMAT_VERSION_MICRO 100
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter

[Sven Dueking]

> -Ursprüngliche Nachricht-
> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
> von Carl Eugen Hoyos
> Gesendet: Mittwoch, 14. Oktober 2015 14:41
> An: ffmpeg-devel@ffmpeg.org
> Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
> 
> Carl Eugen Hoyos  ag.or.at> writes:
> 
> > > +AV_PIX_FMT_RGB32 ,
> >
> > Trailing whitespace that cannot be committed to our repo,
> 
> There is no trailing whitespace, just an (unintended?) whitespace,
> sorry.
> 
> > please use tools/patcheck.
> 
> This is still a good idea!

Agree :)

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

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

Re: [FFmpeg-devel] [PATCH] avutil: install des.h, rc4.h and tree.h as public headers

[Ronald S. Bultje]

Hi,

On Wed, Oct 14, 2015 at 10:50 AM, Nicolas George  wrote:

> Le duodi 22 vendémiaire, an CCXXIV, James Almer a écrit :
> > Since these two were never installed, we can remove the
> FF_API_CRYPTO_CONTEXT
> > wrapper from them before applying this patch, as this would be the first
> time
> > the API becomes public.
> >
> > Now, what i want to know is what will it be in the end for the actual
> > deprecation in question? Reimar and Nicolas were against making the
> context
> > opaque as having them in stack has its uses.
> > I want to know what people want, since the deprecation is not present on
> any
> > release and we still have time to rollback. Do we keep the deprecation in
> > place for des, rc4, blowfish and xtea, or remove it altogether?
>
> The reason for my objection are that the odds that the contents of the
> context change in the future are very small for low-level standardized
> crypto functions (this is the reason for making structure opaques). On the
> other hand, foregoing the checks for memory allocations is nice, and crypto
> functions may be used in speed-critical portions of the code where memory
> allocations are not negligible.


I think this is a reasonable argument, so +1 from me for "let's expose the
struct and remove deprecations".

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

Re: [FFmpeg-devel] [PATCHv2] avutil/intmath: use de Bruijn based ff_ctz

[Ronald S. Bultje]

Hi,

On Wed, Oct 14, 2015 at 1:26 PM, Ganesh Ajjanagadde 
wrote:

> On Wed, Oct 14, 2015 at 1:13 PM, Ronald S. Bultje 
> wrote:
> > Hi,
> >
> > On Wed, Oct 14, 2015 at 10:26 AM, Ganesh Ajjanagadde
> >  wrote:
> >>
> >> It has already been demonstrated that the de Bruijn method has benefits
> >> over the current implementation: commit
> >> 971d12b7f9d7be3ca8eb98e6c04ed521f83cbd3c.
> >> That commit implemented it for long long, this extends it to the int
> >> version.
> >>
> >> Tested with FATE.
> >>
> >> Signed-off-by: Ganesh Ajjanagadde 
> >> ---
> >>  libavutil/intmath.h | 32 +++-
> >>  1 file changed, 7 insertions(+), 25 deletions(-)
> >>
> >> diff --git a/libavutil/intmath.h b/libavutil/intmath.h
> >> index 802abe3..5a55123 100644
> >> --- a/libavutil/intmath.h
> >> +++ b/libavutil/intmath.h
> >> @@ -129,33 +129,15 @@ static av_always_inline av_const int
> >> ff_log2_16bit_c(unsigned int v)
> >>   * @return   the number of trailing 0-bits
> >>   */
> >>  #if !defined( _MSC_VER )
> >> +/* We use the De-Bruijn method outlined in:
> >> + * http://supertech.csail.mit.edu/papers/debruijn.pdf. */
> >>  static av_always_inline av_const int ff_ctz_c(int v)
> >>  {
> >> -int c;
> >> -
> >> -if (v & 0x1)
> >> -return 0;
> >> -
> >> -c = 1;
> >> -if (!(v & 0x)) {
> >> -v >>= 16;
> >> -c += 16;
> >> -}
> >> -if (!(v & 0xff)) {
> >> -v >>= 8;
> >> -c += 8;
> >> -}
> >> -if (!(v & 0xf)) {
> >> -v >>= 4;
> >> -c += 4;
> >> -}
> >> -if (!(v & 0x3)) {
> >> -v >>= 2;
> >> -c += 2;
> >> -}
> >> -c -= v & 0x1;
> >> -
> >> -return c;
> >> +static const uint8_t debruijn_ctz32[32] = {
> >> +0, 1, 28, 2, 29, 14, 24, 3, 30, 22, 20, 15, 25, 17, 4, 8,
> >> +31, 27, 13, 23, 21, 19, 16, 7, 26, 12, 18, 6, 11, 5, 10, 9
> >> +};
> >> +return debruijn_ctz32[(uint32_t)((v & -v) * 0x077CB531U) >> 27];
> >>  }
> >>  #else
> >>  static av_always_inline av_const int ff_ctz_c( int v )
> >> --
> >> 2.6.1
> >
> >
> > lgtm. Would you like to push yourself or have me do it for you?
>
> Either way is fine: if it is not done by tonight, I will do it.
> Thanks.


Pushed :)

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

Re: [FFmpeg-devel] lavf: Remove duplicated latm demuxer

[Paul B Mahol]

On 10/14/15, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch reduces code duplication.
> (There was a API-relevant change in git right now.)
>
> Please comment, Carl Eugen
>

Duplicate how? Replaced by what?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avutil/fifo: add function av_fifo_generic_peek_at()

[Michael Niedermayer]

On Wed, Oct 14, 2015 at 02:20:07PM +0800, Zhang Rui wrote:
> ---
>  libavutil/fifo.c| 55 
> +
>  libavutil/fifo.h| 11 +++
>  tests/ref/fate/fifo | 27 ++
>  3 files changed, 93 insertions(+)
> 
> diff --git a/libavutil/fifo.c b/libavutil/fifo.c
> index 07fb4ec..a7da591 100644
> --- a/libavutil/fifo.c
> +++ b/libavutil/fifo.c
> @@ -148,6 +148,38 @@ int av_fifo_generic_write(AVFifoBuffer *f, void *src, 
> int size,
>  return total - size;
>  }
>  
> +int av_fifo_generic_peek_at(AVFifoBuffer *f, void *dest, int offset, int 
> buf_size, void (*func)(void*, void*, int))
> +{

> +uint8_t *rptr = f->rptr + offset;

this can overflow
fixed it and applied

thanks


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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

[FFmpeg-devel] [PATCHv2] avformat/movenc: suppress -Wstrict-overflow warnings

[Ganesh Ajjanagadde]

This patch results in identical behavior of movenc, and suppresses 
-Wstrict-overflow
warnings observed in GCC 5.2:
http://fate.ffmpeg.org/log.cgi?time=20150926231053=compile=x86_64-archlinux-gcc-threads-misc,
"warning: assuming signed overflow does not occur when assuming that (X - c) > 
X is always false [-Wstrict-overflow]"
I have manually checked that all usages are safe, and overflow possibility does
not exist with this expression rewrite.

Some expressed concern over readability loss, hence a comment is added.
This is the simplest way to suppress this warning.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavformat/movenc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 5115585..ff997f2 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -854,7 +854,9 @@ static int get_cluster_duration(MOVTrack *track, int 
cluster_idx)
 {
 int64_t next_dts;
 
-if (cluster_idx >= track->entry)
+/* GCC 5.2 wants to "optimize" cluster_idx >= track->entry to the below
+ * expression. We actually mean cluster_idx >= track->entry. */
+if (cluster_idx - track->entry >= 0)
 return 0;
 
 if (cluster_idx + 1 == track->entry)
-- 
2.6.1

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

Re: [FFmpeg-devel] [PATCH] avformat/movenc: suppress -Wstrict-overflow warnings

[Ganesh Ajjanagadde]

On Mon, Oct 12, 2015 at 12:00 PM, Ganesh Ajjanagadde  wrote:
> On Mon, Oct 12, 2015 at 11:47 AM, Michael Niedermayer
>  wrote:
>> On Mon, Oct 12, 2015 at 11:16:00AM -0400, Ganesh Ajjanagadde wrote:
>>> On Mon, Oct 12, 2015 at 10:54 AM, Ronald S. Bultje  
>>> wrote:
>>> > Hi,
>>> >
>>> > On Mon, Oct 12, 2015 at 10:51 AM, Ganesh Ajjanagadde 
>>> > wrote:
>>> >>
>>> >> On Thu, Oct 8, 2015 at 5:07 PM, Ganesh Ajjanagadde 
>>> >> wrote:
>>> >> > On Sat, Oct 3, 2015 at 8:17 AM, Ganesh Ajjanagadde 
>>> >> > wrote:
>>> >> >> On Tue, Sep 29, 2015 at 10:49 AM, Ganesh Ajjanagadde 
>>> >> >> 
>>> >> >> wrote:
>>> >> >>> On Sun, Sep 27, 2015 at 9:39 PM, Ganesh Ajjanagadde 
>>> >> >>> 
>>> >> >>> wrote:
>>> >>  On Sun, Sep 27, 2015 at 9:18 PM, Michael Niedermayer
>>> >>   wrote:
>>> >> > On Sun, Sep 27, 2015 at 01:23:03PM -0400, Ganesh Ajjanagadde wrote:
>>> >> >> On Sun, Sep 27, 2015 at 12:58 PM, Michael Niedermayer
>>> >> >>  wrote:
>>> >> >> > On Sat, Sep 26, 2015 at 10:55:26PM -0400, Ganesh Ajjanagadde
>>> >> >> > wrote:
>>> >> >> >> On Sat, Sep 26, 2015 at 10:32 PM, Ronald S. Bultje
>>> >> >> >>  wrote:
>>> >> >> >> > Hi,
>>> >> >> >> >
>>> >> >> >> > On Sat, Sep 26, 2015 at 7:19 PM, Ganesh Ajjanagadde
>>> >> >> >> > 
>>> >> >> >> > wrote:
>>> >> >> >> >
>>> >> >> >> >> On Sat, Sep 26, 2015 at 7:11 PM, Michael Niedermayer
>>> >> >> >> >> 
>>> >> >> >> >> wrote:
>>> >> >> >> >> > On Fri, Sep 18, 2015 at 05:15:50PM -0400, Ganesh
>>> >> >> >> >> > Ajjanagadde wrote:
>>> >> >> >> >> >> This patch results in identical behavior of movenc, and
>>> >> >> >> >> >> suppresses
>>> >> >> >> >> -Wstrict-overflow
>>> >> >> >> >> >> warnings observed in GCC 5.2.
>>> >> >> >> >> >> I have manually checked that all usages are safe, and
>>> >> >> >> >> >> overflow
>>> >> >> >> >> possibility does
>>> >> >> >> >> >> not exist with this expression rewrite.
>>> >> >> >> >> >>
>>> >> >> >> >> >> Signed-off-by: Ganesh Ajjanagadde 
>>> >> >> >> >> >> 
>>> >> >> >> >> >> ---
>>> >> >> >> >> >>  libavformat/movenc.c | 2 +-
>>> >> >> >> >> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>>> >> >> >> >> >>
>>> >> >> >> >> >> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>>> >> >> >> >> >> index af03d1e..6e4a1a6 100644
>>> >> >> >> >> >> --- a/libavformat/movenc.c
>>> >> >> >> >> >> +++ b/libavformat/movenc.c
>>> >> >> >> >> >> @@ -854,7 +854,7 @@ static int
>>> >> >> >> >> >> get_cluster_duration(MOVTrack *track,
>>> >> >> >> >> int cluster_idx)
>>> >> >> >> >> >>  {
>>> >> >> >> >> >>  int64_t next_dts;
>>> >> >> >> >> >>
>>> >> >> >> >> >> -if (cluster_idx >= track->entry)
>>> >> >> >> >> >> +if (cluster_idx - track->entry >= 0)
>>> >> >> >> >> >
>>> >> >> >> >> > i do not understand what this fixes or why
>>> >> >> >> >> > also plese quote the actual warnings which are fixed in 
>>> >> >> >> >> > the
>>> >> >> >> >> > commit
>>> >> >> >> >> > message
>>> >> >> >> >>
>>> >> >> >> >> I have posted v2 with a more detailed commit message. It
>>> >> >> >> >> should be
>>> >> >> >> >> self explanatory.
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > Even with the new message, it's still not clear to me what's
>>> >> >> >> > being fixed.
>>> >> >> >> > What does the warning check for? What is the problem in the
>>> >> >> >> > initial
>>> >> >> >> > expression?
>>> >> >> >>
>>> >> >> >> Compilers make transformations on the statements in order to
>>> >> >> >> possibly
>>> >> >> >> get better performance when compiled with optimizations.
>>> >> >> >> However, some
>>> >> >> >> of these optimizations require assumptions in the code. In
>>> >> >> >> particular,
>>> >> >> >> the compiler is internally rewriting cluster_idx >= 
>>> >> >> >> track->entry
>>> >> >> >> to
>>> >> >> >> cluster_idx - track->entry >= 0 internally for some reason (I 
>>> >> >> >> am
>>> >> >> >> not
>>> >> >> >> an asm/instruction set guy, so I can't comment why it likes
>>> >> >> >> this).
>>> >> >> >> However, such a transformation is NOT always safe as integer
>>> >> >> >> arithmetic can overflow (try e.g extreme values close to
>>> >> >> >> INT_MIN,
>>> >> >> >> INT_MAX). The warning is spit out since the compiler can't be
>>> >> >> >> sure
>>> >> >> >> that this is safe, but it still wants to do it (I suspect only
>>> >> >> >> the
>>> >> >> >> -O3/-O2 level that try this, can check if you want).
>>> >> >> >
>>> >> >> > iam not sure i 

[FFmpeg-devel] [PATCH] doc/ffmpeg: use stream_loop instead of loop

[Ganesh Ajjanagadde]

Commit dbb03b8e47f905f0f7b10c3eb5ac11f9bfc793ff renamed loop to
stream_loop. This documents the change.

Signed-off-by: Ganesh Ajjanagadde 
---
 doc/ffmpeg.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 5624930..de49618 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -253,7 +253,7 @@ Overwrite output files without asking.
 Do not overwrite output files, and exit immediately if a specified
 output file already exists.
 
-@item -loop @var{number} (@emph{input})
+@item -stream_loop @var{number} (@emph{input})
 Set number of times input stream shall be looped.
 
 @item -c[:@var{stream_specifier}] @var{codec} (@emph{input/output,per-stream})
-- 
2.6.1

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

Re: [FFmpeg-devel] [PATCH] doc/ffmpeg: use stream_loop instead of loop

[Ganesh Ajjanagadde]

On Wed, Oct 14, 2015 at 9:54 PM, Ganesh Ajjanagadde
 wrote:
> Commit dbb03b8e47f905f0f7b10c3eb5ac11f9bfc793ff renamed loop to
> stream_loop. This documents the change.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  doc/ffmpeg.texi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> index 5624930..de49618 100644
> --- a/doc/ffmpeg.texi
> +++ b/doc/ffmpeg.texi
> @@ -253,7 +253,7 @@ Overwrite output files without asking.
>  Do not overwrite output files, and exit immediately if a specified
>  output file already exists.
>
> -@item -loop @var{number} (@emph{input})
> +@item -stream_loop @var{number} (@emph{input})
>  Set number of times input stream shall be looped.
>
>  @item -c[:@var{stream_specifier}] @var{codec} 
> (@emph{input/output,per-stream})
> --
> 2.6.1
>

this is trivial, will push within next 1 hour if no one objects.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/avfiltergraph: fix -Wunused-result warnings

[Ganesh Ajjanagadde]

Commit bf0d2d6030c239f91e0368a20fb2dc0705bfec99 introduced
av_warn_unused_result to avfilter/formats, whose associated warnings
were mostly fixed in 6aaac24d72a7da631173209841a3944fcb4a3309. This
fixes the issues in avfilter/avfiltergraph.

Tested with FATE.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/avfiltergraph.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c
index bc10665..d749250 100644
--- a/libavfilter/avfiltergraph.c
+++ b/libavfilter/avfiltergraph.c
@@ -745,7 +745,8 @@ do {
   \
 fmts = out_link->in_ ## list;  \
\
 if (!out_link->in_ ## list->nb) {  \
-add_format(_link->in_ ##list, fmt);\
+if ((ret = add_format(_link->in_ ##list, fmt)) < 0)\
+return ret;\
 ret = 1;   \
 break; \
 }  \
@@ -811,16 +812,21 @@ static int reduce_formats_on_filter(AVFilterContext 
*filter)
 return ret;
 }
 
-static void reduce_formats(AVFilterGraph *graph)
+static int reduce_formats(AVFilterGraph *graph)
 {
-int i, reduced;
+int i, reduced, ret;
 
 do {
 reduced = 0;
 
-for (i = 0; i < graph->nb_filters; i++)
-reduced |= reduce_formats_on_filter(graph->filters[i]);
+for (i = 0; i < graph->nb_filters; i++) {
+if ((ret = reduce_formats_on_filter(graph->filters[i])) < 0)
+return ret;
+reduced |= ret;
+}
 } while (reduced);
+
+return 0;
 }
 
 static void swap_samplerates_on_filter(AVFilterContext *filter)
@@ -1138,7 +1144,8 @@ static int graph_config_formats(AVFilterGraph *graph, 
AVClass *log_ctx)
 /* Once everything is merged, it's possible that we'll still have
  * multiple valid media format choices. We try to minimize the amount
  * of format conversion inside filters */
-reduce_formats(graph);
+if ((ret = reduce_formats(graph)) < 0)
+return ret;
 
 /* for audio filters, ensure the best format, sample rate and channel 
layout
  * is selected */
-- 
2.6.1

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

[FFmpeg-devel] [PATCH 1/2] avfilter/internal: Doxygen for ff_fmt_is_in

[Ganesh Ajjanagadde]

This clarifies and Doxygen's the comment for ff_fmt_is_in.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/internal.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavfilter/internal.h b/libavfilter/internal.h
index bb94707..c07d306 100644
--- a/libavfilter/internal.h
+++ b/libavfilter/internal.h
@@ -152,7 +152,13 @@ struct AVFilterInternal {
 avfilter_execute_func *execute;
 };
 
-/** Tell is a format is contained in the provided list terminated by -1. */
+/**
+ * Tell if a format is contained in the provided -1 terminated list of formats.
+ *
+ * @param fmt provided format
+ * @param fmts -1 terminated list of formats
+ * @return 1 if present, 0 if absent
+ */
 int ff_fmt_is_in(int fmt, const int *fmts);
 
 /* Functions to parse audio format arguments */
-- 
2.6.1

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

Re: [FFmpeg-devel] [PATCH] doc/ffmpeg: use stream_loop instead of loop

[Ganesh Ajjanagadde]

On Wed, Oct 14, 2015 at 9:55 PM, Ganesh Ajjanagadde
 wrote:
> On Wed, Oct 14, 2015 at 9:54 PM, Ganesh Ajjanagadde
>  wrote:
>> Commit dbb03b8e47f905f0f7b10c3eb5ac11f9bfc793ff renamed loop to
>> stream_loop. This documents the change.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  doc/ffmpeg.texi | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
>> index 5624930..de49618 100644
>> --- a/doc/ffmpeg.texi
>> +++ b/doc/ffmpeg.texi
>> @@ -253,7 +253,7 @@ Overwrite output files without asking.
>>  Do not overwrite output files, and exit immediately if a specified
>>  output file already exists.
>>
>> -@item -loop @var{number} (@emph{input})
>> +@item -stream_loop @var{number} (@emph{input})
>>  Set number of times input stream shall be looped.
>>
>>  @item -c[:@var{stream_specifier}] @var{codec} 
>> (@emph{input/output,per-stream})
>> --
>> 2.6.1
>>
>
> this is trivial, will push within next 1 hour if no one objects.

pushed. Please let me know if such things are ok or not in the future
- technically I guess doc maintainers need to respond before I can
push, but as this change was trivial I thought I would do it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] mips: disable all features in configure if no cpu is matched

[Vicente Olivert Riera]

Signed-off-by: Vicente Olivert Riera 
---
 configure |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 7e55e92..cd27ad7 100755
--- a/configure
+++ b/configure
@@ -4130,6 +4130,15 @@ elif enabled mips; then
 disable mips64r6
 disable msa
 ;;
+*)
+disable mipsfpu
+disable mips32r2
+disable mips32r5
+disable mips64r6
+disable mipsdspr1
+disable mipsdspr2
+disable msa
+;;
 esac
 
 elif enabled ppc; then
-- 
1.7.1

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

Re: [FFmpeg-devel] [PATCH 08/10] tools/crypto_bench: add AES-192 and AES-256

[Nicolas George]

Le primidi 21 vendémiaire, an CCXXIV, Rodger Combs a écrit :
> ---
>  tools/crypto_bench.c | 82 
> 
>  1 file changed, 82 insertions(+)

LGTM

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 10/10] tools/crypto_bench: add support for multiple lavu versions by cpuflag

[Nicolas George]

Le primidi 21 vendémiaire, an CCXXIV, Rodger Combs a écrit :
> ---
>  tools/crypto_bench.c | 51 +++
>  1 file changed, 43 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/crypto_bench.c b/tools/crypto_bench.c
> index 0b1bfc8..f84e2a7 100644
> --- a/tools/crypto_bench.c
> +++ b/tools/crypto_bench.c
> @@ -32,6 +32,7 @@
>  #include "libavutil/crc.h"
>  #include "libavutil/intreadwrite.h"
>  #include "libavutil/timer.h"
> +#include "libavutil/cpu.h"
>  
>  #ifndef AV_READ_TIME
>  #define AV_READ_TIME(x) 0
> @@ -65,6 +66,7 @@ struct hash_impl {
>  const char *name;
>  void (*run)(uint8_t *output, const uint8_t *input, unsigned size);
>  const char *output;
> +int cpu_versions;
>  };
>  
>  /***
> @@ -658,6 +660,16 @@ static unsigned crc32(const uint8_t *data, unsigned size)
>  return av_crc(av_crc_get_table(AV_CRC_32_IEEE), 0, data, size);
>  }
>  
> +static const struct {
> +int flag;
> +const char *name;
> +} cpu_flag_tab[] = {
> +#if ARCH_X86
> +{ AV_CPU_FLAG_AESNI, "aesni"  },
> +#endif
> +{ 0 }
> +};
> +
>  static void run_implementation(const uint8_t *input, uint8_t *output,
> struct hash_impl *impl, unsigned size)
>  {
> @@ -671,6 +683,29 @@ static void run_implementation(const uint8_t *input, 
> uint8_t *output,
>  if (enabled_libs  && !av_stristr(enabled_libs,  impl->lib) ||
>  enabled_algos && !av_stristr(enabled_algos, impl->name))
>  return;
> +

> +if (impl->cpu_versions && !strcmp(impl->lib, "lavu")) {

Could you play with the macros in order to have cpu_versions only in the
libraries that support it?

> +char lib_name[32];
> +struct hash_impl impl2 = *impl;
> +int real_flags = av_get_cpu_flags();
> +int current_flags = real_flags;
> +impl2.cpu_versions = 0;
> +impl2.lib = lib_name;
> +for (i = 0; cpu_flag_tab[i].flag; i++) {
> +if (cpu_flag_tab[i].flag & impl->cpu_versions &&
> +real_flags & cpu_flag_tab[i].flag) {
> +snprintf(lib_name, sizeof(lib_name), "lavu_%s", 
> cpu_flag_tab[i].name);

> +run_implementation(input, output, , size);
> +current_flags &= ~cpu_flag_tab[i].flag;
> +av_force_cpu_flags(current_flags);

It looks a bit strange: you seem to rely on the fact that the flags are
enabled enabled by default, and to disable them one by one.

If there are more flags at some time, it seems even stranger: the first run
will have flag1+flag2+flag3, the second only flag2+flag3, the third only
flag3.

Is this on purpose?

> +}
> +}
> +impl2.lib = "lavu";
> +run_implementation(input, output, , size);
> +av_force_cpu_flags(real_flags);
> +return;
> +}
> +
>  if (!sscanf(impl->output, "crc:%x", )) {
>  outlen = strlen(impl->output) / 2;
>  for (i = 0; i < outlen; i++) {
> @@ -709,8 +744,8 @@ static void run_implementation(const uint8_t *input, 
> uint8_t *output,
>  fflush(stdout);
>  }
>  
> -#define IMPL_USE(lib, name, symbol, output) \
> -{ #lib, name, run_ ## lib ## _ ## symbol, output },
> +#define IMPL_USE(lib, name, symbol, output, ...) \
> +{ #lib, name, run_ ## lib ## _ ## symbol, output, __VA_ARGS__ },
>  #define IMPL(lib, ...) IMPL_USE_ ## lib(lib, __VA_ARGS__)
>  #define IMPL_ALL(...) \
>  IMPL(lavu,   __VA_ARGS__) \
> @@ -727,12 +762,12 @@ struct hash_impl implementations[] = {
>  IMPL(lavu, "RIPEMD-128", ripemd128, 
> "9ab8bfba2ddccc5d99c9d4cdfb844a5f")
>  IMPL(tomcrypt, "RIPEMD-128", ripemd128, 
> "9ab8bfba2ddccc5d99c9d4cdfb844a5f")
>  IMPL_ALL("RIPEMD-160", ripemd160, 
> "62a5321e4fc8784903bb43ab7752c75f8b25af00")
> -IMPL_ALL("AES-128-ECB",aes128,"crc:ff6bc888")
> -IMPL_ALL("AES-192-ECB",aes192,"crc:1022815b")
> -IMPL_ALL("AES-256-ECB",aes256,"crc:792e4e8a")
> -IMPL_ALL("AES-128-CBC",aes128cbc, "crc:0efebabe")
> -IMPL_ALL("AES-192-CBC",aes192cbc, "crc:ee2e34e8")
> -IMPL_ALL("AES-256-CBC",aes256cbc, "crc:0c9b875c")
> +IMPL_ALL("AES-128-ECB",aes128,"crc:ff6bc888", AV_CPU_FLAG_AESNI)
> +IMPL_ALL("AES-192-ECB",aes192,"crc:1022815b", AV_CPU_FLAG_AESNI)
> +IMPL_ALL("AES-256-ECB",aes256,"crc:792e4e8a", AV_CPU_FLAG_AESNI)
> +IMPL_ALL("AES-128-CBC",aes128cbc, "crc:0efebabe", AV_CPU_FLAG_AESNI)
> +IMPL_ALL("AES-192-CBC",aes192cbc, "crc:ee2e34e8", AV_CPU_FLAG_AESNI)
> +IMPL_ALL("AES-256-CBC",aes256cbc, "crc:0c9b875c", AV_CPU_FLAG_AESNI)
>  IMPL_ALL("CAMELLIA",   camellia,  "crc:7abb59a7")
>  IMPL_ALL("CAST-128",   cast128,   "crc:456aa584")
>  IMPL_ALL("BLOWFISH",   blowfish,  "crc:33e8aa74")

Does it produce warnings for missing initializers in the other cases?

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital 

Re: [FFmpeg-devel] [PATCH] doc/ffmpeg: use stream_loop instead of loop

[Timothy Gu]

On Wed, Oct 14, 2015 at 8:08 PM Ganesh Ajjanagadde 
wrote:

> pushed. Please let me know if such things are ok or not in the future
> - technically I guess doc maintainers need to respond before I can
> push, but as this change was trivial I thought I would do it.\
>

As a documentation maintainer, I'm comfortable to say that changes like
this can be directly pushed without first sending it to the ML.

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

Re: [FFmpeg-devel] [PATCH 1/2] avfilter/internal: Doxygen for ff_fmt_is_in

[Timothy Gu]

On Wed, Oct 14, 2015 at 8:05 PM Ganesh Ajjanagadde 
wrote:
> This clarifies and Doxygen's the comment for ff_fmt_is_in.

 ^
gajjanag.c:1:23: error: unexpected token ‘adjective’


>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavfilter/internal.h | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/internal.h b/libavfilter/internal.h
> index bb94707..c07d306 100644
> --- a/libavfilter/internal.h
> +++ b/libavfilter/internal.h
> @@ -152,7 +152,13 @@ struct AVFilterInternal {
>  avfilter_execute_func *execute;
>  };
>
> -/** Tell is a format is contained in the provided list terminated by -1.
> */
> +/**
>


> + * Tell if a format is contained in the provided -1 terminated list of
> formats.
>

-1-terminated

Also what's the format supposed to be? If it can be used for all integers
(as the source seems to indicate) then say "tell if an integer is contained
… list of integers. This is useful for determining if BLAH format is in an
array of supported formats."


> + *
> + * @param fmt provided format
> + * @param fmts -1 terminated list of formats
> + * @return 1 if present, 0 if absent
> + */
>  int ff_fmt_is_in(int fmt, const int *fmts);
>

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

[FFmpeg-devel] [libavformat rtsp] RTSP protocol not sending the ending TEARDOWN packet

[Nicolas Adenis-Lamarre]

When a client close a rtsp connexion, it is supposed to send the TEARDOWN
packet according to
​https://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol to tell to the
server to stop the streaming.
ffmpeg doesn't (controlled by wireshark, works with some other soft), while
i guess it worked at a given time while the code to do it is inside ffmpeg.

In short, because my tv provider allows only 1 channel at a time, i've to
wait 30 seconds between each channel change. However, even with 2 channels
at a time, the traffic is higer for 30 secondes and there are troubles
until the end of the server streaming of the 1st channel.

Below, you'll find more detail, and a not perfect at all but working in my
case patch to show the problem more in detail.

How to reproduce:

% ffplay 
'rtsp://mafreebox.freebox.fr/fbxtv_pub/stream?namespace=1=201=ld'

The attached file is not really a patch while it's not the good way to fix.
However, it works in my case.

I found that ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
doesn't send the teardown packet, but the same command for DESCRIBE works,
so i tried to call this function before (i supposed that something is
closed too soon, or not flushed) :

The thing is that

rtsp::read_close function
containing ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);

is called after

is->abort_request = 1;
SDL_WaitThread(is->read_tid, NULL);

and at the end, the packet is never sent.
To quickly and badly fix, i've added a preclose function called before the
sdl_waitthread.

I'have troubleshooted this bug for 1 week, and only yesterday i finally
found it was related to ffmpeg, so i'm new to the ffmpeg code, so for the
moment, i don't the architecture and the best place to put the TEARDOWN
packet. (at the end of the thread ? or at the same place but fixing
something else). You guess i didn't found immediatly it was a missing
teardown packet in the rtsp protocol (i'm new to that protocol too...).
diff --git a/ffplay.c b/ffplay.c
index 4a084b4..c47cc95 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -1192,6 +1192,8 @@ static void stream_component_close(VideoState *is, int stream_index)
 
 static void stream_close(VideoState *is)
 {
+avformat_preclose_input(>ic);
+  
 /* XXX: use a special url_shutdown call to abort parse cleanly */
 is->abort_request = 1;
 SDL_WaitThread(is->read_tid, NULL);
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index f3ffcfb..76d9402 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -693,6 +693,12 @@ typedef struct AVInputFormat {
 int (*read_packet)(struct AVFormatContext *, AVPacket *pkt);
 
 /**
+ * The stream is going to be closed. The AVFormatContext and AVStreams are not
+ * freed by this function
+ */
+int (*read_preclose)(struct AVFormatContext *);
+  
+/**
  * Close the stream. The AVFormatContext and AVStreams are not
  * freed by this function
  */
@@ -2231,6 +2237,14 @@ int av_read_play(AVFormatContext *s);
 int av_read_pause(AVFormatContext *s);
 
 /**
+ * Call before closing input AVFormatContext.
+ */
+void avformat_preclose_input(AVFormatContext **s);
+/**
+ * @}
+ */
+
+/**
  * Close an opened input AVFormatContext. Free it and all its contents
  * and set *s to NULL.
  */
diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index 3c0010e..17afd47 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -53,13 +53,20 @@ static const struct RTSPStatusMessage {
 { 0,  "NULL" }
 };
 
-static int rtsp_read_close(AVFormatContext *s)
+static int rtsp_read_preclose(AVFormatContext *s)
 {
 RTSPState *rt = s->priv_data;
 
-if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN))
-ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
+if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN)) {
+  ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
+}
+return 0;
+}
 
+static int rtsp_read_close(AVFormatContext *s)
+{
+RTSPState *rt = s->priv_data;
+	
 ff_rtsp_close_streams(s);
 ff_rtsp_close_connections(s);
 ff_network_close();
@@ -551,7 +558,7 @@ static int rtsp_read_play(AVFormatContext *s)
 ff_rtsp_send_cmd(s, "PLAY", rt->control_uri, cmd, reply, NULL);
 if (reply->status_code != RTSP_STATUS_OK) {
 return ff_rtsp_averror(reply->status_code, -1);
-}
+}	
 if (rt->transport == RTSP_TRANSPORT_RTP &&
 reply->range_start != AV_NOPTS_VALUE) {
 for (i = 0; i < rt->nb_rtsp_streams; i++) {
@@ -616,7 +623,7 @@ int ff_rtsp_setup_input_streams(AVFormatContext *s, RTSPMessageHeader *reply)
 }
 if (!content)
 return AVERROR_INVALIDDATA;
-
+
 av_log(s, AV_LOG_VERBOSE, "SDP:\n%s\n", content);
 /* now we got the SDP description, we parse it */
 ret = ff_sdp_parse(s, (const char *)content);
@@ -966,6 +973,7 @@ AVInputFormat ff_rtsp_demuxer = {
 .read_probe