Re: [vdr] Understanding the dataflow
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
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
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
[vdr] Understanding the dataflow
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 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