On Saturday 20 October 2012 10:20:40 Dan Dennedy wrote: > 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()
As you said, filling the "shot_change_list" is not very expensive and since that filter is not used so much, we probably don't need to care. What I meant is that instead of using another property to trigger the processing, I was checking if the "shot_change_list" already existed, and if it didn't no updating was done. So, when we want to get the scene cut list, we call melt movie.mpg -attach motion_est shot_change_list="0" (...) But that's not important. By the way, I am currently working on making the same modification to the autotrack_rectangle so that we can retrieve the geometry of a moving object, so that we can later use it in Kdenlive. For example we could re-use this data to create keyframes for a composite transition so that a title with that composite transition would follow a moving object. regards jb ------------------------------------------------------------------------------ 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
