[MPlayer-dev-eng] x86_64 and windows codecs

Nicolas George nicolas.george at ens.fr
Fri Jun 29 17:55:02 CEST 2007


Le primidi 11 messidor, an CCXV, Reimar Doeffinger a écrit :
> Hardly since you always must extract loader, no way it can work without
> it.

I think I misunderstood what you were suggesting, I see better now. Yes,
that could be an easy solution, but I fear the protocol would need a bit
more work.

Unfortunately, right now, I am stuck with either approaches. See below for
details on my problem.

> 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

That is not really an issue: global variables can always be passed as
invisible arguments added by the RPC mechanism.

The negotiation of pixel format in mpcodecs_config_vo could be more a
problem, but I believe that it can be evacuated by deciding that all decoded
data will be in YV12. ffmpeg's colorspace converters are probably better
than microsoft's anyway...


I have tried further to implement things, but I am stuck with a
non-deterministic bug in the loader. I try a minimalistic program (at the
end of this mail). All it does it call DMO_VideoDecoder_Open. I build it
with:

cc -I /tmp/mplayer -Wall -O4 -pthread -o testdmo main0.c \
  -L /tmp/mplayer/loader -lloader /tmp/mplayer/osdep/mmap_anon.o \
  /tmp/mplayer/cpudetect.o -lm

/tmp/mplayer is a compilation tree, and the system is pure 32 bits (it's a
Pentium 4).

The result is that sometimes it work, and sometimes it fails with
"IMediaObject ERROR: 0x805b369  input format not accepted (0x80040205 :
-2147220987)", with probability about 1/2. Changing compilation options,
compiling with -m32 on a Core2, etc., gives the same result.

I am at a loss to find what I am doing wrong. As far as I can see, mplayer
does exactly the same call, and it succeeds each time.

If someone who understands the inner workings of the loader can enlighten
me, that would be very helpful.

Regards,

-- 
  Nicolas George


<-------------------------------- main0.c -------------------------------->

#include <stdio.h>
#include <stdlib.h>
#include "codec-cfg.h"
#include "stream/stream.h"
#include "libmpdemux/demuxer.h"
#include "libmpdemux/stheader.h"
#include "cpudetect.h"
#include "codecs.conf.h"
#include "loader/dmo/DMO_VideoDecoder.h"

void
mp_msg(int mod, int lev, const char *format, ... )
{
}

int
mp_msg_test(int mod, int lev)
{
    return(0);
}

char *
get_path(void)
{
    return("/tmp/registry");
}

int
main(void)
{
    /* values from guignols-20070622.wmv */
    BITMAPINFOHEADER bih = {
        .biSize = 44,
        .biWidth = 240,
        .biHeight = 180,
        .biPlanes = 1,
        .biBitCount = 24,
        .biCompression = 0x33564D57,
        .biSizeImage = 0,
        .biXPelsPerMeter = 0,
        .biYPelsPerMeter = 0,
        .biClrUsed = 0,
        .biClrImportant = 0,
    };

    /* 73 is wmv9dmod.dll */
    printf("73 -> %s\n", builtin_video_codecs[73].dll);
    GetCpuCaps(&gCpuCaps);
    DMO_VideoDecoder_Open(builtin_video_codecs[73].dll,
        &builtin_video_codecs[73].guid, &bih, 0, 0);
    return(0);
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070629/f18ad5b3/attachment.pgp>


More information about the MPlayer-dev-eng mailing list