xineliboutput-user Mailing List for VDR xine-lib output device
Brought to you by:
phintuka
You can subscribe to this list here.
2007 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(6) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
2010 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Andreas M. <and...@os...> - 2011-03-09 14:12:19
|
Greetings, I'm trying to get libxineliboutput-fbfe to send received TV signals to my Hollywood+ card so that I can watch TV, pictures and listen to music on my analogue CRT. Yes, I know, times have changed, but that's just the configuration my purse can afford. Anyway, em8300 modules are ready and correctly configured for TV output over a SCART adapter (tested using dxr3config). As far as I understand, I have to install libxine1, xineliboutput and libxineliboutput-fbfe for this combination to work, is that correct? Now using this combination, I 've come as far as producing framebuffer TV output. Also a nice and cheap solution but TV output with a dxr3 card is far better picture quality. Unfortunately, xine seems to ignore my dxr3 card. When I use the following 'config' settings in /etc/vdr/plugins/xineliboutput, I get no error messages and no TV picture on screen, and VDR seems to work nicely in the background: # contents of /etc/vdr/plugins/xineliboutput/config # local=fbfe primary remote=none video=dxr3 audio=oss display=/dev/fb0 Is there anyone on this list with such a combination? Any help would be appreciated, Thanks in advance, vdr-xxl |
From: Jiri J. <ja...@fe...> - 2010-05-13 16:57:47
|
Hi, I bought nvidia g210 (with vdpau support) and would like use it as video output device with VDR. I installed nvidia driver and mplayer plays all videos well both with VDPAU or XV. I never using xineliboutput plugin before, because I had DXR3 card and it seems it's run better with DXR3 VDR plugin. So, I began from scratch. I installed xinelib-1.2 into system and xinelibplugin into VDR. But result dosn't look good. I have many problems, but most significant is jerky video in few second after channel switch and in from time to time after it. In logs, I'am getting messages like this: video_out: throwing away image with pts 2920558 because it's too old (diff : 5694). video_out: throwing away image with pts 2974558 because it's too old (diff : 6457). video_out: throwing away image with pts 3028558 because it's too old (diff : 7171). 200 frames delivered, 0 frames skipped, 5 frames discarded I googled it, but nothing usefull found. I tested it on MPEG2 PAL television station with xineliboutput both with XV and VDPAU (processor is pentium4@2.8GHz) with same result. So can anybody help me with my problem? Is any solution of it? How set it up you? (I run vdr in play X server....) Thanks Jiri Jansky |
From: Petri H. <phi...@us...> - 2010-01-03 18:34:03
|
Gerald Dachs wrote: > Am Tue, 29 Dec 2009 22:02:52 +0200 schrieb Petri Hintukainen <phi...@us...>: > > > Rewind with mpeg-ts recordings hasn't been implemented yet. > > Bad news, we planned to build a new distribution around xineliboutput > and vdr 1.7.10. Does it make sense to keep our breath or would you > recommend us to switch to vdr-xine? Give me few days to estimate what needs to be done. I don't have much time for the project at the moment, so fixing it will take more likely few weeks than few days. Maybe the changes in vdr-1.7.5 actually make rewind usable :) - Petri |
From: Gerald D. <gd...@gm...> - 2009-12-29 20:37:21
|
Am Tue, 29 Dec 2009 22:02:52 +0200 schrieb Petri Hintukainen <phi...@us...>: > Gerald Dachs wrote: > > Hello, > > > > if I try to rewind a recording, I can see the movie going fast > > backwards, but if I stop rewinding, the movie continues from the > > moment I started the rewinding. > > This doesn't happen with xine-ui and the xine-plugin and with xbmc > > using the streamdev-plugin, so I believe it is a xineliboutput > > problem. > > > > I use a cvs snapshot from yesterday and vdr 1.7.10 on Ubuntu 9.10, > > xinelib 1.2 with vdpau patch r285 and durchflieger cropping > > patch. > > > > What can I do to help you solving the problem? > > Rewind with mpeg-ts recordings hasn't been implemented yet. Bad news, we planned to build a new distribution around xineliboutput and vdr 1.7.10. Does it make sense to keep our breath or would you recommend us to switch to vdr-xine? Gerald |
From: Petri H. <phi...@us...> - 2009-12-29 20:03:05
|
Gerald Dachs wrote: > Hello, > > if I try to rewind a recording, I can see the movie going fast > backwards, but if I stop rewinding, the movie continues from the moment > I started the rewinding. > This doesn't happen with xine-ui and the xine-plugin and with xbmc > using the streamdev-plugin, so I believe it is a xineliboutput problem. > > I use a cvs snapshot from yesterday and vdr 1.7.10 on Ubuntu 9.10, > xinelib 1.2 with vdpau patch r285 and durchflieger cropping patch. > > What can I do to help you solving the problem? Rewind with mpeg-ts recordings hasn't been implemented yet. - Peri |
From: Gerald D. <gd...@gm...> - 2009-12-28 00:46:15
|
Hello, if I try to rewind a recording, I can see the movie going fast backwards, but if I stop rewinding, the movie continues from the moment I started the rewinding. This doesn't happen with xine-ui and the xine-plugin and with xbmc using the streamdev-plugin, so I believe it is a xineliboutput problem. I use a cvs snapshot from yesterday and vdr 1.7.10 on Ubuntu 9.10, xinelib 1.2 with vdpau patch r285 and durchflieger cropping patch. What can I do to help you solving the problem? Gerald |
From: Petri H. <phi...@us...> - 2009-07-15 17:38:07
|
la, 2009-07-11 kello 23:29 +0200, Otto Brandstaetter kirjoitti: > Hi List ! > > I wonder, if there is a possibility, to "autostart" the media player when > starting vdr ? > So the vdr immediately plays several videos or mp3 ? > Not directly, but you could use plugin's SVDRP interface (ex. with vdr svdrpsend.pl) to start playback just after VDR has been started. - Petri |
From: Petri H. <phi...@us...> - 2009-07-15 17:37:14
|
la, 2009-07-11 kello 23:31 +0200, Otto Brandstaetter kirjoitti: > Hi ! > > I just got vdr on my xbox (xebian) running. > Now i am wondering, if there is any possibility to get xineliboutput (plugin > of vdr) and mplayer work together ? > so the mplayer-plugin would output to xineliboutput... Do you mean using mplayer as decoder and just outputting to xineliboutput window, or just using mplayer-plugin UI to select media files ? Later should be possible by modifying mplayer plugin to use xineliboutput's service interface. - Petri |
From: Otto B. <of...@br...> - 2009-07-11 21:56:58
|
Hi ! I just got vdr on my xbox (xebian) running. Now i am wondering, if there is any possibility to get xineliboutput (plugin of vdr) and mplayer work together ? so the mplayer-plugin would output to xineliboutput... Thanks in advance ! Otto Brandstaetter |
From: Otto B. <of...@br...> - 2009-07-11 21:56:56
|
Hi List ! I wonder, if there is a possibility, to "autostart" the media player when starting vdr ? So the vdr immediately plays several videos or mp3 ? Best regards, Otto Brandstaetter |
From: Pekka B. <br...@ga...> - 2008-07-19 20:03:09
|
Hi, There seems to be a problem when using Xineliboutput with sxfe frontend and Xv video on ATI Radeon HD 3200. I'm running VDR 1.6.0 with the newest Xineliboutput from the CVS (1.0.2-cvs) on Ubuntu 8.04, libxine version 1.1.11.1. ATI drivers are the newest proprietary ones, Catalyst 8.6. The issue is that for some reason channels with a certain resolution (704x576) show ok but others (720x576) don't, with diagonal striping messing up the picture. Here's a pic what the not working channels look like: http://www.vdr-portal.de/board/attachment.php?attachmentid=19006 (from thread http://www.vdr-portal.de/board/thread.php?postid=735359) The strange thing is that playing various clips in various resolutions in Xine with Xv doesn't seem to be causing any problems AND the striping issue with Xineliboutput can be temporarily fixed by changing from X to text mode with ctrl-alt-f1 and back with ctrl-alt-f7 when VDR is running. Here's VDR log starting from before hitting ctrl-alt-f1 and ending when ctrl-alt-f7 was issued. Jul 19 14:07:00 porakone vdr: [7960] TS buffer on device 1 thread started (pid=7932, tid=7960) Jul 19 14:07:00 porakone vdr: [7958] [xine..put] Detected video size 720x576 Jul 19 14:07:00 porakone vdr: [7947] [input_vdr] H.264 scanner: Possible MPEG2 start code (0xb3) Jul 19 14:07:00 porakone vdr: [7958] setting audio track to 1 (0) Jul 19 14:07:09 porakone vdr: [7958] clearing device because of consecutive poll timeouts Jul 19 14:07:11 porakone vdr: [7958] [xine..put] Detected video size 720x576 Jul 19 14:07:11 porakone vdr: [7947] [input_vdr] H.264 scanner: Possible MPEG2 start code (0xb3) Apparently the "clearing device" operation on 14:07:09 seemed to do a trick which fixed the picture, so maybe the problem isn't that big? Any ideas how to make a patch out of this? There's a discussion about the problem here (in Finnish): http://www.linuxtv.fi/viewtopic.php?p=19581#19581 Best regards, Pekka Brax |
From: Alex S. <mai...@ji...> - 2007-07-02 14:27:19
|
Hi, Please find attached my second attempt at this patch that will disable the gnome screensaver when vdr-sxfe starts and enable it when it quits. The first version was originally posted to the xineliboutput mailing list, this version of the patch has more intelligent Makefile that checks for dbus dev libraries and gets the paths for the dbus includes. Most of the code is taken from this patch for mplayer: http://codebrowse.launchpad.net/~ubuntu-dev/mplayer/ubuntu-feisty/bundle/nafallo%40magicalforest.se-20070311045121-8tq06wthciy3n0sc/bundle.txt from what I could gather on the mplayer mailing list this patch was originally done by Piotr Kaczuba (pe...@at...) so most credit should go to him. The gnome_screensaver.c file is pretty much entirely his with some changes to make it work with the vdr-sxfe logging so if it's used please be sure to credit him. Any feedback appreciated. Cheers, Alex |
From: Alex S. <mai...@ji...> - 2007-06-30 13:30:10
|
Hi, Please find attached a patch that will disable the gnome screensaver when vdr-sxfe starts and enable it when it quits. Most of the code is taken from this patch for mplayer: http://codebrowse.launchpad.net/~ubuntu-dev/mplayer/ubuntu-feisty/bundle/nafallo%40magicalforest.se-20070311045121-8tq06wthciy3n0sc/bundle.txt from what I could gather on the mplayer mailing list this patch was originally done by Piotr Kaczuba (pe...@at...) so most credit should go to him. I'm pretty bad with Makefiles so it doesn't check to see if you have dbus dev libraries automatically you have to set XINELIBOUTPUT_DBUS to 1 or 0. From the original patch in the configure file they use this to find the libraries and paths: if test "$_dbus_glib" = auto && pkg-config --exists dbus-glib-1; then _dbus_glib=yes _inc_dbus_glib=`pkg-config --cflags dbus-glib-1 2>/dev/null` _ld_dbus_glib=`pkg-config --libs dbus-glib-1 2>/dev/null` fi I didn't know how to adapt this to a makefile so left it for now as my priority was getting to to compile. please let me know if this patch is of use, I did think that perhaps instead of having the disable/enable on inital run and on exit it might be better to disable when going into fullscreen mode and enable when leaving fullscreen mode. Cheers, Alex |
From: Alex S. <al...@ji...> - 2007-06-28 15:26:53
|
Petri Hintukainen wrote: > On Thu, 2007-06-28 at 15:38 +0100, Alex Stansfield wrote: >> I solved this by starting vdr with --lirc=/dev/null if anyone knows a >> better way let me know but it works so I'm happy. > > Start vdr with --lirc option and vdr-sxfe without --lirc option Well I want vdr-sxfe to pass the lirc commands, that way when I'm not watching TV I can use the remote to control other things (freevo, mplayer, etc). So I have it setup that vdr connects to /dev/null for lirc (so gets nothing) and then vdr-sxfe passes the lirc commands. This seems to work well, I'm very happy. Keep up the good work, I can't believe I used the xine plugin for so long when this was right under my nose :) Cheers, Alex |
From: Petri H. <phi...@us...> - 2007-06-28 15:15:58
|
On Thu, 2007-06-28 at 15:38 +0100, Alex Stansfield wrote: > I solved this by starting vdr with --lirc=/dev/null if anyone knows a > better way let me know but it works so I'm happy. Start vdr with --lirc option and vdr-sxfe without --lirc option - Petri |
From: Petri H. <phi...@us...> - 2007-06-28 14:59:06
|
On Thu, 2007-06-28 at 12:12 +0100, Alex Stansfield wrote: > So far I've pretty happy with it but can't for the life of me get the > lirc forwarding to work. > > Vdr is compiled with lirc support, when I start it the lircd reports > that a client connected to the device. Note that you should connect LIRC to VDR or vdr-sxfe, but not to both. > I copied the example remote.conf from xineliboutput to vdr's config > directory. I think the problem is there are no LIRC keys defined in remote.conf. (The remote.conf.example file includes bindings for X11 keyboard only). > The keyboard (also configured in the remote.conf example) works fine and > I can control VDR perfectly with it. > > The instructions regarding the use of lirc with > xineliboutput were pretty short. Yes. remote.conf.example file includes bindings for X11 keyboard only. Writing similar generic example for lirc is not possible as LIRC keys can be named freely while learning the remote controller to LIRC. You can use VDR learning mode to learn the LIRC keys. To do this, you need to connect lirc to VDR and start vdr with -P"xineliboutput --local=sxfe" instead of using vdr-sxfe. If this is not possible or requires too much work, key mapping is quite easy to do by hand too. As you now see the LIRC key names in terminal, you can write configuraton based on that. Example: if you press "Play" button on remote and see on console Keypress: LIRC PLAY add following line to remote.conf: LIRC.Play PLAY (this maps the LIRC key event "PLAY" to VDR key "Play") Then, just repeat the process for every key you are going to use. Complete list of keys VDR supports is in beginning if VDR MANUAL file. - Petri |
From: Alex S. <al...@ji...> - 2007-06-28 14:38:50
|
err yeah, I'm an idiot. I got the two columns the wrong way around in the remote.conf. Had the lirc remote calls in the left hand one and the vdr commands to call in the left. Once I sorted that out I got confused that for every key press I made it did two. That I realised was because whilst vdr-sxfe was passing the lirc command, vdr was also capturing it from /dev/lircd itself. I solved this by starting vdr with --lirc=/dev/null if anyone knows a better way let me know but it works so I'm happy. Cheers, Alex |
From: Alex S. <mai...@ji...> - 2007-06-28 11:12:30
|
Hi, This was originally sent to the VDR mailing list before I realised there was a xineliboutput ml. -- I've recently decided to try xineliboutput over my usual choice of xine plugin. So far I've pretty happy with it but can't for the life of me get the lirc forwarding to work. Lirc is installed, the controller is setup and tested to work (it's an mceusb2). Vdr is compiled with lirc support, when I start it the lircd reports that a client connected to the device. I copied the example remote.conf from xineliboutput to vdr's config directory. When I start vdr-sxfe with --lirc and --verbose it starts and shows me the tv. When I click 'up' on the remote (which is one of the buttons configured in the example remote.conf) VDR does nothing, a look at the console shows that vdr-sxfe caught the lirc call and dealt with it. It seems it's not getting to vdr. It's the same with any button I press, whether it's in remote.conf or not. The keyboard (also configured in the remote.conf example) works fine and I can control VDR perfectly with it. Have I missed a step? The instructions regarding the use of lirc with xineliboutput were pretty short. Any help greatfully appreciated. Let me know if you need me to provide any config files, etc. -- Cheers, Alex |
From: Petri H. <phi...@us...> - 2007-03-17 19:17:31
|
Project: VDR xine-lib output device (xineliboutput) Package: xineliboutput Date : 2007-03-17 21:04 Project "VDR xine-lib output device" ('xineliboutput') has released the new version of package 'xineliboutput'. You can download it from SourceForge.net by following this link: <https://sourceforge.net/project/showfiles.php?group_id=160063&release_id=494401> You receive this email because you requested to be notified when new versions of this package were released. If you don't wish to be notified in the future, please login to SourceForge.net and click this link: <https://sourceforge.net/project/filemodule_unmonitor.php?filemodule_id=179891> If you lost your SourceForge.net login name or password, refer to this document: <https://sourceforge.net/docman/display_doc.php?docid=760&group_id=1> Note that you may receive this message indirectly via one of your mailing list subscriptions. Please review message headers before reporting unsolicited mailings. |
From: Petri H. <phi...@cc...> - 2007-01-07 14:47:35
|
Project: VDR xine-lib output device (xineliboutput) Package: xineliboutput Date : 2007-01-07 16:41 Project "VDR xine-lib output device" ('xineliboutput') has released the new version of package 'xineliboutput'. You can download it from SourceForge.net by following this link: <https://sourceforge.net/project/showfiles.php?group_id=160063&release_id=476578 > or browse Release Notes and ChangeLog by visiting this link: <https://sourceforge.net/project/shownotes.php?release_id=476578> You receive this email because you requested to be notified when new versions of this package were released. If you don't wish to be notified in the future, please login to SourceForge.net and click this link: <https://sourceforge.net/project/filemodule_unmonitor.php?filemodule_id=179891> If you lost your SourceForge.net login name or password, refer to this document: <https://sourceforge.net/docman/display_doc.php?docid=760&group_id=1> Note that you may receive this message indirectly via one of your mailing list subscriptions. Please review message headers before reporting unsolicited mailings. |