Re: [vdr] xine-lib and vaapi support
On 6 November 2010 14:14, Udo Richter wrote: > Am 03.11.2010 10:06, schrieb Theunis Potgieter: >> I'm considering to upgrade my current p3 system to a hdmi/optical >> SPDIF and enough expansion slots to fill in dvb-s devices. > >> The unkown factor for me is, should I >> consider a motherboard where the Core i3 (System on Chip) has got a >> built in hdmi interface? Or would I be better off with nvidia's vdpau, >> of consider to go ati/amd and what power usage are we looking at? >> Should I then rely on vaapi support again? > > The alternatives for HD output are still not very satisfying. > > The best - and most common - chances currently are NVidia / vdpau, > though you're stuck on a heavyweight graphics card solution based on > closed source drivers. Plus, NVidia is starting to fade away for onboard > graphics, limiting the future to separate graphics cards. > > Intel graphis and vaapi (Core i3 or GMA X4500HD) is looking very > promising, however its currently more of a proof-of-concept. I think the > best implementation is currenly as mplayer frontend. I was hoping for this for intel solution (less heat and power usage), but their media boards only comes out with hdmi and no onboard(back board) optical SPDIF out (you need a casing/enclosure with the optical module that plugs into the board). > > AMD also supports vaapi, but progress is very slow, and its still very > buggy. Also, its limited to closed source drivers. Sounds similar to what nvidia went through. > > Hardware decoder cards exist, but have their own issues. Extension HD > works, but seems already to be a dying solution. The Broadcom Crystal > decoder works, but has no own output and no de-interlacer. The > Technotrend 6400 FF HD card would be a nice simply-works solution, but > is fighting delays over delays. (Current release plan is Feb 2011, > further delays would surprise no one any more) > Trying to avoid transcoding other media files back to mpeg2 for the FF HD card. > > I am facing the same problem, and decided not to rush anything, esp. > since I still don't have an HD capable TV anyway. > Maybe I need to wait for other manufacturers to provide intel (SoC) hdmi solutions with optical SPDIF out on the backpanel, reason being I require optical as my receiver/amplifier (NAD T761) is from the older generation that is not hdmi compliant. Trying to avoid this upgrade too. The best board that that I can see so far is this one but requires external graphics card and is still a desktop (price comparison) http://www.msi.com/index.php?func=prodmbspec&maincat_no=1&cat2_no=&cat3_no=&prod_no=1846 I just need to buy 2x (pci-e to pci) converters for my current 4x pci dvb-s cards in the pentium 3. And I would still have some pci-e slots free for future use. I have this card already: nVidia Geforce 8400GS, Architecture: G98 A2 and it works great currently with vdr + streamdev as a client + xineliboutput.vdpau, power usage is still a bit high though. The goal is to consolidate the two machines to one machine which runs 24/7. My current power usage for vdr in the home is 330W. I know this by using a power/electricity monitor device. Thanks, Theunis > > Cheers, > > Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] xine-lib and vaapi support
Hello, how about moving to mplayer instead of xine-lib, is not maintained very well any more? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine-lib and vaapi support
On 8 November 2010 13:59, lucian orasanu wrote: > Hello, > > how about moving to mplayer instead of xine-lib, is not maintained very well > any more? > > My personal experience with mplayer is that it lacks proper aspect ratio detection or guessing based on source that does not contain the correct info. xine-lib seems to handle this much better. Also automatic cropping is a nice feature that works quite well in the vdr-xineliboutput plugin (even with vdpau). Most people doesn't seem to mind that the output is stretched or squeezed incorrectly, but I do. I prefer it that a circle appears to be that and not in the elliptical form. Theunis ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine-lib and vaapi support
On 2010-11-08 at 12:54 +0200, Theunis Potgieter wrote: > On 6 November 2010 14:14, Udo Richter wrote: > > AMD also supports vaapi, but progress is very slow, and its still very > > buggy. Also, its limited to closed source drivers. > > Sounds similar to what nvidia went through. AMD's progress has been snail-paced. I think they have actually gone backwards for at least a year now. Most (All?) of the XvBA interfacing work has been done by Gwenole Beauchesne, who is working for a third party. Nvidia's VDPAU is at least supported and it works rather well compared to every other similar attempt on Linux so far. -- Niko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine-lib and vaapi support
On 08/11/10 12:50, Theunis Potgieter wrote: On 8 November 2010 13:59, lucian orasanu wrote: how about moving to mplayer instead of xine-lib, is not maintained very well any more? My personal experience with mplayer is that it lacks proper aspect ratio detection or guessing based on source that does not contain the correct info. xine-lib seems to handle this much better. Also automatic cropping is a nice feature that works quite well in the vdr-xineliboutput plugin (even with vdpau). Most people doesn't seem to mind that the output is stretched or squeezed incorrectly, but I do. I prefer it that a circle appears to be that and not in the elliptical form. What??! You can tell mplayer the exact ratio of your monitor and the exact ratio of the video on the command line and it correctly calculates how to display it. vdr-sxfe and vdr-fbfe have an equivalent of -monitoraspect but xine-ui and gxine don't, or didn't last time I looked. Instead they query the display's dimensions from the X server, which often gives bogus information, or xine doesn't use the information correctly. For example, X thinks my Sony TV (1366x768 physically, but uses a 1360x768 native resolution, connected by HDMI), measures 16m x 9m (yes, metres!) so I override it with: Section "Monitor" Identifier "32in TV" #DisplaySize708 398 # real size DisplaySize 320 180 # lie to avoid tiny fonts Option "UseEdiDpi" "false" Option "DPI" "96 x 96" Option "DPMS""false" EndSection But when I tried xine it was OK windowed, while in full-screen mode it scaled and applied letterboxing as if for a 4:3 display for some reason :-(. With xine you can override the aspect ratio of the video stream too. It has the advantage over mplayer that you can do it on the fly, but the disadvantage that it only has a few presets with names that don't indicate what the aspect ratio actually is in numbers. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
> But even with such unique numbers, an SVDRP client that accesses > recordings or timers would still need to know whether the VDR instance > it is communicating with has been restarted since the last time it > fetched the list of timers/recordings. It should keep the SVDRP connection open, then it will notice a restart. Olaf ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
> should start at 1 and count up as it already does. Also, instead of > changing the current numbering system, could using a hash provide you > with the same result you're looking for? I would think hashing the > first X MB of a recording would suffice to create a unique identifier. If you want a UUID, use a real UUID. (People using SVDRP by hand probably won't like that...) Olaf ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
