[Bug 773463] core(debug): hard to distinguish related log at multi-instance env

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=773463

--- Comment #11 from Thibault Saunier <tsaunier at gnome.org> ---
(In reply to Tim-Philipp Müller from comment #10)
> Instead of this "magic" debug category I would suggest a parameter to the
> GST_DEBUG_OPTIONS env var.

Definitely a good suggestion, I did not know about the var.

> I only quickly glanced at this patchset, but I'm not really sure whether I
> like this approach. Not that I have a thought-through alternative proposal
> yet though :)
>
> I understand the feature request though and think it's a valid request
> that'd be good to solve in some way.
> 
> I'm rambling here now, but something I've been thinking of is that it might
> be easier to implement and more flexible in general if we simply relied on
> tools (log viewers) to do some postprocessing to enable this kind of thing.
> We still need to make that info available for tools of course. We could have
> global sequence numbers for all objects and then simply refer to the objects
> by number, and whenever their state changes we simply log that in reference
> to their number.

Hrm, I am not convinced we want to 'force' people to use gst-debug-viewer to
view their logs, though a post processing script which will just update file or
something could make sense but I am really not convinced :)

> Also means we don't have to take that lock constantly
> everywhere (which your patch also seems to do for the case where we want the
> old print behaviour).

No lock is needed if the feature is not activated (updating the patch to make
sure of this does not happen).

> We have a similar/related problem in bug #761916 btw (similar in terms of
> what an implementation needs to cater for).

My approach can solve this other issue quite nicely fmpov (would need an extra
flag on the object to tell that in all case we should keep track of the parent
name in the representation of the object).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.