video freezes on TS discontinuity (support #EXT-X-DISCONTINUITY)

[GoogleCodeExporter]

currently video freezes when you mix TS files from different encodings.
test: http://hls.artcore.ch/test.m3u8  => freeze after 20seconds.

how could this be fixed?

Original issue reported on code.google.com by yannick....@gmail.com on 1 Apr 2012 at 11:50

[GoogleCodeExporter]

Probably a timestamp discontinuity issue. Thanks for the test case.

Original comment by atmatthewat@gmail.com on 8 Jun 2012 at 5:42

[GoogleCodeExporter]

I've been working for the last few days on digging into the internals of OSMF 
2.0 and your HTTP Live Streaming library in order to implement support for 
timecode discontinuity, as it's foundational to what I'm trying to accomplish 
for a client.  It's for a website where users can create short compositions of 
5-7 different clips and send the resulting video to a friend (think custom 
video e-card).  Right now the site is implemented by using server-side 
concatenation and transcoding to generate each composition as its own .mp4 
file, which is not going to be scalable.  I wanted to use HLS with its 
EXT-X-DISCONTINUITY tag to be able to join these disparate clips on the fly 
during playback.

This works perfectly in QuickTime player, Safari, and on iPhone, but I haven't 
been able to get it to work with OSMF.  The individual segment .ts files are 
all of exactly identical format (codecs, dimensions, etc.), but the segment 
playback freezes and stutters as soon as it starts buffering data from the next 
clip (before the first segment has even finished playing).

From what I can tell, OSMF doesn't have any mechanism for handling timecode 
discontinuity - calling 
appendBytesAction(NetStreamAppendBytesAction.RESET_BEGIN);  So I added the 
events and handlers to HTTPStreamSource, HTTPNetStream, and to 
HTTPStreamingM3U8IndexHandler to indicate that a timecode discontinuity is 
approaching, modeled after the way that the 
HTTPStreamingEvent.FRAGMENT_DURATION event is done.  It now calls 
appendBytesAction(NetStreamAppendBytesAction.RESET_BEGIN) on the HTTPNetStream 
and appends a new FLV header just before beginning to add the bytes for the 
next segment to the fifo, but this had no effect whatsoever.

Do you have any thoughts on what the best way might be to approach this problem?

I'm thinking my next approach might be instead to just re-write any timecode 
information inside HTTPStreamingMP2TSFileHandler, HTTPStreamingMP2PESVideo, and 
HTTPStreamingMP2PESAudio so that there is no discontinuity, but I haven't yet 
looked into what would be involved there.

If you're curious, my test m3u8 file is here: 
http://www.codecomposer.net/hls/playlist.m3u8

And a test page using the <video> tag (works in Safari for Mac, or iOS): 
http://www.codecomposer.net/hls/

Original comment by theturtl...@gmail.com on 25 Jun 2012 at 10:50

[GoogleCodeExporter]

Well I finally got it to work!  I had to modify OSMF 2.0 itself to be able to 
signal a clip discontinuity and trigger a call to 
NeetStream.appendBytesAction(NetStreamAppendBytesAction.RESET_BEGIN) -- from 
what I could tell, there was absolutely no handling for this already built into 
OSMF.  I'll also be working on improving the .ts demuxer and cleaning up my 
code, and hopefully will be able to send you a patch in the next week or two.

Original comment by theturtl...@gmail.com on 26 Jun 2012 at 11:34

[GoogleCodeExporter]

Since the discontinuity handling requires a fork of OSMF 2.0, maybe it would be 
better for me to just put a fork of the project up on GitHub?  How do you want 
to handle that?  Do you know of any way to deal with this without needing to 
patch OSMF?

Original comment by theturtl...@gmail.com on 26 Jun 2012 at 11:36