GNOME Bugzilla – Bug 722877
intervideosrc/intervideosink: cannot change channel while in playing state
Last modified: 2018-11-03 13:20:22 UTC
Once the intervideosrc and intervideosink elements are in the playing state, changing the channel property does not have any effect on their behavior. The elements must be moved to null and then back to playing for the channel behavior to change.
Created attachment 279309 [details] [review] Test and patch for inter element channel change while playing
Review of attachment 279309 [details] [review]: ::: gst/inter/gstintertest_change_sink_channels @@ +1,1 @@ +#! /bin/bash This entire file should not have been committed, it should be in .gitignore. ::: gst/inter/gstintertest_change_sink_channels.c @@ +10,3 @@ +//#define GETTEXT_PACKAGE "intertest" + + I'm tempted to think that this should be an automated tests in tests/check/elements/interaudio.c .. using libcheck. ::: gst/inter/gstintertest_change_src_channels @@ +1,1 @@ +#! /bin/bash same thing here
*** Bug 732258 has been marked as a duplicate of this bug. ***
Created attachment 279489 [details] [review] Updated patch removing generated scripts
I think I agree about moving the test programs to automated tests. I had put them in with the elements since the existing inter code had a similar test there already. I can look into rewriting them to use libcheck if that's the way they're supposed to be executed.
We have some stand-alone tests in tests/icles/ , but if possible at all we prefer automated tests based on libgstcheck in tests/check/elements/ or so. The automated checks are run much more often, so they're more useful in a way.
I've been trying to write a test, and thought I was getting close to having the basic check framework in use, but I'm pulling out my hair getting anything out of the inter objects using a straw pipeline (https://gist.github.com/superlou/c3955431f71eb5766b4c). When I run line 62-63, I get a bunch of 0x10 and 0x80 values at the terminal, but when I run line 64, I see a more proper pile of random numbers (videotestsrc pattern 1 should be white noise). If I launch "gst-launch-1.0 videotestsrc pattern=1 ! intervideosink intervideosrc ! xvimagesink name=sink", I see noise in the xvimage sink, but if I run the test, with an xvimagesink instead of a fakesink, I only see black, which at least agrees with the buffer data. Can inter elements not be used with straw pipelines?
Any suggestions on writing tests for this or updates on the inter plugins making this obsolete?
Still waiting on recommendations for automated testing. Is it possible to consider accepting this as is with the manual tests?
Yes it can be accepted with manual tests/examples. Git master is currently frozen for the 1.6 release, so this can only be merged once 1.6 has released (ideally ping again on the bug after that). As for automated tests, you could just add a pipeline with: videotestsrc pattern=red ! video/x-raw,format=RGBx ! intervideosink channel=red videotestsrc pattern=blue ! video/x-raw,format=RGBx ! intervideosink channel=blue intervideosrc channel=red ! pad/appsink/fakesink and then you check if the pixels in the buffer have the expected colour, then you switch the channel at runtime and check the colour of the pixels afterwards.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/128.