Le nonidi 9 messidor, an CCXV, Reimar Döffinger a écrit :

If you use latest SVN that's not a known issue, no.

I tried with yesterday SVN, and there was no change concerning wmv3. I will report it on ffmpeg-devel.

...

- Using 64 bits windows DLLs. I have read that microsoft had finally released them, and I wonder if someone is working on it. I believe it when I see a link.

One of my friends pretends to have it installed on its windows box, and he can be trusted on technical matters. I have asked for details and links.

Sure, very interesting. As well as the possibility to let it run in a seccomp.

I did not think of that. On the other hand, I thought of running it on non-x86 architecture with qemu; not sure that the speed would be there though.

Not sure how you would do it in order not to duplicate a lot of effort and code.

AFAIK, the major part of a video decoder job is to take encoded data from a buffer, and put decoded data into another buffer. My plan would be: 1. Build the parts of libmpcodecs that can not be built in 64 bits in 32 bits into a libmpcodecs32. This is only makefile hacking. 2. Build a binary around this libmpcodecs32. That requires some protocol implementation (especially if I want to handle control messages), and importing or reimplementing some utility functions (mpcodecs_get_image). 3. Create a new decoder that fork+execs the binary and uses it for the decoding. This will take some work, but I think it can be done. Regards, -- Nicolas George

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 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. 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. Regards, -- Nicolas George

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); }

Le primidi 11 messidor, an CCXV, Reimar Döffinger a écrit :

YV12 with some wmv3 video produces incorrect colours, so you actually do loose a little bit by not allowing other formats.

Ok, I will try to take it into account. Do you have an example of such a file near at hand?

-pthread should not be needed, though it should not hurt either.

There is a pthread_create in win32.c; it is probably not called, but it needs to be resolved.

sizeof(BITMAPINFOHEADER) == 40, so you forgot the 4 additional bytes after the struct. Probably the decoder needs those, but only gets random data with your code.

Well spotted, thanks. I go back to my tests.

Hi Reimar Döffinger! On 2007.06.27 at 14:49:14 +0200, Reimar Döffinger wrote next:

I believe it when I see a link. It is rather hard to believe they would release codecs, given that there is not 64 bit "Windows Media Player" that could use it.

Well according to this http://www.softpedia.com/get/Multimedia/Video/Codec-Packs-Video-Codecs/Vista... there is. Of course, even windows has problems with 64-bit codecs (due to absence of indeo and other important ones), but there is a growing list of 3rd party 64-bit codecs. I unpacked this "vista codecs pack" (you don't need vista for that at all ;)) and following codecs are there audioswitcher.ax ff_samplerate.dll MpaDecFilter.ax audxlib.dll ff_theora.dll MpaSplitter.ax avi2ac3filter.ax ff_tremor.dll MpegSplitter.ax AviSplitter.ax ffvdub.vdf NutSplitter.ax custom matrices ff_wmv9.dll OggSplitter.ax DSMSplitter.ax ff_x264.dll shoutcastsource.ax dtsac3source.ax flicsource.ax SSFSplitter.ax ffdshow.ax languages streamdrivethru.ax ff_kernelDeint.dll libavcodec.dll TomsMoComp_ff.dll ff_liba52.dll libmpeg2_ff.dll udpreader.ax ff_libdts.dll libmplayer.dll VSFilter.dll ff_libfaad2.dll MatroskaMuxer.ax vtsreader.ax ff_libmad.dll MatroskaSplitter.ax wavdest.ax ff_realaac.dll MP4Splitter.ax nice list, isn't it? ;)

Actually, given that for all I know there is no 64 bit DirectX there actually would be no way at all to use them...

I can assure you that there is, I have access to windows 2003 64-bit (should be pretty the same as xp 64-bit) and both 32-bit and 64-bit versions of directx dlls are present. Anyway, one of my friends who is windows guru says that he tried to make vista 64-bit codecs work outside of vista and failed (the ones from the list above would work, of course). 64-bit WMV/WMA/etc codecs from MS are so heavily DRMed so it's basically impossible to use them outside 64-bit vista environment. Maybe it would be possible with custom dmo loader which mplayer uses, but I wouldn't count on it. -- Vladimir