[gst-devel] Implementing a MPEGTS segmenter, what's the best approach?

[David Schleef]

On Sun, Jan 02, 2011 at 04:27:25PM -0800, David Zhao wrote:
> On Sun, Jan 2, 2011 at 1:54 PM, Andoni Morales <ylatuya at gmail.com> wrote:
> 
> > 2010/12/31 David Zhao <david at davidzhao.com>:
> > > Thanks David! That's exactly what I was looking for.
> > >
> > > On Thu, Dec 30, 2010 at 11:23 PM, David Schleef <ds at entropywave.com>
> > >> gst-launch ... ! mpegtsmux ! multifilesink next-file=key-frame \
> > >>    location=%05d.ts
> >
> > That's probably the quickest way to produce segments for testing
> > purpose but these fragments wouldn't follow the spec's
> > recommendations[1].
> >
> > " Transport Stream files MUST contain a single MPEG-2 Program.  There
> >   SHOULD be a Program Association Table and a Program Map Table at the
> >   start of each file.  A file that contains video SHOULD have at least
> >   one key frame and enough information to completely initialize a video
> >   decoder."
> >
> > A client can join the stream at any moment (downloading any of the
> > available segments), so each segment must be independently decodable,
> > which means you need to start each fragment with a PAT table, followed
> > with a PMT table and starting with a keyframe.
> >
> 
> Thanks for the clarification here. Looks like the "correct" way to implement
> this is still to create a special purposed mpegts muxer that will write the
> PAT/PMT tables at the beginning of each TS segment.
> 
> I noticed that the protocol says "SHOULD" instead of "MUST", perhaps the
> current implementation of iOS treat those tables as optional?


It helps to have this commit:

commit 6ab508dfa56f92c86c3b379b6cfe4ff28f2551e4
Author: David Schleef <ds at schleef.org>
Date:   Sun Jan 2 19:19:27 2011 -0800

    multifilesink: send stream headers in key-frame mode

However, the problems with the above pipeline are greatly exaggerated.
In the worst case (without the patch), clients will start the video
one keyframe late.

The *actual* problems with using mpegtsmux ! multifilesink are that it
doesn't write out the .m3u8 file for you, and that you have little
control over keyframe placement.



David