GNOME Bugzilla – Bug 620358
[matroskademux] Sorenson Squish WebM output seeking issues
Last modified: 2010-06-06 13:00:19 UTC
http://lachy.id.au/dev/2010/bus.html http://lachy.id.au/dev/2010/bus-clean.webm http://lachy.id.au/dev/2010/bus-sorenson.webm http://lachy.id.au/dev/2010/falls-creek.html http://lachy.id.au/dev/2010/falls-creek.webm bus-sorenson.webm and falls-creek.webm are output from the Sorenson Squish encoder at http://www.sorensonmedia.com/vp8/ bus-clean.webm is a version cleaned with mkclean. All 3 WebM files have playback problems in Totem using current git master. When seeking in falls-creek.webm, playback simply freezes at the new frame. No amount of play/pause or seeking again can get the file to continue playing. This particular input also causes Opera to deadlock when calling gst_element_get_state on the pipeline after seeking, but I can't reproduce that in Totem and don't know if it's related. For both bus-clean.webm and bus-sorenson.webm, the duration (18 s) appears to be incorrect, even after remuxing. Seeking anywhere causes the seek handle to jump to 9 s and stay stuck there while the file continues playing to the end.
Yes, I can confirm this here. These are problems with matroskademux though, vp8dec/basevideodec doesn't do any seeking magic.
I guessed that it would be VP8 since even remuxing didn't help, but don't have any stronger leads than that.
Correction, Lachy tells me that falls-creek.webm is also a mkclean'd version. It's still broken though :)
Also, after seeking, the audio stops working in bus-sorenson.webm and and bus-clean.webm.
With the falls-creek-2006.webm input, the audio stream seems to be significant. This pipeline deadlocks when seeking: gst-launch filesrc location=falls-creek-2006.webm ! decodebin2 name=dec ! queue ! navseek ! xvimagesink dec. ! queue ! fakesink The following does not, however: gst-launch filesrc location=falls-creek-2006.webm ! decodebin2 name=dec ! queue ! navseek ! xvimagesink I'm not sure if the demuxer's internal state will be different if the audio pad is left unlinked or what exactly happens.
Actually, you can do without the queue elements too, but I don't think that's relevant.
Remuxing the file to have just the audio track or just video track and the problem goes away...
My debug pipeline: filesrc location=~/Videos/test/bus-sorenson.webm ! decodebin2 name=dec ! queue ! navseek ! autovideosink dec. ! queue ! audioconvert ! autoaudiosink It appears as though after seeking no audio (vorbis) buffers are being delivered, as vorbis_dec_chained is never called again after the flush in gst_matroska_demux_handle_seek_event is done.
Created attachment 162859 [details] [review] quickfix When the keyframe bit of SimpleBlock Flags wasn't set, the buffer was being marked with GST_BUFFER_FLAG_DELTA_UNIT, causing all buffers to be skipped after a seek. This may be a problem with the Sorenson Squish encoder, but arguably the keyframe bit should only be applied to video.
The patch is just my quickfix, I'll have to see if the keyframe flag *is* set for the audio streams that don't have this problem. If they do, that would be a bit strange.
Having poked around a bit, some other test files I had didn't use SimpleBlock for audio. Looking at the code, I think any file which does and doesn't set the keyframe flag for the audio tracks (which wouldn't make sense) would suffer from the same problem.
Yes, I think your patch completely makes sense. Thanks
commit b2ff8042d36077ce01e82e28efaf4e6f5d21391b Author: Philip Jägenstedt <philipj@opera.com> Date: Sun Jun 6 14:03:53 2010 +0200 matroskademux: Ignore keyframe flag for non-video streams When the keyframe bit of SimpleBlock Flags wasn't set, the buffer was being marked with GST_BUFFER_FLAG_DELTA_UNIT, causing all buffers to be skipped after a seek. This may be a problem with the Sorenson Squish encoder, but arguably the keyframe bit should only be applied to video. Fixes bug #620358.