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 *);