[vdr] Understanding the dataflow

[Roland Tapken]

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

[Klaus Schmidinger]

Post by Roland Tapken
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.

Post by Roland Tapken
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).

Post by Roland Tapken
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 {
...
};

Post by Roland Tapken
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?

Post by Roland Tapken
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

[Udo Richter]

Post by 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

[Roland Tapken]

Post by Klaus Schmidinger

Post by Roland Tapken
What is cPlayer? As cTransfer implements both cReceiver and cTransfer

Yes, a typo. I shouldn't write mails at that time :)

Post by Klaus Schmidinger
cPlayer sends data to the cDevice - what's not to understand here?

I thought about cDevice as input devices only. After reading PLUGINS.html and
Udo's mail I understand that a cDevice also represents output devices (or both
at the same time when using FF cards).

Post by Klaus Schmidinger
Use the source, Luke! ;-)

Although I'm doing software development for about 10 years I must admin that I
very rarely came in contact with C++ code. I can read and write it, but it
takes longer for me to get an overview as, let's say, in Java code. For
example I had never before to deal with multiple inheritance (besides of
Interfaces). But I'm doing my best :-)

Post by Klaus Schmidinger
You might also want to take a look at PLUGINS.html, especially the sections
on "Players", "Receivers" and "Devices"

Thanks for the hint, I assumed that there must be further documentation, but
somehow I missed this file.

Roland