ignore query when checking for mp4 url extension

[tjenkinson]

This PR will...

Use the parse in UrlToolkit to extract just the path and use that for checking for the '.mp4' extension.

Why is this Pull Request needed?

Currently if there's a query string the check fails.

Resolves issues:

fixes #3756

Checklist

• changes have been done against master branch, and PR does not conflict
• new unit / functional tests have been added (whenever applicable)
• API or design changes are documented in API.md

[robwalch]

Nice fix.

I don't have a lot of experience with SIDX streams. I'd like for the reporter who raised this to provide one, and for us to explore other ways of dealing with this (like: backtracking or changing the requirement for initSegment to be defined when there is no MAP and SIDX is found).

[tjenkinson]

and for use to explore other ways of dealing with this (like: backtracking or changing the requirement for initSegment to be defined when there is no MAP and SIDX is found).

I don’t understand fully what’s going on but given the warning it looks like this is attempting to handle faulty streams that missed the EXT-X-MAP tag?

[robwalch]

I don’t understand fully what’s going on but given the warning it looks like this is attempting to handle faulty streams that missed the EXT-X-MAP tag?

I think streams with SIDX don't need one, but then there is nothing to signal the stream is fmp4, so we're trying to infer that from the url... and set initSegment. If not set, then the first segment we load will determine that we need the mp4 pass through demuxer/remuxer, and when initSegment is undefined we'll have problems (need a stream to confirm this). It might be possible to handle this on-the-fly after parsing the first segment, rather than use this workaround to take the initSegment happy path. I don't know if any of our sample test streams use the SIDX code (where we could clone the manifest and remove MAP tag to test this) so asking for a stream in exchange for working on the issue would be a fair trade.

I'm bringing this up because i've seen too many solutions that infer information from a URL or exrtension and they are never perfect and always come back with new requirements (someone has a custom extension or defines the type in the query string) so if there is a way to deal with this in the transmuxer or stream controllers we wouldn't need this code or warning in the m3u8 parser.

Not pushing back at all on this change. It's a solid improvement. It just raises the concerns of:

• Missing test media (SIDX)
  • also some missing expertise on my part: why would you have a stream like this, how can I make one?
• Inferring info from file extensions is not bullet proof
• Is this configuration spec-compliant and/or is it supported by Safari <video src=?

[tjenkinson]

Cool

Inferring info from file extensions is not bullet proof

Yeh this stands out as being a bit weird