Opened 11 years ago

Closed 10 years ago

#1282 closed defect (remind)

"-vo xvmc,xv," is blocking on xvmc

Reported by: lorefice2@… Owned by: ikalvachev@…
Priority: normal Component: vo
Version: 1.0rc2 Severity: normal
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:

Description

As stated on the man page:
"If the list has a trailing ’,’ MPlayer will fall back on drivers not contained in the list. "

...But it seems that xvmc is an exception; if i try something like:
"mplayer mymovie.avi -vo xvmc,"
mplayer exits with an error saying that video_out driver is incompatible with the codec.
"mplayer mymovie.avi -vo xvmc,xv" is the same, while:
"mplayer mymovie.avi -vo xover,xv" will correctly fallback on xv (xover is unavailable to me).

Change History (2)

comment:1 Changed 10 years ago by diego@…

  • Owner changed from beastd to ikalvachev@…

comment:2 Changed 10 years ago by ikalvachev@…

  • Resolution set to remind
  • Status changed from new to closed

This is actually a documentation bug.

The video output have 2 stages of initialization.
The first is preinit() the second is config().

The fallback happens only if the first stage fails. For XvMC this includes:

  • no X connection (no DISPLAY env).
  • the query for XvMC fails (not supported on that screen, xvmcw not configured)
  • error pasting suboptions.

You can check this behavior by yourself by trying

mplayer file.avi -vf scale=4096:4096 -vo xv,x11,gl

As the scale would make the image bigger than xv driver capabilities (usually 2048x2048) the xv would fail without falling back to the next output.

The second stage of initialization (the one that fails for you)
is called by the decoder() so fall back will not always be possible
as the preinit() phase may already have put the display in some
state.

Yet, I put the bug on remind, so that in future if somebody
reworks the video system to handle such cases this behavior would be
fixed.

Note: See TracTickets for help on using tickets.