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

[GStreamer (bugzilla.gnome.org)]

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

Rob Clark <rob> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rob at ti.com

--- Comment #6 from Rob Clark <rob at ti.com> 2010-01-16 08:14:01 UTC ---
btw, a random musing:  the handful of parsers that I've looked at so far suffer
from bad performance if the size of the input buffer is much smaller than the
size of the packet they are trying to parse..  ie. in the NEED_MORE_DATA they
keep re-parsing the accumulated data each time a new buffer arrives.  (And each
new input buffer gets pushed to an adapter, and subsequent gst_adapter_peek()
copies it into a growing buffer.. and so on.)  For an extreme example, try
running a 20mpix image thru jpegparse with default filesrc 4kb input buffers.

A couple things that would be helpful..  (1) something like GstByteReader that
could deal with a list of non-contiguous buffers to avoid the memcpy currently
happening in adapter on each new input buffers, and (2) parsers that could
operate incrementally, saving their state in the NEED_MORE_DATA case and
resuming parsing on next input buffer without having to backtrack and reparse. 
(But this second point, I'm not really sure offhand of any way to do this in a
generic way..)

anyways, I'm not really sure if that is on or off topic for this bug.. but
maybe something to keep in mind if re-thinking how parsers should work.

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