Re: [vdr] xineliboutput and streamdev at the same time
I just tried vdr-fbfe compiled from CVS on the RPI, and there's still
that judder when pressing keys when the OSD menu is showing. Is this
possible to remedy somehow? This was one of the issues that made me
switch to softhddevice a few years ago.
On 21 April 2015 at 23:36, Harald Milz h...@seneca.muc.de wrote:
On Tue, Apr 21, 2015 at 12:41:57PM +0300, Petri Hintukainen wrote:
Do you mean setting the marks (and letting remote VDR to do the actual
editing) ? Or using VDR in RPi to cut recordings ? Cutting with RPi is
probably very slow and consumes lot of limited I/O resources.
For setting editing marks - probably, I'm not sure. I rarely edit
Yes sure. With vdr-{sxfe,fbfe} you get a remote OSD from the server VDR, i.e.
you work on the server, not the RPi. No data is transferred over the net
except the OSD when cutting.
Latency with 100Mbit/s ethernet is not noticeable. It can be even faster
For SD 100 MBit is fine. For HD it should be okay also. As far as Wifi, 54
MBit is okay-ish for SD but better go for 300 on 5 GHz (to make sure the
wifi is near-exclusively used for the VDR link).
One possible source of problems is audio decoding performance. I'm not
EAC3 ?). AC3 decoding uses ~ half of RPi CPU time. Here the additional
CPU power of RPi 2 would be useful.
Better use HDMI pass-through and have the AC3 receiver decode the stream. The
Pi
has only a 2.0 analog output anyway, so there's little point in decoding on
the Pi.
--
You will be traveling and coming into a fortune.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
--
-Tor
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput and streamdev at the same time
On ti, 2015-05-12 at 16:40 +1000, Torgeir Veimo wrote:
I just tried vdr-fbfe compiled from CVS on the RPI, and there's still
that judder when pressing keys when the OSD menu is showing. Is this
possible to remedy somehow? This was one of the issues that made me
switch to softhddevice a few years ago.
I haven't noticed this.
Did you compile xine-lib from hg or are you using some older version ?
RPi HW OSD support is not in xine-lib 1.2.6.
Do you run also VDR in RPi ? Maybe it uses too much resources when
rendering OSD ?
Also, I have mpeg2 decoding key. It makes SD smoother ...
On 21 April 2015 at 23:36, Harald Milz h...@seneca.muc.de wrote:
On Tue, Apr 21, 2015 at 12:41:57PM +0300, Petri Hintukainen wrote:
Do you mean setting the marks (and letting remote VDR to do the actual
editing) ? Or using VDR in RPi to cut recordings ? Cutting with RPi is
probably very slow and consumes lot of limited I/O resources.
For setting editing marks - probably, I'm not sure. I rarely edit
Yes sure. With vdr-{sxfe,fbfe} you get a remote OSD from the server VDR,
i.e.
you work on the server, not the RPi. No data is transferred over the net
except the OSD when cutting.
Latency with 100Mbit/s ethernet is not noticeable. It can be even faster
For SD 100 MBit is fine. For HD it should be okay also. As far as Wifi, 54
MBit is okay-ish for SD but better go for 300 on 5 GHz (to make sure the
wifi is near-exclusively used for the VDR link).
One possible source of problems is audio decoding performance. I'm not
EAC3 ?). AC3 decoding uses ~ half of RPi CPU time. Here the additional
CPU power of RPi 2 would be useful.
Better use HDMI pass-through and have the AC3 receiver decode the stream.
The Pi
has only a 2.0 analog output anyway, so there's little point in decoding on
the Pi.
--
You will be traveling and coming into a fortune.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput and streamdev at the same time
Seems to work with -V mmal
But I'm still getting judder on OSD update. Does hardware OSD for rpi
require more than just current xine-lib? The xinelibplugin on the
server side is older, since it's a vanilla yavdr installation, am
unsure if that would have an impact on the clients OSD?
On 12 May 2015 at 20:59, Torgeir Veimo torgeir.ve...@gmail.com wrote:
Ok, trying again with recompiled xine-lib from hg as of current
(http://anonscm.debian.org/hg/xine-lib/xine-lib-1.2/)
root@raspberrypi:/usr/local/src/vdr-2.2.0/PLUGINS/src/xineliboutput#
./vdr-fbfe -V rpi -f xvdr+tcp://192.168.1.100
vdr-fbfe 2.0.0-cvs (build with xine-lib 1.2.6, using xine-lib 1.2.6)
Video driver: rpi
Fullscreen mode
VDR Server: xvdr+tcp://192.168.1.100
[2289] [vdr-fbfe] fbfe_display_open: failed to set /dev/tty to graphics mode
[2289] [vdr-fbfe] (ERROR (xine_fbfe_frontend.c,178): Inappropriate
ioctl for device)
[2289] [vdr-fe]fe_xine_init: xine_open_video_driver(rpi) failed
Error initializing xine
Available video drivers: aadxr3 mmal dxr3 raw xshm none fb
Available audio drivers: oss none file
[2289] [vdr-fbfe] fbfe_display_close: failed to set /dev/tty to text mode
[2289] [vdr-fbfe] (ERROR (xine_fbfe_frontend.c,253): Inappropriate
ioctl for device)
root@raspberrypi:/usr/local/src/vdr-2.2.0/PLUGINS/src/xineliboutput#
Did I just forget some switches when configuring xine-lib, or do I
need a new kernel?
root@raspberrypi:/usr/local/src/vdr-2.2.0/PLUGINS/src/xineliboutput# uname -a
Linux raspberrypi 3.18.11-v7+ #781 SMP PREEMPT Tue Apr 21 18:07:59 BST
2015 armv7l GNU/Linux
On 12 May 2015 at 16:58, Petri Hintukainen
phint...@users.sourceforge.net wrote:
On ti, 2015-05-12 at 16:40 +1000, Torgeir Veimo wrote:
I just tried vdr-fbfe compiled from CVS on the RPI, and there's still
that judder when pressing keys when the OSD menu is showing. Is this
possible to remedy somehow? This was one of the issues that made me
switch to softhddevice a few years ago.
I haven't noticed this.
Did you compile xine-lib from hg or are you using some older version ?
RPi HW OSD support is not in xine-lib 1.2.6.
Do you run also VDR in RPi ? Maybe it uses too much resources when
rendering OSD ?
Also, I have mpeg2 decoding key. It makes SD smoother ...
On 21 April 2015 at 23:36, Harald Milz h...@seneca.muc.de wrote:
On Tue, Apr 21, 2015 at 12:41:57PM +0300, Petri Hintukainen wrote:
Do you mean setting the marks (and letting remote VDR to do the actual
editing) ? Or using VDR in RPi to cut recordings ? Cutting with RPi is
probably very slow and consumes lot of limited I/O resources.
For setting editing marks - probably, I'm not sure. I rarely edit
Yes sure. With vdr-{sxfe,fbfe} you get a remote OSD from the server VDR,
i.e.
you work on the server, not the RPi. No data is transferred over the net
except the OSD when cutting.
Latency with 100Mbit/s ethernet is not noticeable. It can be even faster
For SD 100 MBit is fine. For HD it should be okay also. As far as Wifi, 54
MBit is okay-ish for SD but better go for 300 on 5 GHz (to make sure the
wifi is near-exclusively used for the VDR link).
One possible source of problems is audio decoding performance. I'm not
EAC3 ?). AC3 decoding uses ~ half of RPi CPU time. Here the additional
CPU power of RPi 2 would be useful.
Better use HDMI pass-through and have the AC3 receiver decode the stream.
The Pi
has only a 2.0 analog output anyway, so there's little point in decoding
on
the Pi.
--
You will be traveling and coming into a fortune.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
--
-Tor
--
-Tor
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput and streamdev at the same time
Ok, trying again with recompiled xine-lib from hg as of current
(http://anonscm.debian.org/hg/xine-lib/xine-lib-1.2/)
root@raspberrypi:/usr/local/src/vdr-2.2.0/PLUGINS/src/xineliboutput#
./vdr-fbfe -V rpi -f xvdr+tcp://192.168.1.100
vdr-fbfe 2.0.0-cvs (build with xine-lib 1.2.6, using xine-lib 1.2.6)
Video driver: rpi
Fullscreen mode
VDR Server: xvdr+tcp://192.168.1.100
[2289] [vdr-fbfe] fbfe_display_open: failed to set /dev/tty to graphics mode
[2289] [vdr-fbfe] (ERROR (xine_fbfe_frontend.c,178): Inappropriate
ioctl for device)
[2289] [vdr-fe]fe_xine_init: xine_open_video_driver(rpi) failed
Error initializing xine
Available video drivers: aadxr3 mmal dxr3 raw xshm none fb
Available audio drivers: oss none file
[2289] [vdr-fbfe] fbfe_display_close: failed to set /dev/tty to text mode
[2289] [vdr-fbfe] (ERROR (xine_fbfe_frontend.c,253): Inappropriate
ioctl for device)
root@raspberrypi:/usr/local/src/vdr-2.2.0/PLUGINS/src/xineliboutput#
Did I just forget some switches when configuring xine-lib, or do I
need a new kernel?
root@raspberrypi:/usr/local/src/vdr-2.2.0/PLUGINS/src/xineliboutput# uname -a
Linux raspberrypi 3.18.11-v7+ #781 SMP PREEMPT Tue Apr 21 18:07:59 BST
2015 armv7l GNU/Linux
On 12 May 2015 at 16:58, Petri Hintukainen
phint...@users.sourceforge.net wrote:
On ti, 2015-05-12 at 16:40 +1000, Torgeir Veimo wrote:
I just tried vdr-fbfe compiled from CVS on the RPI, and there's still
that judder when pressing keys when the OSD menu is showing. Is this
possible to remedy somehow? This was one of the issues that made me
switch to softhddevice a few years ago.
I haven't noticed this.
Did you compile xine-lib from hg or are you using some older version ?
RPi HW OSD support is not in xine-lib 1.2.6.
Do you run also VDR in RPi ? Maybe it uses too much resources when
rendering OSD ?
Also, I have mpeg2 decoding key. It makes SD smoother ...
On 21 April 2015 at 23:36, Harald Milz h...@seneca.muc.de wrote:
On Tue, Apr 21, 2015 at 12:41:57PM +0300, Petri Hintukainen wrote:
Do you mean setting the marks (and letting remote VDR to do the actual
editing) ? Or using VDR in RPi to cut recordings ? Cutting with RPi is
probably very slow and consumes lot of limited I/O resources.
For setting editing marks - probably, I'm not sure. I rarely edit
Yes sure. With vdr-{sxfe,fbfe} you get a remote OSD from the server VDR,
i.e.
you work on the server, not the RPi. No data is transferred over the net
except the OSD when cutting.
Latency with 100Mbit/s ethernet is not noticeable. It can be even faster
For SD 100 MBit is fine. For HD it should be okay also. As far as Wifi, 54
MBit is okay-ish for SD but better go for 300 on 5 GHz (to make sure the
wifi is near-exclusively used for the VDR link).
One possible source of problems is audio decoding performance. I'm not
EAC3 ?). AC3 decoding uses ~ half of RPi CPU time. Here the additional
CPU power of RPi 2 would be useful.
Better use HDMI pass-through and have the AC3 receiver decode the stream.
The Pi
has only a 2.0 analog output anyway, so there's little point in decoding on
the Pi.
--
You will be traveling and coming into a fortune.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
--
-Tor
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
