Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 20 Apr 2007, at 19:21, Alasdair Campbell wrote: I'll have a look at the softdevice src this weekend compare with xineliboutput. Why aren't you just using softdevice? -- Torgeir Veimo [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] re-use devices in transfer mode
Anssi Hannula wrote: However, the usual use-already-tuned-devices check in GetDevice() only checks for device-Receiving(), which does not report transfer-moded device, resulting in the new receiver being started on second device, thus both devices being reserved for receiving data from the same transponder. Without taking a deeper look into it right now, I think there was some trap with detecting transfer mode in case that some streams are received additionally to live mode, for example teletext with osdteletext plugin. You may want to double-check this. Changes to GetDevice tend to have strange side effects. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 21 Apr 2007, at 11:37, Torgeir Veimo wrote: On 20 Apr 2007, at 19:21, Alasdair Campbell wrote: I'll have a look at the softdevice src this weekend compare with xineliboutput. Why aren't you just using softdevice? Ignore my question, I hadn't read the full thread.. Saturday morning hungover.. -- Torgeir Veimo [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] re-use devices in transfer mode
Anssi Hannula wrote: However, the usual use-already-tuned-devices check in GetDevice() only checks for device-Receiving(), which does not report transfer-moded device, resulting in the new receiver being started on second device, thus both devices being reserved for receiving data from the same transponder. Can this patch also be applied to vdr-1.5.1 with a little manual fixing? Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 21/04/07, Tony Houghton [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], Alasdair Campbell wrote: Because I'm using a 550Mhz P3, my only option is to use the xineliboutput until I figure out what is causing the big CPU load variations. As I've never had softdevice successfully running on this television, I can't really say anything about it's quality, though I know there's been lots of work in respect to the matrox cards. Another alternative is to use the other vdr xine plugin with df_xine, which gives very good results with my Matrox (G450). About the only problem is that it sometimes doesn't scale the OSD correctly, chopping off the right hand side. Something to do with 16:9 vs 4:3 I'm sure. And I'm seeing something similar to that with More4 other less popular channels on UK DVB-T. The lower resolution or incorrect imprinted aspect ratio causes the OSD to zoom to the left two thirds, with the right third off screen. As this only happens on one or two channels that I watch, It's not bothering me too much. xineliboutput is exactly what I need at the moment, with my headless recording server and one streaming client - I wanted to control the server osd directly for now. I don't know whether it can handle letterboxing an interlaced 16:9 picture for a 4:3 TV. I heard that softdevice gets, or used to get that wrong, as if it treated the two fields as one frame and scaled them together, rather than scaling each field separately. Maybe the hardware doesn't support the latter, in which case it would have to use slow software scaling. When I was using softdevice I had a 4:3 TV, but wanted to view 16:9 content in full (so with black horizontal bars above and below video). With this setup, interlaced video would show artifacts. I believe that's been fixed by the kind softdevice guys. My experience with softdevice was that the A/V sync was a bit off for live TV and way off for recordings. df_xine is spot on. If you want to be able to stop/start df_xine and/or watch other videos all with one remote control you can use boxstar as a front-end. I had issues with audio sync with softdevice too, can't really say how it deals now, as I'm underpowered. So boxstar will give me direct control over VDR similar to xineliboutput? I hadn't realised that. At the moment I'm not looking to change my setup, just tweak what I have :-) (Sorry if the formatting on this email is all wrong, I'm writing this with lynx on the console, as my laptop is without X at the moment...) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 21/04/07, Petri Hintukainen [EMAIL PROTECTED] wrote: On Fri, 2007-04-20 at 19:21 +0100, Alasdair Campbell wrote: I'll have a look at the softdevice src this weekend compare with xineliboutput. Better to compare with xine-lib (src/video_out/video_out_directfb.c), as there's not even single line of directfb code in xineliboutput :) Xine-lib DirectFB unscalded OSD (hardware alpha blending) is currently disabled for some matrox cards because of problems with tv-out. See notes on revisions 1.40 and 1.42 at http://xine.cvs.sourceforge.net/xine/xine-lib/src/video_out/video_out_directfb.c?view=log (so, unscaled OSD might work with xine-lib 1.1.2 (?) and recent DirectFB (?)). - Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] re-use devices in transfer mode
Udo Richter wrote: Anssi Hannula wrote: However, the usual use-already-tuned-devices check in GetDevice() only checks for device-Receiving(), which does not report transfer-moded device, resulting in the new receiver being started on second device, thus both devices being reserved for receiving data from the same transponder. Without taking a deeper look into it right now, I think there was some trap with detecting transfer mode in case that some streams are received additionally to live mode, for example teletext with osdteletext plugin. You may want to double-check this. Changes to GetDevice tend to have strange side effects. I proposed this same patch previously, but it was suggested to instead of the check for transfer mode to just change the Receiving() to Receiving(true). I didn't see any caveats back then, so I agreed. Unfortunately, that resulted in problems with situations that you describe. However, this original version of the patch does explicitely check for a device in transfer-mode, and does not care about osdteletext receivers. What could happen is that this would match the transfer modes whose receiverdevice() is the primary device itself (some situations related to the ca or ac3, I guess), thus starting the new receiver in the primary device, which could cause side-effects if the card's bandwidth is not wide enough. However, even without this patch, when a recording is already taking place on the primary device, this rule matches and another recording could be started on the primary device. I don't know if we should be preventing these from happening, but if we do, I think we could make the rule as imp |= !device[i]-Receiving() (device[i] != cTransferControl::ReceiverDevice() || device[i]-IsPrimaryDevice()) || ndr // prevents matching local-transfer-moded primary-device or imp |= !device[i]-Receiving() device[i] != cTransferControl::ReceiverDevice() || device[i]-IsPrimaryDevice() || ndr // addidtionally prevents matching recording primary-devices -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] re-use devices in transfer mode
Stone wrote: Anssi Hannula wrote: However, the usual use-already-tuned-devices check in GetDevice() only checks for device-Receiving(), which does not report transfer-moded device, resulting in the new receiver being started on second device, thus both devices being reserved for receiving data from the same transponder. Can this patch also be applied to vdr-1.5.1 with a little manual fixing? Thanks. I think so, by modifying line 330: imp = 1; imp |= !device[i]-Receiving() || ndr; to imp = 1; imp |= !device[i]-Receiving() device[i] != cTransferControl::ReceiverDevice() || ndr; -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
