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

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Tue Jun 26 08:13:14 PDT 2012


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

--- Comment #9 from Sebastian Dröge <slomo at circular-chaos.org> 2012-06-26 15:13:11 UTC ---
(In reply to comment #8)
> (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.

That's great news :)

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

The main problem with that is that it would be h264parse job still. And
h264parse would be autoplugged anyway. It's were conversions like this should
happen

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