Re: Re: Question for Arpi :)

On Fri, Jul 25, 2003 at 01:05:27PM +0300, Andriy N. Gritsenko wrote:
>     Hi, Arpi!
> 
> Sometime (on Thursday, July 24 at 19:37) I've received something...
> [.......]
> >Differences in video filters:
> >=============================
> >By default, everything works the same way as in G1, except that put_image
> >won't call next filter's put_image directly, but return the dmpi.
> >So, instead of 'return vf_next_put_image(vf,dmpi);' you have to write
> >'return dmpi;' now. And, isntead of 'return 0;' you write 'return NULL;'.
> 
> >Additionally, filters also have a 'drop' parameter, to allow frame
> >dropping at filters. By default you can ignore this flag, your put_image()
> >won't be called when drop!=0.
> 
> >Let's see the non-default case now:
> >Your filters may set 2 special flags to control frame dropping:
> 
> >// filter wants process_image() to be called with mpi=NULL for dropped frames
> >#define VFCAP_NOTIFY_DROPPED_FRAMES 0x2000
> 
> >// filter wants to see all frames, even if we want to drop them...
> >// (so you can't drop frame above this filter)
> >#define VFCAP_WANTS_DROPPED_FRAMES 0x4000
> 
> >As you can see, the 'drop' flag has effect only with VFCAP_WANTS_DROPPED_FRAMES.
> >These flags will allow filters to be notified about dropped frames, it's
> >required for pattern-matching (like inverse telecine) filters and temporal
> >postprocessing filters.
> 
>     Hmm, I've analyzed the sources and didn't get it at all. If we call
> vf_process_image(vf_last,0) for bottom filter (vo or muxer) then any
> filter could not get parameter drop as 1. If we call vf_process_image
> with drop=1 (well, we are about to drop this frame) then again, we never
> can let filter with VFCAP_WANTS_DROPPED_FRAMES get frame if we dropped it
> above, because if some filter above drop frame it will return mpi==NULL.
> So I can see how flag VFCAP_NOTIFY_DROPPED_FRAMES works but flag
> VFCAP_WANTS_DROPPED_FRAMES will work only if no filter above could drop
> frames. But if there is no filter above which could drop frames then that
> flag has no sence - filter with VFCAP_WANTS_DROPPED_FRAMES will _always_
> get _all_ frames already. :)
> 
>     So, example: we have demuxer->filter1->filter2->muxer chain. Filter1
> may drop frames, filter2 has both flags VFCAP_WANTS_DROPPED_FRAMES and
> VFCAP_NOTIFY_DROPPED_FRAMES. Then we have next choises:
> 
> 1) muxer wants to drop that frame: drop==1. Filter2 may get the frame or
> NULL (if filter1 has VFCAP_NOTIFY_DROPPED_FRAMES too).
> 2) muxer doesn't force to drop that frame: drop==0. Filter1 wants that
> frame be dropped. Filter2 will get NULL as mpi.
> 3) drop==0, filter1 doesn't drop the frame. Filter2 will get the frame.
> 
>     So as you can see, VFCAP_WANTS_DROPPED_FRAMES has no effect at all.
> May be you have to modify vf.c:vf_process_image() function and get that
> behavior you mentioned above?
>     Moreover, no filter with VFCAP_NOTIFY_DROPPED_FRAMES will be notified
> about dropped frames when drop==1 and no VFCAP_WANTS_DROPPED_FRAMES for
> that filter or below, see your source.

I don't know the exact answer to your question, but remember, the
chain runs *backwards*!! It's not a simple one-filter-calles-the-next
thing like in g1; the calling app has a complicated loop for calling
the filters. So my first guess (without reading your question in
detail) would be that Arpi is right. :)

Rich