[FFmpeg-devel] [PATCH] swr: general doxy text about swr and example code.

[Clément Bœsch]

On Tue, Nov 20, 2012 at 07:48:18PM +0100, Michael Niedermayer wrote:
[...]
> > OTOH, some clarifications about the out_samples computation would be
> > welcome; for example I'm curious in what case you would want to get a
> > delay with a parameter different than the output sample rate (though, that
> > is quiet unrelated to this example).
> 
> hmm, ill try to improve the swr_get_delay() doxy

Thanks :)

> or do you think it should be explained elsewhere ?
> 

I think it's fine in the swr_get_delay() doxy.

[...]
> > > + *  conversion context and everything associated with it must be freed with
> > > + *  swr_free().
> > > + */
> > >  
> > >  #include <inttypes.h>
> > 
> > unrelated: stdint.h is not enough?
> 
> My principle with headers is, add if compile fails, its not failing.
> Iam quite sure though we could invest time to make the includes a
> tighter subset which then will cause failures and the need to add more
> inlcudes earlier on future changes ...
> In the end this smells like work to add more work.

In this particular case of a public header I think it's important to keep
it clean for apps willing to do such "work". This header just needs
[u]int*_t types for prototypes, it looks pretty safe to just include
stdint.h.

> Or is it faster even by little if stdint.h is used instead of
> inttypes.h ?
> 

I didn't bench, but inttypes start by including stdint.h and then defines
random things, so it's in theory slower to include it. Also, given how
crazy glibc headers can be, it wouldn't surprise me if it slowed down
compilation on modest machines.

[...]

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121120/bf6428a2/attachment.asc>