[MPlayer-dev-eng] filter policy clarification / suggestion

[Michael Niedermayer]

Hi

On Fri, Oct 27, 2006 at 02:55:34AM -0400, Andrew Mahone wrote:
> This issue came up in a discussion on the users mailing list (thread
> archive: 
> http://archives.free.net.ph/thread/20061027.015323.2c78707d.en.html).
> I did not find any clear statement in DOCS/tech regarding filters
> interacting with components outside of mplayer, and there are several
> which already do so (divtc have a two-pass mode using a file, export
> provides access to the decoded audio stream via an mmapped file). I
> understand that the tcdump filter is an ugly hack, and that the right
> way to solve that particular problem is in mencoder's muxer, but I am
> not sure that "no external files" is a good policy in general.
> 
> I can see two legitimate uses for external files in filters:
> 1) two-pass filtering - to store data from a previous run, for more
> accurate output in a subsequent run
> 2) video analysis - tasks such as those performed by blackframe and 
> cropdetect
> 
> I do not think that the first case can be easily solved without a
> logfile managed by the filter itself, as mplayer/mencoder may not know
> what information the filter will need to store between runs, and may
> not know how best to store or index that information (a filter may
> need per-frame statistics, or just a very sparse list of frame or pts
> indexes at which specific events occur). Blackframe and cropdetect use
> mp_msg, but when there will be a large volume of such information, as
> in the case where information about each frame is logged, it seem to
> me more appropriate to use a user-specified file. This may even be a
> necessity, if there is a good reason to use two instances of such a
> filter.
> 
> If the majority of developers are determined that there is never any
> good reason for a plugin to access a file, then I feel that this
> policy should be documented in DOCS/tech, probably in libmpcodecs.txt.
> I believe, however, that a blanket policy is not the best thing for
> mplayer users, and that discretion should instead be exercised in
> determining whether a proposed filter has a good reason for such
> access.

i see no reason or sense in completely forbidding external file usage
in filters, 
storing and loading specific frames from a rawfile or pipe could be
used for building non linear filter chains with the current filter 
system, combined with vf_geq this would allow pretty interresting stuff

for dumping timestamps, crop coordinates and such though i am against
using fopen() fwrite() in a filter
there also is no issue with multiple instances, just prefix the messages
by the filter context pointer [0xDEADBEEF] style its guranteed to be unique

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is