Assumed I have 2 free Tuners and I zapp through the channels of one tuner. Would it be possible to tune the 2. tuner to the same time to the after next channel in change direction, so that for the next channel change in the same direction it would be possible to channge to the 2. tuner instead of changing the channels of the 1. tuner. Channels gets changed afterwords. Does this work? Is changing of the tuners faster than changing channels? Would this flicker? Does this happen already?
Gerald
On Wed, Jan 21, 2009 at 8:33 PM, Gerald Dachs vdr@dachsweb.de wrote:
If you're going into that direction, I think in addition to zaps there might be a need to get back to previous channel regardless of zapping or manual channel selection. Many remote controls even have a special button for that.
Am Wed, 21 Jan 2009 21:07:09 +0200 schrieb Alex Betis alex.betis@gmail.com:
Doable with one tuner more, but the question is still, is changing the primary device faster than changing the channels?
I am a programmer, but I don't know so much about the things that happen inside the vdr. I have looked already some times inside the source code. It is c++ like I do it, a skeleton of c++-code with pure c inside :), but before I spend my time to dig deep enough into it to understand what has to be changed I want to know, that it makes sense.
Gerald
On Wed, Jan 21, 2009 at 11:07 AM, Alex Betis alex.betis@gmail.com wrote:
You can return to the previous channel by pressing 0.
I don't know that the faster channel change time (if it even would be faster) would be worth the effort. My channel changes are 1-2 seconds. Sure I wish it was instant but I think I'll live. I usually change the channel manually or using the guide. Don't remember ever doing sequential changes but I guess someone out there does. :)
On 21.01.2009 19:33, Gerald Dachs wrote:
Channel switching delay is caused by two delays: First, the time to tune and lock the new transponder, second, the time till the next compressed stream starting point (I-Frame or audio syncword) is reached. This second time can be up to a second by its own.
To get instant switching, you would have to also decode the second stream in the background, so that the current frame is available the moment it is needed. Or you can buffer the last GOP of the stream and go back to that point on channel switch. You would have to ring-buffer up to one complete GOP permanently in memory to keep the delay from there on.
Both things are tricky to implement, require work on the output devices, and are probably not worth the effort.
Cheers,
Udo
On 23 Jan 2009, at 23:55, Udo Richter wrote:
Depends if you mean "not worth the effort" == (salary paid developer to implement feature - extra income due to extra sales) or if we're talking some hacking away on it for the heck of it. :)
With vdpau and other accelerated output methods on generic opengl capable hardware becoming available, it can easily be seen advantageous to be able to fetch a new transponder while the old is still in use, to do picture in picture or other fancy effects. The frontend could be more intelligent, and just request channels as it see fit, this is also what's needed in order to implement multi- frontend setups with vdr. The recording subsystem can fetch as many channels as it needs as long as there is enough free tuners, so why shouldn't the frontend be able to do it as well?
Udo Richter wrote:
Yes, the only case i think this could be useful is when the number of tuners >= transponders/muxes and you always receive all of them. Hmm, it might actually make sense for dvb-t (or -c) in some cases. Anyway, back when i was using a dvb-s ff card the tuning itself seemed to be slow, so what i did was cache some parms such as freq, srate, fec, voltage and tone in the driver, to avoid touching the hw/firmware for those that didn't change (the dvb api resulted in the driver always getting a new set of parms, even when some/most of them hadn't changed). That seemed to speed up the channel switches a bit, but as the card was never 100% reliable and would sometimes fail to correctly tune, i never went further with that. Now i think it was probably the pci host that was causing the trouble, and the changes may have been fine.
artur
-
Alex Betis -
Artur Skawina -
Gerald Dachs -
Torgeir Veimo -
Udo Richter -
user.vdr