[Bug 739165] New: debugutils: Truncate parameter values that are too long

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Sat Oct 25 05:13:32 PDT 2014


https://bugzilla.gnome.org/show_bug.cgi?id=739165
  GStreamer | gstreamer (core) | unspecified

           Summary: debugutils: Truncate parameter values that are too
                    long
    Classification: Platform
           Product: GStreamer
           Version: unspecified
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: arun at accosted.net
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


I think this makes sense to have because we often have properties that are
very long and make the debug dump hard to read (RTP, codec_data, ...).

I've made this unconditional in this patch, but we probably want to control
this via GstDebugGraphDetails. Unfortunately that enum is not extensible, so
the options I see are:

1. Add a GST_DEBUG_GRAPH_SHOW_REALLY_ALL or something like that which is a
   '-1' value, making it future-proof. Then we can have something to control
   printing properties or truncating as a new flag. We could adjust this enum
   in the next API break and replace _REALLY_ALL with just _ALL.

2. Add a new flag after GST_DEBUG_GRAPH_SHOW_ALL. In this case, either we'd
   either have to have truncated as a default and the flag as an enabler for
   full output making the _ALL value not actuall be _ALL, or we'd have to have
   the flag after _ALL be a disabler and have it on by default (and any future
   additions would also have to be disablers, not enablers).

I prefer the first to the second because I think truncation (or even disabling
properties) is a sensible default over printing them out.

Opinions and other options welcome. :)

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


More information about the gstreamer-bugs mailing list