libxine/ffmpeg vdpau/vaapi patches/fixes; new vdr shar

[Juergen Lock]

I forgot to say testing vaapi with nvidia needs the multimedia/vdpau-video
port installed too.

On Fri, Mar 18, 2011 at 11:24:54PM +0100, Juergen Lock wrote:
> Hi!
> 
>  So I can finally test vdpau myself (see other thread about my new
> little box:
> 
> 	http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-March/011759.html
> 
> ) and ended up with a few ports patches:
> 
> a) I initially started with the pcbsd version of nvidia-driver
> (260.19.29), which may be the reason I had issues with libxine and
> vdpau (streams wouldnt start etc), googling turned up this which
> suggests a libxcb problem:
> 
> 	http://www.nvnews.net/vbulletin/showthread.php?s=3a5c37bc21c6fe53f81218c4da3436b8&t=155276&page=3
> 
> and which points at this libxine 1.2 workaround commit:
> 
> 	http://hg.debian.org/hg/xine-lib/xine-lib-1.2/rev/c655ca7b6bce
> 
> I backported that to our version of the libxine port and that more
> or less fixed it:
> 
> 	http://people.freebsd.org/~nox/dvb/xine/extrapatch-vdpau-src-video_out-video_out_vdpau.c
> 
> b) Someone on the vdr irc mentioned that for him (on Linux) vdr worked
> better with vaapi than with vdpau and he pointed me at this patch:
> 
> 	http://test.oppserver.net/xine/ffmpeg-vaapi_xine-lib-1.1.19.diff
> 
> That patch needs ffmpeg built with vaapi (libva) support too so I
> made a patch to add knobs for that to the ffmpeg ports and while I
> was at it also switched the default for the vdpau knobs to on:
> 
> 	http://people.freebsd.org/~nox/dvb/ffmpeg-vaapi.patch [1]
> 
> That got vaapi working but it used more cpu than vdpau on the same
> box and it broke playback on the box with the faster cpu which uses
> xorg radeon drivers because it had no r600_drv_video.so - so I added
> a crude check (INIT_ERROR_HACK) to the ffmpeg-vaapi_xine patch
> above:
> 
> 	http://people.freebsd.org/~nox/dvb/xine/ffmpeg-vaapi_xine-lib-1.1.19-initerrorhack.diff
> 
> But you only actually need the ffmpeg port patch [1], and the resulting
> libxine port patch that adds the other above patches: [2]
> 
> 	http://people.freebsd.org/~nox/dvb/xine/libxine-vdpau-vaapi.patch [2]
> 
> then xine should be able to work pretty well with vdpau, and with vaapi too.
> 
>  And now to vdr:  I've put a new shar here:
> 
> 	http://people.freebsd.org/~nox/dvb/vdr-20110317a.shar
> 
> First, how I test vdpau with that version, the above libxine/ffmpeg
> patches, and vdr-sxfe:
> 
> 	vdr-sxfe --hotkeys --video=vdpau --post tvtime:method=use_vo_driver --audio=oss --reconnect --lirc xvdr+tcp://127.1
> 
> And vaapi:
> 
> 	vdr-sxfe --hotkeys --video=xv --post=tvtime:method=Linear,cheap_mode=1,pulldown=0,use_progressive_frame_flag=1 --reconnect --lirc xvdr+tcp://127.1
> 
> Other changes:
> 
> - Updated epgsearch and live plugins to newer git checkouts,
> 
> - Updated vdr itself to 1.7.17 and added a patch to make it handle
>   webcamd's numbering of dvb devices better (adapter0, adapter8 etc),
>   If you want to go back to only have vdr use the first device you
>   can add -D 0 to its startup commandline, (see the vdr manpage)
> 
> - Added a patch to fix the default lirc socket location for xineliboutput
>   and updated it to a more recent checkout, and
> 
> - Chased the libupnp and libextractor shlib version bumps.
> 
> There still is at least one unresolved bug about regenerating index
> files to a recording, once that is found I think the ports can finally
> be committed. :)  (The bug won't affect you as long as you never lose
> files called index in the dir of a recording, see the bugreport for
> details:
> 
> 	http://thread.gmane.org/gmane.linux.vdr/44357/focus=44379
> 
> But if you want to help test/debug this you are most welcome of course.)