Re: [vdr] playing 2 audio streams at the same time
Peter Münster wrote: Is it possible with vdr, to send one audio channel to the headphones and the other audio channel to the speakers (or another headphones)? I don't think that this is currently possible, though it would be a really great feature. The easy way from hardware point - use stereo channels separate - would be rather tricky as you would have to recode the audio signal on the fly. But an secondary sound card output (dvb + sound card out or 2 sound cards) should be possible as plugin. Maybe even overlay an existing 5.1 output with different language on the rear channels. Anyone who ever wanted to write a plugin and had just no idea what? ;) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] How to properly attach stream to live view?
Hi list, Is there a proper way to attach another stream receiver to the currently receiving channel, and - more important - disconnect it properly on channel change? The problem arises from difficulties with the osdteletext plugin. (see http://www.vdr-portal.de/board/thread.php?threadid=70372 ) The problem of the current implementation is that on channel change the teletext receiving stream is disconnected on cStatus::ChannelSwitch(dev,0), which is _after_ GetDevice picked the device for the next channel. And since the teletext stream is still being received, the primary receiving device (FF card) is 'in use' and has NeedsDetachReceiver set - so a budget card is preferred for live viewing. (FF cards normally use no cReceivers at all for live view, so the device is automatically 'free' on channel switch.) (Btw: On 2x budget only systems, it seems as if the live view will constantly switch between the devices for the same reason, or?) Taking a look at the subtitles receiver shows that the subtitles stream is disconnected at the beginning of cDevice::SetChannel, which is right before the GetDevice call, thus a FF card is 'free' again at the GetDevice call. If there's no proper way to solve this right now, I could imagine a few VDR changes that would: - Find a way to mark a receiver as being 'live related' and disconnect it before live channel switching. - Find a way to mark a receiver as being 'extremely unimportant', and don't count them as NeedsDetachReceiver or as Receiving() in that case, maybe by using -1 as priority. - Extend GetDevice to ignore some receivers that will be disconnected afterwards anyway - maybe define 'related' receivers that will disconnect together. - Notify plugins about the upcoming channel switch _before_ the GetDevice call, so live receivers can be disconnected. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to properly attach stream to live view?
On 06/07/08 12:43, Udo Richter wrote: Hi list, Is there a proper way to attach another stream receiver to the currently receiving channel, and - more important - disconnect it properly on channel change? The problem arises from difficulties with the osdteletext plugin. (see http://www.vdr-portal.de/board/thread.php?threadid=70372 ) The problem of the current implementation is that on channel change the teletext receiving stream is disconnected on cStatus::ChannelSwitch(dev,0), which is _after_ GetDevice picked the device for the next channel. And since the teletext stream is still being received, the primary receiving device (FF card) is 'in use' and has NeedsDetachReceiver set - so a budget card is preferred for live viewing. (FF cards normally use no cReceivers at all for live view, so the device is automatically 'free' on channel switch.) (Btw: On 2x budget only systems, it seems as if the live view will constantly switch between the devices for the same reason, or?) Taking a look at the subtitles receiver shows that the subtitles stream is disconnected at the beginning of cDevice::SetChannel, which is right before the GetDevice call, thus a FF card is 'free' again at the GetDevice call. If there's no proper way to solve this right now, I could imagine a few VDR changes that would: - Find a way to mark a receiver as being 'live related' and disconnect it before live channel switching. - Find a way to mark a receiver as being 'extremely unimportant', and don't count them as NeedsDetachReceiver or as Receiving() in that case, maybe by using -1 as priority. Using a negative priority would be the right way: cReceiver(tChannelID ChannelID, int Priority, int Pid, const int *Pids1 = NULL, const int *Pids2 = NULL, const int *Pids3 = NULL); /// ... /// Priority may be any value in the range -99..99. Negative values indicate /// that this cReceiver may be detached at any time (without blocking the /// cDevice it is attached to). Why does the osdteletext plugin use a non-negative priority at all? - Extend GetDevice to ignore some receivers that will be disconnected afterwards anyway - maybe define 'related' receivers that will disconnect together. - Notify plugins about the upcoming channel switch _before_ the GetDevice call, so live receivers can be disconnected. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to properly attach stream to live view?
Klaus Schmidinger wrote: - Find a way to mark a receiver as being 'extremely unimportant', and don't count them as NeedsDetachReceiver or as Receiving() in that case, maybe by using -1 as priority. Using a negative priority would be the right way: cReceiver(tChannelID ChannelID, int Priority, int Pid, const int *Pids1 = NULL, const int *Pids2 = NULL, const int *Pids3 = NULL); /// ... /// Priority may be any value in the range -99..99. Negative values indicate /// that this cReceiver may be detached at any time (without blocking the /// cDevice it is attached to). Why does the osdteletext plugin use a non-negative priority at all? Good question. Though, this alone doesn't fix it. This is VDR without osdteletext, switching to a different transponder: GetDevice: Device 0 Impact 020c4c6e Detach:0 GetDevice: Device 1 Impact 060c4c60 Detach:0 Device 0 is the FF card, device 1 is the budget card. The FF card gets a boost by the first rule: imp |= LiveView ? !device[i]-IsPrimaryDevice() || ndr : 0; The FF card is the primary device, and it has nothing to detach, so this is imp |= true ? !true || false : 0 returning false, giving the FF card a priority boost. The same with osdteletext (priority patched to -1) running: GetDevice: Device 0 Impact 060c4c7e Detach:1 GetDevice: Device 1 Impact 060c4c60 Detach:0 What happened? The ndr clause canceled the FF boost. The actual path in cDvbDevice::ProvidesChannel is ProvidesTransponder(Channel) - Priority = 0 Receiving(true) - !dvbTuner-IsTunedTo(Channel), leading to NeedsDetachReceivers=true. Priority=0 is the new live channel priority, not the -1 of osdteletext. Receiving(true) does count -1 receivers, as opposed to Receiving(false). The next counting rule is the 5'th last low priority rule to prefer channels without receivers. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] False timer conflict
Hi! I saw these in my syslog: Jun 7 10:12:01 sauron vdr: [5433] info: 1 timer conflict(s)! First at 11.06 00:19. Show them? Jun 7 10:42:00 sauron vdr: [5433] info: 1 timer conflict(s)! First at 11.06 00:19. Show them? At the time this recording is scheduled, only one of my two cards would be in use. The recording was scheduled by EPGSearch on an encrypted channel, where I don't have a smartcard/CAM/whatever for. I'll therefore delete the timer entry, but maybe the error message could say something like timer on an encrypted channel, but no decryption possible or so to clarify things. Ciao Martin ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [OT] Generic GPU-Accelerated Video Decoding
Do you know about or are using: http://www.nvidia.com/object/cuda_home.html ? - Original Message - From: Gregoire Favre [EMAIL PROTECTED] To: vdr@linuxtv.org Sent: Friday, June 06, 2008 1:51 AM Subject: [vdr] [OT] Generic GPU-Accelerated Video Decoding Hello, just found out at http://code.google.com/soc/2008/xorg/appinfo.html?csaid=ACD6AA025594454A that : he purpose of this project is to produce a video decoding solution for GPUs that are supported by the Gallium3D driver framework. The project will attempt to implement the XvMC API using the programmable pipeline of a typical GPU, thereby providing accelerated video decoding to a wide variety of hardware. Since the decoding will be implemented using the GPU's programmable pipeline, it is important to note that this solution should support all recent GPUs regardless of whether or not they include dedicated video decoding hardware. It is hoped that this GPU-based acceleration will allow for real-time play back of HD video streams on even modest hardware. The implementation will be developed and tested using Gallium3D's SoftPipe driver, a stable software reference implementation, and later Nvidia hardware and the Nouveau driver. You can follow the progress at http://www.bitblit.org/gsoc/gallium3d_xvmc.shtml Could be pretty usefull to lots of us :-) -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre ___ 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
