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.
Created attachment 474957 [details] [diff] [review] patch v0 Don't assume first WebM track is video. Use mVideoTrack (or mAudioTrack if there's no video) to seek.