After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 768666 - motioncells: motionmaskcoords does not work on start
motioncells: motionmaskcoords does not work on start
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal normal
: 1.13.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-07-11 11:14 UTC by Dmitry Zhadinets
Modified: 2017-05-18 11:48 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
fix for 1.8.3 (4.23 KB, patch)
2017-05-07 19:50 UTC, Dmitry Zhadinets 		none Details | Review

Description Dmitry Zhadinets 2016-07-11 11:14:19 UTC 
Example pipeline:
gst-launch-1.0 videotestsrc pattern=18 ! videorate ! videoscale ! video/x-raw,width=320,height=240,framerate=15/1 ! videoconvert ! motioncells motionmaskcoords=0:0:100:100 ! videoconvert ! glimagesink

motionmaskcoords is not applied on start because gst_motion_cells_handle_sink_event will come after gst_motion_cells_set_property. and at the moment of set there is no information about resolution. and initial mask is set as -1:-1:-1:-1
Comment 1 Dmitry Zhadinets 2017-05-07 19:50:08 UTC 
Created attachment 351313 [details] [review]
fix for 1.8.3

Should work on master, Need to check
Comment 2 Jan Schmidt 2017-05-18 11:48:06 UTC 
Thanks, pushed to master:

commit f0a75cf0294072c93be35b9c16ac7be591986fa8
Author: Dmitry Zhadinets <dzhadinets@gmail.com>
Date:   Sun May 7 19:50:00 2017 +0000

    motioncells: delay motionmaskcoords until caps arrive
    
    motionmaskcoords is not applied on start because the information
    about resolution isn't available until caps arrive.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=768666


There's still a slight limitation in that the mask might not be correct if incoming caps changes, but it's no worse in that regard than the previous code, so it's only a possible enhancement.