GNOME Bugzilla – Bug 567725
[qtdemux] stopping at a time sometimes shows a different frame from seeking to a time
Last modified: 2009-01-23 11:22:05 UTC
Hi, I've found a strange thing recently, whereby the frame shown when one pauses a pipeline often is not the same frame shown if you seek to that pipeline's time. When the frame is off, it is off by one frame, and the seeked frame is one later than the paused frame. By visual inspection and feel, I would expect the paused frame to be the correct one. I'm attaching a short python program that reproduces the issue. I'm not sure if it's in qtdemux, or perhaps even in basesink.
Created attachment 126411 [details] test for frame off-by-one behavior
Created attachment 126416 [details] [review] patch to fix the issue The reason is that last_buffer is not updated (and the preroll vmethod not called) when synchronisation on the new buffer was interrupted and the new buffer was used for preroll. This caused that the position reporting was using the new buffer but last_buffer was still using the previous buffer. This patch will update the last_buffer exactly with the buffer that caused the preroll and it will also call the preroll method with that preroll buffer.
The patch fixes the issue for me. Thank you times 500!
commit 1c7ab4ed4f19b63ba046a6f2fe7d09a6c17357c5 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Wed Jan 21 12:43:55 2009 +0100 Update the last_buffer exactly with the buffer that caused the preroll and also call the preroll method with that preroll buffer. Fixes #567725.