From: David S. <ds...@en...> - 2011-01-03 03:25:39
|
On Sun, Jan 02, 2011 at 04:27:25PM -0800, David Zhao wrote: > On Sun, Jan 2, 2011 at 1:54 PM, Andoni Morales <yl...@gm...> wrote: > > > 2010/12/31 David Zhao <da...@da...>: > > > Thanks David! That's exactly what I was looking for. > > > > > > On Thu, Dec 30, 2010 at 11:23 PM, David Schleef <ds...@en...> > > >> 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...@sc...> 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 |