[url] skip parsing username:password@ for udp/rtp streams

[phunkyfish]

Description

Username and password are not valid for UDP/RTP streams. This can cause issues where the URL is in the form rtp://sourceip@multicastip.

Fixes: #17220

Motivation and Context

Fix udp/rtp streams in the format rtp://sourceip@multicastip

How Has This Been Tested?

Requires user testing. I don't have a stream of this type.

Screenshots (if appropriate):

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• None of the above (please explain below)

Checklist:

• My code follows the Code Guidelines of this project
• My change requires a change to the documentation, either Doxygen or wiki
• I have updated the documentation accordingly
• I have read the Contributing document
• I have added tests to cover my change
• All new and existing tests passed

[Rechi]

Please follow the current code guidelines.

[phunkyfish]

Fixed @Rechi

[Rechi]

Please follow the current code guidelines.

[phunkyfish]

It's really fixed now.

[phunkyfish]

After some user testing on windows we get an error with what is enabled in the ffmpeg build:

20-01-20 20:30:40.851 T:41920  NOTICE: Creating Demuxer
2020-01-20 20:30:40.851 T:41920   DEBUG: ffmpeg[0x281d99ca380X]: [udp] 'circular_buffer_size' option was set but it is not supported on this build (pthread support is required)
2020-01-20 20:30:40.853 T:23612   DEBUG: Previous line repeats 1 times.
2020-01-20 20:30:40.853 T:23612   DEBUG: Loading settings for pvr://channels/tv/All%20channels/pvr.iptvsimple_425868680.pvr

Full log: https://paste.kodi.tv/vewologahu.kodi

[phunkyfish]

As it’s lacking pthread the error should be windows only.

[phunkyfish]

@Paxxi would there be any side effects if we build ffmpeg for windows using pthreads instead w32threads that you know of?

So with something like --disable-w32threads --enable-pthreads or it's working equivalent?

[Paxxi]

I don't really know.

Based on the given information I would assume pthreads don't work on windows or there wouldn't really be a reason to have a w32-threads option.

Maybe it's a simple patch for ffmpeg where it checks for thread support? I would look into that first, if it's more than a bad if check then it might be worth trying with pthreads.

[phunkyfish]

Good point. Will look into it.

May also be solved by a later version of ffmpeg, another option.

[phunkyfish]

Ok, so ffmpeg requires the URL in a different format if source IPs are used: http://ffmpeg.org/ffmpeg-protocols.html#rtp

So rtp://sourceip@multicastip needs to become rtp://@multicastip?sources=sourceip. Which will mean an additional change in DVDDemuxFFmpeg so support this.

May also mean the error above is red herring.

[phunkyfish]

Also, after some reading there is a marginal difference between w32threads and pthreads, hence why most use w32. We can always try it later on if we eventually need to.

[FernetMenta]

I seriously doubt that changing ffmpeg to pthreads is an appropriate solution for the issue you are trying to solve. Try to explain why this should require pthreads. Makes no sense at all. Why don't you elaborate on the root cause. Have you asked ffmpeg developers already?

Changing ffmpeg to pthreads introduces a high risk of breakage. Taking this risk for something that should be fixed elsewhere is a bad idea.

[phunkyfish]

UDP streams use pthreads for their circular_buffer logic. The included patch adds missing logic in w32pthreads to allow this (hopefully) to function, but just for UDP.

Have not asked ffmpeg devs yet. I have submitted a patch that fixes an RTP bug, but I fear this currently lacks a maintainer.

Is the ffmpeg patch in the PR not how you would go about this?

[FernetMenta]

Your commit messages are misleading. I thought you were disabling w32threads in favour of pthreads for the mingw build. This would have been a major change.

What you actually do is making udp use the pthreads compat layer on windows platform. That's a completely different story. Sorry for thy noise. More precise commit messages welcome :)

[phunkyfish]

:) in hindsight it is a bit ambiguous!

[phunkyfish]

All user testing on this has passed so will merge this tomorrow.

Due to the patching required I don’t think I will backport this to Leia.