[Bug 594035] Add HTTP Live Streaming playback support

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Mon Mar 7 09:06:42 PST 2011


https://bugzilla.gnome.org/show_bug.cgi?id=594035
  GStreamer | don't know | git

--- Comment #35 from Andoni Morales <ylatuya at gmail.com> 2011-03-07 17:06:38 UTC ---
(In reply to comment #34)
> Hi, 
> 
> I tested a little bit the new design. It takes some times when entering the
> playing state. Around 1 min for gst-launch playbin2

I have also experienced the same problem but I didn't have time to debug it
further. It also happens whith stream with a low bitrate, so I believe
somewhere a queue is waiting to be filled to start playing.

> Would it be possible to force hlssrc to play the stream which has its bitrate
> the closest than a given bitrate through a property ?
> (for example, even if a user can play the high quality stream, he could also
> decide to play the low one) (Or also if in a certain context, the user knows
> that he cannot play high quality stream, then it's not necessary to try to play
> it) (There is a "connection-speed" property in playbin2)

I think we should have a property to select the bitrate switch algorithm. The
current one is very basic and it only takes in account the download speed but
it should also take in account QOS from downstream elements. It would be
straightforward having the following algorithms:
 * Always lowest
 * Always highest
 * Connection speed
> 
> Also would it be possible to report the decoded url for the fragment, through a
> tag event or something else useable (not only in debug) ?
> 
We could post a message in the bus with the decoded url if you think it's
useful.

> Is there a way to retrieve the downloaded fragments on the local hard disk ?
> (download property of uridecodebin ?)
You can use multifilesink element for that, because the element pushes one
buffer for each fragment
souphttpsrc ! hlssrc ! multifdsink

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list