Thank you for the feedback. The documentation is accordingly updated.
Regarding the request timeout, it depends on the segment duration. Viblast calculates the timeout for every segment by multiplying its duration by 3. So, if you have segment with 10 seconds duration, then Viblast Player will wait 30 seconds before timeout aborting.
Thank you for updating documentation.
It seems that it would be useful to add one more parameter, e.g. maximal-segment-request-timeout
or just segment-request-timeout (in this case the minimal-segment-request-timeout could be removed).
Here is the explanation for this request:
when the Viblast player requests a segment, the server may need some time (a few seconds) to process the request, if it needs to do some database authentication for the request based on the encrypted information of the stream/segment URL. So, after the server receives the request to download a segment, it performs some calculations which may take up to e.g. 2-3 seconds, and then it serves the request. I.e. the actual download of the segment is quite fast, but initial processing and authentication may take a few seconds.
The parameter minimal-segment-request-timeout was created for the situation when the last segment of the stream is very short, in the range of 1-50 ms, as it may happen sometimes. In this case the Viblast's default algorithm will use the segment timeout which is 3*segment duration, i.e. 3-150ms, which will be insufficient for the server to process the request (see above - the server may need 2-3 seconds to authenticate the request). Therefore, the minimal-segment-request-timeout parameter allows to increase this minimal timeout to allow Viblast to successfully download the last segment of the stream.
Also, for some reason, in Firefox, sometimes the request to download the segment times out, and the response is not received at all. Suppose that the segment length is 10 seconds. In this situation Viblast's default timeout will be 30 seconds, and if Viblast will wait 30 seconds, it will likely experience a situation when it will run out of buffer, and playback will stop before Viblast will make a new request to re-download the timed out segment.
For this situation, it is useful to set the timeout value to e.g. 5 seconds (instead of the default 30 seconds based on segment duration), so if the request will time out, such situation will be detected much sooner than the buffer will become empty, and playback will not stop.
So it would be useful to either have the maximal-segment-request-timeout parameter (which we'll set to 5 seconds in the above scenario), or have just a single parameter segment-request-timeout.
Thank you for the detailed feedback.
Sounds reasonable and we are considering to introduce a new parameter - maximal-segment-request-timeout.
Our users who are using Firefox often encounter the problem that Firefox fails to download a chunk, and this results in waiting for too long until Viblast reaches an empty audio buffer, so the playback stops.
We need to be able to force Firefox to re-download a chunk if it did not download it within a few seconds, therefore we need a parameter such as maximal-segment-request-timeout discussed above.
Please add this parameter to Viblast.
With the latest version of the player - 6.56.4 the requested parameter is already supported:
From the docs:
maximal-segment-request-timeout (integer) : Controls the maximal download chunk timeout. The internal download timeout is calculate as: 3*segment duration and if the calculated value is greater than declared, it is replaced. The default value is 30000ms.
It appears that when playing MP4 streams on Firefox, it often encounters a timeout when requesting chunks, and Viblast shows a message like this in the console:
[18:10:07] [vb] Error(HlsPeer.cc:608): Cannot get chunk(chunkIdx=7-7). Request timedout (timeout=30000)
When the buffer is short enough, such a long timeout of 30 seconds causes interruption in playback.
Is there a configuration parameter which allows to configure the chunk request timeout?
Also, could you please update the documentation at
to mention all supported parameters? E.g. some parameters mentioned in release history page
are not mentioned in the documentation. Probably there are other undocumented parameters as well.