On Fri, Dec 28, 2007 at 04:25:03AM +0100, Michael Niedermayer wrote:
> On Thu, Dec 27, 2007 at 06:59:19PM -0500, Rich Felker wrote:
> > On Thu, Dec 27, 2007 at 06:33:05PM +0000, M?ns Rullg?rd wrote:
> > > Rich Felker <dalias at aerifal.cx> writes:
> > >
> > > > Anyway, prototyping usleep is useless. It will work fine without a
> > > > prototype.
> > >
> > > It will only work until someone uses it with a float or wrong-sized
> > > int as argument. Prototypes exist for a reason. Do not ignore it.
> >
> > Again, the code in question is support for a broken platform. On any
> > nonbroken platform, the prototypes will exist. If the argument does
> > happen to have the wrong size I suppose strange windows-only bugs
> > could result, but very little code in ffmpeg has legitimate use for
> > usleep anyway... Actually I wonder why it's used at all.
>> Theres one on ffmpeg.c rate_emu code, this is valid, its argument is int64_t
>> Theres one in http.c since
> r464 | philipjsg | 2002-05-09 03:19:15 +0200 (Thu, 09 May 2002) | 3 lines
>> * Add a sleep when doing the post to ffserver. Yes, this is the wrong
> solution.
> ----
> This should be reverted at once!
>> Theres a large number of invalid looking uses in v4l.c. Theres also a
> invalid nanosleep in there. Luckily v4l2.c doesnt contain any.
> Ill take the liberty to remove the usleeps() together with the whole AIW
> support code. Whoever wants it has to clean it up. The code as it is, is
> not fit for ffmpeg svn (doing _uneeded_ colorspace convertion in v4l.c).
>> Theres also one in bktr.c
There's another nanosleep in x11grab.c.
Maybe #define usleep/nanosleep/usleep away in libavutil.
Diego