HLS Store audio positions according to what a client user has listened to

Hire a Consultant
1

We are streaming Audiobooks as mp3 files and have setup HLS Streaming in Wowza with File as StreamType.

We would like to be able to store Start and Stop positions so that we know what on the mp3 file each user has listened to without having to manipulate the Client-side code.

Ex) a user1 listens from (mm:ss) 00:00 to 00:30 and then seeks to the middle of the playback and listens, 25:00 to 35:00.

We would like to get this data as something like this:

List timeList.

timeList[0].Start = 00:00

timeList[0].Stop = 00:30

timeList[1].Start = 25:00

timeList[1].Stop = 35:00

Right now we are using the onHTTPCupertinoStreamingSessionDestroy event to get the

IOPerformanceCounter.getMessagesOutBytesRate() and IOPerformanceCounter.getMessagesOutBytes()

to calculate how many seconds has been loaded by the user.

Another solution that would solve the problem is if we knew which Chunks (mp3 files inside the chunklist) the user has been listening to.

Ex) if a user listened to the first 30 seconds of the audiobook that would mean he listened to the 3 first chunks, but then he seeks on the player to play somewhere in the middle of the audiobook and while there he listens another 15 seconds.

In this case we would like to see something like :

chunk0 = 10 seconds,

chunk1 = 10 seconds,

chunk2 = 10 seconds,

chunk30 = 10 seconds,

chunk31 = 5 seconds (because in this case the user has only listened 5 seconds as mentioned above).

(ex, if each chunk is 10 seconds it would mean that chunk31 is at 320 seconds (on the seek). in that case we can at least calculate what parts of the mp3 file a user has listened to)

Or just a list of chunks that has been loaded but with some kind of timestamp so that we know that chunk0 started at 00:00 and chunk31 at 05:20.

2

Hi there … just my small grain of salt on this. Measuring this from server side will be complicated. HLS chunks won’t have always same length (it could, but it’s not necessary the case) … second, a chunk downloaded by the player doesn’t mean it was played. HLS specifies that chunks are buffered on client, meaning, 2 chunks could have been downloaded an never played … and each HLS player has its own way of buffering, particularly when it comes to on-demand like your case. Unless you always use same player (not mixing for instance a desktop player with a native IOS player), you could get different results with same behavior.

I know you said you don’t want to manipulate client side, but it’d be the best practice (and you’d be able to get more info from customer’s behavior).

3

Hi there … just my small grain of salt on this. Measuring this from server side will be complicated. HLS chunks won’t have always same length (it could, but it’s not necessary the case) … second, a chunk downloaded by the player doesn’t mean it was played. HLS specifies that chunks are buffered on client, meaning, 2 chunks could have been downloaded an never played … and each HLS player has its own way of buffering, particularly when it comes to on-demand like your case. Unless you always use same player (not mixing for instance a desktop player with a native IOS player), you could get different results with same behavior.

I know you said you don’t want to manipulate client side, but it’d be the best practice (and you’d be able to get more info from customer’s behavior).

Hi Tavius,

We are fully aware of this (that i will only know how many chunks the client has loaded, not what has been played).

And yes we do know that there is only one HLS player that will be using this solution.

It is good enough for us just to know how many/which chunks the client has loaded.