Hi everybody,<br>the problem that I am trying to solve is turning to a more generic one so the related discussion maybe of general interest.<br>My need started around the &quot;motion&quot; plugin but soon it became applicable to its more viable alternative too - the &quot;motiondetector&quot; plugin.<br>
Both these plugins do perform motion detection on a video stream, both signaling with a similar message the motion detected/undetected status change.<br>I was looking for, at least, one of the following features implemented via gstreamer plugin or app, on the basis of the &quot;motion detected&quot; status:<br>
<br>a) being able to only filter out video frames where motion is detected, resulting in a rebuilt continuous video stream (hopefully with no still frames).<br>Maybe an example for this is the audio &quot;cutter&quot; filter.<br>
<br>b) writing out a different video file/stream whenever the &quot;motion detected&quot; status does change, in the same fashion that multifilesink does<br><br>One of the first tries in order for b) was to modify the multifilesink code in order to cut output files on the &quot;motion detected&quot; status change.<br>
A skeleton pipeline for this could be <br>        filesrc ! \<br>        (video decoding elements) ! \<br>(x)    motion ! \<br>        (video encoding elements) ! \<br>(y)    multifilesink<br><br>Please tell me if wrong, I understood that only a gstreamer application building a pipeline can notify (y) on the basis of a message from (x), <br>
so in order for b) writing a plugin derived from multifilesink won&#39;t suffice. <br>Now I am trying to write a gstreamer application, I was able to build up the pipeline and manage a bus callback for the &quot;motion detected&quot; message,<br>
but I think I will take a break in writing unuseful code... :)<br><br>I believe however that my approach is applicable to any plugin, other than motion detection related, that performs an analysis on the video stream<br>resulting in assigning a boolean value to each frame passed. The final sink implementing a) or b) could be far down the pipeline.<br>
To me it seems a quite generic problem, name it &quot;boolean event filter&quot; e.g., so I guess there could be solutions around... any ideas ?<br>Thanks everybody for the interest,<br><br>Bye<br><br>