[gstreamer-bugs] [Bug 413418] New: Make GstAppSrc better
GStreamer (bugzilla.gnome.org)
bugzilla-daemon at bugzilla.gnome.org
Thu Mar 1 04:03:26 PST 2007
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=413418
GStreamer | gst-plugins-bad | Ver: HEAD CVS
Summary: Make GstAppSrc better
Product: GStreamer
Version: HEAD CVS
Platform: Other
OS/Version: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: gst-plugins-bad
AssignedTo: gstreamer-bugs at lists.sourceforge.net
ReportedBy: julien.puydt at laposte.net
QAContact: gstreamer-bugs at lists.sourceforge.net
GNOME version: Unspecified
GNOME milestone: Unspecified
Here are a few remarks of things I noticed when reading the source code :
(1) the header lacks G_BEGIN_DECLS/G_END_DECLS
(2) are the inclusion of config.h, unistd.h, fcntl.h and string.h needed?
(3) the app_src_details are incomplete ("FIXME")
(4) are the enum, gst_app_src_get_properties and gst_app_src_set_properties
needed if there are no properties ?
(5) the ->mutex, ->queue and ->cond are destroyed in dispose : shouldn't it be
done in finalize ? And by the way, shouldn't something be done with the ->caps?
(6) in gst_app_src_unlock, ->unlock is accessed and the condition variable
signalled without holding the mutex : shouldn't it hold the mutex ?
(7) in gst_app_src_unlock, wouldn't it be safer to broadcast the condition
variable (although the current state of the code makes me think signal is
enough)
(8) in gst_app_src_create, shouldn't ->caps be tested for NULL before use ?
(9) if that class is to be used by a program not based on GStreamer, shouldn't
it have a method
void gst_app_src_push_data (GstAppSrc *appsrc,
gpointer data,
guint length);
which builds a GstBuffer then calls gst_app_src_push_buffer with it ?
--
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
More information about the Gstreamer-bugs
mailing list