Re: VDPAU API and implementation issues
I certainly don't do b) - the timestamps are not 0.1 s apart from each other. I'm not sure whether you mean the same thing with a) - what does "added to each" mean when the absolute value is pretty much meaningless? Basically the test code queues each frame to be shown at vdp_presentation_queue_get_current_time() + 0.1 seconds (0.1 seconds into the future from the moment it's queued), and MPlayer tries to queue new frames at the natural rate the video would play at.
The main difference the test code has to "natural" playback that tries to queue frames 0.1 s ahead of their intended display time is that when VDPAU blocks and the queuing happens late as a result, it still queues the frames 0.1 s into the future from the queuing time (instead of the original time which is now less than 0.1 s away due to queuing running late). If "natural" code was slowed down by the blocking it'd queue frames less ahead, making the problem less obvious (queuing frames 0.1 s ahead causes slowdown -> queuing starts running late -> display time is now less than 0.1 s ahead of queuing time and there are no multiple frames queued simultaneously -> speed recovers). With "natural" code the main visible symptom of the problem is high CPU use.
I changed the branch to queue 0.1 s ahead of the queuing moment instead of 10 s. If you want a completely "natural" version I can add that; but I think the 0.1 s version should be "valid" behavior from VDPAU's point of view - VDPAU shouldn't be able to tell it's not just a normal video, and there's no excuse for the behavior it shows.