[gstreamer-bugs] [Bug 348085] [PLUGIN-MOVE] move spectrum to good

GStreamer (bugzilla.gnome.org) bugzilla-daemon at bugzilla.gnome.org
Mon Sep 11 11:38:02 PDT 2006


Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=348085
 GStreamer | gst-plugins-bad | Ver: HEAD CVS





------- Comment #4 from René Stadler  2006-09-11 18:37 UTC -------
(In reply to comment #2)
[...]
> - downgraded the GST_DEBUG to GST_LOG in transform_ip()

Why not GST_DEBUG_OBJECT?

> Some comment about the other changes:
> - event() is optional. see api docs. stop() gets called on EOS

Wrong.  stop () only gets called on the state change from PAUSED to READY.  If
your transformation implementation carries state between invocations, you are
responsible to clear it on EOS youself.  In this case, the data left in the
adapter is to be dropped since it belongs to the old stream.

> - gst_adapter_clear() in stop() just saves the initial gst_adapter_clear() call

This is not about saving anything, it is just more logical in stop because from
PAUSED to READY, you are supposed to give up on stream specific resources.  Why
keep it around all the time we linger in READY or NULL if we drop it when going
back to PAUSED, PLAYING anyways? Just drop it at once.

> - "GST_SECOND / 10" is easier to understand and the result is the same (its a
> constant expression that gets resolved at compile time)

Multiplying integers is always cleaner than dividing.  This is also why there
are all the GST_SECOND, GST_MSECOND, GST_USECOND, etc.  You can always pick the
unit closest to your usage (to keep it easy understandable) and just multiply.

> - g_realloc() copies the data, which we don't want

Yes I noted that afterwards.  But your assertion that we don't want it is
incorrect.  We do not _need_ it, but it won't break anything if it's moved
over.


-- 
Configure bugmail: http://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.




More information about the Gstreamer-bugs mailing list