The new code is faster and reuses the previous state in case of
multiple calls.
The previous code could easily end up in near-infinite loops,
if the difference between two clock() calls never was larger than
1.
This makes fate-parseutils finish in finite time when run in wine,
if CryptGenRandom isn't available (which e.g. isn't available if
targeting Windows RT/metro).
Patch originally by Michael Niedermayer but with some modifications
by Martin Storsjö.
Signed-off-by: Martin Storsjö <martin@martin.st>
unistd.h is used for open/read/close, but if this header does not
exist, there's probably no use in trying to open /dev/*random
at all.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is clearer than comparing against an unsigned number to force an unsigned
comparison that we need.
Originally committed as revision 24114 to svn://svn.ffmpeg.org/ffmpeg/trunk
If both /dev/random and /dev/urandom failed to return data, an
uninitialised value might be returned. Since most systems have a
non-blocking /dev/urandom or have /dev/random with similar properties,
the chance of blocking is minimal, and the alternative of returning
non-random data is worse.
Originally committed as revision 23930 to svn://svn.ffmpeg.org/ffmpeg/trunk
Attempt to read from /dev/urandom and /dev/random with O_NONBLOCK set.
If neither succeeds, proceed with fallbacks.
Originally committed as revision 23903 to svn://svn.ffmpeg.org/ffmpeg/trunk
Keep an old ff_ named function for binary compatibility until the
next major bump.
Originally committed as revision 23254 to svn://svn.ffmpeg.org/ffmpeg/trunk
include paths in the source files.
mostly from a patch by Ronald S. Bultje, rbultje ronald.bitfreak net
Originally committed as revision 9034 to svn://svn.ffmpeg.org/ffmpeg/trunk
armv5t does - use the armv5t function rather than default c code.
patch by Tim Chick chick at computergeek freeserve co uk
Originally committed as revision 8487 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Siarhei Siamashka % siarhei P siamashka A gmail P com %
Original thread:
Date: Jan 6, 2007 5:07 PM
Subject: [Ffmpeg-devel] [PATCH] Optimization of 'dct_unquantize_h263_intra' for ARM (armv5te) (try2)
and
Date: Jan 2, 2007 6:13 PM
Subject: [Ffmpeg-devel] [PATCH] Optimization of 'dct_unquantize_h263_intra' for ARM (armv5te)
Originally committed as revision 7423 to svn://svn.ffmpeg.org/ffmpeg/trunk
while playing with some new hardware, I found it's running a forked mplayer
-- and it looks like they're following the GPL.
The maintainer's page is here: http://atty.jp/?Zaurus/mplayer
Unfortunately it's mostly in Japanese, so it's hard to figure out any
details.
Their code looks quite interesting (at least to those of us w/ ARM CPUs).
The patches I've attached are the patches from atty.jp with a couple of
modifications by myself:
- ported to current CVS
- reverted their change of removing SNOW support from ffmpeg
- cleaned up their bswap mess
- removed DOS-style linebreaks from various files
patch by (Bernhard Rosenkraenzer: bero, arklinux org)
Originally committed as revision 4311 to svn://svn.ffmpeg.org/ffmpeg/trunk
Michael Niedermayer
Rémi Denis-Courmont
Martin Storsjö
Ronald S. Bultje
Yordan Makariev
Mans Rullgard
Anton Khirnov
Baptiste Coudurier
Aurelien Jacobs
Vitor Sessak
Diego Biurrun
Tim Chick
Siarhei Siamashka
Bernhard Rosenkränzer
Zdenek Kabelac
Fabrice Bellard