[Bug 650093] New: [baseparse] GstBaseParseFrame extensibility/flexibility needed

[GStreamer (bugzilla.gnome.org)]

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

           Summary: [baseparse] GstBaseParseFrame
                    extensibility/flexibility needed
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: mnauw at users.sourceforge.net
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


As it stands currently, GstBaseParseFrame is a pretty boxed/static/independent
type, whereas actually more something like GstCollectData relative to
GstCollectPads would be useful/needed.

In particular, subclass should be able to store some parsing state of its own
in a frame which it can use across subsequent invocations.  This is
particularly useful/needed for e.g. current h264parse which keeps (a.o.) track
of last start code position (to resume scanning from that mark).  This is
currently tracked globally in h264parse itself and usually works, but it
may/will actually go wrong if some seek or otherwise repositioning occurs that
disturbs the expected callback sequence and leads to parsing new data with
stale state (e.g. last scan mark).

This might be handled by allowing to register an extended GstBaseParseFrame
size along with some DestroyNotify, InitNotify and/or CopyNotify for a
GstBaseParseFrame, but that would lead to a GstBaseParseFrame with "multiple
faces".

Failing such to be possible, quite some typical subclass cases (e.g. h264parse)
would end up with a lot more complicated (and less efficient) parsing code that
would have to repeatedly start from scratch and parse all over again.

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