On Sat, Oct 20, 2012 at 8:08 AM, j-b-m <[email protected]> wrote: > On Friday 19 October 2012 22:19:18 Dan Dennedy wrote: >> On Fri, Oct 19, 2012 at 6:15 PM, j-b-m <[email protected]> wrote: >> > On Friday 19 October 2012 16:49:59 Dan Dennedy wrote: >> >> On Fri, Oct 19, 2012 at 2:46 PM, j-b-m <[email protected]> > wrote: >> >> > Hi, >> >> > >> >> > Following a feature request in Kdenlive (1), I tried to make a few >> >> > changes >> >> > to >> >> > the motion_est filter to allow the detection of scene changes in a >> >> > clip. >> >> > >> >> > I made 2 changes to the filter: >> >> > >> >> > 1 - add a geometry property "bounding" allowing to process filter on a >> >> > part of the image only to speed up processing >> >> >> >> ok >> >> >> >> > 2 - Store the scene changes frame positions in a "_scene_cut" property >> >> > that can later be retrieved by the application >> >> >> >> Why hide the property with the leading underscore? If it is not >> >> hidden, the someone using melt can use this to serialize the result to >> >> XML for processing the results. Also, the name should perhaps be a bit >> >> more consistent with the existing "shot_change" >> >> >> >> Also, for the value, it looks like you are you are making a list of >> >> frame numbers using a colon delimiter. Hmm.. there might be a case to >> >> get these as time values (i.e. clock or timecode) in the future. Also, >> >> there might be a case for making the list format more consistent with >> >> geometry keyframing where semi-colon is the delimiter. You could then >> >> use mlt_geometry to construct this value instead of this ad hoc code. >> >> An app could use mlt_geometry to parse it as well. Then, when >> >> mlt_geometry is refactored into mlt_properties and a new mlt_rect >> >> type, it will gain support for time values. >> > >> > Ok, here is an updated version, trying to use mlt_geometry. >> >> Now for the second part: the shot_change_list property. mlt_geometry >> can be kept in a data property and reused each iteration, and we can >> set the serializer in case someone ones to get the property as string >> (an app can get it as a geometry and use Mlt::Geometry). But first I >> have to include this bugfix on mlt_geometry_serialise() :-\ You will >> notice the first geometry item has some bogus values; that is an ill, >> but harmless side-effect of mlt_geometry for now. >> >> diff --git a/src/framework/mlt_geometry.c b/src/framework/mlt_geometry.c >> index c4d989f..301963d 100644 >> --- a/src/framework/mlt_geometry.c >> +++ b/src/framework/mlt_geometry.c >> @@ -689,7 +689,7 @@ char *mlt_geometry_serialise( mlt_geometry self ) >> free( g->data ); >> g->data = ret; >> } >> - return ret; >> + return strdup( ret ); >> } >> >> // Close the geometry >> diff --git a/src/modules/motion_est/filter_motion_est.c >> b/src/modules/motion_est/filter_motion_est.c >> index a74bec7..aaf550f 100644 >> --- a/src/modules/motion_est/filter_motion_est.c >> +++ b/src/modules/motion_est/filter_motion_est.c >> @@ -952,10 +952,30 @@ static int filter_get_image( mlt_frame frame, >> uint8_t **image, mlt_image_format >> if( c->comparison_average > 10 * c->mb_w * c->mb_h && >> c->comparison_average > c->previous_msad * 2 ) >> { >> - fprintf(stderr, " - SAD: %d <<Shot change>>\n", >> c->comparison_average); + mlt_properties properties = >> MLT_FILTER_PROPERTIES( filter ); >> + mlt_log_verbose( MLT_FILTER_SERVICE(filter), "shot >> change: %d\n", >> c->comparison_average); >> mlt_properties_set_int( MLT_FRAME_PROPERTIES( frame ), >> "shot_change", >> 1); - // c->former_vectors_valid = 0; // Invalidate the >> previous frame's >> predictors c->shot_change = 1; >> + >> + // Add the shot change to the list >> + mlt_geometry key_frames = mlt_properties_get_data( >> properties, >> "shot_change_list", NULL ); >> + if ( !key_frames ) > > > Ok for me, but it seems like the scene detection will be done on every run of > the filter, which is I think not the best.
I agree in principle, but I think that is easier said than done. I do not see anything in the original filter that toggles the processing. One way to do this is to add another property to tell the filter whether to be active or not, not just whether to update shot_change_list. Updating the shot_change_list is very inexpensive compared to the motion estimation. > In my version, it only filled the "shot_change_list" property if the property > was initialized at the filter startup. what? where? how? I completely fail to see how you can process all of the frames on only the first call to filter_get_image() > Otherwise, you can commit whenever you want, I am ready for the feature on the > Kdenlive side. > > regards > jb -- +-DRD-+ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Mlt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mlt-devel
