Re: [vdr] Understanding the dataflow

2012-04-21 Thread Klaus Schmidinger

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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Understanding the dataflow

2012-04-21 Thread Udo Richter
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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Understanding the dataflow

2012-04-21 Thread Roland Tapken

  What is cPlayer? As cTransfer implements both cReceiver and cTransfer
 
 Typo? It should read cTransfer implements both cReceiver and *cPlayer*:

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

 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).

 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 :-)

 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

-- 
Viele Grüße,

Roland


signature.asc
Description: This is a digitally signed message part.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr