MERGING MediaPortal Url Source Splitter & IPTV Filter (3 Viewers)

[Lyfesaver74]

@FreakyJ Okay, finally getting back to my server. Will be testing this in the next few days to come. What was the other thing you pointed me to in another thread? Damn alerts do not archive. You get a day or two at the most.

 

[FreakyJ]

Sorry I can't remember what the other thing was, but I definitely remember this
Thank you very much for your help

 

[Lyfesaver74]

@FreakyJ It was the thread where I said I was working on it last weekend... grrrrrrr......

 

[Syrel]

Hi,

I'm struggling to setup some RTSP streaming TV channels. With the original filter that came with MP1.6 I got crash right after the 1st channel scan. With this new filter the scan completes, however no channels are found. I've read through this thread, and followed all guides to debug what's going on. This is what I did so far:

1. Set up router to open/forward all UDP ports to the client (for simplicity sake)
2. Disabled Windows firewall
3. Verified that the stream is indeed working, using VLC and MPC-HC.
   
4. Used Wireshark to check what's going on. RTSP OPTION and DESCRIBE are working fine, but after that, no data are coming in.
5. Checked the relevant MP logs, and found that apparently the stream opens, but the data format is not accepted by the filter.
6. I check this thread once more, and finally found the following note right in #1:

Note: From technical point of view are all protocols supported also in IPTV case. But IPTV needs that stream is in MPEG2 TS format. Filter doesn't have ability to transcode or to mux incoming stream to MPEG2 TS format (yet). This condition excludes MMS, RTMP, MSHS and AFHS protocols.

Now I checked the stream format in MPC-HC, and apparently it is H.264 MPEG4.

Now can someone pls. confirm, that indeed currently I will not be able to play this stream, because filter accepts MPEG2-coded streams only? Or is there something I might have overlooked? (I can upload all logs later on, I just did not want to attach them if my assumption above is correct.)
Thanks in advance!

 

[mm1352000]

Hello Syrel

I check this thread once more, and finally found the following note right in #1:

Note: From technical point of view are all protocols supported also in IPTV case. But IPTV needs that stream is in MPEG2 TS format. Filter doesn't have ability to transcode or to mux incoming stream to MPEG2 TS format (yet). This condition excludes MMS, RTMP, MSHS and AFHS protocols.

Now I checked the stream format in MPC-HC, and apparently it is H.264 MPEG4.

Now can someone pls. confirm, that indeed currently I will not be able to play this stream, because filter accepts MPEG2-coded streams only?

The filter accepts MPEG 2 transport streams. The video encoding can be MPEG 1, MPEG 2, or h.264 - any format that is DVB compliant. It sounds like your source is not a transport stream. If that is the case, you'll need to find a way to change the "container" if you want to get the stream working in MP.

mm

 

[georgius]

Hi,

I'm struggling to setup some RTSP streaming TV channels. With the original filter that came with MP1.6 I got crash right after the 1st channel scan. With this new filter the scan completes, however no channels are found. I've read through this thread, and followed all guides to debug what's going on. This is what I did so far:

1. Set up router to open/forward all UDP ports to the client (for simplicity sake)
2. Disabled Windows firewall
3. Verified that the stream is indeed working, using VLC and MPC-HC.
   
4. Used Wireshark to check what's going on. RTSP OPTION and DESCRIBE are working fine, but after that, no data are coming in.
5. Checked the relevant MP logs, and found that apparently the stream opens, but the data format is not accepted by the filter.
6. I check this thread once more, and finally found the following note right in #1:

Note: From technical point of view are all protocols supported also in IPTV case. But IPTV needs that stream is in MPEG2 TS format. Filter doesn't have ability to transcode or to mux incoming stream to MPEG2 TS format (yet). This condition excludes MMS, RTMP, MSHS and AFHS protocols.

Now I checked the stream format in MPC-HC, and apparently it is H.264 MPEG4.

Now can someone pls. confirm, that indeed currently I will not be able to play this stream, because filter accepts MPEG2-coded streams only? Or is there something I might have overlooked? (I can upload all logs later on, I just did not want to attach them if my assumption above is correct.)
Thanks in advance!

It will be great if you have logs, I'm curious what is in DESCRIBE response. Probably there is not MPEG2 Transport Stream, but something else.

 

[mm1352000]

@georgius

Question for you about RTSP and RTP...
For SAT>IP, I'm thinking to do the RTSP handling in the TV library. I think it would require too much custom handling for your filter, or would require a separate filter which I don't really want to do. Anyhow... the problem that I have is the SETUP request. In that request I have to pass the preferred client port details. For example:

Transport: RTP/AVP;unicast;client_port=52028-52029

Then I expect a response:

Transport: RTP/AVP;unicast;client_port=52028-52029;server_port=8000-8001

If we continue with the example...
My understanding is that the RTP/UDP stream can be received using the following URL:

udp://[local NIC IP address]:52028@[SAT>IP server IP address]:8000

Will your filter setup the receive port (52028)?
I hope it will...

mm

 

[georgius]

@georgius

Question for you about RTSP and RTP...
For SAT>IP, I'm thinking to do the RTSP handling in the TV library. I think it would require too much custom handling for your filter, or would require a separate filter which I don't really want to do. Anyhow... the problem that I have is the SETUP request. In that request I have to pass the preferred client port details. For example:

Transport: RTP/AVP;unicast;client_port=52028-52029

Then I expect a response:

Transport: RTP/AVP;unicast;client_port=52028-52029;server_port=8000-8001

If we continue with the example...
My understanding is that the RTP/UDP stream can be received using the following URL:

udp://[local NIC IP address]:52028@[SAT>IP server IP address]:8000

Will your filter setup the receive port (52028)?
I hope it will...

mm

I'm not sure, how it is implemented in Live555 (current MP 1.6 filter). If you're asking, how it is implemented in merged filter, then client ports are reserved before sending SETUP request and also you can pass client ports in "connection string" (I don't have better words for that, it's formatted URL, see first post).

 

[mm1352000]

I'm not sure, how it is implemented in Live555 (current MP 1.6 filter). If you're asking, how it is implemented in merged filter, then client ports are reserved before sending SETUP request and also you can pass client ports in "connection string" (I don't have better words for that, it's formatted URL, see first post).

I read the first post, but I'm sorry to say that it doesn't really help me.
My question is more about the UDP/RTP handling than RTSP. If I was to reserve the client port then surely it would not be possible for the filter to use it... so surely the filter has to set up the socket based on the URL?

 

[georgius]

I'm not sure, how it is implemented in Live555 (current MP 1.6 filter). If you're asking, how it is implemented in merged filter, then client ports are reserved before sending SETUP request and also you can pass client ports in "connection string" (I don't have better words for that, it's formatted URL, see first post).

I read the first post, but I'm sorry to say that it doesn't really help me.
My question is more about the UDP/RTP handling than RTSP. If I was to reserve the client port then surely it would not be possible for the filter to use it... so surely the filter has to set up the socket based on the URL?

Merged filter before sending SETUP request reserves pair of UDP ports (create sockets without SO_REUSEADDR option). If any of ports are used by someone else, it simply choose next pair of ports (by default, filter starts on port 50000 and goes up to 65535, but min and max ports can be configured in RTSP url). UDP ports are reserved without SO_REUSEADDR option on socket, so it's not able to access them.