[phunkyfish]

That’s great. I will submit this patch to ffmpeg in the coming days but I think this patch is safe to leave included in the inputstream addon in the meantime.

It can take while to get things add to ffmpeg!

[buers]

Good to hear all this. Also from my side thanks to @phunkyfish and to @Newbie268 !

@phunkyfish, don't you have any intention to also add it to Kodi without inputstream.ffmpegdirect? I think, this can have some small advantages, i.e. being able to use the identical .m3u file with VLC and with tvheadend. 

When you submit the patch - not sure if this is the right audience, but maybe you can motivate them, that Windows binaries should be compiled with pthreads, or that the missing functionality being added to native Windows threads code.  (Perhaps I will also have a look at this: what is really missing there? - doesn't sound, as it should be some principal problem)

[phunkyfish]

I would like to add the patch to kodi as well as submit the patch upstream to ffmpeg.

Once it's in a nightly build I would like to see if pthreads is needed or not first. I don't think anyone is against pthreads in kodi but do need a good reason to add them

The next questions is dependent on the actual fix upstream. It should work via extending the URL or via an AVDictionary passed to avformat_open_input(). The cleaner implementation in kodi is to use the AVDictionary, but the current patch doesn't support that.

[buers]

Ok, thanks. In the end, ffmpeg devs should know best. I used quite a couple of hours, to understand, what went wrong in the ffmpeg code. The identical patch will fix it for kodi (and probably other libav... users) and for ffmpeg-commandline-tools. Quite down in the ffmpeg call chain, at function rtp_open(), the sources=ip URL is the supported method inside the ffmeg code, and later in the udp code. However, I will also try to have another look, see next paragraph. It should be inside kodi, not inside ffmpeg, though.

There might be another issue left. @Newbie268, in one of your logs, I had detected a line, that had reopened "rtp://source_ip @ip", while it should have used "rtp://@ip?sources=source_ip" (or udp instead of rtp, depending in what testing phase we were). Do you know, which logfile this was? Not sure, how resilient the code in general is, i.e. to temporary net interruptions. With the upd-based rtp protocol, it in general could be rather resilient (of course loosing frames, than, or expecting temporary artefacts). Plugging out the LAN cable for a second might trigger that message? (Not, that I would expect, that kodi/ffmpeg will automatically play fine with this).

It could also be the case, that it is a non-issue now. After all, before the patch, in rtp, SSM was not joined correctly, now it is. (In udp, it was joined correctly all the time).

[Newbie268]

Ok, thanks. In the end, ffmpeg devs should know best. I used quite a couple of hours, to understand, what went wrong in the ffmpeg code. The identical patch will fix it for kodi (and probably other libav... users) and for ffmpeg-commandline-tools. Quite down in the ffmpeg call chain, at function rtp_open(), the sources=ip URL is the supported method inside the ffmeg code, and later in the udp code. However, I will also try to have another look, see next paragraph. It should be inside kodi, not inside ffmpeg, though.

There might be another issue left. @Newbie268, in one of your logs, I had detected a line, that had reopened "rtp://source_ip @ip", while it should have used "rtp://@ip?sources=source_ip" (or udp instead of rtp, depending in what testing phase we were). Do you know, which logfile this was? Not sure, how resilient the code in general is, i.e. to temporary net interruptions. With the upd-based rtp protocol, it in general could be rather resilient (of course loosing frames, than, or expecting temporary artefacts). Plugging out the LAN cable for a second might trigger that message? (Not, that I would expect, that kodi/ffmpeg will automatically play fine with this).

It could also be the case, that it is a non-issue now. After all, before the patch, in rtp, SSM was not joined correctly, now it is. (In udp, it was joined correctly all the time).

I am not sure which file it was:

Maybe the 3rd one in Post 135:

cpp:


1114 2020-02-03 19:30:24.876 T:15052 DEBUG: AddOnLog: Inputstream FFmpeg Direct: CDVDDemuxFFmpeg::Open() UDP/RTP Original URL 'udp://[email protected]:10000/'

1115 2020-02-03 19:30:24.876 T:15052 DEBUG: AddOnLog: Inputstream FFmpeg Direct: CDVDDemuxFFmpeg::Open() UDP/RTP URL 'udp://@232.0.20.35:10000?sources=87.141.215.251'

1116 2020-02-03 19:30:24.876 T:15052 DEBUG: AddOnLog: Inputstream FFmpeg Direct: ffmpeg[0000000000000000X]: [NULL] Opening 'udp://[email protected]:10000' for reading

Logfile

It was there only for UDP testing and not in the first one with rtp!

(unlikely
#111 / #118

[phunkyfish]

It was from post 180:

INFO: AddOnLog: Inputstream FFmpeg Direct: ffmpeg[0000000000000000X]: Input #0, rtp, from 'rtp://[email protected]:10000/':

Somehow ffmpeg gets the other address format. Which must mean it’s returned as part of the rtp/rtcp protocol.

[buers]

Thanks. I meant https://paste.ubuntu.com/p/5dtTVTNTdj/ from post #107. 


line 3807:
2020-01-30 18:08:34.949 T:28568   DEBUG: CDVDDemuxFFmpeg::Open - av_find_stream_info finished
2020-01-30 18:08:34.949 T:28568    INFO: ffmpeg[0x208c3d7f0a0X]: Input #0, mpegts, from 'udp://@232.0.10.234:10000/':

line 8376:
2020-01-30 18:10:25.564 T:28568  NOTICE: CDVDDemuxFFmpeg::Read() stream change
2020-01-30 18:10:25.564 T:28568    INFO: ffmpeg[0x208c3d7f0a0X]: Input #0, mpegts, from 'rtp://[email protected]:10000/':

How could this URL reappear? I will look at the other logs as well. I am not sure, how much time I will find. Other appearances of the bold form, I can somewhat understand. In kodi, even with the patch, there will be the original string from the m3u. But when you are somewhere deep inside ffmpeg, like in line 8377, all the calls should have been "piped" through the patch, that transforms to the ?sources= format. It was obviously not the case in that log. So there seems to be another way to reach ffmpeg (Maybe after an error, then restartin a stream with some "call abbrevation"). This was a time, when the patch changed rtp to udp. So from phunkyfish's reasoning: "Which must mean it’s returned as part of the rtp/rtcp protocol." - I would doubt it. Sure, there are other conditions in the log of #180. To me, this looks like a kodi internal string, with that slash at the end (that we have stripped away in the patch again). You might remember my not very C++-ish string handling for that, that you transfered to proper C++.

The logfile of #180 Looks password protected to me?

EDIT: "Which must mean it’s returned as part of the rtp/rtcp protocol." Sorry. Maybe my conclusion was too fast. Still the comparision with the udp-trick-patch should be valid. Do you think, that there is some automatism, that detects rtp inside udp for udp:// inside ffmpeg? I can hardly believe that. I had studied the rtp protocol, and to my knowledge, it does not report that URL-Details. (The rtp Header is only 12 Bytes Long, contails sequence number, time stamp, Format Information).

[phunkyfish]

I really don’t know. I have submitted the patch, hopefully correctly.

Let’s see what the ffmpeg guys say in a few days.

[Newbie268]

Thanks. I meant https://paste.ubuntu.com/p/5dtTVTNTdj/ from post #107. 


line 3807:
2020-01-30 18:08:34.949 T:28568   DEBUG: CDVDDemuxFFmpeg::Open - av_find_stream_info finished
2020-01-30 18:08:34.949 T:28568    INFO: ffmpeg[0x208c3d7f0a0X]: Input #0, mpegts, from 'udp://@232.0.10.234:10000/':

line 8376:
2020-01-30 18:10:25.564 T:28568  NOTICE: CDVDDemuxFFmpeg::Read() stream change
2020-01-30 18:10:25.564 T:28568    INFO: ffmpeg[0x208c3d7f0a0X]: Input #0, mpegts, from 'rtp://[email protected]:10000/':

How could this URL reappear? I will look at the other logs as well. I am not sure, how much time I will find. Other appearances of the bold form, I can somewhat understand. In kodi, even with the patch, there will be the original string from the m3u. But when you are somewhere deep inside ffmpeg, like in line 8377, all the calls should have been "piped" through the patch, that transforms to the ?sources= format. It was obviously not the case in that log. So there seems to be another way to reach ffmpeg (Maybe after an error, then restartin a stream with some "call abbrevation"). This was a time, when the patch changed rtp to udp. So from phunkyfish's reasoning: "Which must mean it’s returned as part of the rtp/rtcp protocol." - I would doubt it. Sure, there are other conditions in the log of #180. To me, this looks like a kodi internal string, with that slash at the end (that we have stripped away in the patch again). You might remember my not very C++-ish string handling for that, that you transfered to proper C++.

The logfile of #180 Looks password protected to me?

EDIT: "Which must mean it’s returned as part of the rtp/rtcp protocol." Sorry. Maybe my conclusion was too fast. Still the comparision with the udp-trick-patch should be valid. Do you think, that there is some automatism, that detects rtp inside udp for udp:// inside ffmpeg? I can hardly believe that. I had studied the rtp protocol, and to my knowledge, it does not report that URL-Details. (The rtp Header is only 12 Bytes Long, contails sequence number, time stamp, Format Information).

@buers 
The logfile of post #180 shouldn't be password protected. Just tested, the option was not chosen.

[phunkyfish]

@Newbie268 can you test this build: https://mirrors.kodi.tv/test-builds/wind...te-x64.exe

This is kodi with only the ffmpeg new version and patch. This mean you'll need to change the rtp URL to the ffmpeg format to test, i.e. rtp://@232.0.10.234:10000?sources=87.141.215.251. This test should not use ffmpegdirect.

Thanks in advance.

[Newbie268]

@Newbie268 can you test this build: https://mirrors.kodi.tv/test-builds/wind...te-x64.exe

This is kodi with only the ffmpeg new version and patch. This mean you'll need to change the rtp URL to the ffmpeg format to test, i.e. rtp://@232.0.10.234:10000?sources=87.141.215.251. This test should not use ffmpegdirect.

Thanks in advance.

Will test this evening!

[buers]

The logfile of #180 Looks password protected to me?
 

@buers 
The logfile of post #180 shouldn't be password protected. Just tested, the option was not chosen. 

When I click on the logfile of that post, this URL will be opend: https://privatebin.net/?e7a9fad25af4777b...KBMh5k1NXw and I see the following screen: 
(Not sure, if this will display correctly here - I never used an image for this forum before).

Is there anything wrong on my side? I did not take a look at all logfiles linked inside this tread. However, all other logfiles, I tried to look at, displayed as I would have expected.

[Newbie268]

The logfile of #180 Looks password protected to me?
 

@buers 
The logfile of post #180 shouldn't be password protected. Just tested, the option was not chosen.  

When I click on the logfile of that post, this URL will be opend: https://privatebin.net/?e7a9fad25af4777b...KBMh5k1NXw and I see the following screen: 
(Not sure, if this will display correctly here - I never used an image for this forum before).

Is there anything wrong on my side? I did not take a look at all logfiles linked inside this tread. However, all other logfiles, I tried to look at, displayed as I would have expected. 

Strange? Should work w/o password!

@phunkyfish : Do you have the same problem, too?

I changed between all the logs the paste sites 2 times! I've done that because on the first ones used the max. size was too limited for the last logs!

Find same log here again!

Set the password here to: 0000

[buers]

Thanks. It doesn't work for me :-( Message:

Konnte Daten nicht entschlüsseln. Hast Du das falsche Passwort eingegeben? Wiederhole den Vorgang mit dem oben stehenden Knopf.

(It is a zero, not a captilal Oh, I assume . I will try later with another computer).

[Newbie268]

Thanks. It doesn't work for me :-( Message:

Konnte Daten nicht entschlüsseln. Hast Du das falsche Passwort eingegeben? Wiederhole den Vorgang mit dem oben stehenden Knopf.

(It is a zero, not a captilal Oh, I assume . I will try later with another computer).

Just tested direct with my link. After put in 0000 I could access!

Yes it is zero!