Hi,
there is a long discussion at http://www.vdr-portal.de/board16-video-disk- recorder/board55-vdr-plugins/111788-wunschkonzert-livebuffer-plugin/ (german) about the old livebuffer patch and how a new one could look alike.
Since I'm missing some features of a "real" livebuffer very much and have some ideas how this could be implemented in an effective and less-invasive way I started to familiarize myself into the VDR source.
I still have problems to understand the way the stream data takes from the the dvb device to the screen. I would be very thankfully if you can help me to get the "big picture". These are my assumptions. Please correct me where I'm wrong, and complete where I missed some point.
There's a cDevice, I think that's an abstraction of the real hardware. cReceiver controls the device by selecting a channel and transportings stream data to the player. This means, if you watch a show and record another on the same device there would be one device and two receivers.
A device could also be a foreign source, e.g. in streamdev.
A special receiver is cRecorder. It just selects a channel and writes the stream data into a file.
What is cPlayer? As cTransfer implements both cReceiver and cTransfer I thought about it as some kind of frontend abstraction (FF-output, xine, streamdev-server). But it seems that cPlayer directly acts on cDevice, and that doesn't make sense to me at the moment.
Furthermore, I'm still not quote sure where all these components where attached to each other.
Best regards,
Roland
On 20.04.2012 23:58, Roland Tapken wrote:
Hi,
there is a long discussion at http://www.vdr-portal.de/board16-video-disk- recorder/board55-vdr-plugins/111788-wunschkonzert-livebuffer-plugin/ (german) about the old livebuffer patch and how a new one could look alike.
Since I'm missing some features of a "real" livebuffer very much and have some ideas how this could be implemented in an effective and less-invasive way I started to familiarize myself into the VDR source.
I still have problems to understand the way the stream data takes from the the dvb device to the screen. I would be very thankfully if you can help me to get the "big picture". These are my assumptions. Please correct me where I'm wrong, and complete where I missed some point.
There's a cDevice, I think that's an abstraction of the real hardware.
Right.
cReceiver controls the device by selecting a channel and transportings stream data to the player.
Not quite. A cReceiver receives data from the cDevice it has been attached to. It can write that data to disk, stream it to some remote location, or send it to a cPlayer (or do whatever else it finds useful).
This means, if you watch a show and record another on the same device there would be one device and two receivers.
A device could also be a foreign source, e.g. in streamdev.
A special receiver is cRecorder. It just selects a channel and writes the stream data into a file.
What is cPlayer? As cTransfer implements both cReceiver and cTransfer
Typo? It should read "cTransfer implements both cReceiver and *cPlayer*":
class cTransfer : public cReceiver, public cPlayer { ... };
I thought about it as some kind of frontend abstraction (FF-output, xine, streamdev-server). But it seems that cPlayer directly acts on cDevice, and that doesn't make sense to me at the moment.
cPlayer sends data to the cDevice - what's not to understand here?
Furthermore, I'm still not quote sure where all these components where attached to each other.
Use the source, Luke! ;-)
You might also want to take a look at PLUGINS.html, especially the sections on "Players", "Receivers" and "Devices"
Klaus
Am 20.04.2012 23:58, schrieb Roland Tapken:
What is cPlayer? As cTransfer implements both cReceiver and cTransfer I thought about it as some kind of frontend abstraction (FF-output, xine, streamdev-server). But it seems that cPlayer directly acts on cDevice, and that doesn't make sense to me at the moment.
Furthermore, I'm still not quote sure where all these components where attached to each other.
A cDevice can be both, input device and output device. A cReceiver can generally receive stream data like video, audio, subtitles, teletext, EPG, and so on, from a device. A cPlayer provides video/audio data for replay and feeds it into the output device. A cControl acts as the controlling interface of a cPlayer. It can handle keyboard and OSD interaction for a cPlayer device. A cTransfer is a cReceiver and a cPlayer, and just pumps data between these two.
One thing to understand is that a cDevice can be stream source and output device at the same time. Generally, if you switch to a channel, the output device will be asked to show a specific channel. Only if the device itself is unable to do this on its own, a different device will provide the video stream, and a cTransfer is created to transport all the data from the receiving to the output device. 'Full Featured' devices can handle all of this internally. TT-6400 cards, for example, even continue to display live TV while the computer is rebooting.
The general way to switch to a channel is:
- cDevice::PrimaryDevice()->SwitchChannel(channel, LiveView) Instruct the primary device to switch to a channel
- cDevice::SetChannel(Channel, LiveView) Actually handles the switch
- cDevice::GetDevice(Channel, Priority, LiveView, Query) Picks the device that will be receiving. Tries hard to prefer the primary device (output device) as source device too.
If receiving device is an other than the output device, a transfer control / transfer device is created to link them.
One more thing to be aware of: Old non-HD FF cards can only either receive or directly display a video stream. If you watch and record a stream, the recording will usually be on a different device, so two devices will tune to that channel. If there is no other device, and both need to use the same receiving device, then live viewing has to be done using transfer mode. (might break on high bandwidth channels.) I'm not completely sure where in the code this is handled, though. AFAIK the TT6400 cards technically can record and display at the same time, but I'm also not sure whether this is already implemented or still handled the 'old' way.
Cheers,
Udo
-
Klaus Schmidinger -
Roland Tapken -
Udo Richter