[MPlayer-users] Trouble with HD-PVR recordings

[Carl Eugen Hoyos]

Charlie Gunyon <charles.gunyon <at> gmail.com> writes:

[...]
> I understand the idea of container formats, but the real difference
> here is what MPlayer's defaults are.  Is this information documented
> anywhere?

For example in MPlayer's output (fourth line) - I would consider it less helpful
anywhere else. (but as always: Documentation patch welcome!)

[...]

> I uploaded it here: http://www.charlieg.net/downloads/output.log, but
> I really think that my system is not too slow as this sample plays
> just fine in Windows using VLC, or using the CoreAVC for Linux
> software.

That is not really a valid argument (both may drop frames without you noticing
it and CoreAVC can use CPU cores that MPlayer can't use).

> > Are you sure? Could this be a problem with a too low refresh rate of your
> > screen? Did you test export VDPAU_NVIDIA_NO_OVERLAY=1?
> > I will test with my Pentium III 500, but that will take some time.
> 
> Neat trick, that helped a lot!  Is that documented anywhere?

(Here, if I understand you correctly, you should have deleted my line about my
old computer.)
ftp://download.nvidia.com/XFree86/Linux-x86/190.32/README/appendix-h.html
(Paragraph VdpPresentationQueue)
You can test deint=2 now - it probably works as long as you do not use OSD...

[...]

> Yeah I'm starting to figure this out.  You can't use CPU deinterlacing
> when using VDPAU decoding can you?

Not yet, but since the useful de-interlacer (yadif) needs much more CPU power
than decoding alone, I doubt it would help in this case.

> >> And I avoided the SLOW message and A-V desyncs, but playback was quite
> >> choppy.  I assume this is due to 'skipframe=nonref' but if this is the
> >> result I don't see it as a solution.
> >
> > I tried to say it before: You cannot ask the system to drop as many frames
> > as possible and complain about dropping frames.
> 
> Yeah I understand the concept of "frame skipping" or alternately
> "frame dropping" but I thought I wasn't asking it to drop as many
> frames as possible, just the non-reference ones.

No, you asked to drop as many as possible without breaking decoding.

> I guess I didn't
> realize how many that was, the docs really aren't clear about this at all.

I disagree, but see above.

> Also I thought that '-framedrop' was supposed to drop as many frames as
> necessary.

Exactly (as opposed to as many as possible).

Carl Eugen