zaheermerali at gmail.com
Thu Nov 11 10:01:50 PST 2010
On Thu, Nov 11, 2010 at 2:37 PM, Steve Lhomme <slhomme at matroska.org> wrote:
> On Thu, Nov 11, 2010 at 3:29 PM, Andoni Morales <ylatuya at gmail.com> wrote:
>> 2010/11/11 Steve Lhomme <slhomme at matroska.org>:
>>> Interresting. To clarify things on the MKV/WebM side that you don't
>>> support yet. I think it's easier to send Matroska chunks on the fly
>>> that MP4. Basically these chunks don't need a Cues section (nor
>>> chapters, tags, etc or even Meta Seek). So the header is fixed and the
>>> same for all chunks (all you need it set an "unknown" on the high
>>> level Segment structure). They copy as much Clusters you need from the
>>> source file. I think that's basically what Fluendo/GStreamer are doing
>>> on their HTTP server of live WebM content. They don't even bother
>>> cutting the source file on Cluster boundaries, but in the case of
>>> chunks that are supposed to join correctly, you want to avoid some
>>> false alarm in trying to find the boundary you want.
>> On GStreamer, the webm muxers starts a new cluster for each keyframe
>> and unset the DELTA_UNIT flag on this buffers, which makes it a
>> "keyframe". The streamer, multifdsink, allows syncing new clients
>> connections on keyframes, so a client will always receive a stream
>> completely decodable.
> OK, I wasn't sure it had been changed. It's obviously better that way.
> But some other live streamers may still want to use that "lazy"
> technique in the future. Now that GStreamer doesn't do that anymore,
> maybe it should become illegal in WebM to do that.
There is a known bug however in Flumotion/GStreamer where you may get
partial clusters if you have slow clients and to catch them up.
We still need to fix that
More information about the foms