Created attachment 346314 [details] [review]
hlsdemux: Try to find type at the end of a fragment

Comment on attachment 346314 [details] [review]
hlsdemux: Try to find type at the end of a fragment

Can you provide a example stream for this? And why doesn't this find the type while buffers are arriving, but finds it on finish then? Isn't it looking at exactly the same data?

> And why doesn't this find the type while buffers are arriving,
> but finds it on finish then? Isn't it looking at exactly the
> same data?

As I understand it, it doesn't find the type while buffers are arriving because it doesn't even attempt to do any typefinding yet there. When the data is very small (<2 kB), this

    /* Typefind could miss if buffer is too small. In this case we
     * will retry later */
    if (buffer_size >= (2 * 1024) || at_eos) {
      caps =
          gst_type_find_helper_for_data (GST_OBJECT_CAST (hlsdemux), info.data,
          info.size, &prob);
    }

will never run.

I think the patch makes sense.

Yes, that makes sense then. Having an example stream would still be useful though :)

Created attachment 347252 [details] [review]
hlsdemux: Expose all type of rendition streams

Not only audio and video, allow exposing subtitle/closed-caption streams

(In reply to Sebastian Dröge (slomo) from comment #4)
> Yes, that makes sense then. Having an example stream would still be useful
> though :)

This is the test stream provided by Apple.
http://devimages.apple.com.edgekey.net/streaming/examples/bipbop_16x9/bipbop_16x9_variant.m3u8

Additionally, we need attachment 347252 [details] [review] to enable WebVTT subtitle. Anyway, we can remove the code for blocking subtitle streams now, since WebVTT parser has been implemented in subparse element.

There is another reason WebVTT is disabled by default - with playbin2 they cause playback stalls at bitrate switching time.

The problem is that decodebin2 wants to switch to a new decode chain when switching bitrate, but gets stuck waiting for the webVTT stream to EOS - which it never does if the video stream finished already, as it's blocked downstream waiting for video to advance. Video won't advance until the new bitrate stream starts sending data.... which it can't do because decodebin has blocked it waiting for the old bitrate to finish.

We can only enable WebVTT when we know it's OK to switch out streams on-the-fly. For that, we need to only enable them when requested by a stream-selection event. We should implement it that way.

Comment on attachment 347252 [details] [review]
hlsdemux: Expose all type of rendition streams

Let's put this into a new bug then

Attachment 346314 [details] pushed as 3c5eae6 - hlsdemux: Try to find type at the end of a fragment

(In reply to Jan Schmidt from comment #7)
> There is another reason WebVTT is disabled by default - with playbin2 they
> cause playback stalls at bitrate switching time.
> 
> The problem is that decodebin2 wants to switch to a new decode chain when
> switching bitrate, but gets stuck waiting for the webVTT stream to EOS -
> which it never does if the video stream finished already, as it's blocked
> downstream waiting for video to advance. Video won't advance until the new
> bitrate stream starts sending data.... which it can't do because decodebin
> has blocked it waiting for the old bitrate to finish.
> 
> We can only enable WebVTT when we know it's OK to switch out streams
> on-the-fly. For that, we need to only enable them when requested by a
> stream-selection event. We should implement it that way.

Hi,as you say " For that, we need to only enable them when requested by a stream-selection event...."
When we select stream bitrate how we implement WebVTT?
Is it in the function of "gst_hls_demux_select_bitrate(GstAdaptiveDemuxStream * stream, guint64 bitrate)"?