Re: [FFmpeg-devel] [PATCH v7 3/3] mips: add support for R6

[Vicente Olivert Riera]

ping

On 24/02/16 16:38, Vicente Olivert Riera wrote:
> Understanding the mips32r6 and mips64r6 ISAs in the configure script is
> not enough. In order to have full support for MIPS R6 in FFmpeg we need
> to be able to build it, and for that we need to make sure we don't use
> incompatible assembler code which makes the build fail. Ifdefing the
> offending code is sufficient to fix the problem.
> 
> Signed-off-by: Vicente Olivert Riera 
> ---
> Changes v1 -> v7:
>  - Nothing.
> 
>  libavcodec/mips/aaccoder_mips.c   |  4 
>  libavcodec/mips/aacdec_mips.h |  2 ++
>  libavcodec/mips/aacpsdsp_mips.c   |  4 
>  libavcodec/mips/aacpsy_mips.h |  2 ++
>  libavcodec/mips/aacsbr_mips.c |  4 
>  libavcodec/mips/aacsbr_mips.h |  2 ++
>  libavcodec/mips/ac3dsp_mips.c |  6 +-
>  libavcodec/mips/acelp_filters_mips.c  |  4 
>  libavcodec/mips/acelp_vectors_mips.c  |  4 
>  libavcodec/mips/amrwbdec_mips.c   |  2 ++
>  libavcodec/mips/amrwbdec_mips.h   |  2 ++
>  libavcodec/mips/celp_filters_mips.c   |  4 
>  libavcodec/mips/celp_math_mips.c  |  4 
>  libavcodec/mips/compute_antialias_float.h |  2 ++
>  libavcodec/mips/fft_mips.c|  4 
>  libavcodec/mips/iirfilter_mips.c  |  4 
>  libavcodec/mips/lsp_mips.h|  2 ++
>  libavcodec/mips/mpegaudiodsp_mips_fixed.c | 10 ++
>  libavcodec/mips/mpegaudiodsp_mips_float.c | 10 ++
>  libavcodec/mips/sbrdsp_mips.c |  4 
>  libavutil/mips/float_dsp_mips.c   |  4 
>  21 files changed, 83 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/mips/aaccoder_mips.c b/libavcodec/mips/aaccoder_mips.c
> index 8fbdfd2..d690c8c 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;
> @@ -2477,10 +2478,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;
>  
> @@ -2494,5 +2497,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 c4f6438..758266f 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_MIPS_H */
> diff --git a/libavcodec/mips/aacpsdsp_mips.c b/libavcodec/mips/aacpsdsp_mips.c
> index 695f9ef..83fdc2f 100644
> --- a/libavcodec/mips/aacpsdsp_mips.c
> +++ b/libavcodec/mips/aacpsdsp_mips.c
> @@ -188,6 +188,7 @@ static void ps_hybrid_synthesis_deint_mips(float 
> out[2][38][64],
>  }
>  
>  #if HAVE_MIPSFPU
> +#if !HAVE_MIPS32R6 && !HAVE_MIPS64R6
>  static void ps_add_squares_mips(float *dst, const float (*src)[2], int n)
>  {
>  int i;
> @@ -442,6 +443,7 @@ static void ps_stereo_interpolate_mips(float (*l)[2], 
> float (*r)[2],
>  : "memory"
>  );
>  }
> +#endif /* !HAVE_MIPS32R6 && !HAVE_MIPS64R6 */
>  #endif /* HAVE_MIPSFPU */
>  #endif /* HAVE_INLINE_ASM */
>  
> @@ -451,10 +453,12 @@ void ff_psdsp_init_mips(PSDSPContext *s)
>  s->hybrid_analysis_ileave = ps_hybrid_analysis_ileave_mips;
>  s->hybrid_synthesis_deint = ps_hybrid_synthesis_deint_mips;
>  #if HAVE_MIPSFPU
> +#if !HAVE_MIPS32R6 && !HAVE_MIPS64R6
>  s->add_squares= ps_add_squares_mips;
>  s->mul_pair_single= ps_mul_pair_single_mips;
>  s->decorrelate= ps_decorrelate_mips;
>  s->stereo_interpolate[0]  = ps_stereo_interpolate_mips;
> +#endif /* !HAVE_MIPS32R6 && !HAVE_MIPS64R6 */
>  #endif /* HAVE_MIPSFPU */
>  #endif /* HAVE_INLINE_ASM */
>  }
> diff --git a/libavcodec/mips/aacpsy_mips.h b/libavcodec/mips/aacpsy_mips.h
> index 42ff442..a1fe5cc 100644
> --- a

Re: [FFmpeg-devel] [PATCH] avutil/frame: Assert that width/height/channels is 0 for the destination of av_frame*_ref()

[Clément Bœsch]

On Tue, Mar 08, 2016 at 09:14:58PM +0100, Michael Niedermayer wrote:
> This should detect caes where these functions are called in unclean 
> destinations
> ---
>  libavutil/frame.c |6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 5607206..dde32b0 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -375,6 +375,9 @@ int av_frame_ref(AVFrame *dst, const AVFrame *src)
>  {
>  int i, ret = 0;
>  
> +av_assert0(dst->width == 0 && dst->height == 0);
> +av_assert0(dst->channels == 0);
> +
>  dst->format = src->format;
>  dst->width  = src->width;
>  dst->height = src->height;
> @@ -504,6 +507,9 @@ void av_frame_unref(AVFrame *frame)
>  
>  void av_frame_move_ref(AVFrame *dst, AVFrame *src)
>  {
> +av_assert0(dst->width == 0 && dst->height == 0);
> +av_assert0(dst->channels == 0);
> +
>  *dst = *src;
>  if (src->extended_data == src->data)
>  dst->extended_data = dst->data;

That's a good idea but downstream developers might prefer their users to
experience a memleak that random violent aborts. I would probably make it
at assert level 1.

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] avutil/frame: Assert that width/height/channels is 0 for the destination of av_frame*_ref()

[Nicolas George]

Le decadi 20 ventôse, an CCXXIV, Clement Boesch a écrit :
> That's a good idea but downstream developers might prefer their users to
> experience a memleak that random violent aborts. I would probably make it
> at assert level 1.

Assert level 0 and 1 are equivalent from an API point of view: they both
mean (in this case when testing value provided by the caller) that the
provided value is invalid on pain of undefined behaviour.

On the other hand, this was not currently true nor documented: using these
functions with a destination that contains garbage is not illegal according
with doxy and works currently well. Thing is, currently, users can not have
a frame with garbage unless they do it on purpose: either it contains valid
pointers or it is cleared.

At the very least, this change would require updating the doxy accordingly.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] lavc/lpc: exploit even symmetry of window function

[Rostislav Pehlivanov]

On 9 March 2016 at 07:22, Reimar Döffinger  wrote:

> On 09.03.2016, at 04:16, Ganesh Ajjanagadde  wrote:
>
> > Yields 2x improvement in function performance, and boosts aac encoding
> > speed by ~ 4% overall. Sample benchmark (Haswell+GCC under
> -march=native):
> > after:
> > ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.22s user 0.03s system
> 105% cpu 4.970 total
> >
> > before:
> > ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.40s user 0.05s system
> 105% cpu 5.162 total
> >
> > Big shame that len-1 is -1 mod 4; 0 mod 4 would have yielded a further
> 2x through
> > additional symmetry. Of course, one could approximate with the 0 mod 4
> variant,
> > error would essentially be ~ 1/len in the worst case.
>
> Note that I have no idea why we are using double here (is there a good
> reason?)
> It doesn't really matter for the rest of the code, but cosf is also at
> least twice as fast as cos...
> Probably has smaller error than fudging for symmetry and should be enough
> to push the speed cost of this function close to negligible.


Yes, the reason why double is used is because most of the existing code
worked internally using doubles (though it accepted only integer samples
and did an integer->double conversion when windowing). So only a single
function was needed to actually use the existing code with a float input.
The code already has assembly optimizations, so it should be decently fast.
I'm not sure if templating for doubles and floats would be worth it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/lpc: exploit even symmetry of window function

[Rostislav Pehlivanov]

On 9 March 2016 at 03:16, Ganesh Ajjanagadde  wrote:

> Yields 2x improvement in function performance, and boosts aac encoding
> speed by ~ 4% overall. Sample benchmark (Haswell+GCC under -march=native):
> after:
> ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.22s user 0.03s system
> 105% cpu 4.970 total
>
> before:
> ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.40s user 0.05s system
> 105% cpu 5.162 total
>
> Big shame that len-1 is -1 mod 4; 0 mod 4 would have yielded a further 2x
> through
> additional symmetry. Of course, one could approximate with the 0 mod 4
> variant,
> error would essentially be ~ 1/len in the worst case.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/lpc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/lpc.c b/libavcodec/lpc.c
> index 3839119..052aeaa 100644
> --- a/libavcodec/lpc.c
> +++ b/libavcodec/lpc.c
> @@ -176,9 +176,10 @@ double ff_lpc_calc_ref_coefs_f(LPCContext *s, const
> float *samples, int len,
>  const double a = 0.5f, b = 1.0f - a;
>
>  /* Apply windowing */
> -for (i = 0; i < len; i++) {
> +for (i = 0; i <= len / 2; i++) {
>  double weight = a - b*cos((2*M_PI*i)/(len - 1));
>  s->windowed_samples[i] = weight*samples[i];
> +s->windowed_samples[len-1-i] = weight*samples[len-1-i];
>  }
>
>  s->lpc_compute_autocorr(s->windowed_samples, len, order, autoc);
> --
>

LGTM, doesn't add too much complexity and it does give a slight speedup.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2 2/3] avformat/utils: increase detected start_time with skip_samples

[wm4]

On Tue, 8 Mar 2016 23:44:13 +0100 (CET)
Marton Balint  wrote:

> On Tue, 8 Mar 2016, Hendrik Leppkes wrote:
> 
> > On Tue, Mar 8, 2016 at 10:54 PM, Marton Balint  wrote:  
> >>
> >> On Tue, 8 Mar 2016, wm4 wrote:
> >>  
> >>> On Tue,  8 Mar 2016 21:29:52 +0100
> >>> Marton Balint  wrote:
> >>>  
>  Signed-off-by: Marton Balint 
>  ---
>   libavformat/utils.c   | 10 --
>   tests/ref/fate/gapless2-ipod-aac1 | 72
>  +++
>   tests/ref/fate/gapless2-ipod-aac2 | 72
>  +++
>   3 files changed, 80 insertions(+), 74 deletions(-)
>   
> >>  
> >>> I'm a probably bit late here, but what's the rationale of increasing the
> >>> start time?
> >>>  
> >>
> >> According to docs, start time is supposed to be the pts of the first
> >> decoded frame, therefore skipped samples must be taken into account, when
> >> the start time is determined based on the first packet pts.
> >>  
> >
> > But the skipping is performed by avcodec, not avformat, isn't it?  
> 
> Yes.
> 
> > start_time should be the PTS of the first avpacket coming out of
> > avformat, never mind what a decoder might do to that later.  
> 
> Not according to the docs:
> 
> "AVStream->start_time: decoding: pts of the first frame of the stream in 
> presentation order, in stream time base. Only set this if you are 
> absolutely 100% sure that the value you set it to really is the pts of 
> the first frame."
> 
> If here frame refers to a packet, why the docs is talking about 
> presentation order?
> 
> Also check the libavformat/mp3dec.c, it does the same kind of start_time 
> adjustment based on the skipped samples.

True, with mp3, the first PTS is always 0, and after skipping it will
be some positive value, and start_time is set to the skip duration. Is
this the same here?

Also, what the mp3 demuxer does is not necessarily correct. And
also, what works for audio-only formats isn't necessarily right for if
there are video tracks involved. What I'm really worried about is what
utils.c will determine as total stream start time?

From your added tests it looks like mov.c does now what I'd expect,
though. I just want to be sure this mess doesn't become worse.

Last but not least, why do we have about 3 mechanisms to signal
pre-skip? (Skip side data, skip_samples field, and delay field.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Subtitles for GSoC

[Nicolas George]

Le nonidi 19 ventôse, an CCXXIV, Clement Boesch a écrit :
> I added this task for previous OPW (and maybe GSoC, can't remember). I'm
> unfortunately not available for mentoring (too much time, energy and
> responsibility). Though, I can provide standard help as a developer.

Same goes for me.

> So, yeah, currently the subtitles are decoded into an AVSubtitle
> structure, which hold one or several AVSubtitleRect (AVSubtitle.rects[N]).
> 
> For graphic subtitles, each rectangle contains a paletted buffer and its
> position, size, ...
> 
> For text subtitles, the ass field contains the text in ASS markup: indeed,
> we consider the ASS markup to be the best/least worst superset supporting
> almost every style of every other subtitles formats have, so it's used as
> the "decoded" form for all text subtitles. For example, the SubRip (the
> "codec", or markup you find in SRT files) decoder will transform
> "foo" into "{\i1}foo{\i0}".

There is a serious problem with using a common markup: levels and source of
styling.

ASS has already two levels: style that is directly embedded in the dialog
text as markup, and style that applies to the whole dialog event, selected
by the "style" field. There are extra levels: fallback provided by the
application when the format does not provide styling, an possibly fallback
provided by the library if the application has no fallback. Formats that
rely on CSS for styling may have even more complex structures.

Obviously, handling all this in a completely generic way is not possible.
But at least we should try to achieve that transcoding from a format to a
format with similar capabilities, especially the same format, does not
completely lose the structure.

> - they are defined in libavcodec, and we do not want libavfilter to
>   depend on libavcodec for a core feature (we have a few filters
>   depending on it, but that's optional). As such, libavutil is a much
>   better place for this, which already contains the AVFrame.

Personally, I have no problem about lavfi depending on lavc; I want to merge
all libraries anyway.

> When these issues are sorted out, we can finally work on the integration
> within libavfilter, which is yet another topic where other developers
> might want to comment. Typically, I'm not sure what is the state of
> dealing with the sparse property of the subtitles. Nicolas may know :)

Handling sparse streams should not be that difficult. See below.

> Anyway, there are multiple ways of dealing with the previous mentioned
> issues.
> 
> The first one is to create an AVSubtitle2 or something in libavutil,
> copying most of the current AVSubtitle layout but making sure the user
> allocates it with av_subtitle_alloc() or whatever, so we can add fields
> and extend it (mostly) at will.
> 
> The second one, which I'm currently wondering about these days is to try
> to hold the subtitles data into the existing AVFrame structure. We will
> for example have the frame->extended_data[N] (currently used by audio
> frames to hold the channels) point on a instances of a newly defined
> rectangle structure. Having the subtitles into AVFrame might simplify a
> lot the future integration within libavfilter since they are already
> supported as audio and video.  This needs careful thinking, but it might
> be doable.

I think the AVFrame approach is best, especially for lavfi integration.

Here are the issues I can think of:

1. Sparseness: sparseness is not a problem in itself but a problem when
   connected with continuous streams. For example, imagine you have the
   following subtitles:

   0:01:00 -> 0:01:05 Hello world.
   0:59:00 -> 0:59:05 Good bye.

   and you want to render it on the video. When it gets a frame at 1:06,
   the render filter needs the 59:00 event to know that there is no subtitle
   until then to render. With external subtitles, that is not a problem,
   because it arrives immediately. But if the subtitles are muxed with the
   video, then it will only arrive after 58 minutes of video, which will
   need to be buffered as decoded frames. Completely unrealistic.

   Players get away with it by having interleaving constraints: if video has
   reached timestamp 1:06, then other streams should have reached it, or
   will reach it very soon. Then we only need to buffer a few frames worth
   of video to account for muxing delay.

   We can do the same thing in lavfi using heartbeat frames and a sync
   filter.
   
   A heartbeat frame is a frame that says "we are at pts 1:06 and there is
   nothing new". Pure subtitles filters will just ignore and forward them;
   filters that must sync with a continuous stream use them for progress.

   The heartbeat frames need to be generated. Only the application knows
   where the subtitles come from: demuxed from the same file as the video,
   stand-alone file, etc. We can provide infrastructure to help that as a
   filter with a video and a subtitle input, and a subtitle output: it
   forwards the subtitles unchange

Re: [FFmpeg-devel] [PATCH] avutil/frame: Assert that width/height/channels is 0 for the destination of av_frame*_ref()

[Michael Niedermayer]

On Wed, Mar 09, 2016 at 10:39:36AM +0100, Nicolas George wrote:
> Le decadi 20 ventôse, an CCXXIV, Clement Boesch a écrit :
> > That's a good idea but downstream developers might prefer their users to
> > experience a memleak that random violent aborts. I would probably make it
> > at assert level 1.
> 
> Assert level 0 and 1 are equivalent from an API point of view: they both
> mean (in this case when testing value provided by the caller) that the
> provided value is invalid on pain of undefined behaviour.
> 
> On the other hand, this was not currently true nor documented: using these
> functions with a destination that contains garbage is not illegal according
> with doxy and works currently well. Thing is, currently, users can not have
> a frame with garbage unless they do it on purpose: either it contains valid
> pointers or it is cleared.
> 

> At the very least, this change would require updating the doxy accordingly.

wm4 posted a patch to document the undefied-ness of this
0301 19:21 wm4 (2.4K) ├─>[FFmpeg-devel] [PATCH 1/6] lavu: improve 
documentation of some AVFrame functions

is that sufficient, or should further documentation be added ?

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] avutil/frame: Assert that width/height/channels is 0 for the destination of av_frame*_ref()

[Michael Niedermayer]

On Wed, Mar 09, 2016 at 10:27:50AM +0100, Clément Bœsch wrote:
> On Tue, Mar 08, 2016 at 09:14:58PM +0100, Michael Niedermayer wrote:
> > This should detect caes where these functions are called in unclean 
> > destinations
> > ---
> >  libavutil/frame.c |6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/libavutil/frame.c b/libavutil/frame.c
> > index 5607206..dde32b0 100644
> > --- a/libavutil/frame.c
> > +++ b/libavutil/frame.c
> > @@ -375,6 +375,9 @@ int av_frame_ref(AVFrame *dst, const AVFrame *src)
> >  {
> >  int i, ret = 0;
> >  
> > +av_assert0(dst->width == 0 && dst->height == 0);
> > +av_assert0(dst->channels == 0);
> > +
> >  dst->format = src->format;
> >  dst->width  = src->width;
> >  dst->height = src->height;
> > @@ -504,6 +507,9 @@ void av_frame_unref(AVFrame *frame)
> >  
> >  void av_frame_move_ref(AVFrame *dst, AVFrame *src)
> >  {
> > +av_assert0(dst->width == 0 && dst->height == 0);
> > +av_assert0(dst->channels == 0);
> > +
> >  *dst = *src;
> >  if (src->extended_data == src->data)
> >  dst->extended_data = dst->data;
> 
> That's a good idea but downstream developers might prefer their users to
> experience a memleak that random violent aborts. I would probably make it
> at assert level 1.

locally changed

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

Re: [FFmpeg-devel] [PATCH] avutil/frame: Assert that width/height/channels is 0 for the destination of av_frame*_ref()

[Nicolas George]

Le decadi 20 ventôse, an CCXXIV, Michael Niedermayer a écrit :
> wm4 posted a patch to document the undefied-ness of this
> 0301 19:21 wm4 (2.4K) ├─>[FFmpeg-devel] [PATCH 1/6] lavu: improve 
> documentation of some AVFrame functions
> 
> is that sufficient, or should further documentation be added ?

With that change, I have no objection.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] lavc/lpc: exploit even symmetry of window function

[Michael Niedermayer]

On Tue, Mar 08, 2016 at 10:16:50PM -0500, Ganesh Ajjanagadde wrote:
> Yields 2x improvement in function performance, and boosts aac encoding
> speed by ~ 4% overall. Sample benchmark (Haswell+GCC under -march=native):
> after:
> ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.22s user 0.03s system 105% 
> cpu 4.970 total
> 
> before:
> ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.40s user 0.05s system 105% 
> cpu 5.162 total
> 
> Big shame that len-1 is -1 mod 4; 0 mod 4 would have yielded a further 2x 
> through
> additional symmetry. Of course, one could approximate with the 0 mod 4 
> variant,
> error would essentially be ~ 1/len in the worst case.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/lpc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/lpc.c b/libavcodec/lpc.c
> index 3839119..052aeaa 100644
> --- a/libavcodec/lpc.c
> +++ b/libavcodec/lpc.c
> @@ -176,9 +176,10 @@ double ff_lpc_calc_ref_coefs_f(LPCContext *s, const 
> float *samples, int len,
>  const double a = 0.5f, b = 1.0f - a;
>  
>  /* Apply windowing */
> -for (i = 0; i < len; i++) {
> +for (i = 0; i <= len / 2; i++) {

>  double weight = a - b*cos((2*M_PI*i)/(len - 1));

the windows should not be recalcuated for each frame. But either
calculated once during init or calculated at first use if that makes
sense

actually i suspect there should be close to 0 calls to libc math
functions after init in the encoder, or is there some use of these
functions in aac that cannot be replaced by a simple table?

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

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


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

Re: [FFmpeg-devel] [PATCH] lavf/avidec: Skip xxpc entries in index

[Mats Peterson]

On 03/09/2016 02:54 AM, Mats Peterson wrote:

Interim fix of the parsing of idx1 indexes with 'xxpc' (palette change)
entries.

Implementation of 'xxpc' index entry storage for seeking will come in
the future (provided I can manage it).

Test file TOON.AVI from King's Quest VI with indexed 'xxpc' chunks which
would previously cause "stream_ptr out of bounds" error messages to be
emitted in the msvideo1 decoder:

https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU

Mats






Fixes ticket #5311 filed by me, Carl Eugen.

Mats

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

Re: [FFmpeg-devel] [PATCH] lavf/avidec: Skip xxpc entries in index

[Michael Niedermayer]

On Wed, Mar 09, 2016 at 01:20:13PM +0100, Mats Peterson wrote:
> On 03/09/2016 02:54 AM, Mats Peterson wrote:
> >Interim fix of the parsing of idx1 indexes with 'xxpc' (palette change)
> >entries.
> >
> >Implementation of 'xxpc' index entry storage for seeking will come in
> >the future (provided I can manage it).
> >
> >Test file TOON.AVI from King's Quest VI with indexed 'xxpc' chunks which
> >would previously cause "stream_ptr out of bounds" error messages to be
> >emitted in the msvideo1 decoder:
> >
> >https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU
> >
> >Mats
> >
> >
> >
> 
> 

> Fixes ticket #5311 filed by me, Carl Eugen.

please add this to the commit message then

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

No great genius has ever existed without some touch of madness. -- 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] lavf/avidec: Skip xxpc entries in index

[Mats Peterson]

On 03/09/2016 01:43 PM, Michael Niedermayer wrote:

On Wed, Mar 09, 2016 at 01:20:13PM +0100, Mats Peterson wrote:

On 03/09/2016 02:54 AM, Mats Peterson wrote:

Interim fix of the parsing of idx1 indexes with 'xxpc' (palette change)
entries.

Implementation of 'xxpc' index entry storage for seeking will come in
the future (provided I can manage it).

Test file TOON.AVI from King's Quest VI with indexed 'xxpc' chunks which
would previously cause "stream_ptr out of bounds" error messages to be
emitted in the msvideo1 decoder:

https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU

Mats









Fixes ticket #5311 filed by me, Carl Eugen.


please add this to the commit message then

[...]



-

OK, thanks.

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

[FFmpeg-devel] [PATCH] lavf/avidec: Skip xxpc entries in index; fixes trac #5311

[Mats Peterson]

Interim fix of the parsing of idx1 indexes with 'xxpc' (palette change) 
entries.


Implementation of 'xxpc' index entry storage for seeking will come in 
the future (provided I can manage it).


Test file TOON.AVI from King's Quest VI with indexed 'xxpc' chunks which 
would previously cause "stream_ptr out of bounds" error messages to be 
emitted in the msvideo1 decoder:


https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 956242f96307f3b145c3570bccf250299a455e59 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Wed, 9 Mar 2016 02:44:55 +0100
Subject: [PATCH] lavf/avidec: Skip xxpc entries in index; fixes trac #5311

---
 libavformat/avidec.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index eaf8421..49c97d9 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -1581,6 +1581,9 @@ static int avi_read_idx1(AVFormatContext *s, int size)
 st  = s->streams[index];
 ast = st->priv_data;
 
+if ((tag >> 16 & 0xff) == 'p' && (tag >> 24 & 0xff) == 'c')
+continue;
+
 if (first_packet && first_packet_pos) {
 if (avi->movi_list + 4 != pos || pos + 500 > first_packet_pos)
 data_offset  = first_packet_pos - pos;
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH]lavc/hevc_ps: Fix offset for yuv422 and yuv444

[Carl Eugen Hoyos]

Ronald S. Bultje  gmail.com> writes:

> > > That fixes 444, but not 422. For 422 (idc_fmt=2), horiz_mult (for l/r)
> > > should be 2, but vert_mult (for t/b) should be 1.
> >
> > New patch attached.
> 
> lgtm (I think).

Patch applied.

Thank you for your help, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH]lavc/mjpegdec: Set sar for multiscope videos

[Carl Eugen Hoyos]

Michael Niedermayer  niedermayer.cc> writes:

> >  mjpegdec.c |4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 88ce4aaf4530ae0442cb76b6659bec1332c9e5a8  patchmultiscopesar.diff
> > diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
> 
> probably ok

Patch applied.

Thank you, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH]lavf/mpeg: Identify sub-stream ID 0xa1 as mlp

[Carl Eugen Hoyos]

Michael Niedermayer  niedermayer.cc> writes:

> >  mpeg.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 441c00cda76c5f59b560517115ad1677ab8061bd  patchmpegmlp.diff
> > diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c
> > index 787d5f0..2f48459 100644
> 
> if that works and no better way is known then it should be ok

Patch applied.

Thank you, Carl Eugen

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

[FFmpeg-devel] [PATCH]lavf/mxfdec: Support canopus codecs

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #5316 here.
I unfortunately have no idea what the hunk in mxf_read_header() 
does, decoding works fine without it.

Please comment, Carl Eugen
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index f4222fc..3c43968 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -283,6 +283,7 @@ static int mxf_read_close(AVFormatContext *s);
 static const uint8_t mxf_header_partition_pack_key[]   = { 
0x06,0x0e,0x2b,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x02 };
 static const uint8_t mxf_essence_element_key[] = { 
0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01 };
 static const uint8_t mxf_avid_essence_element_key[]= { 
0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0e,0x04,0x03,0x01 };
+static const uint8_t mxf_canopus_essence_element_key[] = { 
0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x0a,0x0e,0x0f,0x03,0x01,0x15,0x01,0x05 };
 static const uint8_t mxf_system_item_key[] = { 
0x06,0x0e,0x2b,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x03,0x01,0x04 };
 static const uint8_t mxf_klv_key[] = { 
0x06,0x0e,0x2b,0x34 };
 /* complete keys to match */
@@ -1128,6 +1129,8 @@ static const MXFCodecUL 
mxf_picture_essence_container_uls[] = {
 { { 
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x01,0x04,0x01 
}, 14, AV_CODEC_ID_MPEG2VIDEO }, /* Type D-10 mapping of 40Mbps 525/60-I */
 { { 
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x02,0x41,0x01 
}, 14,AV_CODEC_ID_DVVIDEO }, /* DV 625 25mbps */
 { { 
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x05,0x00,0x00 
}, 14,   AV_CODEC_ID_RAWVIDEO }, /* Uncompressed Picture */
+{ { 
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0a,0x0e,0x0f,0x03,0x01,0x02,0x20,0x01,0x01 
}, 15, AV_CODEC_ID_HQ_HQA },
+{ { 
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0a,0x0e,0x0f,0x03,0x01,0x02,0x20,0x02,0x01 
}, 15,AV_CODEC_ID_HQX },
 { { 
0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0xff,0x4b,0x46,0x41,0x41,0x00,0x0d,0x4d,0x4f 
}, 14,   AV_CODEC_ID_RAWVIDEO }, /* Legacy ?? Uncompressed Picture */
 { { 
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 
},  0,  AV_CODEC_ID_NONE },
 };
@@ -2734,6 +2737,7 @@ static int mxf_read_header(AVFormatContext *s)
 av_log(s, AV_LOG_TRACE, "size %"PRIu64" offset %#"PRIx64"\n", 
klv.length, klv.offset);
 if (IS_KLV_KEY(klv.key, mxf_encrypted_triplet_key) ||
 IS_KLV_KEY(klv.key, mxf_essence_element_key) ||
+IS_KLV_KEY(klv.key, mxf_canopus_essence_element_key) ||
 IS_KLV_KEY(klv.key, mxf_avid_essence_element_key) ||
 IS_KLV_KEY(klv.key, mxf_system_item_key)) {
 
@@ -2952,6 +2956,7 @@ static int mxf_read_packet_old(AVFormatContext *s, 
AVPacket *pkt)
 return 0;
 }
 if (IS_KLV_KEY(klv.key, mxf_essence_element_key) ||
+IS_KLV_KEY(klv.key, mxf_canopus_essence_element_key) ||
 IS_KLV_KEY(klv.key, mxf_avid_essence_element_key)) {
 int index = mxf_get_stream_index(s, &klv);
 int64_t next_ofs, next_klv;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avutil/file: Move av_tempfile() to avutil/file_open ff_tempfile()

[Michael Niedermayer]

document the issue with av_tempfile()

Signed-off-by: Michael Niedermayer 
---
 libavcodec/libxvid.h  |2 --
 libavutil/file.c  |   48 ++--
 libavutil/file.h  |1 +
 libavutil/file_open.c |   59 +
 libavutil/internal.h  |   14 
 5 files changed, 76 insertions(+), 48 deletions(-)

diff --git a/libavcodec/libxvid.h b/libavcodec/libxvid.h
index bffe07d..ef9a5a9 100644
--- a/libavcodec/libxvid.h
+++ b/libavcodec/libxvid.h
@@ -26,6 +26,4 @@
  * common functions for use with the Xvid wrappers
  */
 
-int ff_tempfile(const char *prefix, char **filename);
-
 #endif /* AVCODEC_LIBXVID_H */
diff --git a/libavutil/file.c b/libavutil/file.c
index 2a06be4..25381b1 100644
--- a/libavutil/file.c
+++ b/libavutil/file.c
@@ -137,52 +137,8 @@ void av_file_unmap(uint8_t *bufptr, size_t size)
 #endif
 }
 
-int av_tempfile(const char *prefix, char **filename, int log_offset, void 
*log_ctx)
-{
-FileLogContext file_log_ctx = { &file_log_ctx_class, log_offset, log_ctx };
-int fd = -1;
-#if !HAVE_MKSTEMP
-void *ptr= tempnam(NULL, prefix);
-if(!ptr)
-ptr= tempnam(".", prefix);
-*filename = av_strdup(ptr);
-#undef free
-free(ptr);
-#else
-size_t len = strlen(prefix) + 12; /* room for "/tmp/" and "XX\0" */
-*filename  = av_malloc(len);
-#endif
-/* -common section-*/
-if (!*filename) {
-av_log(&file_log_ctx, AV_LOG_ERROR, "ff_tempfile: Cannot allocate file 
name\n");
-return AVERROR(ENOMEM);
-}
-#if !HAVE_MKSTEMP
-#   ifndef O_BINARY
-#   define O_BINARY 0
-#   endif
-#   ifndef O_EXCL
-#   define O_EXCL 0
-#   endif
-fd = open(*filename, O_RDWR | O_BINARY | O_CREAT | O_EXCL, 0600);
-#else
-snprintf(*filename, len, "/tmp/%sXX", prefix);
-fd = mkstemp(*filename);
-#ifdef _WIN32
-if (fd < 0) {
-snprintf(*filename, len, "./%sXX", prefix);
-fd = mkstemp(*filename);
-}
-#endif
-#endif
-/* -common section-*/
-if (fd < 0) {
-int err = AVERROR(errno);
-av_log(&file_log_ctx, AV_LOG_ERROR, "ff_tempfile: Cannot open 
temporary file %s\n", *filename);
-av_freep(filename);
-return err;
-}
-return fd; /* success */
+int av_tempfile(const char *prefix, char **filename, int log_offset, void 
*log_ctx) {
+return avpriv_tempfile(prefix, filename, log_offset, log_ctx);
 }
 
 #ifdef TEST
diff --git a/libavutil/file.h b/libavutil/file.h
index e931be7..8666c7b 100644
--- a/libavutil/file.h
+++ b/libavutil/file.h
@@ -62,6 +62,7 @@ void av_file_unmap(uint8_t *bufptr, size_t size);
  * @note On very old libcs it is necessary to set a secure umask before
  *   calling this, av_tempfile() can't call umask itself as it is used in
  *   libraries and could interfere with the calling application.
+ * @deprecated as fd numbers cannot be passed saftely between libs on some 
platforms
  */
 int av_tempfile(const char *prefix, char **filename, int log_offset, void 
*log_ctx);
 
diff --git a/libavutil/file_open.c b/libavutil/file_open.c
index 9e76127..6e58cc1 100644
--- a/libavutil/file_open.c
+++ b/libavutil/file_open.c
@@ -92,6 +92,65 @@ int avpriv_open(const char *filename, int flags, ...)
 return fd;
 }
 
+typedef struct FileLogContext {
+const AVClass *class;
+int   log_offset;
+void *log_ctx;
+} FileLogContext;
+
+static const AVClass file_log_ctx_class = {
+"TEMPFILE", av_default_item_name, NULL, LIBAVUTIL_VERSION_INT,
+offsetof(FileLogContext, log_offset), offsetof(FileLogContext, log_ctx)
+};
+
+int avpriv_tempfile(const char *prefix, char **filename, int log_offset, void 
*log_ctx)
+{
+FileLogContext file_log_ctx = { &file_log_ctx_class, log_offset, log_ctx };
+int fd = -1;
+#if !HAVE_MKSTEMP
+void *ptr= tempnam(NULL, prefix);
+if(!ptr)
+ptr= tempnam(".", prefix);
+*filename = av_strdup(ptr);
+#undef free
+free(ptr);
+#else
+size_t len = strlen(prefix) + 12; /* room for "/tmp/" and "XX\0" */
+*filename  = av_malloc(len);
+#endif
+/* -common section-*/
+if (!*filename) {
+av_log(&file_log_ctx, AV_LOG_ERROR, "ff_tempfile: Cannot allocate file 
name\n");
+return AVERROR(ENOMEM);
+}
+#if !HAVE_MKSTEMP
+#   ifndef O_BINARY
+#   define O_BINARY 0
+#   endif
+#   ifndef O_EXCL
+#   define O_EXCL 0
+#   endif
+fd = open(*filename, O_RDWR | O_BINARY | O_CREAT | O_EXCL, 0600);
+#else
+snprintf(*filename, len, "/tmp/%sXX", prefix);
+fd = mkstemp(*filename);
+#ifdef _WIN32
+if (fd < 0) {
+snprintf(*filename, len, "./%sXX", prefix);
+fd = mkstemp(*filename);
+}
+#endif
+#endif
+/* -common section-*/
+if (fd < 0) {
+int err = AVERROR(errno);
+av_log(&file_log_ctx, AV_LOG_ERROR, "ff_tempfile: Cannot open 
temporary file %s\n", *filename);
+av_freep(filename);
+return er

[FFmpeg-devel] [PATCH 2/2] Use avpriv_tempfile()

[Michael Niedermayer]

Should fix xvid/cache on windows with --enable-shared

Signed-off-by: Michael Niedermayer 
---
 libavcodec/libxvid.c|2 +-
 libavcodec/libxvid_rc.c |4 ++--
 libavformat/cache.c |4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavcodec/libxvid.c b/libavcodec/libxvid.c
index 6fd4e16..76e725e 100644
--- a/libavcodec/libxvid.c
+++ b/libavcodec/libxvid.c
@@ -541,7 +541,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 rc2pass2.version = XVID_VERSION;
 rc2pass2.bitrate = avctx->bit_rate;
 
-fd = av_tempfile("xvidff.", &x->twopassfile, 0, avctx);
+fd = avpriv_tempfile("xvidff.", &x->twopassfile, 0, avctx);
 if (fd < 0) {
 av_log(avctx, AV_LOG_ERROR, "Xvid: Cannot write 2-pass pipe\n");
 return fd;
diff --git a/libavcodec/libxvid_rc.c b/libavcodec/libxvid_rc.c
index 0fd030c..0e25a07 100644
--- a/libavcodec/libxvid_rc.c
+++ b/libavcodec/libxvid_rc.c
@@ -33,7 +33,7 @@
 #include 
 
 #include "libavutil/attributes.h"
-#include "libavutil/file.h"
+#include "libavutil/internal.h"
 
 #include "avcodec.h"
 #include "libxvid.h"
@@ -46,7 +46,7 @@ av_cold int ff_xvid_rate_control_init(MpegEncContext *s)
 xvid_plg_create_t xvid_plg_create = { 0 };
 xvid_plugin_2pass2_t xvid_2pass2  = { 0 };
 
-fd = av_tempfile("xvidrc.", &tmp_name, 0, s->avctx);
+fd = avpriv_tempfile("xvidrc.", &tmp_name, 0, s->avctx);
 if (fd < 0) {
 av_log(NULL, AV_LOG_ERROR, "Can't create temporary pass2 file.\n");
 return fd;
diff --git a/libavformat/cache.c b/libavformat/cache.c
index 1d26cb8..25b28d5 100644
--- a/libavformat/cache.c
+++ b/libavformat/cache.c
@@ -29,7 +29,7 @@
 
 #include "libavutil/avassert.h"
 #include "libavutil/avstring.h"
-#include "libavutil/file.h"
+#include "libavutil/internal.h"
 #include "libavutil/opt.h"
 #include "libavutil/tree.h"
 #include "avformat.h"
@@ -77,7 +77,7 @@ static int cache_open(URLContext *h, const char *arg, int 
flags, AVDictionary **
 
 av_strstart(arg, "cache:", &arg);
 
-c->fd = av_tempfile("ffcache", &buffername, 0, h);
+c->fd = avpriv_tempfile("ffcache", &buffername, 0, h);
 if (c->fd < 0){
 av_log(h, AV_LOG_ERROR, "Failed to create tempfile\n");
 return c->fd;
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH 2/2] Use avpriv_tempfile()

[Carl Eugen Hoyos]

Michael Niedermayer  niedermayer.cc> writes:

> Should fix xvid/cache on windows with --enable-shared

Is this related to ticket #4780?
--enabled-shared is not mentioned there.

Carl Eugen

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

[FFmpeg-devel] [PATCH] Attempt to fix av_fopen_utf8() use in ffmpeg on windows

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 Makefile  |1 +
 file_open.c   |1 +
 tests/ref/fate/source |1 +
 3 files changed, 3 insertions(+)
 create mode 100644 file_open.c

diff --git a/Makefile b/Makefile
index 87a9869..0193960 100644
--- a/Makefile
+++ b/Makefile
@@ -28,6 +28,7 @@ ALLAVPROGS_G = $(AVBASENAMES:%=%$(PROGSSUF)_g$(EXESUF))
 
 $(foreach prog,$(AVBASENAMES),$(eval OBJS-$(prog) += cmdutils.o))
 $(foreach prog,$(AVBASENAMES),$(eval OBJS-$(prog)-$(CONFIG_OPENCL) += 
cmdutils_opencl.o))
+$(foreach prog,$(AVBASENAMES),$(eval OBJS-$(prog)-$(HAVE_LIBC_MSVCRT) += 
file_open.o))
 
 OBJS-ffmpeg   += ffmpeg_opt.o ffmpeg_filter.o
 OBJS-ffmpeg-$(HAVE_VDPAU_X11) += ffmpeg_vdpau.o
diff --git a/file_open.c b/file_open.c
new file mode 100644
index 000..494a5d3
--- /dev/null
+++ b/file_open.c
@@ -0,0 +1 @@
+#include "libavutil/file_open.c"
diff --git a/tests/ref/fate/source b/tests/ref/fate/source
index ec0a98e..40c96b3 100644
--- a/tests/ref/fate/source
+++ b/tests/ref/fate/source
@@ -2,6 +2,7 @@ Files without standard license headers:
 cmdutils_common_opts.h
 compat/avisynth/windowsPorts/basicDataTypeConversions.h
 compat/avisynth/windowsPorts/windows2linux.h
+file_open.c
 libavcodec/file_open.c
 libavcodec/interplayacm.c
 libavcodec/log2_tab.c
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH] Add tests for functions in hash.c

[NagaChaitanya Vellanki]

I wont qualify for GSoC because i am full time employed and a part time
student.

Thank you,
Naga

On Sun, Mar 6, 2016 at 3:26 PM, Michael Niedermayer 
wrote:

> On Sun, Mar 06, 2016 at 11:27:59AM -0800, NagaChaitanya Vellanki wrote:
> > Please review the patch.
> >
> > NagaChaitanya Vellanki (1):
> >   Add tests for functions in hash.c
>
> btw, if this is a qualification task for GSoC or Outreachy then
> please add yourself to
> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016-Qualis
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No snowflake in an avalanche ever feels responsible. -- Voltaire
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] Use avpriv_tempfile()

[Michael Niedermayer]

On Wed, Mar 09, 2016 at 02:43:22PM +, Carl Eugen Hoyos wrote:
> Michael Niedermayer  niedermayer.cc> writes:
> 
> > Should fix xvid/cache on windows with --enable-shared
> 
> Is this related to ticket #4780?
> --enabled-shared is not mentioned there.

i dont know

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


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

Re: [FFmpeg-devel] [PATCH 1/2] avutil/file: Move av_tempfile() to avutil/file_open ff_tempfile()

[Hendrik Leppkes]

On Wed, Mar 9, 2016 at 3:37 PM, Michael Niedermayer
 wrote:
> document the issue with av_tempfile()
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/libxvid.h  |2 --
>  libavutil/file.c  |   48 ++--
>  libavutil/file.h  |1 +
>  libavutil/file_open.c |   59 
> +
>  libavutil/internal.h  |   14 
>  5 files changed, 76 insertions(+), 48 deletions(-)
>
> diff --git a/libavcodec/libxvid.h b/libavcodec/libxvid.h
> index bffe07d..ef9a5a9 100644
> --- a/libavcodec/libxvid.h
> +++ b/libavcodec/libxvid.h
> @@ -26,6 +26,4 @@
>   * common functions for use with the Xvid wrappers
>   */
>
> -int ff_tempfile(const char *prefix, char **filename);
> -
>  #endif /* AVCODEC_LIBXVID_H */
> diff --git a/libavutil/file.c b/libavutil/file.c
> index 2a06be4..25381b1 100644
> --- a/libavutil/file.c
> +++ b/libavutil/file.c
> @@ -137,52 +137,8 @@ void av_file_unmap(uint8_t *bufptr, size_t size)
>  #endif
>  }
>
> -int av_tempfile(const char *prefix, char **filename, int log_offset, void 
> *log_ctx)
> -{
> -FileLogContext file_log_ctx = { &file_log_ctx_class, log_offset, log_ctx 
> };
> -int fd = -1;
> -#if !HAVE_MKSTEMP
> -void *ptr= tempnam(NULL, prefix);
> -if(!ptr)
> -ptr= tempnam(".", prefix);
> -*filename = av_strdup(ptr);
> -#undef free
> -free(ptr);
> -#else
> -size_t len = strlen(prefix) + 12; /* room for "/tmp/" and "XX\0" */
> -*filename  = av_malloc(len);
> -#endif
> -/* -common section-*/
> -if (!*filename) {
> -av_log(&file_log_ctx, AV_LOG_ERROR, "ff_tempfile: Cannot allocate 
> file name\n");
> -return AVERROR(ENOMEM);
> -}
> -#if !HAVE_MKSTEMP
> -#   ifndef O_BINARY
> -#   define O_BINARY 0
> -#   endif
> -#   ifndef O_EXCL
> -#   define O_EXCL 0
> -#   endif
> -fd = open(*filename, O_RDWR | O_BINARY | O_CREAT | O_EXCL, 0600);
> -#else
> -snprintf(*filename, len, "/tmp/%sXX", prefix);
> -fd = mkstemp(*filename);
> -#ifdef _WIN32
> -if (fd < 0) {
> -snprintf(*filename, len, "./%sXX", prefix);
> -fd = mkstemp(*filename);
> -}
> -#endif
> -#endif
> -/* -common section-*/
> -if (fd < 0) {
> -int err = AVERROR(errno);
> -av_log(&file_log_ctx, AV_LOG_ERROR, "ff_tempfile: Cannot open 
> temporary file %s\n", *filename);
> -av_freep(filename);
> -return err;
> -}
> -return fd; /* success */
> +int av_tempfile(const char *prefix, char **filename, int log_offset, void 
> *log_ctx) {
> +return avpriv_tempfile(prefix, filename, log_offset, log_ctx);
>  }
>
>  #ifdef TEST
> diff --git a/libavutil/file.h b/libavutil/file.h
> index e931be7..8666c7b 100644
> --- a/libavutil/file.h
> +++ b/libavutil/file.h
> @@ -62,6 +62,7 @@ void av_file_unmap(uint8_t *bufptr, size_t size);
>   * @note On very old libcs it is necessary to set a secure umask before
>   *   calling this, av_tempfile() can't call umask itself as it is used in
>   *   libraries and could interfere with the calling application.
> + * @deprecated as fd numbers cannot be passed saftely between libs on some 
> platforms
>   */
>  int av_tempfile(const char *prefix, char **filename, int log_offset, void 
> *log_ctx);
>
> diff --git a/libavutil/file_open.c b/libavutil/file_open.c
> index 9e76127..6e58cc1 100644
> --- a/libavutil/file_open.c
> +++ b/libavutil/file_open.c
> @@ -92,6 +92,65 @@ int avpriv_open(const char *filename, int flags, ...)
>  return fd;
>  }
>
> +typedef struct FileLogContext {
> +const AVClass *class;
> +int   log_offset;
> +void *log_ctx;
> +} FileLogContext;
> +
> +static const AVClass file_log_ctx_class = {
> +"TEMPFILE", av_default_item_name, NULL, LIBAVUTIL_VERSION_INT,
> +offsetof(FileLogContext, log_offset), offsetof(FileLogContext, log_ctx)
> +};
> +
> +int avpriv_tempfile(const char *prefix, char **filename, int log_offset, 
> void *log_ctx)
> +{
> +FileLogContext file_log_ctx = { &file_log_ctx_class, log_offset, log_ctx 
> };
> +int fd = -1;
> +#if !HAVE_MKSTEMP
> +void *ptr= tempnam(NULL, prefix);
> +if(!ptr)
> +ptr= tempnam(".", prefix);
> +*filename = av_strdup(ptr);
> +#undef free
> +free(ptr);
> +#else
> +size_t len = strlen(prefix) + 12; /* room for "/tmp/" and "XX\0" */
> +*filename  = av_malloc(len);
> +#endif
> +/* -common section-*/
> +if (!*filename) {
> +av_log(&file_log_ctx, AV_LOG_ERROR, "ff_tempfile: Cannot allocate 
> file name\n");
> +return AVERROR(ENOMEM);
> +}
> +#if !HAVE_MKSTEMP
> +#   ifndef O_BINARY
> +#   define O_BINARY 0
> +#   endif
> +#   ifndef O_EXCL
> +#   define O_EXCL 0
> +#   endif
> +fd = open(*filename, O_RDWR | O_BINARY | O_CREAT | O_EXCL, 0600);
> +#else
> +snprintf(*filename, len, "/tmp/%sXX", prefix);
> +fd = mkstemp(*filename);
> +#ifdef _WIN32
> +if (fd 

Re: [FFmpeg-devel] [PATCH 1/2] avutil/file: Move av_tempfile() to avutil/file_open ff_tempfile()

[Michael Niedermayer]

On Wed, Mar 09, 2016 at 04:27:12PM +0100, Hendrik Leppkes wrote:
> On Wed, Mar 9, 2016 at 3:37 PM, Michael Niedermayer
>  wrote:
> > document the issue with av_tempfile()
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/libxvid.h  |2 --
> >  libavutil/file.c  |   48 ++--
> >  libavutil/file.h  |1 +
> >  libavutil/file_open.c |   59 
> > +
> >  libavutil/internal.h  |   14 
> >  5 files changed, 76 insertions(+), 48 deletions(-)
> >
> > diff --git a/libavcodec/libxvid.h b/libavcodec/libxvid.h
> > index bffe07d..ef9a5a9 100644
> > --- a/libavcodec/libxvid.h
> > +++ b/libavcodec/libxvid.h
> > @@ -26,6 +26,4 @@
> >   * common functions for use with the Xvid wrappers
> >   */
> >
> > -int ff_tempfile(const char *prefix, char **filename);
> > -
> >  #endif /* AVCODEC_LIBXVID_H */
> > diff --git a/libavutil/file.c b/libavutil/file.c
> > index 2a06be4..25381b1 100644
> > --- a/libavutil/file.c
> > +++ b/libavutil/file.c
> > @@ -137,52 +137,8 @@ void av_file_unmap(uint8_t *bufptr, size_t size)
> >  #endif
> >  }
> >
> > -int av_tempfile(const char *prefix, char **filename, int log_offset, void 
> > *log_ctx)
> > -{
> > -FileLogContext file_log_ctx = { &file_log_ctx_class, log_offset, 
> > log_ctx };
> > -int fd = -1;
> > -#if !HAVE_MKSTEMP
> > -void *ptr= tempnam(NULL, prefix);
> > -if(!ptr)
> > -ptr= tempnam(".", prefix);
> > -*filename = av_strdup(ptr);
> > -#undef free
> > -free(ptr);
> > -#else
> > -size_t len = strlen(prefix) + 12; /* room for "/tmp/" and "XX\0" */
> > -*filename  = av_malloc(len);
> > -#endif
> > -/* -common section-*/
> > -if (!*filename) {
> > -av_log(&file_log_ctx, AV_LOG_ERROR, "ff_tempfile: Cannot allocate 
> > file name\n");
> > -return AVERROR(ENOMEM);
> > -}
> > -#if !HAVE_MKSTEMP
> > -#   ifndef O_BINARY
> > -#   define O_BINARY 0
> > -#   endif
> > -#   ifndef O_EXCL
> > -#   define O_EXCL 0
> > -#   endif
> > -fd = open(*filename, O_RDWR | O_BINARY | O_CREAT | O_EXCL, 0600);
> > -#else
> > -snprintf(*filename, len, "/tmp/%sXX", prefix);
> > -fd = mkstemp(*filename);
> > -#ifdef _WIN32
> > -if (fd < 0) {
> > -snprintf(*filename, len, "./%sXX", prefix);
> > -fd = mkstemp(*filename);
> > -}
> > -#endif
> > -#endif
> > -/* -common section-*/
> > -if (fd < 0) {
> > -int err = AVERROR(errno);
> > -av_log(&file_log_ctx, AV_LOG_ERROR, "ff_tempfile: Cannot open 
> > temporary file %s\n", *filename);
> > -av_freep(filename);
> > -return err;
> > -}
> > -return fd; /* success */
> > +int av_tempfile(const char *prefix, char **filename, int log_offset, void 
> > *log_ctx) {
> > +return avpriv_tempfile(prefix, filename, log_offset, log_ctx);
> >  }
> >
> >  #ifdef TEST
> > diff --git a/libavutil/file.h b/libavutil/file.h
> > index e931be7..8666c7b 100644
> > --- a/libavutil/file.h
> > +++ b/libavutil/file.h
> > @@ -62,6 +62,7 @@ void av_file_unmap(uint8_t *bufptr, size_t size);
> >   * @note On very old libcs it is necessary to set a secure umask before
> >   *   calling this, av_tempfile() can't call umask itself as it is used 
> > in
> >   *   libraries and could interfere with the calling application.
> > + * @deprecated as fd numbers cannot be passed saftely between libs on some 
> > platforms
> >   */
> >  int av_tempfile(const char *prefix, char **filename, int log_offset, void 
> > *log_ctx);
> >
> > diff --git a/libavutil/file_open.c b/libavutil/file_open.c
> > index 9e76127..6e58cc1 100644
> > --- a/libavutil/file_open.c
> > +++ b/libavutil/file_open.c
> > @@ -92,6 +92,65 @@ int avpriv_open(const char *filename, int flags, ...)
> >  return fd;
> >  }
> >
> > +typedef struct FileLogContext {
> > +const AVClass *class;
> > +int   log_offset;
> > +void *log_ctx;
> > +} FileLogContext;
> > +
> > +static const AVClass file_log_ctx_class = {
> > +"TEMPFILE", av_default_item_name, NULL, LIBAVUTIL_VERSION_INT,
> > +offsetof(FileLogContext, log_offset), offsetof(FileLogContext, log_ctx)
> > +};
> > +
> > +int avpriv_tempfile(const char *prefix, char **filename, int log_offset, 
> > void *log_ctx)
> > +{
> > +FileLogContext file_log_ctx = { &file_log_ctx_class, log_offset, 
> > log_ctx };
> > +int fd = -1;
> > +#if !HAVE_MKSTEMP
> > +void *ptr= tempnam(NULL, prefix);
> > +if(!ptr)
> > +ptr= tempnam(".", prefix);
> > +*filename = av_strdup(ptr);
> > +#undef free
> > +free(ptr);
> > +#else
> > +size_t len = strlen(prefix) + 12; /* room for "/tmp/" and "XX\0" */
> > +*filename  = av_malloc(len);
> > +#endif
> > +/* -common section-*/
> > +if (!*filename) {
> > +av_log(&file_log_ctx, AV_LOG_ERROR, "ff_tempfile: Cannot allocate 
> > file name\n");
> > +return AVERROR(ENOMEM);
>

Re: [FFmpeg-devel] [PATCH 1/2] avutil/file: Move av_tempfile() to avutil/file_open ff_tempfile()

[Hendrik Leppkes]

On Wed, Mar 9, 2016 at 4:35 PM, Michael Niedermayer
 wrote:
> On Wed, Mar 09, 2016 at 04:27:12PM +0100, Hendrik Leppkes wrote:
>> On Wed, Mar 9, 2016 at 3:37 PM, Michael Niedermayer
>>  wrote:
>> > document the issue with av_tempfile()
>> >
>> > Signed-off-by: Michael Niedermayer 
>> > ---
>> >  libavcodec/libxvid.h  |2 --
>> >  libavutil/file.c  |   48 ++--
>> >  libavutil/file.h  |1 +
>> >  libavutil/file_open.c |   59 
>> > +
>> >  libavutil/internal.h  |   14 
>> >  5 files changed, 76 insertions(+), 48 deletions(-)
>> >
>> > diff --git a/libavcodec/libxvid.h b/libavcodec/libxvid.h
>> > index bffe07d..ef9a5a9 100644
>> > --- a/libavcodec/libxvid.h
>> > +++ b/libavcodec/libxvid.h
>> > @@ -26,6 +26,4 @@
>> >   * common functions for use with the Xvid wrappers
>> >   */
>> >
>> > -int ff_tempfile(const char *prefix, char **filename);
>> > -
>> >  #endif /* AVCODEC_LIBXVID_H */
>> > diff --git a/libavutil/file.c b/libavutil/file.c
>> > index 2a06be4..25381b1 100644
>> > --- a/libavutil/file.c
>> > +++ b/libavutil/file.c
>> > @@ -137,52 +137,8 @@ void av_file_unmap(uint8_t *bufptr, size_t size)
>> >  #endif
>> >  }
>> >
>> > -int av_tempfile(const char *prefix, char **filename, int log_offset, void 
>> > *log_ctx)
>> > -{
>> > -FileLogContext file_log_ctx = { &file_log_ctx_class, log_offset, 
>> > log_ctx };
>> > -int fd = -1;
>> > -#if !HAVE_MKSTEMP
>> > -void *ptr= tempnam(NULL, prefix);
>> > -if(!ptr)
>> > -ptr= tempnam(".", prefix);
>> > -*filename = av_strdup(ptr);
>> > -#undef free
>> > -free(ptr);
>> > -#else
>> > -size_t len = strlen(prefix) + 12; /* room for "/tmp/" and "XX\0" 
>> > */
>> > -*filename  = av_malloc(len);
>> > -#endif
>> > -/* -common section-*/
>> > -if (!*filename) {
>> > -av_log(&file_log_ctx, AV_LOG_ERROR, "ff_tempfile: Cannot allocate 
>> > file name\n");
>> > -return AVERROR(ENOMEM);
>> > -}
>> > -#if !HAVE_MKSTEMP
>> > -#   ifndef O_BINARY
>> > -#   define O_BINARY 0
>> > -#   endif
>> > -#   ifndef O_EXCL
>> > -#   define O_EXCL 0
>> > -#   endif
>> > -fd = open(*filename, O_RDWR | O_BINARY | O_CREAT | O_EXCL, 0600);
>> > -#else
>> > -snprintf(*filename, len, "/tmp/%sXX", prefix);
>> > -fd = mkstemp(*filename);
>> > -#ifdef _WIN32
>> > -if (fd < 0) {
>> > -snprintf(*filename, len, "./%sXX", prefix);
>> > -fd = mkstemp(*filename);
>> > -}
>> > -#endif
>> > -#endif
>> > -/* -common section-*/
>> > -if (fd < 0) {
>> > -int err = AVERROR(errno);
>> > -av_log(&file_log_ctx, AV_LOG_ERROR, "ff_tempfile: Cannot open 
>> > temporary file %s\n", *filename);
>> > -av_freep(filename);
>> > -return err;
>> > -}
>> > -return fd; /* success */
>> > +int av_tempfile(const char *prefix, char **filename, int log_offset, void 
>> > *log_ctx) {
>> > +return avpriv_tempfile(prefix, filename, log_offset, log_ctx);
>> >  }
>> >
>> >  #ifdef TEST
>> > diff --git a/libavutil/file.h b/libavutil/file.h
>> > index e931be7..8666c7b 100644
>> > --- a/libavutil/file.h
>> > +++ b/libavutil/file.h
>> > @@ -62,6 +62,7 @@ void av_file_unmap(uint8_t *bufptr, size_t size);
>> >   * @note On very old libcs it is necessary to set a secure umask before
>> >   *   calling this, av_tempfile() can't call umask itself as it is 
>> > used in
>> >   *   libraries and could interfere with the calling application.
>> > + * @deprecated as fd numbers cannot be passed saftely between libs on 
>> > some platforms
>> >   */
>> >  int av_tempfile(const char *prefix, char **filename, int log_offset, void 
>> > *log_ctx);
>> >
>> > diff --git a/libavutil/file_open.c b/libavutil/file_open.c
>> > index 9e76127..6e58cc1 100644
>> > --- a/libavutil/file_open.c
>> > +++ b/libavutil/file_open.c
>> > @@ -92,6 +92,65 @@ int avpriv_open(const char *filename, int flags, ...)
>> >  return fd;
>> >  }
>> >
>> > +typedef struct FileLogContext {
>> > +const AVClass *class;
>> > +int   log_offset;
>> > +void *log_ctx;
>> > +} FileLogContext;
>> > +
>> > +static const AVClass file_log_ctx_class = {
>> > +"TEMPFILE", av_default_item_name, NULL, LIBAVUTIL_VERSION_INT,
>> > +offsetof(FileLogContext, log_offset), offsetof(FileLogContext, 
>> > log_ctx)
>> > +};
>> > +
>> > +int avpriv_tempfile(const char *prefix, char **filename, int log_offset, 
>> > void *log_ctx)
>> > +{
>> > +FileLogContext file_log_ctx = { &file_log_ctx_class, log_offset, 
>> > log_ctx };
>> > +int fd = -1;
>> > +#if !HAVE_MKSTEMP
>> > +void *ptr= tempnam(NULL, prefix);
>> > +if(!ptr)
>> > +ptr= tempnam(".", prefix);
>> > +*filename = av_strdup(ptr);
>> > +#undef free
>> > +free(ptr);
>> > +#else
>> > +size_t len = strlen(prefix) + 12; /* room for "/tmp/" and "XX\0" 
>> > */
>> > +*filename  = av_malloc(le

Re: [FFmpeg-devel] AAC encoder 3x performance drop in 3.0 since Oct 2014

[Claudio Freire]

On Mon, Feb 29, 2016 at 11:30 PM, Ganesh Ajjanagadde  wrote:
> On Mon, Feb 22, 2016 at 11:34 PM, Andrey Utkin
>  wrote:
>> Hi!
>> I am aware of news that AAC encoder got stable status recently.
>>
>> But you could find this interesting. We've got an ffmpeg build from
>> October 2014, and it performs three times faster on AAC encoding than
>> recent 3.0 release. There is no complaints about audio quality on old
>> version, and I can honestly say the audio quality is really
>> satisfiable on old version. The performance is paramount in our
>> particular usecase, so it is silly to deploy a new version which
>> performs so noticeably worse. Still deploying new release is needed due
>> to other particular bugfixes.
>>
>> Obvious things like lowering bitrace, setting "-aac_coder fast" don't
>> help.
>>
>> You can check this yourself with this script (it is also inlined below):
>> https://gist.github.com/andrey-utkin/c60cd4070eb962d58075
>>
>> On my workstation, the old version finishes the transcoding in 2.5s,
>> the new one in 6.6s.
>>
>> Is there any workaround? Or is the old times speed is buried by
>> correctness and stability?
>
> No idea about this. However, here is some info.
> The regression in speed dates to: 01ecb7172b684f1c4b3e748f95c5a9a494ca36ec.
> At this commit, there was a bad speed regression (11.475 s, vs 2.525 s
> before vs 6.565 s current).
> As can be judged from this, since the main commit bringing in the
> revamped encoder, there have been efforts that have shaved off some
> time, some that increase it slightly, etc.
> However, the chief one that brought it down from 11.x to 6.y was
> b629c67ddfceb7026e407685f04d1bb09cb08d31. Since then, performance has
> been generally stable at ~ 6.5 s +/- 10%.
>
> Generally speaking though, it is indeed true that speed is still
> somewhat lacking:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/184631.html.
>
> Ideally, FATE should have some basic plotting/performance
> infrastructure, e.g a client can submit perf figures so that evolution
> over time can be viewed. No idea why this can't be done.

From my experience, the slowness is mostly due to the fact that
twoloop gets stuck trying to meet the bandwidth limit with an initial
allocation (by aacpsy) that makes it hard. That is, it gives off an
initial solution that is far off the bandwidth limit, and makes
twoloop work extra hard to adjust the solution.

I've been attempting to fix that by making psy's initial allocation a
closer match to the target bitrate, but that's another huge change in
the bit allocator that shows lots of regressions, so it isn't at all
near completion. But I can confirm it does speed up the encoder a
great deal when psy gives a better initial solution, so that's
probably the path to a speedier encoder.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Can't see a mp4 converted video on internet

[Martín Capón Borrego]

 Hi:
 
I use ffmpeg in my asp.net pages
I do
Dim strfichero As String


Dim mh As New MediaHandler


strfichero = Mid(fichero, InStrRev(fichero, "\") + 1)


mh.FFMPEGPath = Server.MapPath("Comun/Ffmpeg/ffmpeg.exe")
 
 


mh.InputPath = Left(fichero, Len(fichero) - Len(strfichero) - 1)


 
mh.OutputPath = Server.MapPath("Temporal")


mh.BackgroundProcessing = True


 
 
mh.FileName = strfichero


mh.OutputFileName = Left(strfichero, Len(strfichero) - 4)


 
mh.OutputExtension = ".mp4"


'mh.VCodec = "libx264"


 


　


mh.Width = 640


mh.Height = 380


mh.Video_Bitrate = 800



 
'mh.Audio_SamplingRate = 44100


'mh.Audio_Bitrate = 128


 
 
mh.Process()
 
 
to convert the video to mp4. It is ok. But when I try to see it on internet, I 
can't.
You can see it here:
https://www.cresolia.com, click on ads, naturaleza en la playa, see
 
Maybe it is a matter od bitrate, códec.
When I doubl click the video directly I can see it.
Can u help me , please?
 
TIA

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

[FFmpeg-devel] Loss of quality in a video uploaded by FTP to the server

[Martín Capón Borrego]

Hi all:
 
I have a video .mp4 in my local pc with Windows 7. When I upload it via FTP  
and go to see it, I reliaze this suffers of loss of quality. Is
it  normal? How to do to see the uploaded video to local?
 
TIA

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

Re: [FFmpeg-devel] [PATCH] Add tests for functions in hash.c

[NagaChaitanya Vellanki]

Ping Michael to review to patch.


Thank you,
Naga

On Tue, Mar 8, 2016 at 5:33 PM, James Almer  wrote:

> On 3/8/2016 2:21 AM, NagaChaitanya Vellanki wrote:
> > ---
> >  libavutil/Makefile   |  1 +
> >  libavutil/hash.c | 42 ++
> >  tests/fate/libavutil.mak |  4 
> >  tests/ref/fate/hash  | 45
> +
> >  4 files changed, 92 insertions(+)
> >  create mode 100644 tests/ref/fate/hash
>
> LGTM. I'll let the maintainer give the final ok and push it (CCing him as
> well).
>
> ___
> 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] avformat/udp: Add a delay between packets for streaming to clients with short buffer

[Pavel Nikiforov]

Nicolas George george at nsup.org wrote:

>>  libavformat/udp.c | 133 
>> --
>>  1 file changed, 129 insertions(+), 4 deletions(-)

>Missing documentation update.
fixed.

>> -while(1) {
>> +for(;;) {

>Stray change.
Portability. You don't know how a compiler other than clang or gcc
will optimize or not optimize "while (1) { }".


>> +if (!(h->flags & AVIO_FLAG_NONBLOCK)) {

>This looks suspicious: blocking/nonblocking is a property of the protocol as
>seen by the calling application, it should not apply in a thread used
>internally. See below.
The thread should work as original non-thread code.

>> +ret = sendto (s->udp_fd, buf, size, 0,
>> +  (struct sockaddr *) &s->dest_addr,

>Style: no spaces after function names and casts.
It is not my code. This block from
static int udp_write(URLContext *h, const uint8_t *buf, int size)

>> +av_usleep(s->packet_gap);

>Not very reliable: if the task gets unscheduled for some time, it will be
>added to the gap and never catch, possibly causing playback hiccups. A
>system with a kind of rate control would probably be better.
Want reliable delay ? Spin in a loop polling dogettimeofday() in
kernel w/o task switch. Otherwise the only thing we have is usleep() .
No more options available to make a delay in user space: all of them
cause task switch with unpredicted return time after delay (preemtable
kernel, you knows).

If all goes right and a system is not overloaded the gap between
packets will be as set (and tcpdump with -ttt prove this). Also, we
have a sendto() syscall (preemption again), the UDP socket buffer, a
network device TX ring and many other things like "backpressure" on an
ethernet switch port that will cause the delay be more than specified.

>> +/*
>> +  Create thread in case of:
>> +  1. Input and circular_buffer_size is set
>> +  2. Output and packet_gap and circular_buffer_size is set
>> +*/

>UDP sockets can be read+write; in this case, two threads are needed.
The UDP socket are mostly read or mostly write. The thread will handle
the most part of socket communication, no need to make a thread for
handle some packets.

Fixed version of the patch in attachment.


udp.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] License term Inquiry

[Peng Poney]

Hi



We need to use FFMpeg in Chromium and we do compile
option:”proprietary_codecs=1”. According  to the license term, we didn’t
 use GPL and NON_Free option when we compile our software. Does it mean we
can use our software fro commercial purpose?



Thanks,

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

Re: [FFmpeg-devel] [PATCH] lavc/lpc: exploit even symmetry of window function

[Reimar Döffinger]

On Wed, Mar 09, 2016 at 01:13:58PM +0100, Michael Niedermayer wrote:
> On Tue, Mar 08, 2016 at 10:16:50PM -0500, Ganesh Ajjanagadde wrote:
> > Yields 2x improvement in function performance, and boosts aac encoding
> > speed by ~ 4% overall. Sample benchmark (Haswell+GCC under -march=native):
> > after:
> > ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.22s user 0.03s system 105% 
> > cpu 4.970 total
> > 
> > before:
> > ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.40s user 0.05s system 105% 
> > cpu 5.162 total
> > 
> > Big shame that len-1 is -1 mod 4; 0 mod 4 would have yielded a further 2x 
> > through
> > additional symmetry. Of course, one could approximate with the 0 mod 4 
> > variant,
> > error would essentially be ~ 1/len in the worst case.
> > 
> > Signed-off-by: Ganesh Ajjanagadde 
> > ---
> >  libavcodec/lpc.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/lpc.c b/libavcodec/lpc.c
> > index 3839119..052aeaa 100644
> > --- a/libavcodec/lpc.c
> > +++ b/libavcodec/lpc.c
> > @@ -176,9 +176,10 @@ double ff_lpc_calc_ref_coefs_f(LPCContext *s, const 
> > float *samples, int len,
> >  const double a = 0.5f, b = 1.0f - a;
> >  
> >  /* Apply windowing */
> > -for (i = 0; i < len; i++) {
> > +for (i = 0; i <= len / 2; i++) {
> 
> >  double weight = a - b*cos((2*M_PI*i)/(len - 1));
> 
> the windows should not be recalcuated for each frame. But either
> calculated once during init or calculated at first use if that makes
> sense
> 
> actually i suspect there should be close to 0 calls to libc math
> functions after init in the encoder, or is there some use of these
> functions in aac that cannot be replaced by a simple table?

I don't understand the code, but I assumed that len changes
regularly here, which is the main problem.
I never actually checked if there is maybe only a small
number of common values at least though.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] License term Inquiry

[Reimar Döffinger]

On Wed, Mar 09, 2016 at 08:52:29AM +0800, Peng Poney wrote:
> Hi
> 
> 
> 
> We need to use FFMpeg in Chromium and we do compile
> option:”proprietary_codecs=1”. According  to the license term, we didn’t
>  use GPL and NON_Free option when we compile our software. Does it mean we
> can use our software fro commercial purpose?

If you plan on investing any relevant amount of money I can
only recommend to talk to a lawyer with experience in OpenSource
and Multimedia, the way you stated your question suggests
you need a lot more information than anyone here has
time to give.
At the very least read the licenses.
Neither GPL or LGPL have any restrictions on USE,
only on DISTRIBUTION.
Even if you DISTRIBUTE commercial or not does not really matter.
As an approximation of the minimum you have to do if
distributing (if not using GPL or non-free parts):
make the source code of the EXACT version of FFmpeg you
used available alongside (e.g. on the same CD,
on the same web-page) with the binaries.
Make it possible to replace the FFmpeg version in
the thing you distribute with a different FFmpeg
version (that is mostly an issue if you link statically).
Alternative options and details: see the licenses.

Regards,
Reimar Döffinger
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AAC encoder 3x performance drop in 3.0 since Oct 2014

[Reimar Döffinger]

On Wed, Mar 09, 2016 at 02:20:35PM -0300, Claudio Freire wrote:
> On Mon, Feb 29, 2016 at 11:30 PM, Ganesh Ajjanagadde  
> wrote:
> > On Mon, Feb 22, 2016 at 11:34 PM, Andrey Utkin
> >  wrote:
> > No idea about this. However, here is some info.
> > The regression in speed dates to: 01ecb7172b684f1c4b3e748f95c5a9a494ca36ec.
> > At this commit, there was a bad speed regression (11.475 s, vs 2.525 s
> > before vs 6.565 s current).
> > As can be judged from this, since the main commit bringing in the
> > revamped encoder, there have been efforts that have shaved off some
> > time, some that increase it slightly, etc.
> > However, the chief one that brought it down from 11.x to 6.y was
> > b629c67ddfceb7026e407685f04d1bb09cb08d31. Since then, performance has
> > been generally stable at ~ 6.5 s +/- 10%.
> >
> > Generally speaking though, it is indeed true that speed is still
> > somewhat lacking:
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/184631.html.
> >
> > Ideally, FATE should have some basic plotting/performance
> > infrastructure, e.g a client can submit perf figures so that evolution
> > over time can be viewed. No idea why this can't be done.
> 
> From my experience, the slowness is mostly due to the fact that
> twoloop gets stuck trying to meet the bandwidth limit with an initial
> allocation (by aacpsy) that makes it hard. That is, it gives off an
> initial solution that is far off the bandwidth limit, and makes
> twoloop work extra hard to adjust the solution.
> 
> I've been attempting to fix that by making psy's initial allocation a
> closer match to the target bitrate, but that's another huge change in
> the bit allocator that shows lots of regressions, so it isn't at all
> near completion. But I can confirm it does speed up the encoder a
> great deal when psy gives a better initial solution, so that's
> probably the path to a speedier encoder.

You mean besides fixing the obvious performance bugs in the code :)
After all we manged to extract about 25% or more of extra performance
already with no algorithm changes, so there was (is?) a surprising
amount of low-hanging fruit.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add tests for functions in hash.c

[Michael Niedermayer]

On Wed, Mar 09, 2016 at 10:27:29AM -0800, NagaChaitanya Vellanki wrote:
> Ping Michael to review to patch.

patch applied

thanks

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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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

Re: [FFmpeg-devel] [PATCH v7 3/3] mips: add support for R6

[Michael Niedermayer]

On Wed, Feb 24, 2016 at 04:38:22PM +, Vicente Olivert Riera wrote:
> Understanding the mips32r6 and mips64r6 ISAs in the configure script is
> not enough. In order to have full support for MIPS R6 in FFmpeg we need
> to be able to build it, and for that we need to make sure we don't use
> incompatible assembler code which makes the build fail. Ifdefing the
> offending code is sufficient to fix the problem.
> 
> Signed-off-by: Vicente Olivert Riera 
> ---
> Changes v1 -> v7:
>  - Nothing.
> 
>  libavcodec/mips/aaccoder_mips.c   |  4 
>  libavcodec/mips/aacdec_mips.h |  2 ++
>  libavcodec/mips/aacpsdsp_mips.c   |  4 
>  libavcodec/mips/aacpsy_mips.h |  2 ++
>  libavcodec/mips/aacsbr_mips.c |  4 
>  libavcodec/mips/aacsbr_mips.h |  2 ++
>  libavcodec/mips/ac3dsp_mips.c |  6 +-
>  libavcodec/mips/acelp_filters_mips.c  |  4 
>  libavcodec/mips/acelp_vectors_mips.c  |  4 
>  libavcodec/mips/amrwbdec_mips.c   |  2 ++
>  libavcodec/mips/amrwbdec_mips.h   |  2 ++
>  libavcodec/mips/celp_filters_mips.c   |  4 
>  libavcodec/mips/celp_math_mips.c  |  4 
>  libavcodec/mips/compute_antialias_float.h |  2 ++
>  libavcodec/mips/fft_mips.c|  4 
>  libavcodec/mips/iirfilter_mips.c  |  4 
>  libavcodec/mips/lsp_mips.h|  2 ++
>  libavcodec/mips/mpegaudiodsp_mips_fixed.c | 10 ++
>  libavcodec/mips/mpegaudiodsp_mips_float.c | 10 ++
>  libavcodec/mips/sbrdsp_mips.c |  4 
>  libavutil/mips/float_dsp_mips.c   |  4 
>  21 files changed, 83 insertions(+), 1 deletion(-)

applied

thanks

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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

Re: [FFmpeg-devel] [PATCH] Add tests for functions in hash.c

[Reimar Döffinger]

On Wed, Mar 09, 2016 at 10:27:29AM -0800, NagaChaitanya Vellanki wrote:
> On Tue, Mar 8, 2016 at 5:33 PM, James Almer  wrote:
> 
> > On 3/8/2016 2:21 AM, NagaChaitanya Vellanki wrote:
> > > ---
> > >  libavutil/Makefile   |  1 +
> > >  libavutil/hash.c | 42 ++
> > >  tests/fate/libavutil.mak |  4 
> > >  tests/ref/fate/hash  | 45
> > +
> > >  4 files changed, 92 insertions(+)
> > >  create mode 100644 tests/ref/fate/hash
> >
> > LGTM. I'll let the maintainer give the final ok and push it (CCing him as
> > well).

It looks fine to me, though there are a few things that could
be improved if wanted.
For example all-0s for src is a bit boring, just a
couple of random numbers would be a better test.
At 64 bytes it is also a bit short, for some hashes that
would mean the same size as the hash, and thus some
parts of the algorithm would never ever run.
A power-of-two size also means the padding special-cases
are not tested.
Something like e.g. 133 bytes might be a better test
(assuming all our hashes support that as input?
I actually have no idea who is responsible for padding).
As we are testing things, changing the memset to
not 0 but e.g. 'a' would ensure that we would notice
if someone broke then 0-termination of the string,
and it should then also be run before the av_hash_final_b64.
But regardless of that it is great to have a test,
these are just some improvement ideas that also
can be added later.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/mxfdec: Support canopus codecs

[Tomas Härdin]

On Wed, 2016-03-09 at 15:21 +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch fixes ticket #5316 here.
> I unfortunately have no idea what the hunk in mxf_read_header() 
> does, decoding works fine without it.

Strange. Why was mxf_canopus_essence_element_key added then? Pushing
without it is fine if it fixes the issue, even preferable (since it'd
be simpler).

/Tomas

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

Re: [FFmpeg-devel] Loss of quality in a video uploaded by FTP to the server

[Lou Logan]

On Wed, 9 Mar 2016 17:48:41 +, Martín Capón Borrego wrote:

> Hi all:
>  
> I have a video .mp4 in my local pc with Windows 7. When I upload it
> via FTP  and go to see it, I reliaze this suffers of loss of quality.
> Is it  normal? How to do to see the uploaded video to local? 
> TIA

There are several issues with your message:

1. You sent to the wrong mailing list. ffmpeg-devel is for patch
submissions and discussions related to the development of FFmpeg.
Questions involving usage of the FFmpeg tools should be asked at
ffmpeg-user.

2. You replied to an existing message and changed the subject, but your
messaged ended up in the thread of the original message you responded
to. This is called "thread hijacking" and often results in the message
being ignored because it is mixed with an unrelated thread. You can see
what I am describing in the archives:



3. You did not provide enough info. You need to show your actual,
unscripted ffmpeg command and the complete console output. Also,
provide a link to a short sample input file if it is required to
duplicate the issue.

4. ffmpeg-user only provides support for direct usage of the FFmpeg cli
tools. You will have to get help elsewhere for scripting help.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AAC encoder 3x performance drop in 3.0 since Oct 2014

[Claudio Freire]

On Wed, Mar 9, 2016 at 3:52 PM, Reimar Döffinger
 wrote:
> On Wed, Mar 09, 2016 at 02:20:35PM -0300, Claudio Freire wrote:
>> On Mon, Feb 29, 2016 at 11:30 PM, Ganesh Ajjanagadde  
>> wrote:
>> > On Mon, Feb 22, 2016 at 11:34 PM, Andrey Utkin
>> >  wrote:
>> > No idea about this. However, here is some info.
>> > The regression in speed dates to: 01ecb7172b684f1c4b3e748f95c5a9a494ca36ec.
>> > At this commit, there was a bad speed regression (11.475 s, vs 2.525 s
>> > before vs 6.565 s current).
>> > As can be judged from this, since the main commit bringing in the
>> > revamped encoder, there have been efforts that have shaved off some
>> > time, some that increase it slightly, etc.
>> > However, the chief one that brought it down from 11.x to 6.y was
>> > b629c67ddfceb7026e407685f04d1bb09cb08d31. Since then, performance has
>> > been generally stable at ~ 6.5 s +/- 10%.
>> >
>> > Generally speaking though, it is indeed true that speed is still
>> > somewhat lacking:
>> > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/184631.html.
>> >
>> > Ideally, FATE should have some basic plotting/performance
>> > infrastructure, e.g a client can submit perf figures so that evolution
>> > over time can be viewed. No idea why this can't be done.
>>
>> From my experience, the slowness is mostly due to the fact that
>> twoloop gets stuck trying to meet the bandwidth limit with an initial
>> allocation (by aacpsy) that makes it hard. That is, it gives off an
>> initial solution that is far off the bandwidth limit, and makes
>> twoloop work extra hard to adjust the solution.
>>
>> I've been attempting to fix that by making psy's initial allocation a
>> closer match to the target bitrate, but that's another huge change in
>> the bit allocator that shows lots of regressions, so it isn't at all
>> near completion. But I can confirm it does speed up the encoder a
>> great deal when psy gives a better initial solution, so that's
>> probably the path to a speedier encoder.
>
> You mean besides fixing the obvious performance bugs in the code :)
> After all we manged to extract about 25% or more of extra performance
> already with no algorithm changes, so there was (is?) a surprising
> amount of low-hanging fruit.

Sure, but the speedup I see is like 4x or something like that (I
haven't properly measured it yet, but it was noticeable)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/lpc: exploit even symmetry of window function

[Michael Niedermayer]

On Wed, Mar 09, 2016 at 07:32:29PM +0100, Reimar Döffinger wrote:
> On Wed, Mar 09, 2016 at 01:13:58PM +0100, Michael Niedermayer wrote:
> > On Tue, Mar 08, 2016 at 10:16:50PM -0500, Ganesh Ajjanagadde wrote:
> > > Yields 2x improvement in function performance, and boosts aac encoding
> > > speed by ~ 4% overall. Sample benchmark (Haswell+GCC under -march=native):
> > > after:
> > > ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.22s user 0.03s system 
> > > 105% cpu 4.970 total
> > > 
> > > before:
> > > ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.40s user 0.05s system 
> > > 105% cpu 5.162 total
> > > 
> > > Big shame that len-1 is -1 mod 4; 0 mod 4 would have yielded a further 2x 
> > > through
> > > additional symmetry. Of course, one could approximate with the 0 mod 4 
> > > variant,
> > > error would essentially be ~ 1/len in the worst case.
> > > 
> > > Signed-off-by: Ganesh Ajjanagadde 
> > > ---
> > >  libavcodec/lpc.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/libavcodec/lpc.c b/libavcodec/lpc.c
> > > index 3839119..052aeaa 100644
> > > --- a/libavcodec/lpc.c
> > > +++ b/libavcodec/lpc.c
> > > @@ -176,9 +176,10 @@ double ff_lpc_calc_ref_coefs_f(LPCContext *s, const 
> > > float *samples, int len,
> > >  const double a = 0.5f, b = 1.0f - a;
> > >  
> > >  /* Apply windowing */
> > > -for (i = 0; i < len; i++) {
> > > +for (i = 0; i <= len / 2; i++) {
> > 
> > >  double weight = a - b*cos((2*M_PI*i)/(len - 1));
> > 
> > the windows should not be recalcuated for each frame. But either
> > calculated once during init or calculated at first use if that makes
> > sense
> > 
> > actually i suspect there should be close to 0 calls to libc math
> > functions after init in the encoder, or is there some use of these
> > functions in aac that cannot be replaced by a simple table?
> 
> I don't understand the code, but I assumed that len changes
> regularly here, which is the main problem.
> I never actually checked if there is maybe only a small
> number of common values at least though.

encoding matrixbench with defaults i get this list of lens with their freuqncies
  1 ff_lpc_calc_ref_coefs_f 108
131 ff_lpc_calc_ref_coefs_f 116
148 ff_lpc_calc_ref_coefs_f 584
 75 ff_lpc_calc_ref_coefs_f 84
  1 ff_lpc_calc_ref_coefs_f 88


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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


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

Re: [FFmpeg-devel] [PATCH] lavc/lpc: exploit even symmetry of window function

[Reimar Döffinger]

On Wed, Mar 09, 2016 at 09:04:29PM +0100, Michael Niedermayer wrote:
> On Wed, Mar 09, 2016 at 07:32:29PM +0100, Reimar Döffinger wrote:
> > On Wed, Mar 09, 2016 at 01:13:58PM +0100, Michael Niedermayer wrote:
> > > On Tue, Mar 08, 2016 at 10:16:50PM -0500, Ganesh Ajjanagadde wrote:
> > > > Yields 2x improvement in function performance, and boosts aac encoding
> > > > speed by ~ 4% overall. Sample benchmark (Haswell+GCC under 
> > > > -march=native):
> > > > after:
> > > > ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.22s user 0.03s system 
> > > > 105% cpu 4.970 total
> > > > 
> > > > before:
> > > > ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.40s user 0.05s system 
> > > > 105% cpu 5.162 total
> > > > 
> > > > Big shame that len-1 is -1 mod 4; 0 mod 4 would have yielded a further 
> > > > 2x through
> > > > additional symmetry. Of course, one could approximate with the 0 mod 4 
> > > > variant,
> > > > error would essentially be ~ 1/len in the worst case.
> > > > 
> > > > Signed-off-by: Ganesh Ajjanagadde 
> > > > ---
> > > >  libavcodec/lpc.c | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/libavcodec/lpc.c b/libavcodec/lpc.c
> > > > index 3839119..052aeaa 100644
> > > > --- a/libavcodec/lpc.c
> > > > +++ b/libavcodec/lpc.c
> > > > @@ -176,9 +176,10 @@ double ff_lpc_calc_ref_coefs_f(LPCContext *s, 
> > > > const float *samples, int len,
> > > >  const double a = 0.5f, b = 1.0f - a;
> > > >  
> > > >  /* Apply windowing */
> > > > -for (i = 0; i < len; i++) {
> > > > +for (i = 0; i <= len / 2; i++) {
> > > 
> > > >  double weight = a - b*cos((2*M_PI*i)/(len - 1));
> > > 
> > > the windows should not be recalcuated for each frame. But either
> > > calculated once during init or calculated at first use if that makes
> > > sense
> > > 
> > > actually i suspect there should be close to 0 calls to libc math
> > > functions after init in the encoder, or is there some use of these
> > > functions in aac that cannot be replaced by a simple table?
> > 
> > I don't understand the code, but I assumed that len changes
> > regularly here, which is the main problem.
> > I never actually checked if there is maybe only a small
> > number of common values at least though.
> 
> encoding matrixbench with defaults i get this list of lens with their 
> freuqncies
>   1 ff_lpc_calc_ref_coefs_f 108
> 131 ff_lpc_calc_ref_coefs_f 116
> 148 ff_lpc_calc_ref_coefs_f 584
>  75 ff_lpc_calc_ref_coefs_f 84
>   1 ff_lpc_calc_ref_coefs_f 88

That looks to me like it will depend on content.
Then probably only a cache will work.
It could safe a few more operations by directly
containing the weight.
Still, not sure it's worth the effort, I think we'd
only save another 1% over what you get with
this patch + using cosf.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/lpc: exploit even symmetry of window function

[Michael Niedermayer]

On Wed, Mar 09, 2016 at 09:56:00PM +0100, Reimar Döffinger wrote:
> On Wed, Mar 09, 2016 at 09:04:29PM +0100, Michael Niedermayer wrote:
> > On Wed, Mar 09, 2016 at 07:32:29PM +0100, Reimar Döffinger wrote:
> > > On Wed, Mar 09, 2016 at 01:13:58PM +0100, Michael Niedermayer wrote:
> > > > On Tue, Mar 08, 2016 at 10:16:50PM -0500, Ganesh Ajjanagadde wrote:
> > > > > Yields 2x improvement in function performance, and boosts aac encoding
> > > > > speed by ~ 4% overall. Sample benchmark (Haswell+GCC under 
> > > > > -march=native):
> > > > > after:
> > > > > ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.22s user 0.03s 
> > > > > system 105% cpu 4.970 total
> > > > > 
> > > > > before:
> > > > > ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.40s user 0.05s 
> > > > > system 105% cpu 5.162 total
> > > > > 
> > > > > Big shame that len-1 is -1 mod 4; 0 mod 4 would have yielded a 
> > > > > further 2x through
> > > > > additional symmetry. Of course, one could approximate with the 0 mod 
> > > > > 4 variant,
> > > > > error would essentially be ~ 1/len in the worst case.
> > > > > 
> > > > > Signed-off-by: Ganesh Ajjanagadde 
> > > > > ---
> > > > >  libavcodec/lpc.c | 3 ++-
> > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/libavcodec/lpc.c b/libavcodec/lpc.c
> > > > > index 3839119..052aeaa 100644
> > > > > --- a/libavcodec/lpc.c
> > > > > +++ b/libavcodec/lpc.c
> > > > > @@ -176,9 +176,10 @@ double ff_lpc_calc_ref_coefs_f(LPCContext *s, 
> > > > > const float *samples, int len,
> > > > >  const double a = 0.5f, b = 1.0f - a;
> > > > >  
> > > > >  /* Apply windowing */
> > > > > -for (i = 0; i < len; i++) {
> > > > > +for (i = 0; i <= len / 2; i++) {
> > > > 
> > > > >  double weight = a - b*cos((2*M_PI*i)/(len - 1));
> > > > 
> > > > the windows should not be recalcuated for each frame. But either
> > > > calculated once during init or calculated at first use if that makes
> > > > sense
> > > > 
> > > > actually i suspect there should be close to 0 calls to libc math
> > > > functions after init in the encoder, or is there some use of these
> > > > functions in aac that cannot be replaced by a simple table?
> > > 
> > > I don't understand the code, but I assumed that len changes
> > > regularly here, which is the main problem.
> > > I never actually checked if there is maybe only a small
> > > number of common values at least though.
> > 
> > encoding matrixbench with defaults i get this list of lens with their 
> > freuqncies
> >   1 ff_lpc_calc_ref_coefs_f 108
> > 131 ff_lpc_calc_ref_coefs_f 116
> > 148 ff_lpc_calc_ref_coefs_f 584
> >  75 ff_lpc_calc_ref_coefs_f 84
> >   1 ff_lpc_calc_ref_coefs_f 88
> 
> That looks to me like it will depend on content.
> Then probably only a cache will work.
> It could safe a few more operations by directly
> containing the weight.
> Still, not sure it's worth the effort, I think we'd
> only save another 1% over what you get with
> this patch + using cosf.

the patch is surely a good idea either way

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

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


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

Re: [FFmpeg-devel] [PATCHv2 2/3] avformat/utils: increase detected start_time with skip_samples

[Marton Balint]

On Wed, 9 Mar 2016, wm4 wrote:

On Tue, 8 Mar 2016 23:44:13 +0100 (CET)
Marton Balint  wrote:


On Tue, 8 Mar 2016, Hendrik Leppkes wrote:

> On Tue, Mar 8, 2016 at 10:54 PM, Marton Balint  wrote: 
>>

>> On Tue, 8 Mar 2016, wm4 wrote:
>> 
>>> On Tue,  8 Mar 2016 21:29:52 +0100

>>> Marton Balint  wrote:
>>> 
 Signed-off-by: Marton Balint 

 ---
  libavformat/utils.c   | 10 --
  tests/ref/fate/gapless2-ipod-aac1 | 72
 +++
  tests/ref/fate/gapless2-ipod-aac2 | 72
 +++
  3 files changed, 80 insertions(+), 74 deletions(-)
 
>> 
>>> I'm a probably bit late here, but what's the rationale of increasing the

>>> start time?
>>> 
>>

>> According to docs, start time is supposed to be the pts of the first
>> decoded frame, therefore skipped samples must be taken into account, when
>> the start time is determined based on the first packet pts.
>> 
>
> But the skipping is performed by avcodec, not avformat, isn't it? 


Yes.

> start_time should be the PTS of the first avpacket coming out of
> avformat, never mind what a decoder might do to that later. 


Not according to the docs:

"AVStream->start_time: decoding: pts of the first frame of the stream in 
presentation order, in stream time base. Only set this if you are 
absolutely 100% sure that the value you set it to really is the pts of 
the first frame."


If here frame refers to a packet, why the docs is talking about 
presentation order?


Also check the libavformat/mp3dec.c, it does the same kind of start_time 
adjustment based on the skipped samples.


True, with mp3, the first PTS is always 0, and after skipping it will
be some positive value, and start_time is set to the skip duration. Is
this the same here?


Yes. These are iTunes (-compatible) m4a files by the way with iTunes 
gapless metadata. I don't think you can make any assumptions based on 
a negative timestamp, even for MOV, elst should contain the proper start 
time:

https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html


Also, what the mp3 demuxer does is not necessarily correct. And
also, what works for audio-only formats isn't necessarily right for if
there are video tracks involved.


Only audio stream start times are adjusted, I don't see why does it make 
a difference if there are other (video) streams.


What I'm really worried about is what utils.c will determine as total 
stream start time?


What do you mean by "total stream start time"? Are you referring to 
AVFormat->start_time? Isn't that simply the minimum of the stream start 
times?



From your added tests it looks like mov.c does now what I'd expect,
though. I just want to be sure this mess doesn't become worse.



Sure, ok.


Last but not least, why do we have about 3 mechanisms to signal
pre-skip? (Skip side data, skip_samples field, and delay field.)


As far as I see, avformat code injects skip side data based on the
AVStream->skip_samples field, avcodec code uses skip side data to 
skip the samples.


I guess the delay field is the old way of signalling the 
number of to-be-skipped frames. As this can only signal whole frames and 
not samples, it has a very limited use. Generic code does not do anything 
with this.


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

Re: [FFmpeg-devel] [PATCH] lavc/lpc: exploit even symmetry of window function

[Moritz Barsnick]

On Tue, Mar 08, 2016 at 22:16:50 -0500, Ganesh Ajjanagadde wrote:
> ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.22s user 0.03s system 105% 
> cpu 4.970 total

Just wondering: Is this the sin.flac from
ffmpeg -f lavfi -i aevalsrc="sin(440*2*PI*t):s=48000" -t 300 -y sin.flac
??

Is a sinusoidal signal good enough to benchmark an audio encoder? It
only requires one very narrow frequency band, after all, no
psychoacoustics, ...

I don't see differences in general encoding speed of sine vs. noise,
but I didn't check the influence on your code improvements. Agreed,
noise doesn't do much for psychoacoustics probably either.

(BTW, if just inspecting ffmpeg runtime without use of benchmarking
start/stop markers, I use lavfi directly, to avoid the overhead of flac
decoding. And not aevalsrc - sine and even anoisesrc are 10x faster.)

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

[FFmpeg-devel] [PATCH 1/3] lavf/avidec: Skip xxpc entries in index; fixes trac #5311

[Mats Peterson]

Interim fix of the parsing of idx1 indexes with 'xxpc' (palette change) 
entries.


Implementation of 'xxpc' index entry storage for seeking will come in 
the future (provided I can manage it).


Test file TOON.AVI from King's Quest VI with indexed 'xxpc' chunks which 
would previously cause "stream_ptr out of bounds" error messages to be 
emitted in the msvideo1 decoder:


https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU

Mats

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

[FFmpeg-devel] [PATCH 1/3] lavf/avidec: Skip xxpc entries in index; fixes trac #5311

[Mats Peterson]

Interim fix of the parsing of idx1 indexes with 'xxpc' (palette change) 
entries.


Implementation of 'xxpc' index entry storage for seeking will come in 
the future (provided I can manage it).


Test file TOON.AVI from King's Quest VI with indexed 'xxpc' chunks which 
would previously cause "stream_ptr out of bounds" error messages to be 
emitted in the msvideo1 decoder:


https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 7ad8519fe62008cdd84039fd6949488982a3ee3b Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Wed, 9 Mar 2016 23:18:07 +0100
Subject: [PATCH 1/3] lavf/avidec: Skip xxpc entries in index; fixes trac #5311

---
 libavformat/avidec.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index eaf8421..49c97d9 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -1581,6 +1581,9 @@ static int avi_read_idx1(AVFormatContext *s, int size)
 st  = s->streams[index];
 ast = st->priv_data;
 
+if ((tag >> 16 & 0xff) == 'p' && (tag >> 24 & 0xff) == 'c')
+continue;
+
 if (first_packet && first_packet_pos) {
 if (avi->movi_list + 4 != pos || pos + 500 > first_packet_pos)
 data_offset  = first_packet_pos - pos;
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH 1/3] lavf/avidec: Skip xxpc entries in index; fixes trac #5311

[Mats Peterson]

On 03/09/2016 11:26 PM, Mats Peterson wrote:

Interim fix of the parsing of idx1 indexes with 'xxpc' (palette change)
entries.

Implementation of 'xxpc' index entry storage for seeking will come in
the future (provided I can manage it).

Test file TOON.AVI from King's Quest VI with indexed 'xxpc' chunks which
would previously cause "stream_ptr out of bounds" error messages to be
emitted in the msvideo1 decoder:

https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU

Mats



Forgot to attach the patch. Sorry.

Mats

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

[FFmpeg-devel] [PATCH 2/3] lavf/riffenc: Improve spec compliance

[Mats Peterson]

From the Microsoft documentation for BITMAPINFOHEADER at
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx:

"biSize: Specifies the number of bytes required by the structure. This 
value does not include the size of the color table or the size of the 
color masks, if they are appended to the end of structure."


So, biSize is always 40. Also, Windows Media Player won't detect video 
encoded with Microsoft Video 1 in 8 bpp mode if this value is anything 
else than 40. I don't know about other codecs, they probably work. 
Anyway, we should stick with the specs, and not include the palette size 
in that field.


Regarding the biClrUsed field, I'm setting it to 1 << 
bits_per_coded_sample if palettized video, since setting it to 0 is 
another case where it won't work with Windows Media Player and Microsoft 
Video 1 in 8 bpp mode.


Mats


--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From c9b1a89ddc16a7c65feaa56ca6ecb8d8ff7a9dbc Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Wed, 9 Mar 2016 23:20:09 +0100
Subject: [PATCH 2/3] lavf/riffenc: Improve spec compliance

---
 libavformat/riffenc.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index 195a58e..3edb8d6 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -222,8 +222,8 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
 if (!enc->extradata_size && pal_avi)
 extradata_size = 4 * (1 << enc->bits_per_coded_sample);
 
-/* size */
-avio_wl32(pb, 40 + (ignore_extradata ? 0 :extradata_size));
+/* size (not including the size of the color table or color masks */
+avio_wl32(pb, 40);
 avio_wl32(pb, enc->width);
 //We always store RGB TopDown
 avio_wl32(pb, enc->codec_tag || keep_height ? enc->height : -enc->height);
@@ -236,7 +236,8 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
 avio_wl32(pb, (enc->width * enc->height * (enc->bits_per_coded_sample ? enc->bits_per_coded_sample : 24)+7) / 8);
 avio_wl32(pb, 0);
 avio_wl32(pb, 0);
-avio_wl32(pb, 0);
+/* number of color indices in the color table that are used */
+avio_wl32(pb, pal_avi ? 1 << enc->bits_per_coded_sample : 0);
 avio_wl32(pb, 0);
 
 if (!ignore_extradata) {
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH 3/3] lavf/avienc: Add xxpc entries to index

[Mats Peterson]

Here's an interesting one. Windows Media Player won't make any palette 
changes without the xxpc chunks beeing indexed.


Fixing the logic for reading and seeking with xxpc chunks in the demuxer 
is a future task. Now the muxing of video with xxpc chunks works 
properly at least.


Try playing the resulting test.avi file from the command line below with 
Windows Media Player, with and without patch 2/3 and 3/3 (you'll need 
patch 1/3 in order to get the xxpc chunks properly in the demuxer).


ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From e60e92cc96c50de0fa81195cc8ed8c97702c7d1b Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Wed, 9 Mar 2016 23:20:56 +0100
Subject: [PATCH 3/3] lavf/avienc: Add xxpc entries to index

---
 libavformat/avienc.c |   55 +-
 1 file changed, 45 insertions(+), 10 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ad50379..cab8e63 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -44,12 +44,16 @@
  */
 
 typedef struct AVIIentry {
-unsigned int flags, pos, len;
+char tag[5];
+unsigned int flags;
+unsigned int pos;
+unsigned int len;
 } AVIIentry;
 
 #define AVI_INDEX_CLUSTER_SIZE 16384
 
 #define AVISF_VIDEO_PALCHANGES 0x0001
+#define AVIIF_NO_TIME  0x0100
 
 typedef struct AVIIndex {
 int64_t indx_start;
@@ -612,9 +616,13 @@ static int avi_write_idx1(AVFormatContext *s)
 }
 if (!empty) {
 avist = s->streams[stream_id]->priv_data;
-avi_stream2fourcc(tag, stream_id,
+if (*ie->tag)
+ffio_wfourcc(pb, ie->tag);
+else {
+avi_stream2fourcc(tag, stream_id,
   s->streams[stream_id]->codec->codec_type);
-ffio_wfourcc(pb, tag);
+ffio_wfourcc(pb, tag);
+}
 avio_wl32(pb, ie->flags);
 avio_wl32(pb, ie->pos);
 avio_wl32(pb, ie->len);
@@ -673,6 +681,7 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 return avi_write_packet_internal(s, pkt); /* Passthrough */
 
 if (enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+AVIContext *avi  = s->priv_data;
 AVIStream *avist = s->streams[stream_index]->priv_data;
 AVIOContext *pb  = s->pb;
 AVPacket *opkt   = pkt;
@@ -709,6 +718,39 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 unsigned char tag[5];
 avi_stream2fourcc(tag, stream_index, enc->codec_type);
 tag[2] = 'p'; tag[3] = 'c';
+if (s->pb->seekable) {
+AVIIndex *idx;
+int cl, id;
+if (avist->strh_flags_offset) {
+int64_t cur_offset = avio_tell(pb);
+avio_seek(pb, avist->strh_flags_offset, SEEK_SET);
+avio_wl32(pb, AVISF_VIDEO_PALCHANGES);
+avio_seek(pb, cur_offset, SEEK_SET);
+avist->strh_flags_offset = 0;
+}
+idx = &avist->indexes;
+cl = idx->entry / AVI_INDEX_CLUSTER_SIZE;
+id = idx->entry % AVI_INDEX_CLUSTER_SIZE;
+if (idx->ents_allocated <= idx->entry) {
+idx->cluster = av_realloc_f(idx->cluster, sizeof(void*), cl+1);
+if (!idx->cluster) {
+idx->ents_allocated = 0;
+idx->entry  = 0;
+return AVERROR(ENOMEM);
+}
+idx->cluster[cl] =
+av_malloc(AVI_INDEX_CLUSTER_SIZE * sizeof(AVIIentry));
+if (!idx->cluster[cl])
+return AVERROR(ENOMEM);
+idx->ents_allocated += AVI_INDEX_CLUSTER_SIZE;
+}
+strcpy(idx->cluster[cl][id].tag, tag);
+idx->cluster[cl][id].flags = AVIIF_NO_TIME;
+idx->cluster[cl][id].pos   = avio_tell(pb) - avi->movi_list;
+idx->cluster[cl][id].len   = pal_size * 4 + 4;
+avist->max_size = FFMAX(avist->max_size, pal_size * 4 + 4);
+idx->entry++;
+}
 pc_tag = ff_start_tag(pb, tag);
 avio_w8(pb, 0);
 avio_w8(pb, pal_size & 0xFF);
@@ -719,13 +761,6 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 }
 ff_end_tag(pb, pc_tag);
  

Re: [FFmpeg-devel] [PATCH 1/3] lavf/avidec: Skip xxpc entries in index; fixes trac #5311

[Michael Niedermayer]

On Wed, Mar 09, 2016 at 11:27:27PM +0100, Mats Peterson wrote:
> Interim fix of the parsing of idx1 indexes with 'xxpc' (palette
> change) entries.
> 
> Implementation of 'xxpc' index entry storage for seeking will come
> in the future (provided I can manage it).
> 
> Test file TOON.AVI from King's Quest VI with indexed 'xxpc' chunks
> which would previously cause "stream_ptr out of bounds" error
> messages to be emitted in the msvideo1 decoder:
> 
> https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU
> 
> Mats
> 
> -- 
> Mats Peterson
> http://matsp888.no-ip.org/~mats/

>  avidec.c |3 +++
>  1 file changed, 3 insertions(+)
> 319d5689342af69a8146c1e06833af4ad1d5f1a7  
> 0001-lavf-avidec-Skip-xxpc-entries-in-index.patch
> From 7ad8519fe62008cdd84039fd6949488982a3ee3b Mon Sep 17 00:00:00 2001
> From: Mats Peterson 
> Date: Wed, 9 Mar 2016 23:18:07 +0100
> Subject: [PATCH 1/3] lavf/avidec: Skip xxpc entries in index; fixes trac #5311

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] Use matroska TrackNumber for populating AVStream::id

[Sergey Volk]

Ok, so then I guess we'll need to update AVStream::id to be 64-bit
first, and then I'll make the necessary changes in matroskadec.
I've prepared a patch to bump AVStream::id to be int64_t in the next
major version, I'll send it out shortly. After I rebuilt ffmpeg
with AVStream::id being int64_t I got a couple of new warnings in the
code that was using 32-bit format specifiers for printing
stream ids, I've fixed those as well. I've also re-ran 'make fate' and
all the tests seem to be good.

On Sat, Mar 5, 2016 at 2:47 AM, Michael Niedermayer
 wrote:
> On Fri, Mar 04, 2016 at 04:19:18PM -0800, Sergey Volk wrote:
>> Ok, something like this for now, then?
>
> your original patch contained a nice commit message, this one
> doesnt
>
>
>> I'm new to ffmpeg development. When is the next version bump going to happen?
>
> you can make changes at the next bump by using #if FF_API...
> see libavfilter/version.h
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> It is dangerous to be right in matters on which the established authorities
> are wrong. -- Voltaire
>
> ___
> 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] lavc/aacenc_quantization: use cbrt table

[Ganesh Ajjanagadde]

There is no reason for computing cbrtf at runtime; we have a table for
this.

Cruft needed due to the build system, the people who still like using
hardcoded tables and need for single cbrt_tab across the code.

Yields non-negligible speedup (Haswell+GCC, -march=native)
before:
ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.22s user 0.03s system 105% cpu 
4.970 total
after:
ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.15s user 0.02s system 105% cpu 
4.884 total

Also reduces size of the binary:
after:
15503040libavcodec/libavcodec.so.57
before:
15504176libavcodec/libavcodec.so.57

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/Makefile | 27 ++
 libavcodec/aacdec_fixed.c   |  4 +--
 libavcodec/aacdec_template.c|  4 +--
 libavcodec/aacenc.c |  2 ++
 libavcodec/aacenc_quantization.h|  3 +-
 libavcodec/{cbrt_tablegen.h => cbrt_data.c} | 56 -
 libavcodec/cbrt_tablegen.c  | 20 +--
 libavcodec/cbrt_tablegen.h  | 53 +--
 libavcodec/cbrt_tablegen_template.c | 38 
 9 files changed, 77 insertions(+), 130 deletions(-)
 copy libavcodec/{cbrt_tablegen.h => cbrt_data.c} (64%)
 delete mode 100644 libavcodec/cbrt_tablegen_template.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index ee9a962..3315cf7 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -132,22 +132,31 @@ OBJS-$(CONFIG_WMA_FREQS)   += wma_freqs.o
 OBJS-$(CONFIG_WMV2DSP) += wmv2dsp.o
 
 # decoders/encoders
+AAC_DECODER-OBJS-$(CONFIG_HARDCODED_TABLES)+= cbrt_tables.o
+AAC_FIXED_DECODER-OBJS-$(CONFIG_HARDCODED_TABLES)  += cbrt_tables.o
+AAC_ENCODER-OBJS-$(CONFIG_HARDCODED_TABLES)+= cbrt_tables.o
+AAC_DECODER-OBJS-$(!CONFIG_HARDCODED_TABLES)   += cbrt_data.o
+AAC_FIXED_DECODER-OBJS-$(!CONFIG_HARDCODED_TABLES) += cbrt_data.o
+AAC_ENCODER-OBJS-$(!CONFIG_HARDCODED_TABLES)   += cbrt_data.o
 OBJS-$(CONFIG_ZERO12V_DECODER) += 012v.o
 OBJS-$(CONFIG_A64MULTI_ENCODER)+= a64multienc.o elbg.o
 OBJS-$(CONFIG_A64MULTI5_ENCODER)   += a64multienc.o elbg.o
 OBJS-$(CONFIG_AAC_DECODER) += aacdec.o aactab.o aacsbr.o 
aacps_float.o \
   aacadtsdec.o mpeg4audio.o kbdwin.o \
-  sbrdsp.o aacpsdsp_float.o
+  sbrdsp.o aacpsdsp_float.o \
+  $(AAC_DECODER-OBJS-yes)
 OBJS-$(CONFIG_AAC_FIXED_DECODER)   += aacdec_fixed.o aactab.o 
aacsbr_fixed.o aacps_fixed.o \
   aacadtsdec.o mpeg4audio.o kbdwin.o \
-  sbrdsp_fixed.o aacpsdsp_fixed.o
+  sbrdsp_fixed.o aacpsdsp_fixed.o \
+  $(AAC_FIXED_DECODER-OBJS-yes)
 OBJS-$(CONFIG_AAC_ENCODER) += aacenc.o aaccoder.o aacenctab.o\
   aacpsy.o aactab.o  \
   aacenc_is.o \
   aacenc_tns.o \
   aacenc_ltp.o \
   aacenc_pred.o \
-  psymodel.o mpeg4audio.o kbdwin.o
+  psymodel.o mpeg4audio.o kbdwin.o \
+  $(AAC_ENCODER-OBJS-yes)
 OBJS-$(CONFIG_AASC_DECODER)+= aasc.o msrledec.o
 OBJS-$(CONFIG_AC3_DECODER) += ac3dec_float.o ac3dec_data.o ac3.o 
kbdwin.o
 OBJS-$(CONFIG_AC3_FIXED_DECODER)   += ac3dec_fixed.o ac3dec_data.o ac3.o 
kbdwin.o
@@ -979,7 +988,6 @@ TOOLS = fourcc2pixfmt
 HOSTPROGS = aacps_tablegen  \
 aacps_fixed_tablegen\
 cbrt_tablegen   \
-cbrt_fixed_tablegen \
 cos_tablegen\
 dv_tablegen \
 motionpixels_tablegen   \
@@ -993,6 +1001,7 @@ CLEANFILES = *_tables.c *_tables.h *_tablegen$(HOSTEXESUF)
 
 $(SUBDIR)dct-test$(EXESUF): $(SUBDIR)dctref.o $(SUBDIR)aandcttab.o
 $(SUBDIR)dv_tablegen$(HOSTEXESUF): $(SUBDIR)dvdata_host.o
+$(SUBDIR)cbrt_tablegen$(HOSTEXESUF): $(SUBDIR)cbrt_data.o
 
 TRIG_TABLES  = cos cos_fixed sin
 TRIG_TABLES := $(TRIG_TABLES:%=$(SUBDIR)%_tables.c)
@@ -1000,13 +1009,19 @@ TRIG_TABLES := $(TRIG_TABLES:%=$(SUBDIR)%_tables.c)
 $(TRIG_TABLES): $(SUBDIR)%_tables.c: $(SUBDIR)cos_tablegen$(HOSTEXESUF)
$(M)./$< $* > $@
 
+CBRT_TABLES  = cbrt
+C

Re: [FFmpeg-devel] [PATCH] Use matroska TrackNumber for populating AVStream::id

[Sergey Volk]

From: Sergey Volk 
Date: Wed, 9 Mar 2016 14:34:19 -0800
Subject: [PATCH] Change AVStream::id to int64_t in the next version bump

I have also bumped the major version to 58 locally in version.h, and
re-ran make with the stream id being int64_t and fixed all new
warnings that showed up (only saw new warnings related to the
incorrect format being used for int64_t value).
---
 ffprobe.c   | 8 +++-
 libavformat/avformat.h  | 4 
 libavformat/concatdec.c | 8 ++--
 libavformat/dump.c  | 4 
 libavformat/mpegtsenc.c | 7 ++-
 libavformat/version.h   | 3 +++
 6 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/ffprobe.c b/ffprobe.c
index f7b51ad..21eab61 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -2287,7 +2287,13 @@ static int show_stream(WriterContext *w,
AVFormatContext *fmt_ctx, int stream_id
 }
 }

-if (fmt_ctx->iformat->flags & AVFMT_SHOW_IDS) print_fmt("id",
"0x%x", stream->id);
+#if FF_API_OLD_INT32_STREAM_ID
+#define STREAM_ID_FORMAT "0x%x"
+#else
+#define STREAM_ID_FORMAT "0x%"PRIx64
+#endif
+if (fmt_ctx->iformat->flags & AVFMT_SHOW_IDS) print_fmt("id",
STREAM_ID_FORMAT, stream->id);
+#undef STREAM_ID_FORMAT
 else  print_str_opt("id", "N/A");
 print_q("r_frame_rate",   stream->r_frame_rate,   '/');
 print_q("avg_frame_rate", stream->avg_frame_rate, '/');
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index a558f2d..253b293 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -871,7 +871,11 @@ typedef struct AVStream {
  * decoding: set by libavformat
  * encoding: set by the user, replaced by libavformat if left unset
  */
+#if FF_API_OLD_INT32_STREAM_ID
 int id;
+#else
+int64_t id;
+#endif
 /**
  * Codec context associated with this stream. Allocated and freed by
  * libavformat.
diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index e69096f..481c8433 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -238,8 +238,12 @@ static int match_streams_exact_id(AVFormatContext *avf)
 for (j = 0; j < avf->nb_streams; j++) {
 if (avf->streams[j]->id == st->id) {
 av_log(avf, AV_LOG_VERBOSE,
-   "Match slave stream #%d with stream #%d id 0x%x\n",
-   i, j, st->id);
+#if FF_API_OLD_INT32_STREAM_ID
+   "Match slave stream #%d with stream #%d id 0x%x\n"
+#else
+   "Match slave stream #%d with stream #%d id
0x%"PRIx64"\n"
+#endif
+   , i, j, st->id);
 if ((ret = copy_stream_props(avf->streams[j], st)) < 0)
 return ret;
 cat->cur_file->streams[i].out_stream_index = j;
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 86bb82d..8b50ec1 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -453,7 +453,11 @@ static void dump_stream_format(AVFormatContext *ic, int i,
 /* the pid is an important information, so we display it */
 /* XXX: add a generic system */
 if (flags & AVFMT_SHOW_IDS)
+#if FF_API_OLD_INT32_STREAM_ID
 av_log(NULL, AV_LOG_INFO, "[0x%x]", st->id);
+#else
+av_log(NULL, AV_LOG_INFO, "[0x%"PRIx64"]", st->id);
+#endif
 if (lang)
 av_log(NULL, AV_LOG_INFO, "(%s)", lang->value);
 av_log(NULL, AV_LOG_DEBUG, ", %d, %d/%d", st->codec_info_nb_frames,
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 68f9867..0244b7f 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -833,7 +833,12 @@ static int mpegts_init(AVFormatContext *s)
 ts_st->pid = st->id;
 } else {
 av_log(s, AV_LOG_ERROR,
-   "Invalid stream id %d, must be less than 8191\n", st->id);
+#if FF_API_OLD_INT32_STREAM_ID
+   "Invalid stream id %d, must be less than 8191\n",
+#else
+   "Invalid stream id %"PRId64", must be less than 8191\n",
+#endif
+st->id);
 ret = AVERROR(EINVAL);
 goto fail;
 }
diff --git a/libavformat/version.h b/libavformat/version.h
index 7dcce2c..e0ac45a 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -74,6 +74,9 @@
 #ifndef FF_API_OLD_OPEN_CALLBACKS
 #define FF_API_OLD_OPEN_CALLBACKS   (LIBAVFORMAT_VERSION_MAJOR < 58)
 #endif
+#ifndef FF_API_OLD_INT32_STREAM_ID
+#define FF_API_OLD_INT32_STREAM_ID  (LIBAVFORMAT_VERSION_MAJOR < 58)
+#endif

 #ifndef FF_API_R_FRAME_RATE
 #define FF_API_R_FRAME_RATE1
-- 
2.7.0.rc3.207.g0ac5344

On Wed, Mar 9, 2016 at 3:55 PM, Sergey Volk  wrote:
> Ok, so then I guess we'll need to update AVStream::id to be 64-bit
> first, and then I'll make the necessary changes in matroskadec.
> I've prepared a patch to bump AVStream::id to be int64_t in the next
> major version, I'll send it out shortly. After I rebuilt ffmpeg
> with AVStream::id being int64_t I got 

Re: [FFmpeg-devel] [PATCH] lavc/lpc: exploit even symmetry of window function

[Ganesh Ajjanagadde]

On Wed, Mar 9, 2016 at 5:09 PM, Moritz Barsnick  wrote:
> On Tue, Mar 08, 2016 at 22:16:50 -0500, Ganesh Ajjanagadde wrote:
>> ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.22s user 0.03s system 105% 
>> cpu 4.970 total
>
> Just wondering: Is this the sin.flac from
> ffmpeg -f lavfi -i aevalsrc="sin(440*2*PI*t):s=48000" -t 300 -y sin.flac
> ??

Precisely from Andrey Utkin's remark on AAC perf drop, so yes.

>
> Is a sinusoidal signal good enough to benchmark an audio encoder? It
> only requires one very narrow frequency band, after all, no
> psychoacoustics, ...
>
> I don't see differences in general encoding speed of sine vs. noise,
> but I didn't check the influence on your code improvements. Agreed,
> noise doesn't do much for psychoacoustics probably either.

These are good points, but note that at some level all benchmarking
has the same flaws if they have variable execution length paths; i.e
what is the "holy grail" signal of interest. If you are a Bayesian,
you might place a prior on various signals; if you are a frequentist,
you could do a min-max over a class or check for Pareto dominance.

>
> (BTW, if just inspecting ffmpeg runtime without use of benchmarking
> start/stop markers, I use lavfi directly, to avoid the overhead of flac
> decoding. And not aevalsrc - sine and even anoisesrc are 10x faster.)

I am deliberately using this same command throughout all the patches I
send to give a uniform comparison of progress over time. I have noted
this for the future, thanks.

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

Re: [FFmpeg-devel] [PATCH] lavc/lpc: exploit even symmetry of window function

[Ganesh Ajjanagadde]

On Wed, Mar 9, 2016 at 1:32 PM, Reimar Döffinger
 wrote:
> On Wed, Mar 09, 2016 at 01:13:58PM +0100, Michael Niedermayer wrote:
>> On Tue, Mar 08, 2016 at 10:16:50PM -0500, Ganesh Ajjanagadde wrote:
>> > Yields 2x improvement in function performance, and boosts aac encoding
>> > speed by ~ 4% overall. Sample benchmark (Haswell+GCC under -march=native):
>> > after:
>> > ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.22s user 0.03s system 
>> > 105% cpu 4.970 total
>> >
>> > before:
>> > ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.40s user 0.05s system 
>> > 105% cpu 5.162 total
>> >
>> > Big shame that len-1 is -1 mod 4; 0 mod 4 would have yielded a further 2x 
>> > through
>> > additional symmetry. Of course, one could approximate with the 0 mod 4 
>> > variant,
>> > error would essentially be ~ 1/len in the worst case.
>> >
>> > Signed-off-by: Ganesh Ajjanagadde 
>> > ---
>> >  libavcodec/lpc.c | 3 ++-
>> >  1 file changed, 2 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/libavcodec/lpc.c b/libavcodec/lpc.c
>> > index 3839119..052aeaa 100644
>> > --- a/libavcodec/lpc.c
>> > +++ b/libavcodec/lpc.c
>> > @@ -176,9 +176,10 @@ double ff_lpc_calc_ref_coefs_f(LPCContext *s, const 
>> > float *samples, int len,
>> >  const double a = 0.5f, b = 1.0f - a;
>> >
>> >  /* Apply windowing */
>> > -for (i = 0; i < len; i++) {
>> > +for (i = 0; i <= len / 2; i++) {
>>
>> >  double weight = a - b*cos((2*M_PI*i)/(len - 1));
>>
>> the windows should not be recalcuated for each frame. But either
>> calculated once during init or calculated at first use if that makes
>> sense
>>
>> actually i suspect there should be close to 0 calls to libc math
>> functions after init in the encoder, or is there some use of these
>> functions in aac that cannot be replaced by a simple table?
>
> I don't understand the code, but I assumed that len changes
> regularly here, which is the main problem.
> I never actually checked if there is maybe only a small
> number of common values at least though.

So I did check this; len does change quite regularly. On the other
hand, it does not change too drastically over time, so a cache
approach could work at a significant code complexity increase for
minimal gain.

In fact, I personally have no idea why it is absolutely critical that
a Hamming window is used, see 0cfdaf45c4 where Welch was used
previously. At a first glance I think one can find a window that works
and avoids libm, e.g Parzen or other polynomial windows.
Rostislav, any thoughts?

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

Re: [FFmpeg-devel] [PATCH] lavc/aacenc_utils: replace powf(x, y) by expf(logf(x), y)

[Ganesh Ajjanagadde]

On Wed, Mar 9, 2016 at 2:16 AM, Reimar Döffinger
 wrote:
> On 08.03.2016, at 04:48, Ganesh Ajjanagadde  wrote:
>
>> +nzl += expf(logf(s / ethresh) * nzslope);
>
> Shouldn't log2f/exp2f be faster?
> log2f at least has CPU support on x86 AFAICT.

I had tested this, and no, though it is still faster than powf.

It still seems to rely on libm, note that we don't use -ffast-math and
a look at https://github.com/lattera/glibc/tree/master/sysdeps/x86_64/fpu
as well seems to say no. Problem is, GNU people like to prioritize
"correctly rounded" behavior over fast, reasonably accurate code,
sometimes to ludicruous degrees.

Personally, I don't know why we don't use -ffast-math, not many seem
to care that heavily on strict IEEE semantics. Maybe it leads to too
much variation across platforms?

> ___
> 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/2] avformat/concatdec: set safe mode to enabled instead of auto

[Michael Niedermayer]

On Wed, Jan 20, 2016 at 05:02:15PM +0100, Nicolas George wrote:
> Le decadi 30 nivôse, an CCXXIV, Michael Niedermayer a écrit :
> > This is safer, as a selected demuxer could still mean that it was 
> > auto-detected
> > by a user application
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/concatdec.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> No objection in principle, but the documentation needs updating as pointed
> out by Andreas. Also, without auto being the default, there is not much
> point in keeping auto at all, all the corresponding code could go; and if
> so, en extension can be declared (cf. 6cc1235).

applied
i can remove the auto feature but did not in this patch to make
backporting easier

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH 3/3] lavf/avienc: Add xxpc entries to index

[Mats Peterson]

On 03/09/2016 11:39 PM, Mats Peterson wrote:

Try playing the resulting test.avi file from the command line below with
Windows Media Player, with and without patch 2/3 and 3/3 (you'll need
patch 1/3 in order to get the xxpc chunks properly in the demuxer).

ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi

Mats




I should say "without patch 3/3" rather, since without patch 2, no video 
will be displayed whatsoever.


Mats

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

[FFmpeg-devel] [PATCH 2/3 v2] lavf/riffenc: Improve spec compliance

[Mats Peterson]

HuffYUV uses its own weird variant of the BITMAPINFOHEADER that *does* 
include the Huffman table size in biSize. That's the only exception as 
far as I know.


http://wiki.multimedia.cx/index.php?title=HuffYUV

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From d6cb26096e08e43a686ea67fd099ec523498f8b8 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Thu, 10 Mar 2016 08:13:00 +0100
Subject: [PATCH 2/3 v2] lavf/riffenc: Improve spec compliance

---
 libavformat/riffenc.c |   12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index 195a58e..c5bbc25 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -222,8 +222,13 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
 if (!enc->extradata_size && pal_avi)
 extradata_size = 4 * (1 << enc->bits_per_coded_sample);
 
-/* size */
-avio_wl32(pb, 40 + (ignore_extradata ? 0 :extradata_size));
+/*
+ * Size (not including the size of extra data like the color table or
+ * color masks).
+ * An exception is made for HuffYUV, which includes the size of the
+ * Huffman tables here.
+ */
+avio_wl32(pb, 40 + (enc->codec_id == AV_CODEC_ID_HUFFYUV ? extradata_size : 0));
 avio_wl32(pb, enc->width);
 //We always store RGB TopDown
 avio_wl32(pb, enc->codec_tag || keep_height ? enc->height : -enc->height);
@@ -236,7 +241,8 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
 avio_wl32(pb, (enc->width * enc->height * (enc->bits_per_coded_sample ? enc->bits_per_coded_sample : 24)+7) / 8);
 avio_wl32(pb, 0);
 avio_wl32(pb, 0);
-avio_wl32(pb, 0);
+/* number of color indices in the color table that are used */
+avio_wl32(pb, pal_avi ? 1 << enc->bits_per_coded_sample : 0);
 avio_wl32(pb, 0);
 
 if (!ignore_extradata) {
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH 2/3 v3] lavf/riffenc: Improve spec compliance

[Mats Peterson]

Respect "ignore_extradata", for what it's worth.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 8bdcc615499872b034c9b17a38d296aa74e31d09 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Thu, 10 Mar 2016 08:31:24 +0100
Subject: [PATCH 2/3 v3] lavf/riffenc: Improve spec compliance

---
 libavformat/riffenc.c |   13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index 195a58e..518b292 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -222,8 +222,14 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
 if (!enc->extradata_size && pal_avi)
 extradata_size = 4 * (1 << enc->bits_per_coded_sample);
 
-/* size */
-avio_wl32(pb, 40 + (ignore_extradata ? 0 :extradata_size));
+/*
+ * Size (not including the size of extra data like the color table or
+ * color masks).
+ * An exception is made for HuffYUV, which includes the size of the
+ * Huffman tables here.
+ */
+avio_wl32(pb, 40 + (ignore_extradata ||
+  enc->codec_id != AV_CODEC_ID_HUFFYUV ? 0 : extradata_size));
 avio_wl32(pb, enc->width);
 //We always store RGB TopDown
 avio_wl32(pb, enc->codec_tag || keep_height ? enc->height : -enc->height);
@@ -236,7 +242,8 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
 avio_wl32(pb, (enc->width * enc->height * (enc->bits_per_coded_sample ? enc->bits_per_coded_sample : 24)+7) / 8);
 avio_wl32(pb, 0);
 avio_wl32(pb, 0);
-avio_wl32(pb, 0);
+/* number of color indices in the color table that are used */
+avio_wl32(pb, pal_avi ? 1 << enc->bits_per_coded_sample : 0);
 avio_wl32(pb, 0);
 
 if (!ignore_extradata) {
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] lavc/aacenc_utils: replace powf(x, y) by expf(logf(x), y)

[Reimar Döffinger]

On 10.03.2016, at 03:06, Ganesh Ajjanagadde  wrote:

> On Wed, Mar 9, 2016 at 2:16 AM, Reimar Döffinger
>  wrote:
>> On 08.03.2016, at 04:48, Ganesh Ajjanagadde  wrote:
>> 
>>> +nzl += expf(logf(s / ethresh) * nzslope);
>> 
>> Shouldn't log2f/exp2f be faster?
>> log2f at least has CPU support on x86 AFAICT.
> 
> I had tested this, and no, though it is still faster than powf.
> 
> It still seems to rely on libm, note that we don't use -ffast-math and
> a look at https://github.com/lattera/glibc/tree/master/sysdeps/x86_64/fpu
> as well seems to say no. Problem is, GNU people like to prioritize
> "correctly rounded" behavior over fast, reasonably accurate code,
> sometimes to ludicruous degrees.
> 
> Personally, I don't know why we don't use -ffast-math, not many seem
> to care that heavily on strict IEEE semantics. Maybe it leads to too
> much variation across platforms?

You lose some guarantees. In particular, the compiler will assume NaNs do not 
happen and you cannot predict which code path (after a comparison for example) 
they take.
But some code for either security or correctness reasons needs them to be 
handled a certain way.
I guess in theory you could try to make sure fisnan is used in all those cases, 
but then you need to find them, and I think if you take -ffast-math description 
literally there is no guarantee that even fisnan continues to work... I am also 
not sure none of the code relies on order of operations to get the precision it 
needs.
So it is simply too dangerous.
Some more specific options might be possible to use though (but I think even 
full -ffast-math gains you almost nothing? Does it even help here?).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/aacenc_quantization: use cbrt table

[Hendrik Leppkes]

On Thu, Mar 10, 2016 at 12:49 AM, Ganesh Ajjanagadde  wrote:
> There is no reason for computing cbrtf at runtime; we have a table for
> this.
>
> Cruft needed due to the build system, the people who still like using
> hardcoded tables and need for single cbrt_tab across the code.
>

The build-system changes look *extremely* messy, I would rather not go
down that route.
Don't we have an example somewhere of a hardcoded table thats used by
multiple components with a cleaner solution? mpegaudio_tables.h looks
shared by the float and fixed decoder without magic special sauce?

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