Hi Folks
I (along with some other folks at my company) are developing a LinuxDVB implementation for one of our devices. Since VDR (combined with vdr-dvd) is one of the most feature complete applications targeting this API we have been using it a one of our reference clients.
One of the aspects of VDR's behaviour that surprised me is that it never sets the audio stream type (AUDIO_SET_STREAMTYPE or AUDIO_SET_ATTRIBUTES). This leaves the LinuxDVB implementation to guess the stream type from its contents or its PES headers.
Is the absence of the above LinuxDVB operations from VDR an oversight because the existing full-featured cards don't need them or have these calls been deliberately omitted? Would patches to introduce them be accepted?
Daniel THOMPSON wrote:
Hi Folks
I (along with some other folks at my company) are developing a LinuxDVB implementation for one of our devices. Since VDR (combined with vdr-dvd) is one of the most feature complete applications targeting this API we have been using it a one of our reference clients.
One of the aspects of VDR's behaviour that surprised me is that it never sets the audio stream type (AUDIO_SET_STREAMTYPE or AUDIO_SET_ATTRIBUTES). This leaves the LinuxDVB implementation to guess the stream type from its contents or its PES headers.
Is the absence of the above LinuxDVB operations from VDR an oversight because the existing full-featured cards don't need them or have these calls been deliberately omitted?
VDR simply writes the video and audio data to the device - apparently at least with the FF cards nothing else is necessary. After all, the device that plays the data _has_ to intepret the data, so why should an application do that, too?
Would patches to introduce them be accepted?
Where would that information come from?
Klaus
-
Daniel THOMPSON -
Klaus Schmidinger