XBMC and CoreAVC (not yet)
January 8th, 2009
* mplayer mailinglist. patch for coreavc 0.0.4 (http://archives.free.net.ph/message/20060331.210050.da1641a9.en.html)
* doom9 board. coreavc 1.0 (http://forum.doom9.org/showpost.php?p=813281&postcount=1114)
like many people in the nero digital mpeg-4 avc / x264 support (http://www.xboxmediaplayer.de/cgi-bin/forums/ikonboard.pl?act=st;f=4;t=8555;st=120) 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 (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/flsalloc.asp)
- flsgetvalue (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/flsgetvalue.asp)
- flssetvalue (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/flssetvalue.asp)
- flsfree (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/flsfree.asp)
- encodepointer (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devnotes/winprog/encodepointer_func.asp)
- decodepointer (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devnotes/winprog/decodepointer_func.asp)
therefore, i added the missing functions to the kernel32.dll emulation (xbmc/xbmc/xbmc/cores/dllloader/exports) layer:
xbm_exports-2006-04-28.zip (http://www.feedface.com/patrick/_tmpshare/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...
but i've have no intention on making it available to general users, since I don't feel like getting shit from corecodec when users start using pirated version of it. and this is final untill someone from corecodec tell me to go ahead and how to wish me to handle licencing information.
not to mention the fact that a mplayer with coreavc support totally crashes xbmc when invalid or no licening info is available.
They have also already done some benchmarks in which they decode some AVC videos to show the difference between the latest FFh264 (the MPEG-4-AVC H.264 decoder code in FFmpeg) are CoreAVC on MPlayer, and here are those result:These benchmark were done on a Linux computer with a Pentium-4 2.8GHz,
(512K Level2 cache Intel Northwood CPU) with Hyper-Threading disabled.
Each stream was benchmarked 3 times with the average result used
(reproducibilty was very good)
encoding was done using:
mencoder -ovc x264 -oac mp3lame -vf scale=320x180 -srate 8000
-lameopts cbr:br=48 -x264encopts xxxx
decoding was done using:
mplayer -vc coreavc/ffh264 -vo null -nosound -benchmark
frame comparison was done using:
mplayer -vc coreavc/ffh264 -vo md5sum -nosound
every frame was different. I guess the next step would be to do a
frame diff but let's do this one step at a time. The one thing I can
say is that the output from CoreAVC looks very good.
Note! CABAC / CAVLC, and loop filter / disabled loop filter was not tested!
320x180_lo_no_b.avi: AVC: 1.6983 FFh264: 2.1397 Diff: 20.63%
320x180_no_b.avi: AVC: 2.5720 FFh264: 3.6647 Diff: 29.82%
320x180_2_b.avi: AVC: 3.0217 FFh264: 4.3490 Diff: 30.52%
320x180_only_i.avi: AVC: 3.6400 FFh264: 5.5330 Diff: 34.21%
640x360_lo_no_b.avi: AVC: 7.4727 FFh264: 9.0733 Diff: 17.64%
640x360_no_b.avi: AVC: 11.6083 FFh264: 15.1547 Diff: 23.40%
640x360_2_b.avi: AVC: 13.2737 FFh264: 17.6897 Diff: 24.96%
640x360_only_i.avi: AVC: 13.9900 FFh264: 20.8660 Diff: 32.95%
960x540_lo_no_b.avi: AVC: 16.3263 FFh264: 19.5637 Diff: 16.55%
960x540_no_b.avi: AVC: 25.7600 FFh264: 34.7473 Diff: 25.86%
960x540_2_b.avi: AVC: 29.5473 FFh264: 40.3160 Diff: 26.71%
960x540_only_i.avi: AVC: 32.3753 FFh264: 47.0533 Diff: 31.19%
1280x720_lo_no_b.avi: AVC: 28.5677 FFh264: 34.8783 Diff: 18.09%
1280x720_no_b.avi: AVC: 46.9833 FFh264: 62.9510 Diff: 25.36%
1280x720_2_b.avi: AVC: 51.2857 FFh264: 70.2810 Diff: 27.01%
1280x720_only_i.avi: AVC: 56.2217 FFh264: 81.0200 Diff: 30.61%If the same 20-30% FPS speed increase also holds true for videos encoded with CABAC, CAVLC or LOOP (DEBLOCKING) then XBMC might be able to pull of decoding of 480p (720x480) H.264 AVC videos on the Xbox in the future, which would be great.
However, those who thought they someday would see 720p (1280x720 progressive) or 1080i (1920x1080 interlanced) playback of H.264 AVC videos on the Xbox 733Mhz CPU will be disappointed by these results.
So on the Xbox's 733Mhz Intel Pentium III processor CoreAVC might be able to produce what compared to FFmpeg?, 1 more FPS?
More info here:
http://code.google.com/p/coreavc-for-linux/
CoreAVC decoder could probebely do 576p at best on an Xbox, (so 720x576).
Yesterday a new (updated) CoreAVC h264 codec patch was submitted to the MPlayer-dev-eng mailing-list (http://www.mplayerhq.hu/design7/mailing_lists.html) (that's the mailing-list for developer of MPlayer for Linux/Win32)Date: Mon, 2 Oct 2006 18:20:59 -0700
From: "Alan Nisota"
Subject: [MPlayer-dev-eng] [PATCH]Add support for CoreAVC h264 codec
To: mplayer-dev-eng@mplayerhq.hu
Cc: dbzdeath87@yahoo.com.au
Message-ID:
Content-Type: text/plain; charset="iso-8859-1"
I posted a similar patch to the mplayer-cygwin list 6 months ago, but
figured I might as well clean it up and post it here in case mplayer
devs are interested in using it.
What it does is to enhance the dshow codec support such that the
CoreAVC h264 codec will run under mplayer. This codec is ~30% more
efficient than ffh264 by my testing with mplayer.
As this codec must be registered, it requires registry entries be
present to use. I have added support for updating registry entries
throgh the codecs.conf file to support this.
There are changes to the wine code to support the codec, including
some nasty tricks with the memory handler which may not be portable.
There are also changes to the dshow filter code to pass correct data
to the codec for intialization. These changes need to be tested to
make sure they don't break other dshow codecs.
Anyhow, the patch is built against SVN 20017.
Install the patch, then add the following to your codecs.conf file:
videocodec coreavc
info "CoreAVC DShow H264 decoder for x86 - http://corecodec.org/"
status untested
format 0x10000005
fourcc H264,h264
fourcc X264,x264
fourcc avc1,AVC1
fourcc davc,DAVC
fourcc VSSH
driver dshow
dll "CoreAVCDecoder.ax"
regval "SOFTWARE\Licenturion GmbH\0000032D\Product Key"
"ABCD-EFGH-IJKL-MNOP-QRST-UVWX"
regval "SOFTWARE\Licenturion GmbH\0000032D\User ID" "Joe User"
guid 0x09571a4b, 0xf1fe, 0x4c60, 0x97, 0x60, 0xde, 0x6d, 0x31, 0x0c,
0x7c, 0x31
out YV12,IYUV,I420,YUY2
(replace the User Id and Product Key with your registration
key...which can be obtained via regedit or by installing under wine,
and getting the values from the user.reg file)
It has been tested with CoreAVC 0.0.4, 1.0, and 1.1.0.5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: coreavc.patch
Type: application/octet-stream
Size: 21506 bytes
Desc: not available
Url :
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20061002/eee59c4b/coreavc.obj
------------------------------
_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng@mplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-engThe discussion can be followed here: [PATCH]Add support for CoreAVC h264 codec (link) (http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2006-October/thread.html#46422)
easier to debug such stuff on windows than on the xbox.
on a sidenote, since the calling convention was wrong for that function, it is likely wrong for others we have too. would be nice to fixup.
but i just had a quick look at "c calling conventions". i always thought that the caller function handles the stack manipulation (esp) for the arguments, while the called function handles it for variables. but it seems that in some calling conventions, e.g. some win32 specific ones, where the called function is also responsible for the argument cleanup... more to follow.
keep it up. :thumbsup:
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.
However I don't think this will 'Fix' the h.264 problem, merely make it less pronounced. There are cases where certian complicated h.264 480p encoded videos on the Xbox drop to about 1fps when decoding, a 30% increase in decoding speed would not eliminate these cases.
Also, addressing something previously said in this thread about 720p and how the Xbox will never decode native 720p video sources. That's quite a lie. I've done it without dropping frames at all, you just have to use MPEG-2. :) Which, while you may laugh at it, we use XBMC to turn Xbox's into streaming video set top boxes taking feeds from a VLC server. The quality is quite nice when you considder that network bandwidth is cheaper than CPU power :)
interesting :]
So if you guys want to see CoreAVC support in XBMC someday then you need to lobby it to the MPlayer developers (http://www.xboxmediacenter.com/wiki/index.php?title=Codec_and_Format_requests) first.
http://www.xboxmediacenter.com/wiki/index.php?title=Codec_and_Format_requests
http://code.google.com/p/coreavc-for-linux/
Please read this on how to do and what to expect when making a codec and format requests (link) (http://www.xboxmediacenter.com/wiki/index.php?title=Codec_and_Format_requests) :nerd:
the included "mplayer.patch" contains alan nisota's as well as my (small) changes.
unlike before, xbmc now crashes - so it seems - within the coreavc decoder and not in mplayer. this makes debugging even more horrible.
unable to resolve: kernel32.dll decodepointer
kernel32.dll!getprocaddress(0x1113968, 'decodepointer') => 0x0
same with encodepointer.. that could easily lead to an exception if it tries to do something on that pointer..
will add the xbmc changes later this week (including enc/dec pointer) the mplayer changes are still abit too much hackish to put in cvs.
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 :sniffle: guess i'll add some additional debug messages to the mplayer.dll as i have no windows pc -> no debugging on the xbox.
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 :-(
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;
The Xbox1 can live for many more years :)
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 ))
mplayer * * * * * * * * * * * * * * * * *xbmc
*| * * * * * * * * * * * * * * * * * * * *|
*|---( registercomclass: * * * * * * )--->|
*| * ( &memallocator_createallocator ) * *|
*| * * * * * * * * * * * * * * * * * * * *|
*|<--( memallocator_createallocator: )----|
*| * ( /*args */ * * * * * * * * * * ) * *|
Anyway, i've just found registry.dat in the mplayer codecs folder, think I will give this a try.
Also, isnt development halted?
Sollie.
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 (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/7295a55b-12c7-4ed0-a7a4-9ecee16afdec.asp) documentation and it seems that its actually quite important. time to replace the "fake" with a real emulation.
@Diontae16, I think Nuka is wanting someone to to test/benchmark his samples on a Linux computer (a PC, not an Xbox) using MPlayer with an without this patch http://code.google.com/p/coreavc-for-linux/ and to stay true both test/benchmark when comparing to standard MPlayer you should test it all on a single-core/CPU machine (that does not even have Hyper-Threaded enabled).
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?
YES, if XBMC had HD capabilities, just imagine how much value and life our Xbox's would have!
Keep up the good work devs.
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?
Here are a couple links, you should download them first.
http://movies.apple.com/movies/wb/300/300-tlr2_h480p.mov
http://movies.apple.com/movies/rogue_pictures/balls_of_fury/balls_of_fury-tlr2_h480p.mov
Some 480p play fine with DVD player, but these two drop frames bad with both mplayer and dvdplayer.
Thank you
What is the status on this issue?
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
really want this for the xbox.
ok, last time i exported the "memallocate" function, which was successfully called from coreavcdecoder, but somehow it still didn't work.
coreavcdecoder requesting the allocator-instance:0x10022dca *push 0x10048350; rcls-guid
0x10022dcf *call cocreateinstance
0x10022dd5 *retn
what's happening is that the "retn" returns to "0x10048350" - an address in the data-segment, an exception is thrown and it is catched by cmplayer::openfile. why? the stack is messed up - the stack-pointer still points to the rcls-guid after the call, before the "retn". the "retn" fetchs the -wrong- return address from the stack and *boom*.
thanks to elupus & pike for their help.
also abit funny, that extended memory operations is enabled (ie larger than 4gb ram :)
somebody did a evil copy paste, will fixup later too
i wonder if it possible to call an xbmc function from mplayer.dll - and if then how?
I'm happy to spend this afternoon giving it a go, but I'd like to know if anyone's had any luck with the current code, or if it's at least technically possible, before I lay down $15 for a licence. The main stumbling block is the registry key, is there anything like this on the Xbox?
msg: selected video codec: [coreavc] vfm:dshow (coreavc dshow h264 decoder for x86 - http://corecodec.org/)
but it still doesn't work: playback has started
msg: ds_videodecoder_decodeinternal(01411980,015207b0,1 472,0,01e36030)
:
*msg: cmediasample_getsize(013c7c70) called -> 460800
mm: page fault touching 01ea7000, trap frame d04d067c, eip 01fea212
first-chance exception at 0x01fea212 in xbmcd.xbe: 0xc0000005: access violation reading location 0x01ea7000.
dsound: cmcpxstream::servicevoiceinterrupt: warning: the stream is starving
not sure if i will waste any further time on a closed source product...
FYI; the very latest FFmpeg SVN (http://ffmpeg.mplayerhq.hu) (so not in the XBMC SVN yet!) now supports multi-threading decoding of H.264 (or to be more specific "slice-based parallel H.264 decoding") in order to to speed up H.264 decoding on multiple processors (CPUs). Though this will not help playing x264/h264 encoded video on the Xbox, it will help future versions of XBMC Linux port to better handle playback of such material (on dual-core and SMP computers). And this is just the first level in decoding parallelzation in FFmpeg (http://ffmpeg.mplayerhq.hu), bringing it one step closer to becoming up-to-par with the CoreAVC decoder.
NOTE! Again, this does will not increase the decoding speed on the Xbox as the Xbox processor (CPU) only support one thread.
#If you have any other info about this subject , Please add it free.# |
Posted in freedeadaim.com | edit 
A little something about you, the author. Nothing lengthy, just an overview.