[Bug 675625] [dashbin] a streaming client supporting the new MPEG DASH standard

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Tue Jun 26 08:04:11 PDT 2012


https://bugzilla.gnome.org/show_bug.cgi?id=675625
  GStreamer | gst-plugins-bad | 0.10.23

--- Comment #8 from Gianluca Gennari <gennarone at gmail.com> 2012-06-26 15:04:03 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > I would strongly prefer a setup where the DASH plugin comes into play only when
> > > a DASH manifest file is detected. This means there either needs to be a special
> > > URI scheme (not a great approach), or a manifest file "demuxer" approach  a la
> > > hlsdemux needs to be taken. "demuxer" is a bit misleading here, since it's not
> > > really doing any demuxing at all, it's just how it appears to playbin2 really
> > > and where it sits in the autoplugging order. Once it gets the initial
> > > playlist/file, it takes over.
> > 
> > Thanks for the explanation, now it makes a lot of sense. Actually, this
> > approach will simplify quite a few things and it is easy to implement, so I'm
> > definitely going to adopt it.
> 
> Any news on this? :)

Hi Sebastian,
there are several news indeed. We are about to start a collaboration with
Orange (they have been very active on the GStreamer list about DASH
developments) in order to jointly develop a new DASH client for GStreamer,
based on HLSdemux, with an enhanced feature set and an up-to-date support for
the DASH manifest file syntax. This will take several weeks to be released, so
for the time being please consider the DASH client released in this topic as a
proof-of-concept version.

> 
> > Since we started talking about the interaction with Playbin2, let me ask a few
> > question.
> > 
> > We may have several languages for audio tracks or subtitles, available as
> > separate streams. The list of all available options is known after we complete
> > the parsing of the manifest file, then we need to notify Playbin2 of this list,
> > and finally we need to get back the selected language from Playbin2, in order
> > to set-up the download of the correct tracks. Is there a standard way to do
> > this with Playbin2?
> 
> Language tags for the different streams, yes. That's how it is done with other
> container formats too.

Ok thanks, I will look into this. My only doubt was about the possibility to
have a notification from playbin2 about the audio track effectively selected by
the user (or at least a default selection) before we start downloading the
segments. 

> > Also, when we have several video views/layers (for H.264/MVC or H.264/SVC
> > streams) we need to reassemble a compliant H.264 raw bitstream using a sort of
> > "h264mux" element, before sending it to the decoder. Is Playbin2 able to
> > auto-plug muxer elements (eventually, using some "magic" trick)? Otherwise, I
> > will have to construct the reassembling pipeline into the dashbin.
> 
> h264parse could do this and is autoplugged already in front of the
> decoders/sinks

I know h264parse quite well, as I already modified it to implement the opposite
feature ("demuxing" the H.264 stream to feed the mpegtsmux element in order to
produce a "layered" MPEG-2 transport stream). But I don't like its structure
very much, so I will probably end up developing a new plugin dedicated to just
reassembling the H.264 layers/views (as there is not much parsing involved into
this process, the code duplication will be minimal, if any).

-- 
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