[gstreamer-bugs] [Bug 590014] Future of parsers

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=590014
  GStreamer | gstreamer (core) | git

Stefan Kost (gstreamer, gtkdoc dev) <ensonic> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ensonic at sonicpulse.de

--- Comment #8 from Stefan Kost (gstreamer, gtkdoc dev) <ensonic at sonicpulse.de> 2010-01-28 09:15:02 UTC ---
I think this also suffers from a terminology problem. We have this draft
http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/design/draft-klass.txt
It defines Encoders/Decoders/Muxers/Demuxer and even Extracter/Formatter.

Right now we use Parsers to packetize incoming streams into units for decoding.
E.g. standalone bitstreams that are not in a container format are parsed and
converted into a format that codecs expect. This allows us to spare all codec
implementations to reimplement that.

We also use parsers to to packetize raw audio/video in case we know the format
from somewhere.

One benefit of having parsers is that one can find out more details from media,
without plugin codecs. On platforms where codecs are run on dsp/gpu
instantiating a codec can be slow or can have limmitations.

But then we also use the Parser terminology for 'demuxers' that only have
single media streams (wavparse, auparse, ...).


So I actualy like the original plan of having parsers and also make them more
madatory. I don't think we need the counterparts in many cases (e.g. rawparse
obviously does not need them). For bitstream formats or metadata adding and the
single stream format they make sense.

I admit I failed to get the point in comment #3 for the muxers - which of our
muxers uses GstAdapater?

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