[MPlayer-users] I know what telecine and interlacing are, but ....

Andy Furniss adf.lists at gmail.com
Sat May 17 14:31:47 CEST 2014


Reimar Döffinger wrote:
> On Thu, May 15, 2014 at 02:30:42PM +0100, Andy Furniss wrote:
>>> For anyone using NVidia however I certainly can't see why you'd
>>> want to go through such a pain.
>>
>> Maybe true, does having nvidia h/w exempt people from mplayer
>> fps=refresh issues?
>
> I assume you mean specifically the "-framedrop required" issue?
> First, that option should not be causing any issues, not even with
> H.264. The answer depends a bit on the vo so here for the most common
> ones:
>
> gl: The way vsync works by default it's problematic. -vo
> gl:swapinterval=0 avoids it, except for the fact that it is (AFAICT)
> broken with Mesa drivers. If you do not use a compositing window
> manager and can't/don't enable triple buffering in the driver you
> might get tearing. I.e. with the right configuration there should be
> no issue with NVidia hardware.

OK, but TBH GL isn't really an option for my typical TV use as I need a
GPU deinterlace as my CPU can't handle HD.

Testing quickly, no composite, no triple with amd foss, wait swapbuffers
off in xorg using glamor as GPU is radeonsi. I can see what you mean
about swapinterval=0. AIUI default mesa/dri vblank_mode is 2 and it
doesn't work with that. It does with vblank_mode=1, but for reasons
above I tear.

> xv, vdpau: -framedrop should not be required and there should be no
> tearing. Anything else is a driver bug. I.e. no issues with NVidia.

Well this is my use case, and having a new GPU means I haven't tested
that much yet. Initial tests do seem to give similar results to my old
GPU = CPU load with s/w decode seems relevant.

On TV 1080i50 seems to be borderline between OK and not - so not so good
to test with. Better testing seems to come with playing 1080i50, monitor
at 60Hz with speed 30/25. Doing that even though I have a 3.4Ghz X4 CPU
and top shows plenty spare I hit problems. CPUs and GPU are both set
high, so hopefully no cpufreq/dpm issues.

Using GPU field rate deinterlace without framedrop I am way too slow,
with it there is plenty of dropping leading to variable amounts of
disruption depending (I speculate) on whether key frames are lost -v
output gives plenty of noise from h264 decoder like the stream is broken.

My test case may be hard, being a transport stream with more sound
initially than vid but that's what I watch.

For the test I used what I would normally use (excepting speed) and I
believe the command line is equivelant with the mpv one/mpvs defaults.

mplayer -speed 30/25 -lavdopts threads=4 -demuxer lavf -fs -vo
vdpau:colorspace=2:deint=3 ...

mpv -speed 30/25 --softvol no --deinterlace=yes -fs -vo vdpau:fps=60

-framedrop/--framedrop=yes also tested of course.

mpv is not using uvd, but manages to play the stream flawlessly.


> I guess the summary is: If your drivers aren't buggy you shouldn't
> really have this issue, and NVidia drivers are not buggy in that way
> at least.


Fair enough, my vdpau is probably buggy, but whatever mpv does with the
same vdpau avoids it.

FWIW mplayer using uvd  - so no cpu load, did seem to work OK I couldn't
test for long as I was running a known flakey with radeonsi kernel and
it died on me - but seemed good while it lasted :-)




More information about the MPlayer-users mailing list