Re: Question for Arpi :)

"Andriy N. Gritsenko" <[email protected]>
Newsgroups gmane.comp.video.mplayer.g2.devel
Message-ID <[email protected]>
    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.

    With best wishes.
    Andriy.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.