VDR Streamdev Plugin

Hi,

a SAT IP plugin for VDR is already available: http://www.saunalahti.fi/~rahrenbe/vdr/satip/

Hi,

yes, I am aware of this plugin.
However, it is a SAT>IP client plugin and not a SAT>IP server plugin.

I have already started to implement componentRTSP.[ch] and connectionRTSP.[ch]
A lot of code from connectionHTTP and connectionVTP can be reused.

I had to modify the class cStreamdevWriter to also be able to write TS-in-RTP packets, rather than only TS-in-UDP packets, because SAT>IP uses the protocol combination RTSP/RTP for communication.

As RTSP is similiar to HTTP, it is possibe to reuse the code from the HTTP part for parsing and response generation.

Currently, I am a bit stuck how to use the livestreamer. I do not know if I have to use the filterstreamer of not.
Basically, a RTSP client SETUP request tunes the frontend and the RTSP client PLAY request starts sending the stream via RTP.
This behaviour is the same as in VTP (commands TUNE and PORT). So I can also party reuse the code from there.

The RTSP client can request any PID from a tuned TS. Would this at all be possible with VDR?

Hi,

yes, I am aware of this plugin.
However, it is a SAT>IP client plugin and not a SAT>IP server plugin.

Oops - sorry! Should have taken a closer look...
Seems you already made some good progress. I'll try to help whenever I can, however my time is very limited at the moment.

Currently, I am a bit stuck how to use the livestreamer. I do not know if I have to use the filterstreamer of not.

Filterstreamer provides the interface needed by VDR's section handler. I don't think that it will be helpfull. Take cStreamdevPatFilter to insert SI data into the TS stream.

The RTSP client can request any PID from a tuned TS. Would this at all be possible with VDR?

You could parse PAT/PMT just like cStreamdevPatFilter does and add all the PIDs you can find.

After browsing through the specs, let me share some thoughts:

I think it makes sense to implement SSDP as a separate componentSSDP - just in case someone wants to add DLNA in the future.

Unless you want to implement the "Unicast Only Profile" IGMP will be needed, too. At the moment streamdev implements IGMPv2/1 but not IGMPv3. The specs say "IGMPv3 mandates backwards compatibility with IGMPv2 but SAT>IP servers do not have to understand IGMPv2 messages". So it's not unlikely that there are SAT>IP clients which also don't talk IGMPv2.

Some files need to be served by the streamdev HTTP server (e.g. XML device description and icons). Serving files from a directory has been on my list for a while to get icons and an external CSS file for the HTML menu. But as more and more different contents are added to the HTTP server, I think it's time to introduce some sort of URL handler interface and move code from cConnectionHTTP::ProcessURI/ProcessRequest/*FromString to subclasses of this interface.

The RTSP client can request any PID from a tuned TS. Would this at all be possible with VDR?

You could parse PAT/PMT just like cStreamdevPatFilter does and add all the PIDs you can find.

Thanks for the hint.
I am still unsure about how VDR internals actually work.
The SAT>IP basically extends DVB frontends over the network. So there is no knowledge of something like channels.
However, VDR seems to act on channels only. So would it be possible for streamdev to get all the PIDs of tuned transponder's TS from VDR?
Think of a SAT>IP client which is clever and requests two channels (one for live TV, one for recording) within the same RTSP/RTP session.

After browsing through the specs, let me share some thoughts:

I think it makes sense to implement SSDP as a separate componentSSDP - just in case someone wants to add DLNA in the future.

Yes, but I would suggest to add that later in a second step. For now, I would like to leave the whole discovery thing out of the plugin and use a seperate tool(process) which announces the SAT>IP server.

Unless you want to implement the "Unicast Only Profile" IGMP will be needed, too. At the moment streamdev implements IGMPv2/1 but not IGMPv3. The specs say "IGMPv3 mandates backwards compatibility with IGMPv2 but SAT>IP servers do not have to understand IGMPv2 messages". So it's not unlikely that there are SAT>IP clients which also don't talk IGMPv2.

First, the "Unicast only profile" would be enough. Basically all SAT>IP client I currently know, all use RTSP/RTP for accesing the DVB frontends.
So I would like to leave out the IGMP things for now.

Some files need to be served by the streamdev HTTP server (e.g. XML device description and icons). Serving files from a directory has been on my list for a while to get icons and an external CSS file for the HTML menu. But as more and more different contents are added to the HTTP server, I think it's time to introduce some sort of URL handler interface and move code from cConnectionHTTP::ProcessURI/ProcessRequest/*FromString to subclasses of this interface.

In my approach, this would be part of the external process which handles discovery and also serving the XML file for SAT>IP clients.

Fortunately, the SAT>IP clients also offer the option to manually specify the SAT>IP server IP address.

So at the moment, implementing RTSP/RTP in the first phase would be enough to get things going.

Forgot one thing concerning the VDR channel thing I have mentioned.

What I mean is, do we not some mapping of the RTSP SETUP URI parameters (freq=...&msys=dvbs2&pids=...) to VDR channels?
Or is it possible to just make VDR tune the DVB frontend with that URI parameters and get the wanted PIDS?

However, VDR seems to act on channels only. So would it be possible for streamdev to get all the PIDs of tuned transponder's TS from VDR?
Think of a SAT>IP client which is clever and requests two channels (one for live TV, one for recording) within the same RTSP/RTP session.

Unfortunately there's no full TS transfer in VDR. VDR uses the DVB API demux device to access only those PIDs it currently needs. The program related PIDs (audio, video, ...) are selected using the DVB API PES filter, PIDs with section data are delivered separately using the DVB API section filter.

If you look at streamdev VTP, there are ususally three connections. There's the control connection for the commands. Then there's the connection for the actual program (livestreamer). The ADDP/DELP commands add and delete PIDs on this connection which delivers the data from the PES filter on the DVB device. It is possible for the client to receive multiple channels on the same transponder (e.g. live TV plus recording) by adding the required PIDs. And then there's an other connection for section data (livefilter). The ADDF/DELF commands are used to add PIDs to the section filter on the DVB device. So streamdev VTP actually extends the DVB PES filter and the DVB section filter over the network. VDR gives no direct access to the frontend, so no way to extend the frontend over the network.

Now let's take a look at streamdev HTTP. The typical TS client expects a complete TS stream (program plus section data), which is not available from VDR. Streamdev uses the PatFilter to receive section data, filter out section data refering to other channels on the transponder and request all PIDs for this channel from the PES filter. The data from the PES and from the section filter is then merged into a single TS stream.

If you have a smart RTSP client which only requests the PIDs it actually needs, VTP ADDP/DELP commands are your friend.
To get all PIDs, a simple solution would be to loop through VDRs channel list and collect all PIDs of all channels on the requested transponder. But as you have to insert section data, too, you will need to parse PAT and PMT (see PatFilter) and so you can get the required PIDs from there.
Note that PatFilter generates a new "single channel" PAT. This would probably not be necessary for RTSP clients.

So at the moment, implementing RTSP/RTP in the first phase would be enough to get things going.

Great.

What I mean is, do we not some mapping of the RTSP SETUP URI parameters (freq=...&msys=dvbs2&pids=...) to VDR channels?
Or is it possible to just make VDR tune the DVB frontend with that URI parameters and get the wanted PIDS?

There's no direct access to the DVB frontend for VDR plugins, so you will have to use the information from the parameters to find the corresponding VDR channel.

That's a pity but I fully understand. Thanks for your efforts.