[MPlayer-dev-eng] x86_64 and windows codecs

[Reimar Doeffinger]

Hello,
On Fri, Jun 29, 2007 at 12:54:37PM +0200, Nicolas George wrote:
> Le nonidi 9 messidor, an CCXV, Reimar Döffinger a écrit :
> > Since finding out if a binary is 32 or 64 bits involves a major effort
> > on Windows I'm not convinced he actually checked...
> 
> I am quite sure he did, but I do not have the details yet.

I did not check 64 bit Vista, so it could well be. Neither did I have 64
bit W2K3 installed for long, so I might have overlooked something.

> > I think this is a very bad idea, involving a major effort, libmpcodecs
> > has strong dependencies in MPlayer and a lot of information that is
> > simply useless for decoding.
> > I think you should better consider providing RPC-like stubs of (for
> > decoding DMO):
> > DMO_VideoDecoder_Open
> > DMO_VideoDecoder_SetDestFmt
> > DMO_VideoDecoder_StartInternal
> > DMO_VideoDecoder_Destroy
> > DMO_VideoDecoder_DecodeInternal
> > 
> > To implement these you need only the loader code, which should be much
> > easier to compile stand-alone.
> 
> My idea was that since libmpcodecs is higher-level than loader, embedding it
> would require actually less code duplication.

Hardly since you always must extract loader, no way it can work without
it.

> I tried a quick and dirty approach to see by myself the amount of work. I
> have managed to build a stand-alone binary embedding vd_dmo, vd_dshow,
> vd_qtvideo and vd_vfw. It does absolutely nothing, but there is no undefined
> symbol. To achieve that, I had to define the following stubs:
> 
> mpcodecs_get_image
> mpcodecs_config_vo
> mp_msg
> mp_msg_test
> get_path
> gCpuCaps
> divx_quality
> vo_format_name
> print_video_header
> 
> I do not see anything monstrous.

Well, I see the problem if implementing functions like mp_msg, mpcodecs_config_vo
and variables lib vo_format_name etc. because they must either be
replaced by complete dummies or you need a way to call functions and
access variables that currently aren't in function arguments from the
32 bit to the 64 bit binary (I admit the mp_msg problem still exists
even when splitting out only the loader, but it is in less places).
For the DMO functions all data you need is already in the functions call
arguments and the data they point to may be passed via shared memory.
As far as security is concerned (if you care about the seccomp idea) it
also seems much easier to check the DMO function return values for
correctness than e.g. the mpcodecs_config_vo parameters.

Greetings,
Reimar Doeffinger