[vdr] Ideas for DVBVideoLan / Question to Convergence developers

[René Bartsch <rene@bartschnet.de>]

Hi,

I've thought about where to connect to the Convergence-driver with DVBVideoLan.

The simpliest way would be to grab the complete PS/PES-stream sent to the hardware decoder,
buffer it for avoiding underruns or breaks and to send it by RTP.

As for the complete demuxing is done by the player, there won't be any (de-)muxing or
A/V-syncing problems for server and network.

That interface shouldn't directly be hardware-related but in a upper level of the driver to create
a decoder-dummy (so, that e.g. VDR can send it's PS/PES-stream to a imaginary MPEG-decoder-dummy
which simply reroutes to the RTP-stack when using a low-budget card).

Maybe we'll find a way to mux-in OSD-function in the future. Another possibilty should be to RTP PIDs (Internet, DataServices, ...)
So we should consider that for the interface.

An additional function-call patched into the Convergence-driver could look like this:

"rtpstream( serverIP( ), serverPORT( ), streaming( ), interface( ) )"

where "serverIP" is the IP of the network interface (multicast- or single client address)
and "serverPORT" for the port. Streaming hands over additional options.

This could be e.g. "off" or "false" to stop streaming or options to start streaming.
"video" could be used to simply stream the PES/PS-stream sent to the decoder
and given PIDs like "512 384 67 3052" could define to send that PIDs of the just 
received DVB-stream by RTP.

Last, but maybe not least interface( 1 2 4 ...) could define which DVB-cards to be used.

Tuning and all other stuff would be done by the standard function-calls in the Convergence-driver.
So, the existing software stays compatible.

And now the big question to Convergence:

Which function-calls/APIs in which files of the Convergence-driver would please Mr. Winkler?

(as for I'm a very poor programmer I'll limit myself on doing research - except you want some bluescreens on UNIX? ;o)  )


Rene