>> Based on my analysis, I don't think it will work
>> very well to encapsulate detect and transform. I
>> think we should simply combine the detect and
>> transform filters into a single filter. In
>> "vid.stab.detect", you used a clever trick to
>> rename "mlt_service" to "vid.stab.transform" so
>> that running melt with the MLT XML will cause the
>> transform filter to be used on the second pass.
>> This is a very clever use of properties, but it
>> only works for the two-pass melt method and isn't
>> friendly for an application which will keep an
>> instance of the detect filter and re-run that.
>> Also, changing the "mlt_service" property is not
>> a precedent we want to set.
>> The new filter name could be "vidstab" (notice there
>> is no "eo"). The behavior should be the same as the
>> "videostab2" filter.
>> Jakub,
>> Would you be willing to combine the detect and
>> transform filters? If not, I should be able to
>> get around to it in the next week or so.
> Sure, I can do it. I've already got an idea to add
> an if() to process_filter functions, so it would look like:
>
> if(there are no vectors) {
> mlt_frame_push_get_image(frame, get_image_and_detect);
>
> } else {
> mlt_frame_push_get_image(frame, get_image_and_transform);
>
> }
Yes, that should be all it takes to make it work.
>> Also, the deshake filter looks good. But it will
>> provide strange results when seeking because it
>> will be using information from frames that do not
>> immediately proceed the frame being processed. It
>> might be a good idea to detect seeking and call
>> clear_deshake(). I'm willing to commit the module
>> without this change, but I thought I would mention it.
> Hmm, there is a "refresh" property that controls when the
> stabilization data should be reset. Wasn't it supposed to
> be used in cases like seeking, etc.?
The "refresh" property is OK in cases where the application is changing a
filter parameter because it knows what filter it is operating on. But it does
not work well for seeking because the application may now know what filters are
attached to a producer it is seeking on. Some services check for parameter
changes with each processed frame to avoid "refresh" type properties.
> However, clearing this data won't help much, as in your
> case it is almost impossible to always get the same
> transformation without knowing backward frames. Almost,
> because there is a possibility to save frames while
> playing, so they could be replayed by the filter when
> necessary.
I understand your point - that a seeked frame will not receive the same
transformation is it would if its predecessors were played before it. My
thinking is that in the case of seeking, it might be more visually appealing
for the filter to restart on the new frame with no vectors, rather than some
random vectors from some completely unrelated frames. It's a minor nit for your
consideration.
~Brian
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
