[MPlayer-dev-eng] hmm. one step closer to sorenson.

Arpi arpi at thot.banki.hu
Mon Dec 31 05:01:58 CET 2001


Hi,

> > next step?
> > getting mplayer's loader/qtx/qtxload.c working, at least at level of codec
> > being initialized. we should catch the function pointer of sorenson codec at
> > GetProcAddress, and dump every calls to it. this way we should be able to
> > dump and understand data structure passed to the codec.
> > any volunteers? :)
> 
> 	I'm not sure if I follow what you want to do here. Are you looking
> for Sorenson in a neat little binary codec that just handles SVQ1
> decoding? Or is this a method for loading the Quicktime.qts file and
> exploiting the routines buried deep within?

Loading that not-so-small (4MB) Quicktime.qts, and getting its built-in
codecs working. To get it, we have to reverse engineer the wrapper between
quicktime applications and codec plugins. The qt SDK is nice, big, but has
only dummy placeholders for the important structs, and has a static
closedsource library containing functions to manage plugin registration,
search and access.

As I said before, I see no sense of trying to reverse engineeer the sorenson
algorithm itself, as there are lots of codecs requires (including sorenson
v1,v2,v3 and their audio codecs) so it's better to get their codec work first.

QuickTime.qts is big, really big, but it seems to contains independent
plugins packed together. At least I could address them and get them opened,
but for initialization and use i have to pass some general plugin descriptor
struct pointer, which is unknown (has only placeholder in sdk).
I think, if we can find out the struct, and filled by right values, we are
done, at least we can jump to next step.


A'rpi / Astral & ESP-team

--
mailto:arpi at thot.banki.hu
http://esp-team.scene.hu



More information about the MPlayer-dev-eng mailing list