[MPlayer-G2-dev] Re: Question for Arpi :)

[Andriy N. Gritsenko]

    Hi, D Richard Felker III!

Sometime (on Friday, July 25 at 19:36) I've received something...
>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. :)

    Thank you, but I already know that. :)  Chain runs backwards until it
get the frame, after that it runs forwards through all chain (see that
function vf_process_image() in vf.c) - but some filter may drop the frame
to NULL. Read my example above, please. If you still don't believe then
create test filter and run it with gdb. :)

    With best wishes.
    Andriy.