[gstreamer-bugs] [Bug 323693] [PATCH] [lame] accept track-count tag

[GStreamer (bugzilla.gnome.org)]

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=323693
 GStreamer | gst-plugins-ugly | Ver: HEAD CVS


malsyned at uofr.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |malsyned at uofr.net




------- Comment #3 from malsyned at uofr.net  2005-12-30 09:29 UTC -------
Ooh, I hadn't thought of that.  It actually would work, so long as all the
instances ran in the same thread.  If the two elements could be executing
concurrently, though, they could smash each others' trackNumInfo.  I'll look
into making it thread-safe in the next couple days.  I wasn't really happy with
having to use a global structure anyway.  The data only needs to exist for the
duration of the call to gst_lame_set_metadata, but I didn't see an easy way to
get it to be local to that stack frame and available to gst_lame_set_track and
gst_lame_set_trackcount, whose one argument was already used up by the
lame_global_flags pointer.

Would a palatable solution be to wrap the lame_global_flags pointer in another
struct that included the track info, and then wrap all of the lame id3tag_*
functions with simple wrappers that pulled that pointer back out again?

(It's 4:30am, so I appologize if I've made less than perfect sense.  I'll look
at this with fresh eyes later.)


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