[Newbie268]

Dou you mean h264 instead of x264? x264 is an encoder, isn't it?

@newbie264 mentioned it already. The stream, where Kodi crashed (from the log, it sounds more like a termination than like a crash), from the log - please note fps:

Code:

Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt470bg), 720x576 [SAR 64:45 DAR 16:9], [b]50 fps[/b], 50 tbr, 90k tbn, 50 Tbc

from commandline ffmpeg (which is correct for fps)

Code:

Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt470bg, top first), 720x576 [SAR 64:45 DAR 16:9], [b]25 fps,[/b] 50 tbr, 90k tbn, 50 tbc

W/o having any knowledge about video decoding i noticed in addition:

My Kodi stream LOG SD: [SAR 64:45 DAR 16:9]

In my ffmpeg LOG SD: [SAR 16:11 DAR 20:11]

ffmpeg LOG of @buers SD: [SAR 64:45 DAR 16:9]

But as it ran with different aspect ratio's in both ffmpeg versions this seems not to be the problem!

Can it be that due to the difference in FPS the failure of missing reference picture is the result (or vice versa)?

From HD working Build testlog

[h264 @ 000001e609baf840] reference picture missing during reorder
[h264 @ 000001e609baf840] Missing reference picture, default is 65763
[h264 @ 000001e609baf840] mmco: unref short failure
Last message repeated 1 times
[h264 @ 000001e609baf840] Increasing reorder buffer to 2
.
.
.
2020-01-25 19:46:17.909 T:2932 ERROR: ffmpeg[0x2775e6490e0X]: [h264] SPS unavailable in decode_picture_timing
2020-01-25 19:46:17.909 T:2932 ERROR: ffmpeg[0x2775e6490e0X]: [h264] non-existing PPS 0 referenced
2020-01-25 19:46:17.910 T:2932 ERROR: ffmpeg[0x2775e6490e0X]: [h264] SPS unavailable in decode_picture_timing
2020-01-25 19:46:17.910 T:2932 ERROR: ffmpeg[0x2775e6490e0X]: [h264] non-existing PPS 0 referenced
2020-01-25 19:46:17.910 T:2932 ERROR: ffmpeg[0x2775e6490e0X]: [h264] decode_slice_header error
2020-01-25 19:46:17.910 T:2932 ERROR: ffmpeg[0x2775e6490e0X]: [h264] no frame!

[phunkyfish]

Yes, apologies, h264. 

Ok, so you think an increase in analyze duration might help?

[Newbie268]

Yes, apologies, h264. 

Ok, so you think an increase in analyze duration might help?

Maybe?

[Newbie268]

The thing is you should use hwaccel for x264 I would think.

Maybe try this testbuild where I just pass the url exactly like the ffmpeg command as a URL: https://mirrors.kodi.tv/test-builds/wind...ix-x64.exe

If it works maybe we can see about fixing ffmpeg so it just works with rtp.

Will test this evening!

[Newbie268]

Yes, apologies, h264. 

Ok, so you think an increase in analyze duration might help?

Maybe? 

Sorry, your question was @buers

[Newbie268]

The thing is you should use hwaccel for x264 I would think.

Maybe try this testbuild where I just pass the url exactly like the ffmpeg command as a URL: https://mirrors.kodi.tv/test-builds/wind...ix-x64.exe

If it works maybe we can see about fixing ffmpeg so it just works with rtp.

Just tested Build cb68f4cf

Another step forward and a new behaviour:

Tested on 2 HD channels: Stream with no obvious failures!

Tested on 1 SD channel: Audio starts with failures, no/or freeze frame (no movie), Mouse does not react anymore, Kodi has to be terminated with taskmanager

See log here

[Newbie268]

The thing is you should use hwaccel for x264 I would think.

Maybe try this testbuild where I just pass the url exactly like the ffmpeg command as a URL: https://mirrors.kodi.tv/test-builds/wind...ix-x64.exe

If it works maybe we can see about fixing ffmpeg so it just works with rtp.

Just tested Build cb68f4cf

Another step forward and a new behaviour:

Tested on 2 HD channels: Stream with no obvious failures!

Tested on 1 SD channel: Audio starts with failures, no/or freeze frame (no movie), Mouse does not react anymore, Kodi has to be terminated with taskmanager

See log here 

Just had a look at the log:

line 2376: The adress is sligthly different to the one used in ffmpeg udp://@232.0.10.35:10000/?sources=87.141.215.251 in contrast to udp://@232.0.20.35:10000?sources=87.141.215.251

line 2382: It is decoding now with 25FPS!!  Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt470bg, top first), 720x576 [SAR 16:11 DAR 20:11], 25 fps, 50 tbr, 90k tbn, 50 tbc

line 2445ff:
2020-01-28 17:04:38.985 T:2984 ERROR: ffmpeg[0x127c46de0c0X]: [h264] number of reference frames (0+5) exceeds max (4; probably corrupt input), discarding one
2020-01-28 17:04:38.985 T:2984 ERROR: ffmpeg[0x127c46de0c0X]: [h264] hardware accelerator failed to decode picture
2020-01-28 17:04:38.985 T:2984 ERROR: ffmpeg[0x127c46de0c0X]: [h264] reference picture missing during reorder
2020-01-28 17:04:38.986 T:2984 ERROR: ffmpeg[0x127c46de0c0X]: [h264] Missing reference picture, default is 65588
2020-01-28 17:04:38.986 T:2984 ERROR: ffmpeg[0x127c46de0c0X]: [h264] hardware accelerator failed to decode picture

[phunkyfish]

The thing is you should use hwaccel for x264 I would think.

Maybe try this testbuild where I just pass the url exactly like the ffmpeg command as a URL: https://mirrors.kodi.tv/test-builds/wind...ix-x64.exe

If it works maybe we can see about fixing ffmpeg so it just works with rtp.

Just tested Build cb68f4cf

Another step forward and a new behaviour:

Tested on 2 HD channels: Stream with no obvious failures!

Tested on 1 SD channel: Audio starts with failures, no/or freeze frame (no movie), Mouse does not react anymore, Kodi has to be terminated with taskmanager

See log here 

Just had a look at the log:

line 2376: The adress is sligthly different to the one used in ffmpeg udp://@232.0.10.35:10000/?sources=87.141.215.251 in contrast to udp://@232.0.20.35:10000?sources=87.141.215.251

line 2382: It is decoding now with 25FPS!!  Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt470bg, top first), 720x576 [SAR 16:11 DAR 20:11], 25 fps, 50 tbr, 90k tbn, 50 tbc

line 2445ff:
2020-01-28 17:04:38.985 T:2984 ERROR: ffmpeg[0x127c46de0c0X]: [h264] number of reference frames (0+5) exceeds max (4; probably corrupt input), discarding one
2020-01-28 17:04:38.985 T:2984 ERROR: ffmpeg[0x127c46de0c0X]: [h264] hardware accelerator failed to decode picture
2020-01-28 17:04:38.985 T:2984 ERROR: ffmpeg[0x127c46de0c0X]: [h264] reference picture missing during reorder
2020-01-28 17:04:38.986 T:2984 ERROR: ffmpeg[0x127c46de0c0X]: [h264] Missing reference picture, default is 65588
2020-01-28 17:04:38.986 T:2984 ERROR: ffmpeg[0x127c46de0c0X]: [h264] hardware accelerator failed to decode picture 

If you switch off hardware acceleration in kodi settings what happens?

[buers]

I second that - try to disable HW acceleration (I recommended it before - I fear I was not really clear). Before you do it: Do you have the chance, to try another mpegts H264 SD stream (not depending on rtp)? Just to verify, that it is nothing totally unrelated to our rtp-issue.

Very good spotting of the additional slash, @Newbie268. I looked at the patch - I don't understand, how this could happen, after I have looked at it for quite some time. But I am a C-Oldie, and not a C++ Expert. I am aware of nested vars, but this needs a language lawyer

cpp:
size_t start = found + 3;

        size_t found = strURL.find("@");

 

Same variable name at the same block level but different - this smells fishy :-) @phunkyfish, do you see  the reason for the additional slash? If no, do you have the chance to investigate it in a debugger? No need to access the streams for this. But the additional slash is clearly wrong. (But might still not be the reason for the problem).

analyseduration: I don't have really an opinion there, just wanted to point out the surprisingly wrong fps. ffmpeg tells me often, that it does not recognize a stream and does suggest to increase the duration. Typically it will be EPG - we can ignore that. When I assume, that ffmpeg is expecting mpegts as Default with udp anyway - it should be easy. UDP is in some way less reliable as tcp, and packets can be reordered. rtp sends a sequence number, to detect this. I wanted to write robust code, to reorder buffers when needed. But it never happened in 48 hours. So, at least here, the stream is very reliable. And ffmpeg should be able to analyze it fast. But why the wrong fps?

[Newbie268]

Just tested Build cb68f4cf

Another step forward and a new behaviour:

Tested on 2 HD channels: Stream with no obvious failures!

Tested on 1 SD channel: Audio starts with failures, no/or freeze frame (no movie), Mouse does not react anymore, Kodi has to be terminated with taskmanager

See log here

Just had a look at the log:

line 2376: The adress is sligthly different to the one used in ffmpeg udp://@232.0.10.35:10000/?sources=87.141.215.251 in contrast to udp://@232.0.20.35:10000?sources=87.141.215.251

line 2382: It is decoding now with 25FPS!!  Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt470bg, top first), 720x576 [SAR 16:11 DAR 20:11], 25 fps, 50 tbr, 90k tbn, 50 tbc

line 2445ff:
2020-01-28 17:04:38.985 T:2984 ERROR: ffmpeg[0x127c46de0c0X]: [h264] number of reference frames (0+5) exceeds max (4; probably corrupt input), discarding one
2020-01-28 17:04:38.985 T:2984 ERROR: ffmpeg[0x127c46de0c0X]: [h264] hardware accelerator failed to decode picture
2020-01-28 17:04:38.985 T:2984 ERROR: ffmpeg[0x127c46de0c0X]: [h264] reference picture missing during reorder
2020-01-28 17:04:38.986 T:2984 ERROR: ffmpeg[0x127c46de0c0X]: [h264] Missing reference picture, default is 65588
2020-01-28 17:04:38.986 T:2984 ERROR: ffmpeg[0x127c46de0c0X]: [h264] hardware accelerator failed to decode picture  

If you switch off hardware acceleration in kodi settings what happens? 

Great step! Congratulations! It seems you come very close to a (temporay) solution until update of ffmpeg in Kodi?

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

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

Tested 2 SD channels (the same TV channels as for HD) each ~30 sec.: Significant interupts in stream and audio, green artefacts (But it seems only on the channels which are broadcasted both in SD and HD. Will investigate this further!

Find here the log!

[Newbie268]

Just had a look at the log:

line 2376: The adress is sligthly different to the one used in ffmpeg udp://@232.0.10.35:10000/?sources=87.141.215.251 in contrast to udp://@232.0.20.35:10000?sources=87.141.215.251

line 2382: It is decoding now with 25FPS!!  Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt470bg, top first), 720x576 [SAR 16:11 DAR 20:11], 25 fps, 50 tbr, 90k tbn, 50 tbc

line 2445ff:
2020-01-28 17:04:38.985 T:2984 ERROR: ffmpeg[0x127c46de0c0X]: [h264] number of reference frames (0+5) exceeds max (4; probably corrupt input), discarding one
2020-01-28 17:04:38.985 T:2984 ERROR: ffmpeg[0x127c46de0c0X]: [h264] hardware accelerator failed to decode picture
2020-01-28 17:04:38.985 T:2984 ERROR: ffmpeg[0x127c46de0c0X]: [h264] reference picture missing during reorder
2020-01-28 17:04:38.986 T:2984 ERROR: ffmpeg[0x127c46de0c0X]: [h264] Missing reference picture, default is 65588
2020-01-28 17:04:38.986 T:2984 ERROR: ffmpeg[0x127c46de0c0X]: [h264] hardware accelerator failed to decode picture  

If you switch off hardware acceleration in kodi settings what happens?  

Great step! Congratulations! It seems you come very close to a (temporay) solution until update of ffmpeg in Kodi?

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

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

Tested 2 SD channels (the same TV channels as for HD) each ~30 sec.: Significant interupts in stream and audio, green artefacts (But it seems only on the channels which are broadcasted both in SD and HD. Will investigate this further!

Find here the log! 

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

[Newbie268]

I second that - try to disable HW acceleration (I recommended it before - I fear I was not really clear). Before you do it: Do you have the chance, to try another mpegts H264 SD stream (not depending on rtp)? Just to verify, that it is nothing totally unrelated to our rtp-issue.

Very good spotting of the additional slash, @Newbie268. I looked at the patch - I don't understand, how this could happen, after I have looked at it for quite some time. But I am a C-Oldie, and not a C++ Expert. I am aware of nested vars, but this needs a language lawyer

cpp:
size_t start = found + 3;

        size_t found = strURL.find("@");

 

Same variable name at the same block level but different - this smells fishy :-) @phunkyfish, do you see  the reason for the additional slash? If no, do you have the chance to investigate it in a debugger? No need to access the streams for this. But the additional slash is clearly wrong. (But might still not be the reason for the problem).

analyseduration: I don't have really an opinion there, just wanted to point out the surprisingly wrong fps. ffmpeg tells me often, that it does not recognize a stream and does suggest to increase the duration. Typically it will be EPG - we can ignore that. When I assume, that ffmpeg is expecting mpegts as Default with udp anyway - it should be easy. UDP is in some way less reliable as tcp, and packets can be reordered. rtp sends a sequence number, to detect this. I wanted to write robust code, to reorder buffers when needed. But it never happened in 48 hours. So, at least here, the stream is very reliable. And ffmpeg should be able to analyze it fast. But why the wrong fps?

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?

[Newbie268]

If you switch off hardware acceleration in kodi settings what happens?  

Great step! Congratulations! It seems you come very close to a (temporay) solution until update of ffmpeg in Kodi?

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

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

Tested 2 SD channels (the same TV channels as for HD) each ~30 sec.: Significant interupts in stream and audio, green artefacts (But it seems only on the channels which are broadcasted both in SD and HD. Will investigate this further!

Find here the log! 

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

Strange: If running the same channel for about 23 min it seems there will be no further failures?

Here is the log

Unfortunately I had to remove a lot to get it pasted! Hope, that I had not removed too much!

[phunkyfish]

I second that - try to disable HW acceleration (I recommended it before - I fear I was not really clear). Before you do it: Do you have the chance, to try another mpegts H264 SD stream (not depending on rtp)? Just to verify, that it is nothing totally unrelated to our rtp-issue.

Very good spotting of the additional slash, @Newbie268. I looked at the patch - I don't understand, how this could happen, after I have looked at it for quite some time. But I am a C-Oldie, and not a C++ Expert. I am aware of nested vars, but this needs a language lawyer

cpp:
size_t start = found + 3;

        size_t found = strURL.find("@");

 

Same variable name at the same block level but different - this smells fishy :-) @phunkyfish, do you see  the reason for the additional slash? If no, do you have the chance to investigate it in a debugger? No need to access the streams for this. But the additional slash is clearly wrong. (But might still not be the reason for the problem).

analyseduration: I don't have really an opinion there, just wanted to point out the surprisingly wrong fps. ffmpeg tells me often, that it does not recognize a stream and does suggest to increase the duration. Typically it will be EPG - we can ignore that. When I assume, that ffmpeg is expecting mpegts as Default with udp anyway - it should be easy. UDP is in some way less reliable as tcp, and packets can be reordered. rtp sends a sequence number, to detect this. I wanted to write robust code, to reorder buffers when needed. But it never happened in 48 hours. So, at least here, the stream is very reliable. And ffmpeg should be able to analyze it fast. But why the wrong fps?

I missed that one. The variable should not be redefined. However functionally it won't make a difference.

[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.