Re: [FFmpeg-devel] [PATCH 03/10] libavcodec/ccaption_dec: add calculate_duration option

[wm4]

On Tue,  5 Jan 2016 23:41:35 -0800
Aman Gupta  wrote:

> From: Aman Gupta 
> 
> new option defaults to true, to preserve existing behavior. by flipping
> the option to false, subtitle events are emitted as soon as they are
> received and have an infinite duration.
> 
> this new mode is useful for realtime decoding of closed captions so they
> can be display along with decoded mpeg2 frames.
> ---
>  libavcodec/ccaption_dec.c | 19 ---
>  1 file changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
> index f651c88..9f17e77 100644
> --- a/libavcodec/ccaption_dec.c
> +++ b/libavcodec/ccaption_dec.c
> @@ -150,6 +150,7 @@ struct Screen {
>  
>  typedef struct CCaptionSubContext {
>  AVClass *class;
> +int calculate_duration;
>  struct Screen screen[2];
>  int active_screen;
>  uint8_t cursor_row;
> @@ -545,8 +546,12 @@ static int decode(AVCodecContext *avctx, void *data, int 
> *got_sub, AVPacket *avp
>  continue;
>  else
>  process_cc608(ctx, *(bptr + i + 1) & 0x7f, *(bptr + i + 2) & 
> 0x7f);
> -if (ctx->screen_changed)
> -{
> +
> +if (!ctx->screen_changed)
> +continue;
> +ctx->screen_changed = 0;
> +
> +if (ctx->calculate_duration) {
>  if (ctx->prev_string) {
>  int start_time = av_rescale_q(ctx->prev_time, 
> avctx->time_base, (AVRational){ 1, 100 });
>  int end_time = av_rescale_q(avpkt->pts, avctx->time_base, 
> (AVRational){ 1, 100 });
> @@ -560,7 +565,12 @@ static int decode(AVCodecContext *avctx, void *data, int 
> *got_sub, AVPacket *avp
>  av_bprintf(>buffer, "\r\n");
>  ctx->prev_string = av_strdup(ctx->buffer.str);
>  ctx->prev_time = avpkt->pts;
> -ctx->screen_changed = 0;
> +} else {
> +int start_time = av_rescale_q(avpkt->pts, avctx->time_base, 
> (AVRational){ 1, 100 });
> +ret = ff_ass_add_rect_bprint(sub, >buffer, start_time, -1);
> +if (ret < 0)
> +return ret;
> +sub->pts = av_rescale_q(avpkt->pts, avctx->time_base, 
> AV_TIME_BASE_Q);
>  }
>  }
>  
> @@ -568,7 +578,10 @@ static int decode(AVCodecContext *avctx, void *data, int 
> *got_sub, AVPacket *avp
>  return ret;
>  }
>  
> +#define OFFSET(x) offsetof(CCaptionSubContext, x)
> +#define SD AV_OPT_FLAG_SUBTITLE_PARAM | AV_OPT_FLAG_DECODING_PARAM
>  static const AVOption options[] = {
> +{ "calculate_duration", "Buffer closed captions to calculate 
> durations.", OFFSET(calculate_duration), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 
> 1, SD },
>  {NULL}
>  };
>  

I want to note that this is actually the only way to get realtime
closed captions (playback, or even just transcoding with rendering
subtitles to the video). Without this, the API user would have to
buffer video and audio frames until the closed caption even is "done".

Returning events with infinite duration is a hack and a weakness in the
API. These events can't be used with libass in a simple way. Instead,
the API user has to adjust or delete previous events manually. Not
really ideal.

I'm not sure what a better API could look like.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: SMI to SVQ3

[Paul B Mahol]

On 1/6/16, wm4  wrote:
> On Wed, 6 Jan 2016 04:33:16 +0100
> Mats Peterson  wrote:
>
>> At least in this case, MPlayer seems to look at the codec tag rather
>> than the codec ID in order to determine the codec. Therefore, the
>> 'fourcc' variable needs to be set to 'SVQ3' as well, which is later
>> copied to st->codec->codec_tag in matroskadec.c.
>
> You should fix mplayer instead. FFmpeg API users are not supposed to
> use fourcc fields to identify codecs. The fourcc variable in
> matroskadec.c is copied to AVCodecContext.codec_tag, which is not
> necessarily a fourcc (depends on the CODEC_ID; most time it's unused),
> and the svq3 decoder in libavcodec doesn't read it.

Yes, fix broken MPlayer instead.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: SMI to SVQ3

[Mats Peterson]

On 01/06/2016 11:06 AM, Carl Eugen Hoyos wrote:

Mats Peterson  ffmpeg.org> writes:

[...]

The patch is ok, the commit message not:
This is not related to MPlayer but old
lavf producing broken files.
The codec_tag SMI does not exist, SVQ3
should be exported.

Carl Eugen

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



I think you should wait with your statements until you've tried things, 
Carl. The old (broken) "SMI" file output-ffmpeg-20140109-git-c0a33c4.mkv 
(Google for it), which is actually SVQ3, playsi without video in 
MPlayer. It complains at not finding a 'SMI ' codec.



Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: SMI to SVQ3

[Carl Eugen Hoyos]

Mats Peterson  ffmpeg.org> writes:

> You're welcome to fix this issue on the MPlayer side, 
> since it seems you've done that before.

If there were a fourcc (or codec_tag) "SMI " this 
would be trivial to fix in MPlayer.
But this codec_tag does not exist, FFmpeg used to 
write broken mkv files that contained only part 
of the stsd atom.
"Your" patch is correct, the codec_tag for mkv files 
containing SVQ3 should be "SVQ3".

Carl Eugen

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

Re: [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

[Hendrik Leppkes]

On Wed, Jan 6, 2016 at 4:01 AM, James Almer  wrote:
> On 1/5/2016 11:51 PM, Michael Niedermayer wrote:
>> On Tue, Jan 05, 2016 at 11:44:04PM -0300, James Almer wrote:
>>> On 1/5/2016 11:35 PM, Michael Niedermayer wrote:
 On Tue, Jan 05, 2016 at 11:27:25PM -0300, James Almer wrote:
> On 1/5/2016 11:21 PM, Michael Niedermayer wrote:
>> [...]


>
> Ideally, once this decoder is committed replacing the current one we'd 
> replace
> the samples for the set available here: 
> https://github.com/foo86/dcadec-samples

 we can add new fate samples, we cannot replace fate samples
 replacing would break previous checkouts and releases
 not sure you actually meant to replace any ...
>>>
>>> Yeah, forgot about that. Kinda makes for a bloated fate suit in the long 
>>> run...
>>
>> this wouldnt happen if reference files where properly generated
>> that is with some reference decoder or taken from the input to a
>> reference encoder or from some referece test suite.
>>
>> for subtitles or other where files are tiny that is a non issue though
>> ...
>
> Well, whoever made the xll test knew it would probably become obsolete at some
> point, since the decoder was not bitexact when the pcm reference was created.
> At least i assume that's why the test fails with this new bitexact decoder.

If its properly bitexact now, we can use a md5 test instead of needing
a reference sample, so that would safe us adding a new one.
It would be nice to add all the tests from the dcadec test suite later
to get more coverage, dca is slightly under-tested as it is.

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

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: SMI to SVQ3

[Mats Peterson]

On 01/06/2016 11:26 AM, Carl Eugen Hoyos wrote:

Mats Peterson  ffmpeg.org> writes:


You're welcome to fix this issue on the MPlayer side,
since it seems you've done that before.


If there were a fourcc (or codec_tag) "SMI " this
would be trivial to fix in MPlayer.
But this codec_tag does not exist, FFmpeg used to
write broken mkv files that contained only part
of the stsd atom.
"Your" patch is correct, the codec_tag for mkv files
containing SVQ3 should be "SVQ3".

Carl Eugen

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



Yes, I know my patch is correct in that sense. One thing I don't 
understand is why MPlayer looks at the codec tag whatsoever in order to 
determine the video codec, when it should use the codec ID. But that's 
not my problem.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: SMI to SVQ3

[Mats Peterson]

On 01/06/2016 11:26 AM, Carl Eugen Hoyos wrote:

But this codec_tag does not exist, FFmpeg used to
write broken mkv files that contained only part
of the stsd atom.


FFmpeg still writes broken mkv files, for the record. It doesn't include 
the palette, if any, in the stsd atom. But that's a later issue, one 
that I'm currently not concerned about since I use mkvmerge to remux.


Mats

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

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: SMI to SVQ3

[Mats Peterson]

On 01/06/2016 12:22 PM, Mats Peterson wrote:

order to procuce a working Matroska file from a QuickTime file.


Produce, not procuce.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] decklink: support all valid numbers of audio channels

[Matthias Hunstock]

Am 06.01.2016 um 04:08 schrieb Michael Niedermayer:
> any patch that was forgotten and should be applied ?
> just asking as your comment sounds a bit in that direction

Yes, there was some discussion but no further action. But this is the
first patch submitted by me, so I don't fully know the procedures, just
the developer documentation on the website.

The patch I'm referring to is

https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg25609.html

Message-Id: <1450612652-10321-1-git-send-email-a...@fem.tu-ilmenau.de>

(mail from Dec 20th 2015)

Regards
Matthias

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

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: SMI to SVQ3

[Mats Peterson]

On 01/06/2016 10:41 AM, wm4 wrote:

On Wed, 6 Jan 2016 04:33:16 +0100
Mats Peterson  wrote:


At least in this case, MPlayer seems to look at the codec tag rather
than the codec ID in order to determine the codec. Therefore, the
'fourcc' variable needs to be set to 'SVQ3' as well, which is later
copied to st->codec->codec_tag in matroskadec.c.


You should fix mplayer instead. FFmpeg API users are not supposed to
use fourcc fields to identify codecs. The fourcc variable in
matroskadec.c is copied to AVCodecContext.codec_tag, which is not
necessarily a fourcc (depends on the CODEC_ID; most time it's unused),
and the svq3 decoder in libavcodec doesn't read it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



:) In any case, the fourcc should be SVQ3 and not SMI, regardless of 
what MPlayer is doing.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: SMI to SVQ3

[Carl Eugen Hoyos]

Mats Peterson  ffmpeg.org> writes:

[...]

The patch is ok, the commit message not:
This is not related to MPlayer but old 
lavf producing broken files.
The codec_tag SMI does not exist, SVQ3 
should be exported.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: SMI to SVQ3

[Mats Peterson]

On 01/06/2016 11:53 AM, Mats Peterson wrote:

FFmpeg still writes broken mkv files, for the record. It doesn't include
the palette, if any, in the stsd atom. But that's a later issue, one
that I'm currently not concerned about since I use mkvmerge to remux.



That's just one of the QuickTime to Matroska remuxing issues. But then 
again, I use mkvmerge, which is currently the safest alternative in 
order to procuce a working Matroska file from a QuickTime file.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2] Enable dash output to work when the output isn't a local file

[Raymond Hilseth]

Use avpriv_io_move instead of ff_rename to support more than only
the file protocol.

Enabled the implementation of file_move in libavformat/file.c for
systems not having unistd.h since it only requires the rename function
from os_support.h.

Signed-off-by: Raymond Hilseth 
---
 libavformat/dashenc.c | 4 ++--
 libavformat/file.c| 4 
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 4509ee4..378c4e4 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -549,7 +549,7 @@ static int write_manifest(AVFormatContext *s, int final)
 avio_printf(out, "\n");
 avio_flush(out);
 avio_close(out);
-return ff_rename(temp_filename, s->filename, s);
+return avpriv_io_move(temp_filename, s->filename);
 }
 
 static int dash_write_header(AVFormatContext *s)
@@ -856,7 +856,7 @@ static int dash_flush(AVFormatContext *s, int final, int 
stream)
 } else {
 ffurl_close(os->out);
 os->out = NULL;
-ret = ff_rename(temp_path, full_path, s);
+ret = avpriv_io_move(temp_path, full_path);
 if (ret < 0)
 break;
 }
diff --git a/libavformat/file.c b/libavformat/file.c
index a318408..e56ea79 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -176,7 +176,6 @@ static int file_delete(URLContext *h)
 
 static int file_move(URLContext *h_src, URLContext *h_dst)
 {
-#if HAVE_UNISTD_H
 const char *filename_src = h_src->filename;
 const char *filename_dst = h_dst->filename;
 av_strstart(filename_src, "file:", _src);
@@ -186,9 +185,6 @@ static int file_move(URLContext *h_src, URLContext *h_dst)
 return AVERROR(errno);
 
 return 0;
-#else
-return AVERROR(ENOSYS);
-#endif /* HAVE_UNISTD_H */
 }
 
 #if CONFIG_FILE_PROTOCOL
-- 
2.4.3

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

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: SMI to SVQ3

[wm4]

On Wed, 6 Jan 2016 11:20:25 +0100
Mats Peterson  wrote:

> On 01/06/2016 11:16 AM, Mats Peterson wrote:
> > On 01/06/2016 11:12 AM, Mats Peterson wrote:  
> >> On 01/06/2016 11:06 AM, Carl Eugen Hoyos wrote:  
> >>> Mats Peterson  ffmpeg.org> writes:
> >>>
> >>> [...]
> >>>
> >>> The patch is ok, the commit message not:
> >>> This is not related to MPlayer but old
> >>> lavf producing broken files.
> >>> The codec_tag SMI does not exist, SVQ3
> >>> should be exported.
> >>>
> >>> Carl Eugen
> >>>
> >>> ___
> >>> ffmpeg-devel mailing list
> >>> ffmpeg-devel@ffmpeg.org
> >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>>  
> >>
> >> I think you should wait with your statements until you've tried things,
> >> Carl. The old (broken) "SMI" file output-ffmpeg-20140109-git-c0a33c4.mkv
> >> (Google for it), which is actually SVQ3, playsi without video in
> >> MPlayer. It complains at not finding a 'SMI ' codec.
> >>
> >>
> >> Mats
> >>  
> >
> > Or the fourcc 0x20494d53 rather.  (' ', 'I', 'M', 'S').
> >
> > Mats
> >  
> 
> You're welcome to fix this issue on the MPlayer side, since it seems 
> you've done that before.

Uh. You know, they accept patches, just like FFmpeg.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: SMI to SVQ3

[wm4]

On Wed, 6 Jan 2016 04:33:16 +0100
Mats Peterson  wrote:

> At least in this case, MPlayer seems to look at the codec tag rather
> than the codec ID in order to determine the codec. Therefore, the
> 'fourcc' variable needs to be set to 'SVQ3' as well, which is later
> copied to st->codec->codec_tag in matroskadec.c.

You should fix mplayer instead. FFmpeg API users are not supposed to
use fourcc fields to identify codecs. The fourcc variable in
matroskadec.c is copied to AVCodecContext.codec_tag, which is not
necessarily a fourcc (depends on the CODEC_ID; most time it's unused),
and the svq3 decoder in libavcodec doesn't read it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: SMI to SVQ3

[Mats Peterson]

On 01/06/2016 11:16 AM, Mats Peterson wrote:

On 01/06/2016 11:12 AM, Mats Peterson wrote:

On 01/06/2016 11:06 AM, Carl Eugen Hoyos wrote:

Mats Peterson  ffmpeg.org> writes:

[...]

The patch is ok, the commit message not:
This is not related to MPlayer but old
lavf producing broken files.
The codec_tag SMI does not exist, SVQ3
should be exported.

Carl Eugen

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



I think you should wait with your statements until you've tried things,
Carl. The old (broken) "SMI" file output-ffmpeg-20140109-git-c0a33c4.mkv
(Google for it), which is actually SVQ3, playsi without video in
MPlayer. It complains at not finding a 'SMI ' codec.


Mats



Or the fourcc 0x20494d53 rather.  (' ', 'I', 'M', 'S').

Mats



You're welcome to fix this issue on the MPlayer side, since it seems 
you've done that before.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: SMI to SVQ3

[Mats Peterson]

On 01/06/2016 11:32 AM, wm4 wrote:


Uh. You know, they accept patches, just like FFmpeg.

You don't say.

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

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: SMI to SVQ3

[Mats Peterson]

On 01/06/2016 10:53 AM, Paul B Mahol wrote:


Yes, fix broken MPlayer instead.

Me? :) Hardly.

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

Re: [FFmpeg-devel] [PATCH] avfilter: add ahistogram multimedia filter

[Moritz Barsnick]

On Tue, Jan 05, 2016 at 21:36:20 +0100, Moritz Barsnick wrote:
> This is not the first of your filters where you describe a parameter as
> a "percentage", but expect a float value [0, 1]. That is extremely
> confusing, if not even wrong. To me, a percentage covers [0, 100]. You
> need to find a different term for the "factor" ranging from zero to
> one.

Sorry, that was an unfair remark, as my memory failed me. The commit I
was primarily referring to was by a different author.

I see this use in the tremolo, vibrato, chromakey, colorkey filters,
while several others use the term percentage for something with a [0,
100] full range.

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

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: SMI to SVQ3

[Michael Niedermayer]

On Wed, Jan 06, 2016 at 10:26:08AM +, Carl Eugen Hoyos wrote:
> Mats Peterson  ffmpeg.org> writes:
> 
> > You're welcome to fix this issue on the MPlayer side, 
> > since it seems you've done that before.
> 
> If there were a fourcc (or codec_tag) "SMI " this 
> would be trivial to fix in MPlayer.
> But this codec_tag does not exist, FFmpeg used to 
> write broken mkv files that contained only part 
> of the stsd atom.

> "Your" patch is correct, the codec_tag for mkv files 
> containing SVQ3 should be "SVQ3".

fixed the commit message and applied

thx

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: SMI to SVQ3

[Mats Peterson]

On 01/06/2016 02:45 PM, Michael Niedermayer wrote:

On Wed, Jan 06, 2016 at 10:26:08AM +, Carl Eugen Hoyos wrote:

Mats Peterson  ffmpeg.org> writes:


You're welcome to fix this issue on the MPlayer side,
since it seems you've done that before.


If there were a fourcc (or codec_tag) "SMI " this
would be trivial to fix in MPlayer.
But this codec_tag does not exist, FFmpeg used to
write broken mkv files that contained only part
of the stsd atom.



"Your" patch is correct, the codec_tag for mkv files
containing SVQ3 should be "SVQ3".


fixed the commit message and applied

thx

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire



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



Thanks. Only the AV_CODEC_ID_NONE patches for matroskadec.c and mov.c 
left ;)


Mats

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

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: SMI to SVQ3

[Mats Peterson]

On 01/06/2016 11:53 AM, Mats Peterson wrote:

FFmpeg still writes broken mkv files, for the record. It doesn't include
the palette, if any, in the stsd atom. But that's a later issue, one
that I'm currently not concerned about since I use mkvmerge to remux.


To be perfectly clear, the private data in Matroska doesn't contain the 
whole stsd atom, but the *sample description*, which is *part* of the 
stsd atom.


Mats

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

Re: [FFmpeg-devel] [PATCH] avfilter/formats: fix leak of formats on error

[Michael Niedermayer]

On Tue, Jan 05, 2016 at 01:39:48PM -0800, Ganesh Ajjanagadde wrote:
> On Tue, Jan 5, 2016 at 12:11 PM, Paul B Mahol  wrote:
> > Signed-off-by: Paul B Mahol 
> > ---
> >  libavfilter/formats.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/libavfilter/formats.c b/libavfilter/formats.c
> > index a2b19e7..f12dcf4 100644
> > --- a/libavfilter/formats.c
> > +++ b/libavfilter/formats.c
> > @@ -518,6 +518,8 @@ void ff_formats_changeref(AVFilterFormats **oldref, 
> > AVFilterFormats **newref)
> >  int ret = ref_fn(fmts, >inputs[i]->out_fmts);  \
> >  if (ret < 0) {  \
> >  unref_fn();\
> > +av_freep(>list);  \
> > +av_freep();\
> >  return ret; \
> >  }   \
> >  count++;\
> > @@ -528,6 +530,8 @@ void ff_formats_changeref(AVFilterFormats **oldref, 
> > AVFilterFormats **newref)
> >  int ret = ref_fn(fmts, >outputs[i]->in_fmts);  \
> >  if (ret < 0) {  \
> >  unref_fn();\
> > +av_freep(>list);  \
> > +av_freep();\
> >  return ret; \
> >  }   \
> >  count++;\
> 
> This is a good effort, and I favor it. However, note that no matter
> what is done here (ie at the API level in avfilter/formats), it will
> not fix all possible error paths in the filters as far as I can tell.
> The reason roughly boils down to the calls being able to free their
> own stuff on failure, but they are not able to free other things, e.g
> samplerates functions can't free channel layouts.
> 

> Or put in other words, if one wants to be absolutely correct, a ton of
> filters will need updating unfortunately.

i think it would be better to libavfilter cleanup instead of each
filter duplicating cleanup code.
If this needs API extensions somewhere, i dont think thats a problem


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

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] avfilter/formats: fix leak of formats on error

[Nicolas George]

Le septidi 17 nivôse, an CCXXIV, Michael Niedermayer a écrit :
> i think it would be better to libavfilter cleanup instead of each
> filter duplicating cleanup code.

This is already done: allocated data that was successfully stored in the
structure is freed, in this instance in the free_link() function.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libstagefright

[Matthieu Bouron]

On Wed, Jan 6, 2016 at 3:45 PM, Derek Buitenhuis  wrote:

> On 1/5/2016 9:58 AM, Carl Eugen Hoyos wrote:
> > So perhaps libstagefright should be removed once your
> > patch hits the git repo?
>
> I would like to push this today if people are OK with it.
>
> Personally I think it's better to push it before, since,
> as per paragraph #2, it promotes incorrect info / cargo-culting.
>

I'm OK with that.

Matthieu

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

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libstagefright

[Derek Buitenhuis]

On 1/5/2016 9:58 AM, Carl Eugen Hoyos wrote:
> So perhaps libstagefright should be removed once your 
> patch hits the git repo?

I would like to push this today if people are OK with it.

Personally I think it's better to push it before, since,
as per paragraph #2, it promotes incorrect info / cargo-culting.

I'll go with whichever is popular opinion. Matthieu, Philip,
Hendrik, wm4, Rostislav, Martin?

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

Re: [FFmpeg-devel] [PATCH] avfilter/formats: fix leak of formats on error

[Paul B Mahol]

On 1/5/16, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/formats.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libavfilter/formats.c b/libavfilter/formats.c
> index a2b19e7..f12dcf4 100644
> --- a/libavfilter/formats.c
> +++ b/libavfilter/formats.c
> @@ -518,6 +518,8 @@ void ff_formats_changeref(AVFilterFormats **oldref,
> AVFilterFormats **newref)
>  int ret = ref_fn(fmts, >inputs[i]->out_fmts);  \
>  if (ret < 0) {  \
>  unref_fn();\
> +av_freep(>list);  \
> +av_freep();\
>  return ret; \
>  }   \
>  count++;\
> @@ -528,6 +530,8 @@ void ff_formats_changeref(AVFilterFormats **oldref,
> AVFilterFormats **newref)
>  int ret = ref_fn(fmts, >outputs[i]->in_fmts);  \
>  if (ret < 0) {  \
>  unref_fn();\
> +av_freep(>list);  \
> +av_freep();\
>  return ret; \
>  }   \
>  count++;\
> --
> 1.9.1
>
>

I will commit this if nobody object. As it fix memory leak.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libstagefright

[Ronald S. Bultje]

Hi,

On Wed, Jan 6, 2016 at 9:45 AM, Derek Buitenhuis  wrote:

> On 1/5/2016 9:58 AM, Carl Eugen Hoyos wrote:
> > So perhaps libstagefright should be removed once your
> > patch hits the git repo?
>
> I would like to push this today if people are OK with it.


I think it's OK. The old implementation will still be available in recent
releases for users of very old Android versions.

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

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

[Daniel Serpell]

Hi!,

El Tue, Jan 05, 2016 at 09:01:40PM -0800, Ganesh Ajjanagadde escribio:
> On Tue, Jan 5, 2016 at 10:46 AM, Ganesh Ajjanagadde  wrote:
> > On Tue, Jan 5, 2016 at 10:10 AM, Daniel Serpell  wrote:
> >> Hi!,
> >>
> >> El Tue, Jan 05, 2016 at 08:08:35AM -0800, Ganesh Ajjanagadde escribio:
> >>> On Tue, Jan 5, 2016 at 7:44 AM, Daniel Serpell  wrote:
> >>> > Hi!,
> >>> >
> >>> > El Mon, Jan 04, 2016 at 06:33:59PM -0800, Ganesh Ajjanagadde escribio:
> >>> >> This exploits an approach based on the sieve of Eratosthenes, a popular
> >>> >> method for generating prime numbers.
> >>> >>
> >>> >> Tables are identical to previous ones.
> >>> >>
> >>> >> Tested with FATE with/without --enable-hardcoded-tables.
> >>> >>
> >>> >> Sample benchmark (Haswell, GNU/Linux+gcc):
> >>> >> prev:
> >>> >> 7860100 decicycles in cbrt_tableinit,   1 runs,  0 skips
> >>> >> 490 decicycles in cbrt_tableinit,   2 runs,  0 skips
> >>> >> [...]
> >>> >> 7582339 decicycles in cbrt_tableinit, 256 runs,  0 skips
> >>> >> 7563556 decicycles in cbrt_tableinit, 512 runs,  0 skips
> >>> >>
> >>> >> new:
> >>> >> 2099480 decicycles in cbrt_tableinit,   1 runs,  0 skips
> >>> >> 2044470 decicycles in cbrt_tableinit,   2 runs,  0 skips
> >>> >> [...]
> >>> >> 1796544 decicycles in cbrt_tableinit, 256 runs,  0 skips
> >>> >> 1791631 decicycles in cbrt_tableinit, 512 runs,  0 skips
> >>> >>
> >>> >
> >>> > See attached code, function "test1", based on an approximation of:
> >>> >
> >>> >   (i+1)^(1/3) ~= i^(1/3) * ( 1 + 1/(3i) - 1/(9i) + 5/(81i) -  )
> [...]
> 
> So I looked up Mr. Fog's manuals, and it seems like divides are
> considerably slower than multiplies and adds. This made me somewhat
> skeptical of your idea, and so I benched it.
> Seems like your patch is actually significantly slower on my setup
> (gcc 5.3.0, GNU libm):
> 3349080 decicycles in cbrt_tableinit,   1 runs,  0 skips
> 3466605 decicycles in cbrt_tableinit,   2 runs,  0 skips
> [...]
> 3425939 decicycles in cbrt_tableinit, 256 runs,  0 skips
> 3414528 decicycles in cbrt_tableinit, 512 runs,  0 skips
> 
> (clang 3.7.0):
> 3337590 decicycles in cbrt_tableinit,   1 runs,  0 skips
> 3276225 decicycles in cbrt_tableinit,   2 runs,  0 skips
> [...]
> 2871065 decicycles in cbrt_tableinit, 256 runs,  0 skips
> 2832137 decicycles in cbrt_tableinit, 512 runs,  0 skips
> 
> The divides seem to be what is killing your approach.
> Times (just for the divisions, clang):
> 1085430 decicycles in cbrt_tableinit,   1 runs,  0 skips
> 1005165 decicycles in cbrt_tableinit,   2 runs,  0 skips
> [...]
>  863732 decicycles in cbrt_tableinit, 256 runs,  0 skips
>  864907 decicycles in cbrt_tableinit, 512 runs,  0 skips
> 
> Another illustration, even if I change the 1.0/(3*i) to simply i to
> get rid of the multiplication as well, obviously not possible but
> really wishful thinking, you still only get:
> (clang)
> 2013390 decicycles in cbrt_tableinit,   1 runs,  0 skips
> 1950135 decicycles in cbrt_tableinit,   2 runs,  0 skips
> [...]
> 1668963 decicycles in cbrt_tableinit, 256 runs,  0 skips
> 1653179 decicycles in cbrt_tableinit, 512 runs,  0 skips
> 
> To complete my curiousity,
> (gcc)
> 1485240 decicycles in cbrt_tableinit,   1 runs,  0 skips
> 1522115 decicycles in cbrt_tableinit,   2 runs,  0 skips
> [...]
> 1324325 decicycles in cbrt_tableinit, 256 runs,  0 skips
> 1322110 decicycles in cbrt_tableinit, 512 runs,  0 skips
> 
> i.e not a whole lot faster than the benchmark I posted.
> 
> If you feel this can't be right, I can do give a higher level
> justification, which shows that for a reasonable libm cbrt, and
> standard architectural assumptions, the approach I have is faster.
> 

Thanks for your tests.

In my PC I measured a higher speedup, perhaps you can replace the main
loop with:

cb = 7;
for(i=343; i<8192; i++)
{
double s, r, t;
out[i] = cb * i;
// For big values, we use 4 terms:
r = (1.0/3.0)/i;  // 0 A , 1 M , 1 D
t = r;//
s = 1.0 + r;  // 1 A , 1 M , 1 D
r = r * r;// 1 A , 2 M , 1 D
s = s - r;// 2 A , 2 M , 1 D
r = r * t;// 2 A , 3 M , 1 D
s = s + 1.6644 *r;// 3 A , 4 M , 1 D
cb = cb * s;  // 3 A , 5 M , 1 D
}


I know that divisions are considerably slower than multiplications, but
at least in my PC, the following is slower still (based on newton's
method):

// "cb" is the cube-root approximation to "1/i²"
cb = 1.0/49.0;
for(i=343; i<8192; i++)
{
double s = cb*cb*i;
cb = (1.0/3.0) * (4*cb - s*s);
s = cb*cb*i;
cb = (1.0/3.0) * (4*cb - s*s);
out[i] = cb * i * i;

Re: [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

[foo86]

On Wed, Jan 06, 2016 at 12:28:00AM +0100, Hendrik Leppkes wrote:
> So that leaves us with a bunch of positive comments, on this side
> anyway, and noone opposed yet.
> 
> Arguments for a switch include:
> - Nearly complete coverage of all DTS features, well tested and
> confirmed bit-exact (only DTS Express is missing, which is technically
> its own little codec using DTS EXSS headers)
> - Slightly faster (~5%)
> - Active maintainer
> - Andreas seal of security approval ;)
> 
> If anyone thinks we should not replace our decoder, speak now or
> forever hold your peace (and bring proper arguments).
> I will try to do a code review to the best of my abilities in the upcoming 
> days.
> 
> foo86, could you work on changing the patch to replace the original instead?
> 
> After it is merged, we could think about integrating your test-suite
> into the FATE system, but all in good time.

OK, I'll start changing the patch.

Some questions so far:

1. Should I remove old decoder files in separate commit first or should
I simply proceed with replacing entire content of certain files (e.g.,
dcadec.c, dca_exss.c, dca_xll.c)?

2. Is it OK to leave arch-specific dca code as well as dcadsp.c
untouched for now? I'd really like to postpone dealing with that until
I'm done with generic code, especially since the new decoder is not
slower already. This means some assembly functions (ff_dca_lfe_fir32_*,
ff_dca_qmf_32_subbands_*) will still be compiled in but unused.
libavcodec/dcadsp.c will be still around but not compiled.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

[Carl Eugen Hoyos]

foo86  gmail.com> writes:

> 1. Should I remove old decoder files in separate 
> commit first

Please do that, it makes the diff much easier to 
read afaict,

> 2. Is it OK to leave arch-specific dca code as 
> well as dcadsp.c untouched for now?

Only if you believe that this makes your future 
work easier;-)

Carl Eugen

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

Re: [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

[James Almer]

On 1/6/2016 2:32 PM, foo86 wrote:
> On Wed, Jan 06, 2016 at 12:28:00AM +0100, Hendrik Leppkes wrote:
>> So that leaves us with a bunch of positive comments, on this side
>> anyway, and noone opposed yet.
>>
>> Arguments for a switch include:
>> - Nearly complete coverage of all DTS features, well tested and
>> confirmed bit-exact (only DTS Express is missing, which is technically
>> its own little codec using DTS EXSS headers)
>> - Slightly faster (~5%)
>> - Active maintainer
>> - Andreas seal of security approval ;)
>>
>> If anyone thinks we should not replace our decoder, speak now or
>> forever hold your peace (and bring proper arguments).
>> I will try to do a code review to the best of my abilities in the upcoming 
>> days.
>>
>> foo86, could you work on changing the patch to replace the original instead?
>>
>> After it is merged, we could think about integrating your test-suite
>> into the FATE system, but all in good time.
> 
> OK, I'll start changing the patch.
> 
> Some questions so far:
> 
> 1. Should I remove old decoder files in separate commit first or should
> I simply proceed with replacing entire content of certain files (e.g.,
> dcadec.c, dca_exss.c, dca_xll.c)?

Yeah, send it as separate patches to make reviewing easier. Whoever commits it
can then squash it into a single patch (Like it was done in commit b08569a2) if
necessary.

Also, while at it, try to split the main header into separate headers for some
of the modules (xll, exss, dsp which already exists for the old decoder, etc).

> 
> 2. Is it OK to leave arch-specific dca code as well as dcadsp.c
> untouched for now? I'd really like to postpone dealing with that until
> I'm done with generic code, especially since the new decoder is not
> slower already. This means some assembly functions (ff_dca_lfe_fir32_*,
> ff_dca_qmf_32_subbands_*) will still be compiled in but unused.
> libavcodec/dcadsp.c will be still around but not compiled.

Try to disable or remove code that will not be used. Git will easily let you
recover any of it in the future if needed.
Better than keeping dead code in the tree, IMO, but do what you think will make
your work easier.

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

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

Re: [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

[Christophe Gisquet]

Hi,

2016-01-06 18:32 GMT+01:00 foo86 :
> dca dca2libdcadec
> System 1:   0:11.90 0:11.16 0:19.73
> System 2:   0:57.00 0:55.23 1:21.33
> System 3:   7:41.31 7:00.84 13:16.70

Just to be sure, because I won't check myself: is this an
apple-to-apple comparison for dca vs dca2? I mean, things like
favorable/native output format, eg without conversion, etc ?

> The new decoder appears slightly faster than dca even though it doesn't
> use any assembly optimized code for dcadsp (besides synth_filter).

synth_filter was in my benchmarks (2? years ago, on a non-avx2 system
with 5.1 core dts) around 50% of the execution time. It's good that it
can be reused, but people have "suffered" using dca without it for
near a decade, so they'll probably handle waiting another decade for
it to be rewritten if it needs to be.

But the other parts of dcadsp are probably contributing less than 10%,
so dca2 looks good.

And anyhow, seeing the enthusiastic support for your version,
performance is probably secondary to a lot of people.

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

Re: [FFmpeg-devel] [PATCH v5 1/4] mips: improve detection of ISAs, FPU and ASEs (DSP, MSA)

[Michael Niedermayer]

On Wed, Jan 06, 2016 at 04:55:26PM +, Vicente Olivert Riera wrote:
> Signed-off-by: Vicente Olivert Riera 
> ---
> Changes v4 -> v5:
>  - Check for msa.h and disable msa if not found.
> 
> Changes v3 -> v4:
>  - Nothing.
> 
> Changes v2 -> v3:
>  - Nothing.
> 
> Changes v1 -> v2:
>  - Add a block of code for mipsdspr2 which was previously placed in the
>first patch of this series causing a syntax error in the configure
>script.
>https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183444.html
> 
>  configure | 85 
> +--
>  1 file changed, 67 insertions(+), 18 deletions(-)

still fails to build:
make distclean ; ../configure  --cross-prefix=/usr/mips-linux-gnu/bin/ 
--cc='ccache mips-linux-gnu-gcc-4.4' --arch=mips --target-os=linux 
--enable-cross-compile && make -j12
...
CC  libavcodec/mips/aaccoder_mips.o
Assembler messages:
Warning: mips1 ISA does not support DSP ASE
Warning: mips1 ISA does not support DSP R2 ASE
/tmp/ccAm9ayd.s:320: Error: opcode not supported on this processor: mips1 
(mips1) `movn $4,$24,$12'
/tmp/ccAm9ayd.s:321: Error: opcode not supported on this processor: mips1 
(mips1) `movn $9,$25,$13'
/tmp/ccAm9ayd.s:322: Error: opcode not supported on this processor: mips1 
(mips1) `movn $8,$16,$14'
/tmp/ccAm9ayd.s:323: Error: opcode not supported on this processor: mips1 
(mips1) `movn $5,$17,$15'
/tmp/ccAm9ayd.s:509: Error: opcode not supported on this processor: mips1 
(mips1) `movn $4,$24,$11'
/tmp/ccAm9ayd.s:510: Error: opcode not supported on this processor: mips1 
(mips1) `movn $8,$24,$13'
/tmp/ccAm9ayd.s:511: Error: opcode not supported on this processor: mips1 
(mips1) `movn $6,$24,$14'
/tmp/ccAm9ayd.s:512: Error: opcode not supported on this processor: mips1 
(mips1) `movn $5,$24,$15'
/tmp/ccAm9ayd.s:707: Error: opcode not supported on this processor: mips1 
(mips1) `movn $5,$24,$12'
/tmp/ccAm9ayd.s:708: Error: opcode not supported on this processor: mips1 
(mips1) `movn $9,$24,$13'
/tmp/ccAm9ayd.s:709: Error: opcode not supported on this processor: mips1 
(mips1) `movn $4,$24,$14'
/tmp/ccAm9ayd.s:710: Error: opcode not supported on this processor: mips1 
(mips1) `movn $8,$24,$15'
/tmp/ccAm9ayd.s:723: Error: opcode not supported on this processor: mips1 
(mips1) `movn $5,$24,$12'
...

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

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


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

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libstagefright

[Derek Buitenhuis]

On 1/6/2016 3:51 PM, Matthieu Bouron wrote:
> I'm OK with that.

Pushed with commit message changed, as per Martin.

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

Re: [FFmpeg-devel] [PATCH v4 11/14] mips: do not disable any feature for generic cores

[Vicente Olivert Riera]

Dear Andreas Cadhalpun and Michael Niedermayer,

On 30/12/15 21:02, Andreas Cadhalpun wrote:

On 30.12.2015 20:35, Michael Niedermayer wrote:

On Fri, Dec 04, 2015 at 03:48:27PM +, Vicente Olivert Riera wrote:

We don't know which features are available when the user selects a
generic core, so don't disable anything by default and let the user
decide.

Signed-off-by: Vicente Olivert Riera 
---
Changes v3 -> v4:
  - Minor change in the commit log: remove "let's".

Changes v2 -> v3:
  - Change the logic of this patch. Instead of removing the generic core,
do not disable any feature and add a warning message to state that.
The patch subject has also changed accordingly.

Changes v1 -> v2:
  - Nothing.


  configure | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 8bd47b9..2ee10db 100755
--- a/configure
+++ b/configure
@@ -4159,8 +4159,8 @@ elif enabled mips; then
  esac
  ;;
  generic)
-disable mips64r6
-disable msa
+# We do not disable anything. Is up to the user to disable
+# the unwanted features.


i just noticed now but this breaks build


That explains, why it got disabled here.


make distclean ; ./configure --cross-prefix=/usr/mips-linux-gnu/bin/ --cc='ccache 
mips-linux-gnu-gcc-4.4' --arch=mips --target-os=linux --enable-cross-compile && 
make -j12

CC  libavcodec/mips/blockdsp_msa.o
In file included from ffmpeg/libavcodec/mips/blockdsp_msa.c:21:
ffmpeg/libavutil/mips/generic_macros_msa.h:25:17: warning: msa.h: No such file 
or directory


This looks like configure should check for msa.h and disable msa
if that header is not found.


yes, and it's better to reorder the remaining patches and apply the one 
who improves the detection of the ISAs, FPU and ASEs (DSP, MSA) first. I 
will re-send that 4-patch series.


Regards,

Vincent.


Best regards,
Andreas


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

Re: [FFmpeg-devel] [PATCH] avfilter/formats: fix leak of formats on error

[Ganesh Ajjanagadde]

On Wed, Jan 6, 2016 at 6:43 AM, Nicolas George  wrote:
> Le septidi 17 nivôse, an CCXXIV, Michael Niedermayer a écrit :
>> i think it would be better to libavfilter cleanup instead of each
>> filter duplicating cleanup code.
>
> This is already done: allocated data that was successfully stored in the
> structure is freed, in this instance in the free_link() function.

Hmm, ok. Then maybe this does take care of the remaining issues. Will
wait and check once this patch goes in.

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

[FFmpeg-devel] [PATCH v5 3/4] mips: add support for R6

[Vicente Olivert Riera]

Understanding the mips32r6 and mips64r6 ISAs in the configure script is
not enough. In order to have full support for MIPS R6 in FFmpeg we need
to be able to build it, and for that we need to make sure we don't use
incompatible assembler code which makes the build fail. Ifdefing the
offending code is sufficient to fix the problem.

Signed-off-by: Vicente Olivert Riera 
---
Changes v4 -> v5:
 - Nothing.

Changes v3 -> v4:
 - Nothing.

Changes v2 -> v3:
 - Nothing.

Changes v1 -> v2:
 - Nothing.

 libavcodec/mips/aaccoder_mips.c   |  4 
 libavcodec/mips/aacdec_mips.h |  2 ++
 libavcodec/mips/aacpsdsp_mips.c   |  4 
 libavcodec/mips/aacpsy_mips.h |  2 ++
 libavcodec/mips/aacsbr_mips.c |  4 
 libavcodec/mips/aacsbr_mips.h |  2 ++
 libavcodec/mips/ac3dsp_mips.c |  6 +-
 libavcodec/mips/acelp_filters_mips.c  |  4 
 libavcodec/mips/acelp_vectors_mips.c  |  4 
 libavcodec/mips/amrwbdec_mips.c   |  2 ++
 libavcodec/mips/amrwbdec_mips.h   |  2 ++
 libavcodec/mips/celp_filters_mips.c   |  4 
 libavcodec/mips/celp_math_mips.c  |  4 
 libavcodec/mips/compute_antialias_float.h |  2 ++
 libavcodec/mips/fft_mips.c|  4 
 libavcodec/mips/iirfilter_mips.c  |  4 
 libavcodec/mips/lsp_mips.h|  2 ++
 libavcodec/mips/mpegaudiodsp_mips_fixed.c | 10 ++
 libavcodec/mips/mpegaudiodsp_mips_float.c | 10 ++
 libavcodec/mips/sbrdsp_mips.c |  4 
 libavutil/mips/float_dsp_mips.c   |  4 
 21 files changed, 83 insertions(+), 1 deletion(-)

diff --git a/libavcodec/mips/aaccoder_mips.c b/libavcodec/mips/aaccoder_mips.c
index 04b3dca..3ebd776 100644
--- a/libavcodec/mips/aaccoder_mips.c
+++ b/libavcodec/mips/aaccoder_mips.c
@@ -66,6 +66,7 @@
 #include "libavcodec/aacenc_utils.h"
 
 #if HAVE_INLINE_ASM
+#if !HAVE_MIPS32R6 && !HAVE_MIPS64R6
 typedef struct BandCodingPath {
 int prev_idx;
 float cost;
@@ -2474,10 +2475,12 @@ static void search_for_ms_mips(AACEncContext *s, 
ChannelElement *cpe)
 
 #include "libavcodec/aaccoder_trellis.h"
 
+#endif /* !HAVE_MIPS32R6 && !HAVE_MIPS64R6 */
 #endif /* HAVE_INLINE_ASM */
 
 void ff_aac_coder_init_mips(AACEncContext *c) {
 #if HAVE_INLINE_ASM
+#if !HAVE_MIPS32R6 && !HAVE_MIPS64R6
 AACCoefficientsEncoder *e = c->coder;
 int option = c->options.coder;
 
@@ -2491,5 +2494,6 @@ void ff_aac_coder_init_mips(AACEncContext *c) {
 #if HAVE_MIPSFPU
 e->search_for_ms= search_for_ms_mips;
 #endif /* HAVE_MIPSFPU */
+#endif /* !HAVE_MIPS32R6 && !HAVE_MIPS64R6 */
 #endif /* HAVE_INLINE_ASM */
 }
diff --git a/libavcodec/mips/aacdec_mips.h b/libavcodec/mips/aacdec_mips.h
index 054a9fb..0c2b243 100644
--- a/libavcodec/mips/aacdec_mips.h
+++ b/libavcodec/mips/aacdec_mips.h
@@ -61,6 +61,7 @@
 #include "libavutil/mips/asmdefs.h"
 
 #if HAVE_INLINE_ASM && HAVE_MIPSFPU
+#if !HAVE_MIPS32R6 && !HAVE_MIPS64R6
 static inline float *VMUL2_mips(float *dst, const float *v, unsigned idx,
const float *scale)
 {
@@ -246,6 +247,7 @@ static inline float *VMUL4S_mips(float *dst, const float 
*v, unsigned idx,
 #define VMUL4 VMUL4_mips
 #define VMUL2S VMUL2S_mips
 #define VMUL4S VMUL4S_mips
+#endif /* !HAVE_MIPS32R6 && !HAVE_MIPS64R6 */
 #endif /* HAVE_INLINE_ASM && HAVE_MIPSFPU */
 
 #endif /* AVCODEC_MIPS_AACDEC_FLOAT_H */
diff --git a/libavcodec/mips/aacpsdsp_mips.c b/libavcodec/mips/aacpsdsp_mips.c
index 695f9ef..83fdc2f 100644
--- a/libavcodec/mips/aacpsdsp_mips.c
+++ b/libavcodec/mips/aacpsdsp_mips.c
@@ -188,6 +188,7 @@ static void ps_hybrid_synthesis_deint_mips(float 
out[2][38][64],
 }
 
 #if HAVE_MIPSFPU
+#if !HAVE_MIPS32R6 && !HAVE_MIPS64R6
 static void ps_add_squares_mips(float *dst, const float (*src)[2], int n)
 {
 int i;
@@ -442,6 +443,7 @@ static void ps_stereo_interpolate_mips(float (*l)[2], float 
(*r)[2],
 : "memory"
 );
 }
+#endif /* !HAVE_MIPS32R6 && !HAVE_MIPS64R6 */
 #endif /* HAVE_MIPSFPU */
 #endif /* HAVE_INLINE_ASM */
 
@@ -451,10 +453,12 @@ void ff_psdsp_init_mips(PSDSPContext *s)
 s->hybrid_analysis_ileave = ps_hybrid_analysis_ileave_mips;
 s->hybrid_synthesis_deint = ps_hybrid_synthesis_deint_mips;
 #if HAVE_MIPSFPU
+#if !HAVE_MIPS32R6 && !HAVE_MIPS64R6
 s->add_squares= ps_add_squares_mips;
 s->mul_pair_single= ps_mul_pair_single_mips;
 s->decorrelate= ps_decorrelate_mips;
 s->stereo_interpolate[0]  = ps_stereo_interpolate_mips;
+#endif /* !HAVE_MIPS32R6 && !HAVE_MIPS64R6 */
 #endif /* HAVE_MIPSFPU */
 #endif /* HAVE_INLINE_ASM */
 }
diff --git a/libavcodec/mips/aacpsy_mips.h b/libavcodec/mips/aacpsy_mips.h
index 42ff442..a1fe5cc 100644
--- a/libavcodec/mips/aacpsy_mips.h
+++ b/libavcodec/mips/aacpsy_mips.h
@@ -59,6 +59,7 @@
 #include "libavutil/mips/asmdefs.h"
 
 #if HAVE_INLINE_ASM && HAVE_MIPSFPU && ( PSY_LAME_FIR_LEN == 

[FFmpeg-devel] [PATCH v5 4/4] mips: display a warning message when using an unknown CPU

[Vicente Olivert Riera]

Signed-off-by: Vicente Olivert Riera 
---
Changes v4 -> v5:
 - Nothing.

Changes v3 -> v4:
 - Use a more accurate warning message.

Changes v2 -> v3:
 - This patch has been added for v3.

Changes v1 -> v2:
 - This patch didn't exist at that point.

 configure | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configure b/configure
index b6ca84d..9e1e615 100755
--- a/configure
+++ b/configure
@@ -4241,6 +4241,8 @@ elif enabled mips; then
 # the unwanted features.
 ;;
 *)
+# Unknown CPU. Disable everything.
+echo "Warning: unknown CPU. Disabling all MIPS optimizations."
 disable mipsfpu
 disable mips32r2
 disable mips32r6
-- 
2.4.10

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

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

[Ganesh Ajjanagadde]

On Wed, Jan 6, 2016 at 7:38 AM, Daniel Serpell  wrote:
> Hi!,
>
> El Tue, Jan 05, 2016 at 09:01:40PM -0800, Ganesh Ajjanagadde escribio:
>> On Tue, Jan 5, 2016 at 10:46 AM, Ganesh Ajjanagadde  wrote:
>> > On Tue, Jan 5, 2016 at 10:10 AM, Daniel Serpell  wrote:
>> >> Hi!,
>> >>
>> >> El Tue, Jan 05, 2016 at 08:08:35AM -0800, Ganesh Ajjanagadde escribio:
>> >>> On Tue, Jan 5, 2016 at 7:44 AM, Daniel Serpell  
>> >>> wrote:
>> >>> > Hi!,
>> >>> >
>> >>> > El Mon, Jan 04, 2016 at 06:33:59PM -0800, Ganesh Ajjanagadde escribio:
>> >>> >> This exploits an approach based on the sieve of Eratosthenes, a 
>> >>> >> popular
>> >>> >> method for generating prime numbers.
>> >>> >>
>> >>> >> Tables are identical to previous ones.
>> >>> >>
>> >>> >> Tested with FATE with/without --enable-hardcoded-tables.
>> >>> >>
>> >>> >> Sample benchmark (Haswell, GNU/Linux+gcc):
>> >>> >> prev:
>> >>> >> 7860100 decicycles in cbrt_tableinit,   1 runs,  0 skips
>> >>> >> 490 decicycles in cbrt_tableinit,   2 runs,  0 skips
>> >>> >> [...]
>> >>> >> 7582339 decicycles in cbrt_tableinit, 256 runs,  0 skips
>> >>> >> 7563556 decicycles in cbrt_tableinit, 512 runs,  0 skips
>> >>> >>
>> >>> >> new:
>> >>> >> 2099480 decicycles in cbrt_tableinit,   1 runs,  0 skips
>> >>> >> 2044470 decicycles in cbrt_tableinit,   2 runs,  0 skips
>> >>> >> [...]
>> >>> >> 1796544 decicycles in cbrt_tableinit, 256 runs,  0 skips
>> >>> >> 1791631 decicycles in cbrt_tableinit, 512 runs,  0 skips
>> >>> >>
>> >>> >
>> >>> > See attached code, function "test1", based on an approximation of:
>> >>> >
>> >>> >   (i+1)^(1/3) ~= i^(1/3) * ( 1 + 1/(3i) - 1/(9i) + 5/(81i) -  )
>> [...]
>>
>> So I looked up Mr. Fog's manuals, and it seems like divides are
>> considerably slower than multiplies and adds. This made me somewhat
>> skeptical of your idea, and so I benched it.
>> Seems like your patch is actually significantly slower on my setup
>> (gcc 5.3.0, GNU libm):
>> 3349080 decicycles in cbrt_tableinit,   1 runs,  0 skips
>> 3466605 decicycles in cbrt_tableinit,   2 runs,  0 skips
>> [...]
>> 3425939 decicycles in cbrt_tableinit, 256 runs,  0 skips
>> 3414528 decicycles in cbrt_tableinit, 512 runs,  0 skips
>>
>> (clang 3.7.0):
>> 3337590 decicycles in cbrt_tableinit,   1 runs,  0 skips
>> 3276225 decicycles in cbrt_tableinit,   2 runs,  0 skips
>> [...]
>> 2871065 decicycles in cbrt_tableinit, 256 runs,  0 skips
>> 2832137 decicycles in cbrt_tableinit, 512 runs,  0 skips
>>
>> The divides seem to be what is killing your approach.
>> Times (just for the divisions, clang):
>> 1085430 decicycles in cbrt_tableinit,   1 runs,  0 skips
>> 1005165 decicycles in cbrt_tableinit,   2 runs,  0 skips
>> [...]
>>  863732 decicycles in cbrt_tableinit, 256 runs,  0 skips
>>  864907 decicycles in cbrt_tableinit, 512 runs,  0 skips
>>
>> Another illustration, even if I change the 1.0/(3*i) to simply i to
>> get rid of the multiplication as well, obviously not possible but
>> really wishful thinking, you still only get:
>> (clang)
>> 2013390 decicycles in cbrt_tableinit,   1 runs,  0 skips
>> 1950135 decicycles in cbrt_tableinit,   2 runs,  0 skips
>> [...]
>> 1668963 decicycles in cbrt_tableinit, 256 runs,  0 skips
>> 1653179 decicycles in cbrt_tableinit, 512 runs,  0 skips
>>
>> To complete my curiousity,
>> (gcc)
>> 1485240 decicycles in cbrt_tableinit,   1 runs,  0 skips
>> 1522115 decicycles in cbrt_tableinit,   2 runs,  0 skips
>> [...]
>> 1324325 decicycles in cbrt_tableinit, 256 runs,  0 skips
>> 1322110 decicycles in cbrt_tableinit, 512 runs,  0 skips
>>
>> i.e not a whole lot faster than the benchmark I posted.
>>
>> If you feel this can't be right, I can do give a higher level
>> justification, which shows that for a reasonable libm cbrt, and
>> standard architectural assumptions, the approach I have is faster.
>>
>
> Thanks for your tests.
>
> In my PC I measured a higher speedup, perhaps you can replace the main
> loop with:
>
> cb = 7;
> for(i=343; i<8192; i++)
> {
> double s, r, t;
> out[i] = cb * i;
> // For big values, we use 4 terms:
> r = (1.0/3.0)/i;  // 0 A , 1 M , 1 D
> t = r;//
> s = 1.0 + r;  // 1 A , 1 M , 1 D
> r = r * r;// 1 A , 2 M , 1 D
> s = s - r;// 2 A , 2 M , 1 D
> r = r * t;// 2 A , 3 M , 1 D
> s = s + 1.6644 *r;// 3 A , 4 M , 1 D
> cb = cb * s;  // 3 A , 5 M , 1 D
> }

All of the below done with gcc.
Better, but still slower than proposed:
2620600 decicycles in cbrt_tableinit,   1 runs,  0 skips
2666850 decicycles in cbrt_tableinit,   2 runs,  0 

Re: [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

[foo86]

On Tue, Jan 05, 2016 at 10:46:19PM +0100, Andreas Cadhalpun wrote:
> OK. This decoder seems to be quite robust in handling fuzzed samples,
> so from a security point of view it should be fine to replace the
> old dca decoder with this one.

Out of interest, did you disable CRC checks in the decoder while fuzzing?
Otherwise testing coverage will be decreased somewhat. The easiest way to do
this is to modify ff_dca2_check_crc() to always return 0.

> Out of curiosity: Can you post a few benchmarks comparing the performance
> of the old and the new decoder?

Here are some benchmarks I did with 3 available decoders on 3 different
systems: (1) x86_64 desktop, (2) ancient i386 laptop, (3) Raspberry Pi Model
B+.

Measuring how much time it takes to loop 2000 times over a short 5.1
channel core sample (for a total duration of 00:51:56.22) yields the
following results:

dca dca2libdcadec
System 1:   0:11.90 0:11.16 0:19.73
System 2:   0:57.00 0:55.23 1:21.33
System 3:   7:41.31 7:00.84 13:16.70

The new decoder appears slightly faster than dca even though it doesn't
use any assembly optimized code for dcadsp (besides synth_filter).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v5 2/4] mips: do not disable any feature for generic cores

[Vicente Olivert Riera]

We don't know which features are available when the user selects a
generic core, so don't disable anything by default and let the user
decide.

Signed-off-by: Vicente Olivert Riera 
---
Changes v4 -> v5:
 - Nothing.

Changes v3 -> v4:
 - Minor change in the commit log: remove "let's".

Changes v2 -> v3:
 - Change the logic of this patch. Instead of removing the generic core,
   do not disable any feature and add a warning message to state that.
   The patch subject has also changed accordingly.

Changes v1 -> v2:
 - Nothing.

 configure | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 1cfa31e..b6ca84d 100755
--- a/configure
+++ b/configure
@@ -4237,8 +4237,8 @@ elif enabled mips; then
 esac
 ;;
 generic)
-disable mips64r6
-disable msa
+# We do not disable anything. Is up to the user to disable
+# the unwanted features.
 ;;
 *)
 disable mipsfpu
-- 
2.4.10

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

[FFmpeg-devel] [PATCH v5 1/4] mips: improve detection of ISAs, FPU and ASEs (DSP, MSA)

[Vicente Olivert Riera]

Signed-off-by: Vicente Olivert Riera 
---
Changes v4 -> v5:
 - Check for msa.h and disable msa if not found.

Changes v3 -> v4:
 - Nothing.

Changes v2 -> v3:
 - Nothing.

Changes v1 -> v2:
 - Add a block of code for mipsdspr2 which was previously placed in the
   first patch of this series causing a syntax error in the configure
   script.
   https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183444.html

 configure | 85 +--
 1 file changed, 67 insertions(+), 18 deletions(-)

diff --git a/configure b/configure
index 6710f85..1cfa31e 100755
--- a/configure
+++ b/configure
@@ -5042,27 +5042,76 @@ elif enabled mips; then
 enabled mmi && check_inline_asm mmi '"punpcklhw $f0, $f0, $f0"'
 
 # Enable minimum ISA based on selected options
-if enabled mips64 && (enabled mipsdsp || enabled mipsdspr2); then
-add_cflags "-mips64r2"
-add_asflags "-mips64r2"
-elif enabled mips64 && enabled mipsfpu && disabled loongson2 && disabled 
loongson3; then
-add_cflags "-mips64"
-add_asflags "-mips64"
-elif enabled mipsdsp || enabled mipsdspr2; then
-add_cflags "-mips32r2 -mfp32"
-add_asflags "-mips32r2 -mfp32"
+if enabled mips64; then
+if enabled mips64r6; then
+check_cflags "-mips64r6" &&
+check_ldflags "-mips64r6" &&
+add_asflags "-mips64r6" &&
+check_inline_asm mips64r6 '"dlsa $0, $0, $0, 1"'
+elif enabled mips64r2; then
+check_cflags "-mips64r2" &&
+check_ldflags "-mips64r2" &&
+add_asflags "-mips64r2" &&
+check_inline_asm mips64r2 '"dext $0, $0, 0, 1"'
+else
+check_cflags "-mips64" &&
+check_ldflags "-mips64" &&
+add_asflags "-mips64" &&
+check_inline_asm mips64r1 '"daddi $0, $0, 0"'
+fi
+else
+if enabled mips32r6; then
+check_cflags "-mips32r6" &&
+check_ldflags "-mips32r6" &&
+add_asflags "-mips32r6" &&
+check_inline_asm mips32r6 '"aui $0, $0, 0"'
+elif enabled mips32r2; then
+check_cflags "-mips32r2" &&
+check_ldflags "-mips32r2" &&
+add_asflags "-mips32r2" &&
+check_inline_asm mips32r2 '"ext $0, $0, 0, 1"'
+else
+check_cflags "-mips32" &&
+check_ldflags "-mips32" &&
+add_asflags "-mips32" &&
+check_inline_asm mips32r1 '"addi $0, $0, 0"'
+fi
+fi
+
+# MIPS FPU
+if enabled mipsfpu; then
+add_cflags "-mhard-float" &&
+add_asflags "-mhard-float" &&
+check_inline_asm mipsfpu '"cvt.d.l $f0, $f2"'
 fi
 
-enabled mipsdsp && add_cflags "-mdsp" && add_asflags "-mdsp" &&
- check_inline_asm mipsdsp '"addu.qb $t0, $t1, $t2"'
-enabled mipsdspr2 && add_cflags "-mdspr2" && add_asflags "-mdspr2" &&
- check_inline_asm mipsdspr2 '"absq_s.qb $t0, $t1"'
-enabled mipsfpu   && add_cflags "-mhard-float" && add_asflags 
"-mhard-float" &&
- check_inline_asm mipsfpu   '"madd.d $f0, $f2, $f4, $f6"'
-enabled msa   && check_cflags "-mmsa" && check_ldflags "-mmsa" &&
- check_inline_asm msa   '"addvi.b $w0, $w1, 1"'
+# MSA and DSP support require ISA revision level 2 or greater
+if enabled mips32r2 || enabled mips64r2 || enabled mips32r6 || enabled 
mips64r6; then
+# MSA must be used with -mfp64 and -mhard-float
+if enabled mipsfpu; then
+if enabled msa; then
+check_cflags "-mfp64 -mmsa" &&
+check_ldflags "-mfp64 -mmsa" &&
+add_asflags "-mfp64 -mmsa" &&
+check_inline_asm msa '"addvi.b $w0, $w1, 1"' &&
+check_header msa.h ||
+disable msa
+fi
+else
+disable msa
+fi
 
-enabled msa && add_asflags "-mmsa"
+if enabled mipsdsp; then
+check_cflags "-mdsp" &&
+add_asflags "-mdsp" &&
+check_inline_asm mipsdsp '"addu.qb $t0, $t1, $t2"'
+fi
+if enabled mipsdspr2; then
+check_cflags "-mdspr2" &&
+add_asflags "-mdspr2" &&
+check_inline_asm mipsdspr2 '"absq_s.qb $t0, $t1"'
+fi
+fi
 
 elif enabled parisc; then
 
-- 
2.4.10

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

Re: [FFmpeg-devel] [PATCH] avfilter: add ahistogram multimedia filter

[Ganesh Ajjanagadde]

On Wed, Jan 6, 2016 at 5:36 AM, Moritz Barsnick  wrote:
> On Tue, Jan 05, 2016 at 21:36:20 +0100, Moritz Barsnick wrote:
>> This is not the first of your filters where you describe a parameter as
>> a "percentage", but expect a float value [0, 1]. That is extremely
>> confusing, if not even wrong. To me, a percentage covers [0, 100]. You
>> need to find a different term for the "factor" ranging from zero to
>> one.
>
> Sorry, that was an unfair remark, as my memory failed me. The commit I
> was primarily referring to was by a different author.
>
> I see this use in the tremolo, vibrato, chromakey, colorkey filters,
> while several others use the term percentage for something with a [0,
> 100] full range.

Patch welcome ;).

>
> Moritz
> ___
> 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] A53 Closed Captions in mpeg2video

[Zach Swena]

Hi,

What is the current status of closed captions for mpeg2 video outputs?  I
know caption pass through is supposed to work for libx264, but most ATSC
broadcast is still in mpeg2.  Do we have any timeline on when this part
will be done yet?

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

Re: [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

[Andreas Cadhalpun]

On 06.01.2016 18:32, foo86 wrote:
> On Tue, Jan 05, 2016 at 10:46:19PM +0100, Andreas Cadhalpun wrote:
>> OK. This decoder seems to be quite robust in handling fuzzed samples,
>> so from a security point of view it should be fine to replace the
>> old dca decoder with this one.
> 
> Out of interest, did you disable CRC checks in the decoder while fuzzing?

No, I tested it as is.

> Otherwise testing coverage will be decreased somewhat. The easiest way to do
> this is to modify ff_dca2_check_crc() to always return 0.

I tried this (comment out everything in ff_dca2_check_crc except 'return 0')
and there doesn't seem to be much difference.

>> Out of curiosity: Can you post a few benchmarks comparing the performance
>> of the old and the new decoder?
> 
> Here are some benchmarks I did with 3 available decoders on 3 different
> systems: (1) x86_64 desktop, (2) ancient i386 laptop, (3) Raspberry Pi Model
> B+.
> 
> Measuring how much time it takes to loop 2000 times over a short 5.1
> channel core sample (for a total duration of 00:51:56.22) yields the
> following results:
> 
> dca dca2libdcadec
> System 1:   0:11.90 0:11.16 0:19.73
> System 2:   0:57.00 0:55.23 1:21.33
> System 3:   7:41.31 7:00.84 13:16.70
> 
> The new decoder appears slightly faster than dca even though it doesn't
> use any assembly optimized code for dcadsp (besides synth_filter).

Thanks for sharing these benchmarks. They look quite nice. ;-)

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

Re: [FFmpeg-devel] [PATCH 03/10] libavcodec/ccaption_dec: add calculate_duration option

[Aman Gupta]

The new "calculate_duration" option in this patch defaults to true, to
preserve the existing behavior. You can set it to false to get the new
realtime behavior. This seems a little backwards, so if someone has a
better name for this new behavior I'd be interested to hear it. Maybe the
option can be called "realtime" and default to false?

Here's an example of the old and new optional behavior:

$ ffmpeg -y -nostats -f lavfi -i 'movie=input.ts[out0+subcc]' -map s -f ass
-
Dialogue: 0,0:00:02.70,0:00:07.47,Default,,0,0,0,,- HEY, THINGS ACTUALLY
TURNED\NOUT OKAY FOR ME THIS TIME.
Dialogue: 0,0:00:07.47,0:00:08.61,Default,,0,0,0,,- BUTTERS!
Dialogue: 0,0:00:08.61,0:00:10.48,Default,,0,0,0,,- OH, I KNOW.
Dialogue: 0,0:00:10.48,0:00:41.64,Default,,0,0,0,,Captioning by CaptionMax\
Nwww.captionmax.com
Dialogue: 0,0:00:41.64,0:00:42.28,Default,,0,0,0,,>> Trevor: HAPPY NEW YEAR,
Dialogue: 0,0:00:42.28,0:00:43.91,Default,,0,0,0,,>> Trevor: HAPPY NEW
YEAR,\NEVERYBODY, TONIGHT WE'LL COVER
Dialogue: 0,0:00:43.91,0:00:45.18,Default,,0,0,0,,EVERYBODY, TONIGHT WE'LL
COVER\NTHE NEWS WE MISSED OVER THE

$ ffmpeg -y -calculate_duration 0 -nostats -f lavfi -i
'movie=input.ts[out0+subcc]' -map s -f ass -
Dialogue: 0,0:00:00.20,999:59:59.99,Default,,0,0,0,,
Dialogue: 0,0:00:00.27,999:59:59.99,Default,,0,0,0,,
Dialogue: 0,0:00:02.64,999:59:59.99,Default,,0,0,0,,
Dialogue: 0,0:00:02.70,999:59:59.99,Default,,0,0,0,,- HEY, THINGS ACTUALLY
TURNED\NOUT OKAY FOR ME THIS TIME.
Dialogue: 0,0:00:07.41,999:59:59.99,Default,,0,0,0,,
Dialogue: 0,0:00:07.47,999:59:59.99,Default,,0,0,0,,- BUTTERS!
Dialogue: 0,0:00:08.54,999:59:59.99,Default,,0,0,0,,
Dialogue: 0,0:00:08.61,999:59:59.99,Default,,0,0,0,,- OH, I KNOW.
Dialogue: 0,0:00:10.41,999:59:59.99,Default,,0,0,0,,
Dialogue: 0,0:00:10.48,999:59:59.99,Default,,0,0,0,,Captioning by
CaptionMax\Nwww.captionmax.com
Dialogue: 0,0:00:13.48,999:59:59.99,Default,,0,0,0,,
Dialogue: 0,0:00:41.07,999:59:59.99,Default,,0,0,0,,
Dialogue: 0,0:00:41.27,999:59:59.99,Default,,0,0,0,,>> Trevor
Dialogue: 0,0:00:41.47,999:59:59.99,Default,,0,0,0,,>> Trevor: HAPPY NEW
Dialogue: 0,0:00:41.64,999:59:59.99,Default,,0,0,0,,>> Trevor: HAPPY NEW
YEAR,
Dialogue: 0,0:00:41.84,999:59:59.99,Default,,0,0,0,,>> Trevor: HAPPY NEW
YEAR,\NEVERYBODY,
Dialogue: 0,0:00:42.04,999:59:59.99,Default,,0,0,0,,>> Trevor: HAPPY NEW
YEAR,\NEVERYBODY, TONIGHT WE
Dialogue: 0,0:00:42.24,999:59:59.99,Default,,0,0,0,,>> Trevor: HAPPY NEW
YEAR,\NEVERYBODY, TONIGHT WE'LL COVER
Dialogue: 0,0:00:42.28,999:59:59.99,Default,,0,0,0,,>> Trevor: HAPPY NEW
YEAR,\NEVERYBODY, TONIGHT WE'LL COVER
Dialogue: 0,0:00:42.48,999:59:59.99,Default,,0,0,0,,EVERYBODY, TONIGHT
WE'LL COVER\NTHE NEWS W
Dialogue: 0,0:00:42.68,999:59:59.99,Default,,0,0,0,,EVERYBODY, TONIGHT
WE'LL COVER\NTHE NEWS WE
Dialogue: 0,0:00:43.01,999:59:59.99,Default,,0,0,0,,EVERYBODY, TONIGHT
WE'LL COVER\NTHE NEWS WE M
Dialogue: 0,0:00:43.21,999:59:59.99,Default,,0,0,0,,EVERYBODY, TONIGHT
WE'LL COVER\NTHE NEWS WE MISSED OVER
Dialogue: 0,0:00:43.41,999:59:59.99,Default,,0,0,0,,EVERYBODY, TONIGHT
WE'LL COVER\NTHE NEWS WE MISSED OVER THE
Dialogue: 0,0:00:43.91,999:59:59.99,Default,,0,0,0,,EVERYBODY, TONIGHT
WE'LL COVER\NTHE NEWS WE MISSED OVER THE

On Wed, Jan 6, 2016 at 2:37 AM, wm4  wrote:

> On Tue,  5 Jan 2016 23:41:35 -0800
> Aman Gupta  wrote:
>
> > From: Aman Gupta 
> >
> > new option defaults to true, to preserve existing behavior. by flipping
> > the option to false, subtitle events are emitted as soon as they are
> > received and have an infinite duration.
> >
> > this new mode is useful for realtime decoding of closed captions so they
> > can be display along with decoded mpeg2 frames.
> > ---
> >  libavcodec/ccaption_dec.c | 19 ---
> >  1 file changed, 16 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
> > index f651c88..9f17e77 100644
> > --- a/libavcodec/ccaption_dec.c
> > +++ b/libavcodec/ccaption_dec.c
> > @@ -150,6 +150,7 @@ struct Screen {
> >
> >  typedef struct CCaptionSubContext {
> >  AVClass *class;
> > +int calculate_duration;
> >  struct Screen screen[2];
> >  int active_screen;
> >  uint8_t cursor_row;
> > @@ -545,8 +546,12 @@ static int decode(AVCodecContext *avctx, void
> *data, int *got_sub, AVPacket *avp
> >  continue;
> >  else
> >  process_cc608(ctx, *(bptr + i + 1) & 0x7f, *(bptr + i + 2)
> & 0x7f);
> > -if (ctx->screen_changed)
> > -{
> > +
> > +if (!ctx->screen_changed)
> > +continue;
> > +ctx->screen_changed = 0;
> > +
> > +if (ctx->calculate_duration) {
> >  if (ctx->prev_string) {
> >  int start_time = av_rescale_q(ctx->prev_time,
> avctx->time_base, (AVRational){ 1, 100 });
> >  int end_time = av_rescale_q(avpkt->pts,
> avctx->time_base, (AVRational){ 1, 100 });
> > @@ -560,7 +565,12 @@ 

[FFmpeg-devel] [PATCH] x86/intmath: add sse optimized av_clipf and av_clipd

[James Almer]

Signed-off-by: James Almer 
---
I could also include stdlib.h inside the __GNU__ section if that's
prefered, since other compilers don't need it.

 libavutil/x86/intmath.h | 33 +
 1 file changed, 33 insertions(+)

diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
index 611ef88..2b2c869 100644
--- a/libavutil/x86/intmath.h
+++ b/libavutil/x86/intmath.h
@@ -22,6 +22,7 @@
 #define AVUTIL_X86_INTMATH_H
 
 #include 
+#include 
 #if HAVE_FAST_CLZ
 #if defined(_MSC_VER)
 #include 
@@ -98,6 +99,38 @@ static av_always_inline av_const unsigned 
av_mod_uintp2_bmi2(unsigned a, unsigne
 
 #endif /* __BMI2__ */
 
+#if defined(__SSE2__)
+
+#define av_clipd av_clipd_sse2
+static av_always_inline av_const double av_clipd_sse2(double a, double amin, 
double amax)
+{
+#if defined(ASSERT_LEVEL) && ASSERT_LEVEL >= 2
+if (amin > amax) abort();
+#endif
+__asm__ ("minsd %2, %0 \n\t"
+ "maxsd %1, %0 \n\t"
+ : "+x"(a) : "xm"(amin), "xm"(amax));
+return a;
+}
+
+#endif /* __SSE2__ */
+
+#if defined(__SSE__)
+
+#define av_clipf av_clipf_sse
+static av_always_inline av_const float av_clipf_sse(float a, float amin, float 
amax)
+{
+#if defined(ASSERT_LEVEL) && ASSERT_LEVEL >= 2
+if (amin > amax) abort();
+#endif
+__asm__ ("minss %2, %0 \n\t"
+ "maxss %1, %0 \n\t"
+ : "+x"(a) : "xm"(amin), "xm"(amax));
+return a;
+}
+
+#endif /* __SSE__ */
+
 #endif /* __GNUC__ */
 
 #endif /* AVUTIL_X86_INTMATH_H */
-- 
2.6.3

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

Re: [FFmpeg-devel] [PATCH 2/2] x86/vf_w3fdif: simplify w3fdif_simple_high

[Hendrik Leppkes]

On Mon, Oct 12, 2015 at 1:21 AM, James Almer  wrote:
> On 10/11/2015 3:11 PM, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Sun, Oct 11, 2015 at 1:17 PM, James Almer  wrote:
>>
>>> On 10/11/2015 4:31 AM, Paul B Mahol wrote:
 On 10/11/15, James Almer  wrote:
> Signed-off-by: James Almer 
> ---
>  libavfilter/x86/vf_w3fdif.asm | 16 +++-
>  1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/libavfilter/x86/vf_w3fdif.asm
>>> b/libavfilter/x86/vf_w3fdif.asm
> index f02319b..f2001a4 100644
> --- a/libavfilter/x86/vf_w3fdif.asm
> +++ b/libavfilter/x86/vf_w3fdif.asm
> @@ -103,13 +103,11 @@ REP_RET
>
>  %if ARCH_X86_64
>
> -cglobal w3fdif_simple_high, 5, 9, 9, 0, work_line, in_lines_cur0,
> in_lines_adj0, coef, linesize
> +cglobal w3fdif_simple_high, 5, 9, 8, 0, work_line, in_lines_cur0,
> in_lines_adj0, coef, linesize
>  movq  m2, [coefq]
>  DEFINE_ARGSwork_line, in_lines_cur0, in_lines_adj0,
>>> in_lines_cur1,
> linesize, offset, in_lines_cur2, in_lines_adj1, in_lines_adj2
> -SPLATWm0, m2, 0
> -SPLATWm1, m2, 1
> +pshufdm0, m2, q
>  SPLATWm2, m2, 2
> -SBUTTERFLYwd, 0, 1, 7
>  pxor  m7, m7
>  mov  offsetq, 0
>  mov   in_lines_cur2q, [in_lines_cur0q+gprsize*2]
> @@ -124,23 +122,23 @@ cglobal w3fdif_simple_high, 5, 9, 9, 0, work_line,
> in_lines_cur0, in_lines_adj0,
>  movh   m4, [in_lines_cur1q+offsetq]
>  punpcklbw  m3, m7
>  punpcklbw  m4, m7
> -SBUTTERFLY wd, 3, 4, 8
> +SBUTTERFLY wd, 3, 4, 1
>  pmaddwdm3, m0
> -pmaddwdm4, m1
> +pmaddwdm4, m0
>  movh   m5, [in_lines_adj0q+offsetq]
>  movh   m6, [in_lines_adj1q+offsetq]
>  punpcklbw  m5, m7
>  punpcklbw  m6, m7
> -SBUTTERFLY wd, 5, 6, 8
> +SBUTTERFLY wd, 5, 6, 1
>  pmaddwdm5, m0
> -pmaddwdm6, m1
> +pmaddwdm6, m0
>  paddd  m3, m5
>  paddd  m4, m6
>  movh   m5, [in_lines_cur2q+offsetq]
>  movh   m6, [in_lines_adj2q+offsetq]
>  punpcklbw  m5, m7
>  punpcklbw  m6, m7
> -SBUTTERFLY wd, 5, 6, 8
> +SBUTTERFLY wd, 5, 6, 1
>  pmaddwdm5, m2
>  pmaddwdm6, m2
>  paddd  m3, m5
> --
> 2.6.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

 Cant this now be used on x32?
>>>
>>
>> Add to the data pointers directly (in_lines_cur0q and work_lineq). Then sub
>> all other curXq/adjXq from cur0q (on 32bit only) before the loop and you
>> have to adds (on 32bit) instead of one (on 64bit), but one reg less
>> (offset), making it 7, which means it works.
>>
>> Ronald
>
> Ah, like it's being done in PACK_6CH from swr's audio_convert.asm
> For complex_high some stack ab/use will be needed (see PACK_8CH), but it 
> should
> be doable.
> This way w3fdif will be able to fully dethrone yadif :P

Are you still working on w3fdif_simple_high for 32bit?
I would be interested in that. Otherwise I might try to do it myself,
although it sounds like a lot of #if'ery
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC v5] libavcodec: add a native Daala decoder

[Ganesh Ajjanagadde]

On Wed, Jan 6, 2016 at 5:22 PM, Ronald S. Bultje  wrote:
> Hello,
>
[...]
>
>> +#define DAALA_QM_SCALE (1 << 15)
>> +#define DAALA_QM_SCALE_MAX (DAALA_QM_SCALE - 1)
>> +#define DAALA_QM_SCALE_UNIT (1.0f/DAALA_QM_SCALE_MAX)
>> +#define DAALA_QM_INV_SCALE (1 << 12)
>> +#define DAALA_QM_INV_SCALE_UNIT (1.0f/DAALA_QM_INV_SCALE)
>> +#define DAALA_QM_BSIZE (DAALA_BSIZE_MAX*DAALA_BSIZE_MAX)
>> +#define DAALA_QM_BUFFER_SIZE (DAALA_NBSIZES*2*DAALA_QM_BSIZE)
>
> Floats in a video decoder? That looks strange. I’m pretty sure these are
> placeholders for integer arithmetic?

Just my curiosity, but isn't it easier while developing video codecs
to work with floats, and then convert to fixed point arithmetic? It
can be hard while designing algorithms from the start to agonize over
fixed point at the very beginning, echoing your remark about
placeholders.

[...]
>
>> +static inline double daalapvq_gain_raise(double cg, int q0, double beta)
>> +{
>> +if (beta == 1.0f)
>> +return cg*q0;
>> +else if (beta == 1.5f) {
>> +cg *= q0*DAALAPVQ_COMPAND_SCALE_1;
>> +return DAALAPVQ_COMPAND_SCALE*cg*sqrt(cg);
>> +}
>> +return DAALAPVQ_COMPAND_SCALE*pow(cg*q0*DAALAPVQ_COMPAND_SCALE_1,
> beta);
>> +}
>
> Pow, sqrt, really?

That pow may be translatable to sqrt, code above suggest half
integers, though I have not studied this. In any case, a comment with
a TODO/FIXME maybe useful for reference.

[...]
>
>> +#define DAALA_BSIZE8x8(arr, bstride, bx, by) ((arr)[(by)*(bstride) +
> (bx)])
>> +#define DAALA_BSIZE4x4(arr, bstride, bx, by) DAALA_BSIZE8x8(arr,
> bstride, (bx) >> 1, (by) >> 1)
>
> ? So, this may just be me, but I feel this is getting in the #define inc(a)
> ((a)++) territory.

+1

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

[FFmpeg-devel] [PATCH] x86/intmath: add sse optimized av_clipf and av_clipd

[James Almer]

Signed-off-by: James Almer 
---
 libavutil/x86/intmath.h | 32 
 1 file changed, 32 insertions(+)

diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
index 611ef88..e1cd596 100644
--- a/libavutil/x86/intmath.h
+++ b/libavutil/x86/intmath.h
@@ -98,6 +98,38 @@ static av_always_inline av_const unsigned 
av_mod_uintp2_bmi2(unsigned a, unsigne
 
 #endif /* __BMI2__ */
 
+#if defined(__SSE2__)
+
+#define av_clipd av_clipd_sse2
+static av_always_inline av_const double av_clipd_sse2(double a, double amin, 
double amax)
+{
+#if defined(ASSERT_LEVEL) && ASSERT_LEVEL >= 2
+if (amin > amax) abort();
+#endif
+__asm__ ("minsd %2, %0 \n\t"
+ "maxsd %1, %0 \n\t"
+ : "+x"(a) : "xm"(amin), "xm"(amax));
+return a;
+}
+
+#endif /* __SSE2__ */
+
+#if defined(__SSE__)
+
+#define av_clipf av_clipf_sse
+static av_always_inline av_const float av_clipf_sse(float a, float amin, float 
amax)
+{
+#if defined(ASSERT_LEVEL) && ASSERT_LEVEL >= 2
+if (amin > amax) abort();
+#endif
+__asm__ ("minss %2, %0 \n\t"
+ "maxss %1, %0 \n\t"
+ : "+x"(a) : "xm"(amin), "xm"(amax));
+return a;
+}
+
+#endif /* __SSE__ */
+
 #endif /* __GNUC__ */
 
 #endif /* AVUTIL_X86_INTMATH_H */
-- 
2.6.3

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

Re: [FFmpeg-devel] [RFC v5] libavcodec: add a native Daala decoder

[Ronald S. Bultje]

Hello,

On Sat, Jan 2, 2016 at 12:56 PM, Rostislav Pehlivanov 
wrote:
> @@ -864,6 +865,7 @@ OBJS-$(CONFIG_BMP_PARSER)  += bmp_parser.o
>  OBJS-$(CONFIG_CAVSVIDEO_PARSER)+= cavs_parser.o
>  OBJS-$(CONFIG_COOK_PARSER) += cook_parser.o
>  OBJS-$(CONFIG_DCA_PARSER)  += dca_parser.o dca.o
> +OBJS-$(CONFIG_DAALA_PARSER)+= daala_parser.o
>  OBJS-$(CONFIG_DIRAC_PARSER)+= dirac_parser.o
>  OBJS-$(CONFIG_DNXHD_PARSER)+= dnxhd_parser.o
>  OBJS-$(CONFIG_DPX_PARSER)  += dpx_parser.o

Alphabetical ordering.

> +#ifndef AVCODEC_DAALA_H
> +#define AVCODEC_DAALA_H
> +
> +#include "avcodec.h"

Why? I see nothing in this header that requires avcodec.h. All you should
need is stdint.h and intmath.h.

> +/* Essential typedefs */
> +typedef uint32_t ent_win; /* Has to be able to express 32bit uint nums */
> +typedef uint16_t ent_rng;
> +typedef  int32_t dctcoef;

Is this for compat with daala functions? I find this very confusing TBH.
Are coefficients for 8bit content really 32bit? (In most codecs, they’re
only 16 bit.)

> +#define DAALA_MAX_REF_FRAMES 2  /* Maximum number of reference frames */

Dev note - OMG please increase this.

> +#define DAALA_QM_SCALE (1 << 15)
> +#define DAALA_QM_SCALE_MAX (DAALA_QM_SCALE - 1)
> +#define DAALA_QM_SCALE_UNIT (1.0f/DAALA_QM_SCALE_MAX)
> +#define DAALA_QM_INV_SCALE (1 << 12)
> +#define DAALA_QM_INV_SCALE_UNIT (1.0f/DAALA_QM_INV_SCALE)
> +#define DAALA_QM_BSIZE (DAALA_BSIZE_MAX*DAALA_BSIZE_MAX)
> +#define DAALA_QM_BUFFER_SIZE (DAALA_NBSIZES*2*DAALA_QM_BSIZE)

Floats in a video decoder? That looks strange. I’m pretty sure these are
placeholders for integer arithmetic?

> +/* Expectation value log, outputs Q1 */
> +static av_always_inline int daalaent_log_ex(int ex_q16)
> +{
> +int o, log = daalaent_log2(ex_q16);
> +if (log < 15) {
> +o = ex_q16*ex_q16 > 2 << 2*log;

Derf-style?

> +/* Expectation value is in Q16 */
> +static inline int daalaent_decode_generic(DaalaEntropy *e, DaalaCDF *c,
int *ex,
> +  int max, int integrate)
> +{
> +int rval, lsb = 0, log_ex = daalaent_log_ex(*ex);
> +const int shift = FFMAX(0, (log_ex - 5) >> 1);
> +const int id = FFMIN(DAALAENT_MODEL_TAB - 1, log_ex);
> +const int ms = (max + (1 << shift >> 1)) >> shift;
> +int xs = (max == -1) ? 16 : FFMIN(ms + 1, 16);
> +ent_rng *cdf = >cdf[id*c->y];
> +if (!max)
> +return 0;
> +if ((xs = daalaent_decode_cdf(e, cdf, xs, 0, CDF_UNSCALED)) == 15) {
> +int g = ((2*(*ex) >> 8) + (1 << shift >> 1)) >> shift;
> +ent_win decay = FFMAX(2, FFMIN(254, 256*g/(g + 256)));

av_clip? And space between operators.

> +#ifndef AVCODEC_DAALAPVQ_H
> +#define AVCODEC_DAALAPVQ_H
[..]
> +#define DAALAPVQ_MAX_PART_SIZE   (DAALA_QM_BSIZE/2)
> +#define DAALAPVQ_COMPAND_SCALE   (256 << DAALA_CSHIFT)
> +#define DAALAPVQ_COMPAND_SCALE_1 (1.0f/DAALAPVQ_COMPAND_SCALE)

More floating point, very strange. Will this become integer math at some
point?

> +/* Index for packed quantization matrices */
> +static av_always_inline int daalapvq_get_qm_idx(enum DaalaBsize bsize,
int band)
> +{
> +return bsize*bsize + bsize + band - band/3;
> +}

I know we expect all compilers to know how to do this, but anyway - can we
use fastdiv for this?

> +static inline double daalapvq_gain_raise(double cg, int q0, double beta)
> +{
> +if (beta == 1.0f)
> +return cg*q0;
> +else if (beta == 1.5f) {
> +cg *= q0*DAALAPVQ_COMPAND_SCALE_1;
> +return DAALAPVQ_COMPAND_SCALE*cg*sqrt(cg);
> +}
> +return DAALAPVQ_COMPAND_SCALE*pow(cg*q0*DAALAPVQ_COMPAND_SCALE_1,
beta);
> +}

Pow, sqrt, really?

> +/* Decodes quantized coefficients from  the bitsteam */
> +static void daalapvq_decode_laplace_vector(DaalaEntropy *e, dctcoef *y,
> +   int n, int k, dctcoef *curr,
> +   const dctcoef *means)
> +{
[..]
> +memset([i], 0, (n - i)*sizeof(dctcoef)); /* Zero the rest */

This is a little strange. So, we typically take advantage of the fact that
most coefficients are zero, and then we use the inverse transform (or
whatever daala’s equivalent of wording is here) to zero only the used part
of the coefficients. Then, we can assume they are zero by default in this
function, and the memset becomes unnecessary. This typically causes a
slight speedup also, because the memset is in simd and requires no extra
function call.

> +static void daalapvq_decode_codeword(DaalaEntropy *e, DaalaPVQ *pvq,
> + dctcoef *y, int n, int k, uint8_t
has_ref,
> + enum DaalaBsize bsize)

Making function arguments uint8_t usually has odd side-effects and
typically causes slowdowns. I’d recommend to just use int or unsigned for
scalar values. Same for the functions below this one.

> +#define 

Re: [FFmpeg-devel] [PATCH v5] lavf/matroskadec: A_QUICKTIME and AV_CODEC_ID_NONE

[Mats Peterson]

On 01/06/2016 04:32 AM, Mats Peterson wrote:

In many older QuickTime files, the audio format, or "fourcc", is
0x (AV_CODEC_ID_NONE). The QuickTime File Format Specification
states the following regarding this situation:

"This format descriptor should not be used, but may be found in some
files. Samples are assumed to be stored in either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."

MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.

Mats



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



Michael?

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] x86/intmath: add sse optimized av_clipf and av_clipd

[Michael Niedermayer]

On Wed, Jan 06, 2016 at 10:09:45PM -0300, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  libavutil/x86/intmath.h | 32 
>  1 file changed, 32 insertions(+)

seems failing to build

CC  libavcodec/proresdec_lgpl.o
In file included from ./libavutil/intmath.h:33:0,
 from libavcodec/proresdec_lgpl.c:35:
./libavutil/x86/intmath.h: In function ‘av_clipd_sse2’:
./libavutil/x86/intmath.h:107:5: error: implicit declaration of function 
‘abort’ [-Werror=implicit-function-declaration]
./libavutil/x86/intmath.h:107:22: warning: incompatible implicit declaration of 
built-in function ‘abort’ [enabled by default]
./libavutil/x86/intmath.h: In function ‘av_clipf_sse’:
./libavutil/x86/intmath.h:123:22: warning: incompatible implicit declaration of 
built-in function ‘abort’ [enabled by default]
cc1: some warnings being treated as errors
make: *** [libavcodec/proresdec_lgpl.o] Error 1

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

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


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

Re: [FFmpeg-devel] [PATCH 3/3] ffmdec: change type of len to ptrdiff_t

[Michael Niedermayer]

On Sat, Jan 02, 2016 at 04:52:25PM +0100, Andreas Cadhalpun wrote:
> It is used to store the difference between pointers, so ptrdiff_t is the
> correct type.
> 
> This prevents potential overflows.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/ffmdec.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

I think if these pointers can differ by more than te int range then
theres someting else wrong and changing one variable to ptrdiff_t
might be insufficient to support that

that said, it should do no harm if you feel that changing these 2
would make the code more robust

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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

Re: [FFmpeg-devel] [PATCH v2] lavf/matroskadec: A_QUICKTIME and AV_CODEC_ID_NONE

[Mats Peterson]

On 01/04/2016 10:49 PM, Mats Peterson wrote:

In many older QuickTime files, the audio format, or "fourcc", is
0x (AV_CODEC_ID_NONE). The QuickTime File Format Specification
states the following regarding this situation:

"This format descriptor should not be used, but may be found in some
files. Samples are assumed to be stored in either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."

MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.

Mats



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



Michael?

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] ffmpeg: check fclose return values

[Ganesh Ajjanagadde]

In the spirit of commit a956840cbc. Simple method to reproduce:
pass -vstats_file /dev/full to ffmpeg.

All raw fclose usages in ffmpeg.c taken care of here.

Signed-off-by: Ganesh Ajjanagadde 
---
 ffmpeg.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index 0c83165..858e6d7 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -554,8 +554,12 @@ static void ffmpeg_cleanup(int ret)
 av_freep(_streams[i]);
 }
 
-if (vstats_file)
-fclose(vstats_file);
+if (vstats_file) {
+if ((ret = fclose(vstats_file)) < 0)
+av_log(NULL, AV_LOG_ERROR,
+   "Error closing vstats file, loss of information possible: 
%s\n",
+   av_err2str(ret));
+}
 av_freep(_filename);
 
 av_freep(_streams);
@@ -4200,7 +4204,10 @@ static int transcode(void)
 ost = output_streams[i];
 if (ost) {
 if (ost->logfile) {
-fclose(ost->logfile);
+if ((ret = fclose(ost->logfile)) < 0)
+av_log(NULL, AV_LOG_ERROR,
+   "Error closing logfile, loss of information 
possible: %s\n",
+   av_err2str(ret));
 ost->logfile = NULL;
 }
 av_freep(>forced_kf_pts);
-- 
2.6.4

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

[FFmpeg-devel] [PATCH] x86/vf_w3fdif: 32-bit compatibility for w3fdif_simple_high

[Hendrik Leppkes]

---
Based on an idea from Ronald mentioend in an earlier thread about this function.

It works and passes FATE, however I'm sure some aspects can be done easier or 
cleaner, so please let me know.


 libavfilter/x86/vf_w3fdif.asm| 37 ++---
 libavfilter/x86/vf_w3fdif_init.c |  2 +-
 2 files changed, 35 insertions(+), 4 deletions(-)

diff --git a/libavfilter/x86/vf_w3fdif.asm b/libavfilter/x86/vf_w3fdif.asm
index c3c73ea..35768c3 100644
--- a/libavfilter/x86/vf_w3fdif.asm
+++ b/libavfilter/x86/vf_w3fdif.asm
@@ -102,14 +102,22 @@ cglobal w3fdif_complex_low, 4, 7, 8, 0, work_line, 
in_lines_cur0, coef, linesize
 REP_RET
 
 %if ARCH_X86_64
-
 cglobal w3fdif_simple_high, 5, 9, 8, 0, work_line, in_lines_cur0, 
in_lines_adj0, coef, linesize
+%else
+cglobal w3fdif_simple_high, 4, 7, 8, 0, work_line, in_lines_cur0, 
in_lines_adj0, coef, linesize
+%endif
 movq  m2, [coefq]
-DEFINE_ARGSwork_line, in_lines_cur0, in_lines_adj0, in_lines_cur1, 
linesize, offset, in_lines_cur2, in_lines_adj1, in_lines_adj2
+%if ARCH_X86_64
+DEFINE_ARGSwork_line, in_lines_cur0, in_lines_adj0, linesize, offset, 
in_lines_cur1, in_lines_cur2, in_lines_adj1, in_lines_adj2
+mov  offsetq, 0
+%else
+DEFINE_ARGSwork_line, in_lines_cur0, in_lines_adj0, in_lines_cur1, 
in_lines_cur2, in_lines_adj1, in_lines_adj2
+%define linesized dword r4m
+%endif
+
 pshufdm0, m2, q
 SPLATWm2, m2, 2
 pxor  m7, m7
-mov  offsetq, 0
 mov   in_lines_cur2q, [in_lines_cur0q+gprsize*2]
 mov   in_lines_cur1q, [in_lines_cur0q+gprsize]
 mov   in_lines_cur0q, [in_lines_cur0q]
@@ -117,8 +125,21 @@ cglobal w3fdif_simple_high, 5, 9, 8, 0, work_line, 
in_lines_cur0, in_lines_adj0,
 mov   in_lines_adj1q, [in_lines_adj0q+gprsize]
 mov   in_lines_adj0q, [in_lines_adj0q]
 
+%if ARCH_X86_32
+sub in_lines_cur1q, in_lines_cur0q
+sub in_lines_cur2q, in_lines_cur0q
+sub in_lines_adj0q, in_lines_cur0q
+sub in_lines_adj1q, in_lines_cur0q
+sub in_lines_adj2q, in_lines_cur0q
+%define offsetq in_lines_cur0q
+%endif
+
 .loop:
+%if ARCH_X86_64
 movh   m3, [in_lines_cur0q+offsetq]
+%else
+movh   m3, [in_lines_cur0q]
+%endif
 movh   m4, [in_lines_cur1q+offsetq]
 punpcklbw  m3, m7
 punpcklbw  m4, m7
@@ -143,15 +164,25 @@ cglobal w3fdif_simple_high, 5, 9, 8, 0, work_line, 
in_lines_cur0, in_lines_adj0,
 pmaddwdm6, m2
 paddd  m3, m5
 paddd  m4, m6
+%if ARCH_X86_64
 paddd  m3, [work_lineq+offsetq*4]
 paddd  m4, [work_lineq+offsetq*4+mmsize]
 mova   [work_lineq+offsetq*4], m3
 mova[work_lineq+offsetq*4+mmsize], m4
+%else
+paddd  m3, [work_lineq]
+paddd  m4, [work_lineq+mmsize]
+mova [work_lineq], m3
+mova  [work_lineq+mmsize], m4
+addwork_lineq, mmsize*2
+%endif
 add   offsetq, mmsize/2
 sub linesized, mmsize/2
 jg .loop
 REP_RET
 
+%if ARCH_X86_64
+
 cglobal w3fdif_complex_high, 5, 13, 10, 0, work_line, in_lines_cur0, 
in_lines_adj0, coef, linesize
 movq  m0, [coefq+0]
 movd  m4, [coefq+8]
diff --git a/libavfilter/x86/vf_w3fdif_init.c b/libavfilter/x86/vf_w3fdif_init.c
index 72ea657..9bf06e8 100644
--- a/libavfilter/x86/vf_w3fdif_init.c
+++ b/libavfilter/x86/vf_w3fdif_init.c
@@ -51,12 +51,12 @@ av_cold void ff_w3fdif_init_x86(W3FDIFDSPContext *dsp)
 
 if (EXTERNAL_SSE2(cpu_flags)) {
 dsp->filter_simple_low   = ff_w3fdif_simple_low_sse2;
+dsp->filter_simple_high  = ff_w3fdif_simple_high_sse2;
 dsp->filter_complex_low  = ff_w3fdif_complex_low_sse2;
 dsp->filter_scale= ff_w3fdif_scale_sse2;
 }
 
 if (ARCH_X86_64 && EXTERNAL_SSE2(cpu_flags)) {
-dsp->filter_simple_high  = ff_w3fdif_simple_high_sse2;
 dsp->filter_complex_high = ff_w3fdif_complex_high_sse2;
 }
 }
-- 
2.6.2.windows.1

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

Re: [FFmpeg-devel] [PATCH 2/2] x86/vf_w3fdif: simplify w3fdif_simple_high

[Hendrik Leppkes]

On Thu, Jan 7, 2016 at 3:13 AM, Hendrik Leppkes  wrote:
> On Mon, Oct 12, 2015 at 1:21 AM, James Almer  wrote:
>> On 10/11/2015 3:11 PM, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Sun, Oct 11, 2015 at 1:17 PM, James Almer  wrote:
>>>
 On 10/11/2015 4:31 AM, Paul B Mahol wrote:
> On 10/11/15, James Almer  wrote:
>> Signed-off-by: James Almer 
>> ---
>>  libavfilter/x86/vf_w3fdif.asm | 16 +++-
>>  1 file changed, 7 insertions(+), 9 deletions(-)
>>
>> diff --git a/libavfilter/x86/vf_w3fdif.asm
 b/libavfilter/x86/vf_w3fdif.asm
>> index f02319b..f2001a4 100644
>> --- a/libavfilter/x86/vf_w3fdif.asm
>> +++ b/libavfilter/x86/vf_w3fdif.asm
>> @@ -103,13 +103,11 @@ REP_RET
>>
>>  %if ARCH_X86_64
>>
>> -cglobal w3fdif_simple_high, 5, 9, 9, 0, work_line, in_lines_cur0,
>> in_lines_adj0, coef, linesize
>> +cglobal w3fdif_simple_high, 5, 9, 8, 0, work_line, in_lines_cur0,
>> in_lines_adj0, coef, linesize
>>  movq  m2, [coefq]
>>  DEFINE_ARGSwork_line, in_lines_cur0, in_lines_adj0,
 in_lines_cur1,
>> linesize, offset, in_lines_cur2, in_lines_adj1, in_lines_adj2
>> -SPLATWm0, m2, 0
>> -SPLATWm1, m2, 1
>> +pshufdm0, m2, q
>>  SPLATWm2, m2, 2
>> -SBUTTERFLYwd, 0, 1, 7
>>  pxor  m7, m7
>>  mov  offsetq, 0
>>  mov   in_lines_cur2q, [in_lines_cur0q+gprsize*2]
>> @@ -124,23 +122,23 @@ cglobal w3fdif_simple_high, 5, 9, 9, 0, work_line,
>> in_lines_cur0, in_lines_adj0,
>>  movh   m4, [in_lines_cur1q+offsetq]
>>  punpcklbw  m3, m7
>>  punpcklbw  m4, m7
>> -SBUTTERFLY wd, 3, 4, 8
>> +SBUTTERFLY wd, 3, 4, 1
>>  pmaddwdm3, m0
>> -pmaddwdm4, m1
>> +pmaddwdm4, m0
>>  movh   m5, [in_lines_adj0q+offsetq]
>>  movh   m6, [in_lines_adj1q+offsetq]
>>  punpcklbw  m5, m7
>>  punpcklbw  m6, m7
>> -SBUTTERFLY wd, 5, 6, 8
>> +SBUTTERFLY wd, 5, 6, 1
>>  pmaddwdm5, m0
>> -pmaddwdm6, m1
>> +pmaddwdm6, m0
>>  paddd  m3, m5
>>  paddd  m4, m6
>>  movh   m5, [in_lines_cur2q+offsetq]
>>  movh   m6, [in_lines_adj2q+offsetq]
>>  punpcklbw  m5, m7
>>  punpcklbw  m6, m7
>> -SBUTTERFLY wd, 5, 6, 8
>> +SBUTTERFLY wd, 5, 6, 1
>>  pmaddwdm5, m2
>>  pmaddwdm6, m2
>>  paddd  m3, m5
>> --
>> 2.6.0
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> Cant this now be used on x32?

>>>
>>> Add to the data pointers directly (in_lines_cur0q and work_lineq). Then sub
>>> all other curXq/adjXq from cur0q (on 32bit only) before the loop and you
>>> have to adds (on 32bit) instead of one (on 64bit), but one reg less
>>> (offset), making it 7, which means it works.
>>>
>>> Ronald
>>
>> Ah, like it's being done in PACK_6CH from swr's audio_convert.asm
>> For complex_high some stack ab/use will be needed (see PACK_8CH), but it 
>> should
>> be doable.
>> This way w3fdif will be able to fully dethrone yadif :P
>
> Are you still working on w3fdif_simple_high for 32bit?
> I would be interested in that. Otherwise I might try to do it myself,
> although it sounds like a lot of #if'ery

I was bored and it was easy, so patch coming up anyway!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] lavf/matroskadec: A_QUICKTIME and AV_CODEC_ID_NONE

[Mats Peterson]

On 01/07/2016 04:13 AM, Mats Peterson wrote:

On 01/04/2016 10:49 PM, Mats Peterson wrote:

In many older QuickTime files, the audio format, or "fourcc", is
0x (AV_CODEC_ID_NONE). The QuickTime File Format Specification
states the following regarding this situation:

"This format descriptor should not be used, but may be found in some
files. Samples are assumed to be stored in either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."

MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.

Mats



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



Michael?



No, not this one. Forget it.

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] lavf/mov: Audio and AV_CODEC_ID_NONE

[Mats Peterson]

On 01/05/2016 06:45 AM, Mats Peterson wrote:

Simplified the patch somewhat. Description follows:

In many older QuickTime files, the audio format, or "fourcc", is
0x (AV_CODEC_ID_NONE). The QuickTime File Format Specification
states the following regarding this situation:

"This format descriptor should not be used, but may be found in some
files. Samples are assumed to be stored in either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."

MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.

Mats



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



Michael?

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] x86/intmath: add sse optimized av_clipf and av_clipd

[James Almer]

On 1/7/2016 12:19 AM, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Jan 6, 2016 at 8:09 PM, James Almer  wrote:
> 
>> Signed-off-by: James Almer 
>> ---
>>  libavutil/x86/intmath.h | 32 
>>  1 file changed, 32 insertions(+)
>>
>> diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
>> index 611ef88..e1cd596 100644
>> --- a/libavutil/x86/intmath.h
>> +++ b/libavutil/x86/intmath.h
>> @@ -98,6 +98,38 @@ static av_always_inline av_const unsigned
>> av_mod_uintp2_bmi2(unsigned a, unsigne
>>
>>  #endif /* __BMI2__ */
>>
>> +#if defined(__SSE2__)
>> +
>> +#define av_clipd av_clipd_sse2
>> +static av_always_inline av_const double av_clipd_sse2(double a, double
>> amin, double amax)
>> +{
>> +#if defined(ASSERT_LEVEL) && ASSERT_LEVEL >= 2
>> +if (amin > amax) abort();
>> +#endif
>> +__asm__ ("minsd %2, %0 \n\t"
>> + "maxsd %1, %0 \n\t"
>> + : "+x"(a) : "xm"(amin), "xm"(amax));
>> +return a;
>> +}
>> +
>> +#endif /* __SSE2__ */
> 
> 
> This __SSE2__ is kind of strange, and we don't use it anywhere else. I
> understand it's not the same thing, but for practical purposes, could we
> just use #if ARCH_X86_64 and not care about -msse2?
> 
> Ronald

We use it in x86/intreadwrite.h for AV_ZERO128.
And no, I'd rather have it working on x86_32 when -msse2 is used since it's
much more efficient.
Compare:

 <_av_clipf_sse>:
   0:   83 ec 0csubesp,0xc
   3:   f2 0f 10 44 24 10   movsd  xmm0,QWORD PTR [esp+0x10]
   9:   f2 0f 5d 44 24 20   minsd  xmm0,QWORD PTR [esp+0x20]
   f:   f2 0f 5f 44 24 18   maxsd  xmm0,QWORD PTR [esp+0x18]
  15:   f2 0f 11 04 24  movsd  QWORD PTR [esp],xmm0
  1a:   dd 04 24fldQWORD PTR [esp]
  1d:   83 c4 0caddesp,0xc
  20:   c3  ret

with:

0030 <_av_clipf_c>:
  30:   dd 44 24 04 fldQWORD PTR [esp+0x4]
  34:   dd 44 24 14 fldQWORD PTR [esp+0x14]
  38:   dd 44 24 0c fldQWORD PTR [esp+0xc]
  3c:   db ea   fucomi st,st(2)
  3e:   77 10   ja 50 <_clipf_c+0x20>
  40:   dd d8   fstp   st(0)
  42:   d9 c9   fxch   st(1)
  44:   db e9   fucomi st,st(1)
  46:   db d1   fcmovnbe st,st(1)
  48:   dd d9   fstp   st(1)
  4a:   eb 08   jmp54 <_clipf_c+0x24>
  4c:   8d 74 26 00 leaesi,[esi+eiz*1+0x0]
  50:   dd d9   fstp   st(1)
  52:   dd d9   fstp   st(1)
  54:   f3 c3   repz ret

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: check fclose return values

[Ganesh Ajjanagadde]

On Wed, Jan 6, 2016 at 9:00 PM, Ganesh Ajjanagadde
 wrote:
> In the spirit of commit a956840cbc. Simple method to reproduce:
> pass -vstats_file /dev/full to ffmpeg.
>
> All raw fclose usages in ffmpeg.c taken care of here.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  ffmpeg.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/ffmpeg.c b/ffmpeg.c
> index 0c83165..858e6d7 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -554,8 +554,12 @@ static void ffmpeg_cleanup(int ret)
>  av_freep(_streams[i]);
>  }
>
> -if (vstats_file)
> -fclose(vstats_file);
> +if (vstats_file) {
> +if ((ret = fclose(vstats_file)) < 0)
> +av_log(NULL, AV_LOG_ERROR,
> +   "Error closing vstats file, loss of information possible: 
> %s\n",
> +   av_err2str(ret));
> +}
>  av_freep(_filename);
>
>  av_freep(_streams);
> @@ -4200,7 +4204,10 @@ static int transcode(void)
>  ost = output_streams[i];
>  if (ost) {
>  if (ost->logfile) {
> -fclose(ost->logfile);
> +if ((ret = fclose(ost->logfile)) < 0)
> +av_log(NULL, AV_LOG_ERROR,
> +   "Error closing logfile, loss of information 
> possible: %s\n",
> +   av_err2str(ret));
>  ost->logfile = NULL;
>  }
>  av_freep(>forced_kf_pts);
> --
> 2.6.4
>

Should have mentioned this earlier, but this fclose related business
was due to listening to:
https://www.irill.org/events/ghm-gnu-hackers-meeting/videos/jim-meyering-goodbye-world-the-perils-of-relying-on-output-streams-in-c,
slides: 
https://www.gnu.org/ghm/2011/paris/slides/jim-meyering-goodbye-world.pdf.

For a more sustainable solution, we should create an API in e.g
libavutil for this IMHO, since fclose is called not just in ffmpeg but
also in libavfilter. There may be 2 ways of doing this:
1. Developing it organically in FFmpeg.
2. Using gnulib and associated close_stream/other API's (e.g
https://github.com/coreutils/gnulib/blob/master/lib/close-stream.c) as
suggested in the talk as a basis. There are some problems:
a) Licensing - it is GPL. There is some mention regarding relicensing
for gnulib, https://www.gnu.org/software/gnulib/manual/html_node/Copyright.html,
so it may be ok to relicense under lgpl. However, I am not a lawyer.
b) Care may need to be taken to make sure it is portable enough, and
refactoring may be necessary.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] x86/intmath: add sse optimized av_clipf and av_clipd

[Ronald S. Bultje]

Hi,

On Wed, Jan 6, 2016 at 8:09 PM, James Almer  wrote:

> Signed-off-by: James Almer 
> ---
>  libavutil/x86/intmath.h | 32 
>  1 file changed, 32 insertions(+)
>
> diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
> index 611ef88..e1cd596 100644
> --- a/libavutil/x86/intmath.h
> +++ b/libavutil/x86/intmath.h
> @@ -98,6 +98,38 @@ static av_always_inline av_const unsigned
> av_mod_uintp2_bmi2(unsigned a, unsigne
>
>  #endif /* __BMI2__ */
>
> +#if defined(__SSE2__)
> +
> +#define av_clipd av_clipd_sse2
> +static av_always_inline av_const double av_clipd_sse2(double a, double
> amin, double amax)
> +{
> +#if defined(ASSERT_LEVEL) && ASSERT_LEVEL >= 2
> +if (amin > amax) abort();
> +#endif
> +__asm__ ("minsd %2, %0 \n\t"
> + "maxsd %1, %0 \n\t"
> + : "+x"(a) : "xm"(amin), "xm"(amax));
> +return a;
> +}
> +
> +#endif /* __SSE2__ */


This __SSE2__ is kind of strange, and we don't use it anywhere else. I
understand it's not the same thing, but for practical purposes, could we
just use #if ARCH_X86_64 and not care about -msse2?

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

Re: [FFmpeg-devel] [PATCH] x86/vf_w3fdif: 32-bit compatibility for w3fdif_simple_high

[James Almer]

On 1/6/2016 11:54 PM, Hendrik Leppkes wrote:
> ---
> Based on an idea from Ronald mentioend in an earlier thread about this 
> function.
> 
> It works and passes FATE, however I'm sure some aspects can be done easier or 
> cleaner, so please let me know.
> 
> 
>  libavfilter/x86/vf_w3fdif.asm| 37 ++---
>  libavfilter/x86/vf_w3fdif_init.c |  2 +-
>  2 files changed, 35 insertions(+), 4 deletions(-)
> 
> diff --git a/libavfilter/x86/vf_w3fdif.asm b/libavfilter/x86/vf_w3fdif.asm
> index c3c73ea..35768c3 100644
> --- a/libavfilter/x86/vf_w3fdif.asm
> +++ b/libavfilter/x86/vf_w3fdif.asm
> @@ -102,14 +102,22 @@ cglobal w3fdif_complex_low, 4, 7, 8, 0, work_line, 
> in_lines_cur0, coef, linesize
>  REP_RET
>  
>  %if ARCH_X86_64
> -
>  cglobal w3fdif_simple_high, 5, 9, 8, 0, work_line, in_lines_cur0, 
> in_lines_adj0, coef, linesize
> +%else
> +cglobal w3fdif_simple_high, 4, 7, 8, 0, work_line, in_lines_cur0, 
> in_lines_adj0, coef, linesize
> +%endif
>  movq  m2, [coefq]
> -DEFINE_ARGSwork_line, in_lines_cur0, in_lines_adj0, in_lines_cur1, 
> linesize, offset, in_lines_cur2, in_lines_adj1, in_lines_adj2
> +%if ARCH_X86_64
> +DEFINE_ARGSwork_line, in_lines_cur0, in_lines_adj0, linesize, 
> offset, in_lines_cur1, in_lines_cur2, in_lines_adj1, in_lines_adj2

This broke x86_64. Leave it as it was above.

> +mov  offsetq, 0

Since you're moving this take the chance to replace it with a xor.

> +%else
> +DEFINE_ARGSwork_line, in_lines_cur0, in_lines_adj0, in_lines_cur1, 
> in_lines_cur2, in_lines_adj1, in_lines_adj2
> +%define linesized dword r4m

Nit: r4mp instead of dword r4m

> +%endif
> +
>  pshufdm0, m2, q
>  SPLATWm2, m2, 2
>  pxor  m7, m7
> -mov  offsetq, 0
>  mov   in_lines_cur2q, [in_lines_cur0q+gprsize*2]
>  mov   in_lines_cur1q, [in_lines_cur0q+gprsize]
>  mov   in_lines_cur0q, [in_lines_cur0q]
> @@ -117,8 +125,21 @@ cglobal w3fdif_simple_high, 5, 9, 8, 0, work_line, 
> in_lines_cur0, in_lines_adj0,
>  mov   in_lines_adj1q, [in_lines_adj0q+gprsize]
>  mov   in_lines_adj0q, [in_lines_adj0q]
>  
> +%if ARCH_X86_32
> +sub in_lines_cur1q, in_lines_cur0q
> +sub in_lines_cur2q, in_lines_cur0q
> +sub in_lines_adj0q, in_lines_cur0q
> +sub in_lines_adj1q, in_lines_cur0q
> +sub in_lines_adj2q, in_lines_cur0q
> +%define offsetq in_lines_cur0q
> +%endif
> +
>  .loop:
> +%if ARCH_X86_64
>  movh   m3, [in_lines_cur0q+offsetq]
> +%else
> +movh   m3, [in_lines_cur0q]
> +%endif
>  movh   m4, [in_lines_cur1q+offsetq]
>  punpcklbw  m3, m7
>  punpcklbw  m4, m7
> @@ -143,15 +164,25 @@ cglobal w3fdif_simple_high, 5, 9, 8, 0, work_line, 
> in_lines_cur0, in_lines_adj0,
>  pmaddwdm6, m2
>  paddd  m3, m5
>  paddd  m4, m6
> +%if ARCH_X86_64
>  paddd  m3, [work_lineq+offsetq*4]
>  paddd  m4, [work_lineq+offsetq*4+mmsize]
>  mova   [work_lineq+offsetq*4], m3
>  mova[work_lineq+offsetq*4+mmsize], m4
> +%else
> +paddd  m3, [work_lineq]
> +paddd  m4, [work_lineq+mmsize]
> +mova [work_lineq], m3
> +mova  [work_lineq+mmsize], m4
> +addwork_lineq, mmsize*2
> +%endif
>  add   offsetq, mmsize/2
>  sub linesized, mmsize/2
>  jg .loop
>  REP_RET
>  
> +%if ARCH_X86_64
> +
>  cglobal w3fdif_complex_high, 5, 13, 10, 0, work_line, in_lines_cur0, 
> in_lines_adj0, coef, linesize
>  movq  m0, [coefq+0]
>  movd  m4, [coefq+8]
> diff --git a/libavfilter/x86/vf_w3fdif_init.c 
> b/libavfilter/x86/vf_w3fdif_init.c
> index 72ea657..9bf06e8 100644
> --- a/libavfilter/x86/vf_w3fdif_init.c
> +++ b/libavfilter/x86/vf_w3fdif_init.c
> @@ -51,12 +51,12 @@ av_cold void ff_w3fdif_init_x86(W3FDIFDSPContext *dsp)
>  
>  if (EXTERNAL_SSE2(cpu_flags)) {
>  dsp->filter_simple_low   = ff_w3fdif_simple_low_sse2;
> +dsp->filter_simple_high  = ff_w3fdif_simple_high_sse2;
>  dsp->filter_complex_low  = ff_w3fdif_complex_low_sse2;
>  dsp->filter_scale= ff_w3fdif_scale_sse2;
>  }
>  
>  if (ARCH_X86_64 && EXTERNAL_SSE2(cpu_flags)) {
> -dsp->filter_simple_high  = ff_w3fdif_simple_high_sse2;
>  dsp->filter_complex_high = ff_w3fdif_complex_high_sse2;
>  }
>  }
> 

Seems to work. Maybe it can be improved but it should be good as is.

And to 

Re: [FFmpeg-devel] [PATCHv2] avformat/mp3dec, rmdec: check return value of ffio_ensure_seekback

[Ganesh Ajjanagadde]

On Wed, Jan 6, 2016 at 1:25 PM, Michael Niedermayer
 wrote:
> On Tue, Jan 05, 2016 at 09:51:15PM -0800, Ganesh Ajjanagadde wrote:
>> On Tue, Jan 5, 2016 at 4:57 PM, Michael Niedermayer
>>  wrote:
>> > On Tue, Jan 05, 2016 at 01:57:09PM -0800, Ganesh Ajjanagadde wrote:
>> >> On Tue, Jan 5, 2016 at 11:01 AM, wm4  wrote:
>> >> > On Tue, 5 Jan 2016 08:32:02 -0800
>> >> > Ganesh Ajjanagadde  wrote:
>> >> >
>> >> >> On Tue, Jan 5, 2016 at 5:29 AM, wm4  wrote:
>> >> >> > On Mon,  4 Jan 2016 17:50:01 -0800
>> >> >> > Ganesh Ajjanagadde  wrote:
>> >> >> >
>> >> >> >> ffio_ensure_seekback can fail due to e.g ENOMEM. This return value 
>> >> >> >> is
>> >> >> >> checked here and a diagnostic is logged.
>> >> >> >>
>> >> >> >> All usage of ffio_ensure_seekback in the codebase now has the 
>> >> >> >> return value checked.
>> >> >> >>
>> >> >> >> Reviewed-by: wm4 
>> >> >> >> Reviewed-by: Ronald S. Bultje 
>> >> >> >> Reviewed-by: Michael Niedermayer 
>> >> >> >> Signed-off-by: Ganesh Ajjanagadde 
>> >> >> >> ---
>> >> >> >>  libavformat/mp3dec.c | 13 +++--
>> >> >> >>  libavformat/rmdec.c  |  3 ++-
>> >> >> >>  2 files changed, 13 insertions(+), 3 deletions(-)
>> >> >> >>
>> >> >> >> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
>> >> >> >> index c76b21e..57ebcc8 100644
>> >> >> >> --- a/libavformat/mp3dec.c
>> >> >> >> +++ b/libavformat/mp3dec.c
>> >> >> >> @@ -372,11 +372,19 @@ static int mp3_read_header(AVFormatContext *s)
>> >> >> >>  uint32_t header, header2;
>> >> >> >>  int frame_size;
>> >> >> >>  if (!(i&1023))
>> >> >> >> -ffio_ensure_seekback(s->pb, i + 1024 + 4);
>> >> >> >> +if ((ret = ffio_ensure_seekback(s->pb, i + 1024 + 4)) 
>> >> >> >> < 0) {
>> >> >> >> +av_log(s, AV_LOG_WARNING,
>> >> >> >> +   "initial junk detection and skipping 
>> >> >> >> impossible due to: %s\n", av_err2str(ret));
>> >> >> >> +goto skip_fail;
>> >> >> >> +}
>> >> >> >>  frame_size = check(s->pb, off + i, );
>> >> >> >>  if (frame_size > 0) {
>> >> >> >>  avio_seek(s->pb, off, SEEK_SET);
>> >> >> >> -ffio_ensure_seekback(s->pb, i + 1024 + frame_size + 4);
>> >> >> >> +if ((ret = ffio_ensure_seekback(s->pb, i + 1024 + 
>> >> >> >> frame_size + 4)) < 0) {
>> >> >> >> +av_log(s, AV_LOG_WARNING,
>> >> >> >> +   "initial junk detection and skipping 
>> >> >> >> impossible due to: %s\n", av_err2str(ret));
>> >> >> >> +goto skip_fail;
>> >> >> >> +}
>> >> >> >>  if (check(s->pb, off + i + frame_size, ) >= 0 
>> >> >> >> &&
>> >> >> >>  (header & SAME_HEADER_MASK) == (header2 & 
>> >> >> >> SAME_HEADER_MASK))
>> >> >> >>  {
>> >> >> >> @@ -387,6 +395,7 @@ static int mp3_read_header(AVFormatContext *s)
>> >> >> >>  }
>> >> >> >>  avio_seek(s->pb, off, SEEK_SET);
>> >> >> >>  }
>> >> >> >> +skip_fail:
>> >> >> >>
>> >> >> >>  // the seek index is relative to the end of the xing vbr 
>> >> >> >> headers
>> >> >> >>  for (i = 0; i < st->nb_index_entries; i++)
>> >> >> >> diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
>> >> >> >> index 4e46a3d..470e227 100644
>> >> >> >> --- a/libavformat/rmdec.c
>> >> >> >> +++ b/libavformat/rmdec.c
>> >> >> >> @@ -618,7 +618,8 @@ static int rm_read_header(AVFormatContext *s)
>> >> >> >>  size = avio_rb32(pb);
>> >> >> >>  codec_pos = avio_tell(pb);
>> >> >> >>
>> >> >> >> -ffio_ensure_seekback(pb, 4);
>> >> >> >> +if ((ret = ffio_ensure_seekback(pb, 4)) < 0)
>> >> >> >> +av_log(s, AV_LOG_WARNING, "seeking back impossible 
>> >> >> >> due to: %s\n", av_err2str(ret));
>> >> >> >>  v = avio_rb32(pb);
>> >> >> >>  if (v == MKBETAG('M', 'L', 'T', 'I')) {
>> >> >> >>  ret = rm_read_multi(s, s->pb, st, mime);
>> >> >> >
>> >> >> > I maintain that this should not be done, because it makes the code
>> >> >> > verbose for no reason.
>> >> >>
>> >> >> Michael has pointed out that when seekback fails, one should really
>> >> >> break out of the junk detection loop in mp3dec. Your idea fails to
>> >> >> achieve it.
>> >> >
>> >> > Why? It's not really harmful. You could even argue that this will make
>> >> > the common case (skipping jumk and finding a valid frame in a seekable
>> >> > file) work in low memory situations, while your patch breaks it.
>> >
>> > ffio_ensure_seekback() never fails for seekable files
>> > it checks s->seekable and return 0 if true before attempting to
>> > allocate anything
>> >
>> >
>> >>
>> >> I assumed Michael had a good reason for it, but 

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

[Ganesh Ajjanagadde]

On Tue, Jan 5, 2016 at 7:03 PM, Ganesh Ajjanagadde  wrote:
> On Tue, Jan 5, 2016 at 6:44 PM, Michael Niedermayer
>  wrote:
>> On Mon, Jan 04, 2016 at 05:38:46PM -0800, Ganesh Ajjanagadde wrote:
>>> On Sat, Jan 2, 2016 at 7:59 AM, Ganesh Ajjanagadde  wrote:
>>> > On Sat, Jan 2, 2016 at 6:24 AM, Michael Niedermayer
>>> >  wrote:
>>> >> On Fri, Jan 01, 2016 at 05:55:31PM -0800, Ganesh Ajjanagadde wrote:
>>> >>> On Wed, Dec 30, 2015 at 1:01 AM, Hendrik Leppkes  
>>> >>> wrote:
>>> >>> > On Wed, Dec 30, 2015 at 4:39 AM, Ganesh Ajjanagadde
>>> >>> >  wrote:
>>> >>> >> The log is anyway rounded to an integer, so one may use an frexp
>>> >>> >> based approach. Note that this may be made frexpf; if arguments are 
>>> >>> >> less than
>>> >>> >> 2^24 there is no loss. Kept as double precision for simplicity; 2^32 
>>> >>> >> is
>>> >>> >> exactly representable as a double.
>>> >>> >>
>>> >>> >> Signed-off-by: Ganesh Ajjanagadde 
>>> >>> >> ---
>>> >>> >>  ffmpeg.c | 13 -
>>> >>> >>  1 file changed, 12 insertions(+), 1 deletion(-)
>>> >>> >>
>>> >>> >> diff --git a/ffmpeg.c b/ffmpeg.c
>>> >>> >> index 6d01987..ee72f91 100644
>>> >>> >> --- a/ffmpeg.c
>>> >>> >> +++ b/ffmpeg.c
>>> >>> >> @@ -1486,6 +1486,17 @@ static void print_final_stats(int64_t 
>>> >>> >> total_size)
>>> >>> >>  }
>>> >>> >>  }
>>> >>> >>
>>> >>> >> +static inline int log2i(double d)
>>> >>> >> +{
>>> >>> >> +int exp;
>>> >>> >> +double mant;
>>> >>> >> +
>>> >>> >> +mant = frexp(d, );
>>> >>> >> +if (mant >= M_SQRT1_2)
>>> >>> >> +return exp;
>>> >>> >> +return exp-1;
>>> >>> >> +}
>>> >>> >> +
>>> >>> >>  static void print_report(int is_last_report, int64_t timer_start, 
>>> >>> >> int64_t cur_time)
>>> >>> >>  {
>>> >>> >>  char buf[1024];
>>> >>> >> @@ -1559,7 +1570,7 @@ static void print_report(int is_last_report, 
>>> >>> >> int64_t timer_start, int64_t cur_ti
>>> >>> >>  if (qp >= 0 && qp < FF_ARRAY_ELEMS(qp_histogram))
>>> >>> >>  qp_histogram[qp]++;
>>> >>> >>  for (j = 0; j < 32; j++)
>>> >>> >> -snprintf(buf + strlen(buf), sizeof(buf) - 
>>> >>> >> strlen(buf), "%X", (int)lrintf(log2(qp_histogram[j] + 1)));
>>> >>> >> +snprintf(buf + strlen(buf), sizeof(buf) - 
>>> >>> >> strlen(buf), "%X", log2i(qp_histogram[j] + 1));
>>> >>> >>  }
>>> >>> >>
>>> >>> >>  if ((enc->flags & AV_CODEC_FLAG_PSNR) && 
>>> >>> >> (ost->pict_type != AV_PICTURE_TYPE_NONE || is_last_report)) {
>>> >>> >> --
>>> >>> >> 2.6.4
>>> >>> >
>>> >>> > This isn't exactly a performance critical area, and defining a custom
>>> >>> > function just for this seems somewhat like over-optimization.
>>> >>> > Just my opinion, of course, I'll leave the decision up to the
>>> >>> > maintainers of ffmpeg.c
>>> >>>
>>> >>> Ping: based on the above, final decision left to you, Michael.
>>> >>
>>> >> maybe av_log2() could be used, so as to avoid any increase in
>>> >> complexity
>>> >
>>> > Not really, or at least not without additional code. The lrint rounds
>>> > the log; av_log2 either returns the log of the next higher power of 2,
>>> > or the one before it. Thus they are quite different things. I don't
>>> > know if this is wrong or not; I created this to preserve identical
>>> > behavior.
>>>
>>> @Michael: final thoughts?
>>
>> is there any loss of usefullness of the output with av_log2() ?
>> i dont think we need to maintain exactly identical output for
>> such fancy / debug output
>
> AFAIK none, but I was not around when it was made, and I am not a
> heavy user :). Replaced by av_log2 locally, will push tomorrow in
> absence of further comments.

pushed, thanks.

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

Re: [FFmpeg-devel] [PATCH 2/3] libavcodec/ccaption_dec: clean up and standardize white space

[Michael Niedermayer]

On Tue, Jan 05, 2016 at 10:26:05PM -0800, Aman Gupta wrote:
> On Tue, Jan 5, 2016 at 6:24 PM, Michael Niedermayer 
> wrote:
> 
> > On Tue, Jan 05, 2016 at 09:34:35PM +0100, Clément Bœsch wrote:
> > > On Mon, Jan 04, 2016 at 07:28:02PM -0800, Aman Gupta wrote:
> > > > From: Aman Gupta 
> > > >
> > > > ---
> > > >  libavcodec/ccaption_dec.c | 98
> > ++-
> > > >  1 file changed, 45 insertions(+), 53 deletions(-)
> > > >
> > >
> > > There are much more garbage formatting in that file (typically at the
> > > beginning of process_cc608 around braces) but still fine with me.
> >
> > should i apply this patch and the other?
> >
> 
> Please do, as my follow-up patchsets are based on this patch.

ok, applied
ill leave all other cc patches to ubitux as IIUC he wants to
review/apply them

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

[FFmpeg-devel] [PATCH 1/5] asfdec_o: check avio_skip in asf_read_simple_index

[Andreas Cadhalpun]

The loop can be very long, even though the file is very short.

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/asfdec_o.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavformat/asfdec_o.c b/libavformat/asfdec_o.c
index 02809bb..bc168d3 100644
--- a/libavformat/asfdec_o.c
+++ b/libavformat/asfdec_o.c
@@ -970,7 +970,7 @@ static int asf_read_simple_index(AVFormatContext *s, const 
GUIDParseTable *g)
 uint64_t interval; // index entry time interval in 100 ns units, usually 
it's 1s
 uint32_t pkt_num, nb_entries;
 int32_t prev_pkt_num = -1;
-int i;
+int i, ret;
 uint64_t size = avio_rl64(pb);
 
 // simple index objects should be ordered by stream number, this loop 
tries to find
@@ -992,7 +992,11 @@ static int asf_read_simple_index(AVFormatContext *s, const 
GUIDParseTable *g)
 nb_entries = avio_rl32(pb);
 for (i = 0; i < nb_entries; i++) {
 pkt_num = avio_rl32(pb);
-avio_skip(pb, 2);
+ret = avio_skip(pb, 2);
+if (ret < 0) {
+av_log(s, AV_LOG_ERROR, "Skipping failed in 
asf_read_simple_index.\n");
+return ret;
+}
 if (prev_pkt_num != pkt_num) {
 av_add_index_entry(st, asf->first_packet_offset + asf->packet_size 
*
pkt_num, av_rescale(interval, i, 1),
-- 
2.6.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/5] asfdec_o: make sure packet_size is non-zero before seeking

[Andreas Cadhalpun]

This fixes infinite loops due to seeking back.
---
 libavformat/asfdec_o.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/asfdec_o.c b/libavformat/asfdec_o.c
index b81519f..4a3c815 100644
--- a/libavformat/asfdec_o.c
+++ b/libavformat/asfdec_o.c
@@ -1287,6 +1287,10 @@ static int asf_read_payload(AVFormatContext *s, AVPacket 
*pkt)
 }
 if (!asf_pkt) {
 if (asf->packet_offset + asf->packet_size <= asf->data_offset + 
asf->data_size) {
+if (!asf->packet_size) {
+av_log(s, AV_LOG_ERROR, "Invalid packet size 0.\n");
+return AVERROR_INVALIDDATA;
+}
 avio_seek(pb, asf->packet_offset + asf->packet_size, SEEK_SET);
 av_log(s, AV_LOG_WARNING, "Skipping the stream with the 
invalid stream index %d.\n",
asf->stream_index);
-- 
2.6.4

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

[FFmpeg-devel] [PATCH 2/5] asfdec_o: prevent overflow causing seekback

[Andreas Cadhalpun]

This fixes infinite loops.

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/asfdec_o.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/asfdec_o.c b/libavformat/asfdec_o.c
index bc168d3..b81519f 100644
--- a/libavformat/asfdec_o.c
+++ b/libavformat/asfdec_o.c
@@ -167,7 +167,7 @@ static void swap_guid(ff_asf_guid guid)
 
 static void align_position(AVIOContext *pb,  int64_t offset, uint64_t size)
 {
-if (avio_tell(pb) != offset + size)
+if (size < INT64_MAX - offset && avio_tell(pb) != offset + size)
 avio_seek(pb, offset + size, SEEK_SET);
 }
 
-- 
2.6.4

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

[FFmpeg-devel] [PATCH 5/5] asfdec_o: check for too small size in asf_read_unknown

[Andreas Cadhalpun]

This fixes infinite loops due to seeking back.
---
 libavformat/asfdec_o.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavformat/asfdec_o.c b/libavformat/asfdec_o.c
index ca4a066..bc79f10 100644
--- a/libavformat/asfdec_o.c
+++ b/libavformat/asfdec_o.c
@@ -190,8 +190,13 @@ static int asf_read_unknown(AVFormatContext *s, const 
GUIDParseTable *g)
 if ((ret = detect_unknown_subobject(s, asf->unknown_offset,
 asf->unknown_size)) < 0)
 return ret;
-} else
+} else {
+if (size < 24) {
+av_log(s, AV_LOG_ERROR, "Too small size %"PRIu64" (< 24).\n", 
size);
+return AVERROR_INVALIDDATA;
+}
 avio_skip(pb, size - 24);
+}
 
 return 0;
 }
-- 
2.6.4

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

[FFmpeg-devel] [PATCH 4/5] asfdec_o: break if EOF is reached after asf_read_packet_header

[Andreas Cadhalpun]

asf_read_payload can unset eof_reached, so check it also before calling
that function.

This fixes infinite loops.

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/asfdec_o.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/asfdec_o.c b/libavformat/asfdec_o.c
index 4a3c815..ca4a066 100644
--- a/libavformat/asfdec_o.c
+++ b/libavformat/asfdec_o.c
@@ -1434,6 +1434,8 @@ static int asf_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 while (!pb->eof_reached) {
 if (asf->state == PARSE_PACKET_HEADER) {
 asf_read_packet_header(s);
+if (pb->eof_reached)
+break;
 if (!asf->nb_mult_left)
 asf->state = READ_SINGLE;
 else
-- 
2.6.4

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

[FFmpeg-devel] [PATCH 1/3] libavcodec/ccaption_dec: rename to screen_changed to screen_reaped

[Aman Gupta]

From: Aman Gupta 

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

diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index 6dff761..706da16 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -158,7 +158,7 @@ typedef struct CCaptionSubContext {
 uint8_t cursor_color;
 uint8_t cursor_font;
 AVBPrint buffer;
-int screen_changed;
+int screen_reaped;
 int rollup;
 enum cc_mode mode;
 char *prev_string;
@@ -202,7 +202,7 @@ static void flush_decoder(AVCodecContext *avctx)
 ctx->screen[0].row_used = 0;
 ctx->screen[1].row_used = 0;
 av_bprint_clear(>buffer);
-ctx->screen_changed = 1;
+ctx->screen_reaped = 1;
 ctx->mode = CCMODE_POPON;
 }
 
@@ -342,9 +342,9 @@ static int reap_screen(CCaptionSubContext *ctx)
 if (screen->row_used && ctx->buffer.len >= 2) {
 ctx->buffer.len -= 2;
 ctx->buffer.str[ctx->buffer.len] = 0;
-ctx->screen_changed = 1;
 }
 
+ctx->screen_reaped = 1;
 return ret;
 }
 
@@ -553,9 +553,9 @@ static int decode(AVCodecContext *avctx, void *data, int 
*got_sub, AVPacket *avp
 else
 process_cc608(ctx, *(bptr + i + 1) & 0x7f, *(bptr + i + 2) & 0x7f);
 
-if (!ctx->screen_changed)
+if (!ctx->screen_reaped)
 continue;
-ctx->screen_changed = 0;
+ctx->screen_reaped = 0;
 
 if (ctx->calculate_duration) {
 if (ctx->prev_string) {
-- 
2.5.3

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

[FFmpeg-devel] [PATCH 2/3] libavcodec/ccaption_dec: in realtime mode, emit new ASS events every 200ms

[Aman Gupta]

From: Aman Gupta 

---
 libavcodec/ccaption_dec.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index 706da16..737c3f6 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -159,6 +159,7 @@ typedef struct CCaptionSubContext {
 uint8_t cursor_font;
 AVBPrint buffer;
 int screen_reaped;
+int screen_touched;
 int rollup;
 enum cc_mode mode;
 char *prev_string;
@@ -487,6 +488,7 @@ static void process_cc608(CCaptionSubContext *ctx, uint8_t 
hi, uint8_t lo)
 case 0x2c:
 /* erase display memory */
 handle_erase(ctx, ctx->active_screen);
+ctx->screen_touched = 1;
 break;
 case 0x2d:
 /* carriage return */
@@ -513,6 +515,8 @@ static void process_cc608(CCaptionSubContext *ctx, uint8_t 
hi, uint8_t lo)
 } else if (hi >= 0x20) {
 /* Standard characters (always in pairs) */
 handle_char(ctx, hi, lo);
+if (ctx->mode != CCMODE_POPON)
+ctx->screen_touched = 1;
 } else {
 /* Ignoring all other non data code */
 ff_dlog(ctx, "Unknown command 0x%hhx 0x%hhx\n", hi, lo);
@@ -577,9 +581,23 @@ static int decode(AVCodecContext *avctx, void *data, int 
*got_sub, AVPacket *avp
 if (ret < 0)
 return ret;
 sub->pts = av_rescale_q(avpkt->pts, avctx->time_base, 
AV_TIME_BASE_Q);
+ctx->prev_time = avpkt->pts;
 }
 }
 
+if (!ctx->calculate_duration && ctx->screen_touched &&
+avpkt->pts > ctx->prev_time + av_rescale_q(20, ass_tb, 
avctx->time_base)) {
+ctx->screen_touched = 0;
+
+reap_screen(ctx);
+ctx->screen_reaped = 0;
+
+int start_time = av_rescale_q(avpkt->pts, avctx->time_base, ass_tb);
+ff_ass_add_rect_bprint(sub, >buffer, start_time, -1);
+sub->pts = av_rescale_q(avpkt->pts, avctx->time_base, AV_TIME_BASE_Q);
+ctx->prev_time = avpkt->pts;
+}
+
 *got_sub = sub->num_rects > 0;
 return ret;
 }
-- 
2.5.3

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

[FFmpeg-devel] [PATCH 3/3] libavcodec/ccaption_dec: emit blank ASS events only in realtime mode

[Aman Gupta]

From: Aman Gupta 

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

diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index 737c3f6..8e3008d 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -345,7 +345,9 @@ static int reap_screen(CCaptionSubContext *ctx)
 ctx->buffer.str[ctx->buffer.len] = 0;
 }
 
-ctx->screen_reaped = 1;
+if (ctx->buffer.len || !ctx->calculate_duration)
+ctx->screen_reaped = 1;
+
 return ret;
 }
 
-- 
2.5.3

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

Re: [FFmpeg-devel] [PATCH 1/3] libavcodec/ccaption_dec: rename to screen_changed to screen_reaped

[Moritz Barsnick]

On Wed, Jan 06, 2016 at 11:35:10 -0800, Aman Gupta wrote:

> Subject: [FFmpeg-devel] [PATCH 1/3] libavcodec/ccaption_dec: rename to
> screen_changed to screen_reaped

There's a "to" too many in the commit message (the first one).

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

Re: [FFmpeg-devel] [PATCH v5 4/4] mips: display a warning message when using an unknown CPU

[Michael Niedermayer]

On Wed, Jan 06, 2016 at 04:55:29PM +, Vicente Olivert Riera wrote:
> Signed-off-by: Vicente Olivert Riera 
> ---
> Changes v4 -> v5:
>  - Nothing.
> 
> Changes v3 -> v4:
>  - Use a more accurate warning message.
> 
> Changes v2 -> v3:
>  - This patch has been added for v3.
> 
> Changes v1 -> v2:
>  - This patch didn't exist at that point.
> 
>  configure | 2 ++
>  1 file changed, 2 insertions(+)

applied

thanks

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

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


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

Re: [FFmpeg-devel] [FFmpeg-cvslog] mips: display a warning message when using an unknown CPU

[Clément Bœsch]

On Wed, Jan 06, 2016 at 09:28:33PM +0100, Vicente Olivert Riera wrote:
> ffmpeg | branch: master | Vicente Olivert Riera  | 
> Wed Jan  6 16:55:29 2016 +| [6282bdc2bf36ce492d233db38bce219a1a976cfe] | 
> committer: Michael Niedermayer
> 
> mips: display a warning message when using an unknown CPU
> 
> Signed-off-by: Vicente Olivert Riera 
> Signed-off-by: Michael Niedermayer 
> 
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=6282bdc2bf36ce492d233db38bce219a1a976cfe
> ---
> 
>  configure |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/configure b/configure
> index 4d6d4fc..6fda30b 100755
> --- a/configure
> +++ b/configure
> @@ -4238,6 +4238,8 @@ elif enabled mips; then
>  disable msa
>  ;;
>  *)
> +# Unknown CPU. Disable everything.
> +echo "Warning: unknown CPU. Disabling all MIPS optimizations."

We have a warn() function in configure.

[...]

-- 
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] [FFmpeg-cvslog] mips: display a warning message when using an unknown CPU

[Michael Niedermayer]

On Wed, Jan 06, 2016 at 09:44:51PM +0100, Clément Bœsch wrote:
> On Wed, Jan 06, 2016 at 09:28:33PM +0100, Vicente Olivert Riera wrote:
> > ffmpeg | branch: master | Vicente Olivert Riera  
> > | Wed Jan  6 16:55:29 2016 +| 
> > [6282bdc2bf36ce492d233db38bce219a1a976cfe] | committer: Michael Niedermayer
> > 
> > mips: display a warning message when using an unknown CPU
> > 
> > Signed-off-by: Vicente Olivert Riera 
> > Signed-off-by: Michael Niedermayer 
> > 
> > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=6282bdc2bf36ce492d233db38bce219a1a976cfe
> > ---
> > 
> >  configure |2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/configure b/configure
> > index 4d6d4fc..6fda30b 100755
> > --- a/configure
> > +++ b/configure
> > @@ -4238,6 +4238,8 @@ elif enabled mips; then
> >  disable msa
> >  ;;
> >  *)
> > +# Unknown CPU. Disable everything.
> > +echo "Warning: unknown CPU. Disabling all MIPS optimizations."
> 
> We have a warn() function in configure.

fixed

thanks

[...]

-- 
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] [PATCHv2] avformat/mp3dec, rmdec: check return value of ffio_ensure_seekback

[Michael Niedermayer]

On Tue, Jan 05, 2016 at 09:51:15PM -0800, Ganesh Ajjanagadde wrote:
> On Tue, Jan 5, 2016 at 4:57 PM, Michael Niedermayer
>  wrote:
> > On Tue, Jan 05, 2016 at 01:57:09PM -0800, Ganesh Ajjanagadde wrote:
> >> On Tue, Jan 5, 2016 at 11:01 AM, wm4  wrote:
> >> > On Tue, 5 Jan 2016 08:32:02 -0800
> >> > Ganesh Ajjanagadde  wrote:
> >> >
> >> >> On Tue, Jan 5, 2016 at 5:29 AM, wm4  wrote:
> >> >> > On Mon,  4 Jan 2016 17:50:01 -0800
> >> >> > Ganesh Ajjanagadde  wrote:
> >> >> >
> >> >> >> ffio_ensure_seekback can fail due to e.g ENOMEM. This return value is
> >> >> >> checked here and a diagnostic is logged.
> >> >> >>
> >> >> >> All usage of ffio_ensure_seekback in the codebase now has the return 
> >> >> >> value checked.
> >> >> >>
> >> >> >> Reviewed-by: wm4 
> >> >> >> Reviewed-by: Ronald S. Bultje 
> >> >> >> Reviewed-by: Michael Niedermayer 
> >> >> >> Signed-off-by: Ganesh Ajjanagadde 
> >> >> >> ---
> >> >> >>  libavformat/mp3dec.c | 13 +++--
> >> >> >>  libavformat/rmdec.c  |  3 ++-
> >> >> >>  2 files changed, 13 insertions(+), 3 deletions(-)
> >> >> >>
> >> >> >> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> >> >> >> index c76b21e..57ebcc8 100644
> >> >> >> --- a/libavformat/mp3dec.c
> >> >> >> +++ b/libavformat/mp3dec.c
> >> >> >> @@ -372,11 +372,19 @@ static int mp3_read_header(AVFormatContext *s)
> >> >> >>  uint32_t header, header2;
> >> >> >>  int frame_size;
> >> >> >>  if (!(i&1023))
> >> >> >> -ffio_ensure_seekback(s->pb, i + 1024 + 4);
> >> >> >> +if ((ret = ffio_ensure_seekback(s->pb, i + 1024 + 4)) < 
> >> >> >> 0) {
> >> >> >> +av_log(s, AV_LOG_WARNING,
> >> >> >> +   "initial junk detection and skipping 
> >> >> >> impossible due to: %s\n", av_err2str(ret));
> >> >> >> +goto skip_fail;
> >> >> >> +}
> >> >> >>  frame_size = check(s->pb, off + i, );
> >> >> >>  if (frame_size > 0) {
> >> >> >>  avio_seek(s->pb, off, SEEK_SET);
> >> >> >> -ffio_ensure_seekback(s->pb, i + 1024 + frame_size + 4);
> >> >> >> +if ((ret = ffio_ensure_seekback(s->pb, i + 1024 + 
> >> >> >> frame_size + 4)) < 0) {
> >> >> >> +av_log(s, AV_LOG_WARNING,
> >> >> >> +   "initial junk detection and skipping 
> >> >> >> impossible due to: %s\n", av_err2str(ret));
> >> >> >> +goto skip_fail;
> >> >> >> +}
> >> >> >>  if (check(s->pb, off + i + frame_size, ) >= 0 &&
> >> >> >>  (header & SAME_HEADER_MASK) == (header2 & 
> >> >> >> SAME_HEADER_MASK))
> >> >> >>  {
> >> >> >> @@ -387,6 +395,7 @@ static int mp3_read_header(AVFormatContext *s)
> >> >> >>  }
> >> >> >>  avio_seek(s->pb, off, SEEK_SET);
> >> >> >>  }
> >> >> >> +skip_fail:
> >> >> >>
> >> >> >>  // the seek index is relative to the end of the xing vbr headers
> >> >> >>  for (i = 0; i < st->nb_index_entries; i++)
> >> >> >> diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
> >> >> >> index 4e46a3d..470e227 100644
> >> >> >> --- a/libavformat/rmdec.c
> >> >> >> +++ b/libavformat/rmdec.c
> >> >> >> @@ -618,7 +618,8 @@ static int rm_read_header(AVFormatContext *s)
> >> >> >>  size = avio_rb32(pb);
> >> >> >>  codec_pos = avio_tell(pb);
> >> >> >>
> >> >> >> -ffio_ensure_seekback(pb, 4);
> >> >> >> +if ((ret = ffio_ensure_seekback(pb, 4)) < 0)
> >> >> >> +av_log(s, AV_LOG_WARNING, "seeking back impossible 
> >> >> >> due to: %s\n", av_err2str(ret));
> >> >> >>  v = avio_rb32(pb);
> >> >> >>  if (v == MKBETAG('M', 'L', 'T', 'I')) {
> >> >> >>  ret = rm_read_multi(s, s->pb, st, mime);
> >> >> >
> >> >> > I maintain that this should not be done, because it makes the code
> >> >> > verbose for no reason.
> >> >>
> >> >> Michael has pointed out that when seekback fails, one should really
> >> >> break out of the junk detection loop in mp3dec. Your idea fails to
> >> >> achieve it.
> >> >
> >> > Why? It's not really harmful. You could even argue that this will make
> >> > the common case (skipping jumk and finding a valid frame in a seekable
> >> > file) work in low memory situations, while your patch breaks it.
> >
> > ffio_ensure_seekback() never fails for seekable files
> > it checks s->seekable and return 0 if true before attempting to
> > allocate anything
> >
> >
> >>
> >> I assumed Michael had a good reason for it, but from what you say here
> >> and my examination just now, I would at a first glance agree with you.
> >> Ronald had concerns about repetition of messages, so if he (and
> >> Michael) are fine with logging within