[Bug 667352] [0.11] misc core API/bug comments/nitpicks

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=667352
  GStreamer | gstreamer (core) | 0.11.x

Wim Taymans <wim.taymans> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wim.taymans at gmail.com

--- Comment #3 from Wim Taymans <wim.taymans at gmail.com> 2012-02-14 09:29:06 UTC ---
(In reply to comment #0)
> Collecting a number of odd things/behaviour that pop up when browsing 0.11
> core; maybe they are bugs, maybe as it is supposed to be.
> 
> * memory/buffer:
> - no checking on modifying size in _unmap

The resizing feature was removed from unmap.

> - a number of operations on _buffer can be tricky with an outstanding _map
> (notable removing a memory range, or performing another _map); no checking
> though

The outstanding _map now keeps a ref to the memory object so it can't go away
when buffer operations remove the memory for some reason. Nested mappings are
now allowed and refcounted. You can only do a nested mapping with the same
mode.

> - what is to happen upon release/free with an outstanding _map (allowed or not,
> automagic stuff ?); no doc or sanity checking

Unreffing the memory with an outstanding _map will cause an assertion and is
not allowed. Since the buffer map keeps a ref to the memory objects, you can't
unref the memory while mapped.

> - some adapter operations with outstanding _map can be likewise tricky (most
> notably another _map, _flush or _clear); see also bug #664133.

the adapter now keeps the state of the last map operation and automatically
unmaps when the state would become invalid (_clear, _flush etc). It's not as
nice but it should work.

> 
> * (sticky) event:
> - order of serialized events not preserved;
> a sticky event could be received, not sent downstream and stored, and then a
> subsequent event is sent directly downstream without sending the stored first

I will check how this is suppposed to work (looking at the code it seems like
sticky events are not pushed before the new event)

> * a FLUSH_STOP does not clear any sticky event, so the latter can turn up after
> a flush, which seems to be very (too?) sticky

FLUSH_STOP clears the EOS event. Removing segment events is not really needed,
the next segment event after the flush will replace the old one. All other
events can probably stay on the pad.. 

> * when a sticky event is stored, it replaces the currently stored of same type,
> and as such it will also be sent in order of the "old event", rather than
> current/new order

While this is true, it never causes events to go into a 'wrong' order, you'll
always have STREAM_START, CAPS, STREAM_CONFIG, SEGMENT, ..., EOS in that order
(unless the element sends out the events in the wrong order when starting, we
don't enforce that)

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