[ravemax]

in middle of april alan nisota released two patches, which allows to use the coreavc directshow in mplayer:
* mplayer mailinglist. patch for coreavc 0.0.4
* doom9 board. coreavc 1.0

like many people in the nero digital mpeg-4 avc / x264 support thread i thought "hey that is perfect for the xbmc".
so first, i build a custom mplayer.dll with the 0.0.4 patch applied and copied it onto the xbox.
btw, please note that since i can't affort the 1.0 at the moment - i am quite broke - i do all the tests with the 0.0.4 which is probably illegal since it was only released for testing purposes.
but it didn't work:
xbmc.log (only some interesting lines)

debug   msg:opening video decoder: [dshow] directshow video codecs
debug loadlibrarya('coreavcdecoder.ax')
error dll coreavcdecoder.ax was not found in path
debug getmodulehandlea(kernel32.dll) .. looking up
debug getmodulehandlea('kernel32.dll') => 0x6812b0
warning unable to resolve: kernel32.dll flsalloc
debug kernel32.dll!getprocaddress(0x6812b0, 'flsalloc') => 0x0
:
debug loadlibrary('coreavcdecoder.ax') returning: 0x8e07e0
debug coreavcdecoder.ax!getprocaddress(0x8e07e0, 'dllgetclassobject') => 0x15a57d0
debug   msg:decoder supports the following yuv formats:
debug   msg:yuy2
debug   msg:iyuv
debug   msg:yv12
debug   msg:i420
debug   msg:decoder is capable of yuv output (flags 0x27)
debug   msg:vdec: vo config request - 640 x 480 (preferred csp: packed yuy2)
debug   msg:[pp] using codec's postprocessing, max q = 4.
debug   msg:vdec: using planar yv12 as output csp (no 0)
debug   msg:movie-aspect is undefined - no prescaling applied.
debug   msg:vo: [directx] 640x480 => 640x480 planar yv12
debug created yv12 texture 1
debug created yv12 texture 0
warning ol32.dll fake function cocreateinstance called
error cmplayer::openfile() e:\media\video\[k-f]_one_piece_169_[e977a001].mp4 failed

the xbmc dllloader were unable to resolve the following symbols:
- flsalloc
- flsgetvalue
- flssetvalue
- flsfree
- encodepointer
- decodepointer

therefore, i added the missing functions to the kernel32.dll emulation (xbmc/xbmc/xbmc/cores/dllloader/exports) layer:
xbm_exports-2006-04-28.zip
and a nice person in #xbmc build me a default.xbe with the modified files.

debug: getmodulehandlea('kernel32.dll') => 0x8dda78
debug: kernel32.dll!getprocaddress(0x8dda78, 'flsalloc') => 0x171674
:
error: cmplayer::openfile() e:\media\video\[k-f]_one_piece_169_[e977a001].mp4 failed

unlike before, the xbmc was able to resolve the symbols, but still it did not work.

so i guess i have to take a further look into the "cmplayer::openfile" methods...

[Caldor]

awesome. i can help you out with testing if you like - i've got over a decade of experience testing software professionally and an interest in digital media.

being able to do full pal resolution anamorphic encodes using high profile avc like in sharktooth's profiles really would be excellent.

maybe we can get donations going to help you get the 1.0 license?

[ravemax]

ok, i did some additional - unsuccessful - tests...

the mplayer from the xbmc-cvs still works in windows. all you got to do is to remove the "ad_aiffpcm.c" from libmpcodecs/makefile. the just run "configure" - without "-d_xbox", etc.. while this build plays h264 files using ffmpeg, it crashs with coreavc :-(

[elupus]

well that is a good thing

easier to debug such stuff on windows than on the xbox.

[ravemax]

still trying.. i don't give up yet.
i enabled the output of the directshow messages and compared the logs of the win32 and the xbox version:

videodecoder::setextattr: registry failure

only on win32, but it doesn't matter because it's for the old divx filter anyway.

selected video codec: [coreavc] (..)

only shows up on win32, while xbmc gives a

cmplayer::openfile() (..) failed

so what happens between those two lines? mplayer starts the decoder (ds_videodecoder_startinternal : memallocator_commit, cmediasample_create).
what's weird is that all functions are called within "init_best_video_codec" - every quitting is accompanied by a log-message, e.g. "selected" like above. but their ain't a message on the xbox??

[edit] forgot to mention that the logs are otherwise equal, e.g. the "filter-wiring" seems to be correct.

[edit2] debug ol32.dll fake function cocreateinstance called <- forgot this one. message before the ".. failed".

[edit3] hmm i just read microsofts cocreateinstance documentation and it seems that its actually quite important. time to replace the "fake" with a real emulation.

[ravemax]

i did some investigation in respects of cocreateinstance.

i added some lines of code, which write the rclsid (class identifier) and the riid (interface identifier) passed to the -fake- cocreateinstance (dllloader/exports/emu_ole32.cpp) to the log.

- rclsid = 1e651cc0, b199, 11d0 - 82 12 00 c0 4f c3 2c 45
- riid   = 56a8689c, 0ad4, 11ce - b0 3a 00 20 af 0b a7 70

just for curiosity, i disassembled coreavcdecoder.ax with ida and found the corresponding cocreateinstance call at address 10022dca. maybe this is useful later on.

now to the interesting part: the rclsid/riid isn't a special class, but the normal memory-allocator:
both are defined in "mplayer/loader/dshow/guids.c":
- clsid_memoryallocator (rclsid)
- iid_imemallocator (riid)

so what's missing? borrow some code from "mplayer/loader/win32.c" to have a proper cocreateinstance emulation. plus maybe a call to "registercomclass", as found in "dshow/allocator.c".

@elupus: do you think that "xobjbase.h" could be useful, or should i just "upgrade" emu_ole32.cpp?

[elupus]

it could potentially be usefull to use that header. if there is help to do the emulation in the xdk, please use that.. the xdk does have very much in common with normal windows.

sound like you are on the right track thou. you probably need that allocator, as the mplayer we use expect that to exist in the system already since we try to behave as much as normal windows as possible. so the loader in our version of mplayer is pretty much disabled if i remember correctly.

those stuff could be usefull if we want to add support for more directshow stuff for the dvdplayer for example

[ravemax]

@any dev:
i wonder if it possible to call an xbmc function from mplayer.dll - and if then how?

[darkie]

yes, that is possible. but why do you want todo that?

[ravemax]

the mplayer.dll contains a function (loader/dshow/allocator.c: memallocator_createallocator) which creates a memory-allocator. what i want to do is to pass the address of this function to an xbmc function called "registercomclass" (xbmc/cores/dllloader/exports/emu_ole32.cpp), store it in a variable and then call the mplayer-function at some later time.

mplayer:allocator.c:

int memallocator_createallocator(/*args*/) { /* .. do something */}
registercomclass(&memallocator_createallocator);

xbmc:emu_ole32.cpp:

typedef int (*comfunction)(/*args*/);

static comfunction func;
void registercomclass(comfunction newfunc) {
  func = newfunc;
}
void someotherfunction() {
  func(/*args*/);
}

((edit: couldn't resist ))

<span style='font-family:courier'>mplayer                                  xbmc
 |                                        |
 |---( registercomclass:             )--->|
 |   ( &memallocator_createallocator )    |
 |                                        |
 |<--( memallocator_createallocator: )----|
 |   ( /*args */                     )    |</span>

[ravemax]

^-- no longer necessary to answer this post, but i am still curious how mplayer would call an xbmc method...

mplayer:loader/dshow/allocator.c

- static long memallocator_createallocator(guid* clsid, const guid* iid, void** ppv)
+ long memallocator_createallocator(guid* clsid, const guid* iid, void** ppv)
{
 :
+  debug printf("memallocator_createallocator(...) called\n");

mplayer:mplayer.def

+ memallocator_createallocator @ 65;

xbmc:xbmc/xbmc/cores/mplayer/mplayer.cpp:

+ long (__cdecl* pmemallocatorcreateallocator)(void* clsid, const void* iid, void** ppv);
+   long mplayer_memallocator_createallocator(void* clsid, const void* iid, void** ppv)
+  {
+    if (pmemallocatorcreateallocator)
+      return pmemallocatorcreateallocator(clsid, iid, ppv);
+    return -1;
+  }
+  dll.resolveexport("memallocator_createallocator", (void**)&pmemallocatorcreateallocator);

xbmc:xbmc/xbmc/cores/dllloader/exports/emu_ole32.cpp

+ #include <guiddef.h>
+ #include "..\..\mplayer\mplayer.h"

+ const guid clsid_memoryallocator={0x1e651cc0, 0xb199, 0x11d0,
+    {0x82, 0x12, 0x00, 0xc0, 0x4f, 0xc3, 0x2c, 0x45}};

- extern "c" hresult dllcocreateinstance( refclsid rclsid, lpunknown punkouter, dword dwclscontext, refiid riid)
+ extern "c" hresult dllcocreateinstance( refclsid rclsid, lpunknown punkouter, dword dwclscontext, refiid riid, lpvoid * ppv)
{
+  if (!memcmp((void*)&rclsid, (void*)&clsid_memoryallocator, sizeof(guid)))
+    return mplayer_memallocator_createallocator((void*)&rclsid, (void*)&riid, ppv);
 return regdb_e_classnotreg;

[ravemax]

continuation ... seems the post above was to long...
so what happens? coreavcdecoder.ax calls "dllcocreateinstance" and this calls "mplayer_memalloc(..)" if coreavc requests the allocator, what it does:

debug:   msg: memallocator_createallocator(...) called
debug:   msg: memallocatorcreate() called -> 01229010
error: cmplayer::openfile() e:\media\video\[k-f]_one_piece_169_[e977a001]___hd.mp4 failed

but it still doesn't work guess i'll add some additional debug messages to the mplayer.dll as i have no windows pc -> no debugging on the xbox.

[jblade]

i encourage to keep on working on this, i dont know how well the xbox will support the hd content, but i am highly anticipating the addition of coreavc. i dunno if this is legal to post here or not, but here is the link to 1.0.0

pike edit: warez links are never legal

both of those have it, the second link has the codecs seperated diffrently, but i think ull be able to figure it out.

[ashlar]

ravemax, i see you are devoting a lot of time to this. thanks, i really appreciate it. i'm sorry of not being able to help in any way.

[jblade]

ravemax, pm me about the 1.0 version. ill supply you with the one i bought.