[gst-devel] Implementing a MPEGTS segmenter, what's the best approach?
david at davidzhao.com
Mon Jan 3 07:07:58 CET 2011
On Sun, Jan 2, 2011 at 7:28 PM, David Schleef <ds at entropywave.com> wrote:
> 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>
> > > 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.
> > >
> > > " 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
> > this is still to create a special purposed mpegts muxer that will write
> > 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.
I've tested ts files generated by multifilesink (even before this commit)
and it seems to work fine when it's not switching streams. When it does
switch between variants, this commit may become necessary. I'll give this a
shot, will report back with results.
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gstreamer-devel