GNOME Bugzilla – Bug 797333
videoscale cannot change interpolation method
Last modified: 2018-11-03 12:11:24 UTC
Created attachment 374032 [details] example code in python In a python demo program, I wish to demonstrate various interpolation methods on low resolution video using menu commands and/or keypresses. This requires changing the interpolation method. For this I use calls like self.videoscale.set_property("method", 'nearest-neighbour') They seem to have not effect whatsoever. The property seems to be set properly (can be read back using get_property) but is otherwise ignored. This code was written a long time ago and I think it worked under an older version of gstreamer/pygi (not sure which one; this was many years ago) Code is attached. Use the menus to change between methods.
Created attachment 374033 [details] glade file accompanying the python code
You have to restart the pipeline. videoscale at least has to be set back to the READY state to notice the change of the property. This could be changed though. Do you want to work on a patch for that? Similarly, other property changes are only applied when going from READY to PAUSED.
What would be the proper way to restart the pipeline? Simple code (in a GUI callback) like self.pipeline.set_state(Gst.State.READY) self.videoscale.set_property("method", 'nearest-neighbour') self.pipeline.set_state(Gst.State.PLAYING) or self.pipeline.set_state(Gst.State.NULL) self.videoscale.set_property("method", 'nearest-neighbour') self.pipeline.set_state(Gst.State.PLAYING) does not work, perhaps because you have to wait for the state transition to actually occur. I have debugged gstreamer in the past, so I know how to do it. However, this was a long time ago, so my knowledge is rusty, and obviously things have changed as this old code no longer works. I have too little time in the next months, but perhaps in 2019...
Both do not work? Also you have to set the property as an enum, it's not a string.
I believe that your statement about the enum is incorrect, as the python interface handles this conversion. In the code below I read the property before and after setting it. You can see from the output that it has actually set an enum value self.pipeline.set_state(Gst.State.NULL) print 'NN BEFORE', self.videoscale.get_property("method") self.videoscale.set_property("method", 'nearest-neighbour') self.pipeline.set_state(Gst.State.PLAYING) print 'NN AFTER', self.videoscale.get_property("method") Disregarding the first error message (the usual gtk problems) below, the value change can be seen in the lines "NN BEFORE" and ""NN after". Also, the last line shows that the way of disabling the pipeline does not work properly. The video freezes at this point. The same thing happens with Gst.State.READY instead of Gst.State.NULL (test.py:26337): Gtk-CRITICAL **: gtk_container_propagate_draw: assertion '_gtk_widget_get_parent (child) == GTK_WIDGET (container)' failed NN BEFORE <enum Bilinear (2-tap) of type __main__.GstVideoScaleMethod> NN AFTER <enum Nearest Neighbour of type __main__.GstVideoScaleMethod> ('on_error():', (gerror=GLib.Error('Internal data stream error.', 'gst-stream-error-quark', 1), debug='gstavidemux.c(5770): gst_avi_demux_loop (): /GstPipeline:pipeline0/GstBin:bin0/GstDecodeBin:decodebin0/GstAviDemux:avidemux1:\nstreaming stopped, reason not-linked (-1)')) I will attach a log file with GST_DEBUG=4 for the case where I set the pipeline state to READY There is some info on how to properly restart here: http://gstreamer-devel.966125.n4.nabble.com/Restart-Pipeline-td4685703.html but honestly, it seems quite complicated and I wonder if this is the right approach.
Created attachment 374063 [details] GST_DEBUG=4 setting pipeline state to READY and then PLAYING leads to error
-- 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-base/issues/498.