[MPlayer-users] Re: mplayer screen snapshots
D Richard Felker III
dalias at aerifal.cx
Tue Nov 4 05:19:32 CET 2003
On Mon, Nov 03, 2003 at 06:52:41PM +0100, Samuel Kvasnica wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> Ok, so I hacked it and got the feature. Took me almost a day since the
> mplayer.c is such a disgusting piece of code with deep pointer forest
> and globals, great example how not to write C programs. In a fact, the
> implementation cries for C++, it would cost at most 10%overhead but the
> code would be much more readable. But enough swearing.
Um, no. With C++ it would be 100x more unreadable, and slower too.
What it cries for is a clean rewrite, aka MPlayer G2, in a clean
language, aka C.
> I have now mapped 's' key for snapshot and 'snapshot' cli command for
> '-slave' mode. I just created a secondary video output snapshot_out
> which is using vo_jpeg, vo_png etc. and coresponding sh_snapshot and
> call decode_video() second time using sh_snapshot. swscaler is initd
> automatically. Works great for me. I still have to add an cli option to
> select the snapshot format e.g. -grab jpeg and maybe option for output
> file name which would allow for stdout output - important for -slave
> operation.
>
> Should I submit a patch ? In my case this feature is extremely
> important. Imagine you are watching live raw video e.g. CCD on
> microscope and want just to shot a picture when you find something
> interesting - not to save the whole video and look for pictures
> afterwards. The reason I decided to misuse mplayer is that it understands
> plenty of raw video format, filters etc.
I agree this would be a useful feature. The way you're doing it is
something of an ugly hack (from what I understand the filter chain
will miss a frame, which will mess up filters that want to see every
frame), but for the sort of purpose you're thinking of it seems ok.
If possible, could you make it attach the vo_jpeg (or whatever) onto
the end of the existing video filter chain? Maybe that's what you're
already thinking of. It would work a lot better, IMO. Another option
is to make a filter that captures a frame going through it and writes
that frame to disk, and have that filter sit by idle until the main
program signals it to capture.
Rich
More information about the MPlayer-users
mailing list