Found this file via bug 593814. Seeking to a new time fails with both remote and local files.
+ EBML head at 0 |+ Doc type: webm at 11 |+ Doc type read version: 2 at 22 + Segment, size 17003173 at 26 |+ Seek head at 34 | + Seek entry at 86 | + Seek ID: 0x1c 0x53 0xbb 0x6b (KaxCues) at 95 | + Seek position: 4434 at 102 | + Muxing application: libebml2 v0.11.1 + libmatroska2 v0.11.0 at 172 | + Writing application: mkclean 0.5.6 from GStreamer plugin version 0.10.23 + OggConvert 0.3.3 at 214 Looks fine, has a Cues element. |+ Segment tracks at 298 | + Track number: 1 at 319 | + Codec ID: A_VORBIS at 325 | + A track at 4402 | + Track number: 2 at 4410 | + Codec ID: V_VP8 at 4416 Vorbis track is first track, which is unusual. Need to check if this is valid wrt to the WebM spec. |+ Cues at 4468 | + Cue point at 4480 | + Cue time: 0.000s at 4482 | + Cue track positions at 4485 | + Cue track: 2 at 4487 | + Cue cluster position: 5924 at 4490 Cues are present for track 2 (VP8 track).
int r = nestegg_track_seek(mContext, 0, aTarget * NS_PER_MS); Oops, nsWebMReader::Seek assumes the first track is the video track. It should be using mVideoTrack.
Don't assume first WebM track is video. Use mVideoTrack (or mAudioTrack if there's no video) to seek.
Attachment #474957 - Flags: review?(chris.double)
Summary: Seeking fails in WebM file muxed with libmatroska2/mkclean via GStreamer → nsWebMReader::Seek assumes video is first track in the stream and fails to seek in files where this is not true
blocking2.0: ? → final+
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.