Re: [FFmpeg-devel] VS 2015 patch

[Hendrik Leppkes]

On Tue, Nov 24, 2015 at 11:18 PM, Bruce Dawson  wrote:
> I've been working on getting Chromium compiling with VS 2015 and there are
> some tweaks needed to ffmpeg to get it working with gn. Currently the
> BUILD.gn file defines five symbols/keywords that are missing from VS 2013's
> C compiler, and defines _snprintf to make it safer. These defines are
> illegal and do not work in VS 2015, , and they are not necessary because VS
> 2015 supplies inline, snprintf, etc. These are the defines:
>
>   "inline=__inline",
>   "strtoll=_strtoi64",
>   "strtod=avpriv_strtod",
>   "snprintf=avpriv_snprintf",
>   "_snprintf=avpriv_snprintf",
>   "vsnprintf=avpriv_vsnprintf",
>
> The attached patch lets ffmpeg build with both VS 2013 and VS 2015.
>
> Comments?

FFmpeg builds with VS2015 out of the box today.

BUILD.gn is not part of ffmpeg, so I suppose you send the patch to the
wrong place.

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

Re: [FFmpeg-devel] [PATCH 4/5] concatdec: add option for adding segment start time and duration metadata

[Marton Balint]

On Fri, 13 Nov 2015, Nicolas George wrote:


Le decadi 20 brumaire, an CCXXIV, Marton Balint a écrit :

Signed-off-by: Marton Balint 
---
 doc/demuxers.texi   |  8 
 libavformat/concatdec.c | 10 ++
 2 files changed, 18 insertions(+)


This one looks fine.


Applied, thanks.

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

Re: [FFmpeg-devel] [PATCH 3/5] concatdec: simplify duration calculation in open_next_file

[Marton Balint]

On Fri, 13 Nov 2015, Nicolas George wrote:


Le decadi 20 brumaire, an CCXXIV, Marton Balint a écrit :

If duration is still AV_NOPTS_VALUE when opening the next file, we can assume
that outpoint is not set.

Signed-off-by: Marton Balint 
---
 libavformat/concatdec.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)


Seems tightly linked with patch #2 in the series, and I fear I am missing
something in it, so waiting for your reply on it.



Applied this as well.

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

Re: [FFmpeg-devel] [PATCH] Allow mpjpeg demuxer to process MIME parts which do not include Content-Length header.

[Michael Niedermayer]

On Tue, Nov 24, 2015 at 03:01:28PM -0500, Alex Agranovsky wrote:
[...]

> From 2c253d7978a6c9c2dc701d393eb5b9d68e831c98 Mon Sep 17 00:00:00 2001
> From: Alex Agranovsky 
> Date: Tue, 24 Nov 2015 00:07:34 -0500
> Subject: [PATCH 2/2] If available, use the actual boundary in HTTP response's
>  Content-Type header, to separate MIME parts in mpjpeg stream
> 
> This code is disabled by default so not to break some fragile endpoints 
> sending invalid MIME, but can be enabled via AVOption 'strict_mime_boundary'
> 
> Signed-off-by: Alex Agranovsky 
> ---
>  libavformat/mpjpegdec.c | 75 
> +++--
>  1 file changed, 72 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
> index b9093ea..b89f128 100644
> --- a/libavformat/mpjpegdec.c
> +++ b/libavformat/mpjpegdec.c
> @@ -20,6 +20,7 @@
>   */
>  
>  #include "libavutil/avstring.h"
> +#include "libavutil/opt.h"
>  
>  #include "avformat.h"
>  #include "internal.h"
> @@ -28,9 +29,11 @@
>  
>  
>  typedef struct MPJPEGDemuxContext {
> +const AVClass *class;
>  char*   boundary;
>  char*   searchstr;
>  int searchstr_len;
> +int strict_mime_boundary;
>  } MPJPEGDemuxContext;
>  
>  
> @@ -245,6 +248,43 @@ static int parse_multipart_header(AVIOContext *pb,
>  }
>  
>  
> +static char* mpjpeg_get_boundary(AVIOContext* pb)
> +{
> +uint8_t *mime_type = NULL;
> +uint8_t *start;
> +uint8_t *end;
> +uint8_t *res = NULL;
> +int len;
> +
> +/* get MIME type, and skip to the first parameter */
> +av_opt_get(pb, "mime_type", AV_OPT_SEARCH_CHILDREN, _type);
> +start = mime_type;
> +while (start != NULL && *start != '\0') {
> +start = strchr(start, ';');
> +if (start)
> +start = start+1;
> +
> +while (av_isspace(*start))
> +start++;
> +
> +if (!av_strncasecmp(start, "boundary=", 9)) {
> +start += 9;
> +
> +end = strchr(start, ';');
> +if (end)
> +len = end - start - 1;
> +else
> +len = strlen(start);
> +res = av_strndup(start, len);
> +break;
> +}
> +}
> +
> +av_freep(_type);
> +return res;
> +}
> +
> +
>  static int mpjpeg_read_packet(AVFormatContext *s, AVPacket *pkt)
>  {
>  int size;
> @@ -252,8 +292,18 @@ static int mpjpeg_read_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  
>  MPJPEGDemuxContext *mpjpeg = s->priv_data;
>  if (mpjpeg->boundary == NULL) {
> -mpjpeg->boundary = av_strdup("--");
> -mpjpeg->searchstr = av_strdup("\r\n--");
> +uint8_t* boundary = NULL;
> +if (mpjpeg->strict_mime_boundary) {
> +boundary = mpjpeg_get_boundary(s->pb);
> +}
> +if (boundary != NULL) {
> +mpjpeg->boundary = boundary;
> +mpjpeg->searchstr = av_malloc(4+strlen(boundary)+1);

> +sprintf( mpjpeg->searchstr, "\r\n%s\r\n", boundary );

please use snprintf()


> +} else {
> +mpjpeg->boundary = av_strdup("--");
> +mpjpeg->searchstr = av_strdup("\r\n--");
> +}
>  mpjpeg->searchstr_len = strlen(mpjpeg->searchstr);
>  if (!mpjpeg->boundary || !mpjpeg->searchstr) {
>  av_freep(>boundary);
> @@ -315,6 +365,22 @@ static int mpjpeg_read_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  return ret;
>  }
>  
> +#define OFFSET(x) offsetof(MPJPEGDemuxContext, x)
> +
> +#define DEC AV_OPT_FLAG_DECODING_PARAM
> +const AVOption mpjpeg_options[] = {
> +{ "strict_mime_boundary",  "require MIME boundaries match", 
> OFFSET(strict_mime_boundary), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, DEC },
> +{ NULL }
> +};
> +
> +

> +static const AVClass ff_mpjpeg_demuxer_class = {

there should be no ff_ as its static


> +.class_name = "MPJPEG demuxer",
> +.item_name  = av_default_item_name,
> +.option = mpjpeg_options,
> +.version= LIBAVUTIL_VERSION_INT,
> +};
> +
>  AVInputFormat ff_mpjpeg_demuxer = {
>  .name  = "mpjpeg",
>  .long_name = NULL_IF_CONFIG_SMALL("MIME multipart JPEG"),
> @@ -324,5 +390,8 @@ AVInputFormat ff_mpjpeg_demuxer = {
>  .read_probe= mpjpeg_read_probe,
>  .read_header   = mpjpeg_read_header,
>  .read_packet   = mpjpeg_read_packet,
> -.read_close= mpjpeg_read_close
> +.read_close= mpjpeg_read_close,
> +.priv_class= _mpjpeg_demuxer_class
>  };
> +
> +
> -- 
> 2.4.9 (Apple Git-60)
> 

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


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible 

Re: [FFmpeg-devel] VS 2015 patch

[Bruce Dawson]

This would make ffmpeg fail on VS versions prior to VS 2013, for those
using the BUILD.gn file, which I assume is not many. It would be easy to
add additional conditionals for earlier versions, but if it's just for
Chromium then 2013/2015 is sufficient.

VS versions after 2015 will work automatically, which is why I did the
conditional as shown.

On Tue, Nov 24, 2015 at 4:01 PM, compn  wrote:

> On Tue, 24 Nov 2015 14:18:47 -0800
> Bruce Dawson  wrote:
>
> > The attached patch lets ffmpeg build with both VS 2013 and VS 2015.
> >
> > Comments?
> >
>
> not sure if ffmpeg is supporting VS 2010, but does this work on VS2010
> (or any other VS besides 2013/2015) after your changes?
>
> thanks
> -compn
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>



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

Re: [FFmpeg-devel] Include more developers in the voting committee [#3]

[Ricardo Constantino]

On 24 November 2015 at 23:40, compn  wrote:

> old developers have no right? is baptiste bad because he works on ffmbc?
> is roberto bad because he works on mplayer? are you bad because you work
> on mpv ? what makes a developer have rights or have no rights?
>
Most of those developers are not currently active in FFmpeg though. I
thought the point of the voting committee was that only active developers
with at least 50 commits in the last year were part of it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] git-howto: mention how to clone ffmpeg-web

[Andreas Cadhalpun]

Signed-off-by: Andreas Cadhalpun 
---
 doc/git-howto.texi | 8 
 1 file changed, 8 insertions(+)

diff --git a/doc/git-howto.texi b/doc/git-howto.texi
index bf37bcc..88b9926 100644
--- a/doc/git-howto.texi
+++ b/doc/git-howto.texi
@@ -65,6 +65,14 @@ git clone git@@source.ffmpeg.org:ffmpeg 
 This will put the FFmpeg sources into the directory @var{} and let
 you push back your changes to the remote repository.
 
+@example
+git clone gil@@ffmpeg.org:ffmpeg-web 
+@end example
+
+This will put the source of the FFmpeg website into the directory
+@var{} and let you push back your changes to the remote repository.
+(Note that @var{gil} is not a typo of @var{git}.)
+
 Make sure that you do not have Windows line endings in your checkouts,
 otherwise you may experience spurious compilation failures. One way to
 achieve this is to run
-- 
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] git-howto: mention how to clone ffmpeg-web

[compn]

On Wed, 25 Nov 2015 00:55:25 +0100
Andreas Cadhalpun  wrote:


> +@example
> +git clone gil@@ffmpeg.org:ffmpeg-web 
> +@end example
> +
> +This will put the source of the FFmpeg website into the directory
> +@var{} and let you push back your changes to the remote

patch lgtm

but ffmpeg-web repo has iirc limited write-access to only a few
developers currently , so possibly a note should be added about sending
patches? i'm not sure... its up to you.

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

Re: [FFmpeg-devel] [PATCH 2/5] concatdec: calculate duration early if outpoint is known

[Marton Balint]

On Sun, 22 Nov 2015, Nicolas George wrote:


Sorry, missed this reply.


In read_header, duration is only set if both inpoint and outpoint is set by
the user.

In open_file duration is set if outpoint is set by the user which is the
superset of the first case.


Ok, I think I was confused by the similar inpoint / file_inpoint field
names. At some point, renaming the second one to maybe ts_origin, or maybe
ts_delta (changing the logic a bit) would probably a good idea.


Agreed...



In the meantime, no objection to this patch.


Ok, thanks, applied.

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

Re: [FFmpeg-devel] [PATCH] git-howto: mention how to clone ffmpeg-web

[Andreas Cadhalpun]

On 25.11.2015 01:11, compn wrote:
> On Wed, 25 Nov 2015 00:55:25 +0100
> Andreas Cadhalpun  wrote:
> 
> 
>> +@example
>> +git clone gil@@ffmpeg.org:ffmpeg-web 
>> +@end example
>> +
>> +This will put the source of the FFmpeg website into the directory
>> +@var{} and let you push back your changes to the remote
> 
> patch lgtm
> 
> but ffmpeg-web repo has iirc limited write-access to only a few
> developers currently , so possibly a note should be added about sending
> patches? i'm not sure... its up to you.

I tried to add such a note, see attached patch.

Best regards,
Andreas

>From 423b0f91afdc07965d0b8a47e663afbe2d345fe7 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Wed, 25 Nov 2015 00:52:39 +0100
Subject: [PATCH] git-howto: mention how to clone ffmpeg-web

Signed-off-by: Andreas Cadhalpun 
---
 doc/git-howto.texi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/doc/git-howto.texi b/doc/git-howto.texi
index bf37bcc..e5e3c81 100644
--- a/doc/git-howto.texi
+++ b/doc/git-howto.texi
@@ -65,6 +65,21 @@ git clone git@@source.ffmpeg.org:ffmpeg 
 This will put the FFmpeg sources into the directory @var{} and let
 you push back your changes to the remote repository.
 
+@example
+git clone gil@@ffmpeg.org:ffmpeg-web 
+@end example
+
+This will put the source of the FFmpeg website into the directory
+@var{} and let you push back your changes to the remote repository.
+(Note that @var{gil} stands for GItoLite and is not a typo of @var{git}.)
+
+If you don't have write-access to the ffmpeg-web repository, you can
+create patches after making a read-only ffmpeg-web clone:
+
+@example
+git clone git://ffmpeg.org/ffmpeg-web 
+@end example
+
 Make sure that you do not have Windows line endings in your checkouts,
 otherwise you may experience spurious compilation failures. One way to
 achieve this is to run
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] web/download: point to the official Debian/Ubuntu packages

[Andreas Cadhalpun]

On 06.11.2015 20:45, Michael Niedermayer wrote:
> On Fri, Nov 06, 2015 at 08:18:39PM +0100, Andreas Cadhalpun wrote:
>>  download |   11 ++-
>>  1 file changed, 10 insertions(+), 1 deletion(-)
>> ab219d2ff4c6f57ec33c97deb649be0cc1d7b2f3  
>> 0001-web-download-point-to-the-official-Debian-Ubuntu-pac.patch
>> From 8b3c774fcce80fd0b5a457122aba79685fded71b Mon Sep 17 00:00:00 2001
>> From: Andreas Cadhalpun 
>> Date: Fri, 6 Nov 2015 20:15:09 +0100
>> Subject: [PATCH] web/download: point to the official Debian/Ubuntu packages
>>
>> Signed-off-by: Andreas Cadhalpun 
> 
> LGTM

Pushed.

Best regards,
Andreas

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

Re: [FFmpeg-devel] support for reading / writing encrypted MP4 files

[compn]

On Tue, 24 Nov 2015 12:10:43 +
Eran Kornblau  wrote:
> Before we start working on this feature, since we really prefer not
> to manage our own fork of the code, we wanted to check with you
> whether you will be willing to merge such a feature ? (assuming it
> conforms to the coding standards, naturally)

yes, we have support for encrypted wmv so there should be no problem.

try to reuse the crypt code from ffmpeg/libavutil/* where possible. or
consider adding whatever en/decrypt code you need, as we do not like to
use too many external libs.

the more communication you have with ffmpeg developers or the mailing
list, the less problems you will have when merging time happens.

you may also want to post any work in progress patches or do request
for comments on any ideas, so developers do not object about strange
api additions to the code.

feel free to ask any questions.

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

Re: [FFmpeg-devel] [PATCH]lavf/mxfdec: Set width to actual coded_width for AVCI50

[Tomas Härdin]

On Tue, 2015-11-24 at 12:02 +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch fixes ticket #5029.
> 
> Please comment, Carl Eugen

Looks simple enough, but (ab)using MXFCodecUL like that has a slight
stink to it. Can we perhaps rename the struct to something that signals
its more general use of mapping ULs to integers?

Another thing: don't we have some table like this for H.264 in MXF
already?

/Tomas


signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Allow mpjpeg demuxer to process MIME parts which do not include Content-Length header.

[Alex Agranovsky]

-- 
Alex Agranovsky
Sighthound, Inc
www.sighthound.com  

On November 24, 2015 at 12:36:30 PM, wm4 (nfx...@googlemail.com) wrote:

On Tue, 24 Nov 2015 11:39:07 -0500  
Alex Agranovsky  wrote:  

> On November 24, 2015 at 10:32:47 AM, wm4 (nfx...@googlemail.com) wrote:  
>  
> On Tue, 24 Nov 2015 00:16:06 -0500  
> Alex Agranovsky  wrote:  
>  
> > From a2a0b9e0da14b6e82aa783535ec1878c8ffbede0 Mon Sep 17 00:00:00 2001  
> > From: Alex Agranovsky   
> > Date: Tue, 24 Nov 2015 00:06:14 -0500  
> > Subject: [PATCH 1/2] Allow mpjpeg demuxer to process MIME parts which do 
> > not  
> > include Content-Length header.  
> >   
> > Fixes ticket 5023  
> >   
> > Signed-off-by: Alex Agranovsky   
> > ---  
> > libavformat/mpjpegdec.c | 176 
> >   
> > 1 file changed, 133 insertions(+), 43 deletions(-)  
> >   
> > diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c  
> > index 2749a48..e494f1a 100644  
> > --- a/libavformat/mpjpegdec.c  
> > +++ b/libavformat/mpjpegdec.c  
> > @@ -23,22 +23,16 @@  
> >    
> > #include "avformat.h"  
> > #include "internal.h"  
> > +#include "avio_internal.h"  
> >    
> > -static int get_line(AVIOContext *pb, char *line, int line_size)  
> > -{  
> > - int i = ff_get_line(pb, line, line_size);  
> >    
> > - if (i > 1 && line[i - 2] == '\r')  
> > - line[i - 2] = '\0';  
> >    
> > - if (pb->error)  
> > - return pb->error;  
> > -  
> > - if (pb->eof_reached)  
> > - return AVERROR_EOF;  
> > -  
> > - return 0;  
> > -}  
> > +/** Context for demuxing an MPJPEG stream. */  
>  
> This comment is really not needed.  
> Will be removed in follow up submission.  
>  
>  
>  
> > +typedef struct MPJPEGDemuxContext {  
> > + char* boundary;  
> > + char* searchstr;  
> > + int searchstr_len;  
> > +} MPJPEGDemuxContext;  
> >    
> >    
> > static void trim_right(char* p)  
> > @@ -46,13 +40,32 @@ static void trim_right(char* p)  
> > char *end;  
> > if (!p || !*p)  
> > return;  
> > - end = p + strlen(p) - 1;  
> > - while (end != p && av_isspace(*end)) {  
> > + int len = strlen(p);  
> > + if ( !len )  
> > + return;  
> > + end = p + len - 1;  
> > + while (end >= p && av_isspace(*end)) {  
>  
> Why this change? Note that strlen(p)>0 is already guaranteed by the  
> "!*p" check before.  
>  
>  
> Consider input of a single ‘\r’. It will never get trimmed with the old code. 
>  

I don't really see how most of the changes fix this case. The only  
change that does anything is replacing the != operator with >= . Which  
is invalid as I see just now: it would set end to p-1, which AFAIK is  
undefined behavior.  


Setting end to p-1 would force us to exit the loop, no? We’re just comparing 
two pointer values, without dereferencing them.
I do see that length check is redundant with !*p, so removing that.

> > *end = '\0'; 
> > end--; 
> > } 
> > } 
> >   
> > +static int get_line(AVIOContext *pb, char *line, int line_size) 
> > +{ 
> > + ff_get_line(pb, line, line_size); 
> > + 
> > + if (pb->error) 
> > + return pb->error; 
> > + 
> > + if (pb->eof_reached) 
> > + return AVERROR_EOF; 
> > + 
> > + trim_right(line); 
> > + return 0; 
> > +} 
> > + 
> > + 
> > + 
> > static int split_tag_value(char **tag, char **value, char *line) 
> > { 
> > char *p = line; 
> > @@ -86,12 +99,24 @@ static int split_tag_value(char **tag, char **value, 
> > char *line) 
> > return 0; 
> > } 
> >   
> > -static int parse_multipart_header(AVIOContext *pb, void *log_ctx); 
> > +static int parse_multipart_header(AVIOContext *pb, 
> > + int* size, 
> > + const char* expected_boundary, 
> > + void *log_ctx); 
> > + 
> > +static int mpjpeg_read_close(AVFormatContext *s) 
> > +{ 
> > + MPJPEGDemuxContext *mpjpeg = s->priv_data; 
> > + av_freep(>boundary); 
> > + av_freep(>searchstr); 
> > + return 0; 
> > +} 
> >   
> > static int mpjpeg_read_probe(AVProbeData *p) 
> > { 
> > AVIOContext *pb; 
> > int ret = 0; 
> > + int size = 0; 
> >   
> > if (p->buf_size < 2 || p->buf[0] != '-' || p->buf[1] != '-') 
> > return 0; 
> > @@ -100,7 +125,7 @@ static int mpjpeg_read_probe(AVProbeData *p) 
> > if (!pb) 
> > return 0; 
> >   
> > - ret = (parse_multipart_header(pb, NULL)>0)?AVPROBE_SCORE_MAX:0; 
> > + ret = ( parse_multipart_header(pb, , "--", NULL) > 0 ) ? 
> > AVPROBE_SCORE_MAX : 0;  
> 
> A stray space got in. 
> Parameters to parse_multipart_header had changed.  

Yes, but the 2 additional spaces after the ( and before the ) are not 
consistent with the rest of the coding style. (Though I admit the 
FFmpeg code has some consistency problems, e.g. the line you changed 
was missing some spaces.) 

While these cosmetic issues are not that important, I think at least 
some effort should be put into not making it look worse. 
Agreed. It takes effort, though, to switch to a specific project’s style, so I 
apologize for having to go through that.  I’ll 

[FFmpeg-devel] [PATCH] lavd/avfoundation: overhaul

[Thilo Borgmann]

Hi,

this patchset fixes most if not all bugs reported to trac for me.

I'm sorry but splitting it up into really distinct patches that can be
tested separately did not work out for me so there are some unrelated
lines within. Also, applying patch 1/3 does not work on its own...

However I split them up as good as I can for better reviewing.

1/3: This patch basically switches from a one-frame buffer to Apple's
buffer queues, which also voids the need for posix thread
synchronization. This avoids frame drops and duplications as good as
possible as well as async audio recording.
Also, the previous run-time approach to get the final recording formats
for audio and video has been replaced by respective format queries.
Last, support for (possibly padded) planar pixel formats is added.

2/3: The available audio formats can be now be listed and choosen by
their respective index.

3/3: Comments & reindentions.

Please comment!

-Thilo

p.s. I would appreciate if someone could test more exessively on iOS
what I cannot easily do...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/3] lavd/avfoundation: Switch from run-time approach for format detection to format query and Organize frame buffer in buffer queue.

[Thilo Borgmann]

From 852b7db7efd2de9409a578f2e19debd2cfaf2abd Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Mon, 23 Nov 2015 23:19:23 +0100
Subject: [PATCH 1/3] lavd/avfoundation: Switch from run-time approach for
 format detection to format query and Organize frame buffer in buffer queue.

This fixes tickets #4089, #4437, #4463 and #4513.
---
 libavdevice/avfoundation.m | 385 +++--
 1 file changed, 166 insertions(+), 219 deletions(-)

diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 763e675..37f6be0 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -26,6 +26,7 @@
  */
 
 #import 
+#import 
 #include 
 
 #include "libavutil/pixdesc.h"
@@ -82,14 +83,10 @@ typedef struct
 {
 AVClass*class;
 
-int frames_captured;
-int audio_frames_captured;
 int64_t first_pts;
 int64_t first_audio_pts;
-pthread_mutex_t frame_lock;
-pthread_cond_t  frame_wait_cond;
 id  avf_delegate;
-id  avf_audio_delegate;
+dispatch_queue_t dispatch_queue;
 
 AVRational  framerate;
 int width, height;
@@ -108,6 +105,8 @@ typedef struct
 
 int num_video_devices;
 
+AVCaptureDeviceFormat *audio_format;
+
 int audio_channels;
 int audio_bits_per_sample;
 int audio_float;
@@ -124,20 +123,9 @@ typedef struct
 AVCaptureSession *capture_session;
 AVCaptureVideoDataOutput *video_output;
 AVCaptureAudioDataOutput *audio_output;
-CMSampleBufferRef current_frame;
-CMSampleBufferRef current_audio_frame;
+CMBufferQueueRef frame_buffer;
 } AVFContext;
 
-static void lock_frames(AVFContext* ctx)
-{
-pthread_mutex_lock(>frame_lock);
-}
-
-static void unlock_frames(AVFContext* ctx)
-{
-pthread_mutex_unlock(>frame_lock);
-}
-
 /** FrameReciever class - delegate for AVCaptureSession
  */
 @interface AVFFrameReceiver : NSObject
@@ -167,65 +155,7 @@ static void unlock_frames(AVFContext* ctx)
   didOutputSampleBuffer:(CMSampleBufferRef)videoFrame
  fromConnection:(AVCaptureConnection *)connection
 {
-lock_frames(_context);
-
-if (_context->current_frame != nil) {
-CFRelease(_context->current_frame);
-}
-
-_context->current_frame = (CMSampleBufferRef)CFRetain(videoFrame);
-
-pthread_cond_signal(&_context->frame_wait_cond);
-
-unlock_frames(_context);
-
-++_context->frames_captured;
-}
-
-@end
-
-/** AudioReciever class - delegate for AVCaptureSession
- */
-@interface AVFAudioReceiver : NSObject
-{
-AVFContext* _context;
-}
-
-- (id)initWithContext:(AVFContext*)context;
-
-- (void)  captureOutput:(AVCaptureOutput *)captureOutput
-  didOutputSampleBuffer:(CMSampleBufferRef)audioFrame
- fromConnection:(AVCaptureConnection *)connection;
-
-@end
-
-@implementation AVFAudioReceiver
-
-- (id)initWithContext:(AVFContext*)context
-{
-if (self = [super init]) {
-_context = context;
-}
-return self;
-}
-
-- (void)  captureOutput:(AVCaptureOutput *)captureOutput
-  didOutputSampleBuffer:(CMSampleBufferRef)audioFrame
- fromConnection:(AVCaptureConnection *)connection
-{
-lock_frames(_context);
-
-if (_context->current_audio_frame != nil) {
-CFRelease(_context->current_audio_frame);
-}
-
-_context->current_audio_frame = (CMSampleBufferRef)CFRetain(audioFrame);
-
-pthread_cond_signal(&_context->frame_wait_cond);
-
-unlock_frames(_context);
-
-++_context->audio_frames_captured;
+CMBufferQueueEnqueue(_context->frame_buffer, videoFrame);
 }
 
 @end
@@ -238,22 +168,16 @@ static void destroy_context(AVFContext* ctx)
 [ctx->video_outputrelease];
 [ctx->audio_outputrelease];
 [ctx->avf_delegaterelease];
-[ctx->avf_audio_delegate release];
 
 ctx->capture_session = NULL;
 ctx->video_output= NULL;
 ctx->audio_output= NULL;
 ctx->avf_delegate= NULL;
-ctx->avf_audio_delegate = NULL;
 
 av_freep(>audio_buffer);
 
-pthread_mutex_destroy(>frame_lock);
-pthread_cond_destroy(>frame_wait_cond);
-
-if (ctx->current_frame) {
-CFRelease(ctx->current_frame);
-}
+CFRelease(ctx->frame_buffer);
+dispatch_release(ctx->dispatch_queue);
 }
 
 static void parse_device_name(AVFormatContext *s)
@@ -273,7 +197,7 @@ static void parse_device_name(AVFormatContext *s)
 /**
  * Configure the video device.
  *
- * Configure the video device using a run-time approach to access properties
+ * Configure the video device using format query to access properties
  * since formats, activeFormat are available since  iOS >= 7.0 or OSX >= 10.7
  * and activeVideoMaxFrameDuration is available since i0S >= 7.0 and OSX >= 
10.9.
  *
@@ -301,6 +225,8 @@ static int configure_video_device(AVFormatContext *s, 
AVCaptureDevice *video_dev
 

[FFmpeg-devel] [PATCH 2/3] lavd/avfoundation: Allow selection of audio format and list audio formats for specific devices.

[Thilo Borgmann]

From 735e26a0f525d94a31db56d4a25a3d15d021cca6 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Tue, 24 Nov 2015 19:01:55 +0100
Subject: [PATCH 2/3] lavd/avfoundation: Allow selection of audio format and
 list audio formats for specific devices.

---
 libavdevice/avfoundation.m | 150 ++---
 1 file changed, 115 insertions(+), 35 deletions(-)

diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 37f6be0..20341ef 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -95,10 +95,12 @@ typedef struct
 int capture_mouse_clicks;
 
 int list_devices;
+int list_audio_formats;
 int video_device_index;
 int video_stream_index;
 int audio_device_index;
 int audio_stream_index;
+int audio_format_index;
 
 char*video_filename;
 char*audio_filename;
@@ -109,11 +111,6 @@ typedef struct
 
 int audio_channels;
 int audio_bits_per_sample;
-int audio_float;
-int audio_be;
-int audio_signed_integer;
-int audio_packed;
-int audio_non_interleaved;
 
 int32_t *audio_buffer;
 int audio_buffer_size;
@@ -259,7 +256,7 @@ static int configure_video_device(AVFormatContext *s, 
AVCaptureDevice *video_dev
 [video_device setValue:min_frame_duration 
forKey:@"activeVideoMinFrameDuration"];
 [video_device setValue:min_frame_duration 
forKey:@"activeVideoMaxFrameDuration"];
 } else {
-av_log(s, AV_LOG_ERROR, "Could not lock device for configuration");
+av_log(s, AV_LOG_ERROR, "Could not lock video device for 
configuration");
 return AVERROR(EINVAL);
 }
 
@@ -333,8 +330,24 @@ static int add_video_device(AVFormatContext *s, 
AVCaptureDevice *video_device)
 }
 } @catch (NSException *exception) {
 if (![[exception name] isEqualToString:NSUndefinedKeyException]) {
-  av_log (s, AV_LOG_ERROR, "An error occurred: %s", [exception.reason 
UTF8String]);
-  return AVERROR_EXTERNAL;
+av_log (s, AV_LOG_ERROR, "An error occurred: %s", 
[exception.reason UTF8String]);
+return AVERROR_EXTERNAL;
+} else {
+// AVCaptureScreenInput does not contain formats property
+// get the screen dimensions using CoreGraphics and display id
+#if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
+uint32_t num_screens = 0;
+CGGetActiveDisplayList(0, NULL, _screens);
+if (ctx->video_device_index < ctx->num_video_devices + 
num_screens) {
+CGDirectDisplayID screens[num_screens];
+CGGetActiveDisplayList(num_screens, screens, _screens);
+int screen_idx = ctx->video_device_index - 
ctx->num_video_devices;
+CGDisplayModeRef mode = 
CGDisplayCopyDisplayMode(screens[screen_idx]);
+ctx->width  = CGDisplayModeGetWidth(mode);
+ctx->height = CGDisplayModeGetHeight(mode);
+CFRelease(mode);
+}
+#endif
 }
 }
 
@@ -440,6 +453,12 @@ static int add_audio_device(AVFormatContext *s, 
AVCaptureDevice *audio_device)
 
 [ctx->audio_output setSampleBufferDelegate:ctx->avf_delegate 
queue:ctx->dispatch_queue];
 
+if ([audio_device lockForConfiguration:NULL] == YES) {
+audio_device.activeFormat = ctx->audio_format;
+} else {
+av_log(s, AV_LOG_ERROR, "Could not lock audio device for 
configuration");
+return AVERROR(EINVAL);
+}
 
 if ([ctx->capture_session canAddOutput:ctx->audio_output]) {
 [ctx->capture_session addOutput:ctx->audio_output];
@@ -570,17 +589,15 @@ static int avf_read_header(AVFormatContext *s)
 AVFContext *ctx = (AVFContext*)s->priv_data;
 AVCaptureDevice *video_device = nil;
 AVCaptureDevice *audio_device = nil;
-// Find capture device
-NSArray *devices = [AVCaptureDevice devicesWithMediaType:AVMediaTypeVideo];
-ctx->num_video_devices = [devices count];
 
-ctx->first_pts  = av_gettime();
-ctx->first_audio_pts= av_gettime();
 // Create dispatch queue and set delegate
 CMBufferQueueCreate(kCFAllocatorDefault, 0, 
CMBufferQueueGetCallbacksForSampleBuffersSortedByOutputPTS(), 
>frame_buffer);
 ctx->avf_delegate   = [[AVFFrameReceiver alloc] initWithContext:ctx];
 ctx->dispatch_queue = dispatch_queue_create("org.ffmpeg.dispatch_queue", 
NULL);
 
+// Query video devices
+NSArray *devices   = [AVCaptureDevice 
devicesWithMediaType:AVMediaTypeVideo];
+ctx->num_video_devices = [devices count];
 
 #if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
 CGGetActiveDisplayList(0, NULL, _screens);
@@ -661,21 +678,19 @@ static 

[FFmpeg-devel] [PATCH 3/3] lavd/avfoundation: Reindentions and comment improvements.

[Thilo Borgmann]

From bcf7a6b966469902a080c4f52c4c091fa19c286c Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Tue, 24 Nov 2015 19:08:39 +0100
Subject: [PATCH 3/3] lavd/avfoundation: Reindentions and comment improvements.

---
 libavdevice/avfoundation.m | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 20341ef..8119820 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -206,9 +206,9 @@ static int configure_video_device(AVFormatContext *s, 
AVCaptureDevice *video_dev
 AVFContext *ctx = (AVFContext*)s->priv_data;
 
 double framerate = av_q2d(ctx->framerate);
-NSObject *range = nil;
+NSObject *range  = nil;
 NSObject *format = nil;
-NSObject *selected_range = nil;
+NSObject *selected_range  = nil;
 NSObject *selected_format = nil;
 
 for (format in [video_device valueForKey:@"formats"]) {
@@ -304,7 +304,7 @@ static int add_video_device(AVFormatContext *s, 
AVCaptureDevice *video_device)
 
 if (!capture_input) {
 av_log(s, AV_LOG_ERROR, "Failed to create AV capture input device: 
%s\n",
-   [[error localizedDescription] UTF8String]);
+[[error localizedDescription] UTF8String]);
 return 1;
 }
 
@@ -364,14 +364,14 @@ static int add_video_device(AVFormatContext *s, 
AVCaptureDevice *video_device)
 // check if selected pixel format is supported by AVFoundation
 if (pxl_fmt_spec.ff_id == AV_PIX_FMT_NONE) {
 av_log(s, AV_LOG_ERROR, "Selected pixel format (%s) is not supported 
by AVFoundation.\n",
-   av_get_pix_fmt_name(pxl_fmt_spec.ff_id));
+av_get_pix_fmt_name(pxl_fmt_spec.ff_id));
 return 1;
 }
 
 // check if the pixel format is available for this device
 if ([[ctx->video_output availableVideoCVPixelFormatTypes] 
indexOfObject:[NSNumber numberWithInt:pxl_fmt_spec.avf_id]] == NSNotFound) {
 av_log(s, AV_LOG_ERROR, "Selected pixel format (%s) is not supported 
by the input device.\n",
-   av_get_pix_fmt_name(pxl_fmt_spec.ff_id));
+av_get_pix_fmt_name(pxl_fmt_spec.ff_id));
 
 pxl_fmt_spec.ff_id = AV_PIX_FMT_NONE;
 
@@ -405,10 +405,10 @@ static int add_video_device(AVFormatContext *s, 
AVCaptureDevice *video_device)
 }
 }
 
-ctx->pixel_format  = pxl_fmt_spec.ff_id;
-pixel_format = [NSNumber numberWithUnsignedInt:pxl_fmt_spec.avf_id];
-capture_dict = [NSDictionary dictionaryWithObject:pixel_format
-   
forKey:(id)kCVPixelBufferPixelFormatTypeKey];
+ctx->pixel_format = pxl_fmt_spec.ff_id;
+pixel_format  = [NSNumber numberWithUnsignedInt:pxl_fmt_spec.avf_id];
+capture_dict  = [NSDictionary dictionaryWithObject:pixel_format
+  
forKey:(id)kCVPixelBufferPixelFormatTypeKey];
 
 [ctx->video_output setVideoSettings:capture_dict];
 [ctx->video_output setAlwaysDiscardsLateVideoFrames:YES];
@@ -432,7 +432,7 @@ static int add_audio_device(AVFormatContext *s, 
AVCaptureDevice *audio_device)
 
 if (!audio_dev_input) {
 av_log(s, AV_LOG_ERROR, "Failed to create AV capture input device: 
%s\n",
-   [[error localizedDescription] UTF8String]);
+[[error localizedDescription] UTF8String]);
 return 1;
 }
 
@@ -644,6 +644,7 @@ static int avf_read_header(AVFormatContext *s)
 sscanf(ctx->audio_filename, "%d", >audio_device_index);
 }
 
+// select video device by index
 if (ctx->video_device_index >= 0) {
 if (ctx->video_device_index < ctx->num_video_devices) {
 video_device = [devices objectAtIndex:ctx->video_device_index];
@@ -729,7 +730,7 @@ static int avf_read_header(AVFormatContext *s)
 }
 }
 
-// get audio device
+// select audio device by index
 if (ctx->audio_device_index >= 0) {
 NSArray *devices = [AVCaptureDevice 
devicesWithMediaType:AVMediaTypeAudio];
 
-- 
2.3.2 (Apple Git-55)

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

Re: [FFmpeg-devel] [PATCH 2/3] lavd/avfoundation: Allow selection of audio format and list audio formats for specific devices.

[Thilo Borgmann]

p.s. I will add documentaion for this when applying it...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] support for reading / writing encrypted MP4 files

[Paul B Mahol]

On 11/24/15, Eran Kornblau  wrote:
> Hi all,
>
> We're thinking about adding support for MP4 files encrypted using the CENC
> scheme to ffmpeg (such as the ones supported by GPAC -
> https://gpac.wp.mines-telecom.fr/mp4box/encryption/common-encryption/)
> The motivation is to be able to transcode files without having the media
> ever resident in the clear on disk (some of our customers have
> security regulations that forbid that).
>
> We'll probably add to movenc.c a parameter of encryption-scheme, supporting
> only the value cenc for now, and another parameter
> that will contain the encryption key.
> Similarly, mov.c will be added a parameter of encryption-key to enable
> reading encrypted MP4s.
> At first phase, only AAC / AVC codecs will be supported (this change is not
> codec agnostic since for AVC for example, the contents
> of the NAL units is encrypted, while the NAL size + type are not)
>
> Before we start working on this feature, since we really prefer not to
> manage our own fork of the code, we wanted to check with you
> whether you will be willing to merge such a feature ?
> (assuming it conforms to the coding standards, naturally)

If implementation is clean and does not break what was already working why not?

>
> Thank you
>
> Eran
>
> ___
> 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] Fix sample_aspect_ratio computation for stereo matroska content.

[Kirill Gavrilov]

On Mon, Nov 23, 2015 at 11:37 PM, Aaron Colwell  wrote:

> matroskaenc.c applies divisors to the display width/height when generating
> stereo content. This patch adds the corresponding multipliers to
> matroskadec.c
> so that the original sample aspect ratio can be recovered.


Just to link this patch with Matroska Specification notes:
http://www.matroska.org/technical/specs/notes.html#3D

> The pixel count of the track (PixelWidth/PixelHeight) should be the raw
> amount of pixels (for example 3840x1080 for full HD side by side)
> and the DisplayWidth/Height in pixels should be the amount of pixels for
> one plane (1920x1080 for that full HD stream).
>

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

[FFmpeg-devel] [PATCHv2] avfilter/vsrc_mandelbrot: avoid sqrt for epsilon calculation

[Ganesh Ajjanagadde]

This rewrites into a similar expression avoiding sqrt. Similarity is
assured since sqrt(x^2 + y^2)/(x+y) lies in [1/sqrt(2), 1] for x, y > 0.

Tested on x86-64, Haswell, GNU/Linux.
Command:
ffmpeg -f lavfi -i mandelbrot -f null -

old (draw_mandelbrot):
277625266 decicycles in draw_mandelbrot, 256 runs,  0 skips
304527322 decicycles in draw_mandelbrot, 512 runs,  0 skips
377593582 decicycles in draw_mandelbrot,1024 runs,  0 skips
338539499 decicycles in draw_mandelbrot,2048 runs,  0 skips
583630357 decicycles in draw_mandelbrot,4096 runs,  0 skips

new (draw_mandelbrot):
274635709 decicycles in draw_mandelbrot, 256 runs,  0 skips
300287046 decicycles in draw_mandelbrot, 512 runs,  0 skips
371819935 decicycles in draw_mandelbrot,1024 runs,  0 skips
336663765 decicycles in draw_mandelbrot,2048 runs,  0 skips
581851016 decicycles in draw_mandelbrot,4096 runs,  0 skips

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

diff --git a/libavfilter/vsrc_mandelbrot.c b/libavfilter/vsrc_mandelbrot.c
index bdcad25..6ba8c59 100644
--- a/libavfilter/vsrc_mandelbrot.c
+++ b/libavfilter/vsrc_mandelbrot.c
@@ -291,7 +291,7 @@ static void draw_mandelbrot(AVFilterContext *ctx, uint32_t 
*color, int linesize,
 
 use_zyklus= (x==0 || s->inner!=BLACK ||color[x-1 + y*linesize] == 
0xFF00);
 if(use_zyklus)
-epsilon= scale*1*sqrt(SQR(x-s->w/2) + SQR(y-s->h/2))/s->w;
+epsilon= scale*(abs(x-s->w/2) + abs(y-s->h/2))/s->w;
 
 #define Z_Z2_C(outr,outi,inr,ini)\
 outr= inr*inr - ini*ini + cr;\
-- 
2.6.2

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

[FFmpeg-devel] support for reading / writing encrypted MP4 files

[Eran Kornblau]

Hi all,

We're thinking about adding support for MP4 files encrypted using the CENC 
scheme to ffmpeg (such as the ones supported by GPAC -
https://gpac.wp.mines-telecom.fr/mp4box/encryption/common-encryption/)
The motivation is to be able to transcode files without having the media ever 
resident in the clear on disk (some of our customers have
security regulations that forbid that).

We'll probably add to movenc.c a parameter of encryption-scheme, supporting 
only the value cenc for now, and another parameter
that will contain the encryption key.
Similarly, mov.c will be added a parameter of encryption-key to enable reading 
encrypted MP4s.
At first phase, only AAC / AVC codecs will be supported (this change is not 
codec agnostic since for AVC for example, the contents
of the NAL units is encrypted, while the NAL size + type are not)

Before we start working on this feature, since we really prefer not to manage 
our own fork of the code, we wanted to check with you
whether you will be willing to merge such a feature ?
(assuming it conforms to the coding standards, naturally)

Thank you

Eran

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

Re: [FFmpeg-devel] [PATCH] avutil/WIP: add AVAsync API

[Clément Bœsch]

On Fri, Nov 13, 2015 at 03:57:22PM +0100, Nicolas George wrote:
> Le primidi 21 brumaire, an CCXXIV, Clement Boesch a écrit :
> > You construct something like this:
> > 
> >   AVAsyncContext(
> > AVAsyncReader(
> >   AVAsyncDecoder(...),
> >   AVAsyncDecoder(...),
> >   AVAsyncDecoder(...),
> >   ...
> > ),
> > AVAsyncReader(
> >   AVAsyncDecoder(...),
> >   AVAsyncDecoder(...),
> >   ...
> > ),
> > 
> >   )
> 
> Is there a specific reason you use a different type for decoders and
> readers? If I understand correctly, readers would be demuxers, and
> basically, if you look from high enough, demuxers and decoders are basically
> the same.
> 

Not sure I understand what you mean. It's important to have a threading
separation between the two for the sole reason of performance. Yes,
readers are demuxers in this simple model; one reader for N decoders.

[...]
> > - first, in threadmessage it seems I can't yet flush the fifo properly
> >   (for example by calling av_frame_free() on each entry of the frame
> >   queue): should I extend the API? Nicolas, maybe you have a suggestion?
> 
> Not really. IIUC, you need a function for the sender to tell "all queued
> messages are useless, discard them"? Or maybe more generic out-of-band /
> prioritized messages?

No idea what would be appropriate; I just need a way to drain the demuxer
and decoder queues, which contain AVFrame and AVPacket that needs to be
free'd properly.

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] Allow mpjpeg demuxer to process MIME parts which do not include Content-Length header.

[Alex Agranovsky]

On November 24, 2015 at 10:32:47 AM, wm4 (nfx...@googlemail.com) wrote:

On Tue, 24 Nov 2015 00:16:06 -0500
Alex Agranovsky  wrote:

> From a2a0b9e0da14b6e82aa783535ec1878c8ffbede0 Mon Sep 17 00:00:00 2001
> From: Alex Agranovsky 
> Date: Tue, 24 Nov 2015 00:06:14 -0500
> Subject: [PATCH 1/2] Allow mpjpeg demuxer to process MIME parts which do not
> include Content-Length header.
> 
> Fixes ticket 5023
> 
> Signed-off-by: Alex Agranovsky 
> ---
> libavformat/mpjpegdec.c | 176 
> 1 file changed, 133 insertions(+), 43 deletions(-)
> 
> diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
> index 2749a48..e494f1a 100644
> --- a/libavformat/mpjpegdec.c
> +++ b/libavformat/mpjpegdec.c
> @@ -23,22 +23,16 @@
>  
> #include "avformat.h"
> #include "internal.h"
> +#include "avio_internal.h"
>  
> -static int get_line(AVIOContext *pb, char *line, int line_size)
> -{
> - int i = ff_get_line(pb, line, line_size);
>  
> - if (i > 1 && line[i - 2] == '\r')
> - line[i - 2] = '\0';
>  
> - if (pb->error)
> - return pb->error;
> -
> - if (pb->eof_reached)
> - return AVERROR_EOF;
> -
> - return 0;
> -}
> +/** Context for demuxing an MPJPEG stream. */

This comment is really not needed.
Will be removed in follow up submission.



> +typedef struct MPJPEGDemuxContext {
> + char* boundary;
> + char* searchstr;
> + int searchstr_len;
> +} MPJPEGDemuxContext;
>  
>  
> static void trim_right(char* p)
> @@ -46,13 +40,32 @@ static void trim_right(char* p)
> char *end;
> if (!p || !*p)
> return;
> - end = p + strlen(p) - 1;
> - while (end != p && av_isspace(*end)) {
> + int len = strlen(p);
> + if ( !len )
> + return;
> + end = p + len - 1;
> + while (end >= p && av_isspace(*end)) {

Why this change? Note that strlen(p)>0 is already guaranteed by the
"!*p" check before.


Consider input of a single ‘\r’. It will never get trimmed with the old code.

> *end = '\0';
> end--;
> }
> }
>  
> +static int get_line(AVIOContext *pb, char *line, int line_size)
> +{
> + ff_get_line(pb, line, line_size);
> +
> + if (pb->error)
> + return pb->error;
> +
> + if (pb->eof_reached)
> + return AVERROR_EOF;
> +
> + trim_right(line);
> + return 0;
> +}
> +
> +
> +
> static int split_tag_value(char **tag, char **value, char *line)
> {
> char *p = line;
> @@ -86,12 +99,24 @@ static int split_tag_value(char **tag, char **value, char 
> *line)
> return 0;
> }
>  
> -static int parse_multipart_header(AVIOContext *pb, void *log_ctx);
> +static int parse_multipart_header(AVIOContext *pb,
> + int* size,
> + const char* expected_boundary,
> + void *log_ctx);
> +
> +static int mpjpeg_read_close(AVFormatContext *s)
> +{
> + MPJPEGDemuxContext *mpjpeg = s->priv_data;
> + av_freep(>boundary);
> + av_freep(>searchstr);
> + return 0;
> +}
>  
> static int mpjpeg_read_probe(AVProbeData *p)
> {
> AVIOContext *pb;
> int ret = 0;
> + int size = 0;
>  
> if (p->buf_size < 2 || p->buf[0] != '-' || p->buf[1] != '-')
> return 0;
> @@ -100,7 +125,7 @@ static int mpjpeg_read_probe(AVProbeData *p)
> if (!pb)
> return 0;
>  
> - ret = (parse_multipart_header(pb, NULL)>0)?AVPROBE_SCORE_MAX:0;
> + ret = ( parse_multipart_header(pb, , "--", NULL) > 0 ) ? 
> AVPROBE_SCORE_MAX : 0;

A stray space got in.
Parameters to parse_multipart_header had changed. 





>  
> av_free(pb);
>  
> @@ -110,17 +135,19 @@ static int mpjpeg_read_probe(AVProbeData *p)
> static int mpjpeg_read_header(AVFormatContext *s)
> {
> AVStream *st;
> - char boundary[70 + 2 + 1];
> + char boundary[70 + 2 + 1] = {0};
> int64_t pos = avio_tell(s->pb);
> int ret;
>  
> + do {
> + ret = get_line(s->pb, boundary, sizeof(boundary));
> + if (ret < 0)
> + return ret;
> + } while (!boundary[0]);
>  
> - ret = get_line(s->pb, boundary, sizeof(boundary));
> - if (ret < 0)
> - return ret;
> -

Can you explain why it suddenly has to skip multiple lines?
MIME standard, as old as it is, is poorly implemented by many camera 
manufacturers. In the last few weeks, I have seen things ranging from not 
sending a proper boundary, to not including a CRLF after a body part, to 
including multiples. When we process the headers, it is assumed body part had 
been consumed, and we need to get to the next non-empty lines. It is solving 
the same problem as 18f9308e6a96bbeb034ee5213a6d41e0b6c2ae74, just the other 
manifestation of it.





> - if (strncmp(boundary, "--", 2))
> + if (strncmp(boundary, "--", 2)) {
> return AVERROR_INVALIDDATA;
> + }

Another change that looks like a stray change.
Will remove in follow-up submission.



>  
> st = avformat_new_stream(s, NULL);
> if (!st)
> @@ -147,28 +174,44 @@ static int parse_content_length(const char *value)
> return val;
> }
>  
> -static int parse_multipart_header(AVIOContext *pb, void *log_ctx)
> +static int parse_multipart_header(AVIOContext *pb,
> + int* size,
> + const char* expected_boundary,
> + void *log_ctx)
> {
> char line[128];
> int found_content_type = 

[FFmpeg-devel] [PATCH] avfilter/vsrc_mandelbrot: change sin to sinf for color computation

[Ganesh Ajjanagadde]

lrintf is anyway used, suggesting we only care up to floating precision.
Rurthermore, there is a compat hack in avutil/libm for this function,
and it is used in avcodec/aacps_tablegen.h.

This yields a non-negligible speedup. Sample benchmark:
x86-64, Haswell, GNU/Linux:

old (draw_mandelbrot):
274635709 decicycles in draw_mandelbrot, 256 runs,  0 skips
300287046 decicycles in draw_mandelbrot, 512 runs,  0 skips
371819935 decicycles in draw_mandelbrot,1024 runs,  0 skips
336663765 decicycles in draw_mandelbrot,2048 runs,  0 skips
581851016 decicycles in draw_mandelbrot,4096 runs,  0 skips

new (draw_mandelbrot):
269882717 decicycles in draw_mandelbrot, 256 runs,  0 skips
296359285 decicycles in draw_mandelbrot, 512 runs,  0 skips
370076599 decicycles in draw_mandelbrot,1024 runs,  0 skips
331478354 decicycles in draw_mandelbrot,2048 runs,  0 skips
571904318 decicycles in draw_mandelbrot,4096 runs,  0 skips

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

diff --git a/libavfilter/vsrc_mandelbrot.c b/libavfilter/vsrc_mandelbrot.c
index 6ba8c59..6c210bb 100644
--- a/libavfilter/vsrc_mandelbrot.c
+++ b/libavfilter/vsrc_mandelbrot.c
@@ -334,11 +334,11 @@ static void draw_mandelbrot(AVFilterContext *ctx, 
uint32_t *color, int linesize,
 switch(s->outer){
 caseITERATION_COUNT:
 zr = i;
-c = lrintf((sin(zr)+1)*127) + 
lrintf((sin(zr/1.234)+1)*127)*256*256 + lrintf((sin(zr/100)+1)*127)*256;
+c = lrintf((sinf(zr)+1)*127) + 
lrintf((sinf(zr/1.234)+1)*127)*256*256 + lrintf((sinf(zr/100)+1)*127)*256;
 break;
 case NORMALIZED_ITERATION_COUNT:
 zr = i + log2(log(s->bailout) / log(zr*zr + 
zi*zi));
-c = lrintf((sin(zr)+1)*127) + 
lrintf((sin(zr/1.234)+1)*127)*256*256 + lrintf((sin(zr/100)+1)*127)*256;
+c = lrintf((sinf(zr)+1)*127) + 
lrintf((sinf(zr/1.234)+1)*127)*256*256 + lrintf((sinf(zr/100)+1)*127)*256;
 break;
 case  WHITE:
 c = 0xFF;
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] lavd/avfoundation: overhaul

[Clément Bœsch]

On Tue, Nov 24, 2015 at 07:27:57PM +0100, Thilo Borgmann wrote:
> Hi,
> 
> this patchset fixes most if not all bugs reported to trac for me.
> 

Thanks.

BTW, did you see
http://lists.libav.org/pipermail/libav-devel/2015-November/073162.html ?

Are you in contact with the author or something? Any idea how this is
going to be handled for the merge?

[...]

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCHv2] avfilter/vsrc_mandelbrot: avoid sqrt for epsilon calculation

[Michael Niedermayer]

On Tue, Nov 24, 2015 at 12:02:24PM -0500, Ganesh Ajjanagadde wrote:
> This rewrites into a similar expression avoiding sqrt. Similarity is
> assured since sqrt(x^2 + y^2)/(x+y) lies in [1/sqrt(2), 1] for x, y > 0.
> 
> Tested on x86-64, Haswell, GNU/Linux.
> Command:
> ffmpeg -f lavfi -i mandelbrot -f null -
> 
> old (draw_mandelbrot):
> 277625266 decicycles in draw_mandelbrot, 256 runs,  0 skips
> 304527322 decicycles in draw_mandelbrot, 512 runs,  0 skips
> 377593582 decicycles in draw_mandelbrot,1024 runs,  0 skips
> 338539499 decicycles in draw_mandelbrot,2048 runs,  0 skips
> 583630357 decicycles in draw_mandelbrot,4096 runs,  0 skips
> 
> new (draw_mandelbrot):
> 274635709 decicycles in draw_mandelbrot, 256 runs,  0 skips
> 300287046 decicycles in draw_mandelbrot, 512 runs,  0 skips
> 371819935 decicycles in draw_mandelbrot,1024 runs,  0 skips
> 336663765 decicycles in draw_mandelbrot,2048 runs,  0 skips
> 581851016 decicycles in draw_mandelbrot,4096 runs,  0 skips
> 
> Reviewed-by: Michael Niedermayer 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavfilter/vsrc_mandelbrot.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM

thx

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

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


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

Re: [FFmpeg-devel] [PATCH] avfilter/vsrc_mandelbrot: change sin to sinf for color computation

[Michael Niedermayer]

On Tue, Nov 24, 2015 at 01:05:20PM -0500, Ganesh Ajjanagadde wrote:
> lrintf is anyway used, suggesting we only care up to floating precision.
> Rurthermore, there is a compat hack in avutil/libm for this function,
> and it is used in avcodec/aacps_tablegen.h.
> 
> This yields a non-negligible speedup. Sample benchmark:
> x86-64, Haswell, GNU/Linux:
> 
> old (draw_mandelbrot):
> 274635709 decicycles in draw_mandelbrot, 256 runs,  0 skips
> 300287046 decicycles in draw_mandelbrot, 512 runs,  0 skips
> 371819935 decicycles in draw_mandelbrot,1024 runs,  0 skips
> 336663765 decicycles in draw_mandelbrot,2048 runs,  0 skips
> 581851016 decicycles in draw_mandelbrot,4096 runs,  0 skips
> 
> new (draw_mandelbrot):
> 269882717 decicycles in draw_mandelbrot, 256 runs,  0 skips
> 296359285 decicycles in draw_mandelbrot, 512 runs,  0 skips
> 370076599 decicycles in draw_mandelbrot,1024 runs,  0 skips
> 331478354 decicycles in draw_mandelbrot,2048 runs,  0 skips
> 571904318 decicycles in draw_mandelbrot,4096 runs,  0 skips
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavfilter/vsrc_mandelbrot.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

LGTM

thx

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

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


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

[FFmpeg-devel] [PATCH] web/download: remove architecture lists

[Andreas Cadhalpun]

They are not very helpful and feel out-of-place.

Suggested-by: Timothy Gu 
Signed-off-by: Andreas Cadhalpun 
---
 src/download | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/download b/src/download
index e870ea4..aa7daa2 100644
--- a/src/download
+++ b/src/download
@@ -55,23 +55,19 @@
 
   https://tracker.debian.org/pkg/ffmpeg;>
 Debian – Official packages for 
Stable-Backports, Testing, Unstable
-(amd64, arm64, armel, armhf, i386, kfreebsd-amd64, 
kfreebsd-i386, mips, mipsel, powerpc, ppc64el, s390x)
   
   http://www.deb-multimedia.org/;>
 Debian – deb-multimedia packages for 
Oldstable, Stable, Testing, Unstable
-(amd64, armel, armhf, i386, ia64, kfreebsd-amd64, 
kfreebsd-i386, mips, mipsel, powerpc, sparc)
   
   https://launchpad.net/ubuntu/+source/ffmpeg; 
class="list-group-item">
 Ubuntu – Official packages for Vivid, Wily, 
Xenial
-(amd64, arm64, armhf, i386, powerpc, ppc64el)
   
   https://launchpad.net/~mc3man/+archive/ubuntu/trusty-media; 
class="list-group-item">
 Ubuntu – Ubuntu Multimedia for Trusty PPA. 
Provides static binaries
 from most recent release branch.
-(amd64, i386)
   
   http://rpmfusion.org/;>
-Fedora and Red Hat Enterprise 
Linux packages (i386, x86_64)
+Fedora and Red Hat Enterprise 
Linux packages
   
  
 
-- 
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Include more developers in the voting committee [#3]

[compn]

On Tue, 24 Nov 2015 13:47:52 +0100
wm4  wrote:

> I don't think non-developers 

most of the list of people are developers of ffmpeg:

http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=togni
http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=Strasser
http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=Coudurier
http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=clement
http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=fabrice
http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=arpi
http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=kempf
http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=kieran
http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=logan
http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=reimar
http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=compn
http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=Nicholson

that leaves nikolay as the only one with zero commits (apologies if i
missed someone or someone's commits).

>(or developers not actively involved with
> FFmpeg) should have the right to vote on developer issues.

past developers dont have the right to vote on current developer
issues? why not?

old developers have no right? is baptiste bad because he works on ffmbc?
is roberto bad because he works on mplayer? are you bad because you work
on mpv ? what makes a developer have rights or have no rights?

help convince the fellow developers to your posit, wm4.

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

Re: [FFmpeg-devel] [PATCHv2] avutil/libm: correct isnan, isinf compat hacks

[Michael Niedermayer]

On Tue, Nov 24, 2015 at 09:17:18AM +0100, Hendrik Leppkes wrote:
> On Sat, Nov 21, 2015 at 2:53 PM, Ganesh Ajjanagadde  wrote:
> > On Wed, Nov 18, 2015 at 3:04 PM, Ganesh Ajjanagadde  
> > wrote:
> >> On Wed, Nov 18, 2015 at 2:58 PM, Michael Niedermayer  
> >> wrote:
> >>> On Tue, Nov 17, 2015 at 04:54:10PM -0500, Ganesh Ajjanagadde wrote:
>  isnan and isinf are actually macros as per the standard. In particular,
>  the existing implementation has incorrect signature. Furthermore, this
>  results in undefined behavior for e.g double values outside float range
>  as per the standard.
> 
>  This patch corrects the undefined behavior for all usage within FFmpeg.
> 
>  Note that long double is not handled as it is not used in FFmpeg.
>  Furthermore, even if at some point long double gets used, it is likely
>  not needed to modify the macro in practice for usage in FFmpeg. See
>  below for analysis.
> 
>  Getting long double to work strictly per the spec is significantly harder
>  since a long double may be an IEEE 128 bit quad (very rare), 80 bit
>  extended precision value (on GCC/Clang), or simply double (on recent 
>  Microsoft).
>  On the other hand, any potential future usage of long double is likely
>  for precision (when a platform offers extra precision) and not for 
>  range, since
>  the range anyway varies and is not as portable as IEEE 754 single/double
>  precision. In such cases, the implicit cast to a double is well defined
>  and isinf and isnan should work as intended.
> 
>  Reviewed-by: Michael Niedermayer 
>  Signed-off-by: Ganesh Ajjanagadde 
>  ---
>   libavutil/libm.h | 34 --
>   1 file changed, 32 insertions(+), 2 deletions(-)
> >>>
> >>> probably ok
> >>> maybe wait a day or 2 before pushing so people can test it on more
> >>> obscure platforms
> >>>
> >>> thx
> >>
> >> ok, will wait for 2 days for the hypot hack as well. Thanks.
> >
> > pushed, thanks
> >
> 
> nan/inf behavior on VS2012 seems to have broken with this (probably
> nan, but as the patch touches both..)
> Reverting this particular patch resolves the failures.
> 
> http://fate.ffmpeg.org/report.cgi?time=20151124040137=x86_32-msvc11-windows-native
> (ebur128 was broken before)

heres a patch to reproduce these failures on linux

diff --git a/libavutil/libm.h b/libavutil/libm.h
index 9e5ec5d..1669970 100644
--- a/libavutil/libm.h
+++ b/libavutil/libm.h
@@ -82,6 +82,7 @@ static av_always_inline float cbrtf(float x)
 #define exp2f(x) ((float)exp2(x))
 #endif /* HAVE_EXP2F */

+#define HAVE_ISINF 0
 #if !HAVE_ISINF
 #undef isinf
 /* Note: these do not follow the BSD/Apple/GNU convention of returning -1 for
@@ -109,6 +110,7 @@ static av_always_inline av_const int avpriv_isinf(double x)
 : avpriv_isinf(x))
 #endif /* HAVE_ISINF */

+#define HAVE_ISNAN 0
 #if !HAVE_ISNAN
 static av_always_inline av_const int avpriv_isnanf(float x)
 {


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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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

Re: [FFmpeg-devel] VS 2015 patch

[Bruce Dawson]

Interesting. I grabbed the code with:

git clone https://chromium.googlesource.com/chromium/third_party/ffmpeg

and that contains BUILD.gn as part of the repo. Is it possible that
BUILD.gn is part of the repo but is only used when it is part of Chromium?
That appears to be the case, in which case Chromium needs the patch landed
and it shouldn't affect anyone else.

On Tue, Nov 24, 2015 at 3:12 PM, Hendrik Leppkes 
wrote:

> On Tue, Nov 24, 2015 at 11:18 PM, Bruce Dawson 
> wrote:
> > I've been working on getting Chromium compiling with VS 2015 and there
> are
> > some tweaks needed to ffmpeg to get it working with gn. Currently the
> > BUILD.gn file defines five symbols/keywords that are missing from VS
> 2013's
> > C compiler, and defines _snprintf to make it safer. These defines are
> > illegal and do not work in VS 2015, , and they are not necessary because
> VS
> > 2015 supplies inline, snprintf, etc. These are the defines:
> >
> >   "inline=__inline",
> >   "strtoll=_strtoi64",
> >   "strtod=avpriv_strtod",
> >   "snprintf=avpriv_snprintf",
> >   "_snprintf=avpriv_snprintf",
> >   "vsnprintf=avpriv_vsnprintf",
> >
> > The attached patch lets ffmpeg build with both VS 2013 and VS 2015.
> >
> > Comments?
>
> FFmpeg builds with VS2015 out of the box today.
>
> BUILD.gn is not part of ffmpeg, so I suppose you send the patch to the
> wrong place.
>
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>



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

Re: [FFmpeg-devel] VS 2015 patch

[compn]

On Tue, 24 Nov 2015 14:18:47 -0800
Bruce Dawson  wrote:

> The attached patch lets ffmpeg build with both VS 2013 and VS 2015.
> 
> Comments?
> 

not sure if ffmpeg is supporting VS 2010, but does this work on VS2010
(or any other VS besides 2013/2015) after your changes?

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

Re: [FFmpeg-devel] [PATCHv2 5/5] lavfi/select: add support for concatdec_select option

[Marton Balint]

On Fri, 20 Nov 2015, Stefano Sabatini wrote:


On date Friday 2015-11-20 13:54:26 +0100, Marton Balint encoded:

This option can be used to select useful frames from an ffconcat file which is
using inpoints and outpoints but where the source files are not intra frame
only.

Signed-off-by: Marton Balint 
---
 doc/filters.texi   | 20 
 libavfilter/f_select.c | 27 +++
 2 files changed, 47 insertions(+)

diff --git a/doc/filters.texi b/doc/filters.texi
index 471ec3f..c886976 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -13196,6 +13196,19 @@ value between 0 and 1 to indicate a new scene; a low 
value reflects a low
 probability for the current frame to introduce a new scene, while a higher
 value means the current frame is more likely to be one (see the example below)

+@item concatdec_select
+The concat demuxer can set the @var{lavf.concat.start_time} and the
+@var{lavf.concat.duration} packet metadata values which are also present in the
+decoded frames.


Maybe here you could elaborate. Something like:

The concat demuxer can select only part of a concat input file by
setting an inpoint and an outpoint, but the output packets may not be
entirely contained in the selected interval. By using this variable,
it is possible to skip frames generated by the concat demuxer which
are not exactly contained in the selected interval.


+
+The @var{concatdec_select} variable is -1 if the frame pts is at least
+start_time and either the duration metadata is missing or the frame pts is less
+than start_time + duration, 0 otherwise, and NaN if the start_time metadata is
+missing.
+
+That basically means that an input frame is selected if its pts is within the
+interval set by the concat demuxer.

[...]

Looks good otherwise.


Thanks, applied with the proposed changes.

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

Re: [FFmpeg-devel] VS 2015 patch

[wm4]

On Tue, 24 Nov 2015 16:02:01 -0800
Bruce Dawson  wrote:

> Interesting. I grabbed the code with:
> 
> git clone https://chromium.googlesource.com/chromium/third_party/ffmpeg
> 
> and that contains BUILD.gn as part of the repo. Is it possible that
> BUILD.gn is part of the repo but is only used when it is part of Chromium?
> That appears to be the case, in which case Chromium needs the patch landed
> and it shouldn't affect anyone else.

Google tend to replace the build system of 3rd party dependencies, and
I suppose this is what happened here?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] VS 2015 patch

[Bruce Dawson]

Yes - the modifications to BUILD.gn seem to all be done by Google/Chromium
engineers.

When Chromium pulls in a third party dependency they sometimes but the
build files just outside of the copy of the third party repo, and this time
the build files got checked in to the upstream repo. I'm not sure why -
perhaps there were other gn based projects using ffmpeg.

On Tue, Nov 24, 2015 at 4:36 PM, wm4  wrote:

> On Tue, 24 Nov 2015 16:02:01 -0800
> Bruce Dawson  wrote:
>
> > Interesting. I grabbed the code with:
> >
> > git clone https://chromium.googlesource.com/chromium/third_party/ffmpeg
> >
> > and that contains BUILD.gn as part of the repo. Is it possible that
> > BUILD.gn is part of the repo but is only used when it is part of
> Chromium?
> > That appears to be the case, in which case Chromium needs the patch
> landed
> > and it shouldn't affect anyone else.
>
> Google tend to replace the build system of 3rd party dependencies, and
> I suppose this is what happened here?
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>



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

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

[Michael Niedermayer]

On Tue, Nov 24, 2015 at 01:18:20PM +0100, Paul B Mahol wrote:
> Subject: [PATCH] avfilter: add compensation delay line filter
> 
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi   |  42 
>  libavfilter/Makefile   |   1 +
>  libavfilter/af_compensationdelay.c | 196 
> +
>  libavfilter/allfilters.c   |   1 +
>  4 files changed, 240 insertions(+)
>  create mode 100644 libavfilter/af_compensationdelay.c
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index f351390..d8b2fb5 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -1628,6 +1628,48 @@
> compand=.1|.1:.1|.1:-45.1/-45.1|-45/-900|0/-900:.01:45:-90:.1
>  @end example
>  @end itemize
> 
> +@section compensationdelay
> +
> +Compensation Delay Line is a metric based delay to compensate differing
> +positions of microphones or speakers.
> +
> +For example, you have recorded guitar with two microphones placed in
> +different location. Because the front of sound wave has fixed speed in
> +normal conditions, the phasing of microphones can vary and depends on
> +their location and interposition. The best sound mix you will get when
> +these microphones are in phase (synchronized). Note that distance of
> +~30 cm between microphones makes one microphone to capture signal in
> +antiphase to another microphone. That makes the final mix sounding moody.
> +This filter helps to solve phasing problems by adding different delays
> +to each microphone track and make them synchronized.
> +
> +The best result can be reached when you take one track as base and
> +synchronize other tracks one by one with it.
> +Remember that synchronization/delay tolerance depends on sample rate, too.
> +Higher sample rates will give more tolerance.
> +
> +It accepts the following parameters:
> +
> +@table @option
> +@item mm
> +Set millimeters distance. This is compensation distance for fine tuning.
> +
> +@item cm
> +Set cm distance. This is compensation distance for tighten distance setup.
> +
> +@item m
> +Set meters distance. This is compensation distance for hard distance setup.
> +
> +@item dry
> +Set dry amount. Amount of unprocessed (dry) signal.
> +
> +@item wet
> +Set wet amount. Amount of processed (wet) signal.
> +
> +@item temp
> +Set temperature degree in Celzius. This is the temperature of the 
> environment.
> +@end table
> +
>  @section dcshift
>  Apply a DC shift to the audio.
> 
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 1f4abeb..c896374 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -64,6 +64,7 @@ OBJS-$(CONFIG_CHANNELMAP_FILTER) +=
> af_channelmap.o
>  OBJS-$(CONFIG_CHANNELSPLIT_FILTER)   += af_channelsplit.o
>  OBJS-$(CONFIG_CHORUS_FILTER) += af_chorus.o
> generate_wave_table.o
>  OBJS-$(CONFIG_COMPAND_FILTER)+= af_compand.o
> +OBJS-$(CONFIG_COMPENSATIONDELAY_FILTER)  += af_compensationdelay.o
>  OBJS-$(CONFIG_DCSHIFT_FILTER)+= af_dcshift.o
>  OBJS-$(CONFIG_DYNAUDNORM_FILTER) += af_dynaudnorm.o
>  OBJS-$(CONFIG_EARWAX_FILTER) += af_earwax.o
> diff --git a/libavfilter/af_compensationdelay.c
> b/libavfilter/af_compensationdelay.c
> new file mode 100644
> index 000..1a32879
> --- /dev/null
> +++ b/libavfilter/af_compensationdelay.c
> @@ -0,0 +1,196 @@
> +/*
> + * Copyright (c) 2001-2010 Krzysztof Foltman, Markus Schmidt, Thor
> Harald Johansen, Vladimir Sadovnikov and others
> + * 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/opt.h"
> +#include "libavutil/samplefmt.h"
> +#include "avfilter.h"
> +#include "audio.h"
> +#include "internal.h"
> +
> +typedef struct CompensationDelayContext {
> +const AVClass *class;
> +int distance_mm;
> +int distance_cm;
> +int distance_m;
> +double dry, wet;
> +int temp;
> +
> +unsigned delay;
> +unsigned w_ptr;
> +unsigned buf_size;
> +AVFrame *delay_frame;
> +} CompensationDelayContext;
> +
> +#define OFFSET(x) offsetof(CompensationDelayContext, x)
> +#define A AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
> +

[FFmpeg-devel] TrueHD Decoder fails on sample

[Marcus Johnson]

The sample is exactly 1 minute long, 48000hz sample rate, 24 bits per
sample, 8 channels. and all samples are set to 0xFF

here's the thd sample, and here's one of the 8 mono wavs (they're all
literally the same, I manually created the file in a hex editor and copied
it for all the others.)

the thd was created with Dolby Media Encoder Standalone Edition.

Input.mlp is what ffmpeg decodes, to Output.wav.

Original.wav is the file fed into Dolby Media Encode Standalone Edition

Here are the files:

Input.mlp: https://www.dropbox.com/s/fvh9lie1ofryws0/Input.mlp


Output.wav: https://www.dropbox.com/s/vjfjgv1vu11uci4/Output.wav


Original.wav: https://www.dropbox.com/s/8s5n5lv4qtvzysw/Original.wav
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[chcunningham]

From: Chris Cunningham 

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

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

Also, some re-ordering of the logic in mp3_seek to simplify and
give usetoc=1 precedence over fastseek flag.
---
 libavformat/mp3dec.c | 45 +++--
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 32ca00c..a1f21b7 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -115,7 +115,8 @@ static void read_xing_toc(AVFormatContext *s, int64_t 
filesize, int64_t duration
 {
 int i;
 MP3DecContext *mp3 = s->priv_data;
-int fill_index = mp3->usetoc == 1 && duration > 0;
+int fast_seek = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 0;
+int fill_index = (mp3->usetoc || fast_seek) && duration > 0;
 
 if (!filesize &&
 !(filesize = avio_size(s->pb))) {
@@ -344,9 +345,6 @@ static int mp3_read_header(AVFormatContext *s)
 int ret;
 int i;
 
-if (mp3->usetoc < 0)
-mp3->usetoc = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 2;
-
 st = avformat_new_stream(s, NULL);
 if (!st)
 return AVERROR(ENOMEM);
@@ -501,40 +499,43 @@ static int mp3_seek(AVFormatContext *s, int stream_index, 
int64_t timestamp,
 MP3DecContext *mp3 = s->priv_data;
 AVIndexEntry *ie, ie1;
 AVStream *st = s->streams[0];
-int64_t ret  = av_index_search_timestamp(st, timestamp, flags);
-int64_t best_pos;
 int fast_seek = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 0;
 int64_t filesize = mp3->header_filesize;
 
-if (mp3->usetoc == 2)
-return -1; // generic index code
-
 if (filesize <= 0) {
 int64_t size = avio_size(s->pb);
 if (size > 0 && size > s->internal->data_offset)
 filesize = size - s->internal->data_offset;
 }
 
-if (   (mp3->is_cbr || fast_seek)
-&& (mp3->usetoc == 0 || !mp3->xing_toc)
-&& st->duration > 0
-&& filesize > 0) {
-ie = 
-timestamp = av_clip64(timestamp, 0, st->duration);
-ie->timestamp = timestamp;
-ie->pos   = av_rescale(timestamp, filesize, st->duration) + 
s->internal->data_offset;
-} else if (mp3->xing_toc) {
+if (mp3->xing_toc && (mp3->usetoc || (fast_seek && !mp3->is_cbr))) {
+av_log(s, AV_LOG_ERROR, "XING seeking. filesize = %"PRId64"\n", 
filesize);
+// NOTE: The MP3 TOC is not a precise lookup table. The precision is
+// worse closer to the end of the file, especially for large files.
+// Seeking to 90% of duration in file of size 4M will be off by 
roughly 1 second.
+if (filesize > 400)
+av_log(s, AV_LOG_WARNING, "Using MP3 TOC to seek; may be 
imprecise.\n");
+
+int64_t ret  = av_index_search_timestamp(st, timestamp, flags);
 if (ret < 0)
 return ret;
 
 ie = >index_entries[ret];
+} else if (fast_seek && st->duration > 0 && filesize > 0) {
+if (!mp3->is_cbr)
+av_log(s, AV_LOG_WARNING, "Using scaling to seek VBR MP3; may be 
imprecise.\n");
+
+ie = 
+timestamp = av_clip64(timestamp, 0, st->duration);
+ie->timestamp = timestamp;
+ie->pos   = av_rescale(timestamp, filesize, st->duration) + 
s->internal->data_offset;
 } else {
-return -1;
+return -1; // generic index code
 }
 
-best_pos = mp3_sync(s, ie->pos, flags);
+int64_t best_pos = mp3_sync(s, ie->pos, flags);
 if (best_pos < 0)
-return best_pos;
+  return best_pos;
 
 if (mp3->is_cbr && ie ==  && mp3->frames) {
 int frame_duration = av_rescale(st->duration, 1, mp3->frames);
@@ -546,7 +547,7 @@ static int mp3_seek(AVFormatContext *s, int stream_index, 
int64_t timestamp,
 }
 
 static const AVOption options[] = {
-{ "usetoc", "use table of contents", offsetof(MP3DecContext, usetoc), 
AV_OPT_TYPE_INT, {.i64 = -1}, -1, 2, AV_OPT_FLAG_DECODING_PARAM},
+{ "usetoc", "use table of contents", offsetof(MP3DecContext, usetoc), 
AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM},
 { NULL },
 };
 
-- 
2.6.0.rc2.230.g3dd15c0

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

Re: [FFmpeg-devel] [PATCH 3/3] lavd/avfoundation: Reindentions and comment improvements.

[Michael Niedermayer]

On Tue, Nov 24, 2015 at 07:32:22PM +0100, Thilo Borgmann wrote:
> 

>  avfoundation.m |   23 ---
>  1 file changed, 12 insertions(+), 11 deletions(-)
> 82a547bdb47d2d38a2860d3c246345a0542fb2d6  
> 0003-lavd-avfoundation-Reindentions-and-comment-improveme.patch
> From bcf7a6b966469902a080c4f52c4c091fa19c286c Mon Sep 17 00:00:00 2001
> From: Thilo Borgmann 
> Date: Tue, 24 Nov 2015 19:08:39 +0100
> Subject: [PATCH 3/3] lavd/avfoundation: Reindentions and comment improvements.

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCHv2] avfilter/vsrc_mandelbrot: avoid sqrt for epsilon calculation

[Ganesh Ajjanagadde]

On Tue, Nov 24, 2015 at 2:28 PM, Michael Niedermayer  wrote:
> On Tue, Nov 24, 2015 at 12:02:24PM -0500, Ganesh Ajjanagadde wrote:
>> This rewrites into a similar expression avoiding sqrt. Similarity is
>> assured since sqrt(x^2 + y^2)/(x+y) lies in [1/sqrt(2), 1] for x, y > 0.
>>
>> Tested on x86-64, Haswell, GNU/Linux.
>> Command:
>> ffmpeg -f lavfi -i mandelbrot -f null -
>>
>> old (draw_mandelbrot):
>> 277625266 decicycles in draw_mandelbrot, 256 runs,  0 skips
>> 304527322 decicycles in draw_mandelbrot, 512 runs,  0 skips
>> 377593582 decicycles in draw_mandelbrot,1024 runs,  0 skips
>> 338539499 decicycles in draw_mandelbrot,2048 runs,  0 skips
>> 583630357 decicycles in draw_mandelbrot,4096 runs,  0 skips
>>
>> new (draw_mandelbrot):
>> 274635709 decicycles in draw_mandelbrot, 256 runs,  0 skips
>> 300287046 decicycles in draw_mandelbrot, 512 runs,  0 skips
>> 371819935 decicycles in draw_mandelbrot,1024 runs,  0 skips
>> 336663765 decicycles in draw_mandelbrot,2048 runs,  0 skips
>> 581851016 decicycles in draw_mandelbrot,4096 runs,  0 skips
>>
>> Reviewed-by: Michael Niedermayer 
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavfilter/vsrc_mandelbrot.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> LGTM
>
> thx

pushed, 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.
>
> ___
> 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/vsrc_mandelbrot: change sin to sinf for color computation

[Ganesh Ajjanagadde]

On Tue, Nov 24, 2015 at 2:28 PM, Michael Niedermayer  wrote:
> On Tue, Nov 24, 2015 at 01:05:20PM -0500, Ganesh Ajjanagadde wrote:
>> lrintf is anyway used, suggesting we only care up to floating precision.
>> Rurthermore, there is a compat hack in avutil/libm for this function,
>> and it is used in avcodec/aacps_tablegen.h.
>>
>> This yields a non-negligible speedup. Sample benchmark:
>> x86-64, Haswell, GNU/Linux:
>>
>> old (draw_mandelbrot):
>> 274635709 decicycles in draw_mandelbrot, 256 runs,  0 skips
>> 300287046 decicycles in draw_mandelbrot, 512 runs,  0 skips
>> 371819935 decicycles in draw_mandelbrot,1024 runs,  0 skips
>> 336663765 decicycles in draw_mandelbrot,2048 runs,  0 skips
>> 581851016 decicycles in draw_mandelbrot,4096 runs,  0 skips
>>
>> new (draw_mandelbrot):
>> 269882717 decicycles in draw_mandelbrot, 256 runs,  0 skips
>> 296359285 decicycles in draw_mandelbrot, 512 runs,  0 skips
>> 370076599 decicycles in draw_mandelbrot,1024 runs,  0 skips
>> 331478354 decicycles in draw_mandelbrot,2048 runs,  0 skips
>> 571904318 decicycles in draw_mandelbrot,4096 runs,  0 skips
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavfilter/vsrc_mandelbrot.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> LGTM
>
> thx

pushed, thanks.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In a rich man's house there is no place to spit but his face.
> -- Diogenes of Sinope
>
> ___
> 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 03/10] avcodec/aacps_tablegen: use hypot()

[Ganesh Ajjanagadde]

On Sun, Nov 22, 2015 at 6:59 PM, Rostislav Pehlivanov
 wrote:
> LGTM, feel free to apply.

pushed, thanks

>
> On Sun, 2015-11-22 at 12:05 -0500, Ganesh Ajjanagadde wrote:
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavcodec/aacps_tablegen.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/aacps_tablegen.h
>> b/libavcodec/aacps_tablegen.h
>> index ca1112d..0bd51cc 100644
>> --- a/libavcodec/aacps_tablegen.h
>> +++ b/libavcodec/aacps_tablegen.h
>> @@ -136,7 +136,7 @@ static av_cold void ps_tableinit(void)
>>  float pd2_im = ipdopd_sin[pd2];
>>  float re_smooth = 0.25f * pd0_re + 0.5f * pd1_re +
>> pd2_re;
>>  float im_smooth = 0.25f * pd0_im + 0.5f * pd1_im +
>> pd2_im;
>> -float pd_mag = 1 / sqrt(im_smooth * im_smooth +
>> re_smooth * re_smooth);
>> +float pd_mag = 1 / hypot(im_smooth, re_smooth);
>>  pd_re_smooth[pd0*64+pd1*8+pd2] = re_smooth * pd_mag;
>>  pd_im_smooth[pd0*64+pd1*8+pd2] = im_smooth * pd_mag;
>>  }
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2] avutil/libm: correct isnan, isinf compat hacks

[Ganesh Ajjanagadde]

On Tue, Nov 24, 2015 at 6:53 PM, Michael Niedermayer  wrote:
> On Tue, Nov 24, 2015 at 09:17:18AM +0100, Hendrik Leppkes wrote:
>> On Sat, Nov 21, 2015 at 2:53 PM, Ganesh Ajjanagadde  wrote:
>> > On Wed, Nov 18, 2015 at 3:04 PM, Ganesh Ajjanagadde  
>> > wrote:
>> >> On Wed, Nov 18, 2015 at 2:58 PM, Michael Niedermayer  
>> >> wrote:
>> >>> On Tue, Nov 17, 2015 at 04:54:10PM -0500, Ganesh Ajjanagadde wrote:
>>  isnan and isinf are actually macros as per the standard. In particular,
>>  the existing implementation has incorrect signature. Furthermore, this
>>  results in undefined behavior for e.g double values outside float range
>>  as per the standard.
>> 
>>  This patch corrects the undefined behavior for all usage within FFmpeg.
>> 
>>  Note that long double is not handled as it is not used in FFmpeg.
>>  Furthermore, even if at some point long double gets used, it is likely
>>  not needed to modify the macro in practice for usage in FFmpeg. See
>>  below for analysis.
>> 
>>  Getting long double to work strictly per the spec is significantly 
>>  harder
>>  since a long double may be an IEEE 128 bit quad (very rare), 80 bit
>>  extended precision value (on GCC/Clang), or simply double (on recent 
>>  Microsoft).
>>  On the other hand, any potential future usage of long double is likely
>>  for precision (when a platform offers extra precision) and not for 
>>  range, since
>>  the range anyway varies and is not as portable as IEEE 754 single/double
>>  precision. In such cases, the implicit cast to a double is well defined
>>  and isinf and isnan should work as intended.
>> 
>>  Reviewed-by: Michael Niedermayer 
>>  Signed-off-by: Ganesh Ajjanagadde 
>>  ---
>>   libavutil/libm.h | 34 --
>>   1 file changed, 32 insertions(+), 2 deletions(-)
>> >>>
>> >>> probably ok
>> >>> maybe wait a day or 2 before pushing so people can test it on more
>> >>> obscure platforms
>> >>>
>> >>> thx
>> >>
>> >> ok, will wait for 2 days for the hypot hack as well. Thanks.
>> >
>> > pushed, thanks
>> >
>>
>> nan/inf behavior on VS2012 seems to have broken with this (probably
>> nan, but as the patch touches both..)
>> Reverting this particular patch resolves the failures.
>>
>> http://fate.ffmpeg.org/report.cgi?time=20151124040137=x86_32-msvc11-windows-native
>> (ebur128 was broken before)
>
> heres a patch to reproduce these failures on linux
>
> diff --git a/libavutil/libm.h b/libavutil/libm.h
> index 9e5ec5d..1669970 100644
> --- a/libavutil/libm.h
> +++ b/libavutil/libm.h
> @@ -82,6 +82,7 @@ static av_always_inline float cbrtf(float x)
>  #define exp2f(x) ((float)exp2(x))
>  #endif /* HAVE_EXP2F */
>
> +#define HAVE_ISINF 0
>  #if !HAVE_ISINF
>  #undef isinf
>  /* Note: these do not follow the BSD/Apple/GNU convention of returning -1 for
> @@ -109,6 +110,7 @@ static av_always_inline av_const int avpriv_isinf(double 
> x)
>  : avpriv_isinf(x))
>  #endif /* HAVE_ISINF */
>
> +#define HAVE_ISNAN 0
>  #if !HAVE_ISNAN
>  static av_always_inline av_const int avpriv_isnanf(float x)
>  {

problem is with the isnan alone, reproduced and under investigation.

>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I am the wisest man alive, for I know one thing, and that is that I know
> nothing. -- Socrates
>
> ___
> 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] avformat/mp3dec: prefer "fast_seek" to TOC seek for CBR files.

[Chris Cunningham]

The new patch incorporates the "3 use-cases" feedback from wm4.

1. default: use generic (accurate but slow) seeking
2. fast: set -fflags fastseek to get fast accurate scaled seek for CBR, TOC
seek for VBR falling back to scaling if no TOC exists
3. custom: set -usetoc 1 to always use TOC for VBR & CBR. Will override
fastseek flag. This is very inaccurate for large files.

fastseek is really very close to generic seek for CBR files. for VBR its
pretty rough.

The fate-seek-extra-mp3 test is still failing. Its easy to fix, but I need
some guidance on what the test is supposed to focus on. It was originally
going through the av_rescale path of mp3_seek. With my patch it goes
through the return -1 (slow generic index) path. IIUC, the generic index
path is covered elsewhere (
https://github.com/FFmpeg/FFmpeg/blob/a62178be80dd6a643973f62002fc0ed42495c358/tests/fate-run.sh#L229).
I think I can restore the behavior of this test to use the av_rescale path
if I replace -usetoc 0 with -fflags fastseek (and update args parsing)...
is that what we want?

Thanks,
Chris

On Tue, Nov 24, 2015 at 4:55 PM,  wrote:

> From: Chris Cunningham 
>
> "Fast seek" uses linear interpolation to find the position of the
> requested seek time. For CBR this is more direct than using the
> mp3 TOC and bypassing the TOC avoids problems with TOC precision.
> (see https://crbug.com/545914#c13)
>
> For VBR, fast seek is not precise, so continue to prefer the TOC
> when available (the lesser of two evils).
>
> Also, some re-ordering of the logic in mp3_seek to simplify and
> give usetoc=1 precedence over fastseek flag.
> ---
>  libavformat/mp3dec.c | 45 +++--
>  1 file changed, 23 insertions(+), 22 deletions(-)
>
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index 32ca00c..a1f21b7 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -115,7 +115,8 @@ static void read_xing_toc(AVFormatContext *s, int64_t
> filesize, int64_t duration
>  {
>  int i;
>  MP3DecContext *mp3 = s->priv_data;
> -int fill_index = mp3->usetoc == 1 && duration > 0;
> +int fast_seek = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 0;
> +int fill_index = (mp3->usetoc || fast_seek) && duration > 0;
>
>  if (!filesize &&
>  !(filesize = avio_size(s->pb))) {
> @@ -344,9 +345,6 @@ static int mp3_read_header(AVFormatContext *s)
>  int ret;
>  int i;
>
> -if (mp3->usetoc < 0)
> -mp3->usetoc = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 2;
> -
>  st = avformat_new_stream(s, NULL);
>  if (!st)
>  return AVERROR(ENOMEM);
> @@ -501,40 +499,43 @@ static int mp3_seek(AVFormatContext *s, int
> stream_index, int64_t timestamp,
>  MP3DecContext *mp3 = s->priv_data;
>  AVIndexEntry *ie, ie1;
>  AVStream *st = s->streams[0];
> -int64_t ret  = av_index_search_timestamp(st, timestamp, flags);
> -int64_t best_pos;
>  int fast_seek = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 0;
>  int64_t filesize = mp3->header_filesize;
>
> -if (mp3->usetoc == 2)
> -return -1; // generic index code
> -
>  if (filesize <= 0) {
>  int64_t size = avio_size(s->pb);
>  if (size > 0 && size > s->internal->data_offset)
>  filesize = size - s->internal->data_offset;
>  }
>
> -if (   (mp3->is_cbr || fast_seek)
> -&& (mp3->usetoc == 0 || !mp3->xing_toc)
> -&& st->duration > 0
> -&& filesize > 0) {
> -ie = 
> -timestamp = av_clip64(timestamp, 0, st->duration);
> -ie->timestamp = timestamp;
> -ie->pos   = av_rescale(timestamp, filesize, st->duration) +
> s->internal->data_offset;
> -} else if (mp3->xing_toc) {
> +if (mp3->xing_toc && (mp3->usetoc || (fast_seek && !mp3->is_cbr))) {
> +av_log(s, AV_LOG_ERROR, "XING seeking. filesize = %"PRId64"\n",
> filesize);
> +// NOTE: The MP3 TOC is not a precise lookup table. The precision
> is
> +// worse closer to the end of the file, especially for large
> files.
> +// Seeking to 90% of duration in file of size 4M will be off by
> roughly 1 second.
> +if (filesize > 400)
> +av_log(s, AV_LOG_WARNING, "Using MP3 TOC to seek; may be
> imprecise.\n");
> +
> +int64_t ret  = av_index_search_timestamp(st, timestamp, flags);
>  if (ret < 0)
>  return ret;
>
>  ie = >index_entries[ret];
> +} else if (fast_seek && st->duration > 0 && filesize > 0) {
> +if (!mp3->is_cbr)
> +av_log(s, AV_LOG_WARNING, "Using scaling to seek VBR MP3; may
> be imprecise.\n");
> +
> +ie = 
> +timestamp = av_clip64(timestamp, 0, st->duration);
> +ie->timestamp = timestamp;
> +ie->pos   = av_rescale(timestamp, filesize, st->duration) +
> s->internal->data_offset;
>  } else {
> -return -1;
> +return -1; // generic index 

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

[Ganesh Ajjanagadde]

On Tue, Nov 24, 2015 at 7:18 AM, Paul B Mahol  wrote:
> Subject: [PATCH] avfilter: add compensation delay line filter
>
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi   |  42 
>  libavfilter/Makefile   |   1 +
>  libavfilter/af_compensationdelay.c | 196 
> +
>  libavfilter/allfilters.c   |   1 +
>  4 files changed, 240 insertions(+)
>  create mode 100644 libavfilter/af_compensationdelay.c
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index f351390..d8b2fb5 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -1628,6 +1628,48 @@
> compand=.1|.1:.1|.1:-45.1/-45.1|-45/-900|0/-900:.01:45:-90:.1
>  @end example
>  @end itemize
>
> +@section compensationdelay
> +
> +Compensation Delay Line is a metric based delay to compensate differing
> +positions of microphones or speakers.
> +
> +For example, you have recorded guitar with two microphones placed in
> +different location. Because the front of sound wave has fixed speed in
> +normal conditions, the phasing of microphones can vary and depends on
> +their location and interposition. The best sound mix you will get when
> +these microphones are in phase (synchronized). Note that distance of
> +~30 cm between microphones makes one microphone to capture signal in
> +antiphase to another microphone. That makes the final mix sounding moody.
> +This filter helps to solve phasing problems by adding different delays
> +to each microphone track and make them synchronized.
> +
> +The best result can be reached when you take one track as base and
> +synchronize other tracks one by one with it.
> +Remember that synchronization/delay tolerance depends on sample rate, too.
> +Higher sample rates will give more tolerance.
> +
> +It accepts the following parameters:
> +
> +@table @option
> +@item mm
> +Set millimeters distance. This is compensation distance for fine tuning.
> +
> +@item cm
> +Set cm distance. This is compensation distance for tighten distance setup.
> +
> +@item m
> +Set meters distance. This is compensation distance for hard distance setup.
> +
> +@item dry
> +Set dry amount. Amount of unprocessed (dry) signal.
> +
> +@item wet
> +Set wet amount. Amount of processed (wet) signal.
> +
> +@item temp
> +Set temperature degree in Celzius. This is the temperature of the 
> environment.
> +@end table
> +
>  @section dcshift
>  Apply a DC shift to the audio.
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 1f4abeb..c896374 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -64,6 +64,7 @@ OBJS-$(CONFIG_CHANNELMAP_FILTER) +=
> af_channelmap.o
>  OBJS-$(CONFIG_CHANNELSPLIT_FILTER)   += af_channelsplit.o
>  OBJS-$(CONFIG_CHORUS_FILTER) += af_chorus.o
> generate_wave_table.o
>  OBJS-$(CONFIG_COMPAND_FILTER)+= af_compand.o
> +OBJS-$(CONFIG_COMPENSATIONDELAY_FILTER)  += af_compensationdelay.o
>  OBJS-$(CONFIG_DCSHIFT_FILTER)+= af_dcshift.o
>  OBJS-$(CONFIG_DYNAUDNORM_FILTER) += af_dynaudnorm.o
>  OBJS-$(CONFIG_EARWAX_FILTER) += af_earwax.o
> diff --git a/libavfilter/af_compensationdelay.c
> b/libavfilter/af_compensationdelay.c
> new file mode 100644
> index 000..1a32879
> --- /dev/null
> +++ b/libavfilter/af_compensationdelay.c
> @@ -0,0 +1,196 @@
> +/*
> + * Copyright (c) 2001-2010 Krzysztof Foltman, Markus Schmidt, Thor
> Harald Johansen, Vladimir Sadovnikov and others
> + * 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/opt.h"
> +#include "libavutil/samplefmt.h"
> +#include "avfilter.h"
> +#include "audio.h"
> +#include "internal.h"
> +
> +typedef struct CompensationDelayContext {
> +const AVClass *class;
> +int distance_mm;
> +int distance_cm;
> +int distance_m;
> +double dry, wet;
> +int temp;
> +
> +unsigned delay;
> +unsigned w_ptr;
> +unsigned buf_size;
> +AVFrame *delay_frame;
> +} CompensationDelayContext;
> +
> +#define OFFSET(x) offsetof(CompensationDelayContext, x)
> +#define A 

Re: [FFmpeg-devel] [PATCH 1/2] lavu/utils: add av_parse_iso8601_tz; use it in time parsing functions

[Michael Niedermayer]

On Tue, Nov 10, 2015 at 11:20:42PM -0600, Rodger Combs wrote:
> ---
>  libavformat/utils.c| 20 
>  libavutil/parseutils.c | 43 +--
>  libavutil/parseutils.h | 18 +++---
>  3 files changed, 68 insertions(+), 13 deletions(-)

needs a update for version.h and APIChanges
otherwise should be ok

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

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


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

Re: [FFmpeg-devel] [PATCH 2/2] lavf/mov: strip com.apple.quicktime prefix in meta; parse creation date

[Michael Niedermayer]

On Tue, Nov 10, 2015 at 11:20:43PM -0600, Rodger Combs wrote:
> ---
>  libavformat/mov.c | 16 
>  1 file changed, 16 insertions(+)

probably ok

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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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

Re: [FFmpeg-devel] [PATCH] avutil/lls: speed up performance of solve_lls

[Michael Niedermayer]

On Tue, Nov 24, 2015 at 08:32:05PM -0500, Ganesh Ajjanagadde wrote:
> On Tue, Nov 24, 2015 at 8:19 PM, Michael Niedermayer  wrote:
> > On Mon, Nov 23, 2015 at 08:00:12PM -0500, Ganesh Ajjanagadde wrote:
> >> This is a trivial rewrite of the loops that results in better cache
> >> efficiency. Essentially, iterating backwards over an array is a bad
> >> idea, since it leads to many cache misses: forward iteration fetches a
> >> new cache line that gets subsequently used, while backwards iteration 
> >> fetches the
> >> cache line thinking that the indexing would move forwards (the common 
> >> behavior),
> >> resulting in many cache misses.
> >>
> >> Speedup is nontrivial. Benchmarks obtained by 10^6 iterations within
> >> solve_lls, with START/STOP_TIMER. File is 
> >> tests/data/fate/flac-16-lpc-cholesky.err.
> >> Hardware: x86-64, Haswell, GNU/Linux.
> >>
> >> new:
> >>   12598 decicycles in solve_lls, 2096871 runs,281 skips
> >>   12393 decicycles in solve_lls, 4193889 runs,415 skips
> >>   12250 decicycles in solve_lls, 8387253 runs,   1355 skips
> >>   12585 decicycles in solve_lls,16775089 runs,   2127 skips
> >>   12785 decicycles in solve_lls,33550272 runs,   4160 skips
> >>   12483 decicycles in solve_lls,67101734 runs,   7130 skips
> >>   12610 decicycles in solve_lls,134202614 runs,  15114 skips
> >>
> >> old:
> >>   18101 decicycles in solve_lls, 2096659 runs,493 skips
> >>   17850 decicycles in solve_lls, 4193609 runs,695 skips
> >>   17757 decicycles in solve_lls, 8387458 runs,   1150 skips
> >>   17746 decicycles in solve_lls,16775207 runs,   2009 skips
> >>   17906 decicycles in solve_lls,33550820 runs,   3612 skips
> >>   17931 decicycles in solve_lls,67102891 runs,   5973 skips
> >>   17907 decicycles in solve_lls,134206693 runs,  11035 skips
> >>
> >> ---
> >> Barring asm for this function, there are two (more interesting) potential
> >> optimizations for the Cholesky decomposition here:
> >> 1. Notice that update_lls is doing a rank one update of the matrix via the 
> >> var
> >> vector. Rank one update of the Cholesky decomposition can be done much more
> >> efficiently than a full blown decomposition, see e.g Wikipedia. This will 
> >> almost
> >> certainly require some API thought.
> >>
> >> 2. LDL' form of the Cholesky factorization offers 2 main advantages:
> >> a) Avoiding sqrt and its associated cost, trading it off with extra 
> >> multiplications.
> >> This may or may not be worth the computational cost, though it seems like 
> >> in
> >> FFmpeg, the Cholesky operates on small matrices of dim ~ 3-50, resulting in
> >> not too many extra multiplies.
> >> b) It provides benefits especially in the poorly conditioned
> >> case since one does not have to worry about nan's and associated tainting 
> >> due
> >> to the sqrt.
> >> This may or may not require API thought.
> >>
> >> I personally view 1 as being more unambiguously worthy of exploration at 
> >> this stage.
> >>
> >> Signed-off-by: Ganesh Ajjanagadde 
> >> ---
> >>  libavutil/lls.c | 6 +++---
> >>  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > this significantly changes the output for
> > libavutil/lls-test
> >
> > is that intended ?
> 
> Wait, I thought there was only one line changed in a diff between the
> old and new output, and it was trivial involving a nan. Maybe I posted
> the wrong patch, in which case sorry.

--- old 2015-11-25 02:15:20.396932045 +0100
+++ new 2015-11-25 02:15:26.620932176 +0100
@@ -2,299 +2,299 @@
 real:-0.828987 order:1 pred:-0.828987 var:0.00 coeffs:2.166433  0.00  
0.00
 real:-0.828987 order:2 pred:-0.828987 var:0.00 coeffs:2.166433  0.00  
0.00
 real:-0.326534 order:0 pred:-0.588792 var:0.272632 coeffs:1.427836 -0.385559  
0.00
-real:-0.326534 order:1 pred:-0.326534 var:-nan coeffs:3.274787 -1.436430  
0.00
-real:-0.326534 order:2 pred:-0.326534 var:-nan coeffs:3.274787 -1.436430  
0.00
+real:-0.326534 order:1 pred: 0.435087 var:0.734692 coeffs:1.427836 -1.436430  
0.00
+real:-0.326534 order:2 pred: 0.435087 var:0.734692 coeffs:1.427836 -1.436430  
0.00
 real:-0.496309 order:0 pred:-0.560478 var:0.227332 coeffs:1.343229 -0.128675 
-0.372131
-real:-0.496309 order:1 pred:-0.649268 var:0.214850 coeffs:1.541607 -0.245332  
0.00
-real:-0.496309 order:2 pred:-0.496309 var:0.00 coeffs:1.629421  0.626407 
-0.697480
+real:-0.496309 order:1 pred:-1.051144 var:0.444802 coeffs:2.504735 -0.245332  
0.00
+real:-0.496309 order:2 pred:-0.882916 var:0.272824 coeffs:2.504735 -0.245332 
-0.697480
 real: 0.386201 order:0 pred: 0.644642 var:0.263532 coeffs:1.005471 -0.232581 
-0.189366
-real: 0.386201 order:1 pred: 0.590550 var:0.236486 coeffs:1.416443 -0.420822  
0.00
-real: 0.386201 order:2 pred: 0.653364 var:0.216704 coeffs:1.417320 -0.084129 
-0.312548
+real: 0.386201 order:1 pred: 0.480672 var:0.250092 

Re: [FFmpeg-devel] [PATCH] avutil/lls: speed up performance of solve_lls

[Ganesh Ajjanagadde]

On Tue, Nov 24, 2015 at 8:19 PM, Michael Niedermayer  wrote:
> On Mon, Nov 23, 2015 at 08:00:12PM -0500, Ganesh Ajjanagadde wrote:
>> This is a trivial rewrite of the loops that results in better cache
>> efficiency. Essentially, iterating backwards over an array is a bad
>> idea, since it leads to many cache misses: forward iteration fetches a
>> new cache line that gets subsequently used, while backwards iteration 
>> fetches the
>> cache line thinking that the indexing would move forwards (the common 
>> behavior),
>> resulting in many cache misses.
>>
>> Speedup is nontrivial. Benchmarks obtained by 10^6 iterations within
>> solve_lls, with START/STOP_TIMER. File is 
>> tests/data/fate/flac-16-lpc-cholesky.err.
>> Hardware: x86-64, Haswell, GNU/Linux.
>>
>> new:
>>   12598 decicycles in solve_lls, 2096871 runs,281 skips
>>   12393 decicycles in solve_lls, 4193889 runs,415 skips
>>   12250 decicycles in solve_lls, 8387253 runs,   1355 skips
>>   12585 decicycles in solve_lls,16775089 runs,   2127 skips
>>   12785 decicycles in solve_lls,33550272 runs,   4160 skips
>>   12483 decicycles in solve_lls,67101734 runs,   7130 skips
>>   12610 decicycles in solve_lls,134202614 runs,  15114 skips
>>
>> old:
>>   18101 decicycles in solve_lls, 2096659 runs,493 skips
>>   17850 decicycles in solve_lls, 4193609 runs,695 skips
>>   17757 decicycles in solve_lls, 8387458 runs,   1150 skips
>>   17746 decicycles in solve_lls,16775207 runs,   2009 skips
>>   17906 decicycles in solve_lls,33550820 runs,   3612 skips
>>   17931 decicycles in solve_lls,67102891 runs,   5973 skips
>>   17907 decicycles in solve_lls,134206693 runs,  11035 skips
>>
>> ---
>> Barring asm for this function, there are two (more interesting) potential
>> optimizations for the Cholesky decomposition here:
>> 1. Notice that update_lls is doing a rank one update of the matrix via the 
>> var
>> vector. Rank one update of the Cholesky decomposition can be done much more
>> efficiently than a full blown decomposition, see e.g Wikipedia. This will 
>> almost
>> certainly require some API thought.
>>
>> 2. LDL' form of the Cholesky factorization offers 2 main advantages:
>> a) Avoiding sqrt and its associated cost, trading it off with extra 
>> multiplications.
>> This may or may not be worth the computational cost, though it seems like in
>> FFmpeg, the Cholesky operates on small matrices of dim ~ 3-50, resulting in
>> not too many extra multiplies.
>> b) It provides benefits especially in the poorly conditioned
>> case since one does not have to worry about nan's and associated tainting due
>> to the sqrt.
>> This may or may not require API thought.
>>
>> I personally view 1 as being more unambiguously worthy of exploration at 
>> this stage.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavutil/lls.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> this significantly changes the output for
> libavutil/lls-test
>
> is that intended ?

Wait, I thought there was only one line changed in a diff between the
old and new output, and it was trivial involving a nan. Maybe I posted
the wrong patch, in which case sorry.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I have often repented speaking, but never of holding my tongue.
> -- Xenocrates
>
> ___
> 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] lavc/ac3_parser: avoid zeroing codec parameters if we haven't parsed a frame

[Michael Niedermayer]

On Tue, Nov 24, 2015 at 03:23:17AM -0600, Rodger Combs wrote:
> This caused issues when seeking in some unusual MPEGTS files
> ---
>  libavcodec/aac_ac3_parser.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/aac_ac3_parser.c b/libavcodec/aac_ac3_parser.c
> index 2f7d568..b01d5a5 100644
> --- a/libavcodec/aac_ac3_parser.c
> +++ b/libavcodec/aac_ac3_parser.c
> @@ -34,6 +34,7 @@ int ff_aac_ac3_parse(AVCodecParserContext *s1,
>  ParseContext *pc = >pc;
>  int len, i;
>  int new_frame_start;
> +int got_frame = 0;
>  
>  get_next:
>  i=END_NOT_FOUND;
> @@ -51,6 +52,7 @@ get_next:
>  if(len<=0){
>  i=END_NOT_FOUND;
>  }else{
> +got_frame = 1;
>  s->state=0;
>  i-= s->header_size -1;
>  s->remaining_size = len;
> @@ -80,7 +82,7 @@ get_next:
> and total number of samples found in an AAC ADTS header are not
> reliable. Bit rate is still accurate because the total frame duration 
> in
> seconds is still correct (as is the number of bits in the frame). */
> -if (avctx->codec_id != AV_CODEC_ID_AAC) {
> +if (avctx->codec_id != AV_CODEC_ID_AAC && got_frame) {

is this not also needed for bitrate ?

and patch should be ok


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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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

Re: [FFmpeg-devel] [PATCH] web/download: remove architecture lists

[Timothy Gu]

On Wed, Nov 25, 2015 at 12:35:03AM +0100, Andreas Cadhalpun wrote:
> They are not very helpful and feel out-of-place.
> 
> Suggested-by: Timothy Gu 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  src/download | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)

LGTM.

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

Re: [FFmpeg-devel] [PATCH 4/8] avcodec/aacps_tablegen_template: replace #define by typedef

[Ganesh Ajjanagadde]

On Sat, Nov 21, 2015 at 5:58 PM, Ganesh Ajjanagadde
 wrote:
> On Thu, Nov 19, 2015 at 8:14 AM, Ganesh Ajjanagadde
>  wrote:
>>
>> See e.g 
>> https://stackoverflow.com/questions/1666353/are-typedef-and-define-the-same-in-c
>> for rationale.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavcodec/aacps_tablegen_template.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/aacps_tablegen_template.c 
>> b/libavcodec/aacps_tablegen_template.c
>> index e06ec91..341bd44 100644
>> --- a/libavcodec/aacps_tablegen_template.c
>> +++ b/libavcodec/aacps_tablegen_template.c
>> @@ -26,13 +26,13 @@
>>
>>  #if USE_FIXED
>>  #define TYPE_NAME "int32_t"
>> -#define INT32FLOAT int32_t
>> +typedef int32_t INT32FLOAT;
>>  #define ARRAY_RENAME(x) write_int32_t_ ## x
>>  #define ARRAY_URENAME(x) write_uint32_t_ ## x
>>  #include "aacps_fixed_tablegen.h"
>>  #else
>>  #define TYPE_NAME "float"
>> -#define INT32FLOAT float
>> +typedef float INT32FLOAT;
>>  #define ARRAY_RENAME(x) write_float_ ## x
>>  #define ARRAY_URENAME(x) write_float_ ## x
>>  #include "aacps_tablegen.h"
>> --
>> 2.6.2
>>
>
> ping for the aac maintainers

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

Re: [FFmpeg-devel] [PATCH] avutil/lls: speed up performance of solve_lls

[Michael Niedermayer]

On Mon, Nov 23, 2015 at 08:00:12PM -0500, Ganesh Ajjanagadde wrote:
> This is a trivial rewrite of the loops that results in better cache
> efficiency. Essentially, iterating backwards over an array is a bad
> idea, since it leads to many cache misses: forward iteration fetches a
> new cache line that gets subsequently used, while backwards iteration fetches 
> the
> cache line thinking that the indexing would move forwards (the common 
> behavior),
> resulting in many cache misses.
> 
> Speedup is nontrivial. Benchmarks obtained by 10^6 iterations within
> solve_lls, with START/STOP_TIMER. File is 
> tests/data/fate/flac-16-lpc-cholesky.err.
> Hardware: x86-64, Haswell, GNU/Linux.
> 
> new:
>   12598 decicycles in solve_lls, 2096871 runs,281 skips
>   12393 decicycles in solve_lls, 4193889 runs,415 skips
>   12250 decicycles in solve_lls, 8387253 runs,   1355 skips
>   12585 decicycles in solve_lls,16775089 runs,   2127 skips
>   12785 decicycles in solve_lls,33550272 runs,   4160 skips
>   12483 decicycles in solve_lls,67101734 runs,   7130 skips
>   12610 decicycles in solve_lls,134202614 runs,  15114 skips
> 
> old:
>   18101 decicycles in solve_lls, 2096659 runs,493 skips
>   17850 decicycles in solve_lls, 4193609 runs,695 skips
>   17757 decicycles in solve_lls, 8387458 runs,   1150 skips
>   17746 decicycles in solve_lls,16775207 runs,   2009 skips
>   17906 decicycles in solve_lls,33550820 runs,   3612 skips
>   17931 decicycles in solve_lls,67102891 runs,   5973 skips
>   17907 decicycles in solve_lls,134206693 runs,  11035 skips
> 
> ---
> Barring asm for this function, there are two (more interesting) potential
> optimizations for the Cholesky decomposition here:
> 1. Notice that update_lls is doing a rank one update of the matrix via the var
> vector. Rank one update of the Cholesky decomposition can be done much more
> efficiently than a full blown decomposition, see e.g Wikipedia. This will 
> almost
> certainly require some API thought.
> 
> 2. LDL' form of the Cholesky factorization offers 2 main advantages:
> a) Avoiding sqrt and its associated cost, trading it off with extra 
> multiplications.
> This may or may not be worth the computational cost, though it seems like in
> FFmpeg, the Cholesky operates on small matrices of dim ~ 3-50, resulting in
> not too many extra multiplies.
> b) It provides benefits especially in the poorly conditioned
> case since one does not have to worry about nan's and associated tainting due
> to the sqrt.
> This may or may not require API thought.
> 
> I personally view 1 as being more unambiguously worthy of exploration at this 
> stage.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/lls.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

this significantly changes the output for
libavutil/lls-test

is that intended ?

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

Re: [FFmpeg-devel] Include more developers in the voting committee [#3]

[Ganesh Ajjanagadde]

On Tue, Nov 24, 2015 at 6:40 PM, compn  wrote:
> On Tue, 24 Nov 2015 13:47:52 +0100
> wm4  wrote:
>
>> I don't think non-developers
>
> most of the list of people are developers of ffmpeg:
>
> http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=togni
> http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=Strasser
> http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=Coudurier
> http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=clement
> http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=fabrice
> http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=arpi
> http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=kempf
> http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=kieran
> http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=logan
> http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=reimar
> http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=compn
> http://git.videolan.org/?p=ffmpeg.git=search=HEAD=author=Nicholson
>
> that leaves nikolay as the only one with zero commits (apologies if i
> missed someone or someone's commits).
>
>>(or developers not actively involved with
>> FFmpeg) should have the right to vote on developer issues.
>
> past developers dont have the right to vote on current developer
> issues? why not?
>
> old developers have no right? is baptiste bad because he works on ffmbc?
> is roberto bad because he works on mplayer? are you bad because you work
> on mpv ? what makes a developer have rights or have no rights?
>
> help convince the fellow developers to your posit, wm4.

It is not that they are bad or anything, they have definitely done
fantastic work which I am pretty sure Ronald or wm4 agrees with. It is
just that they are not active, and hence do not offer much to the
developer decision process today. I think in practice Michael's
suggestion is fine as well: inactive but formerly active developers
will anyway not take part in these votes, so I don't mind either way.

On the other hand, it is also ok to simply not include at the moment,
and if a particular person wishes to be included, we can of course
include them by e.g a vote. Or put in other words, I don't think we
need to go out of the normal "50 commit" or whatever it is for these
other cases - other cases can be included pretty easily anyway.

>
> -compn
> ___
> 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/libm: correct isnan, isinf compat hacks

[Ganesh Ajjanagadde]

On Tue, Nov 24, 2015 at 8:48 PM, Ganesh Ajjanagadde  wrote:
> On Tue, Nov 24, 2015 at 6:53 PM, Michael Niedermayer  wrote:
>> On Tue, Nov 24, 2015 at 09:17:18AM +0100, Hendrik Leppkes wrote:
>>> On Sat, Nov 21, 2015 at 2:53 PM, Ganesh Ajjanagadde  
>>> wrote:
>>> > On Wed, Nov 18, 2015 at 3:04 PM, Ganesh Ajjanagadde  
>>> > wrote:
>>> >> On Wed, Nov 18, 2015 at 2:58 PM, Michael Niedermayer  
>>> >> wrote:
>>> >>> On Tue, Nov 17, 2015 at 04:54:10PM -0500, Ganesh Ajjanagadde wrote:
>>>  isnan and isinf are actually macros as per the standard. In particular,
>>>  the existing implementation has incorrect signature. Furthermore, this
>>>  results in undefined behavior for e.g double values outside float range
>>>  as per the standard.
>>> 
>>>  This patch corrects the undefined behavior for all usage within FFmpeg.
>>> 
>>>  Note that long double is not handled as it is not used in FFmpeg.
>>>  Furthermore, even if at some point long double gets used, it is likely
>>>  not needed to modify the macro in practice for usage in FFmpeg. See
>>>  below for analysis.
>>> 
>>>  Getting long double to work strictly per the spec is significantly 
>>>  harder
>>>  since a long double may be an IEEE 128 bit quad (very rare), 80 bit
>>>  extended precision value (on GCC/Clang), or simply double (on recent 
>>>  Microsoft).
>>>  On the other hand, any potential future usage of long double is likely
>>>  for precision (when a platform offers extra precision) and not for 
>>>  range, since
>>>  the range anyway varies and is not as portable as IEEE 754 
>>>  single/double
>>>  precision. In such cases, the implicit cast to a double is well defined
>>>  and isinf and isnan should work as intended.
>>> 
>>>  Reviewed-by: Michael Niedermayer 
>>>  Signed-off-by: Ganesh Ajjanagadde 
>>>  ---
>>>   libavutil/libm.h | 34 --
>>>   1 file changed, 32 insertions(+), 2 deletions(-)
>>> >>>
>>> >>> probably ok
>>> >>> maybe wait a day or 2 before pushing so people can test it on more
>>> >>> obscure platforms
>>> >>>
>>> >>> thx
>>> >>
>>> >> ok, will wait for 2 days for the hypot hack as well. Thanks.
>>> >
>>> > pushed, thanks
>>> >
>>>
>>> nan/inf behavior on VS2012 seems to have broken with this (probably
>>> nan, but as the patch touches both..)
>>> Reverting this particular patch resolves the failures.
>>>
>>> http://fate.ffmpeg.org/report.cgi?time=20151124040137=x86_32-msvc11-windows-native
>>> (ebur128 was broken before)
>>
>> heres a patch to reproduce these failures on linux
>>
>> diff --git a/libavutil/libm.h b/libavutil/libm.h
>> index 9e5ec5d..1669970 100644
>> --- a/libavutil/libm.h
>> +++ b/libavutil/libm.h
>> @@ -82,6 +82,7 @@ static av_always_inline float cbrtf(float x)
>>  #define exp2f(x) ((float)exp2(x))
>>  #endif /* HAVE_EXP2F */
>>
>> +#define HAVE_ISINF 0
>>  #if !HAVE_ISINF
>>  #undef isinf
>>  /* Note: these do not follow the BSD/Apple/GNU convention of returning -1 
>> for
>> @@ -109,6 +110,7 @@ static av_always_inline av_const int avpriv_isinf(double 
>> x)
>>  : avpriv_isinf(x))
>>  #endif /* HAVE_ISINF */
>>
>> +#define HAVE_ISNAN 0
>>  #if !HAVE_ISNAN
>>  static av_always_inline av_const int avpriv_isnanf(float x)
>>  {
>
> problem is with the isnan alone, reproduced and under investigation.

Analysis complete and it is due to implementation defined behavior of
the cast of the uint64_t result into int. Worked around with a hack:
basically add a && 1 at the return to guarantee returning of 0 or 1.
Tested with FATE on Michael's lines and pushed.
Apologies all for the breakage.

>
>>
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> I am the wisest man alive, for I know one thing, and that is that I know
>> nothing. -- Socrates
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/8] avcodec/aac_defines: replace #define by typedef

[Ganesh Ajjanagadde]

On Thu, Nov 19, 2015 at 8:14 AM, Ganesh Ajjanagadde
 wrote:
> See e.g 
> https://stackoverflow.com/questions/1666353/are-typedef-and-define-the-same-in-c
> for rationale.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/aac_defines.h | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/libavcodec/aac_defines.h b/libavcodec/aac_defines.h
> index 3c45742..eff63b3 100644
> --- a/libavcodec/aac_defines.h
> +++ b/libavcodec/aac_defines.h
> @@ -34,11 +34,11 @@
>
>  #define AAC_RENAME(x)   x ## _fixed
>  #define AAC_RENAME_32(x)x ## _fixed_32
> -#define INTFLOAT int
> -#define INT64FLOAT  int64_t
> -#define SHORTFLOAT int16_t
> -#define AAC_FLOAT SoftFloat
> -#define AAC_SIGNE   int
> +typedef int INTFLOAT;
> +typedef int64_t INT64FLOAT;
> +typedef int16_t SHORTFLOAT;
> +typedef SoftFloat   AAC_FLOAT;
> +typedef int AAC_SIGNE;
>  #define FIXR(a) ((int)((a) * 1 + 0.5))
>  #define FIXR10(a)   ((int)((a) * 1024.0 + 0.5))
>  #define Q23(a)  (int)((a) * 8388608.0 + 0.5)
> @@ -82,11 +82,11 @@
>
>  #define AAC_RENAME(x)   x
>  #define AAC_RENAME_32(x)x
> -#define INTFLOAT float
> -#define INT64FLOAT  float
> -#define SHORTFLOAT float
> -#define AAC_FLOAT float
> -#define AAC_SIGNE   unsigned
> +typedef float   INTFLOAT;
> +typedef float   INT64FLOAT;
> +typedef float   SHORTFLOAT;
> +typedef float   AAC_FLOAT;
> +typedef unsignedAAC_SIGNE;
>  #define FIXR(x) ((float)(x))
>  #define FIXR10(x)   ((float)(x))
>  #define Q23(x)  x
> --
> 2.6.2
>

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

[FFmpeg-devel] [PATCHv2] avutil/lls: speed up performance of solve_lls

[Ganesh Ajjanagadde]

This is a trivial rewrite of the loops that results in better
prefetching and associated cache efficiency. Essentially, the problem is
that modern prefetching logic is based on finite state Markov memory, a 
reasonable
assumption that is used elsewhere in CPU's in for instance branch
predictors.

Surrounding loops all iterate forward through the array, making the
predictor think of prefetching in the forward direction, but the
intermediate loop is unnecessarily in the backward direction.

Speedup is nontrivial. Benchmarks obtained by 10^6 iterations within
solve_lls, with START/STOP_TIMER. File is 
tests/data/fate/flac-16-lpc-cholesky.err.
Hardware: x86-64, Haswell, GNU/Linux.

new:
  17291 decicycles in solve_lls, 2096706 runs,446 skips
  17255 decicycles in solve_lls, 4193657 runs,647 skips
  17231 decicycles in solve_lls, 8384997 runs,   3611 skips
  17189 decicycles in solve_lls,16771010 runs,   6206 skips
  17132 decicycles in solve_lls,33544757 runs,   9675 skips
  17092 decicycles in solve_lls,67092404 runs,  16460 skips
  17058 decicycles in solve_lls,134188213 runs,  29515 skips

old:
  18009 decicycles in solve_lls, 2096665 runs,487 skips
  17805 decicycles in solve_lls, 4193320 runs,984 skips
  17779 decicycles in solve_lls, 8386855 runs,   1753 skips
  18289 decicycles in solve_lls,16774280 runs,   2936 skips
  18158 decicycles in solve_lls,33548104 runs,   6328 skips
  18420 decicycles in solve_lls,67091793 runs,  17071 skips
  18310 decicycles in solve_lls,134187219 runs,  30509 skips

Reviewed-by: Michael Niedermayer 
Signed-off-by: Ganesh Ajjanagadde 
---
 libavutil/lls.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavutil/lls.c b/libavutil/lls.c
index f77043b..4330697 100644
--- a/libavutil/lls.c
+++ b/libavutil/lls.c
@@ -55,7 +55,7 @@ void avpriv_solve_lls(LLSModel *m, double threshold, unsigned 
short min_order)
 for (j = i; j < count; j++) {
 double sum = covar[i][j];
 
-for (k = i - 1; k >= 0; k--)
+for (k = 0; k <= i-1; k++)
 sum -= factor[i][k] * factor[j][k];
 
 if (i == j) {
@@ -71,7 +71,7 @@ void avpriv_solve_lls(LLSModel *m, double threshold, unsigned 
short min_order)
 for (i = 0; i < count; i++) {
 double sum = covar_y[i + 1];
 
-for (k = i - 1; k >= 0; k--)
+for (k = 0; k <= i-1; k++)
 sum -= factor[i][k] * m->coeff[0][k];
 
 m->coeff[0][i] = sum / factor[i][i];
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] avutil/lls: speed up performance of solve_lls

[Ganesh Ajjanagadde]

On Tue, Nov 24, 2015 at 8:32 PM, Ganesh Ajjanagadde  wrote:
> On Tue, Nov 24, 2015 at 8:19 PM, Michael Niedermayer  wrote:
>> On Mon, Nov 23, 2015 at 08:00:12PM -0500, Ganesh Ajjanagadde wrote:
>>> This is a trivial rewrite of the loops that results in better cache
>>> efficiency. Essentially, iterating backwards over an array is a bad
>>> idea, since it leads to many cache misses: forward iteration fetches a
>>> new cache line that gets subsequently used, while backwards iteration 
>>> fetches the
>>> cache line thinking that the indexing would move forwards (the common 
>>> behavior),
>>> resulting in many cache misses.
>>>
>>> Speedup is nontrivial. Benchmarks obtained by 10^6 iterations within
>>> solve_lls, with START/STOP_TIMER. File is 
>>> tests/data/fate/flac-16-lpc-cholesky.err.
>>> Hardware: x86-64, Haswell, GNU/Linux.
>>>
>>> new:
>>>   12598 decicycles in solve_lls, 2096871 runs,281 skips
>>>   12393 decicycles in solve_lls, 4193889 runs,415 skips
>>>   12250 decicycles in solve_lls, 8387253 runs,   1355 skips
>>>   12585 decicycles in solve_lls,16775089 runs,   2127 skips
>>>   12785 decicycles in solve_lls,33550272 runs,   4160 skips
>>>   12483 decicycles in solve_lls,67101734 runs,   7130 skips
>>>   12610 decicycles in solve_lls,134202614 runs,  15114 skips
>>>
>>> old:
>>>   18101 decicycles in solve_lls, 2096659 runs,493 skips
>>>   17850 decicycles in solve_lls, 4193609 runs,695 skips
>>>   17757 decicycles in solve_lls, 8387458 runs,   1150 skips
>>>   17746 decicycles in solve_lls,16775207 runs,   2009 skips
>>>   17906 decicycles in solve_lls,33550820 runs,   3612 skips
>>>   17931 decicycles in solve_lls,67102891 runs,   5973 skips
>>>   17907 decicycles in solve_lls,134206693 runs,  11035 skips
>>>
>>> ---
>>> Barring asm for this function, there are two (more interesting) potential
>>> optimizations for the Cholesky decomposition here:
>>> 1. Notice that update_lls is doing a rank one update of the matrix via the 
>>> var
>>> vector. Rank one update of the Cholesky decomposition can be done much more
>>> efficiently than a full blown decomposition, see e.g Wikipedia. This will 
>>> almost
>>> certainly require some API thought.
>>>
>>> 2. LDL' form of the Cholesky factorization offers 2 main advantages:
>>> a) Avoiding sqrt and its associated cost, trading it off with extra 
>>> multiplications.
>>> This may or may not be worth the computational cost, though it seems like in
>>> FFmpeg, the Cholesky operates on small matrices of dim ~ 3-50, resulting in
>>> not too many extra multiplies.
>>> b) It provides benefits especially in the poorly conditioned
>>> case since one does not have to worry about nan's and associated tainting 
>>> due
>>> to the sqrt.
>>> This may or may not require API thought.
>>>
>>> I personally view 1 as being more unambiguously worthy of exploration at 
>>> this stage.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavutil/lls.c | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> this significantly changes the output for
>> libavutil/lls-test
>>
>> is that intended ?
>
> Wait, I thought there was only one line changed in a diff between the
> old and new output, and it was trivial involving a nan. Maybe I posted
> the wrong patch, in which case sorry.

I should have been suspicious of the huge perf change, there was an
extra stray line from the old patch I was working with. Reposted as
v2, updated perf numbers; it is far more modest as expected.
Explanation also improved.

>
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> I have often repented speaking, but never of holding my tongue.
>> -- Xenocrates
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/af_afade: improve accuracy and speed of gain computation

[Ganesh Ajjanagadde]

Gain computation for various curves was being done in a needlessly
inaccurate fashion. Of course these are all subjective curves, but when
a curve is advertised to the user, it should be matched as closely as
possible within the limitations of libm. In particular, the constants
kept here were pretty inaccurate for double precision.

Speed improvements are mainly due to the avoidance of pow, the most
notorious of the libm functions in terms of performance. To be fair, it
is the GNU libm that is among the worst, but it is not really GNU libm's fault
since others simply yield a higher error as measured in ULP.

"Magic" constants are also accordingly documented, since they take at
least a minute of thought for a casual reader.

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

diff --git a/libavfilter/af_afade.c b/libavfilter/af_afade.c
index ca9f2c4..c8b6ed8 100644
--- a/libavfilter/af_afade.c
+++ b/libavfilter/af_afade.c
@@ -92,6 +92,7 @@ static int query_formats(AVFilterContext *ctx)
 
 static double fade_gain(int curve, int64_t index, int range)
 {
+#define CUBE(a) ((a)*(a)*(a))
 double gain;
 
 gain = av_clipd(1.0 * index / range, 0, 1.0);
@@ -101,22 +102,25 @@ static double fade_gain(int curve, int64_t index, int 
range)
 gain = sin(gain * M_PI / 2.0);
 break;
 case IQSIN:
-gain = 0.636943 * asin(gain);
+/* 0.6... = 2 / M_PI */
+gain = 0.6366197723675814 * asin(gain);
 break;
 case ESIN:
-gain = 1.0 - cos(M_PI / 4.0 * (pow(2.0*gain - 1, 3) + 1));
+gain = 1.0 - cos(M_PI / 4.0 * (CUBE(2.0*gain - 1) + 1));
 break;
 case HSIN:
 gain = (1.0 - cos(gain * M_PI)) / 2.0;
 break;
 case IHSIN:
-gain = 0.318471 * acos(1 - 2 * gain);
+/* 0.3... = 1 / M_PI */
+gain = 0.3183098861837907 * acos(1 - 2 * gain);
 break;
 case EXP:
-gain = pow(0.1, (1 - gain) * 5.0);
+/* -11.5... = 5*ln(0.1) */
+gain = exp(-11.512925464970227 * (1 - gain));
 break;
 case LOG:
-gain = av_clipd(0.0868589 * log(10 * gain), 0, 1.0);
+gain = av_clipd(1 + 0.2 * log10(gain), 0, 1.0);
 break;
 case PAR:
 gain = 1 - sqrt(1 - gain);
@@ -128,7 +132,7 @@ static double fade_gain(int curve, int64_t index, int range)
 gain *= gain;
 break;
 case CUB:
-gain = gain * gain * gain;
+gain = CUBE(gain);
 break;
 case SQU:
 gain = sqrt(gain);
@@ -137,10 +141,10 @@ static double fade_gain(int curve, int64_t index, int 
range)
 gain = cbrt(gain);
 break;
 case DESE:
-gain = gain <= 0.5 ? pow(2 * gain, 1/3.) / 2: 1 - pow(2 * (1 - gain), 
1/3.) / 2;
+gain = gain <= 0.5 ? cbrt(2 * gain) / 2: 1 - cbrt(2 * (1 - gain)) / 2;
 break;
 case DESI:
-gain = gain <= 0.5 ? pow(2 * gain, 3) / 2: 1 - pow(2 * (1 - gain), 3) 
/ 2;
+gain = gain <= 0.5 ? CUBE(2 * gain) / 2: 1 - CUBE(2 * (1 - gain)) / 2;
 break;
 }
 
-- 
2.6.2

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

[FFmpeg-devel] [PATCH] avfilter/af_dynaudnorm: remove wasteful pow

[Ganesh Ajjanagadde]

This removes wasteful pow(x, 2.0) that although not terribly important
for speed, is still useless.

Signed-off-by: Ganesh Ajjanagadde 
--
Observed while auditing the codebase for wasteful pow calls.

---
 libavfilter/af_dynaudnorm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/af_dynaudnorm.c b/libavfilter/af_dynaudnorm.c
index 62a2653..5f412f5 100644
--- a/libavfilter/af_dynaudnorm.c
+++ b/libavfilter/af_dynaudnorm.c
@@ -237,13 +237,13 @@ static void 
init_gaussian_filter(DynamicAudioNormalizerContext *s)
 // Pre-compute constants
 const int offset = s->filter_size / 2;
 const double c1 = 1.0 / (sigma * sqrt(2.0 * M_PI));
-const double c2 = 2.0 * pow(sigma, 2.0);
+const double c2 = 2.0 * sigma * sigma;
 
 // Compute weights
 for (i = 0; i < s->filter_size; i++) {
 const int x = i - offset;
 
-s->weights[i] = c1 * exp(-(pow(x, 2.0) / c2));
+s->weights[i] = c1 * exp(-x * x / c2);
 total_weight += s->weights[i];
 }
 
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] lavd/avfoundation: overhaul

[Thilo Borgmann]

Am 24.11.15 um 20:28 schrieb Clément Bœsch:
> On Tue, Nov 24, 2015 at 07:27:57PM +0100, Thilo Borgmann wrote:
>> Hi,
>>
>> this patchset fixes most if not all bugs reported to trac for me.
>>
> 
> Thanks.

> BTW, did you see
> http://lists.libav.org/pipermail/libav-devel/2015-November/073162.html ?

Not yet, thanks for the link!

> Are you in contact with the author or something? Any idea how this is
> going to be handled for the merge?

I've currently no contact. I will have a look and see if that might be fruitful.

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

Re: [FFmpeg-devel] [PATCHv2] avutil/libm: correct isnan, isinf compat hacks

[Hendrik Leppkes]

On Sat, Nov 21, 2015 at 2:53 PM, Ganesh Ajjanagadde  wrote:
> On Wed, Nov 18, 2015 at 3:04 PM, Ganesh Ajjanagadde  wrote:
>> On Wed, Nov 18, 2015 at 2:58 PM, Michael Niedermayer  
>> wrote:
>>> On Tue, Nov 17, 2015 at 04:54:10PM -0500, Ganesh Ajjanagadde wrote:
 isnan and isinf are actually macros as per the standard. In particular,
 the existing implementation has incorrect signature. Furthermore, this
 results in undefined behavior for e.g double values outside float range
 as per the standard.

 This patch corrects the undefined behavior for all usage within FFmpeg.

 Note that long double is not handled as it is not used in FFmpeg.
 Furthermore, even if at some point long double gets used, it is likely
 not needed to modify the macro in practice for usage in FFmpeg. See
 below for analysis.

 Getting long double to work strictly per the spec is significantly harder
 since a long double may be an IEEE 128 bit quad (very rare), 80 bit
 extended precision value (on GCC/Clang), or simply double (on recent 
 Microsoft).
 On the other hand, any potential future usage of long double is likely
 for precision (when a platform offers extra precision) and not for range, 
 since
 the range anyway varies and is not as portable as IEEE 754 single/double
 precision. In such cases, the implicit cast to a double is well defined
 and isinf and isnan should work as intended.

 Reviewed-by: Michael Niedermayer 
 Signed-off-by: Ganesh Ajjanagadde 
 ---
  libavutil/libm.h | 34 --
  1 file changed, 32 insertions(+), 2 deletions(-)
>>>
>>> probably ok
>>> maybe wait a day or 2 before pushing so people can test it on more
>>> obscure platforms
>>>
>>> thx
>>
>> ok, will wait for 2 days for the hypot hack as well. Thanks.
>
> pushed, thanks
>

nan/inf behavior on VS2012 seems to have broken with this (probably
nan, but as the patch touches both..)
Reverting this particular patch resolves the failures.

http://fate.ffmpeg.org/report.cgi?time=20151124040137=x86_32-msvc11-windows-native
(ebur128 was broken before)

Do any other systems use these fallbacks to verify they actually work?

I'm not at home until next week to do any further testing for the time being.

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

[FFmpeg-devel] [PATCH] lavc/ac3_parser: avoid zeroing codec parameters if we haven't parsed a frame

[Rodger Combs]

This caused issues when seeking in some unusual MPEGTS files
---
 libavcodec/aac_ac3_parser.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/aac_ac3_parser.c b/libavcodec/aac_ac3_parser.c
index 2f7d568..b01d5a5 100644
--- a/libavcodec/aac_ac3_parser.c
+++ b/libavcodec/aac_ac3_parser.c
@@ -34,6 +34,7 @@ int ff_aac_ac3_parse(AVCodecParserContext *s1,
 ParseContext *pc = >pc;
 int len, i;
 int new_frame_start;
+int got_frame = 0;
 
 get_next:
 i=END_NOT_FOUND;
@@ -51,6 +52,7 @@ get_next:
 if(len<=0){
 i=END_NOT_FOUND;
 }else{
+got_frame = 1;
 s->state=0;
 i-= s->header_size -1;
 s->remaining_size = len;
@@ -80,7 +82,7 @@ get_next:
and total number of samples found in an AAC ADTS header are not
reliable. Bit rate is still accurate because the total frame duration in
seconds is still correct (as is the number of bits in the frame). */
-if (avctx->codec_id != AV_CODEC_ID_AAC) {
+if (avctx->codec_id != AV_CODEC_ID_AAC && got_frame) {
 avctx->sample_rate = s->sample_rate;
 
 /* (E-)AC-3: allow downmixing to stereo or mono */
-- 
2.6.3

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

[FFmpeg-devel] [PATCH]lavf/mxfdec: Set width to actual coded_width for AVCI50

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #5029.

Please comment, Carl Eugen
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 429f46a..6b1c654 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1145,6 +1145,15 @@ static const MXFCodecUL 
mxf_intra_only_picture_essence_coding_uls[] = {
 { { 
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 
},  0,   AV_CODEC_ID_NONE },
 };
 
+/* actual coded width for AVC-Intra to allow selecting correct SPS/PPS */
+static const MXFCodecUL mxf_intra_only_picture_coded_width[] = {
+{ { 
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x01,0x32,0x21,0x01 
}, 16, 1440 },
+{ { 
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x01,0x32,0x21,0x02 
}, 16, 1440 },
+{ { 
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x01,0x32,0x21,0x03 
}, 16, 1440 },
+{ { 
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x01,0x32,0x21,0x04 
}, 16, 1440 },
+{ { 
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 
},  0,0 },
+};
+
 static const MXFCodecUL mxf_sound_essence_container_uls[] = {
 // sound essence container uls
 { { 
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x06,0x01,0x00 
}, 14, AV_CODEC_ID_PCM_S16LE }, /* BWF Frame wrapped */
@@ -2128,6 +2137,10 @@ static int mxf_parse_structural_metadata(MXFContext *mxf)
 memcpy(st->codec->extradata, descriptor->extradata, 
descriptor->extradata_size);
 }
 } else if (st->codec->codec_id == AV_CODEC_ID_H264) {
+int coded_width = 
mxf_get_codec_ul(mxf_intra_only_picture_coded_width,
+   
>essence_codec_ul)->id;
+if (coded_width)
+st->codec->width = coded_width;
 ret = ff_generate_avci_extradata(st);
 if (ret < 0)
 return ret;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#2]

[Michael Niedermayer]

On Sun, Oct 25, 2015 at 01:53:07AM +0200, Michael Niedermayer wrote:
> Hi all
> 
> Heres another suggested addition to the voting committee
> also off topic but i wonder if "[DECISSION]" in the subject is the best
> choice for this
> 
> I Suggest to add all people who pushed or pull-requested 20 or more commits
> according to the commiter field in the last year (the initial voting committee
> members where based on the Author field)
> 
> I used the following to generate the list (this sadly can still change if
> people push changes with commit dates in the past, i suggest that such cases
> wont be considered)
> The command explicitly excludes "enemy merges" as these have not been
> requested by the commiters
> excluding all merges results in a list with the same people just
> somewhat different numbers
> 
> git log libav/master..master --no-merges  --since=2014-10-25T00:00:00Z 
> --until 2015-10-25T00:00:00Z --pretty=fuller | grep '^Commit:' | sed 
> 's/<.*//' |sort | uniq -c | sort -nr
> 
> most of these developers are already in the voting committee
> here is the list that command generated locally at around 1 o clock local time
> 
>3691 Commit: Michael Niedermayer
> 334 Commit: Paul B Mahol
> 242 Commit: Clément Bœsch
> 205 Commit: Carl Eugen Hoyos
> 203 Commit: James Almer
> 154 Commit: Ronald S. Bultje
> 115 Commit: Rostislav Pehlivanov
>  88 Commit: Lukasz Marek
>  77 Commit: Andreas Cadhalpun
>  64 Commit: Reynaldo H. Verdejo Pinochet
>  56 Commit: Stefano Sabatini
>  44 Commit: Hendrik Leppkes
>  40 Commit: Marton Balint
>  39 Commit: Nicolas George
>  38 Commit: Philip Langdale
>  37 Commit: Timothy Gu
>  29 Commit: wm4
>  27 Commit: Ganesh Ajjanagadde
>  20 Commit: Reimar Döffinger
>  20 Commit: Lou Logan
> 
> The newly added developers would be
> Ganesh Ajjanagadde
> Lou Logan
> Marton Balint
> Philip Langdale
> Reimar Döffinger
> 
> All of them have also contributed significantly outside of just self
> pushed commits.
> I belive they all should be on the voting comittee
> 
> Identical to the last suggested addition,
> I suggest a deadline for making a decision on these 5 people of 15 days
> starting now.

a bit later but announcing the results now, noone was against so
 Ganesh Ajjanagadde
 Lou Logan
 Marton Balint
 Philip Langdale
 Reimar Döffinger
are now part of the vote comittee

[...]

-- 
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] [PATCH] avfilter/vsrc_mandelbrot: avoid sqrt for epsilon calculation

[Ganesh Ajjanagadde]

On Mon, Nov 23, 2015 at 9:46 PM, Michael Niedermayer  wrote:
> On Mon, Nov 23, 2015 at 05:19:52PM -0500, Ganesh Ajjanagadde wrote:
>> This rewrites into the mathematically equivalent expression avoiding sqrt,
>> and results in a very minor speedup.
>>
>> Tested on x86-64, Haswell, GNU/Linux.
>> Command:
>> ffmpeg -v error -f lavfi -i mandelbrot -f null -
>>
>> old (draw_mandelbrot):
>> 3982389425 decicycles in draw_mandelbrot, 256 runs,  0 skips
>> 7634221782 decicycles in draw_mandelbrot, 512 runs,  0 skips
>> 20576449397 decicycles in draw_mandelbrot,1024 runs,  0 skips
>> 12949998655 decicycles in draw_mandelbrot,2048 runs,  0 skips
>>
>> new (draw_mandelbrot):
>> 3966406060 decicycles in draw_mandelbrot, 256 runs,  0 skips
>> 7553322112 decicycles in draw_mandelbrot, 512 runs,  0 skips
>> 20454169970 decicycles in draw_mandelbrot,1024 runs,  0 skips
>> 1288615 decicycles in draw_mandelbrot,2048 runs,  0 skips
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavfilter/vsrc_mandelbrot.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavfilter/vsrc_mandelbrot.c b/libavfilter/vsrc_mandelbrot.c
>> index 950c5c8..20da8ae 100644
>> --- a/libavfilter/vsrc_mandelbrot.c
>> +++ b/libavfilter/vsrc_mandelbrot.c
>> @@ -291,7 +291,7 @@ static void draw_mandelbrot(AVFilterContext *ctx, 
>> uint32_t *color, int linesize,
>>
>>  use_zyklus= (x==0 || s->inner!=BLACK ||color[x-1 + y*linesize] 
>> == 0xFF00);
>>  if(use_zyklus)
>> -epsilon= scale*1*sqrt(SQR(x-s->w/2) + SQR(y-s->h/2))/s->w;
>> +epsilon= SQR(scale/s->w)*(SQR(x-s->w/2) + SQR(y-s->h/2));
>
> if the sqrt is a speed problem, (i had originally thougt it would
> not be)
> you can probably replace this by an approximation like:
> epsilon= scale*CONSTANT*(FFABS(x-s->w/2) + FFABS(y-s->h/2))/s->w;

This is mathematically justifiable in the sense that \forall x, y \ge
0, \sqrt{\frac{1}{2}}(x+y) \le \sqrt{x^2 + y^2} \le 1(x+y), i.e
replacing by a constant is ok as the constant is guaranteed to lie
within bounds not too far apart (~[0.7, 1]). Furthermore, anyway the
"10*epsilon*epsilon" is a heuristic, and so the 10 can absorb any
minor change here.
Will change, and replace by the constant 1. Note that this will avoid
the cost of sqrt as well as squaring, so hopefully it is more readily
measurable.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter: add compensationdelay filter

[Paul B Mahol]

Subject: [PATCH] avfilter: add compensation delay line filter

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi   |  42 
 libavfilter/Makefile   |   1 +
 libavfilter/af_compensationdelay.c | 196 +
 libavfilter/allfilters.c   |   1 +
 4 files changed, 240 insertions(+)
 create mode 100644 libavfilter/af_compensationdelay.c

diff --git a/doc/filters.texi b/doc/filters.texi
index f351390..d8b2fb5 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -1628,6 +1628,48 @@
compand=.1|.1:.1|.1:-45.1/-45.1|-45/-900|0/-900:.01:45:-90:.1
 @end example
 @end itemize

+@section compensationdelay
+
+Compensation Delay Line is a metric based delay to compensate differing
+positions of microphones or speakers.
+
+For example, you have recorded guitar with two microphones placed in
+different location. Because the front of sound wave has fixed speed in
+normal conditions, the phasing of microphones can vary and depends on
+their location and interposition. The best sound mix you will get when
+these microphones are in phase (synchronized). Note that distance of
+~30 cm between microphones makes one microphone to capture signal in
+antiphase to another microphone. That makes the final mix sounding moody.
+This filter helps to solve phasing problems by adding different delays
+to each microphone track and make them synchronized.
+
+The best result can be reached when you take one track as base and
+synchronize other tracks one by one with it.
+Remember that synchronization/delay tolerance depends on sample rate, too.
+Higher sample rates will give more tolerance.
+
+It accepts the following parameters:
+
+@table @option
+@item mm
+Set millimeters distance. This is compensation distance for fine tuning.
+
+@item cm
+Set cm distance. This is compensation distance for tighten distance setup.
+
+@item m
+Set meters distance. This is compensation distance for hard distance setup.
+
+@item dry
+Set dry amount. Amount of unprocessed (dry) signal.
+
+@item wet
+Set wet amount. Amount of processed (wet) signal.
+
+@item temp
+Set temperature degree in Celzius. This is the temperature of the environment.
+@end table
+
 @section dcshift
 Apply a DC shift to the audio.

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 1f4abeb..c896374 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -64,6 +64,7 @@ OBJS-$(CONFIG_CHANNELMAP_FILTER) +=
af_channelmap.o
 OBJS-$(CONFIG_CHANNELSPLIT_FILTER)   += af_channelsplit.o
 OBJS-$(CONFIG_CHORUS_FILTER) += af_chorus.o
generate_wave_table.o
 OBJS-$(CONFIG_COMPAND_FILTER)+= af_compand.o
+OBJS-$(CONFIG_COMPENSATIONDELAY_FILTER)  += af_compensationdelay.o
 OBJS-$(CONFIG_DCSHIFT_FILTER)+= af_dcshift.o
 OBJS-$(CONFIG_DYNAUDNORM_FILTER) += af_dynaudnorm.o
 OBJS-$(CONFIG_EARWAX_FILTER) += af_earwax.o
diff --git a/libavfilter/af_compensationdelay.c
b/libavfilter/af_compensationdelay.c
new file mode 100644
index 000..1a32879
--- /dev/null
+++ b/libavfilter/af_compensationdelay.c
@@ -0,0 +1,196 @@
+/*
+ * Copyright (c) 2001-2010 Krzysztof Foltman, Markus Schmidt, Thor
Harald Johansen, Vladimir Sadovnikov and others
+ * 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/opt.h"
+#include "libavutil/samplefmt.h"
+#include "avfilter.h"
+#include "audio.h"
+#include "internal.h"
+
+typedef struct CompensationDelayContext {
+const AVClass *class;
+int distance_mm;
+int distance_cm;
+int distance_m;
+double dry, wet;
+int temp;
+
+unsigned delay;
+unsigned w_ptr;
+unsigned buf_size;
+AVFrame *delay_frame;
+} CompensationDelayContext;
+
+#define OFFSET(x) offsetof(CompensationDelayContext, x)
+#define A AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption compensationdelay_options[] = {
+{ "mm",   "set mm distance",OFFSET(distance_mm),
AV_OPT_TYPE_INT,{.i64=0},   0,  10, A },
+{ "cm",   "set cm distance",OFFSET(distance_cm),
AV_OPT_TYPE_INT,{.i64=0},   0, 100, A },
+{ "m","set 

[FFmpeg-devel] [PATCH] Remove size magic number (15) and use sizeof instead

[webmaster]

From: Mohammad Ghasembeigi 

---
 libavcodec/dsicinvideo.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavcodec/dsicinvideo.c b/libavcodec/dsicinvideo.c
index f95cbc7..dc9ae7d 100644
--- a/libavcodec/dsicinvideo.c
+++ b/libavcodec/dsicinvideo.c
@@ -100,12 +100,12 @@ static int cin_decode_huffman(const unsigned char *src, 
int src_size,
 unsigned char *dst_end   = dst + dst_size;
 const unsigned char *src_end = src + src_size;
 
-memcpy(huff_code_table, src, 15);
-src += 15;
+memcpy(huff_code_table, src, sizeof(huff_code_table));
+src += sizeof(huff_code_table);
 
 while (src < src_end) {
 huff_code = *src++;
-if ((huff_code >> 4) == 15) {
+if ((huff_code >> 4) == sizeof(huff_code_table)) {
 b  = huff_code << 4;
 huff_code  = *src++;
 *dst_cur++ = b | (huff_code >> 4);
@@ -114,8 +114,8 @@ static int cin_decode_huffman(const unsigned char *src, int 
src_size,
 if (dst_cur >= dst_end)
 break;
 
-huff_code &= 15;
-if (huff_code == 15) {
+huff_code &= sizeof(huff_code_table);
+if (huff_code == sizeof(huff_code_table)) {
 *dst_cur++ = *src++;
 } else
 *dst_cur++ = huff_code_table[huff_code];
-- 
1.9.5.msysgit.1

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

Re: [FFmpeg-devel] Include more developers in the voting committee [#3]

[Paul B Mahol]

On 11/24/15, Michael Niedermayer  wrote:
> Hi all
>
> Heres another suggested addition to the voting committee, i omitted
> the "[DECISSION]" from the subject as IIUC nicolas suggested to do it
> in a 2 step process, first check if anyone was missed and then do a
> actual [DECISSION] vote mail
>
> I suggest to add people who do/did admin/provide ffmpeg infrastructure
> within the last year.
>
> Alexander Strasser  most of the trac maintaince, lots of work in
> the last server move
> Baptiste Coudurier  (fate.ffmpeg.org server)
> Clement Boesch   ffbox0 (he is already in the comittee)
> Compn   all kinds of things all over the place, from
> helping users here to helping there, to being
> ML admin backup, ...
> Fabrice Bellard Project founder, ffmpeg.org name owner, without
> him there would be no FFmpeg
> ifj Gereoffy Arpad  the .hu servers we used forever and current
> secondary DNS
> Jean-Baptiste Kempf our git and incoming ftp
> Kieran Kunhya   (trac.ffmpeg.org server)
> Lou Logan   (already in the comittee)
> Nikolay Aleksandrov ffbox1, seting up VMs on ffbox1, other ->ffbox1
> copiing work
> Reimar Doeffinger(already in the comittee)
> Roberto Togni   some work moving away from .hu, providing secondary
> DNS
> Tim Nicholson   mail stuff, spam filtering
>
> if i forgot someone who did significant infrastructure related work
> in the last year please add them to the list
>
> I intend to in 1-2 weeks or so to post a DECISSION mail with the list
> (probably later as ill forget again) and then everyone can vote on
> the list
>
> Thanks
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Democracy is the form of government in which you can choose your dictator
>

Some of them are not (FFmpeg or whatever) developers. So subject name is wrong.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Include more developers in the voting committee [#3]

[Michael Niedermayer]

Hi all

Heres another suggested addition to the voting committee, i omitted
the "[DECISSION]" from the subject as IIUC nicolas suggested to do it
in a 2 step process, first check if anyone was missed and then do a
actual [DECISSION] vote mail

I suggest to add people who do/did admin/provide ffmpeg infrastructure
within the last year.

Alexander Strasser  most of the trac maintaince, lots of work in
the last server move
Baptiste Coudurier  (fate.ffmpeg.org server)
Clément Bœsch   ffbox0 (he is already in the comittee)
Compn   all kinds of things all over the place, from
helping users here to helping there, to being
ML admin backup, ...
Fabrice Bellard Project founder, ffmpeg.org name owner, without
him there would be no FFmpeg
ifj Gereoffy Arpad  the .hu servers we used forever and current secondary 
DNS
Jean-Baptiste Kempf our git and incoming ftp
Kieran Kunhya   (trac.ffmpeg.org server)
Lou Logan   (already in the comittee)
Nikolay Aleksandrov ffbox1, seting up VMs on ffbox1, other ->ffbox1 copiing 
work
Reimar Döffinger(already in the comittee)
Roberto Togni   some work moving away from .hu, providing secondary DNS
Tim Nicholson   mail stuff, spam filtering

if i forgot someone who did significant infrastructure related work
in the last year please add them to the list

I intend to in 1-2 weeks or so to post a DECISSION mail with the list
(probably later as ill forget again) and then everyone can vote on
the list

Thanks

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator


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

Re: [FFmpeg-devel] Include more developers in the voting committee [#3]

[Rostislav Pehlivanov]

I agree with both BBB and wm4.

You have to remember that when we made the committee back in September we
agreed to only include people who had more than 50 commits in the period of
a year. Therefore, if we include inactive people now, then they would be
out of the committee by next September because chances are they'll still
remain inactive. We did agree to remove inactive developers who did not
meed the quota after all.
I also think that should any real conflict arise and we have too many
people then we would run into the problem of having far too many opinions
with little chance of ever agreeing and doing what the committee is
supposed to do, which is to solve serious problems.

On 24 November 2015 at 12:50, Ronald S. Bultje  wrote:

> Hi,
>
> On Tue, Nov 24, 2015 at 6:21 AM, Michael Niedermayer 
> wrote:
>
> > Hi all
> >
> > Heres another suggested addition to the voting committee, i omitted
> > the "[DECISSION]" from the subject as IIUC nicolas suggested to do it
> > in a 2 step process, first check if anyone was missed and then do a
> > actual [DECISSION] vote mail
> >
> > I suggest to add people who do/did admin/provide ffmpeg infrastructure
> > within the last year.
> >
> > Alexander Strasser  most of the trac maintaince, lots of work in
> > the last server move
> > Baptiste Coudurier  (fate.ffmpeg.org server)
> > Clément Bœsch   ffbox0 (he is already in the comittee)
> > Compn   all kinds of things all over the place, from
> > helping users here to helping there, to being
> > ML admin backup, ...
> > Fabrice Bellard Project founder, ffmpeg.org name owner, without
> > him there would be no FFmpeg
> > ifj Gereoffy Arpad  the .hu servers we used forever and current
> > secondary DNS
> > Jean-Baptiste Kempf our git and incoming ftp
> > Kieran Kunhya   (trac.ffmpeg.org server)
> > Lou Logan   (already in the comittee)
> > Nikolay Aleksandrov ffbox1, seting up VMs on ffbox1, other ->ffbox1
> > copiing work
> > Reimar Döffinger(already in the comittee)
> > Roberto Togni   some work moving away from .hu, providing
> > secondary DNS
> > Tim Nicholson   mail stuff, spam filtering
> >
> > if i forgot someone who did significant infrastructure related work
> > in the last year please add them to the list
> >
> > I intend to in 1-2 weeks or so to post a DECISSION mail with the list
> > (probably later as ill forget again) and then everyone can vote on
> > the list
>
>
> Just like we don't add any drive-by patch author, we should not add any
> drive-by infrastructure provider. We should only add these that provided
> significant infrastructure for significant amounts of time, specifically
> targetted at FFmpeg.
>
> Quote from me on IRC:
>  I have to admit, I feel somewhat uncomfortable giving voting rights
> to some people that are really not involved with ffmpeg development at all
>  (or ffmpeg at all, for that matter)
>  people that manage our infrastructure should get voting rights,
> there’s little doubt about that, but people that manage other
> infrastructure and just happen to stuff a bit of ffmpeg in there also, and
> that’s their only involvement, I have reservations about that
>  as valuable as it is, that does not make you part of a core voting
> committee, IMHO
>
> As such, "setting up secondary DNS" probably does not meet this bar. I also
> object to Fabrice, he has not been actively involved for >10 years. The
> committee is for active developers.
>
> 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

Re: [FFmpeg-devel] Include more developers in the voting committee [#3]

[Ronald S. Bultje]

Hi,

On Tue, Nov 24, 2015 at 6:21 AM, Michael Niedermayer 
wrote:

> Hi all
>
> Heres another suggested addition to the voting committee, i omitted
> the "[DECISSION]" from the subject as IIUC nicolas suggested to do it
> in a 2 step process, first check if anyone was missed and then do a
> actual [DECISSION] vote mail
>
> I suggest to add people who do/did admin/provide ffmpeg infrastructure
> within the last year.
>
> Alexander Strasser  most of the trac maintaince, lots of work in
> the last server move
> Baptiste Coudurier  (fate.ffmpeg.org server)
> Clément Bœsch   ffbox0 (he is already in the comittee)
> Compn   all kinds of things all over the place, from
> helping users here to helping there, to being
> ML admin backup, ...
> Fabrice Bellard Project founder, ffmpeg.org name owner, without
> him there would be no FFmpeg
> ifj Gereoffy Arpad  the .hu servers we used forever and current
> secondary DNS
> Jean-Baptiste Kempf our git and incoming ftp
> Kieran Kunhya   (trac.ffmpeg.org server)
> Lou Logan   (already in the comittee)
> Nikolay Aleksandrov ffbox1, seting up VMs on ffbox1, other ->ffbox1
> copiing work
> Reimar Döffinger(already in the comittee)
> Roberto Togni   some work moving away from .hu, providing
> secondary DNS
> Tim Nicholson   mail stuff, spam filtering
>
> if i forgot someone who did significant infrastructure related work
> in the last year please add them to the list
>
> I intend to in 1-2 weeks or so to post a DECISSION mail with the list
> (probably later as ill forget again) and then everyone can vote on
> the list


Just like we don't add any drive-by patch author, we should not add any
drive-by infrastructure provider. We should only add these that provided
significant infrastructure for significant amounts of time, specifically
targetted at FFmpeg.

Quote from me on IRC:
 I have to admit, I feel somewhat uncomfortable giving voting rights
to some people that are really not involved with ffmpeg development at all
 (or ffmpeg at all, for that matter)
 people that manage our infrastructure should get voting rights,
there’s little doubt about that, but people that manage other
infrastructure and just happen to stuff a bit of ffmpeg in there also, and
that’s their only involvement, I have reservations about that
 as valuable as it is, that does not make you part of a core voting
committee, IMHO

As such, "setting up secondary DNS" probably does not meet this bar. I also
object to Fabrice, he has not been actively involved for >10 years. The
committee is for active developers.

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

Re: [FFmpeg-devel] Include more developers in the voting committee [#3]

[wm4]

On Tue, 24 Nov 2015 12:21:57 +0100
Michael Niedermayer  wrote:

> Hi all
> 
> Heres another suggested addition to the voting committee, i omitted
> the "[DECISSION]" from the subject as IIUC nicolas suggested to do it
> in a 2 step process, first check if anyone was missed and then do a
> actual [DECISSION] vote mail
> 
> I suggest to add people who do/did admin/provide ffmpeg infrastructure
> within the last year.
> 
> Alexander Strasser  most of the trac maintaince, lots of work in
> the last server move
> Baptiste Coudurier  (fate.ffmpeg.org server)
> Clément Bœsch   ffbox0 (he is already in the comittee)
> Compn   all kinds of things all over the place, from
> helping users here to helping there, to being
> ML admin backup, ...
> Fabrice Bellard Project founder, ffmpeg.org name owner, without
> him there would be no FFmpeg
> ifj Gereoffy Arpad  the .hu servers we used forever and current secondary 
> DNS
> Jean-Baptiste Kempf our git and incoming ftp
> Kieran Kunhya   (trac.ffmpeg.org server)
> Lou Logan   (already in the comittee)
> Nikolay Aleksandrov ffbox1, seting up VMs on ffbox1, other ->ffbox1 
> copiing work
> Reimar Döffinger(already in the comittee)
> Roberto Togni   some work moving away from .hu, providing secondary 
> DNS
> Tim Nicholson   mail stuff, spam filtering
> 
> if i forgot someone who did significant infrastructure related work
> in the last year please add them to the list
> 
> I intend to in 1-2 weeks or so to post a DECISSION mail with the list
> (probably later as ill forget again) and then everyone can vote on
> the list
> 
> Thanks
> 

I don't think non-developers (or developers not actively involved with
FFmpeg) should have the right to vote on developer issues.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Allow mpjpeg demuxer to process MIME parts which do not include Content-Length header.

[wm4]

On Tue, 24 Nov 2015 00:16:06 -0500
Alex Agranovsky  wrote:

> From a2a0b9e0da14b6e82aa783535ec1878c8ffbede0 Mon Sep 17 00:00:00 2001
> From: Alex Agranovsky 
> Date: Tue, 24 Nov 2015 00:06:14 -0500
> Subject: [PATCH 1/2] Allow mpjpeg demuxer to process MIME parts which do not
>  include Content-Length header.
> 
> Fixes ticket 5023
> 
> Signed-off-by: Alex Agranovsky 
> ---
>  libavformat/mpjpegdec.c | 176 
> 
>  1 file changed, 133 insertions(+), 43 deletions(-)
> 
> diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
> index 2749a48..e494f1a 100644
> --- a/libavformat/mpjpegdec.c
> +++ b/libavformat/mpjpegdec.c
> @@ -23,22 +23,16 @@
>  
>  #include "avformat.h"
>  #include "internal.h"
> +#include "avio_internal.h"
>  
> -static int get_line(AVIOContext *pb, char *line, int line_size)
> -{
> -int i = ff_get_line(pb, line, line_size);
>  
> -if (i > 1 && line[i - 2] == '\r')
> -line[i - 2] = '\0';
>  
> -if (pb->error)
> -return pb->error;
> -
> -if (pb->eof_reached)
> -return AVERROR_EOF;
> -
> -return 0;
> -}
> +/** Context for demuxing an MPJPEG stream. */

This comment is really not needed.

> +typedef struct MPJPEGDemuxContext {
> +char*   boundary;
> +char*   searchstr;
> +int searchstr_len;
> +} MPJPEGDemuxContext;
>  
>  
>  static void trim_right(char* p)
> @@ -46,13 +40,32 @@ static void trim_right(char* p)
>  char *end;
>  if (!p || !*p)
>  return;
> -end = p + strlen(p) - 1;
> -while (end != p && av_isspace(*end)) {
> +int len = strlen(p);
> +if ( !len )
> +return;
> +end = p + len - 1;
> +while (end >= p && av_isspace(*end)) {

Why this change? Note that strlen(p)>0 is already guaranteed by the
"!*p" check before.

>  *end = '\0';
>  end--;
>  }
>  }
>  
> +static int get_line(AVIOContext *pb, char *line, int line_size)
> +{
> +ff_get_line(pb, line, line_size);
> +
> +if (pb->error)
> +return pb->error;
> +
> +if (pb->eof_reached)
> +return AVERROR_EOF;
> +
> +trim_right(line);
> +return 0;
> +}
> +
> +
> +
>  static int split_tag_value(char **tag, char **value, char *line)
>  {
>  char *p = line;
> @@ -86,12 +99,24 @@ static int split_tag_value(char **tag, char **value, char 
> *line)
>  return 0;
>  }
>  
> -static int parse_multipart_header(AVIOContext *pb, void *log_ctx);
> +static int parse_multipart_header(AVIOContext *pb,
> +int* size,
> +const char* expected_boundary,
> +void *log_ctx);
> +
> +static int mpjpeg_read_close(AVFormatContext *s)
> +{
> +MPJPEGDemuxContext *mpjpeg = s->priv_data;
> +av_freep(>boundary);
> +av_freep(>searchstr);
> +return 0;
> +}
>  
>  static int mpjpeg_read_probe(AVProbeData *p)
>  {
>  AVIOContext *pb;
>  int ret = 0;
> +int size = 0;
>  
>  if (p->buf_size < 2 || p->buf[0] != '-' || p->buf[1] != '-')
>  return 0;
> @@ -100,7 +125,7 @@ static int mpjpeg_read_probe(AVProbeData *p)
>  if (!pb)
>  return 0;
>  
> -ret = (parse_multipart_header(pb, NULL)>0)?AVPROBE_SCORE_MAX:0;
> +ret = ( parse_multipart_header(pb, , "--", NULL) > 0 ) ? 
> AVPROBE_SCORE_MAX : 0;

A stray space got in.

>  
>  av_free(pb);
>  
> @@ -110,17 +135,19 @@ static int mpjpeg_read_probe(AVProbeData *p)
>  static int mpjpeg_read_header(AVFormatContext *s)
>  {
>  AVStream *st;
> -char boundary[70 + 2 + 1];
> +char boundary[70 + 2 + 1] = {0};
>  int64_t pos = avio_tell(s->pb);
>  int ret;
>  
> +do {
> +ret = get_line(s->pb, boundary, sizeof(boundary));
> +if (ret < 0)
> +return ret;
> +} while (!boundary[0]);
>  
> -ret = get_line(s->pb, boundary, sizeof(boundary));
> -if (ret < 0)
> -return ret;
> -

Can you explain why it suddenly has to skip multiple lines?

> -if (strncmp(boundary, "--", 2))
> +if (strncmp(boundary, "--", 2)) {
>  return AVERROR_INVALIDDATA;
> +}

Another change that looks like a stray change.

>  
>  st = avformat_new_stream(s, NULL);
>  if (!st)
> @@ -147,28 +174,44 @@ static int parse_content_length(const char *value)
>  return val;
>  }
>  
> -static int parse_multipart_header(AVIOContext *pb, void *log_ctx)
> +static int parse_multipart_header(AVIOContext *pb,
> +int* size,
> +const char* expected_boundary,
> +void *log_ctx)
>  {
>  char line[128];
>  int found_content_type = 0;
> -int ret, size = -1;
> +int ret;
> +
> +*size = -1;
>  
>  // get the CRLF as empty string
>  ret = get_line(pb, line, sizeof(line));

> -if (ret < 0)
> +if (ret < 0) {
>  return ret;