[FFmpeg-devel] [PATCH] support encrypted asf
Wed Oct 10 00:45:56 CEST 2007
On Wed, Oct 10, 2007 at 12:05:23AM +0200, Reimar D?ffinger wrote:
> [... DES code ...]
> > hmm, this doesnt look remotely optimal, maybe you should look at
> > john the ripper IIRC it contains quite fast DES code. though surely far too
> > messy for us to use directly but i guess the ideas used in it could be
> > applied to our code as well
> DES is a mess as it is, it seems unlikely it well ever get any new use,
then why is it used in asf DRM?
> it was designed for hardware that was a factor 100 slower than todays,
> the fast implementations I have seen use several KB of messy tables, and
the fast implementations use 4kb of tables and much simpler code than yours
IIRC, at least for their main loop
> for ASF it is used to decode about 8 bytes out of over 1000.
> I really don't see any point in optimizing the _speed_ of this thing,
for ASF no, no sense at all, but then it has to stay non public in
libavformat, publically available DES code must be fast
> there really are enough fast DES implementations, this one seems rather
> unique in that it uses less than 1 KB of tables and is very close to the
> specification, I would very much prefer to keep it like that (well, at
> least the general idea, not in the details).
well i dont want to think about how a close to the spec h.264 decoder would
no, i really dont think being close to the spec is a desireable goal
less than 1kb tables surely is, that is if the extra code needed is less than
the 3kb you gain
id say the des code needs more throughout review about what effect various
oprimizations would have on code/table size and speed ...
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel