Opened 16 years ago
Closed 15 years ago
#1282 closed defect (remind)
"-vo xvmc,xv," is blocking on xvmc
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Component: | vo |
Version: | 1.0rc2 | Severity: | normal |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Reproduced by developer: | no | Analyzed by developer: | no |
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 by , 15 years ago
Owner: | changed from | to
---|
comment:2 by , 15 years ago
Resolution: | → remind |
---|---|
Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
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:
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.