[MPlayer-dev-eng] [RFC][PATCH] repeat option for mf://

[Vladimir Voroshilov]

Hi, Ivan

2007/7/11, Ivan Kalvachev <ikalvachev at gmail.com>:
> 2007/7/11, Vladimir Voroshilov <voroshil at gmail.com>:
> > Hi, All
> >
> > I've made small patch for mf:// demuxer.
> > It intends to avoid "Program not responding" message while watching
> > pictures with mplayer (with large -mf fps value).
> >
> > With attached patch mf demuxer will duplicate each picture given
> > number of times. This avoids loooong usleep in main loop and increase
> > program responsibility.
> >
> > with "-mf repeat=1" (default) mplayer will work as without this patch
> >
> > Is this feature interesting for anybody else?
> >
> > Am i missing something (e.g. in mf.c ) ?
>
> Similar patches have been proposed and denied before.
Thanks for notice about that.
After googling I've found two patches suggested by Otvos Attila some time ago.

First one (functionality is 99% as in my version):
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2006-February/040574.html

Objections:
1. wrong option name

Another (updated, option name was changed to "fpi", each file reads
from disk only once):
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2006-February/040688.html


Objections:
2. broken autodetection of picture type

Objections against both patches:
3.decoding the same picture again and again is ineffective
4. the same functionality can be archived using mf://@list.txt syntax
(with properly prepared list.txt)

> For one, it is very ineffective to push same encoded picture multiple
> times, to be decoded again and again.

Well. First for all, my patch was mainly  proposed for mplayer not mencoder.
It is not needed for mencoder at all.

1 and 2 obviously can be fixed.
3. i don't think that 25 decodings per second will have too much speed
regression for regular user if another case will be unresponsible
program.
4. functionality is the same from developer's point. imho. I think one
option in config file will be much usable than manual preparation of
file list every time when user what to see some slideshow (don't
forget about standalone mplayer-powered boxes).

> And I'm not exactly sure what do you mean by "Program not responding",
> is that something Windows specific?
No. Keeping fps is implemented by  (1/fsp, in seconds) u_sleep inside
main loop. During this sleep neither commands are processed nor window
are updated. Thus, the whole problem is not Windows specific (specific
only above message).

Here is also quote from Otvos's mail:
================QUOTE==============
2006. február 19. 11.09 dátummal Reimar Döffinger ezt írta:
> Good question, why is this necessary?

1. mplayer mf:///some.jpg -mf fps=0.01	Can't work (exit mplayer)
2. mplayer mf:///*.jpg -mf fps=0.01 Don't work if modify window: resize,
move, switch, etc (don't redraw)
3. mencoder mf:///... -mf fps=0.01 -ofps=25 ... -o test.avi and
mplayer test.avi: Don't work if modify window...
================QUOTE==============
There was no anwser to above arguments.


> Maybe it would be better if you do increase the respond-ablity in
> mplayer.c e.g. by querying input more than once per frame while
> waiting in sleep loop or something. It would also help in the low fps
> movies case.
I'm afraid this will be much harder (and much usefull, though). I've
tried to make such patch.
(I've tried to split one big u_sleep into several smaller u_sleep with
mp_input_get_cmd between them, but i've archived only one thing:
ability to exit mplayer at any time.

-- 
Regards,
Vladimir Voroshilov     mailto:voroshil at gmail.com
JID: voroshil at gmail.com, voroshil at jabber.ru
ICQ: 95587719