Hi,
Attached is a patch to enable decoding of H264 video streams using the CoreAVC Win32 DLL, the latest HG clone of xine-lib and Reinhard's vdr-xine and of course VDR. CoreAVC is a commercial and fast software-based H264 decoder.
To make this work: -
1) Download the latest mercurial xine-lib (hg clone http://hg.debian.org/hg/xine-lib/xine-lib-1.2) 2) Patch it (cd xine-lib-1.2 ; patch -p 1 < xine-lib-1.2hg-coreavc.diff) 3) Make and install it in your usual way (e.g. ./autogen.sh --disable-dxr3 ; make ; make install). You might want to remove old xine-lib first (rm /usr/local/lib/libxine* ; rm -rf /usr/local/lib/xine) 4) Make and install xine-ui (skip if already installed) 5) mkdir /usr/lib/win32 6) Put CoreAVCDecoder.ax (version 1.5.0 is the only version I can get working - the version I have is called coreavcdecoder_unpacked.ax) in /usr/lib/win32 7) Remove the old external ff decoder references (rm /usr/local/lib/xine/plugins/2.0/xineplug_decode_ff.so ; rm /usr/local/lib/xine/plugins/2.0/xineplug_decode_qt.so) 8) Start VDR -Pxine 9) Run xine (xine -f -pq -I -V xv -A alsa --post vdr_video --post vdr_audio -Dtvtime:method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_flag=1 vdr://tmp/vdr-xine/stream#demux:mpeg_pes)
You can also tweak some of the CoreAVC settings. See this page for more details: -
http://code.google.com/p/coreavc-for-linux/wiki/RegisterCoreAVC
but change ~/.mplayer/registry32 with ~/.xine/win32registry.
Note, to increase performance I have disabled the xine de-interlacer for H264 streams as by default the CoreAVC deinterlacer is enabled. I don't think it's as good as the xine de-interlacer, but if you want to try re-enable xine deint on your CPU (too slow on my 2.6Ghz dual core) then edit xine's src/libw32dll/w32codec.c and re-enable "int field = VO_BOTH_FIELDS | VO_INTERLACED_FLAG;" and comment out "int field = VO_BOTH_FIELDS;"
Then you can disable CoreAVC's deinterlacer using the instructions on code.google.com (registercodec -r ~/.xine/win32registry -k "HKEY_CURRENT_USER\Software\CoreCodec\CoreAVC Pro\Deinterlace" -v 3 -t dword)
Note, I haven't written the majority of this patch, it has been pulled together from about 4 other patches (budice's work on DVBN and the google code site itself). I have added code to automatically detect the size of the H264 stream and to set the aspect ratio of the resultant picture as well as making it apply cleanly (hopefully!) to today's HG of xine.
Therefore, the code is nothing more than a total hack and will not likely see inclusion in xine in it's current form. There is currently H264 parsing occurring in the demuxer which is probably a "bad thing", it should be moved out of there. Additionally, I have added a new variable to the BITMAPINFOHEADER to pass the ratio from the demuxer to the codec source which is also not ideal, but hey, it works!
It has been pretty stable for me over the last few days and is a vast improvement over FFMPEG.
Finally, I urge you to go and BUY CoreAVC (http://www.coreavc.com) if you are using this patch - it's only 15USD.
Let me know if there are any problems and good luck!
Cheers,
Morfsta
I demand that Morfsta may or may not have written...
[snip]
If at all possible, the CoreAVC deinterlacer should be made useable as a deinterlacer plugin, much as tvtime and pp are.
If you can untangle them and set up a repository containing the individual patches *or* make a quilt series from them, that'd be better. It might be worth using From: and Subject: headers at the top (RFC2822-style) for proper attribution ("hg import" understands these).
Without overriding the user's preference, I hope.
Therefore, the code is nothing more than a total hack and will not likely see inclusion in xine in it's current form.
You're right (and you mean "its").
(! = will cause rejection; ? - may cause rejection; - = should be fixed.)
! New files are missing copyright/licence headers.
- C++ comments. (We prefer C comments.)
- printf usage - you want xprintf or lprintf.
? static SampleProcUserData sampleProcData - why is this not part of an instance-specific struct, or allocated as needed?
- #include "xine/..." - should use <>, not ""
- White-space and {} changes which don't change the meaning of the code don't belong in the patch.
- 32-bit assumptions. Probably safe for now...
? Use of signal() - be careful: that could trample all over the front end's own signal handling. (I note that signal(2) says that its effects in a multi-threaded process is undefined...)
? src/libw32dll/wine/win32.c, lines 5445-5454: fixed-size buffer & sprintf. Are you *sure* that there's no chance of an overflow here?
- Some indentation/line-break fixups where code is already changed would be good. :-)
[snip already-known problems etc.]
-
Darren Salt -
Morfsta