search

Barracuda09 / SATPI

SATIP server for linux, suitable to run on an Raspberry Pi, Vu+, GigaBlue or any other linux box. currently supporting DVB-S/S2/T/C and transform DVB-S requests to DVB-C
http://barracuda09.github.io/SATPI
GNU General Public License v2.0
154 stars 32 forks source link

TSReader as Multicast/Unicast Input #47

Closed lars18th closed 5 years ago

lars18th commented 8 years ago

Hi @Barracuda09 ,

I see the implementation (not finished) about TSReader. I feel this is for reading FILES. However, I have a similar suggestion, very interesting for IPTV: Get TS from unicast/multicast.

This will be very similar to TSReader, but you only need to get the TS packets reading from a RTP/UDP port/address. For implementing the access, is only required to map a frequency (not relevant the MSYS used in the call) to an address.

You agree?

Barracuda09 commented 8 years ago

Hi,

Yes this is initially for reading files and to give an example how to interface an input device to an output. But indeed it sounds to me to an nice addition. I will look into this!

I'm now improving the OSCam dvbapi that it handles EMM as wel.

Thanks for you interest and suggestions,

Marc Op 15 mrt. 2016 23:23 schreef "lars18th" notifications@github.com het volgende:

Hi @Barracuda09 https://github.com/Barracuda09 ,

I see the implementation (not finished) about TSReader. I feel this is for reading FILES. However, I have a similar suggestion, very interesting for IPTV: Get TS from unicast/multicast.

This will be very similar to TSReader, but you only need to get the TS packets reading from a RTP/UDP port/address. For implementing the access, is only required to map a frequency (not relevant the MSYS used in the call) to an address.

You agree?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/Barracuda09/SATPI/issues/47

lars18th commented 8 years ago

Hi @Barracuda09 ,

If you agree on support this, perhaps I can help doing some testing and implementation. If you provide a simple skeleton for reading from one unicast UDP address, then I can try to provide some code.

You like it? ;)

Barracuda09 commented 8 years ago

Yes I agree, I encourage you to do so (To help).

I have to think about a good skeleton for this, but try to look into this as well yourself.

But I like the help you are offering.

Regards,

Marc

lars18th commented 8 years ago

Hi,

Related to this idea, I see your last commit (https://github.com/Barracuda09/SATPI/commit/14babea315051661dad5daa5e3b53226af8108c9) I feel it very useful as a skeleton changing FILE by STREAM.

Please, can you include some "fixed" (aka. hardcoded) support of a STREAM InputSytem (instead of "input::InputSystem::FILE", adding also one "input::InputSystem::STREAM")?

At time, you can use some #define at some point with the input address and check it with a simple RTP streamer (like VLC, for example). After that we can start to implement the rest of the code.

You agree?

Barracuda09 commented 8 years ago

Hi,

Yes I will add the STREAM input in the near days, it should not be to much work.

Regards,

Marc

lars18th commented 8 years ago

Hi @Barracuda09 ,

Yes I will add the STREAM input in the near days, it should not be to much work.

If it can read a TS from a RTP (or UDP) stream it will be great! I'll wait for it. Regards!

pbriesch commented 8 years ago

Hi,

I'm looking forward to seeing this new feature.

How will the stream inputs be visible on a SAT>IP client? Will you come up with a fake Satellite and/or a fake channel for each stream input? Would it be possible as well to provide e.g. a path to a directory with recordings or video files to SATPI an each file will show up as a fake channel? Regards, Paul

lars18th commented 8 years ago

Hi @pbriesch ,

Would it be possible as well to provide e.g. a path to a directory with recordings or video files to SATPI an each file will show up as a fake channel?

This is, more or less, the "input::InputSystem::FILE" already (partially) implemented by @Barracuda09 .

How will the stream inputs be visible on a SAT>IP client? Will you come up with a fake Satellite and/or a fake channel for each stream input?

The objective to achieve is the same already implemented in the TVHeadend: use a fake satellite/terrestrial/cable AND frequency (Hz) to select a Network Stream (multicast) as input. So the "input::InputSystem::STREAM" will maps a Freq. to Network IP Address. In the client side this will be transparent as the TS from the network will be a valid DVB TS.

Peaul, perhaps you like to implement this on your current sat-ip-proxy project! :) http://github.com/alexte/sat-ip-proxy

pbriesch commented 8 years ago

Thanks for the head up! Sounds great!

Am 29.03.2016 um 13:59 schrieb lars18th notifications@github.com:

Hi @pbriesch ,

Would it be possible as well to provide e.g. a path to a directory with recordings or video files to SATPI an each file will show up as a fake channel?

This is, more or less, the "input::InputSystem::FILE" already (partially) implemented by @Barracuda09 .

How will the stream inputs be visible on a SAT>IP client? Will you come up with a fake Satellite and/or a fake channel for each stream input?

The objective to achieve is the same already implemented in the TVHeadend: use a fake satellite/terrestrial/cable AND frequency (Hz) to select a Network Stream (multicast) as input. So the "input::InputSystem::STREAM" will maps a Freq. to Network IP Address. In the client side this will be transparent as the TS from the network will be a valid DVB TS.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

lars18th commented 8 years ago

Hi @Barracuda09 ,

We can start this soon? I like to implement this, but I need some info or one skeleton. Any comment to help?

Regards!

Barracuda09 commented 8 years ago

Hi,

I did not had that much time to look into this yet. But first of all I did some code cleanups and improvements. I did add an Streamer frontend, now we have to open an unicast UDP address.

Thanks for you interest!

lars18th commented 8 years ago

Hi @Barracuda09 ,

Thank you! I'll try your last commit and I'll comment it after.

lars18th commented 8 years ago

Hi @Barracuda09 ,

The call for the Streamer will be in the form of this?

http://ip.of.your.box:8875:/?msys=stream&uri=udp://0.0.0.0:1234
http://ip.of.your.box:8875:/?msys=stream&uri=rtp://224.0.0.1:1234

It's this is correct? "udp" or "rtp" for selecting the protocol, and "ip:port" for listening unicast address or multicast incoming address. Right?

Barracuda09 commented 8 years ago

Hi,

Yes it should become something like that.

Barracuda09 commented 8 years ago

Hi,

I forgot something, I added with the last commit the InputSystem. It is now something like this:

http://ip.of.your.box:8875:/?msys=streamer&uri=rtp://224.0.0.1:1234

lars18th commented 8 years ago

Hi @Barracuda09 ,

Thank you! I'll try. Now, I assume that at this point this is only a skeleton, right? So no funtional reading from a socket. Then, the first objective is work with a simple raw UDP reception, like:

http://ip.of.your.box:8875:/?msys=streamer&uri=udp://0.0.0.0:1234

And sending the TS over the network using, for example, VLC.

Barracuda09 commented 8 years ago

Hi @lars18th

Yes you are correct, I did not had the time to look into this yet myself.

Maybe you can look into the SSDP Server for opening an UDP socket.

Thanks for trying and regards,

Marc

lars18th commented 8 years ago

Hi @Barracuda09 ,

Please, can you add some raw udp reception in the skeleton? I feel this will be a very interesting functionality.

Thank you!

Barracuda09 commented 8 years ago

Hi lars18th,

Thanks for your interest, I see what I can do with this.

lars18th commented 5 years ago

I close it as it's already implemented.