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>
The new code is faster and reuses the previous state in case of
multiple calls. For testing the iterations are reduced and several
entropy sources are disabled.
Its based on SHA-1
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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