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@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 _______________________________________________ MPlayer-users mailing list MPlayer-users@xxxxxxxxxxxx https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users
