The HLS protocol does not necessarily have ".m3u8" in the Master playlist link.

[kuniteru]

Hi, thank you for the HLS plugin work.

You said in README.md, "Notice that the recognition of the HLS protocol is based on the requirement of the URL extension of the Master playlist link, which must have ".m3u8" on it, as specified on the ISO regulation.". However the ISO regulation seems to write something a little different than this.

ISO regulation

Each Playlist file MUST be identifiable either by the path component of its URI or by HTTP Content-Type. In the first case, the path MUST end with either .m3u8 or .m3u. In the second, the HTTP Content-Type MUST be "application/vnd.apple.mpegurl" or "audio/mpegurl". Clients SHOULD refuse to parse Playlists that are not so identified.

That is, if the path ends with ".m3u" or the Content-Type is "application/vnd.apple.mpegurl" or "audio/mpegurl", the path does not have to contain ".m3u8".

An example of a service that returns a play list of HLS protocols without ".m3u8" in the path is "Microsoft Azure Media Services", and currently this plugin does not support HLS for this service.

• Example of url and Content-Type in Microsoft Azure Media Services
  • https://demo001ms-jpea.streaming.media.azure.net/00000000-0000-0000-0000-000000000000/demo-short.ism/manifest(format=m3u8-aapl)
  • Content-Type: application/vnd.apple.mpegurl

Please fix the protocol decision in the getVideoStreamingSampler function of the VideoStreamingSamplerFactory class.

Video Streaming Plugin version: 3.0.3 JMeter version: 5.3

[kuniteru]

I have confirmed that I can test against the HLS protocol of Microsoft Azure Media Services by using v3.1 and specifying the HLS protocol. Great improvement, thank you!

[RicardoPoleo]

That's nice to hear @kuniteru. Happy that this helped you out.

I'll be closing this issue since it seems it is no longer a problem anymore. However, if you have any troubles, don't hesitate to reopen it again.

Happy Hacking!