[vdr] Re: Implementing new device into a plugin :

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Philippe wrote:
> 
> Hi,
> 
> As I told you before, I'm working on a new class derived from cDevice
> (cEm84Device).
> 
> My device can decode several audio format (AC3, DTS, PCM) and video
> format (MPEG2, MPEG1).
> This device is also OSD capable but I'll work on it later.
> 
> To create this new class I read the VDR documentation but I have
> questions about the following methods :
> 
> 1) void cDevice::Play( void ) [virtual]
> What is the difference between the playModes
> pmNone, pmAudioVideo, pmAudioOnly, pmAudioOnlyBlack,
> pmExtern_THIS_SHOULD_BE_AVOIDED
> 
> 2) int cDevice::PlayVideo ( const uchar *Data, int Length ) [virtual]
> DOC : "Actually plays the given data block as video. The data must be
> part of a PES (Packetized Elementary Stream) which can contain one video
> and one audio strem."
> 
>   a) I can't figure out which part of VDR is sending me this Packet
>   b) Does it mean that I have to demux the packet to get only the video
> part
>   c) How many frames are passed to this method ? (only one, more ?)
> 
> 3) int cDevice::PlayAudio ( const uchar *Data, int Length ) [virtual]
> DOC : "Plays additional audio streams, like Dolby Digital. A derived
> class must call the base class function to make sure data is distributed
> to all registered cAudio objects."
> 
>   a) Why this method seems different from the PlayVideo one? Does it
> mean that a device can only replay video ?
>   b) Same questions as above (PlyaVideo) for the Data sent (Multiple
> frames ? Demux needed?)

There will be a few changes in that area before the final version 1.2.0.
Basically the cDevice will get _one_ function that receives the entire data
stream to be replayed, and will parse that stream and send the various
audio/video/whatever packets to the appropriate functions of the actual
device (through virtual functions).

> 4) Question about the VDR design :
> I understand that the first purpose of VDR was to build an application
> based on DVB card but since some people have written plugins like the
> streamServer / streamClient, could you explain me why you don't move the
> DVB code to a plugin ?
> 
> 5) As your software is every time less DVB dependant, Here is my last
> question :
> Are you going to change the VDR design ? Let me explain :
> As the VDR software can replay many different video/audio format, don't
> you think that i twill be easier if th VDR core handle streams and the
> plugins all the input / output method ?
> For example :
> It should be interessant to make the following actions at the same time:
> Read Data from the "DVB plugin" on the current channel
> Write this stream to the HD
> Read Data from a file (CD-R or HD)
> Send this Data to the matching Demuxer Plugin which will send the chosen
> videostream to the display plugin and the chosen audio stream to the
> audio hardware
> 
> I don't know if you will understand what I mean because of my bad
> english but in fact, I think that your software should be cut into to
> parts :
>  - VDR core : stream handling
>  - VDR Plugins : Input, Output elements (Video, Audio, EPG, ...).

I believe I already did that by implementing a plugin interface for
various things (especially for implementing your very own devices).
The DVB device support is the main purpose of VDR, so I'll leave this
in the core code. If your system doesn't have any DVB cards, VDR just won't
use them and will rely on your cDevice plugins.

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe vdr" as subject.