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

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=738124
  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 concatenating. 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.