We should not be finding GStreamer issues right around release time but that's what we seem to do. Let's see if there are low hanging fruit in automated testing that would allow us to catch at least some issues as they are merged. Some potential tooling: https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-validate/html/ I believe for core gstreamer there are test suites already, we'd just want to choose what to run and when (and then keep the expected results updated). Doing automated testing with e.g. gstreamer-vaapi would be best but testing hardware acceleration on VM can be a little tricky... Even then, a script that QA or developers could run that gave gst-validate like output would be useful.
Forgot the repo links: git://anongit.freedesktop.org/gstreamer/gst-devtools git://anongit.freedesktop.org/gstreamer/gst-integration-testsuites
Moving gstreamer bugs to Anuj.
Ee Peng, can you please evaluate the current tests that we have and see if we can use test-suites available here for runtime testing? I think that we might not be able to test vaapi codecs for the bsp testing using this without changing some of the code to have default codec changed. gstreamer-vaapi does provides some tests which can be built & enabled but they need manual inspection, there's no image comparison to enable automated testing.
We developed some gstreamer CLI tests back in the Intel Ref Kit. Need to try porting this tests to poky. https://github.com/intel/intel-iot-refkit/blob/master/meta-iotqa/lib/oeqa/runtime/multimedia/gstreamer/gstreamer_cli.py
Porting tests from Intel Ref Kit. http://lists.openembedded.org/pipermail/openembedded-core/2018-November/157437.html
http://lists.openembedded.org/pipermail/openembedded-core/2018-November/157445.html