[MPlayer-dev-eng] [PATCH] support run command with specific osd_level

[Ulion]

2008/2/2, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> Hello,
> On Sat, Feb 02, 2008 at 12:11:21PM +0800, Ulion wrote:
> > 2. All osd msgs and osd bar have same internal level in Reimar's
> > patch, while in my patch, they just keeping use their preset internal
> > level, and when a 'osd_level N' prefix (N>=1) is used with a command,
> > which osd msg get displayed, which not displayed, will be decided by N
> > and the msg's preset internal level, so some msg could be displayed,
> > some could not because it's internal level is larger than N. My patch
> > supply more accurate control on this point.
>
> I would be possible to make it increment/decrement the levels instead,
> but it does not seem really useful yet. That said, some of that osd
> handling is a real mess which makes it hard to implement things.
>
> > 3. Reimar's patch still has some bugs:
> >   a. not only seek command will trigger the 'seek action' and osd
> > msgs/bar in mplayer.c, but the patch only works for seek command. that
> > means when use osd_level prefix with other commands causing a 'seek
> > action', the osd msgs/bar are not displayed as expected osd level.
> > Check what my patch does in command.c to see how I fix this problem.
>
> Unfortunately it is also one of the parts I consider ugly about you patch.
> I may have found a slightly simpler solution, but it is still untested.
> Though I noticed that at least the type for your copy of the
> rel_seek_secs variable is wrong, it should be float.

um, it's simper, I will update my patch with your simpler solution and
fix the float type.
another missing place in your patch:
-               if (sh_video)
+               if (sh_video && mpctx->force_osd_level != 0)
                    mpctx->osd_show_percentage = sh_video->fps;
when frontend users do not want any osd display for a seek action, the
osd_percentage should not be triggered.

>
> >   b. osd_function variable is related with the left top corner's OSD
> > symbol, when we reject the osd bar request generated by the 'seek
> > action', the osd_function will never get reset to PLAY status, also
> > the osd symbol. Check my patch code after the 'seek action' in
> > mplayer.c to see how I fix this.
>
> I have seen this, the reason I did not do this is that I have this
> problem of the OSD symbol being stuck to fast forward all the time and
> since IIRC years already without this patch, so I think the real bug
> that the play symbol is handled in a much too brittle way and should be
> fixed separately. I'll try to find time for it somewhen soon.

On my machine, my two line code will fix the stuck although I still
not found how the osd_function's value affect the symbol, maybe by
it's value is the symbol's font index?
And clearly the osd_function's value is reset in the update_osd_msgs
function when osd_visible reached, and for frontend users did not want
osd of a seek action, the symbol should never changed to fast forward
or fast backward.

-- 
Ulion
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmd_with_osd_level4.diff
Type: text/x-vhdl
Size: 5773 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20080202/39c1b35c/attachment.bin>