[Bug 738123] New: validate: Design and implement an interface for setting a report level.

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=738123
  GStreamer | gst-devtools | git

           Summary: validate: Design and implement an interface for
                    setting a report level.
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: Normal
         Component: gst-devtools
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: mathieu.duponchelle at epitech.eu
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


This first comment will not deal with implementation details.

Problem:

Currently, the output of gst_validate_runner_printf is
    * Too verbose, even though the subchain issue concatenation implemented
      at https://bugzilla.gnome.org/show_bug.cgi?id=735665 will partly solve
      that situation.
      Some tests in the GES validation suite report over 600 issues, trimmed
down
      to 200 by the subchain concatenation, but that's still thousands of lines
that
      a normal human brain such as mine is not prepared to parse.
    * Not configurable.
      When trying to validate a single element, the user should not have to dig
in the
      reports to find the ones related to that element.
      Aside from that, validate currently concatenates issues that have the
same type
      inside an element, as part of the "no-flooding" effort. However, in
certain situations,
      the user might want to see all these reports, for example if the element
pushes
      10 buffers after it pushed an EOS, he/she might want to have informations
about all
      these buffers, their timestamps et caetera.

Use case:

The user wants to validate the behaviour of an arbitrary object.
Validate should provide a way to let the user specify:
    * "please give me a report about the issues this object has in a synthetic
way,
      and don't talk to me about the rest of the pipeline, that's not my
problem".
    * "please give me a detailed report about the issues this object has, and
provide
      me with a synthetic report of the issues of the pipeline it's contained
in"

This object can be a bin, an element or a pad. It can be specified by name or
by type
(h264parse / my_h264_parser_12)

Proposed solution:
    An environment variable akin to GST_DEBUG, and API so that this can be set
    on the fly, for use in scenarios for example.

    four possible levels of reporting, applicable globally or per object:
    * none: no report at all, useful in combination with a per-element
reporting level
    * synthetic: Summary of the distinct issues found, with no details:
        In the global case:
            warning: buffer was received after EOS
            Detected X times on <audioconvert6:sink, audioconvert6:src,
audioresample7:sink, audioresample7:src, smart-adder-adder:sink_2>
            Detected X times on <audioconvert7:sink, audioconvert7:src,
audioresample8:sink, audioresample8:src, smart-adder-adder:sink_2>
            Description : a pad shouldn't receive any more buffers after it
gets EOS
        In the per-object case:
            warning on <object>: a pad shouldn't receive any more buffers after
it gets EOS, detected X times.
    * subchain:
        In the global case, same behaviour as with the patches in
https://bugzilla.gnome.org/show_bug.cgi?id=735665, ie distinct issues
        on different subchains / pads are reported, for example:    
            warning: buffer was received after EOS
            Detected X times on <audioconvert6:sink, audioconvert6:src,
audioresample7:sink, audioresample7:src, smart-adder-adder:sink_2>
            Details: Received buffer 0xdeadbeef with timestamp 42:42:424242
after EOS.
            Description : a pad shouldn't receive any more buffers after it
gets EOS
        In the per-object case, reports the cases where an issue was first
reported on that object, for example in the above case, the issue
        will be reported if the requested object is audioconvert, but not if it
is audioresample.
    * monitor:
        In the global case, same behaviour as currently.
        In the per-object case, reports separately the cases where an issue was
noticed for an object, be this object the start of
        a chain or not. Issues still get concatenated inside the object.
    * all:
        All reports, with no intra-object concetenating. Will be extremely
verbose when set globally but ¯\_(ツ)_/¯ .

    Environment variable: GST_VALIDATE_REPORT_LEVEL, a comma-separated list of
(optional) debug categories and levels.
    No debug category means global level.
    Example:
        GST_VALIDATE_REPORT_LEVEL=synthetic,h264parse:all

    API: gst_validate_set_report_level_from_string (const gchar *);

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