[MPlayer-users] Trouble with HD-PVR recordings

[Geoffrey Leach]

On 09/09/2009 04:58:43 PM, Carl Eugen Hoyos wrote:
> 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).

The problem here is not unlike the one that's been bothering me for 
some time. Which is, loss of A-V sync on recordings (MPEG2, HD HomeRun) 
on my PVR (E8400, GE9300, MCP79, 1920x1080 at 60) on two channels, 
consistently. FWIW (be that ever so little), here's my solution.

In mplayer.c:adjust_sync_and_print_status()
    if (AV_delay>0.5 && drop_frame_cnt>500){
        seek(mpctx, -0.1f, 0);
        /* GCL
        if (AV_delay>0.5 && drop_frame_cnt>50 && drop_message==0){
        ++drop_message;
        mp_msg(SGT_AVSYNC,MSGL_WARN,MSGTR_SystemTooSlow);
      */
    }

In other words, make the criteria for complaining that the system's too 
slow a little stricter (based on log observation) and seek backwards a
tad, which forces mplayer to start counting dropped frames again.

It's a bit of a blunt insturment, but it makes recordings watchable 
that were previously not so.

Geoffrey Leach