write smaller clusters at beginning of track


Right now, we don't stream frames until we've read the entire cluster containing the frames. (You don't have to do it that way, but that way turns out to be simpler.) For network downloads, we only want to have to download as little data as possible, in order start playback as quickly as possible. This favors smaller clusters, at least at the beginning of the track.
Our current algorithm writes a new cluster when we have at least one second's worth of data since the last cluster, and we have keyframe. (Since keyframe aren't guaranteed to arrive exactly once per second, in practice the current algorithm creates clusters slightly larger than 1 second.)
To make it easier for clients (like us) who can't stream until receiving an whole cluster, make the first few clusters smaller. For example, write a new cluster immediately when we receive a new keyframe. Do this for 60 seconds worth of clusters.
The doesn't preclude us modifying the mkv source fliter to begin streaming without having an entire cluster (you just need a whole block, not a whole cluster). The change in the muxer just makes it better for clients who happen to need whole clusters.
Closed Mar 8, 2010 at 8:55 PM by matthewjheaney
This is fixed as of the 1.0.3 release. To make this work required doing 3 things:(1) You must send EndOfStream to the file writer.(2) You must implement IAMFilterMiscFlags interface, and return the IS_RENDERER flag.(3) You must send EC_COMPLETE to the media event sink when all of the input streams have received EndOfStream.


matthewjheaney wrote Mar 8, 2010 at 9:00 PM

Actually, that comment applies to a different issue. This issue is indeed fixed, as of the 1.0.3 release. For the first 60 seconds of presentation time, we write a cluster as soon as we're able, which is (1) when we receive a new I-frame, and (2) we have audio whose time as at least equal to the new I-frame. After the first 60 seconds of presentation time, we write clusters in the normal way, which is when we have a new I-frame that is at least 1 second greater in time than earliest reference time we still have enqueued.

wrote Feb 14, 2013 at 7:02 PM

wrote May 16, 2013 at 9:14 AM