GNOME Bugzilla – Bug 347439
[qtdemux] seeks poorly in files with slideshows
Last modified: 2006-07-17 10:27:21 UTC
Some podcasts online (http://thisweekintech.com/this_week_in_media, http://revision3.com/infected) distribute their files as m4a audio files or quicktimes with slideshows instead of video or just audio as their content. This causes a problem in seeking, because it seems that gstreamer will only seek to a place where the picture changes (keyframes), and nowhere else in between. This is using totem, but I get the same problem with other media players. In the case of This Week in Media this is incredibly troublesome. In episode 13, I can't navigate anywhere in between 9:45 and 47:10. The playhead just pops backward to the last place the picture changes. Steps to reproduce: 1. Download a quicktime that uses images instead of video as its content 2. Play the quicktime. 3. Try to seek Expected results: Gstreamer should figure out what the video should look like, and then play the audio from the selected point. Actual result: The playhead snaps back to the last time the picture changed (a keyframe I bet) making it impossible to reseek to the middle of a file. Notes: This works on Macintosh OSX, of course.
totem does keyframes seeks by default for snapier seeking. qtdemux should be able to figure out that the video at the keyframe and requested position is the same and should just do an accurate seek.
can't get to a usable link, can you post a link that I can wget?
http://media.libsyn.com/media/twimenhanced/twim_013_m64.m4a
Thanks! * gst/qtdemux/qtdemux.c: (gst_qtdemux_perform_seek), (gst_qtdemux_prepare_current_sample), (gst_qtdemux_loop_state_movie): Store duration in uint64 too instead of clipping. When we do a keyframe seek and the requested time is at the keyframe, don't seek back to the beginning of the keyframe. Fixes #347439.