[gstreamer-bugs] [Bug 518857] parser baseclass

GStreamer (bugzilla.gnome.org) bugzilla-daemon at bugzilla.gnome.org
Wed Feb 27 06:16:52 PST 2008


If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=518857

  GStreamer | gstreamer (core) | Ver: HEAD CVS




------- Comment #3 from Sebastian Dröge  2008-02-27 14:16 UTC -------
Some comments from a short look:
- as the newsegment event is pushed just before the first buffer we have to
queue up all events (except EOS) and push them after newsegment. This is needed
a decodebin only links pads after newsegment and otherwise we loose some
events, like tags for example. See my latest change to mp3parse/mad.

- g_object_unref (adapter) already clears the adapter ;)

- the event() methods have no way of telling that the event was handled but an
error happened when pushing downstream for example

- there could be some default timestamp tracking for buffers, i.e. look at the
upstream newsegment events for start timestamp, if parse_frame() gives a
duration calculate everything else with it. This should only be done if
parse_frame() doesn't give a valid timestamp!

- IMHO we can pass read-only buffers to check_valid_frame(). This way we don't
need to memcpy(), etc.

- Frames that end before segment start and frames that start after segment stop
should be dropped but there should be a way to override the dropping behaviour.
I.e. for mp3parse we need to start pushing frames a few frames (given as
timestamp) before segment start to get decoding from the position we want.

- For the chain function we should update the minimal frame size after every
pushed frame. This is to allow things like a special header at the start of the
file: the subclass would first have a minimal frame size that is good enough
for that header and update it after the header to the real frame size.

- We could add caching for pull mode as is done in matroskademux. Pull a large
buffer and return subbuffers of this until we need to pull the next large
buffer.

- If the duration is set we should post a duration message (maybe also a tag?)

- For duration/position query we can also answer in BYTES (at least in pull
mode) and could also query upstream if everything fails

- The SEEKING query doesn't return something useful in push mode although
seeking should be supported there too.

- When seeking we currently fail if the subclass can't convert.  This is of
course not optimal, we could simply run chain until we're in the seek segment
or we could simply pull until then. The same could be done for accurate seeks
too (if subclass can't do an accurate conversion... need some flag for this).


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=518857.




More information about the Gstreamer-bugs mailing list