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

[Andrew Mahone]

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.

And no, I don't think tcdump should probably be an official filter.
Dumping data that should be properly encoded in the output file
doesn't seem like an appropriate use. ;)

-- 
Andrew Mahone
andrew DOT mahone AT gmail DOT com