[buers]

 

Tested 2 HD channels each ~30 sec: Stream and audio ok!

Tested 2 SD channels each ~30 sec: Stream and audio ok!
  

Just one note. I know, that it will get tedious. My tests let me recommend, to wait for 3 minutes. I have seen several scenarios, where the MagentaTV SSM streams failed after 2 Minutes 10 seconds (surprisingly this could be reproduced to the second).

[buers]

So far I have/found no UDP source. If you have a legal source for sure I will test it. ;-)

Is it possible to do it on my own by using ffmepg as a source? 

Sorry, I don't know an easy source either. I didn't think of UDP only. Actually I thought also of TCP. To me the errors in the log arej't necessarily dependent on UDP/TCP but might be caused by the pure mpegts (hwaccel) decoder. So, if you have tvheadend running and accessing it from Kodi with the same channel, this might be a test. (It should Transfer the same mpegts data by TCP, which then should be decoded by the same h264 hwaccel in ffmpeg. At least, that was my idea).

Enigma2 streamed channels might be another idea, if you have access. 

Perhaps, my idea is too complicated. You have tried to use a ffmpeg produced ts in Kodi, and that worked already. However, IIRC, you only tested HD there. 

But please stop me, @phunkyfish, if this won't make any sense. Will "normal" TCP provided mpegts in Kodi also be handled by ffmpeg?

[phunkyfish]

I tend to agree. But I know, that sometimes it is very easy to hit undefined situations (I would avoid it here). Certainly, I don't want to discuss that in detail. What explaination do you have for the spurious additional slash in the log of @Newbie268? "udp://@232.0.10.35:10000/?sources=87.141.215.251". There must be a logical explanation for basic string processing.

It's not spurious, it's in the original URL.

[phunkyfish]

So far I have/found no UDP source. If you have a legal source for sure I will test it. ;-)

Is it possible to do it on my own by using ffmepg as a source?  

Sorry, I don't know an easy source either. I didn't think of UDP only. Actually I thought also of TCP. To me the errors in the log arej't necessarily dependent on UDP/TCP but might be caused by the pure mpegts (hwaccel) decoder. So, if you have tvheadend running and accessing it from Kodi with the same channel, this might be a test. (It should Transfer the same mpegts data by TCP, which then should be decoded by the same h264 hwaccel in ffmpeg. At least, that was my idea).

Enigma2 streamed channels might be another idea, if you have access. 

Perhaps, my idea is too complicated. You have tried to use a ffmpeg produced ts in Kodi, and that worked already. However, IIRC, you only tested HD there. 

But please stop me, @phunkyfish, if this won't make any sense. Will "normal" TCP provided mpegts in Kodi also be handled by ffmpeg? 

Everything is handled by ffmpeg.

[buers]

 

 

Just streamed in parallel in VLC--> No artefacts in VLC--> Seems not caused by the stream itself!
 

Good to have a confirmation for this. The same here - the streams are very reliable (according to VLC and to my test program). So we can rely on your results.

There is still a risk and a difference to VLC. From my Analysis of VLC source code, it really does understand the rtp protocol in combination with SSM. Ffmpeg Fails here. So we lie to ffmpeg, and tell it to assume UDP. Then ffmpeg is expecting "pure" mpegts. But the stream is rtp. The difference is (simplifying here): rtp has an additional 12 Bytes as Header. For MagentaTV, then 7 times a 188 Bytes Long ts will follow. So, Decoding from the start of the data must produce some garbage. TS can be detected by the first Byte, that has to be 0x47. Certainly, any Decoder will search for this marker, and skip garbage before the marker. However, the marker can, by coincidence, also be inside the rtp Header. I.e. inside the sequence number field or the timestamp. So a primitive garbage detection, that searches for the first 0x47 can fail with some small probability. Stuff like this will yield in typical "green Errors" and other block artifacts. A smarter garbage detector will look at 0x47 and test for 0x47 another 188 Bytes later. If not both match, the start of mpegts not found yet. Then, even with the wron protocol (pure UDP instead of rtp on UDP), basically no Errors will arise.

(Sorry, my English spelling might be bad enough already. When I type words inside the Forum Software here, random words are capitalized. I resign, correcting that).

[Newbie268]

So far I have/found no UDP source. If you have a legal source for sure I will test it. ;-)

Is it possible to do it on my own by using ffmepg as a source?  

Sorry, I don't know an easy source either. I didn't think of UDP only. Actually I thought also of TCP. To me the errors in the log arej't necessarily dependent on UDP/TCP but might be caused by the pure mpegts (hwaccel) decoder. So, if you have tvheadend running and accessing it from Kodi with the same channel, this might be a test. (It should Transfer the same mpegts data by TCP, which then should be decoded by the same h264 hwaccel in ffmpeg. At least, that was my idea).

Enigma2 streamed channels might be another idea, if you have access. 

Perhaps, my idea is too complicated. You have tried to use a ffmpeg produced ts in Kodi, and that worked already. However, IIRC, you only tested HD there. 

But please stop me, @phunkyfish, if this won't make any sense. Will "normal" TCP provided mpegts in Kodi also be handled by ffmpeg? 

So, I will test with TCP this evening with a stream of THV!

[Newbie268]

Is it possible to do it on my own by using ffmepg as a source?  

Sorry, I don't know an easy source either. I didn't think of UDP only. Actually I thought also of TCP. To me the errors in the log arej't necessarily dependent on UDP/TCP but might be caused by the pure mpegts (hwaccel) decoder. So, if you have tvheadend running and accessing it from Kodi with the same channel, this might be a test. (It should Transfer the same mpegts data by TCP, which then should be decoded by the same h264 hwaccel in ffmpeg. At least, that was my idea).

Enigma2 streamed channels might be another idea, if you have access. 

Perhaps, my idea is too complicated. You have tried to use a ffmpeg produced ts in Kodi, and that worked already. However, IIRC, you only tested HD there. 

But please stop me, @phunkyfish, if this won't make any sense. Will "normal" TCP provided mpegts in Kodi also be handled by ffmpeg?  

Everything is handled by ffmpeg. 

@phunkyfish 
Can you compile the last version for android? If so I will test this evening on FireTV-Stick!

In addition I will test LibreELEC.tv Matrix build #0128. Contains it already your last code?

[Newbie268]

Sorry, I don't know an easy source either. I didn't think of UDP only. Actually I thought also of TCP. To me the errors in the log arej't necessarily dependent on UDP/TCP but might be caused by the pure mpegts (hwaccel) decoder. So, if you have tvheadend running and accessing it from Kodi with the same channel, this might be a test. (It should Transfer the same mpegts data by TCP, which then should be decoded by the same h264 hwaccel in ffmpeg. At least, that was my idea).

Enigma2 streamed channels might be another idea, if you have access. 

Perhaps, my idea is too complicated. You have tried to use a ffmpeg produced ts in Kodi, and that worked already. However, IIRC, you only tested HD there. 

But please stop me, @phunkyfish, if this won't make any sense. Will "normal" TCP provided mpegts in Kodi also be handled by ffmpeg?  

Everything is handled by ffmpeg.  

@phunkyfish 
Can you compile the last version for android? If so I will test this evening on FireTV-Stick!

In addition I will test LibreELEC.tv Matrix build #0128. Contains it already your last code? 

I just want to test the LibreElec Version. During installation I recognized that the installation stopped due to the incompatibility of this build with RBPI4. That means all the tests done so far and reported by me for LibreElec had been done on the official stable release (Kodi 18.5 (Linux Kernel 4.19.x)
LibreELEC-RPi4.arm-9.2.0.img.gz) and not with the testbuilds. Im really sorry for this inconvenience!

[buers]

I compiled this on Linux, Linux buers-MS-7B98 5.3.0-26-generic #28~18.04.1-Ubuntu SMP Wed Dec 18 16:40:14 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux. First time, I compiled kodi, so obviously experience is missing.
1. As we have seen by serveral messages here, streams are working, when you stream them on other devices inside the same network (i.e. VLC, enigma2 receiver, Telekom MagentaTV receiver, ...)
2. Somewhere a slash gets appended to the URL. From the log: CPlayerCoreFactory::GetPlayers(rtp://[email protected]:10000/). I did not investigate the source of the slash yet, but it won't be liked by ffmpeg
3. CDVDDemuxFFmpeg::Open(), where you have added most of your changes, which we are discussing here, really would need a parser for rtp://source_ip@host_ip. But during this phase, simple string operations are of course ok. I already said, that I am no C++ expert. Nevertheless, I believe that this snippet should improve things:

Code:

else if (url.IsProtocol("udp") || url.IsProtocol("rtp"))
{
std::string strURL = url.Get();
CLog::Log(LOGDEBUG,
"CDVDDemuxFFmpeg::Open() UDP/RTP Original URL '%s'",
strURL.c_str());
size_t found = strURL.find("://");
if (found != std::string::npos)
{
size_t start = found + 3;
size_t pat = strURL.find("@");
CLog::Log(LOGDEBUG,
"CDVDDemuxFFmpeg::Open() start %u pat %u",
(unsigned)start, (unsigned)pat);
if (pat != std::string::npos && pat > start)
{
// sourceip found
std::string strSourceIp = strURL.substr(start, pat - start);
strFile = strURL.substr(0, start);
strFile += strURL.substr(pat);
size_t l = strFile.length();
if (l > 0 && strFile[l-1] == '/')
// strFile[l-1] = '\0';
strFile.pop_back();
/* if (strFile.back() == '/')
strFile.back() = 0; */
strFile += "?sources=";
strFile += strSourceIp;
// only use udp as there is bug in rtp in ffmpeg
strFile[0] = 'u';
strFile[1] = 'd';
CLog::Log(LOGDEBUG,
"CDVDDemuxFFmpeg::Open() UDP/RTP URL '%s'",
strFile.c_str());
}
}

I assume, that all the formatting will be lost, but you will see, what I mean, @phunkyfish. I got rid of the overloaded found, and checked for trailing slash, if there, delete it. Sure, this is not production quality.
Then, from the log, it looks ok for me from point of view of the transcription of the URL. Unfortunately, I now get an error inside ffmpeg: "ERROR: ffmpeg[0x55be3de45b60X]: setsockopt(MCAST_JOIN_SOURCE_GROUP): Cannot assign requested address". I have to investigate further from here. My test program, that is able to record the SSM streams, is using exactly this call to setsockopt witt MCAST_JOIN_SOURCE_GROUP. I don't understand this yet. After all, @Newbie268 reported, that the same channel I used for testing, was working. So, quite possible, that I have f***d up something.

Just wanted to share with you the findings, in the hope, that they can be helpful in further analysis.

[buers]

I tend to agree. But I know, that sometimes it is very easy to hit undefined situations (I would avoid it here). Certainly, I don't want to discuss that in detail. What explaination do you have for the spurious additional slash in the log of @Newbie268? "udp://@232.0.10.35:10000/?sources=87.141.215.251". There must be a logical explanation for basic string processing.

It's not spurious, it's in the original URL. 

Well, I tried.m3u file for PVR IPTV simple client, with URLs that did not end in "/". So certainly the slash was not inside the original UR from the .m3u, that PVR IPTV simple client is using.

[phunkyfish]

Maybe it comes from the URL class. I had fixed the slash and redeclaration but never pushed it to the PR, apologies. It's there now and should match the intent of your code.

I've also added the code to the new inputstream addon, it's called inputstream.ffmpegdirect. Only difference is it does not rename the protocol to udp, it assumes ffmpeg will do the right thing.

If you install v1.4.0 from when it's released over the next day or so you just need to add a KODIPROP above the M3U entry like this:

Code:

#KODIPROP:inputstreamclass=inputstream.ffmpegdirect

This will then run on the latest release of ffmpeg. This should allow you to test both RTP on latest ffmpeg in kodi. If you want to test udp you will need to manually modify the URL in the M3U file.

I'll post links to the Android and Windows testbuilds once ready.

[phunkyfish]

Latest Windows testbuild: https://mirrors.kodi.tv/test-builds/wind...ix-x64.exe
Android ARM: https://jenkins.kodi.tv/job/Android-ARM/...bi-v7a.apk
Android ARM64: https://jenkins.kodi.tv/job/Android-ARM6...64-v8a.apk

[Newbie268]

Maybe it comes from the URL class. I had fixed the slash and redeclaration but never pushed it to the PR, apologies. It's there now and should match the intent of your code.

I've also added the code to the new inputstream addon, it's called inputstream.ffmpegdirect. Only difference is it does not rename the protocol to udp, it assumes ffmpeg will do the right thing.

If you install v1.4.0 from when it's released over the next day or so you just need to add a KODIPROP above the M3U entry like this:

Code:

#KODIPROP:inputstreamclass=inputstream.ffmpegdirect

This will then run on the latest release of ffmpeg. This should allow you to test both RTP on latest ffmpeg in kodi. If you want to test udp you will need to manually modify the URL in the M3U file.

I'll post links to the Android and Windows testbuilds once ready.

Thats sounds interesting! Will inputstream.ffmpegdirect contain ffmpeg and released in a new version if a newer release of ffmpeg is done or is it transferring to an additional installed ffmpeg?
Sounds for me as a good alternative instead of having the need for a new kodi version if there is the wish/need to have a newer ffmpeg code embedded!

I suppose the instruction

Code:

#KODIPROP:inputstreamclass=inputstream.ffmpegdirect

has to be added then before each entry in the m3u or has it been written only once at the beginning?

E.g.

#EXTM3U
#KODIPROP:inputstreamclass=inputstream.ffmpegdirect
#EXTINF:-1,(2) ZDF SD
rtp://[email protected]:10000
#KODIPROP:inputstreamclass=inputstream.ffmpegdirect
#EXTINF:-1,(3) RTL SD
rtp://[email protected]:10000
#KODIPROP:inputstreamclass=inputstream.ffmpegdirect
#EXTINF:-1,(4) SAT.1 SD
rtp://[email protected]:10000

[Newbie268]

Latest Windows testbuild: https://mirrors.kodi.tv/test-builds/wind...ix-x64.exe
Android ARM: https://jenkins.kodi.tv/job/Android-ARM/...bi-v7a.apk
Android ARM64: https://jenkins.kodi.tv/job/Android-ARM6...64-v8a.apk

Thanks for the new builds. Will test and report this evening.

[phunkyfish]

 

Thats sounds interesting! Will inputstream.ffmpegdirect contain ffmpeg and released in a new version if a newer release of ffmpeg is done or is it transferring to an additional installed ffmpeg?
Sounds for me as a good alternative instead of having the need for a new kodi version if there is the wish/need to have a newer ffmpeg code embedded!

I suppose the instruction

Code:

#KODIPROP:inputstreamclass=inputstream.ffmpegdirect

has to be added then before each entry in the m3u or has it been written only once at the beginning?

E.g.

#EXTM3U
#KODIPROP:inputstreamclass=inputstream.ffmpegdirect
#EXTINF:-1,(2) ZDF SD
rtp://[email protected]:10000
#KODIPROP:inputstreamclass=inputstream.ffmpegdirect
#EXTINF:-1,(3) RTL SD
rtp://[email protected]:10000
#KODIPROP:inputstreamclass=inputstream.ffmpegdirect
#EXTINF:-1,(4) SAT.1 SD
rtp://[email protected]:10000 

That's correct the way you have added it to the file.

The reason for the addon was to allow support of catchup streams (so where your provider lets you watch the last X days) as to add this to kodi-core would have been very hacky. It won't support all stream types, only those handled by ffmpeg directly (like m3u8, unencrypted DASH, rtp, udp etc.).