date:20151116

Re: [FFmpeg-devel] [PATCH 2/4] lavf/utils: avoid decoding a frame to get the codec parameters

2015-11-16 Thread Matthieu Bouron

On Sun, Nov 15, 2015 at 08:12:57AM -0500, Ronald S. Bultje wrote:
> Hi,

Hi,

> 
> On Sun, Nov 15, 2015 at 4:49 AM, Matthieu Bouron 
> wrote:
> 
> > On Mon, Nov 02, 2015 at 07:56:50AM -0500, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Mon, Nov 2, 2015 at 5:45 AM, Matthieu Bouron <
> > matthieu.bou...@gmail.com>
> > > wrote:
> > >
> > > > From: Matthieu Bouron 
> > > >
> > > > Avoid decoding a frame to get the codec parameters while the codec
> > > > supports FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM. This is particulary useful
> > > > to avoid decoding twice images (once in avformat_find_stream_info and
> > > > once when the actual decode is made).
> > > > ---
> > > >  libavformat/utils.c | 12 
> > > >  1 file changed, 12 insertions(+)
> > > >
> > > > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > > > index 5c4d452..ba62f2b 100644
> > > > --- a/libavformat/utils.c
> > > > +++ b/libavformat/utils.c
> > > > @@ -2695,6 +2695,8 @@ static int try_decode_frame(AVFormatContext *s,
> > > > AVStream *st, AVPacket *avpkt,
> > > >  AVFrame *frame = av_frame_alloc();
> > > >  AVSubtitle subtitle;
> > > >  AVPacket pkt = *avpkt;
> > > > +int do_skip_frame = 0;
> > > > +enum AVDiscard skip_frame;
> > > >
> > > >  if (!frame)
> > > >  return AVERROR(ENOMEM);
> > > > @@ -2733,6 +2735,12 @@ static int try_decode_frame(AVFormatContext *s,
> > > > AVStream *st, AVPacket *avpkt,
> > > >  goto fail;
> > > >  }
> > > >
> > > > +if (st->codec->codec->caps_internal &
> > > > FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM) {
> > > > +do_skip_frame = 1;
> > > > +skip_frame = st->codec->skip_frame;
> > > > +st->codec->skip_frame = AVDISCARD_ALL;
> > > > +}
> > > > +
> > > >  while ((pkt.size > 0 || (!pkt.data && got_picture)) &&
> > > > ret >= 0 &&
> > > > (!has_codec_parameters(st, NULL) ||
> > > > !has_decode_delay_been_guessed(st) ||
> > > > @@ -2768,6 +2776,10 @@ static int try_decode_frame(AVFormatContext *s,
> > > > AVStream *st, AVPacket *avpkt,
> > > >  ret = -1;
> > > >
> > > >  fail:
> > > > +if (do_skip_frame) {
> > > > +st->codec->skip_frame = skip_frame;
> > > > +}
> > > > +
> > > >  av_frame_free();
> > > >  return ret;
> > > >  }
> > > > --
> > > > 2.6.2
> > >
> > >
> > > I think we need an assert in the try_decode loop to ensure that it indeed
> > > did fill all the params. This is to prevent the case where someone adds a
> > > new "thing" to the list of things required for find_stream_info to
> > succeed,
> > > and forgets to update the codecs.
> >
> > While the codec_has_parameters function fits that role, it does not check
> > all codec parameters as they can be codec dependant.
> >
> > I'm not sure if we can create a generic rule here for the same reason as
> > above, as the parameters set can be codec specific and maybe stream
> > specific.
> >
> > Having some fate test to cover this area seems to be another option but
> > would
> > require to inspect all the relevant parameters of AVCodecContext depending
> > on the codec and a lot of different streams.
> 
> 
> I don't care about _which_ parameters were filled. The goal of this option
> is only directly to fill parameters, but the purpose goes far beyond that.
> The indirect goal of this change is to _not_ call try_decode_frame() for
> certain image codecs. Whether they do that by dancing on the table or by
> filling AVCodecContext parameters when a special flag is set, is merely an
> implementation detail.
> 
> I want the test to confirm that we did not call try_decode_frame() when the
> skip-flag was set. It seems easiest to me that we check that by adding a
> one-line assert, for example inside try_decode_frame, that checks that the
> flag does not apply to this codec, right? If the assert triggers, clearly
> something broke, and either the flag should be removed, or the check before
> starting try_decode_frame fixed.

The try_decode_frame function still need to be executed even if the
decoder supports FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM as it still
need to parse the first frame to set the relevant parameters.

The flag only says that the decoder still do the actual parsing even if
the frame is discarded due to the skip_frame option.

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

Re: [FFmpeg-devel] [PATCH 2/4] lavf/utils: avoid decoding a frame to get the codec parameters

2015-11-16 Thread Ronald S. Bultje

Hi,

On Mon, Nov 16, 2015 at 11:06 AM, Matthieu Bouron  wrote:

> On Sun, Nov 15, 2015 at 08:12:57AM -0500, Ronald S. Bultje wrote:
> > Hi,
>
> Hi,
>
> >
> > On Sun, Nov 15, 2015 at 4:49 AM, Matthieu Bouron <
> matthieu.bou...@gmail.com>
> > wrote:
> >
> > > On Mon, Nov 02, 2015 at 07:56:50AM -0500, Ronald S. Bultje wrote:
> > > > Hi,
> > > >
> > > > On Mon, Nov 2, 2015 at 5:45 AM, Matthieu Bouron <
> > > matthieu.bou...@gmail.com>
> > > > wrote:
> > > >
> > > > > From: Matthieu Bouron 
> > > > >
> > > > > Avoid decoding a frame to get the codec parameters while the codec
> > > > > supports FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM. This is particulary
> useful
> > > > > to avoid decoding twice images (once in avformat_find_stream_info
> and
> > > > > once when the actual decode is made).
> > > > > ---
> > > > >  libavformat/utils.c | 12 
> > > > >  1 file changed, 12 insertions(+)
> > > > >
> > > > > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > > > > index 5c4d452..ba62f2b 100644
> > > > > --- a/libavformat/utils.c
> > > > > +++ b/libavformat/utils.c
> > > > > @@ -2695,6 +2695,8 @@ static int try_decode_frame(AVFormatContext
> *s,
> > > > > AVStream *st, AVPacket *avpkt,
> > > > >  AVFrame *frame = av_frame_alloc();
> > > > >  AVSubtitle subtitle;
> > > > >  AVPacket pkt = *avpkt;
> > > > > +int do_skip_frame = 0;
> > > > > +enum AVDiscard skip_frame;
> > > > >
> > > > >  if (!frame)
> > > > >  return AVERROR(ENOMEM);
> > > > > @@ -2733,6 +2735,12 @@ static int try_decode_frame(AVFormatContext
> *s,
> > > > > AVStream *st, AVPacket *avpkt,
> > > > >  goto fail;
> > > > >  }
> > > > >
> > > > > +if (st->codec->codec->caps_internal &
> > > > > FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM) {
> > > > > +do_skip_frame = 1;
> > > > > +skip_frame = st->codec->skip_frame;
> > > > > +st->codec->skip_frame = AVDISCARD_ALL;
> > > > > +}
> > > > > +
> > > > >  while ((pkt.size > 0 || (!pkt.data && got_picture)) &&
> > > > > ret >= 0 &&
> > > > > (!has_codec_parameters(st, NULL) ||
> > > > > !has_decode_delay_been_guessed(st) ||
> > > > > @@ -2768,6 +2776,10 @@ static int try_decode_frame(AVFormatContext
> *s,
> > > > > AVStream *st, AVPacket *avpkt,
> > > > >  ret = -1;
> > > > >
> > > > >  fail:
> > > > > +if (do_skip_frame) {
> > > > > +st->codec->skip_frame = skip_frame;
> > > > > +}
> > > > > +
> > > > >  av_frame_free();
> > > > >  return ret;
> > > > >  }
> > > > > --
> > > > > 2.6.2
> > > >
> > > >
> > > > I think we need an assert in the try_decode loop to ensure that it
> indeed
> > > > did fill all the params. This is to prevent the case where someone
> adds a
> > > > new "thing" to the list of things required for find_stream_info to
> > > succeed,
> > > > and forgets to update the codecs.
> > >
> > > While the codec_has_parameters function fits that role, it does not
> check
> > > all codec parameters as they can be codec dependant.
> > >
> > > I'm not sure if we can create a generic rule here for the same reason
> as
> > > above, as the parameters set can be codec specific and maybe stream
> > > specific.
> > >
> > > Having some fate test to cover this area seems to be another option but
> > > would
> > > require to inspect all the relevant parameters of AVCodecContext
> depending
> > > on the codec and a lot of different streams.
> >
> >
> > I don't care about _which_ parameters were filled. The goal of this
> option
> > is only directly to fill parameters, but the purpose goes far beyond
> that.
> > The indirect goal of this change is to _not_ call try_decode_frame() for
> > certain image codecs. Whether they do that by dancing on the table or by
> > filling AVCodecContext parameters when a special flag is set, is merely
> an
> > implementation detail.
> >
> > I want the test to confirm that we did not call try_decode_frame() when
> the
> > skip-flag was set. It seems easiest to me that we check that by adding a
> > one-line assert, for example inside try_decode_frame, that checks that
> the
> > flag does not apply to this codec, right? If the assert triggers, clearly
> > something broke, and either the flag should be removed, or the check
> before
> > starting try_decode_frame fixed.
>
> The try_decode_frame function still need to be executed even if the
> decoder supports FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM as it still
> need to parse the first frame to set the relevant parameters.
>
> The flag only says that the decoder still do the actual parsing even if
> the frame is discarded due to the skip_frame option.


Oh right, so I guess the assert should then say that after 1 frame (or 2,
or whatever), the try_decode_loop actually succeeded?

I mean, you' see what I'm trying to get at right? I'm trying to get you to
add a check to make sure that this flag does not undetectably break after a
few

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

2015-11-16 Thread Hendrik Leppkes

On Mon, Nov 16, 2015 at 1:52 PM, Ganesh Ajjanagadde  wrote:
> On Mon, Nov 16, 2015 at 3:27 AM, wm4  wrote:
>> On Sun, 15 Nov 2015 17:56:22 -0500
>> Ganesh Ajjanagadde  wrote:
>>
>>> ffio_ensure_seekback can fail due to e.g ENOMEM. This return value is
>>> propagated here, and all usage in the codebase now has its return value
>>> checked.
>>>
>>> A potential memory leak in mp3_read_header is also fixed via a goto
>>> fail.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavformat/mp3dec.c | 12 +---
>>>  libavformat/rmdec.c  |  3 ++-
>>>  2 files changed, 11 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
>>> index 32ca00c..9fefe2d 100644
>>> --- a/libavformat/mp3dec.c
>>> +++ b/libavformat/mp3dec.c
>>> @@ -373,18 +373,20 @@ static int mp3_read_header(AVFormatContext *s)
>>>
>>>  ret = ff_replaygain_export(st, s->metadata);
>>>  if (ret < 0)
>>> -return ret;
>>> +goto fail;
>>>
>>>  off = avio_tell(s->pb);
>>>  for (i = 0; i < 64 * 1024; i++) {
>>>  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)
>>> +goto 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)
>>> +goto fail;
>>>  if (check(s->pb, off + i + frame_size, ) >= 0 &&
>>>  (header & SAME_HEADER_MASK) == (header2 & 
>>> SAME_HEADER_MASK))
>>>  {
>>> @@ -402,6 +404,10 @@ static int mp3_read_header(AVFormatContext *s)
>>>
>>>  /* the parameters will be extracted from the compressed bitstream */
>>>  return 0;
>>> +
>>> +fail:
>>> +ff_free_stream(s, st);
>>> +return ret;
>>>  }
>>>
>>>  #define MP3_PACKET_SIZE 1024
>>> diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
>>> index 4ec78ef..d6e820e 100644
>>> --- a/libavformat/rmdec.c
>>> +++ b/libavformat/rmdec.c
>>> @@ -576,7 +576,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)
>>> +goto fail;
>>>  v = avio_rb32(pb);
>>>  if (v == MKBETAG('M', 'L', 'T', 'I')) {
>>>  int number_of_streams = avio_rb16(pb);
>>
>> NACK. There's no reason to fatally fail in these cases.
>
> Ok, will split into two for the memory leak and these return values.
> For the return values, will simply log at AV_LOG_WARNING.
>

There is no actual memory leak here, the stream is free'ed when the
format context is closed.

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

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

2015-11-16 Thread Ganesh Ajjanagadde

On Mon, Nov 16, 2015 at 3:27 AM, wm4  wrote:
> On Sun, 15 Nov 2015 17:56:22 -0500
> Ganesh Ajjanagadde  wrote:
>
>> ffio_ensure_seekback can fail due to e.g ENOMEM. This return value is
>> propagated here, and all usage in the codebase now has its return value
>> checked.
>>
>> A potential memory leak in mp3_read_header is also fixed via a goto
>> fail.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavformat/mp3dec.c | 12 +---
>>  libavformat/rmdec.c  |  3 ++-
>>  2 files changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
>> index 32ca00c..9fefe2d 100644
>> --- a/libavformat/mp3dec.c
>> +++ b/libavformat/mp3dec.c
>> @@ -373,18 +373,20 @@ static int mp3_read_header(AVFormatContext *s)
>>
>>  ret = ff_replaygain_export(st, s->metadata);
>>  if (ret < 0)
>> -return ret;
>> +goto fail;
>>
>>  off = avio_tell(s->pb);
>>  for (i = 0; i < 64 * 1024; i++) {
>>  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)
>> +goto 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)
>> +goto fail;
>>  if (check(s->pb, off + i + frame_size, ) >= 0 &&
>>  (header & SAME_HEADER_MASK) == (header2 & SAME_HEADER_MASK))
>>  {
>> @@ -402,6 +404,10 @@ static int mp3_read_header(AVFormatContext *s)
>>
>>  /* the parameters will be extracted from the compressed bitstream */
>>  return 0;
>> +
>> +fail:
>> +ff_free_stream(s, st);
>> +return ret;
>>  }
>>
>>  #define MP3_PACKET_SIZE 1024
>> diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
>> index 4ec78ef..d6e820e 100644
>> --- a/libavformat/rmdec.c
>> +++ b/libavformat/rmdec.c
>> @@ -576,7 +576,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)
>> +goto fail;
>>  v = avio_rb32(pb);
>>  if (v == MKBETAG('M', 'L', 'T', 'I')) {
>>  int number_of_streams = avio_rb16(pb);
>
> NACK. There's no reason to fatally fail in these cases.

Ok, will split into two for the memory leak and these return values.
For the return values, will simply log at AV_LOG_WARNING.

> ___
> 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 04/13] Remove --mips64r6 configure option

2015-11-16 Thread Vicente Olivert Riera

Having a configure option with the same name as a MIPS ISA is confusing,
so better to remove it. This option was being used to add some
optimizations to a specific core (i6400). We will add the optimizations
just when the i6400 core has been detected, in a later patch.

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

diff --git a/configure b/configure
index fa5207c..d180c0d 100755
--- a/configure
+++ b/configure
@@ -378,7 +378,6 @@ Optimization options (experts only):
   --disable-neon   disable NEON optimizations
   --disable-inline-asm disable use of inline assembly
   --disable-yasm   disable use of nasm/yasm assembly
-  --disable-mips64r6   disable MIPS64R6 optimizations
   --disable-mipsdspdisable MIPS DSP ASE R1 optimizations
   --disable-mipsdspr2  disable MIPS DSP ASE R2 optimizations
   --disable-msadisable MSA optimizations
@@ -4941,14 +4940,8 @@ elif enabled mips; then
 elif enabled mipsdsp || enabled mipsdspr2; then
 add_cflags "-mips32r2 -mfp32"
 add_asflags "-mips32r2 -mfp32"
-elif enabled mips64r6; then
-check_cflags "-mfp64"
-check_ldflags "-mfp64"
 fi
 
-enabled mips64r6  && check_cflags "-mips64r6 -msched-weight 
-mload-store-pairs -funroll-loops" &&
- check_ldflags "-mips64r6" &&
- check_inline_asm mips64r6  '"aui $t0, $t1, 1"'
 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" &&
@@ -4958,7 +4951,6 @@ elif enabled mips; then
 enabled msa   && check_cflags "-mmsa" && check_ldflags "-mmsa" &&
  check_inline_asm msa   '"addvi.b $w0, $w1, 1"'
 
-enabled mips64r6 && add_asflags "-mips64r6 -mfp64"
 enabled msa && add_asflags "-mmsa"
 
 if enabled mipsdspr2; then
@@ -6034,7 +6026,6 @@ if enabled arm; then
 fi
 if enabled mips; then
 echo "MIPS FPU enabled  ${mipsfpu-no}"
-echo "MIPS64R6 enabled  ${mips64r6-no}"
 echo "MIPS DSP R1 enabled   ${mipsdsp-no}"
 echo "MIPS DSP R2 enabled   ${mipsdspr2-no}"
 echo "MIPS MSA enabled  ${msa-no}"
-- 
1.7.1

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

Re: [FFmpeg-devel] [PATCH] fate: fix concat demuxer extended test portability

2015-11-16 Thread Timothy Gu

tr -d '\r' ?

Timothy

El El lun, 16 de nov de 2015 a las 4:26 AM, Marton Balint 
escribió:

> Sed \r is not portable, it does not work on freebsd, hopefully awk will.
>
> Signed-off-by: Marton Balint 
> ---
>  tests/fate-run.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> index 966cbe2..a23f1e3 100755
> --- a/tests/fate-run.sh
> +++ b/tests/fate-run.sh
> @@ -262,7 +262,7 @@ concat(){
>  awk "{gsub(/%SRCFILE%/, \"$sample\"); print}" $template > $concatfile
>
>  if [ "$mode" = "md5" ]; then
> -  run ffprobe${PROGSUF} -show_streams -show_packets -v 0 -fflags
> keepside -safe 0 $extra_args $concatfile | sed 's/\r//g' > $packetfile
> +  run ffprobe${PROGSUF} -show_streams -show_packets -v 0 -fflags
> keepside -safe 0 $extra_args $concatfile | awk '{gsub(/\r$/,""); print;}' >
> $packetfile
>do_md5sum $packetfile
>  else
>run ffprobe${PROGSUF} -show_streams -show_packets -v 0 -of
> compact=p=0:nk=1 -fflags keepside -safe 0 $extra_args $concatfile
> --
> 2.6.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] aacsbr_fixed: avoid division by zero in sbr_gain_calc

2015-11-16 Thread Michael Niedermayer

On Fri, Nov 13, 2015 at 11:19:44PM +0100, Andreas Cadhalpun wrote:
> On 13.11.2015 04:21, Michael Niedermayer wrote:
> > On Thu, Nov 12, 2015 at 08:51:28PM +0100, Andreas Cadhalpun wrote:
> >> On 11.11.2015 23:19, Michael Niedermayer wrote:
> >>> On Wed, Nov 11, 2015 at 09:31:18PM +0100, Andreas Cadhalpun wrote:
>  I'm not sure, but it can happen, when q_mapped is very small, which can 
>  be
>  caused by noise_facs becoming tiny in sbr_dequant.
>  That's kind of the opposite problem of 'envelope scalefactors 
>  overflowing'.
> >>>
> >>> sbr_dequant() does not look like it can set noise_facs to 0
> >>> except by underflow of the exponent range
> >>
> >> That's exactly what happens.
> >>
> >>> that "has" to be invalid as this depends on the implementation 
> >>
> >> So should sbr_dequant error out instead?
> >> If so, what's the minimal value it should accept?
> > 
> > I dont know the valid range, and i doubt the spec lists this
> > so picking what causes a problem (0) would be the easy solution
> > thats what i would suggest in absence of other suggestions
> 
> Well, unfortunately just rejecting 0 in sbr_dequant is no solution,
> because, as you noticed, that only happens via underflow.

a value that has underflowed should be 0, so underflow affecting
anything implies 0 as result and so a check for 0 would cover all
underflows
I think i misunderstand somehow


> One could check for exponents smaller than MIN_EXP, but since

exponents must not be smaller than MIN_EXP.
no *_sf function should set such an exponent. code directly writing
exponents has to check for exp < MIN_EXP
that could in principle be done by using a _sf function which allows
such exponents on input and clears it up on output


> the exponent can get smaller during the calculations in sbr_gain_calc,
> that wouldn't necessarily avoid the division by 0.
> 

> Additionally both sbr_dequant and sbr_gain_calc are void functions,
> so can't easily return errors.

iam not sure i understand your concern ?
the resturn type is easy changeable or  flag could be added to the
context indicating an error or a simpler hack could be used to
fix this in the releases with a more complete cleanup in master

but maybe iam missing something why you consider this to be a bad
solution ?


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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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

[FFmpeg-devel] [PATCH 13/13] Add support for MIPS R6

2015-11-16 Thread 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 
---
 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 deletions(-)

diff --git a/libavcodec/mips/aaccoder_mips.c b/libavcodec/mips/aaccoder_mips.c
index e8e1e62..2385ed2 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;
@@ -2412,10 +2413,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;
 
@@ -2429,5 +2432,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 596dcad..a216df6 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 == 21 )
+#if !HAVE_MIPS32R6 && !HAVE_MIPS64R6
 static void calc_thr_3gpp_mips(const

[FFmpeg-devel] [PATCH 06/13] MIPS i6400 core do has an FPU, so not disable it

2015-11-16 Thread Vicente Olivert Riera

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

diff --git a/configure b/configure
index e1c8851..ff5e132 100755
--- a/configure
+++ b/configure
@@ -4100,7 +4100,6 @@ elif enabled mips; then
 i6400)
 disable mipsdsp
 disable mipsdspr2
-disable mipsfpu
 check_cflags "-mtune=i6400 -mabi=64" &&
 check_cflags "-mfp64 -msched-weight -mload-store-pairs 
-funroll-loops" &&
 check_ldflags "-mabi=64" &&
-- 
1.7.1

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

[FFmpeg-devel] [PATCH 05/13] Add MIPS i6400 core optimizations

2015-11-16 Thread Vicente Olivert Riera

Signed-off-by: Vicente Olivert Riera 
---
 configure |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index d180c0d..e1c8851 100755
--- a/configure
+++ b/configure
@@ -4101,9 +4101,10 @@ elif enabled mips; then
 disable mipsdsp
 disable mipsdspr2
 disable mipsfpu
-
-check_cflags "-mtune=i6400 -mabi=64"
-check_ldflags "-mabi=64"
+check_cflags "-mtune=i6400 -mabi=64" &&
+check_cflags "-mfp64 -msched-weight -mload-store-pairs 
-funroll-loops" &&
+check_ldflags "-mabi=64" &&
+add_asflags "-mfp64"
 ;;
 loongson*)
 disable mipsfpu
-- 
1.7.1

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

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

2015-11-16 Thread Ganesh Ajjanagadde

On Mon, Nov 16, 2015 at 6:55 AM, Michael Niedermayer
 wrote:
> On Sat, Nov 14, 2015 at 08:05:59PM -0500, Ganesh Ajjanagadde wrote:
>> isnan and isinf are actually macros as per the standard. In particular,
>> the existing implementation has incorrect signature. Furthermore, this
>> results in undefined behavior for e.g double values outside float range
>> as per the standard.
>>
>> This patch corrects the undefined behavior for all usage within FFmpeg.
>> There are some issues with long double, but they are theoretical at the
>> moment. For instance, the usual culprit for lacking isinf and that uses
>> this fallback is Microsoft, and on Microsoft, long double = double
>> anyway. Furthermore, no client of isinf, isnan in the codebase actually
>> uses long double arguments.
>>
>> The above issue is harder because long double may be an IEEE 128 bit quad
>> (very rare) or a 80 bit extended precision value (on GCC/Clang).
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavutil/libm.h | 50 --
>>  1 file changed, 48 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavutil/libm.h b/libavutil/libm.h
>> index ab5df1b..04d9411 100644
>> --- a/libavutil/libm.h
>> +++ b/libavutil/libm.h
>> @@ -91,23 +91,69 @@ static av_always_inline av_const double hypot(double x, 
>> double y)
>>  #endif /* HAVE_HYPOT */
>>
>>  #if !HAVE_ISINF
>> -static av_always_inline av_const int isinf(float x)
>> +#undef isinf
>> +/* Note: these do not follow the BSD/Apple/GNU convention of returning -1 
>> for
>> +-Inf, +1 for Inf, 0 otherwise, but merely follow the POSIX/ISO mandated 
>> spec of
>> +returning a non-zero value for +/-Inf, 0 otherwise. */
>> +static av_always_inline av_const int avpriv_isinff(float x)
>>  {
>>  uint32_t v = av_float2int(x);
>>  if ((v & 0x7f80) != 0x7f80)
>>  return 0;
>>  return !(v & 0x007f);
>>  }
>> +
>> +static av_always_inline av_const int avpriv_isinf(double x)
>> +{
>> +uint64_t v = av_double2int(x);
>> +if ((v & 0x7ff0) != 0x7ff0)
>> +return 0;
>> +return !(v & 0x000f);
>> +}
>> +
>
>> +static av_always_inline av_const int avpriv_isinfl(long double x)
>> +{
>> +// FIXME: just a stub, hard as long double width can vary between 
>> platforms
>> +// Also currently irrelevant
>> +return avpriv_isinf(x);
>> +}
>
> i think we should not add any long double code. It could break
> build and is unused

long double is C89, C99 made it useful by adding support for it in
stdlib with sinl etc.
Nevertheless, since we don't use it, agreed. Still feel a comment with
a TODO is useful.
Will rework and post later.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Awnsering whenever a program halts or runs forever is
> On a turing machine, in general impossible (turings halting problem).
> On any real computer, always possible as a real computer has a finite number
> of states N, and will either halt in less than N cycles or never halt.
>
> ___
> 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 01/13] Rename mipsdspr1 to mipsdsp

2015-11-16 Thread Vicente Olivert Riera

Signed-off-by: Vicente Olivert Riera 
---
 Makefile  |2 +-
 arch.mak  |2 +-
 configure |   34 +
 libavcodec/aacenc.c   |2 +-
 libavcodec/mips/Makefile  |4 +-
 libavcodec/mips/ac3dsp_mips.c |4 +-
 libavcodec/mips/mpegaudiodsp_mips_fixed.c |2 +-
 libavcodec/mpegaudiodec_template.c|4 +-
 libavcodec/mpegaudiodsp.c |2 +-
 libavcodec/mpegaudiodsp.h |2 +-
 10 files changed, 32 insertions(+), 26 deletions(-)

diff --git a/Makefile b/Makefile
index 306f060..6c53ceb 100644
--- a/Makefile
+++ b/Makefile
@@ -85,7 +85,7 @@ SUBDIR_VARS := CLEANFILES EXAMPLES FFLIBS HOSTPROGS TESTPROGS 
TOOLS  \
HEADERS ARCH_HEADERS BUILT_HEADERS SKIPHEADERS\
ARMV5TE-OBJS ARMV6-OBJS ARMV8-OBJS VFP-OBJS NEON-OBJS \
ALTIVEC-OBJS MMX-OBJS YASM-OBJS   \
-   MIPSFPU-OBJS MIPSDSPR2-OBJS MIPSDSPR1-OBJS MSA-OBJS   \
+   MIPSFPU-OBJS MIPSDSPR2-OBJS MIPSDSP-OBJS MSA-OBJS \
MMI-OBJS OBJS SLIBOBJS HOSTOBJS TESTOBJS
 
 define RESET
diff --git a/arch.mak b/arch.mak
index 98fde4a..08f78b4 100644
--- a/arch.mak
+++ b/arch.mak
@@ -5,7 +5,7 @@ OBJS-$(HAVE_VFP) += $(VFP-OBJS) $(VFP-OBJS-yes)
 OBJS-$(HAVE_NEON)+= $(NEON-OBJS)$(NEON-OBJS-yes)
 
 OBJS-$(HAVE_MIPSFPU)   += $(MIPSFPU-OBJS)$(MIPSFPU-OBJS-yes)
-OBJS-$(HAVE_MIPSDSPR1) += $(MIPSDSPR1-OBJS)  $(MIPSDSPR1-OBJS-yes)
+OBJS-$(HAVE_MIPSDSP)   += $(MIPSDSP-OBJS)$(MIPSDSP-OBJS-yes)
 OBJS-$(HAVE_MIPSDSPR2) += $(MIPSDSPR2-OBJS)  $(MIPSDSPR2-OBJS-yes)
 OBJS-$(HAVE_MSA)   += $(MSA-OBJS)$(MSA-OBJS-yes)
 OBJS-$(HAVE_MMI)   += $(MMI-OBJS)   $(MMI-OBJS-yes)
diff --git a/configure b/configure
index 9a736ce..0461a97 100755
--- a/configure
+++ b/configure
@@ -380,7 +380,7 @@ Optimization options (experts only):
   --disable-yasm   disable use of nasm/yasm assembly
   --disable-mips32r5   disable MIPS32R5 optimizations
   --disable-mips64r6   disable MIPS64R6 optimizations
-  --disable-mipsdspr1  disable MIPS DSP ASE R1 optimizations
+  --disable-mipsdspdisable MIPS DSP ASE R1 optimizations
   --disable-mipsdspr2  disable MIPS DSP ASE R2 optimizations
   --disable-msadisable MSA optimizations
   --disable-mipsfpudisable floating point MIPS optimizations
@@ -1627,7 +1627,7 @@ ARCH_EXT_LIST_MIPS="
 mips32r2
 mips32r5
 mips64r6
-mipsdspr1
+mipsdsp
 mipsdspr2
 msa
 "
@@ -2102,7 +2102,7 @@ setend_deps="arm"
 map 'eval ${v}_inline_deps=inline_asm' $ARCH_EXT_LIST_ARM
 
 mipsfpu_deps="mips"
-mipsdspr1_deps="mips"
+mipsdsp_deps="mips"
 mipsdspr2_deps="mips"
 mips32r2_deps="mips"
 mips32r5_deps="mips"
@@ -4064,14 +4064,14 @@ elif enabled mips; then
 disable mips32r5
 disable mips64r6
 disable mipsfpu
-disable mipsdspr1
+disable mipsdsp
 disable mipsdspr2
 disable msa
 ;;
 24kf*)
 disable mips32r5
 disable mips64r6
-disable mipsdspr1
+disable mipsdsp
 disable mipsdspr2
 disable msa
 ;;
@@ -4101,14 +4101,14 @@ elif enabled mips; then
 ;;
 p5600)
 disable mips64r6
-disable mipsdspr1
+disable mipsdsp
 disable mipsdspr2
 
 check_cflags "-mtune=p5600"
 ;;
 i6400)
 disable mips32r5
-disable mipsdspr1
+disable mipsdsp
 disable mipsdspr2
 disable mipsfpu
 
@@ -4120,7 +4120,7 @@ elif enabled mips; then
 disable mips32r2
 disable mips32r5
 disable mips64r6
-disable mipsdspr1
+disable mipsdsp
 disable mipsdspr2
 disable msa
 enable local_aligned_8 local_aligned_16 local_aligned_32
@@ -4152,7 +4152,7 @@ elif enabled mips; then
 disable mips32r2
 disable mips32r5
 disable mips64r6
-disable mipsdspr1
+disable mipsdsp
 disable mipsdspr2
 disable msa
 ;;
@@ -4944,13 +4944,13 @@ 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 mipsdspr1 || enabled mipsdspr2); then
+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 mipsdspr1 ||

[FFmpeg-devel] [PATCH 10/13] Put "disable mipsfpu" in a better place for loongson

2015-11-16 Thread Vicente Olivert Riera

Let's disable the ISAs first, and then the core capabilities, as we do
for the rest of the cores. This way the code is better organized.

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

diff --git a/configure b/configure
index 2f5456c..d366eb2 100755
--- a/configure
+++ b/configure
@@ -4127,11 +4127,11 @@ elif enabled mips; then
 add_asflags "-mfp64"
 ;;
 loongson*)
-disable mipsfpu
 disable mips32r2
 disable mips32r6
 disable mips64r2
 disable mips64r6
+disable mipsfpu
 disable mipsdsp
 disable mipsdspr2
 disable msa
-- 
1.7.1

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

[FFmpeg-devel] [PATCH 11/13] Remove the MIPS "generic" core in favor of "*"

2015-11-16 Thread Vicente Olivert Riera

There is no point to have a "generic" core when we can catch all
unsupported cores with the "*" option, so remove it.

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

diff --git a/configure b/configure
index d366eb2..1bfcc67 100755
--- a/configure
+++ b/configure
@@ -4154,10 +4154,6 @@ elif enabled mips; then
 ;;
 esac
 ;;
-generic)
-disable mips64r6
-disable msa
-;;
 *)
 disable mipsfpu
 disable mips32r2
-- 
1.7.1

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

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

2015-11-16 Thread Nicolas George

Le quartidi 24 brumaire, an CCXXIV, Marton Balint a écrit :
> No, this is deliberately -1. This is the case where the duration metadata is
> missing (because it is unkown), but this also means that the outpoint was
> not set in the file segment, therefore we need to select every frame after
> start_time until the segment ends.

Then I do not understand the reason for the -. I suspected you implemented
the same logic than a comparison function: <0 means that pts is before the
selected interval, 0 that pts is inside and >0 that pts is after. Apparently
this is not it.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH 12/13] Improve detection of MIPS ISAs, FPU and ASEs (DSP, MSA)

2015-11-16 Thread Vicente Olivert Riera

Signed-off-by: Vicente Olivert Riera 
---
 configure |   77 ++--
 1 files changed, 59 insertions(+), 18 deletions(-)

diff --git a/configure b/configure
index 1bfcc67..4173684 100755
--- a/configure
+++ b/configure
@@ -4952,27 +4952,68 @@ 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"'
+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" &&
-- 
1.7.1

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

Re: [FFmpeg-devel] [PATCH] avformat/mov: remove redundant assignment

2015-11-16 Thread Ganesh Ajjanagadde

On Mon, Nov 16, 2015 at 6:40 AM, Michael Niedermayer
 wrote:
> On Sun, Nov 15, 2015 at 09:05:18PM -0500, Ganesh Ajjanagadde wrote:
>> This is possibly undefined behavior based on sequence point rules, but I
>> have not studied the spec at that level of detail.
>>
>> Fixes: CID 1338321.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavformat/mov.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> ok
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The educated differ from the uneducated as much as the living from the
> dead. -- Aristotle
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

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

2015-11-16 Thread Ganesh Ajjanagadde

On Mon, Nov 16, 2015 at 7:53 AM, Hendrik Leppkes  wrote:
> On Mon, Nov 16, 2015 at 1:52 PM, Ganesh Ajjanagadde  wrote:
>> On Mon, Nov 16, 2015 at 3:27 AM, wm4  wrote:
>>> On Sun, 15 Nov 2015 17:56:22 -0500
>>> Ganesh Ajjanagadde  wrote:
>>>
 ffio_ensure_seekback can fail due to e.g ENOMEM. This return value is
 propagated here, and all usage in the codebase now has its return value
 checked.

 A potential memory leak in mp3_read_header is also fixed via a goto
 fail.

 Signed-off-by: Ganesh Ajjanagadde 
 ---
  libavformat/mp3dec.c | 12 +---
  libavformat/rmdec.c  |  3 ++-
  2 files changed, 11 insertions(+), 4 deletions(-)

 diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
 index 32ca00c..9fefe2d 100644
 --- a/libavformat/mp3dec.c
 +++ b/libavformat/mp3dec.c
 @@ -373,18 +373,20 @@ static int mp3_read_header(AVFormatContext *s)

  ret = ff_replaygain_export(st, s->metadata);
  if (ret < 0)
 -return ret;
 +goto fail;

  off = avio_tell(s->pb);
  for (i = 0; i < 64 * 1024; i++) {
  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)
 +goto 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)
 +goto fail;
  if (check(s->pb, off + i + frame_size, ) >= 0 &&
  (header & SAME_HEADER_MASK) == (header2 & 
 SAME_HEADER_MASK))
  {
 @@ -402,6 +404,10 @@ static int mp3_read_header(AVFormatContext *s)

  /* the parameters will be extracted from the compressed bitstream */
  return 0;
 +
 +fail:
 +ff_free_stream(s, st);
 +return ret;
  }

  #define MP3_PACKET_SIZE 1024
 diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
 index 4ec78ef..d6e820e 100644
 --- a/libavformat/rmdec.c
 +++ b/libavformat/rmdec.c
 @@ -576,7 +576,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)
 +goto fail;
  v = avio_rb32(pb);
  if (v == MKBETAG('M', 'L', 'T', 'I')) {
  int number_of_streams = avio_rb16(pb);
>>>
>>> NACK. There's no reason to fatally fail in these cases.
>>
>> Ok, will split into two for the memory leak and these return values.
>> For the return values, will simply log at AV_LOG_WARNING.
>>
>
> There is no actual memory leak here, the stream is free'ed when the
> format context is closed.

Thanks for clarifying, indeed it is part of the context via
avformat_new_stream. I was concerned that this was being called
multiple times. Seems like it is all ok, and checked the docs.

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

Re: [FFmpeg-devel] [PATCH] aac_fixed: fix overflow in sbr_sum_square_c

2015-11-16 Thread Nedeljko Babic

>> On 11.11.2015 13:46, Michael Niedermayer wrote:
>> > On Sun, Nov 08, 2015 at 09:26:21PM +0100, Andreas Cadhalpun wrote:
>> >> On 08.11.2015 20:17, Michael Niedermayer wrote:
>> >>> but the patch does not look like an optimal solution
>> >>
>> >> It's certainly not pretty, but it fixes the crashes/assertion failures.
>> > 
>> > at the expense of making the code rather slow and hard to implement in
>> > SIMD.
>> > This would be perfectly ok if that is neccessary but is it ?
>> > (i dont know)
>> 
>> That depends how you define necessary. It's possible to avoid the problem
>> with simpler, faster means, but those are less correct mathematically.
>
>I define neccessary as what is neccessary for a well working fixed
>point aac decoder.
>
>There are 2 possible cases i think
>A. The large input values are invalid then the correct solution is
>   to detect that and error out / do error concealment
>B. The large values are valid, in this case the implementation is
>   broken. And the question would arrise how to best support the valid
>   range, can the values or their products be scaled down by a fixed
>   shift? or does this affect quality, do we need a variable shift
>   if so how to implement this best (like 2pass, find max, choose
>   shift at a earlier stage possibly, some kind of floats, ...)
>
>
>> 
>> > do we know the valid input range?
>> 
>> I don't know about valid, but the possible input range currently seems
>> to be any 32-bit integer.
>
>yes, and neither do i know the valid range but
>SBR builds the high frequency signal and adds that to the base AAC
>low frequency signal. These cannot be arbitrary large as the output
>cannot be arbitrary large so there is a practical limit on how large
>these values can be unless its possible and allowed to have much
>larger intermediates at some point.
>
>
>[...]
>> > or maybe "valid" is not the correct word (in case the spec does not
>> > specify that directly or indirectly ...)
>> > if thats the case then it could be a question if any encoder could
>> > ever have a reason to use values in a specific range
>> 
>> Anyway, the decoder has to deal with such values somehow.
>> It could also error out, but I don't know which error check to use.
>> And it would be a bit strange if the aac_fixed decoder errors out,
>> while the float aac decoder can handle such samples.
>
>can you check if there are any overflows happening in valid aac files
>?
>if none of them overflows anywhere then i would guess the supported
>ranges are not that far off from what is used by actual encoders
>and just erroring out with a request for a sample might be an easy
>solution and much faster than converting all to some float emulation
>
>Comments fro AAC and SBR experts very welcome!

This code was developed a while ago, but based on informations that I have
this part of code was analysed regarding possibility of overflow and conclusion
was that there is no valid way for causing overflow here.

And regarding valid range, if I remember correctly it should be 29, not 32.

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

[FFmpeg-devel] [PATCH 02/13] Remove --mips32r5 configure option

2015-11-16 Thread Vicente Olivert Riera

Having a configure option with the same name as a MIPS ISA is confusing,
so better to remove it. This option was being used to add some
optimizations to a specific core (p5600). We will add the optimizations
just when the p5600 core has been detected, in a later patch.

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

diff --git a/configure b/configure
index 0461a97..3fd156e 100755
--- a/configure
+++ b/configure
@@ -378,7 +378,6 @@ Optimization options (experts only):
   --disable-neon   disable NEON optimizations
   --disable-inline-asm disable use of inline assembly
   --disable-yasm   disable use of nasm/yasm assembly
-  --disable-mips32r5   disable MIPS32R5 optimizations
   --disable-mips64r6   disable MIPS64R6 optimizations
   --disable-mipsdspdisable MIPS DSP ASE R1 optimizations
   --disable-mipsdspr2  disable MIPS DSP ASE R2 optimizations
@@ -1625,7 +1624,6 @@ ARCH_EXT_LIST_ARM="
 ARCH_EXT_LIST_MIPS="
 mipsfpu
 mips32r2
-mips32r5
 mips64r6
 mipsdsp
 mipsdspr2
@@ -2105,7 +2103,6 @@ mipsfpu_deps="mips"
 mipsdsp_deps="mips"
 mipsdspr2_deps="mips"
 mips32r2_deps="mips"
-mips32r5_deps="mips"
 mips64r6_deps="mips"
 msa_deps="mips"
 mmi_deps="mips"
@@ -4061,7 +4058,6 @@ elif enabled mips; then
 
 case $cpu in
 24kc)
-disable mips32r5
 disable mips64r6
 disable mipsfpu
 disable mipsdsp
@@ -4069,33 +4065,28 @@ elif enabled mips; then
 disable msa
 ;;
 24kf*)
-disable mips32r5
 disable mips64r6
 disable mipsdsp
 disable mipsdspr2
 disable msa
 ;;
 24kec|34kc|1004kc)
-disable mips32r5
 disable mips64r6
 disable mipsfpu
 disable mipsdspr2
 disable msa
 ;;
 24kef*|34kf*|1004kf*)
-disable mips32r5
 disable mips64r6
 disable mipsdspr2
 disable msa
 ;;
 74kc)
-disable mips32r5
 disable mips64r6
 disable mipsfpu
 disable msa
 ;;
 74kf)
-disable mips32r5
 disable mips64r6
 disable msa
 ;;
@@ -4107,7 +4098,6 @@ elif enabled mips; then
 check_cflags "-mtune=p5600"
 ;;
 i6400)
-disable mips32r5
 disable mipsdsp
 disable mipsdspr2
 disable mipsfpu
@@ -4118,7 +4108,6 @@ elif enabled mips; then
 loongson*)
 disable mipsfpu
 disable mips32r2
-disable mips32r5
 disable mips64r6
 disable mipsdsp
 disable mipsdspr2
@@ -4143,14 +4132,12 @@ elif enabled mips; then
 esac
 ;;
 generic)
-disable mips32r5
 disable mips64r6
 disable msa
 ;;
 *)
 disable mipsfpu
 disable mips32r2
-disable mips32r5
 disable mips64r6
 disable mipsdsp
 disable mipsdspr2
@@ -4953,14 +4940,11 @@ elif enabled mips; then
 elif enabled mipsdsp || enabled mipsdspr2; then
 add_cflags "-mips32r2 -mfp32"
 add_asflags "-mips32r2 -mfp32"
-elif enabled mips32r5 || enabled mips64r6; then
+elif enabled mips64r6; then
 check_cflags "-mfp64"
 check_ldflags "-mfp64"
 fi
 
-enabled mips32r5  && check_cflags "-mips32r5 -msched-weight 
-mload-store-pairs -funroll-loops" &&
- check_ldflags "-mips32r5" &&
- check_inline_asm mips32r5  '"ulw $t0, ($t1)"'
 enabled mips64r6  && check_cflags "-mips64r6 -msched-weight 
-mload-store-pairs -funroll-loops" &&
  check_ldflags "-mips64r6" &&
  check_inline_asm mips64r6  '"aui $t0, $t1, 1"'
@@ -4973,7 +4957,6 @@ elif enabled mips; then
 enabled msa   && check_cflags "-mmsa" && check_ldflags "-mmsa" &&
  check_inline_asm msa   '"addvi.b $w0, $w1, 1"'
 
-enabled mips32r5 && add_asflags "-mips32r5 -mfp64"
 enabled mips64r6 && add_asflags "-mips64r6 -mfp64"
 enabled msa && add_asflags "-mmsa"
 
@@ -6050,7 +6033,6 @@ if enabled arm; then
 fi
 if enabled mips; then
 echo "MIPS FPU enabled  ${mipsfpu-no}"
-echo "MIPS32R5 enabled  ${mips32r5-no}"
 echo "MIPS64R6 enabled  ${mips64r6-no}"
 echo "MIPS DSP R1 enabled   ${mipsdsp-no}"
 echo "MIPS DSP R2 enabled   ${mipsdspr2-no}"
-- 
1.7.1

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

[FFmpeg-devel] [PATCH 03/13] Add MIPS p5600 core optimizations

2015-11-16 Thread Vicente Olivert Riera

Signed-off-by: Vicente Olivert Riera 
---
 configure |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 3fd156e..fa5207c 100755
--- a/configure
+++ b/configure
@@ -4094,8 +4094,9 @@ elif enabled mips; then
 disable mips64r6
 disable mipsdsp
 disable mipsdspr2
-
-check_cflags "-mtune=p5600"
+check_cflags "-mtune=p5600" &&
+check_cflags "-mfp64 -msched-weight -mload-store-pairs 
-funroll-loops" &&
+add_asflags "-mfp64"
 ;;
 i6400)
 disable mipsdsp
-- 
1.7.1

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

[FFmpeg-devel] [PATCH] fate: fix concat demuxer extended test portability

2015-11-16 Thread Marton Balint

Sed \r is not portable, it does not work on freebsd, hopefully awk will.

Signed-off-by: Marton Balint 
---
 tests/fate-run.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 966cbe2..a23f1e3 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -262,7 +262,7 @@ concat(){
 awk "{gsub(/%SRCFILE%/, \"$sample\"); print}" $template > $concatfile
 
 if [ "$mode" = "md5" ]; then
-  run ffprobe${PROGSUF} -show_streams -show_packets -v 0 -fflags keepside 
-safe 0 $extra_args $concatfile | sed 's/\r//g' > $packetfile
+  run ffprobe${PROGSUF} -show_streams -show_packets -v 0 -fflags keepside 
-safe 0 $extra_args $concatfile | awk '{gsub(/\r$/,""); print;}' > $packetfile
   do_md5sum $packetfile
 else
   run ffprobe${PROGSUF} -show_streams -show_packets -v 0 -of 
compact=p=0:nk=1 -fflags keepside -safe 0 $extra_args $concatfile
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] avformat/mov: fix memory leak

2015-11-16 Thread Ganesh Ajjanagadde

On Mon, Nov 16, 2015 at 5:27 AM, Paul B Mahol  wrote:
> On 11/16/15, Ganesh Ajjanagadde  wrote:
>> Fixes: CID 1338328.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavformat/mov.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index 38d3659..7ab2808 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -430,6 +430,7 @@ retry:
>>  if (snprintf(str, str_size_alloc, "%f", val) >= str_size_alloc)
>> {
>>  av_log(c->fc, AV_LOG_ERROR,
>> "Failed to store the float32 number (%f) in
>> string.\n", val);
>> +av_free(str);
>>  return AVERROR_INVALIDDATA;
>>  }
>>  } else {
>> --
>> 2.6.2
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> lgtm

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

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

2015-11-16 Thread Daniel Serpell

Hi!,

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

They where correctly rounded to 24bit precision. I don't know if that
was intentional, so I can't comment on the correctness of the patch.

Daniel.

> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/ppc/fdctdsp.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/libavcodec/ppc/fdctdsp.c b/libavcodec/ppc/fdctdsp.c
> index 924d12c..92866d3 100644
> --- a/libavcodec/ppc/fdctdsp.c
> +++ b/libavcodec/ppc/fdctdsp.c
> @@ -37,13 +37,13 @@
>  #define vu16(v) ((vector unsigned short) (v))
>  #define vu32(v)   ((vector unsigned int) (v))
>  
> -#define C1 0.98078525066375732421875000 /* cos(1 * PI / 16) */
> -#define C2 0.92387950420379638671875000 /* cos(2 * PI / 16) */
> -#define C3 0.83146959543228149414062500 /* cos(3 * PI / 16) */
> -#define C4 0.70710676908493041992187500 /* cos(4 * PI / 16) */
> -#define C5 0.7024478912353515625000 /* cos(5 * PI / 16) */
> -#define C6 0.38268342614173889160156250 /* cos(6 * PI / 16) */
> -#define C7 0.19509032368659973144531250 /* cos(7 * PI / 16) */
> +#define C1 0.98078528040323044912618224 /* cos(1 * PI / 16) */
> +#define C2 0.92387953251128675612818319 /* cos(2 * PI / 16) */
> +#define C3 0.83146961230254523707878838 /* cos(3 * PI / 16) */
> +#define C4 M_SQRT1_2/* cos(4 * PI / 16) */
> +#define C5 0.7023301960222474283081 /* cos(5 * PI / 16) */
> +#define C6 0.38268343236508977172845998 /* cos(6 * PI / 16) */
> +#define C7 0.19509032201612826784828487 /* cos(7 * PI / 16) */
>  
>  #define W0 -(2 * C2)
>  #define W1  (2 * C6)
> -- 
> 2.6.2
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 09/13] Add mips32r6 architecture variant

2015-11-16 Thread Vicente Olivert Riera

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

diff --git a/configure b/configure
index 50db22b..2f5456c 100755
--- a/configure
+++ b/configure
@@ -1624,6 +1624,7 @@ ARCH_EXT_LIST_MIPS="
 mipsfpu
 mips32r2
 mips64r2
+mips32r6
 mips64r6
 mipsdsp
 mipsdspr2
@@ -2103,6 +2104,7 @@ mipsfpu_deps="mips"
 mipsdsp_deps="mips"
 mipsdspr2_deps="mips"
 mips32r2_deps="mips"
+mips32r6_deps="mips"
 mips64r2_deps="mips"
 mips64r6_deps="mips"
 msa_deps="mips"
@@ -4059,6 +4061,7 @@ elif enabled mips; then
 
 case $cpu in
 24kc)
+disable mips32r6
 disable mips64r2
 disable mips64r6
 disable mipsfpu
@@ -4067,6 +4070,7 @@ elif enabled mips; then
 disable msa
 ;;
 24kf*)
+disable mips32r6
 disable mips64r2
 disable mips64r6
 disable mipsdsp
@@ -4074,6 +4078,7 @@ elif enabled mips; then
 disable msa
 ;;
 24kec|34kc|1004kc)
+disable mips32r6
 disable mips64r2
 disable mips64r6
 disable mipsfpu
@@ -4081,23 +4086,27 @@ elif enabled mips; then
 disable msa
 ;;
 24kef*|34kf*|1004kf*)
+disable mips32r6
 disable mips64r2
 disable mips64r6
 disable mipsdspr2
 disable msa
 ;;
 74kc)
+disable mips32r6
 disable mips64r2
 disable mips64r6
 disable mipsfpu
 disable msa
 ;;
 74kf)
+disable mips32r6
 disable mips64r2
 disable mips64r6
 disable msa
 ;;
 p5600)
+disable mips32r6
 disable mips64r2
 disable mips64r6
 disable mipsdsp
@@ -4108,6 +4117,7 @@ elif enabled mips; then
 ;;
 i6400)
 disable mips32r2
+disable mips32r6
 disable mips64r2
 disable mipsdsp
 disable mipsdspr2
@@ -4119,6 +4129,7 @@ elif enabled mips; then
 loongson*)
 disable mipsfpu
 disable mips32r2
+disable mips32r6
 disable mips64r2
 disable mips64r6
 disable mipsdsp
@@ -4150,6 +4161,7 @@ elif enabled mips; then
 *)
 disable mipsfpu
 disable mips32r2
+disable mips32r6
 disable mips64r2
 disable mips64r6
 disable mipsdsp
-- 
1.7.1

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

[FFmpeg-devel] [PATCH 08/13] Add mips64r2 architecture variant

2015-11-16 Thread Vicente Olivert Riera

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

diff --git a/configure b/configure
index 3530327..50db22b 100755
--- a/configure
+++ b/configure
@@ -1623,6 +1623,7 @@ ARCH_EXT_LIST_ARM="
 ARCH_EXT_LIST_MIPS="
 mipsfpu
 mips32r2
+mips64r2
 mips64r6
 mipsdsp
 mipsdspr2
@@ -2102,6 +2103,7 @@ mipsfpu_deps="mips"
 mipsdsp_deps="mips"
 mipsdspr2_deps="mips"
 mips32r2_deps="mips"
+mips64r2_deps="mips"
 mips64r6_deps="mips"
 msa_deps="mips"
 mmi_deps="mips"
@@ -4057,6 +4059,7 @@ elif enabled mips; then
 
 case $cpu in
 24kc)
+disable mips64r2
 disable mips64r6
 disable mipsfpu
 disable mipsdsp
@@ -4064,32 +4067,38 @@ elif enabled mips; then
 disable msa
 ;;
 24kf*)
+disable mips64r2
 disable mips64r6
 disable mipsdsp
 disable mipsdspr2
 disable msa
 ;;
 24kec|34kc|1004kc)
+disable mips64r2
 disable mips64r6
 disable mipsfpu
 disable mipsdspr2
 disable msa
 ;;
 24kef*|34kf*|1004kf*)
+disable mips64r2
 disable mips64r6
 disable mipsdspr2
 disable msa
 ;;
 74kc)
+disable mips64r2
 disable mips64r6
 disable mipsfpu
 disable msa
 ;;
 74kf)
+disable mips64r2
 disable mips64r6
 disable msa
 ;;
 p5600)
+disable mips64r2
 disable mips64r6
 disable mipsdsp
 disable mipsdspr2
@@ -4099,6 +4108,7 @@ elif enabled mips; then
 ;;
 i6400)
 disable mips32r2
+disable mips64r2
 disable mipsdsp
 disable mipsdspr2
 check_cflags "-mtune=i6400 -mabi=64" &&
@@ -4109,6 +4119,7 @@ elif enabled mips; then
 loongson*)
 disable mipsfpu
 disable mips32r2
+disable mips64r2
 disable mips64r6
 disable mipsdsp
 disable mipsdspr2
@@ -4139,6 +4150,7 @@ elif enabled mips; then
 *)
 disable mipsfpu
 disable mips32r2
+disable mips64r2
 disable mips64r6
 disable mipsdsp
 disable mipsdspr2
-- 
1.7.1

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

[FFmpeg-devel] [PATCH 07/13] MIPS i6400 core is not mips32r2, so disable mips32r2

2015-11-16 Thread Vicente Olivert Riera

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

diff --git a/configure b/configure
index ff5e132..3530327 100755
--- a/configure
+++ b/configure
@@ -4098,6 +4098,7 @@ elif enabled mips; then
 add_asflags "-mfp64"
 ;;
 i6400)
+disable mips32r2
 disable mipsdsp
 disable mipsdspr2
 check_cflags "-mtune=i6400 -mabi=64" &&
-- 
1.7.1

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

Re: [FFmpeg-devel] [PATCH] fate: fix concat demuxer extended test portability

2015-11-16 Thread Marton Balint



On Mon, 16 Nov 2015, Timothy Gu wrote:


tr -d '\r' ?


Yep, good idea.

Applied with tr -d.

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

Re: [FFmpeg-devel] [PATCH 2/4] lavf/utils: avoid decoding a frame to get the codec parameters

2015-11-16 Thread Michael Niedermayer

On Mon, Nov 16, 2015 at 11:16:42AM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Mon, Nov 16, 2015 at 11:06 AM, Matthieu Bouron  > wrote:
> 
> > On Sun, Nov 15, 2015 at 08:12:57AM -0500, Ronald S. Bultje wrote:
> > > Hi,
> >
> > Hi,
> >
> > >
> > > On Sun, Nov 15, 2015 at 4:49 AM, Matthieu Bouron <
> > matthieu.bou...@gmail.com>
> > > wrote:
> > >
> > > > On Mon, Nov 02, 2015 at 07:56:50AM -0500, Ronald S. Bultje wrote:
> > > > > Hi,
> > > > >
> > > > > On Mon, Nov 2, 2015 at 5:45 AM, Matthieu Bouron <
> > > > matthieu.bou...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > From: Matthieu Bouron 
> > > > > >
> > > > > > Avoid decoding a frame to get the codec parameters while the codec
> > > > > > supports FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM. This is particulary
> > useful
> > > > > > to avoid decoding twice images (once in avformat_find_stream_info
> > and
> > > > > > once when the actual decode is made).
> > > > > > ---
> > > > > >  libavformat/utils.c | 12 
> > > > > >  1 file changed, 12 insertions(+)
> > > > > >
> > > > > > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > > > > > index 5c4d452..ba62f2b 100644
> > > > > > --- a/libavformat/utils.c
> > > > > > +++ b/libavformat/utils.c
> > > > > > @@ -2695,6 +2695,8 @@ static int try_decode_frame(AVFormatContext
> > *s,
> > > > > > AVStream *st, AVPacket *avpkt,
> > > > > >  AVFrame *frame = av_frame_alloc();
> > > > > >  AVSubtitle subtitle;
> > > > > >  AVPacket pkt = *avpkt;
> > > > > > +int do_skip_frame = 0;
> > > > > > +enum AVDiscard skip_frame;
> > > > > >
> > > > > >  if (!frame)
> > > > > >  return AVERROR(ENOMEM);
> > > > > > @@ -2733,6 +2735,12 @@ static int try_decode_frame(AVFormatContext
> > *s,
> > > > > > AVStream *st, AVPacket *avpkt,
> > > > > >  goto fail;
> > > > > >  }
> > > > > >
> > > > > > +if (st->codec->codec->caps_internal &
> > > > > > FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM) {
> > > > > > +do_skip_frame = 1;
> > > > > > +skip_frame = st->codec->skip_frame;
> > > > > > +st->codec->skip_frame = AVDISCARD_ALL;
> > > > > > +}
> > > > > > +
> > > > > >  while ((pkt.size > 0 || (!pkt.data && got_picture)) &&
> > > > > > ret >= 0 &&
> > > > > > (!has_codec_parameters(st, NULL) ||
> > > > > > !has_decode_delay_been_guessed(st) ||
> > > > > > @@ -2768,6 +2776,10 @@ static int try_decode_frame(AVFormatContext
> > *s,
> > > > > > AVStream *st, AVPacket *avpkt,
> > > > > >  ret = -1;
> > > > > >
> > > > > >  fail:
> > > > > > +if (do_skip_frame) {
> > > > > > +st->codec->skip_frame = skip_frame;
> > > > > > +}
> > > > > > +
> > > > > >  av_frame_free();
> > > > > >  return ret;
> > > > > >  }
> > > > > > --
> > > > > > 2.6.2
> > > > >
> > > > >
> > > > > I think we need an assert in the try_decode loop to ensure that it
> > indeed
> > > > > did fill all the params. This is to prevent the case where someone
> > adds a
> > > > > new "thing" to the list of things required for find_stream_info to
> > > > succeed,
> > > > > and forgets to update the codecs.
> > > >
> > > > While the codec_has_parameters function fits that role, it does not
> > check
> > > > all codec parameters as they can be codec dependant.
> > > >
> > > > I'm not sure if we can create a generic rule here for the same reason
> > as
> > > > above, as the parameters set can be codec specific and maybe stream
> > > > specific.
> > > >
> > > > Having some fate test to cover this area seems to be another option but
> > > > would
> > > > require to inspect all the relevant parameters of AVCodecContext
> > depending
> > > > on the codec and a lot of different streams.
> > >
> > >
> > > I don't care about _which_ parameters were filled. The goal of this
> > option
> > > is only directly to fill parameters, but the purpose goes far beyond
> > that.
> > > The indirect goal of this change is to _not_ call try_decode_frame() for
> > > certain image codecs. Whether they do that by dancing on the table or by
> > > filling AVCodecContext parameters when a special flag is set, is merely
> > an
> > > implementation detail.
> > >
> > > I want the test to confirm that we did not call try_decode_frame() when
> > the
> > > skip-flag was set. It seems easiest to me that we check that by adding a
> > > one-line assert, for example inside try_decode_frame, that checks that
> > the
> > > flag does not apply to this codec, right? If the assert triggers, clearly
> > > something broke, and either the flag should be removed, or the check
> > before
> > > starting try_decode_frame fixed.
> >
> > The try_decode_frame function still need to be executed even if the
> > decoder supports FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM as it still
> > need to parse the first frame to set the relevant parameters.
> >
> > The flag only says that the decoder still do the actual parsing even if
> > the frame is

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

2015-11-16 Thread Ganesh Ajjanagadde

On Mon, Nov 16, 2015 at 9:48 AM, Daniel Serpell  wrote:
> Hi!,
>
> El Fri, Nov 13, 2015 at 11:42:30AM -0500, Ganesh Ajjanagadde escribio:
>> Whoever wrote this stuff had a pretty bad libm - digits differ pretty
>> quickly.
>
> They where correctly rounded to 24bit precision. I don't know if that
> was intentional, so I can't comment on the correctness of the patch.

Unless I am off here, doing things at 24 bits makes very little sense:
float itself offers 32 bits, and only place where Ci's get used is in
computing a float array statically so there can be no speed loss.
Thus, currently, useless loss of precision happens. This is very
similar to a recent commit I did with Michael on avcodec/faandct:
064ced5dc147c9b5a33807a90f07037feec57cbe.

In fact, in light of that, I may even want to change to long double
floating literals.
One may think that is excessive, but it has an additional advantage:
suppose someone wishes to move to double precision. Then the #defines
don't need to change, only the type signatures of the static float
array and other such things in the file. Using L is a best effort
solution that helps with future work (if any). Of course, one could
let the array have the literals directly instead of computed from the
cosines, but that results in significant loss of readability and is
likely unnecessary work.

>
> Daniel.
>
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavcodec/ppc/fdctdsp.c | 14 +++---
>>  1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/libavcodec/ppc/fdctdsp.c b/libavcodec/ppc/fdctdsp.c
>> index 924d12c..92866d3 100644
>> --- a/libavcodec/ppc/fdctdsp.c
>> +++ b/libavcodec/ppc/fdctdsp.c
>> @@ -37,13 +37,13 @@
>>  #define vu16(v) ((vector unsigned short) (v))
>>  #define vu32(v)   ((vector unsigned int) (v))
>>
>> -#define C1 0.98078525066375732421875000 /* cos(1 * PI / 16) */
>> -#define C2 0.92387950420379638671875000 /* cos(2 * PI / 16) */
>> -#define C3 0.83146959543228149414062500 /* cos(3 * PI / 16) */
>> -#define C4 0.70710676908493041992187500 /* cos(4 * PI / 16) */
>> -#define C5 0.7024478912353515625000 /* cos(5 * PI / 16) */
>> -#define C6 0.38268342614173889160156250 /* cos(6 * PI / 16) */
>> -#define C7 0.19509032368659973144531250 /* cos(7 * PI / 16) */
>> +#define C1 0.98078528040323044912618224 /* cos(1 * PI / 16) */
>> +#define C2 0.92387953251128675612818319 /* cos(2 * PI / 16) */
>> +#define C3 0.83146961230254523707878838 /* cos(3 * PI / 16) */
>> +#define C4 M_SQRT1_2/* cos(4 * PI / 16) */
>> +#define C5 0.7023301960222474283081 /* cos(5 * PI / 16) */
>> +#define C6 0.38268343236508977172845998 /* cos(6 * PI / 16) */
>> +#define C7 0.19509032201612826784828487 /* cos(7 * PI / 16) */
>>
>>  #define W0 -(2 * C2)
>>  #define W1  (2 * C6)
>> --
>> 2.6.2
>>
> ___
> 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 5/5] lavfi/select: add support for concatdec_select option

2015-11-16 Thread Marton Balint



On Mon, 16 Nov 2015, Nicolas George wrote:


Le quartidi 24 brumaire, an CCXXIV, Marton Balint a écrit :

No, this is deliberately -1. This is the case where the duration metadata is
missing (because it is unkown), but this also means that the outpoint was
not set in the file segment, therefore we need to select every frame after
start_time until the segment ends.


Then I do not understand the reason for the -. I suspected you implemented
the same logic than a comparison function: <0 means that pts is before the
selected interval, 0 that pts is inside and >0 that pts is after. Apparently
this is not it.


No, the reason behind the return value is based on how the select filter 
works which is:

- negative or NaN - frame is sent to the first output
- zero - frame is discarded
- positive - frame is sent to the output with index ceil(val)-1

Therefore the user can simply write -vf select=concatdec_select and such, 
and in this case, as Stefano summerized it an input frame is selected if 
its pts is within the interval set by the concat demuxer. (or if the 
concat metadata is missing, but this just means that you can use this 
filter for non-concatdec input as well, and it will do nothing).


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

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

2015-11-16 Thread Hendrik Leppkes

On Mon, Nov 16, 2015 at 6:24 PM, Ganesh Ajjanagadde  wrote:
> On Mon, Nov 16, 2015 at 9:48 AM, Daniel Serpell  wrote:
>> Hi!,
>>
>> El Fri, Nov 13, 2015 at 11:42:30AM -0500, Ganesh Ajjanagadde escribio:
>>> Whoever wrote this stuff had a pretty bad libm - digits differ pretty
>>> quickly.
>>
>> They where correctly rounded to 24bit precision. I don't know if that
>> was intentional, so I can't comment on the correctness of the patch.
>
> Unless I am off here, doing things at 24 bits makes very little sense:
> float itself offers 32 bits

Actually floats offer 23-bits of precision for the significand (with 8
for mantissa and one sign bit) - 7-8 digits, so any more precision
than that couldn't be stored accurately anymore, so when using single
precision like this code, more precision is not needed.
Maybe it was even specifically wanted to have values that are
represented accurately, but I do not know the history of this code
either.

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

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

2015-11-16 Thread Ganesh Ajjanagadde

On Mon, Nov 16, 2015 at 1:20 PM, Hendrik Leppkes  wrote:
> On Mon, Nov 16, 2015 at 6:24 PM, Ganesh Ajjanagadde  wrote:
>> On Mon, Nov 16, 2015 at 9:48 AM, Daniel Serpell  wrote:
>>> Hi!,
>>>
>>> El Fri, Nov 13, 2015 at 11:42:30AM -0500, Ganesh Ajjanagadde escribio:
 Whoever wrote this stuff had a pretty bad libm - digits differ pretty
 quickly.
>>>
>>> They where correctly rounded to 24bit precision. I don't know if that
>>> was intentional, so I can't comment on the correctness of the patch.
>>
>> Unless I am off here, doing things at 24 bits makes very little sense:
>> float itself offers 32 bits
>
> Actually floats offer 23-bits of precision for the significand (with 8
> for mantissa and one sign bit) - 7-8 digits, so any more precision
> than that couldn't be stored accurately anymore, so when using single
> precision like this code, more precision is not needed.

Point taken. However, the general remark still applies: precision is
being lost unnecessarily at an intermediate computation stage since it
is anyway a static computation.

> Maybe it was even specifically wanted to have values that are
> represented accurately, but I do not know the history of this code
> either.
>
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat: add IVR demuxer

2015-11-16 Thread Michael Niedermayer

On Mon, Nov 16, 2015 at 11:25:33AM +0100, Paul B Mahol wrote:
> 2n version attached

>  Makefile |1 
>  allformats.c |1 
>  rmdec.c  |  303 
> ---
>  3 files changed, 271 insertions(+), 34 deletions(-)
> f8930413dadf24053ff1e19ebbacf90ae801f7d0  0001-avformat-add-IVR-demuxer.patch
> From bada349bdba599b92bcb1d3bc16b630c182174f9 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol 
> Date: Wed, 11 Nov 2015 22:04:57 +0100
> Subject: [PATCH] avformat: add IVR demuxer
> 
> Signed-off-by: Paul B Mahol 
> ---
> 
> Problem with slices/frames ending in middle of packet is still there.
> 
> Reproducible with Opener_rm_hi.ivr
> 
> ---
>  libavformat/Makefile |   1 +
>  libavformat/allformats.c |   1 +
>  libavformat/rmdec.c  | 303 
> +--
>  3 files changed, 271 insertions(+), 34 deletions(-)
> 
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index bdfe35c..e3f19dd 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -228,6 +228,7 @@ OBJS-$(CONFIG_ISS_DEMUXER)   += iss.o
>  OBJS-$(CONFIG_IV8_DEMUXER)   += iv8.o
>  OBJS-$(CONFIG_IVF_DEMUXER)   += ivfdec.o
>  OBJS-$(CONFIG_IVF_MUXER) += ivfenc.o
> +OBJS-$(CONFIG_IVR_DEMUXER)   += rmdec.o rm.o rmsipr.o
>  OBJS-$(CONFIG_JACOSUB_DEMUXER)   += jacosubdec.o subtitles.o
>  OBJS-$(CONFIG_JACOSUB_MUXER) += jacosubenc.o rawenc.o
>  OBJS-$(CONFIG_JV_DEMUXER)+= jvdec.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 73b1e4a..9ac40c5 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -169,6 +169,7 @@ void av_register_all(void)
>  REGISTER_DEMUXER (ISS,  iss);
>  REGISTER_DEMUXER (IV8,  iv8);
>  REGISTER_MUXDEMUX(IVF,  ivf);
> +REGISTER_DEMUXER (IVR,  ivr);
>  REGISTER_MUXDEMUX(JACOSUB,  jacosub);
>  REGISTER_DEMUXER (JV,   jv);
>  REGISTER_MUXER   (LATM, latm);
> diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
> index 4ec78ef..21e8ec5 100644
> --- a/libavformat/rmdec.c
> +++ b/libavformat/rmdec.c
> @@ -63,6 +63,7 @@ typedef struct RMDemuxContext {
>  int remaining_len;
>  int audio_stream_num; ///< Stream number for audio packets
>  int audio_pkt_cnt; ///< Output packet counter
> +int data_end;
>  } RMDemuxContext;
>  
>  static int rm_read_close(AVFormatContext *s);
> @@ -488,6 +489,47 @@ static int rm_read_header_old(AVFormatContext *s)
>  return rm_read_audio_stream_info(s, s->pb, st, st->priv_data, 1);
>  }
>  
> +static int rm_read_multi(AVFormatContext *s, AVIOContext *pb,
> + AVStream *st, char *mime)
> +{
> +int number_of_streams = avio_rb16(pb);
> +int number_of_mdpr;
> +int i, ret;
> +unsigned size2;
> +for (i = 0; i +avio_rb16(pb);
> +number_of_mdpr = avio_rb16(pb);
> +if (number_of_mdpr != 1) {
> +avpriv_request_sample(s, "MLTI with multiple (%d) MDPR", 
> number_of_mdpr);
> +}
> +for (i = 0; i < number_of_mdpr; i++) {
> +AVStream *st2;
> +if (i > 0) {
> +st2 = avformat_new_stream(s, NULL);
> +if (!st2) {
> +ret = AVERROR(ENOMEM);
> +return ret;
> +}
> +st2->id = st->id + (i<<16);
> +st2->codec->bit_rate = st->codec->bit_rate;
> +st2->start_time = st->start_time;
> +st2->duration   = st->duration;
> +st2->codec->codec_type = AVMEDIA_TYPE_DATA;
> +st2->priv_data = ff_rm_alloc_rmstream();
> +if (!st2->priv_data)
> +return AVERROR(ENOMEM);
> +} else
> +st2 = st;
> +
> +size2 = avio_rb32(pb);
> +ret = ff_rm_read_mdpr_codecdata(s, s->pb, st2, st2->priv_data,
> +size2, mime);
> +if (ret < 0)
> +return ret;
> +}
> +return 0;
> +}
> +
>  static int rm_read_header(AVFormatContext *s)
>  {
>  RMDemuxContext *rm = s->priv_data;
> @@ -579,40 +621,9 @@ static int rm_read_header(AVFormatContext *s)
>  ffio_ensure_seekback(pb, 4);
>  v = avio_rb32(pb);
>  if (v == MKBETAG('M', 'L', 'T', 'I')) {
> -int number_of_streams = avio_rb16(pb);
> -int number_of_mdpr;
> -int i;
> -unsigned size2;
> -for (i = 0; i -avio_rb16(pb);
> -number_of_mdpr = avio_rb16(pb);
> -if (number_of_mdpr != 1) {
> -avpriv_request_sample(s, "MLTI with multiple (%d) MDPR", 
> number_of_mdpr);
> -}
> -for (i = 0; i <

Re: [FFmpeg-devel] [PATCH] avformat: add IVR demuxer

2015-11-16 Thread Paul B Mahol

On 11/16/15, Michael Niedermayer  wrote:
> On Mon, Nov 16, 2015 at 11:25:33AM +0100, Paul B Mahol wrote:
>> 2n version attached
>
>>  Makefile |1
>>  allformats.c |1
>>  rmdec.c  |  303
>> ---
>>  3 files changed, 271 insertions(+), 34 deletions(-)
>> f8930413dadf24053ff1e19ebbacf90ae801f7d0
>> 0001-avformat-add-IVR-demuxer.patch
>> From bada349bdba599b92bcb1d3bc16b630c182174f9 Mon Sep 17 00:00:00 2001
>> From: Paul B Mahol 
>> Date: Wed, 11 Nov 2015 22:04:57 +0100
>> Subject: [PATCH] avformat: add IVR demuxer
>>
>> Signed-off-by: Paul B Mahol 
>> ---
>>
>> Problem with slices/frames ending in middle of packet is still there.
>>
>> Reproducible with Opener_rm_hi.ivr
>>
>> ---
>>  libavformat/Makefile |   1 +
>>  libavformat/allformats.c |   1 +
>>  libavformat/rmdec.c  | 303
>> +--
>>  3 files changed, 271 insertions(+), 34 deletions(-)
>>
>> diff --git a/libavformat/Makefile b/libavformat/Makefile
>> index bdfe35c..e3f19dd 100644
>> --- a/libavformat/Makefile
>> +++ b/libavformat/Makefile
>> @@ -228,6 +228,7 @@ OBJS-$(CONFIG_ISS_DEMUXER)   += iss.o
>>  OBJS-$(CONFIG_IV8_DEMUXER)   += iv8.o
>>  OBJS-$(CONFIG_IVF_DEMUXER)   += ivfdec.o
>>  OBJS-$(CONFIG_IVF_MUXER) += ivfenc.o
>> +OBJS-$(CONFIG_IVR_DEMUXER)   += rmdec.o rm.o rmsipr.o
>>  OBJS-$(CONFIG_JACOSUB_DEMUXER)   += jacosubdec.o subtitles.o
>>  OBJS-$(CONFIG_JACOSUB_MUXER) += jacosubenc.o rawenc.o
>>  OBJS-$(CONFIG_JV_DEMUXER)+= jvdec.o
>> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
>> index 73b1e4a..9ac40c5 100644
>> --- a/libavformat/allformats.c
>> +++ b/libavformat/allformats.c
>> @@ -169,6 +169,7 @@ void av_register_all(void)
>>  REGISTER_DEMUXER (ISS,  iss);
>>  REGISTER_DEMUXER (IV8,  iv8);
>>  REGISTER_MUXDEMUX(IVF,  ivf);
>> +REGISTER_DEMUXER (IVR,  ivr);
>>  REGISTER_MUXDEMUX(JACOSUB,  jacosub);
>>  REGISTER_DEMUXER (JV,   jv);
>>  REGISTER_MUXER   (LATM, latm);
>> diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
>> index 4ec78ef..21e8ec5 100644
>> --- a/libavformat/rmdec.c
>> +++ b/libavformat/rmdec.c
>> @@ -63,6 +63,7 @@ typedef struct RMDemuxContext {
>>  int remaining_len;
>>  int audio_stream_num; ///< Stream number for audio packets
>>  int audio_pkt_cnt; ///< Output packet counter
>> +int data_end;
>>  } RMDemuxContext;
>>
>>  static int rm_read_close(AVFormatContext *s);
>> @@ -488,6 +489,47 @@ static int rm_read_header_old(AVFormatContext *s)
>>  return rm_read_audio_stream_info(s, s->pb, st, st->priv_data, 1);
>>  }
>>
>> +static int rm_read_multi(AVFormatContext *s, AVIOContext *pb,
>> + AVStream *st, char *mime)
>> +{
>> +int number_of_streams = avio_rb16(pb);
>> +int number_of_mdpr;
>> +int i, ret;
>> +unsigned size2;
>> +for (i = 0; i> +avio_rb16(pb);
>> +number_of_mdpr = avio_rb16(pb);
>> +if (number_of_mdpr != 1) {
>> +avpriv_request_sample(s, "MLTI with multiple (%d) MDPR",
>> number_of_mdpr);
>> +}
>> +for (i = 0; i < number_of_mdpr; i++) {
>> +AVStream *st2;
>> +if (i > 0) {
>> +st2 = avformat_new_stream(s, NULL);
>> +if (!st2) {
>> +ret = AVERROR(ENOMEM);
>> +return ret;
>> +}
>> +st2->id = st->id + (i<<16);
>> +st2->codec->bit_rate = st->codec->bit_rate;
>> +st2->start_time = st->start_time;
>> +st2->duration   = st->duration;
>> +st2->codec->codec_type = AVMEDIA_TYPE_DATA;
>> +st2->priv_data = ff_rm_alloc_rmstream();
>> +if (!st2->priv_data)
>> +return AVERROR(ENOMEM);
>> +} else
>> +st2 = st;
>> +
>> +size2 = avio_rb32(pb);
>> +ret = ff_rm_read_mdpr_codecdata(s, s->pb, st2, st2->priv_data,
>> +size2, mime);
>> +if (ret < 0)
>> +return ret;
>> +}
>> +return 0;
>> +}
>> +
>>  static int rm_read_header(AVFormatContext *s)
>>  {
>>  RMDemuxContext *rm = s->priv_data;
>> @@ -579,40 +621,9 @@ static int rm_read_header(AVFormatContext *s)
>>  ffio_ensure_seekback(pb, 4);
>>  v = avio_rb32(pb);
>>  if (v == MKBETAG('M', 'L', 'T', 'I')) {
>> -int number_of_streams = avio_rb16(pb);
>> -int number_of_mdpr;
>> -int i;
>> -unsigned size2;
>> -for (i = 0; i> -avio_rb16(pb);
>> -number_of_mdpr = avio_rb16(pb);
>> -if

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

2015-11-16 Thread chcunningham

From: Chris Cunningham 

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

For VBR, fast seek is not precise, so continue to prefer the TOC
when available.
---
 libavformat/mp3dec.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 32ca00c..e12266c 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -515,8 +515,10 @@ static int mp3_seek(AVFormatContext *s, int stream_index, 
int64_t timestamp,
 filesize = size - s->internal->data_offset;
 }
 
-if (   (mp3->is_cbr || fast_seek)
-&& (mp3->usetoc == 0 || !mp3->xing_toc)
+// When fast seeking, prefer to use the TOC when available for VBR files
+// since av_rescale may not be accurate for VBR. For CBR, rescaling is
+// always accurate and more direct than a TOC lookup.
+if (fast_seek && (mp3->is_cbr || !mp3->xing_toc)
 && st->duration > 0
 && filesize > 0) {
 ie = 
-- 
2.6.0.rc2.230.g3dd15c0

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

Re: [FFmpeg-devel] [PATCH] avformat/mov: remove redundant assignment

2015-11-16 Thread Michael Niedermayer

On Sun, Nov 15, 2015 at 09:05:18PM -0500, Ganesh Ajjanagadde wrote:
> This is possibly undefined behavior based on sequence point rules, but I
> have not studied the spec at that level of detail.
> 
> Fixes: CID 1338321.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavformat/mov.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

ok

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

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


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

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

2015-11-16 Thread Stefano Sabatini

On date Tuesday 2015-11-10 00:25:30 +0100, Marton Balint encoded:
> This option can be used to select useful frames from an ffconcat file which is
> using inpoints and outpoints but where the source files are not intra frame
> only.
> 
> Signed-off-by: Marton Balint 
> ---
>  doc/filters.texi   | 17 +
>  libavfilter/f_select.c | 27 +++
>  2 files changed, 44 insertions(+)
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 471ec3f..ade571d 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -13196,6 +13196,16 @@ value between 0 and 1 to indicate a new scene; a low 
> value reflects a low
>  probability for the current frame to introduce a new scene, while a higher
>  value means the current frame is more likely to be one (see the example 
> below)
>  
> +@item concatdec_select
> +The concat demuxer can set the @var{lavf.concat.start_time} and the
> +@var{lavf.concat.duration} packet metadata values which are also present in 
> the
> +decoded frames.
> +

> +The @var{concatdec_select} variable is -1 if the frame pts is at least
> +start_time and either the duration metadata is missing or the frame pts is 
> less
> +than start_time + duration, 0 otherwise, and NaN if the start_time metadata 
> is
> +missing.

Add also a single explanation, like this:

That means that an input frame is selected if its pts is within the
interval set by the concat demuxer.

I wonder if it would make sense to export the input index
(lavf.concat.index), and use it here in place of -1.

> +
>  @end table
>  
>  The default value of the select expression is "1".
> @@ -13270,6 +13280,13 @@ Send even and odd frames to separate outputs, and 
> compose them:
>  @example
>  select=n=2:e='mod(n, 2)+1' [odd][even]; [odd] pad=h=2*ih [tmp]; [tmp][even] 
> overlay=y=h
>  @end example
> +
> +@item
> +Select useful frames from an ffconcat file which is using inpoints and
> +outpoints but where the source files are not intra frame only.
> +@example
> +ffmpeg -copyts -vsync 0 -segment_time_metadata 1 -i input.ffconcat -vf 
> select=concatdec_select -af aselect=concatdec_select output.avi
> +@end example

I guess that the lavf.concat metadata is set so that start_time and
duration corresponds to the inpoint and outpoint interval, right?

>  @end itemize
>  
>  @section selectivecolor
> diff --git a/libavfilter/f_select.c b/libavfilter/f_select.c
> index 2b926e1..14a23d2 100644
> --- a/libavfilter/f_select.c
> +++ b/libavfilter/f_select.c
> @@ -82,6 +82,8 @@ static const char *const var_names[] = {
>  
>  "scene",
>  
> +"concatdec_select",  ///< frame usefulness based on pts and frame 
> metadata originating from the concat demuxer

probably you can give a more explicative description ("useful" is
pretty generic)

[...]

Looks good otherwise.
-- 
FFmpeg = Fiendish and Friendly Mortal Portable Erroneous Gospel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [libav-devel] [PATCH] hqx: correct type and size check of info_offset

2015-11-16 Thread Vittorio Giovara

On Sun, Nov 15, 2015 at 10:50 AM, Andreas Cadhalpun
 wrote:
> It is used as size argument of ff_canopus_parse_info_tag, which uses it
> as size argument to bytestream2_init, which only supports sizes up to
> INT_MAX.
> Changing it's type to unsigned simplifies the check.
>
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/hqx.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/hqx.c b/libavcodec/hqx.c
> index 8060c7a..138d960 100644
> --- a/libavcodec/hqx.c
> +++ b/libavcodec/hqx.c
> @@ -417,8 +417,8 @@ static int hqx_decode_frame(AVCodecContext *avctx, void 
> *data,
>
>  info_tag= AV_RL32(src);
>  if (info_tag == MKTAG('I', 'N', 'F', 'O')) {
> -int info_offset = AV_RL32(src + 4);
> -if (info_offset > UINT32_MAX - 8 || info_offset + 8 > avpkt->size) {
> +unsigned info_offset = AV_RL32(src + 4);
> +if (info_offset > INT_MAX || info_offset + 8 > avpkt->size) {
>  av_log(avctx, AV_LOG_ERROR,
> "Invalid INFO header offset: 0x%08"PRIX32" is too 
> large.\n",
> info_offset);
> --
> 2.6.2

lgtm, thanks
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2015-11-16 Thread Michael Niedermayer

On Sat, Nov 14, 2015 at 08:05:59PM -0500, Ganesh Ajjanagadde wrote:
> isnan and isinf are actually macros as per the standard. In particular,
> the existing implementation has incorrect signature. Furthermore, this
> results in undefined behavior for e.g double values outside float range
> as per the standard.
> 
> This patch corrects the undefined behavior for all usage within FFmpeg.
> There are some issues with long double, but they are theoretical at the
> moment. For instance, the usual culprit for lacking isinf and that uses
> this fallback is Microsoft, and on Microsoft, long double = double
> anyway. Furthermore, no client of isinf, isnan in the codebase actually
> uses long double arguments.
> 
> The above issue is harder because long double may be an IEEE 128 bit quad
> (very rare) or a 80 bit extended precision value (on GCC/Clang).
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/libm.h | 50 --
>  1 file changed, 48 insertions(+), 2 deletions(-)
> 
> diff --git a/libavutil/libm.h b/libavutil/libm.h
> index ab5df1b..04d9411 100644
> --- a/libavutil/libm.h
> +++ b/libavutil/libm.h
> @@ -91,23 +91,69 @@ static av_always_inline av_const double hypot(double x, 
> double y)
>  #endif /* HAVE_HYPOT */
>  
>  #if !HAVE_ISINF
> -static av_always_inline av_const int isinf(float x)
> +#undef isinf
> +/* Note: these do not follow the BSD/Apple/GNU convention of returning -1 for
> +-Inf, +1 for Inf, 0 otherwise, but merely follow the POSIX/ISO mandated spec 
> of
> +returning a non-zero value for +/-Inf, 0 otherwise. */
> +static av_always_inline av_const int avpriv_isinff(float x)
>  {
>  uint32_t v = av_float2int(x);
>  if ((v & 0x7f80) != 0x7f80)
>  return 0;
>  return !(v & 0x007f);
>  }
> +
> +static av_always_inline av_const int avpriv_isinf(double x)
> +{
> +uint64_t v = av_double2int(x);
> +if ((v & 0x7ff0) != 0x7ff0)
> +return 0;
> +return !(v & 0x000f);
> +}
> +

> +static av_always_inline av_const int avpriv_isinfl(long double x)
> +{
> +// FIXME: just a stub, hard as long double width can vary between 
> platforms
> +// Also currently irrelevant
> +return avpriv_isinf(x);
> +}

i think we should not add any long double code. It could break
build and is unused

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

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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

[FFmpeg-devel] [PATCH] avformat/mlpdec: consider all valid mlp access units when probing

2015-11-16 Thread Hendrik Leppkes

Fixes probing of truehd/mlp files with a lot of frames in between the
major sync frames. The spec allows a distance of up to 128 frames in
between major sync frames, which leads to the probing code not reaching
the desired score.
---
 libavformat/mlpdec.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavformat/mlpdec.c b/libavformat/mlpdec.c
index 2cce506..d82df21 100644
--- a/libavformat/mlpdec.c
+++ b/libavformat/mlpdec.c
@@ -29,16 +29,19 @@ static int av_always_inline mlp_thd_probe(AVProbeData *p, 
uint32_t sync)
 {
 const uint8_t *buf, *last_buf = p->buf, *end = p->buf + p->buf_size;
 int frames = 0, valid = 0, size = 0;
+int nsubframes = 0;
 
 for (buf = p->buf; buf + 8 <= end; buf++) {
 if (AV_RB32(buf + 4) == sync) {
 frames++;
 if (last_buf + size == buf) {
-valid++;
+valid += 1 + nsubframes / 8;
 }
+nsubframes = 0;
 last_buf = buf;
 size = (AV_RB16(buf) & 0xfff) * 2;
 } else if (buf - last_buf == size) {
+nsubframes++;
 size += (AV_RB16(buf) & 0xfff) * 2;
 }
 }
-- 
2.6.2.windows.1

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

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

2015-11-16 Thread Chris Cunningham

Hey, sorry for the slow reply.

Use this sample file. Its a CBR file with a corrupt TOC.
http://happyworm.com/jPlayerLab/halite/jumptest/testcount.mp3

Before applying my patch:

./ffplay -ss 00:33:20 testcount.mp3  -usetoc 0
plays out "1395", which is the correct audio for the given seek time

./ffplay -ss 00:33:20 testcount.mp3  -usetoc 1
plays out "...378, 1379", way off because it used the bad TOC

After applying my patch these commands both play out the correct time of
"1395" because usetoc=1 is ignored/overridden by virtue of this file being
CBR.

However, I've *just* thought of another (better) approach. My goal is
really to improve the behavior of AVFMT_FLAG_FAST_SEEK
,
which defaults to using the TOC whenever its available. Standby for a
second patch that will only change TOC behavior when the
AVFMT_FLAG_FAST_SEEK is being used.

Chris

On Mon, Nov 9, 2015 at 3:34 PM, Michael Niedermayer 
wrote:

> On Wed, Nov 04, 2015 at 05:21:57PM -0800, Chris Cunningham wrote:
> > "Fast seek" uses linear interpolation to find the position of the
> > requested seek time. For CBR this is more direct than using the
> > mp3 TOC and bypassing the TOC avoids problems when the TOC is
> > corrupted (e.g. https://crbug.com/545914).
> >
> > For VBR, fast seek is not precise, so continue to prefer the TOC
> > when available.
> > ---
> >  libavformat/mp3dec.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
>
> how can this be reproduced with FFmpeg ?
> do you have a sample which you can share ?
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I have often repented speaking, but never of holding my tongue.
> -- Xenocrates
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Error in ATRAC1 decoder?

2015-11-16 Thread Даниил Чередник

Thank you for answer.

If I understood available ATRAC1 docs, the purpose of this delay line is
just to compensate delay of 1st QMF because for 1st and 2nd band we have
two QMF but for 3rd band just one.

About test, yes for some reason this patch brakes it. I will try to find
out. Sorry, I should have done it before.

I tried to decode "The Four Seasons, Concerto Alla Rustica in G - Winter-
Largo.aea" sample, the results are:
without patch: https://yadi.sk/i/PCFplrafkWEFC
with patch: https://yadi.sk/i/iLUR188gkWEFn
On zoomed spectrogram it is possible to find aliasing if decode without
patch. I can share decoded wav file if needed.



On Mon, Nov 16, 2015 at 3:45 AM, Michael Niedermayer  wrote:

> On Sat, Nov 14, 2015 at 02:59:30AM +0300, Даниил Чередник wrote:
> > Hello!
> >
> > I have noticed if decode
> >
> https://samples.ffmpeg.org/A-codecs/ATRAC1/Test%20tones%20disc%20-%20Chirp.aea
> > file by ffmpeg we got aliasing near 11025Hz. Screenshots:
> > https://yadi.sk/i/r-95jZkKkSnbu https://yadi.sk/i/PV92LNESkSnby
> >
> > I was tried to solve it:
> >
> > ATRAC1 - hybrid codec, has two stacked QMF and splits the signal into 3
> > band before MDCT. Thereby we need to compensate delay of one QMF to
> > achieve reconstruction.
> > There is a delay line but it looks like delay for 23 sample is not
> correct.
> > I have done some experiments and got 39 should be right delay. Results of
> > decoding with patch: https://yadi.sk/i/yooaIQrmkSncB
> > https://yadi.sk/i/CUXsH7-CkSncK
> >
>
> > To be honest I am not a prof in math and it would be great if someone
> > recheck it from math perspective.
>
> i dont think math can help here
> whatever a format requires that has to be done, this could even be
> wrong from a math point of view of a ideal transform
>
>
> >
> > There is a patch in attach.
>
> the patch also affects the atrac1 fate test
> have you checked if the new output for that test is better than the
> old ?
>
> make V=2 fate-atrac1
>
> also have you looked at other files, is this improving all files ?
> any that get worse ?
>
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many that live deserve death. And some that die deserve life. Can you give
> it to them? Then do not be too eager to deal out death in judgement. For
> even the very wise cannot see all ends. -- Gandalf
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>


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

Re: [FFmpeg-devel] 6c6ac9cb "avutil/x86/intmath: Use tzcnt in place of bsf."

2015-11-16 Thread Hans Wennborg

Hello ffmpeg developers,

This commit [1] is causing problems when compiling with Clang on Windows:

..\..\third_party\ffmpeg\libavutil/x86/intmath.h(53,33) :  error:
always_inline function '__tzcnt_u32' requires target feature 'bmi',
but would be inlined into function 'ff_ctzll_x86' that is compiled
without support for 'bmi'
return ((uint32_t)v == 0) ? _tzcnt_u32((uint32_t)(v >> 32)) + 32 :
_tzcnt_u32((uint32_t)v);
^

Essentially the compiler is saying that it won't allow using this
intrinsic unless compiling for a target that supports BMI.

Is there a performance reason for using __tzcnt_u32 instead of
_BitScanForward, or was it mainly to simplify the code?

We're working around this in Chromium by #define'ing __tzcnt_u32 to
__builtin_ctz at the moment, but it would be good if we could find a
nicer solution that could be applied upstream.

Cheers,
Hans

 [1]. 
https://github.com/FFmpeg/FFmpeg/commit/6c6ac9cb17c4944514bde833f2fa8aa8dafa974a
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2015-11-16 Thread Chris Cunningham

To test this new patch, again use testcount.mp3
 (CBR,
corrupt TOC).

Current ffmpeg (with none of my mp3 patches)

./ffplay testcount.mp3 -ss 00:33:20 -usetoc 0

plays out "1395", which is correct

./ffplay testcount.mp3 -ss 00:33:20 -usetoc 1
plays out "..378, 1389", which is incorrect due to the corrupted TOC.

./ffplay testcount.mp3 -ss 00:33:20 -fflags fastseek
also plays out "..378, 1389" because current fast_seek logic uses the TOC
whenever available for CBR and VBR alike.

After applying my *latest* patch:

./ffplay testcount.mp3 -ss 00:33:20 -usetoc 0
is unchanged: plays out "1395", which is correct

./ffplay testcount.mp3 -ss 00:33:20 -usetoc 1
is unchanged: still plays out "378, 1389". This is wrong, but it allows
users to force using TOC should they prefer.

./ffplay testcount.mp3 -ss 00:33:20 -fflags fastseek
*is changed: *plays out "1395", which is correct. fast seek no longer uses
the TOC for CBR files.

What do you think? I personally prefer this way so that usetoc is still
meaningful for CBR files.

Thanks,
Chris

On Mon, Nov 16, 2015 at 4:58 PM,  wrote:

> From: Chris Cunningham 
>
> "Fast seek" uses linear interpolation to find the position of the
> requested seek time. For CBR this is more direct than using the
> mp3 TOC and bypassing the TOC avoids problems when the TOC is
> corrupted (e.g. https://crbug.com/545914).
>
> For VBR, fast seek is not precise, so continue to prefer the TOC
> when available.
> ---
>  libavformat/mp3dec.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index 32ca00c..e12266c 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -515,8 +515,10 @@ static int mp3_seek(AVFormatContext *s, int
> stream_index, int64_t timestamp,
>  filesize = size - s->internal->data_offset;
>  }
>
> -if (   (mp3->is_cbr || fast_seek)
> -&& (mp3->usetoc == 0 || !mp3->xing_toc)
> +// When fast seeking, prefer to use the TOC when available for VBR
> files
> +// since av_rescale may not be accurate for VBR. For CBR, rescaling is
> +// always accurate and more direct than a TOC lookup.
> +if (fast_seek && (mp3->is_cbr || !mp3->xing_toc)
>  && st->duration > 0
>  && filesize > 0) {
>  ie = 
> --
> 2.6.0.rc2.230.g3dd15c0
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2015-11-16 Thread Michael Niedermayer

On Mon, Nov 16, 2015 at 05:28:58PM -0800, Chris Cunningham wrote:
> To test this new patch, again use testcount.mp3
>  (CBR,
> corrupt TOC).
> 
> Current ffmpeg (with none of my mp3 patches)
> 
> ./ffplay testcount.mp3 -ss 00:33:20 -usetoc 0
> 
> plays out "1395", which is correct
> 
> 
> ./ffplay testcount.mp3 -ss 00:33:20 -usetoc 1
> plays out "..378, 1389", which is incorrect due to the corrupted TOC.
> 
> ./ffplay testcount.mp3 -ss 00:33:20 -fflags fastseek
> also plays out "..378, 1389" because current fast_seek logic uses the TOC
> whenever available for CBR and VBR alike.
> 
> 
> After applying my *latest* patch:
> 
> ./ffplay testcount.mp3 -ss 00:33:20 -usetoc 0
> is unchanged: plays out "1395", which is correct
> 
> ./ffplay testcount.mp3 -ss 00:33:20 -usetoc 1
> is unchanged: still plays out "378, 1389". This is wrong, but it allows
> users to force using TOC should they prefer.
> 
> ./ffplay testcount.mp3 -ss 00:33:20 -fflags fastseek
> *is changed: *plays out "1395", which is correct. fast seek no longer uses
> the TOC for CBR files.
> 
> 
> 

> What do you think? I personally prefer this way so that usetoc is still
> meaningful for CBR files.

i tend to agree about usetocs meaningfullness but it seems breaking
fate tests:
--- ./tests/ref/seek/extra-mp3  2015-11-16 00:07:55.812389092 +0100
+++ tests/data/fate/seek-extra-mp3  2015-11-17 03:15:54.266446909 +0100
@@ -5,16 +5,14 @@
 ret: 0 st: 0 flags:1 dts: 1.880816 pts: 1.880816 pos:  31544 size:   
418
 ret: 0 st: 0 flags:0  ts: 0.788334
 ret: 0 st: 0 flags:1 dts: 0.809796 pts: 0.809796 pos:  14407 size:   
418
-ret: 0 st: 0 flags:1  ts:-0.317499
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:   1451 size:   
440
+ret:-1 st: 0 flags:1  ts:-0.317499
 ret: 0 st:-1 flags:0  ts: 2.576668
 ret: 0 st: 0 flags:1 dts: 2.586122 pts: 2.586122 pos:  42828 size:   
418
 ret: 0 st:-1 flags:1  ts: 1.470835
 ret: 0 st: 0 flags:1 dts: 1.462857 pts: 1.462857 pos:  24856 size:   
418
 ret: 0 st: 0 flags:0  ts: 0.365002
 ret: 0 st: 0 flags:1 dts: 0.365714 pts: 0.365714 pos:   7302 size:   
418
-ret: 0 st: 0 flags:1  ts:-0.740831
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:   1451 size:   
440
+ret:-1 st: 0 flags:1  ts:-0.740831
 ret: 0 st:-1 flags:0  ts: 2.153336
 ret: 0 st: 0 flags:1 dts: 2.168163 pts: 2.168163 pos:  36141 size:   
418
 ret: 0 st:-1 flags:1  ts: 1.047503
@@ -41,13 +39,11 @@
 ret: 0 st: 0 flags:1 dts: 1.985306 pts: 1.985306 pos:  33215 size:   
418
 ret: 0 st:-1 flags:0  ts: 0.883340
 ret: 0 st: 0 flags:1 dts: 0.888163 pts: 0.888163 pos:  15661 size:   
418
-ret: 0 st:-1 flags:1  ts:-0.222493
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:   1451 size:   
440
+ret:-1 st:-1 flags:1  ts:-0.222493
 ret: 0 st: 0 flags:0  ts: 2.671674
 ret: 0 st: 0 flags:1 dts: 2.690612 pts: 2.690612 pos:  44500 size:   
418
 ret: 0 st: 0 flags:1  ts: 1.565841
-ret: 0 st: 0 flags:1 dts: 1.567347 pts: 1.567347 pos:  26528 size:   
418
+ret: 0 st: 0 flags:1 dts: 1.541224 pts: 1.541224 pos:  26110 size:   
418
 ret: 0 st:-1 flags:0  ts: 0.460008
 ret: 0 st: 0 flags:1 dts: 0.470204 pts: 0.470204 pos:   8974 size:   
418
-ret: 0 st:-1 flags:1  ts:-0.645825
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:   1451 size:   
440
+ret:-1 st:-1 flags:1  ts:-0.645825
Test seek-extra-mp3 failed. Look at tests/data/fate/seek-extra-mp3.err for 
details.
make: *** [fate-seek-extra-mp3] Error 1
make: *** Waiting for unfinished jobs


> 
> Thanks,
> Chris
> 
> On Mon, Nov 16, 2015 at 4:58 PM,  wrote:
> 
> > From: Chris Cunningham 
> >
> > "Fast seek" uses linear interpolation to find the position of the
> > requested seek time. For CBR this is more direct than using the
> > mp3 TOC and bypassing the TOC avoids problems when the TOC is
> > corrupted (e.g. https://crbug.com/545914).
> >
> > For VBR, fast seek is not precise, so continue to prefer the TOC
> > when available.
> > ---
> >  libavformat/mp3dec.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> > index 32ca00c..e12266c 100644
> > --- a/libavformat/mp3dec.c
> > +++ b/libavformat/mp3dec.c
> > @@ -515,8 +515,10 @@ static int mp3_seek(AVFormatContext *s, int
> > stream_index, int64_t timestamp,
> >  filesize = size - s->internal->data_offset;
> >  }
> >
> > -if (   (mp3->is_cbr || fast_seek)
> > -&& (mp3->usetoc == 0 || !mp3->xing_toc)
> > +// When fast seeking, prefer to use the TOC when available for VBR
> > files
> > +// since av_rescale may not be accurate for VBR. For CBR, rescaling is
> > +

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

2015-11-16 Thread wm4

On Sun, 15 Nov 2015 17:56:22 -0500
Ganesh Ajjanagadde  wrote:

> ffio_ensure_seekback can fail due to e.g ENOMEM. This return value is
> propagated here, and all usage in the codebase now has its return value
> checked.
> 
> A potential memory leak in mp3_read_header is also fixed via a goto
> fail.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavformat/mp3dec.c | 12 +---
>  libavformat/rmdec.c  |  3 ++-
>  2 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index 32ca00c..9fefe2d 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -373,18 +373,20 @@ static int mp3_read_header(AVFormatContext *s)
>  
>  ret = ff_replaygain_export(st, s->metadata);
>  if (ret < 0)
> -return ret;
> +goto fail;
>  
>  off = avio_tell(s->pb);
>  for (i = 0; i < 64 * 1024; i++) {
>  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)
> +goto 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)
> +goto fail;
>  if (check(s->pb, off + i + frame_size, ) >= 0 &&
>  (header & SAME_HEADER_MASK) == (header2 & SAME_HEADER_MASK))
>  {
> @@ -402,6 +404,10 @@ static int mp3_read_header(AVFormatContext *s)
>  
>  /* the parameters will be extracted from the compressed bitstream */
>  return 0;
> +
> +fail:
> +ff_free_stream(s, st);
> +return ret;
>  }
>  
>  #define MP3_PACKET_SIZE 1024
> diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
> index 4ec78ef..d6e820e 100644
> --- a/libavformat/rmdec.c
> +++ b/libavformat/rmdec.c
> @@ -576,7 +576,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)
> +goto fail;
>  v = avio_rb32(pb);
>  if (v == MKBETAG('M', 'L', 'T', 'I')) {
>  int number_of_streams = avio_rb16(pb);

NACK. There's no reason to fatally fail in these cases.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: fix overriding packet duration warning

2015-11-16 Thread Muhammad Faiz

On Mon, Nov 16, 2015 at 8:27 AM, Michael Niedermayer
 wrote:
> On Mon, Nov 16, 2015 at 12:26:28AM +0700, Muhammad Faiz wrote:
>> On Sun, Nov 15, 2015 at 5:55 PM, Michael Niedermayer
>>  wrote:
>> > On Sun, Nov 15, 2015 at 04:04:42PM +0700, Muhammad Faiz wrote:
>> >> no warning when packet duration is valid
>> >>
>> >> patch attached
>> >
>> >> From 789e9f0e93a246fd820401e6c298835bf40dc0c3 Mon Sep 17 00:00:00 2001
>> >> From: Muhammad Faiz 
>> >> Date: Sun, 15 Nov 2015 15:25:43 +0700
>> >> Subject: [PATCH] ffmpeg: fix overriding packet duration warning
>> >>
>> >> no warning when packet duration is valid
>> >> ---
>> >>  ffmpeg.c | 7 ---
>> >>  1 file changed, 4 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/ffmpeg.c b/ffmpeg.c
>> >> index 3341777..5b9e38e 100644
>> >> --- a/ffmpeg.c
>> >> +++ b/ffmpeg.c
>> >> @@ -673,10 +673,11 @@ static void write_frame(AVFormatContext *s, 
>> >> AVPacket *pkt, OutputStream *ost)
>> >>  }
>> >>
>> >>  if (ost->frame_rate.num && ost->is_cfr) {
>> >> -if (pkt->duration > 0)
>> >> +int64_t new_duration = av_rescale_q(1, 
>> >> av_inv_q(ost->frame_rate),
>> >> +ost->st->time_base);
>> >> +if (pkt->duration > 0 && pkt->duration != new_duration)
>> >>  av_log(NULL, AV_LOG_WARNING, "Overriding packet duration 
>> >> by frame rate, this should not happen\n");
>> >> -pkt->duration = av_rescale_q(1, av_inv_q(ost->frame_rate),
>> >> - ost->st->time_base);
>> >> +pkt->duration = new_duration;
>> >
>> > does it work to leave the duration instead of overriding if its
>> > already set ?
>> > i mean the new cfr duration code is certainly not correct for many
>> > common cases (like 24000/1001 framerates at a 90khz timebase) so
>> > overriding things by it if something else already set a (more correct?)
>> > duration might be a bad idea
>>
>> It just change warning message, when actually pkt->duration is equal
>> to new_duration, no warning is generated. It does not change the
>> previous behavior.
>>
>
>> About overriding, don't ask me. I don't know for that. That is not from me.
>
> yes but you seem t have found some cases where this code triggers
> so i was wondering if you also saw cases where they differ and if
> so what values in that case are more correct
>
My patch about wrapped_avframe trigger it on yuv4mpegenc, because
it set packet duration based on frame duration (I think it is not
forbidden). Fortunately both duration don't differ.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat: add IVR demuxer

2015-11-16 Thread Paul B Mahol

2n version attached
From bada349bdba599b92bcb1d3bc16b630c182174f9 Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Wed, 11 Nov 2015 22:04:57 +0100
Subject: [PATCH] avformat: add IVR demuxer

Signed-off-by: Paul B Mahol 
---

Problem with slices/frames ending in middle of packet is still there.

Reproducible with Opener_rm_hi.ivr

---
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/rmdec.c  | 303 +--
 3 files changed, 271 insertions(+), 34 deletions(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index bdfe35c..e3f19dd 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -228,6 +228,7 @@ OBJS-$(CONFIG_ISS_DEMUXER)   += iss.o
 OBJS-$(CONFIG_IV8_DEMUXER)   += iv8.o
 OBJS-$(CONFIG_IVF_DEMUXER)   += ivfdec.o
 OBJS-$(CONFIG_IVF_MUXER) += ivfenc.o
+OBJS-$(CONFIG_IVR_DEMUXER)   += rmdec.o rm.o rmsipr.o
 OBJS-$(CONFIG_JACOSUB_DEMUXER)   += jacosubdec.o subtitles.o
 OBJS-$(CONFIG_JACOSUB_MUXER) += jacosubenc.o rawenc.o
 OBJS-$(CONFIG_JV_DEMUXER)+= jvdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 73b1e4a..9ac40c5 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -169,6 +169,7 @@ void av_register_all(void)
 REGISTER_DEMUXER (ISS,  iss);
 REGISTER_DEMUXER (IV8,  iv8);
 REGISTER_MUXDEMUX(IVF,  ivf);
+REGISTER_DEMUXER (IVR,  ivr);
 REGISTER_MUXDEMUX(JACOSUB,  jacosub);
 REGISTER_DEMUXER (JV,   jv);
 REGISTER_MUXER   (LATM, latm);
diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
index 4ec78ef..21e8ec5 100644
--- a/libavformat/rmdec.c
+++ b/libavformat/rmdec.c
@@ -63,6 +63,7 @@ typedef struct RMDemuxContext {
 int remaining_len;
 int audio_stream_num; ///< Stream number for audio packets
 int audio_pkt_cnt; ///< Output packet counter
+int data_end;
 } RMDemuxContext;
 
 static int rm_read_close(AVFormatContext *s);
@@ -488,6 +489,47 @@ static int rm_read_header_old(AVFormatContext *s)
 return rm_read_audio_stream_info(s, s->pb, st, st->priv_data, 1);
 }
 
+static int rm_read_multi(AVFormatContext *s, AVIOContext *pb,
+ AVStream *st, char *mime)
+{
+int number_of_streams = avio_rb16(pb);
+int number_of_mdpr;
+int i, ret;
+unsigned size2;
+for (i = 0; i 0) {
+st2 = avformat_new_stream(s, NULL);
+if (!st2) {
+ret = AVERROR(ENOMEM);
+return ret;
+}
+st2->id = st->id + (i<<16);
+st2->codec->bit_rate = st->codec->bit_rate;
+st2->start_time = st->start_time;
+st2->duration   = st->duration;
+st2->codec->codec_type = AVMEDIA_TYPE_DATA;
+st2->priv_data = ff_rm_alloc_rmstream();
+if (!st2->priv_data)
+return AVERROR(ENOMEM);
+} else
+st2 = st;
+
+size2 = avio_rb32(pb);
+ret = ff_rm_read_mdpr_codecdata(s, s->pb, st2, st2->priv_data,
+size2, mime);
+if (ret < 0)
+return ret;
+}
+return 0;
+}
+
 static int rm_read_header(AVFormatContext *s)
 {
 RMDemuxContext *rm = s->priv_data;
@@ -579,40 +621,9 @@ static int rm_read_header(AVFormatContext *s)
 ffio_ensure_seekback(pb, 4);
 v = avio_rb32(pb);
 if (v == MKBETAG('M', 'L', 'T', 'I')) {
-int number_of_streams = avio_rb16(pb);
-int number_of_mdpr;
-int i;
-unsigned size2;
-for (i = 0; i 0) {
-st2 = avformat_new_stream(s, NULL);
-if (!st2) {
-ret = AVERROR(ENOMEM);
-goto fail;
-}
-st2->id = st->id + (i<<16);
-st2->codec->bit_rate = st->codec->bit_rate;
-st2->start_time = st->start_time;
-st2->duration   = st->duration;
-

Re: [FFmpeg-devel] [PATCH 2/2] fate: fix concat demuxer extended tests on windows

2015-11-16 Thread Hendrik Leppkes

On Mon, Nov 16, 2015 at 3:39 AM, Michael Niedermayer
 wrote:
> On Mon, Nov 16, 2015 at 01:25:19AM +0100, Marton Balint wrote:
>> Line endings do matter to md5sum...
>>
>> Signed-off-by: Marton Balint 
>> ---
>>  tests/fate-run.sh | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tests/fate-run.sh b/tests/fate-run.sh
>> index 6d46158..966cbe2 100755
>> --- a/tests/fate-run.sh
>> +++ b/tests/fate-run.sh
>> @@ -262,7 +262,7 @@ concat(){
>>  awk "{gsub(/%SRCFILE%/, \"$sample\"); print}" $template > $concatfile
>>
>>  if [ "$mode" = "md5" ]; then
>> -  run ffprobe${PROGSUF} -show_streams -show_packets -v 0 -fflags 
>> keepside -safe 0 $extra_args $concatfile > $packetfile
>> +  run ffprobe${PROGSUF} -show_streams -show_packets -v 0 -fflags 
>> keepside -safe 0 $extra_args $concatfile | sed 's/\r//g' > $packetfile
>>do_md5sum $packetfile
>>  else
>>run ffprobe${PROGSUF} -show_streams -show_packets -v 0 -of 
>> compact=p=0:nk=1 -fflags keepside -safe 0 $extra_args $concatfile
>> --
>> 2.6.2
>
> the 2 patches fix fate on mingw32+64 here locally
>

Fixes both mingw and MSVC running on Windows as well, therefor applied!

Thanks for fixing the problem so quickly.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mov: fix memory leak

2015-11-16 Thread Paul B Mahol

On 11/16/15, Ganesh Ajjanagadde  wrote:
> Fixes: CID 1338328.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavformat/mov.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 38d3659..7ab2808 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -430,6 +430,7 @@ retry:
>  if (snprintf(str, str_size_alloc, "%f", val) >= str_size_alloc)
> {
>  av_log(c->fc, AV_LOG_ERROR,
> "Failed to store the float32 number (%f) in
> string.\n", val);
> +av_free(str);
>  return AVERROR_INVALIDDATA;
>  }
>  } else {
> --
> 2.6.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] UDP constant bitrate feature (cbr)

2015-11-16 Thread Pavel Meshkov


Good day.
We still need this feature. Can someone implement above functionality on 
bounty base (up to $2000)?


12.11.2015 12:28, Pavel Meshkov пишет:

Thanks for explanation.
We will try to rewrite it with new knowledge.

I need your suggestion.
We are try to send constant udp stream from rtmp live stream with only
repack it.

I found "mpegts_write_packet_internal" function
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mpegtsenc.c#L1402
is it right place to make changes?



2015-11-12 1:47 GMT+03:00 Kieran Kunhya :


On 11 November 2015 at 22:41, Kieran Kunhya  wrote:

On 11 Nov 2015 7:08 p.m., "Pavel Meshkov" 

wrote:

Trying to reattach patch

11.11.2015 22:01, Pavel Meshkov пишет:

We added UDP output constant bitrate functionality.
Please review patch.

P.S.: It's first patch we send. Please notify me if something made

wrong.

This an awful hack.
Kieran

I have been asked to explain why this is bad.
You want to use FFmpeg to stream an mpegts - the only correct way to
do this is to index the ts like "multicat" does and then use the PCR
to schedule the output timing.

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


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


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

Re: [FFmpeg-devel] [PATCH] avformat/aviobuf: Improve readability of aviobuf

2015-11-16 Thread Michael Niedermayer

On Sun, Nov 15, 2015 at 06:02:11PM -0800, Bryan Huh wrote:
> No functional changes in this commit, mostly adding comments for
> improved readability. Also minor re-arrangements of variables.
> ---
>  libavformat/avio.h|   47 +++
>  libavformat/aviobuf.c |   16 +---
>  2 files changed, 56 insertions(+), 7 deletions(-)

patch split and both applied

thanks

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

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


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

Re: [FFmpeg-devel] [PATCH] mxfdec: check edit_rate also for physical_track

2015-11-16 Thread tim nicholson

On 15/11/15 18:07, Andreas Cadhalpun wrote:
> Previously only the edit_rate of material_track was checked.
> If it's negative, it causes assertion failures in av_rescale_rnd.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/mxfdec.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index 99c8fed..429f46a 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -1776,6 +1776,16 @@ static int 
> mxf_parse_physical_source_package(MXFContext *mxf, MXFTrack *source_t
>  continue;
>  }
>  
> +if (physical_track->edit_rate.num <= 0 ||
> +physical_track->edit_rate.den <= 0) {
> +av_log(mxf->fc, AV_LOG_WARNING,
> +   "Invalid edit rate (%d/%d) found on structural"
> +   " component #%d, defaulting to 25/1\n",
> +   physical_track->edit_rate.num,
> +   physical_track->edit_rate.den, i);
> +physical_track->edit_rate = (AVRational){25, 1};
> +}
> +
>  for (k = 0; k < 
> physical_track->sequence->structural_components_count; k++) {
>  if (!(mxf_tc = mxf_resolve_timecode_component(mxf, 
> _track->sequence->structural_components_refs[k])))
>  continue;
> 

LGTM, but I am curious as to where you have seen examples of negative
edit rates. (I have found examples in mxf code where signed and unsigned
have been muddled leading to invalid figures and I am wondering if this
is another)

-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] ac3dsp: remove 3dnow version of float_to_fixed24

2015-11-16 Thread Daniel Verkamp

This implementation is only used in a very narrow set of circumstances:
it is not bitexact, and there is an SSE implementation, so the 3DNow
version would only get used on K6-II/K6-III/early (pre-XP) Athlon CPUs.
It is completely dead code in x86-64 builds.

Signed-off-by: Daniel Verkamp 
---
 libavcodec/x86/ac3dsp.asm| 29 -
 libavcodec/x86/ac3dsp_init.c |  6 --
 2 files changed, 35 deletions(-)

diff --git a/libavcodec/x86/ac3dsp.asm b/libavcodec/x86/ac3dsp.asm
index 675ade3..dbb5dab 100644
--- a/libavcodec/x86/ac3dsp.asm
+++ b/libavcodec/x86/ac3dsp.asm
@@ -212,35 +212,6 @@ AC3_SHIFT r, 32, psrad
 ; void ff_float_to_fixed24(int32_t *dst, const float *src, unsigned int len)
 ;-
 
-; The 3DNow! version is not bit-identical because pf2id uses truncation rather
-; than round-to-nearest.
-INIT_MMX 3dnow
-cglobal float_to_fixed24, 3, 3, 0, dst, src, len
-movq   m0, [pf_1_24]
-.loop:
-movq   m1, [srcq   ]
-movq   m2, [srcq+8 ]
-movq   m3, [srcq+16]
-movq   m4, [srcq+24]
-pfmul  m1, m0
-pfmul  m2, m0
-pfmul  m3, m0
-pfmul  m4, m0
-pf2id  m1, m1
-pf2id  m2, m2
-pf2id  m3, m3
-pf2id  m4, m4
-movq  [dstq   ], m1
-movq  [dstq+8 ], m2
-movq  [dstq+16], m3
-movq  [dstq+24], m4
-add  srcq, 32
-add  dstq, 32
-sub  lend, 8
-ja .loop
-femms
-RET
-
 INIT_XMM sse
 cglobal float_to_fixed24, 3, 3, 3, dst, src, len
 movaps m0, [pf_1_24]
diff --git a/libavcodec/x86/ac3dsp_init.c b/libavcodec/x86/ac3dsp_init.c
index eea2736..f229f34 100644
--- a/libavcodec/x86/ac3dsp_init.c
+++ b/libavcodec/x86/ac3dsp_init.c
@@ -41,7 +41,6 @@ void ff_ac3_lshift_int16_sse2(int16_t *src, unsigned int len, 
unsigned int shift
 void ff_ac3_rshift_int32_mmx (int32_t *src, unsigned int len, unsigned int 
shift);
 void ff_ac3_rshift_int32_sse2(int32_t *src, unsigned int len, unsigned int 
shift);
 
-void ff_float_to_fixed24_3dnow(int32_t *dst, const float *src, unsigned int 
len);
 void ff_float_to_fixed24_sse  (int32_t *dst, const float *src, unsigned int 
len);
 void ff_float_to_fixed24_sse2 (int32_t *dst, const float *src, unsigned int 
len);
 
@@ -206,11 +205,6 @@ av_cold void ff_ac3dsp_init_x86(AC3DSPContext *c, int 
bit_exact)
 c->ac3_lshift_int16 = ff_ac3_lshift_int16_mmx;
 c->ac3_rshift_int32 = ff_ac3_rshift_int32_mmx;
 }
-if (EXTERNAL_AMD3DNOW(cpu_flags)) {
-if (!bit_exact) {
-c->float_to_fixed24 = ff_float_to_fixed24_3dnow;
-}
-}
 if (EXTERNAL_MMXEXT(cpu_flags)) {
 c->ac3_exponent_min = ff_ac3_exponent_min_mmxext;
 c->ac3_max_msb_abs_int16 = ff_ac3_max_msb_abs_int16_mmxext;
-- 
2.4.10

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

Re: [FFmpeg-devel] 6c6ac9cb "avutil/x86/intmath: Use tzcnt in place of bsf."

2015-11-16 Thread Matt Oliver

On 17 November 2015 at 12:12, Hans Wennborg  wrote:

> Hello ffmpeg developers,
>
> This commit [1] is causing problems when compiling with Clang on Windows:
>
> ..\..\third_party\ffmpeg\libavutil/x86/intmath.h(53,33) :  error:
> always_inline function '__tzcnt_u32' requires target feature 'bmi',
> but would be inlined into function 'ff_ctzll_x86' that is compiled
> without support for 'bmi'
> return ((uint32_t)v == 0) ? _tzcnt_u32((uint32_t)(v >> 32)) + 32 :
> _tzcnt_u32((uint32_t)v);
> ^
>
> Essentially the compiler is saying that it won't allow using this
> intrinsic unless compiling for a target that supports BMI.
>
> Is there a performance reason for using __tzcnt_u32 instead of
> _BitScanForward, or was it mainly to simplify the code?
>
> We're working around this in Chromium by #define'ing __tzcnt_u32 to
> __builtin_ctz at the moment, but it would be good if we could find a
> nicer solution that could be applied upstream.
>
> Cheers,
> Hans
>
>  [1].
> https://github.com/FFmpeg/FFmpeg/commit/6c6ac9cb17c4944514bde833f2fa8aa8dafa974a
>

tzcnt was used instead of bsf as it has performance advantages on any cpu
that supports the tzcnt instruction. Although tzcnt is a newer instruction
that is part of the BMI instruction set the actual opcode generated by this
instruction is the equivalent to 'rep bsf'. So this instruction will still
execute on any older cpu that doesnt support tzcnt as just the bsf
instruction instead. So it was used as it provides optimum performance on
both newer and older cpus.

Clang is clearly not allowing this particular optimisation. I dont know of
a way to ignore this using a command line option so probably the best way
is to just disable this code when using clang. This will go back to using
the previous behavior which assuming clang on windows still defines the gcc
version check macros will use the __builtin_ctz.

The attached patch should fix it but I dont have clang for windows to test
it.

0001-avutil-x86-intmath-Fix-compilation-with-clang-on-win.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ac3dsp: remove 3dnow version of float_to_fixed24

2015-11-16 Thread Daniel Verkamp

On Tue, Nov 17, 2015 at 12:00 AM, Daniel Verkamp  wrote:
>
> This implementation is only used in a very narrow set of circumstances:
> it is not bitexact, and there is an SSE implementation, so the 3DNow
> version would only get used on K6-II/K6-III/early (pre-XP) Athlon CPUs.
> It is completely dead code in x86-64 builds.

This patch is more or less to "test the waters" for more 3DNow removal patches.

The arguments in favor of removal:

- Any CPU with 3DNow support but no SSE2 support is 10+ years old
(Athlon 64 and the corresponding Opteron introduced SSE2 in 2003), and
any with 3DNow but no SSE is going on 15 years old (Athlon XP added
SSE in 2001).

- Because of the above, nobody is testing this code, so it can easily
bit-rot; I have been running a FATE client on an Athlon 64 machine
(from 2005!) to help guard against this, but I'd like to toss it,
since it's not doing anything else useful aside from heating up the
room. (Additionally, this machine is actually *too new* and is being
forced via CPUFLAGS to run 3DNow functions, rather than the supported
SSE2, so its continued existence is not a proof of users of these
optimizations.)

- 64-bit builds are carrying this extra code that will never get used.
This could be solved by compile-time checks for ARCH_X86_32, but I
think that would be a waste of effort compared to just removing the
code.

- More code means higher maintenance burden when modifying the
corresponding functions.

Arguments against:

- Keeping the existing optimizations has very low cost (but see
maintenance and FATE arguments).

- The few affected machines will presumably get slightly worse
performance from the C/MMX fallbacks.

If you do in fact use an affected machine to run FFmpeg, now is the
time to speak up: if you post benchmarks proving these optimizations
are in fact useful and used, they are less likely to be removed.

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

57 matches

Mail list logo