Answered question

HTTP Live Streaming (or HLS) is an adaptive streaming communications protocol created by Apple to communicate with iOS and Apple TV devices and Macs running OSX in Snow Leopard or later.
HLS can distribute both live and on-demand files and is the sole technology available for adaptively streaming to Apple devices, which is an increasingly important target segment to streaming publishers.

HLS is widely supported in streaming servers from vendors like Adobe, Microsoft, RealNetworks, and Wowza, as well as real time transmuxing functions in distribution platforms like those from Akamai.
The popularity of iOS devices and this distribution-related technology support has also led to increased support on the player side, most notably from Google in Android 3.0.

I discussed with development on this type of application and media stream you are working with, which is indeed an adaptive streaming technology.
Adaptive means that the client can control the quality (bitrate) of the video chunk based on the application and network current performance. Typically, when application runs fine (and with good network condition),
video chunks are sent using highest bitrate available to provide users the best video as possible. But when application or network performance decrease (either server under load or poor network access),
then the client will automatically decrease the quality (bitrate) of the video, to keep showing some content (adaptive streaming technology relies on the fact that uninterrupted bad quality video is better than lagging high quality video).

NeoLoad does not support natively this adaptive streaming technology (HLS). So far, NeoLoad only supports "non-adaptive" streaming technology, where the bitrate is at fixed rate.
However, we have been able in the past to support such protocol by doing an advanced design of the User Path.

The main challenges are:

1) Ability to understand how to compute the most appropriate bitrate based on the current application/network performance. This can be done for example by measuring the response time of the media response time, with 2 javascripts,
one before the request execution to start a timer, and another one after the request execution to stop the timer. Once we know this response time, we can compute what would be the most appropriate bitrate,
and inject it in the next media request URL. This media request has to be in a fork and a while loop.

2) Ability to measure the application performance based on relevant media metric. Natively, NeoLoad provides media metrics (lag duration, buffer length...) only for "non-adaptive" media request. With adaptive streaming technology,
what matters is to know the current bitrate used, to be able to correlate the quality of the video in function of the load/quality of the network. To achieve this need, we can use the NeoLoad custom action "Custom measurement"
to inject the current bitrate value to the NeoLoad Data exchange API.

Technically, this integration is possible, we've successfully done it in the past with previous applications, but it will require a lot of time to understand the bitrate computation algorithm (depends on the client implementation)
and implement such a design in a NeoLoad User Path. It will probably take few days or a week of consulting.