Try 'opengl', 'opengl-old'... But 'xv' should be just as good. Maybe
there's some filter (deblocking/deringing/denoise) active with one but
not with 'xv'.
And I've IIRC used plain 'x11' (or was it 'xv'?) for a very long time.
Try benchmarking yourself a bit, after you've found a setting where no
tearing occurs. Seems mpv has scrapped that benchmarking code of
mplayer though.
$ mplayer -ss 20:00 -endpos 10 -benchmark -vo x11 foo.mkv
BENCHMARKs: VC: 0.910s VO: 1.792s A: 0.043s Sys: 5.272s = 8.017s
$ mplayer -ss 20:00 -endpos 10 -benchmark -vo xv foo.mkv
BENCHMARKs: VC: 1.076s VO: 0.147s A: 0.048s Sys: 6.746s = 8.018s
$ mplayer -ss 20:00 -endpos 10 -benchmark -vo gl foo.mkv
BENCHMARKs: VC: 1.117s VO: 0.251s A: 0.045s Sys: 6.604s = 8.018s
$ mplayer -ss 20:00 -endpos 10 -benchmark -vo gl2 foo.mkv
BENCHMARKs: VC: 0.929s VO: 0.746s A: 0.040s Sys: 6.307s = 8.021s
$ mplayer -ss 20:00 -endpos 10 -benchmark -vo vdpau foo.mkv
BENCHMARKs: VC: 1.161s VO: 0.204s A: 0.071s Sys: 6.582s = 8.018s
Look at the 'VO: ...s' column. You'd probably need longer tests for
significant results.
But, as mpv is based on the mplayer code, I guess you can "port" the
results of each "-vo" to mpv with some educated guesses, and 'gl'
(mpv: 'opengl'?) seems best ... ;)
BTW: Why not just use mplayer? What does mpv offer that mplayer doesn't?
BTW2:
$ mplayer -ss 20:00 -endpos 10 -benchmark -vo vdpau -vc ffh264vdpau foo.mkv
[just errors and some sound]
$ midentify foo.mkv | grep CODEC
ID_VIDEO_CODEC=ffh264
ID_AUDIO_CODEC=ffac3
Which is why I don't use vdpau ;)
HTH,
-dnh, firmly sticking to the original mplayer, and using mencoder
on a regular basis
well the thing with quality is not important. I is negligible ( without
xv option, video seems a little brighter) However it is not important.
Good thing is that I realized what mplayer was doing for default which
mpv wasnt.
Anyway I can get what mplayer was offering, with mpv now, so there is no
need to change.