Author Topic: Some questions on HLS  (Read 99 times)

drugoimir

  • Posts: 23
Some questions on HLS
« on: 14 Mar '19 - 12:15 »
Hello Ian,

i'm referring to this post: http://www.un4seen.com/forum/?topic=16905.msg125091;topicseen#msg125091
where the user tells that the HLS stream stops after some minutes (i've obaserved that the streaming stops when
the songs really ends and the radio is playing a jingle for the next song): i've set a BASS_SYNC_END on the stream channel and indeed it's triggered.
Tried also what you said, so i launch the BASS_ChannelPlay command into the SYNC_END callback, but playing does not recover.

It seems i have the same problem, but only under linux (gcc): i've made the same player runnning under windows (delphi)
and it ran flawlessly for about a whole day.

The library versions (both inteded for x64 OS) are:
on windows
Bass 2.4.14.0
BassHls 2.4.1.1
BassAAC 2.4.0.1

on Linux/Ubuntu16 x64 i have:
Bass 2.4.14.1
BassHls 2.4.2.0
BassAAC 2.4.5.8

A last question: should i take care of buffer over/underflowing due to audio producer/consumer clock skew?
On a previous application using shoutcast, i had to trim the playing speed in order to keep the buffer happy over long times,
Is this still needed with HLS ?
Many thanks.

Ian @ un4seen

  • Administrator
  • Posts: 21593
Re: Some questions on HLS
« Reply #1 on: 14 Mar '19 - 15:40 »
i'm referring to this post: http://www.un4seen.com/forum/?topic=16905.msg125091;topicseen#msg125091
where the user tells that the HLS stream stops after some minutes (i've obaserved that the streaming stops when
the songs really ends and the radio is playing a jingle for the next song): i've set a BASS_SYNC_END on the stream channel and indeed it's triggered.
Tried also what you said, so i launch the BASS_ChannelPlay command into the SYNC_END callback, but playing does not recover.

It seems i have the same problem, but only under linux (gcc): i've made the same player runnning under windows (delphi)
and it ran flawlessly for about a whole day.

Please post an affected URL to have a look at.

If it is the same as in the linked post, note that you would need to recreate the stream when playback ends (eg. call BASS_StreamCreateURL again), not just call BASS_ChannelPlay.

A last question: should i take care of buffer over/underflowing due to audio producer/consumer clock skew?
On a previous application using shoutcast, i had to trim the playing speed in order to keep the buffer happy over long times,
Is this still needed with HLS ?

That sounds like there was a small difference in the rates that the output device and server/source were running at. It is possible for a device to not run exactly at the specified rate. So the answer to your question is that it will depend which end had the timing problem. If it was at your end then it is likely to affect all streams, including HLS. If it was at the server's end then the HLS stream probably won't be affected (if it's a different server/source).

drugoimir

  • Posts: 23
Re: Some questions on HLS
« Reply #2 on: 14 Mar '19 - 18:33 »
Quote
Please post an affected URL to have a look at.
I've mailed it now, it is not a public stream.

Quote
If it is the same as in the linked post, note that you would need to recreate the stream when playback ends (eg. call BASS_StreamCreateURL again), not just call BASS_ChannelPlay.
That's ok, i will try .
But the main reason i wrote is because this problem seems on the basshls linux version only: the same code (only written in delphi) is running on a windows machine and has no problems.
The libraries (both for linux and windows) were "freshly" downloaded from your site, but the versions are slightly different: the linux version seems newer.

Little update: i set a sync also on new HLS segment downloading and i see that, even when the channel has already triggered the STREAM_ENDED sync, it is still downloading HLS segments.
After a couple of new segments downloaded it hangs (when BASS_CONFIG_NET_BUFFER set at 60seconds is reached).
Further update: i confirm that recalling the whole create procedure resumes the stream, but audio "jumps"; resuming is not seamless.
Here's the code i call:
Code: [Select]
void CALLBACK EndSync(HSYNC handle, DWORD channel, DWORD data, void *user)
{
#ifdef DEBUG
fprintf(stderr,"ENDED -RESTARTED \r\n");
#endif
pchan = BASS_HLS_StreamCreateURL(CurrURI,BASS_STREAM_DECODE | BASS_SAMPLE_FLOAT,NULL, 0);
BASS_ChannelSetSync(pchan,BASS_SYNC_HLS_SEGMENT,0,HlsSync,0); // HLS
BASS_ChannelSetSync(pchan,BASS_SYNC_STALL,0,StallSync,0);
                        BASS_ChannelSetSync(pchan,BASS_SYNC_END,0,EndSync,0);
BASS_ChannelPlay(pchan,FALSE);
BASS_Mixer_StreamAddChannel(amix,pchan,BASS_MIXER_BUFFER);

}

Quote
That sounds like there was a small difference in the rates that the output device and server/source were running at. It is possible for a device to not run exactly at the specified rate. So the answer to your question is that it will depend which end had the timing problem. If it was at your end then it is likely to affect all streams, including HLS. If it was at the server's end then the HLS stream probably won't be affected (if it's a different server/source).
Yes, unless both ends are using some absolute timing reference (such as atomic clock, gps or something), and this is not the case,  they must rely on "some tens of ppm" crystal reference.
So, although they are in close proximity, the two frequencies are different and i observed that, over long periods, the buffers tend to over/underflow.
That's why -if your player is intended for 24/7 operation- you should take this into account and it's the same principle used on some hardware streaming modules
that can throttle their clock in order to compensate clock skew.
The streaming clock compensation loop is trivial, and -if not already present- could be a nice feature to be implemented into your library.

Thanks
« Last Edit: 15 Mar '19 - 09:40 by drugoimir »

drugoimir

  • Posts: 23
Re: Some questions on HLS
« Reply #3 on: 16 Mar '19 - 10:26 »
Thanks Ian,
i quote your answer below :
Quote
This is not the same issue as the one in the post
you linked. The problem in this case is that there are occasionally
ID3v2 tag blocks in the AAC data, which is resulting in the decoder
losing sync (when they are more than 1.5KB long) and ending the stream.

An ID3v2 tag block is fine at the start of a media segment but not
mid-segment.
That's ok and makes sense, but the question remains: why this does
not occur having the same stream, same libraries, but running under windows?
Is there any way to catch that spurious ID3V2 tag ?

Thanks

Ian @ un4seen

  • Administrator
  • Posts: 21593
Re: Some questions on HLS
« Reply #4 on: 18 Mar '19 - 14:34 »
I notice in the 1st post you say you're using a much older BASS_AAC version on Windows than on Linux. The sync tolerance was 4.5KB (rather than 1.5KB) back then. I will look into the possibility of having it skip ID3v2 tag blocks of any size, and then hopefully come back with an update for you to try.

drugoimir

  • Posts: 23
Re: Some questions on HLS
« Reply #5 on: 18 Mar '19 - 15:31 »
Quote
I notice in the 1st post you say you're using a much older BASS_AAC version on Windows than on Linux. The sync tolerance was 4.5KB (rather than 1.5KB) back then. I will look into the possibility of having it skip ID3v2 tag blocks of any size, and then hopefully come back with an update for you to try.
That's would be great!
I'll wait for the patched AAC decoder.

Thanks a lot!