[vdr] Re: Ideas for DVBVideoLan / Question to Convergence developers

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

----- Original Message -----
From: "René Bartsch" <rene@bartschnet.de>
To: <vdr@linuxtv.org>
Sent: Friday, March 01, 2002 6:28 PM
Subject: [vdr] Ideas for DVBVideoLan / Question to Convergence developers


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

We should generally use hw-decoder-dummies. (e.g. if you habe DVB-S 1, 2, 3 you can define dummies on 4, 5, 6 ...)
So something could be played back without using a DVB-S (keeping it free for recording ...)

>
> Maybe we'll find a way to mux-in OSD-function in the future.

Could be done by generating a MPEG2-stream with OSD-data on a additionally PID ... (second window on sw-player)

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