Hi all,
Running vdr-sxfe as a local frontend using a pipe _should_ be as fast (if not faster) than using XBMC over an http://localhost streamdev connection. However, I seem to find the opposite to be the case. vdr-sxfe still struggles with HD content, has pops and clicks in the audio, crashes out every now again and generally has inferior playback.
On my main frontend I have VDR running full time in the background with no local frontend running. Then I have a bare-bones X11 configured with a simple .xinitrc that flips between running vdr-sxfe and xbmc (as I prefer it for watching DVDs etc.). For both frontends I am using VDPAU.
I have to use vdr-sxfe to interact with the menus, auto skip adverts in recordings, do cutting, etc. But I'm increasingly finding myself using XBMC and just a directory full of .strm files that point at streamdev TS links, when I want to watch a live HD broadcast.
Does anyone have vdr-sxfe running flawlessly as a local frontend for HD content?
I just wish I could have the full VDR OSD, but within XBMC :)
Cheers, Dom
2012/3/9 Dominic Evans oldmanuk@gmail.com:
Hi all,
-- SNIP --
Does anyone have vdr-sxfe running flawlessly as a local frontend for HD content?
I use a fully updated yaVDR 0.4 and I don't have any issues with the vdr-sxfe frontend. For me, XBMC with the xvdr plugin seems to produce very ackward results and most of the time I'm not able to watch anything because it's still synchronizing the channels.
BTW, you do know that can play all kinds of media (including DVD's) with vdr-sxfe right? I use vdr-sxfe because it's one of the few frontends which allows mediaplayback without any additional plugins.
I just wish I could have the full VDR OSD, but within XBMC :)
That'll never happen ^^
Cheers, Dom
Regards,
Niels Wagenaar
On 9 March 2012 10:09, Niels Wagenaar n.wagenaar@xs4all.nl wrote:
Does anyone have vdr-sxfe running flawlessly as a local frontend for HD content?
I use a fully updated yaVDR 0.4 and I don't have any issues with the vdr-sxfe frontend.
Hmm. I have the same (yaVDR) running on an ION330 box. The channels I most have problems with are 1080i HD at bitrates of around 9-10 MB/s. Perhaps you could post your ~/.xine/config_xineliboutput to http://gist.github.com or http://paste.ubuntu.com ?
For me, XBMC with the xvdr plugin seems to produce very ackward results and most of the time I'm not able to watch anything because it's still synchronizing the channels
Yes, I don't use the xvdr plugin as it is still very buggy. I simply take the playlist of channels from streamdev (available at http://example.com:3000/ on your vdr box) and generate .strm files [1] which I access from a vanilla XBMC Eden via the Videos --> Files browser.
BTW, you do know that can play all kinds of media (including DVD's) with vdr-sxfe right? I use vdr-sxfe because it's one of the few frontends which allows mediaplayback without any additional plugins.
Yep I did know about these, but XBMC provides a much richer experience for DVD, Blu-ray playback. e.g., cataloguing and display of a library, automatic display framerate switching etc.
---
[1] http://wiki.xbmc.org/index.php?title=HOW-TO:Play_internet_video_and_audio_st...:
2012/3/9 Dominic Evans oldmanuk@gmail.com:
On 9 March 2012 10:09, Niels Wagenaar n.wagenaar@xs4all.nl wrote:
Hmm. I have the same (yaVDR) running on an ION330 box. The channels I most have problems with are 1080i HD at bitrates of around 9-10 MB/s. Perhaps you could post your ~/.xine/config_xineliboutput to http://gist.github.com or http://paste.ubuntu.com ?
I use an Asus AT3N7A-I mainboard with the TT 3650-CI which is an ION330 configuration as well and I frequently watch 1080i channels from my provider (Canal Digitaal) without any issues at all. The only issue I have is that the buffering is slower then my old Reel Multimedia ExtensionHD configuration, so it takes somewhat longer to get a picture (max 5 sec).
My xineliboutput configuration is default, I didn't make any changes to it what so ever.
Yes, I don't use the xvdr plugin as it is still very buggy. I simply take the playlist of channels from streamdev (available at http://example.com:3000/ on your vdr box) and generate .strm files [1] which I access from a vanilla XBMC Eden via the Videos --> Files browser.
I'll check this tomorrow and post my experience using this method.
Yep I did know about these, but XBMC provides a much richer experience for DVD, Blu-ray playback. e.g., cataloguing and display of a library, automatic display framerate switching etc.
XBMC does indeed provide a much richer experience and it's a very powerfull frontend. However, personally I don't like the PVR integration in its current state and it produces all kind of WAF-issues ;)
Regards,
Niels Wagenaar
On Fri, Mar 9, 2012 at 11:22 AM, Dominic Evans oldmanuk@gmail.com wrote:
On 9 March 2012 10:09, Niels Wagenaar n.wagenaar@xs4all.nl wrote:
Does anyone have vdr-sxfe running flawlessly as a local frontend for HD content?
I use a fully updated yaVDR 0.4 and I don't have any issues with the vdr-sxfe frontend.
Hmm. I have the same (yaVDR) running on an ION330 box. The channels I most have problems with are 1080i HD at bitrates of around 9-10 MB/s. Perhaps you could post your ~/.xine/config_xineliboutput to http://gist.github.com or http://paste.ubuntu.com ?
<cut>
I'm running yavdr unstable-vdr packages on an Asrock 330HT box (ION) with xubuntu oneiric. I tuned the xineliboutput config a lot before I got anything bearable for HD channels. However, it turned out the the video buffers were the main problem, so most of the rest can use defaults. My current settings are dumped below: 0|~ > egrep -v '^#' /tmp/config_xineliboutput|egrep -v '^$' .version:2 audio.device.alsa_front_device:default audio.device.alsa_mixer_name:Master audio.device.alsa_mmap_enable:1 audio.output.speaker_arrangement:Surround 5.1 audio.synchronization.av_sync_method:resample video.output.vdpau_hd_deinterlace_method:half temporal video.processing.ffmpeg_thread_count:4 effects.goom.fps:25 effects.goom.height:576 effects.goom.width:720 engine.buffers.audio_num_buffers:500 engine.buffers.video_num_buffers:250 engine.buffers.video_num_frames:22 engine.performance.memcpy_method:libc
I launch vdr-sxfe with a command that overrides video_num_buffers, since it keeps getting silently reverted to 250 in the conf: 0|~ > grep xvdr /tmp/open-vdr-sxfe.sh vdr-sxfe xvdr+tcp://localhost:37890 --post tvtime:method=use_vo_driver --audio=alsa --fullscreen --video=vdpau --reconnect --buffers=1000
The result is still not perfect with occasional glitches but it's not bad and after fighting for months with just getting HD channels running I'm quite happy.
I hope it helps.
Cheers, Jonas
On 9 March 2012 15:11, Jonas Bardino jonas@bardinosen.dk wrote:
I launch vdr-sxfe with a command that overrides video_num_buffers,
Thanks for the suggestions. I'll add the buffers cmdline to my vdr-sxfe startup. Interesting that you're using xvdr+tcp://localhost rather than the default unix pipe. Intentional?
The result is still not perfect with occasional glitches but it's not bad and after fighting for months with just getting HD channels running I'm quite happy.
Yeah its great having HD channels playing and recording. It just makes me a little sad that XBMC playback of them is flawless, but with xine we seem to have to settle for "only occasionally glitches" ?
i also have struggled for this holy grail xbmc would really be the ideal interface for me (just cant beat this flexibility - try playing a .bin / .img over a network which is .rar'd - cant do this on vdr) i like the xbmc plugins and flexibility, for the most part. :) for last few months i've been trying xvdr, but i have to say i have mixed feelings/results on this, and it's not very stable (from my experience) the deprecated vnsiserver/client has fallen off the radar by now... not many options other than streamdev/strm files.
i found i kept getting warnings about insufficient buffers with the setting
engine.buffers.video_num_frames:22
, so i bumped that up to 35
only other setting i'd suggest re-examining is the
engine.performance.memcpy_method:libc
at least on my system, kernel is faster. :) autodetect should be fine for this... ? (it should test all of them)
On Fri, Mar 9, 2012 at 10:28 AM, Dominic Evans oldmanuk@gmail.com wrote:
On 9 March 2012 15:11, Jonas Bardino jonas@bardinosen.dk wrote:
I launch vdr-sxfe with a command that overrides video_num_buffers,
Thanks for the suggestions. I'll add the buffers cmdline to my vdr-sxfe startup. Interesting that you're using xvdr+tcp://localhost rather than the default unix pipe. Intentional?
The result is still not perfect with occasional glitches but it's not bad and after fighting for months with just getting HD channels running I'm quite happy.
Yeah its great having HD channels playing and recording. It just makes me a little sad that XBMC playback of them is flawless, but with xine we seem to have to settle for "only occasionally glitches" ?
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 2012-03-09 16:34, Bio H wrote:
i also have struggled for this holy grail xbmc would really be the ideal interface for me (just cant beat this flexibility - try playing a .bin / .img over a network which is .rar'd - cant do this on vdr) i like the xbmc plugins and flexibility, for the most part. :) for last few months i've been trying xvdr, but i have to say i have mixed feelings/results on this, and it's not very stable (from my experience) the deprecated vnsiserver/client has fallen off the radar by now... not many options other than streamdev/strm files.
i found i kept getting warnings about insufficient buffers with the setting
engine.buffers.video_num_frames:22
, so i bumped that up to 35
I got the warnings, too, but ended back at 22 when it didn't make a visible difference. This is on an Atom box with scarce resources, so ymmv.
only other setting i'd suggest re-examining is the
engine.performance.memcpy_method:libc
at least on my system, kernel is faster. :) autodetect should be fine for this... ? (it should test all of them)
I started out with auto detect but then set it to libc which it selected. The start up delay for auto is probably small, so I guess it's a safe bet in most cases.
Cheers, Jonas
On 2012-03-09 16:28, Dominic Evans wrote:
On 9 March 2012 15:11, Jonas Bardinojonas@bardinosen.dk wrote:
I launch vdr-sxfe with a command that overrides video_num_buffers,
Thanks for the suggestions. I'll add the buffers cmdline to my vdr-sxfe startup. Interesting that you're using xvdr+tcp://localhost rather than the default unix pipe. Intentional?
That's a good question actually. I have experimented a *lot* with xine and xineliboutput to get sound through on the AAC/LATM encoded channels here in Denmark, so it may just be something that made a difference at some point along the way - I don't remember. I'm pretty sure my playback glitches are from the combination of unstable-vdr and fairly new LATM support in ffmpeg/xine, but maybe I'll investigate if the pipe works better at some point.
The result is still not perfect with occasional glitches but it's not bad and after fighting for months with just getting HD channels running I'm quite happy.
Yeah its great having HD channels playing and recording. It just makes me a little sad that XBMC playback of them is flawless, but with xine we seem to have to settle for "only occasionally glitches" ?
Here XBMC is absolutely unstable and always has been, while vdr-sxfe runs quite well. I haven't been able to get sound out of XBMC TV since the channel switch to LATM audio, either. It should be noted that I mean XBMC with TV over the various pvr plugins.
Cheers, Jonas
Yep I did know about these, but XBMC provides a much richer experience for DVD, Blu-ray playback. e.g., cataloguing and display of a library, automatic display framerate switching etc.
I thought blu-ray is dead format not supported by Linux movie players. Does XBMC support it somehow?
Mika
vdr-sxfe provides a media player based on xinelib with an access to blu-ray (including menu support)
2012/3/10 Mika Laitio lamikr@pilppa.org
Yep I did know about these, but XBMC provides a much richer experience for DVD, Blu-ray playback. e.g., cataloguing and display of a library, automatic display framerate switching etc.
I thought blu-ray is dead format not supported by Linux movie players. Does XBMC support it somehow?
Mika
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Fri, 9 Mar 2012 09:59:51 +0000 Dominic Evans oldmanuk@gmail.com wrote:
Running vdr-sxfe as a local frontend using a pipe _should_ be as fast (if not faster) than using XBMC over an http://localhost streamdev connection. However, I seem to find the opposite to be the case. vdr-sxfe still struggles with HD content, has pops and clicks in the audio, crashes out every now again and generally has inferior playback.
On my main frontend I have VDR running full time in the background with no local frontend running. Then I have a bare-bones X11 configured with a simple .xinitrc that flips between running vdr-sxfe and xbmc (as I prefer it for watching DVDs etc.). For both frontends I am using VDPAU.
I have to use vdr-sxfe to interact with the menus, auto skip adverts in recordings, do cutting, etc. But I'm increasingly finding myself using XBMC and just a directory full of .strm files that point at streamdev TS links, when I want to watch a live HD broadcast.
IME sxfe works better watching "live" than a recording, but I'm not sure whether it affects how often the audio glitches. Such things in vdr-sxfe seem to come and go at random. Last time I watched an HD recording the picture regularly "jerked", like you get when watching 24fps video very crudely converted to 25fps by repeating a frame every second. But "live" TV seems quite smooth.
The difference between vdr-sxfe and XBMC you're experiencing could be due to differences in the deinterlacing setting. You didn't say what your graphics card is, but the sort of low-power fanless card most of us like to have in an HTPC can't manage the higher quality options. The default for libxine is "temporal", which my lowly 8200 is too slow for in HD (but OK in SD), so I had to use this setting:
video.output.vdpau_hd_deinterlace_method:bob
I was amazed at how good it looks, although I've only tried it at 720p output so far, not at 1080p. I thought I was going to have to add at least a GT210 PCI-E card, but it looks like that's going to be unnecessary.
On 9 March 2012 13:42, Tony Houghton h@realh.co.uk wrote:
The difference between vdr-sxfe and XBMC you're experiencing could be due to differences in the deinterlacing setting. You didn't say what your graphics card is, but the sort of low-power fanless card most of us like to have in an HTPC can't manage the higher quality options. The default for libxine is "temporal", which my lowly 8200 is too slow for in HD (but OK in SD), so I had to use this setting:
video.output.vdpau_hd_deinterlace_method:bob
I was amazed at how good it looks, although I've only tried it at 720p output so far, not at 1080p. I thought I was going to have to add at least a GT210 PCI-E card, but it looks like that's going to be unnecessary.
I actually currently have deinterlacing disabled on both xineliboutput and XBMC.
On Fri, 9 Mar 2012 14:15:06 +0000 Dominic Evans oldmanuk@gmail.com wrote:
On 9 March 2012 13:42, Tony Houghton h@realh.co.uk wrote:
video.output.vdpau_hd_deinterlace_method:bob
I was amazed at how good it looks, although I've only tried it at 720p output so far, not at 1080p. I thought I was going to have to add at least a GT210 PCI-E card, but it looks like that's going to be unnecessary.
I actually currently have deinterlacing disabled on both xineliboutput and XBMC.
AIUI interlaced fields are encoded as a pair in one field, so for most video players "disabled", ignoring the interlacing flags and treating it as as normal frame is the same as "weave". You usually get quite noticeable combing artifacts with that. "Bob" is more or less an alternative way of doing next to nothing; it displays each field in turn without any attempt to combine them.
On 9 March 2012 16:25, Tony Houghton h@realh.co.uk wrote:
I actually currently have deinterlacing disabled on both xineliboutput and XBMC.
AIUI interlaced fields are encoded as a pair in one field, so for most video players "disabled", ignoring the interlacing flags and treating it as as normal frame is the same as "weave". You usually get quite noticeable combing artifacts with that. "Bob" is more or less an alternative way of doing next to nothing; it displays each field in turn without any attempt to combine them.
Ah, actually looking at config_xinelibeoutput, I think vdr-sxfe automatically enables some vdpau deinterlacing by default (half temporal I think?) and the setting I was looking at on the xineliboutput config isn't relevant. I've switched to bob at your recommendation anyway :)
I haven't noticed any combing artifacts into XBMC, but as I have the 'match display rate to match video' configured, its possible that XBMC is just feeding the TV 1080i output and letting it handle the deinterlacing.
On Fri, 9 Mar 2012 09:59:51 +0000 Dominic Evans oldmanuk@gmail.com wrote:
Hi all,
Running vdr-sxfe as a local frontend using a pipe _should_ be as fast (if not faster) than using XBMC over an http://localhost streamdev connection. However, I seem to find the opposite to be the case. vdr-sxfe still struggles with HD content, has pops and clicks in the audio, crashes out every now again and generally has inferior playback.
My experience is that xine frontend runs usually more stable, then vdr-sxfe. If you run sxfe without HUD enabled, video is pretty ok, but gets jerky if you have OSD open. With hood enabled you get this skippy behaviour described in some other answer.
On my main frontend I have VDR running full time in the background with no local frontend running. Then I have a bare-bones X11 configured with a simple .xinitrc that flips between running vdr-sxfe and xbmc (as I prefer it for watching DVDs etc.). For both frontends I am using VDPAU.
I have to use vdr-sxfe to interact with the menus, auto skip adverts in recordings, do cutting, etc. But I'm increasingly finding myself using XBMC and just a directory full of .strm files that point at streamdev TS links, when I want to watch a live HD broadcast.
Interesting solution.
Does anyone have vdr-sxfe running flawlessly as a local frontend for HD content?
I used to use xine as local frontend as its more stable.
I just wish I could have the full VDR OSD, but within XBMC :)
Most likely will never happen.
To answer some points raised in other answers: - default deinterlacing with yavdr is temporal_spatial for SD content and bob for HD content - testing HD deinterlacing settings with 720p stations is pointless as p means progressive aka not interlaced - you can set the deinterlacing settings in the webfrontend (for all frontends, not 100% sure about XBMC) - the xbmc version of yavdr 0.4 isn't optimal anymore, we just did not get around to provide some updated version, current eden with pvr runs a lot more stable, but has other issues (which we did not came around yet to trace them) - there is a new kid on the block called softhddevice, which is local frontend only and based directly on ffmpeg/libav with no libxine involved. Its only a littlebit older then 2 months, those maybe not ready for primetime - but in my opinion providing a better experience then the old xine frontends already. For that oneiric or precise as base is recommended - but this is nothing we can rollout yet. local frontend only is not that much of a backdraw, if you take into account that you can use streamdev with vtp streaming and a local vdr on the client
Hope that provides some insight.
Hi,
I just wish I could have the full VDR OSD, but within XBMC :)
Most likely will never happen.
You'll never know. :)
Haven't looked into XBMC yet, but dbus2vdr (0.0.4) can export the OSD as PNG files and signals changes via DBus. Disadvantage: you can't use the OSD of the output-plugin anymore (which you may not need anymore).
vdr just can use one OSD-provider at the time. Mostly it's instantiated in the "MakePrimaryDevice" of the output-plugin. dbus2vdr can create its OSD-provider which will delete the present one, but can't re-create the old provider (haven't tried yet calling "PrimaryDevice()->MakePrimaryDevice()" yet). And it's not possible at the moment to let dbus2vdr recreate its provider. But this will come.
The first use case for this OSD export is a headless vdr. But it may be worth trying for your setup, too. Please take a look at the README of dbus2vdr line 168ff. https://github.com/flensrocker/vdr-plugin-dbus2vdr/blob/master/README
What you have to do: Listen for dbus-signals on interface de.tvdr.vdr.osd from object /OSD and send the usual keystrokes to vdr to open OSD and navigate (you can do that also viy DBus, see line 119 in the README). "Open" will inform you about the position and id of the OSD, "Display" sends you a filename to the PNG and its position relative to the position of the OSD. After "Close" all files will be deleted. Every PNG between Open and Close have to be displayed over the last ones since only differences are reported.
It's a really young feature and never really tested, and I would like to get some input about this.
Lars.
-
Bio H -
Dominic Evans -
Jonas Bardino -
LACARRIERE Jerome -
Lars Hanisch -
Mika Laitio -
Niels Wagenaar -
Steffen Barszus -
Tony Houghton