[MPlayer-dev-eng] fixed-vo in VDPAU

[The Wanderer]

On 11/02/2009 02:23 AM, Serguei Miridonov wrote:

> On Monday 02 November 2009, The Wanderer wrote:
> 
>> On 11/01/2009 12:50 PM, Dani Church wrote:
>> 
>>> The documentation for fixed-vo says "only one window will be
>>> opened for all files."
> 
> ... and, as I wrote in my other post, average user perception of
> this: the window will keep its geometry or full-screen/panscan mode
> if (s)he changes it during the playback.

The trouble is that this doesn't match the general MPlayer command-line
semantics.


As I understand matters, the MPlayer option semantics are effectively a
type of cascading inheritance of defaults, with the following priority:

If no command or option is given, the compiled-in default will be used
for all files in a playback session.

If an option exists in a system-wide config file, it will override any
earlier setting for all files in a playback session.

If an option exists in a user-specific config file, it will override any
earlier setting for all files in a playback session.

If an option exists in a file-specific config file, it will override any
earlier setting *for that file only*.

If an option is given on the command line before any filename, it will
override any earlier setting (including, I think, file-specific config
files) for all files in a playback session.

If an option is given on the command line after a filename, it will
override any earlier setting *for that file only*.

If an option is given as a command during playback, it will override any
earlier setting *for that file only*.


Now, I do acknowledge that this is not necessarily consistent with what
some - or even potentially most - users will expect. It is, however, the
way pretty much all MPlayer options behave, and I for one like it that
way; it's versatile and IMO intuitive for its purpose.

That doesn't mean that we shouldn't provide the possibility for people
who don't find it intuitive to use a different set of semantics - or
even necessarily that we shouldn't make that different set of semantics
the default. It does, however, IMO mean that we should not take away the
possibility of having this set of semantics from those who find it
"correct".

(I also think that these semantics should remain the default, for
consistency with other options such as e.g. -ss, but that's another
argument.)

>> I think this is a somewhat misleading description. As far as I
>> understand things, what it actually means is "the video-out method
>> will be initialized only once for the entire session, rather than
>> going through initialization and cleanup for every file".
> 
> However, in fact, according to the code, it also runs window
> configuration with every file.
> 
>> That doesn't mean that the VO settings don't change between files,
>> however; they kind of have to, if for instance you're playing files
>> of different resolutions.
> 
> OK, that only means that -fixed-vo option is incompatible with
> multiple files of different resolutions and/or frame rates, color
> spaces, etc. No problem with that.

...no, it isn't; it plays the files just fine, adjusting the window size
(etc.) between files just as is necessary. If it didn't adjust, *that* I
would consider incompatible.

That may well also be why it re-does the window configuration per file.

> But I (and Dani Church, as understand from other post in this thread,
> and may be many other users) want to watch multiple clips from
> camcorder as one movie and we expect mplayer to mimic the same
> behavior as with just one long movie.

That's reasonable. Unless the suggestion from the two-year-old thread I
mentioned would be satisfactory, I don't know if I have a good answer
for this.

>>> Is there a valid, concrete use-case example for using fixed-vo 
>>> and not wanting to keep window settings?  I can't think of one,
>>> but I might be missing something.
>> 
>> What window settings are you thinking of, specifically?
> 
> Geometry (size and position on the screen), switch to full-screen
> mode and back, panscan settings. I think that will be sufficient.

Depends on what you'd consider a valid use case. I can think of one
possibility for the -geometry option (to do with size rather than
position), but it sounds like possibly a bit of a stretch even to me.

Other than that, the only thing I have off the top of my head is the
fact that I *have*, in the past, switched fullscreen playback to
windowed and then considered it entirely reasonable that it reverted to
fullscreen on the next file. Unfortunately, because it seemed so
reasonable, it didn't stick in my memory well enough that I even
remember what the circumstances were.

That said, I have been irritated by the reverse behavior more often -
which would seem to me to be another point in favor of making this
configurable...

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.