HLS packetization (VOD): Wowza sometimes incorrectly handles the last chunk of the file

Wowza Streaming Engine
1

Greetings!

We use VOD streaming of *.m4a audio files.
We use the default value of the cupertinoChunkDurationTarget parameter (10 seconds).

When the audio file is just a bit bigger than the multiple of 10 seconds, there could occur two situations:

  1. the first test case: the file’s duration is almost exactly 90 seconds, but it is actually a bit longer, and the streaming server divides it into 10 chunks, and the last chunk’s duration is 0.023 seconds. Here is the chunklist generated by Wowza:
    #EXTM3U
    #EXT-X-VERSION:3
    #EXT-X-TARGETDURATION:10
    #EXT-X-MEDIA-SEQUENCE:0
    #EXT-X-KEY:METHOD=AES-128,URI="…",KEYFORMATVERSIONS=“1”
    #EXTINF:10.0,
    media_w517450999_0.aac
    #EXTINF:10.0,
    media_w517450999_1.aac
    […]
    #EXTINF:10.0,
    media_w517450999_8.aac
    #EXTINF:0.023,
    media_w517450999_9.aac
    #EXT-X-ENDLIST

In this case there is no problem, except that it would be more efficient to slightly extend the previous chunk (media_w517450999_8.aac), to avoid such short last chunk.

  1. the second test case: the file is 520 seconds long, but it is actually a bit longer, and the streaming server divides it into 53 chunks, and the last chunk’s duration is 0.011 seconds. Here is the chunklist generated by Wowza:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-KEY:METHOD=AES-128,URI="…",KEYFORMATVERSIONS=“1”
#EXTINF:10.0,
media_w1478881681_0.aac
#EXTINF:10.0,
media_w1478881681_1.aac
[…]
#EXTINF:10.0,
media_w1478881681_51.aac
#EXTINF:0.011,
media_w1478881681_52.aac
#EXT-X-ENDLIST

But in this case when the browser requests the last chunk (media_w1478881681_52.aac), it is not a short file, but a big 10MB file which contains basically the content of the whole original file.

While in the first example the short last chunk was not creating major problems, in the second example the problem is very serious, because this leads either to playing the track twice, or the player gets into infinite loop downloading the last chunk, if there is a timeout on the client side, and the client’s network speed is not sufficient to download the last chunk (10MB) within the timeout.

I can provide access to these test files, please let me know if you’d like to see them.

I’ve checked the HTTP Live Streaming specification (RFC 8216): https://tools.ietf.org/html/rfc8216, and it says:

4.3.3.1. EXT-X-TARGETDURATION

The EXT-X-TARGETDURATION tag specifies the maximum Media Segment
duration. The EXTINF duration of each Media Segment in the Playlist
file, when rounded to the nearest integer, MUST be less than or equal
to the target duration; longer segments can trigger playback stalls
or other errors. It applies to the entire Playlist file. Its format
is:

#EXT-X-TARGETDURATION:< s>

where s is a decimal-integer indicating the target duration in
seconds. The EXT-X-TARGETDURATION tag is REQUIRED.

So when the last chunk is shorter than 0.5 seconds, the specification allows to append it to the second-to-last chunk, because the total duration, rounded to the nearest integer, will be equal to EXT-X-TARGETDURATION value (in our case 10 seconds). Following this approach will guarantee that the last chunk’s duration is always greater than 0.5 seconds.

Is it possible to solve the problem on the Wowza side?

2

Sorry you didn’t receive a response @Vladimir_Volovich, Wowza had limited staff throughout the holiday break. Let me see what I can find out for you so that you may add that last, shorter chunk to the previous chunk.