Re: Video stutter
Sorry for the slow response; I haven't been following nvnews.net as often as I used to.
I've tried your clip on both an ION 1 machine and a desktop with AMD Athlon(tm) 64 X2 Dual Core Processor 4000+ and a mid-range VDPAU feature set C GPU.
With software decoding, I certainly do see very slow decoding (Atom) or occasional glitches like 1 frame is 1 VSYNC too late (AMD dual-core); I assume this is just the CPU being unable to keep up with the decoding requirements. (This is with -vo vdpau).
However, with "-vo vdpau -vc ffh264vdpau", I don't see glitches on either platform, even when I get MPlayer to loop playback and watching many iterations of the clip.
I tried MPlayer from SVN r29354 (one of the version we based our early patches on IIRC) and another random version I had (r31342). Both give the same results; no glitches with HW decoding.
The only advice I can give is:
a) Are there delays reading the clip from disk? I have my media on an NFS mount, and did see some glitches the first time through due to the data not being cached on the playback machine.
b) Is your player application sufficiently pipelining decode and display operations? This requires using more than the minimum number of video and output surfaces so the decoder and mixer can ping-pong between output surfaces rather than serializing operations. The driver README appendix H has some more complete details. I know MPlayer doesn't pipeline decoding.
c) Specifically on ION, there are different RAM configurations. I don't recall exactly what they are, but e.g. single-bank vs. dual-bank interleaved, memory clock, perhaps DDR2 vs. DDR3, etc. This may impact performance.
d) Is your application using timestamps when queueing pictures into the VDPAU presentation queue? Without this, every picture is displayed ASAP; i.e. beginning with the very next VSYNC. With 30fps content on a 60fps display, pictures should all be displayed for 2 VSYNCS each, but small variations in the timing of when VDPAU APIs are called, complexity differences in different pictures, etc. could cause some pictures to be displayed for 1 VSYNC and hence others for 3 VSYNCs, which probably would cause symptoms like you're seeing. I know MPlayer doesn't do this either, at least not in the versions I tested with nor the standard SVN repo (although there are some other experimental branches that do). Passing timestamps to vdp_presentation_queue_display, you should be able to avoid this issue.
Determine initial timestamps by using a small offset from VdpPresentationQueueGetTime's result. Pick timestamps in the middle of the VSYNCs to avoid beating with the actual VSYNC. Determine initial inter-timestamp period by e.g. XF86VidMode initially (or hard-coding), and then feeding back the results from VdpPresentationQueueBlockUntilSurfaceIdle or VdpPresentationQueueQuerySurfaceStatus's first_presentation_time value.