Long buffering times in low bitrate HLS AAC radio streams

[Michał Budzyński]

Dear All,

I am experiencing issues with playback of low bitrate HLS radio streams 
with fragments encoded with non-multiplexed AAC ADTS.

While playing low bitrate streams we experience several minutes of 
buffering and ~1min for high bitrate ones (tested with latest 1.9.x master).

gst-launch-1.0 uridecodebin uri= 
http://aac.cbs.co.kr/cbs939/_definst_/cbs939.stream/chunklist_w2049262799.m3u8 
! autoaudiosink

The actual problem is not connected to the HLS per se, rather to the 
following facts:

1. Hlsdemux grabs a the fragment files from streaming server. And is 
able to download new ones only after new EXT-X-MEDIA-SEQUENCE number has 
become available (approx every EXT-X-TARGETDURATION == 10s)

2. Uridecodebin sees that the stream is_adaptive and in "make_decoder 
(GstURIDecodeBin * decoder)" decides to set "use-buffering" property on 
its child decodebin. With 5s and 2MB buffering defaults for decodebin 
which are propagated to its internal multiqueue.

3. Buffers produced by hlsdemux passed to id3demux (and later to 
multiqueue) do not have valid timestamps yet (until passed to aac_parse 
and decoder). Thus multiqueue "max-size-time" based arbitration is 
disabled. As the HLS fragment files are usually small (50KB - 200KB) the 
  default "max-size-bytes" arbitration causes the multiqueue to stall 
for several HLS EXT-X-MEDIA-SEQUENCE updates (1-6minutes).

Of course when using pure decodebin with "use-buffering=TRUE" the 
buffering defaults for multiqueue are no better and effect is identical.

Knowing apriori the stream bitrate I could set the "buffer-size" 
property on uridecodebin/playbin on application lavel and be done with 
the problem but I feel that this should be handled internally by 
uridecodebin and decodebin pair and I would be willing to work on a 
possible fix.

The needed bitrate information is available during
"configure_stream_buffering (GstURIDecodeBin * decoder)" which heppens 
later than "make_decoder (GstURIDecodeBin * decoder)" but is not exposed 
outside and not passed to the appropriate decodebin (decodebin would in 
turn need to update the multiqueue on its "max-size-bytes" update which 
it does not at the moment).

Any thoughts on the matter would be really welcome :)

Best Regards,
Michał Budzyński