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

[Reimar Döffinger]

On 17.05.2014, at 14:31, Andy Furniss <adf.lists at gmail.com> wrote:

> Reimar Döffinger wrote:
>> On Thu, May 15, 2014 at 02:30:42PM +0100, Andy Furniss wrote:
> 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.

You should also see that VO uses most in MPlayer status-line.
In theory that could still mean the GPU itself is the bottleneck, but if it also happens without deinterlacing that is almost certainly not the case. It going away at 120Hz refresh rate would confirm it as a driver issue due to it blocking while waiting for vsync.

> 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

Decoding is not changed in any way with -framedrop, only -hardframedrop does that.
All -framedrop does is not sending some frames to the vo (hm, well, I think it might try to skip decoding non-reference frames as well. Either way, actual output corruption would be a bug, and one I have not encountered so far).

> 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.

Shouldn't matter really.

> 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 ...

With a 4 core CPU and particularly if you have speed issues in the vo you should use more than 4 threads, 8 or more I'd guess in your case.

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

It sure is possible to work around/avoid it in several ways. None is simple enough that I'd like to do it in MPlayer when it's possible to fix for everyone in the driver...