[Matroska-devel] Issue with seeking of .mkv files containing H.264 content

Shyam Sadhwani shyams at microsoft.com
Fri May 1 20:03:36 CEST 2009

Hi Mike,

We do not want Haali source to change the seeking mechanism. Only issue is accuracy of timestamps on input samples after seek.
We are fine with seeking to previous keyframe and send intermediate frames as preroll.

The problem we are seeing is that after these intermediate preroll frames, the frames coming into decoder have timestamps (which are greater than 0) that are already behind current clock.
I suspect Haali source is not setting correct timestamps after seek. 

Timestamps seem to become correct after next key frame most of the time.


-----Original Message-----
From: Михаил Мацнев [mailto:mike at haali.net] 
Sent: Friday, May 01, 2009 6:55 AM
To: Discussion about the current and future development of Matroska
Cc: Yongjun Wu; Shyam Sadhwani
Subject: Re: [Matroska-devel] Issue with seeking of .mkv files containing H.264 content

Harsha Kikkeri (CODEC DSP) wrote:
> We are seeing issues with seeking of .MKV files containing H.264 content.
> After seeking, Haali source filter sends out a bunch of samples which have preroll=1(with negative timestamps, decoder ignores these timestamps) followed by samples with preroll=0.
> Decoder decodes all these samples and only sends the samples with preroll=0 to downstream renderer.
> When renderer receives these samples, timestamps on these samples are already behind the clock and this causes renderer to send late quality messages.
> Haali source can check   that the timestamp of the sample that it is sending out should be greater than current streamtime.
> http://msdn2.microsoft.com/en-us/library/ms780225.aspx
> What we see, it that after a seek the timestamp of the first few samples (which have preroll=0) is behind current StreamTime.
> This causes decoder to drop frames. This happens with ffdshow and Cyberlink decoders as well.
What you describe is a situation when the seek is requested to a non-keyframe. My current code seeks
to a previous keyframe and sends intermediate frames as preroll. Could you suggest a better algorithm
to handle this case? I didn't find anything specific about it in DShow documentation.

More information about the Matroska-devel mailing list