<div dir="ltr">Okay, I'm up to date on 1.3 and still seeing the same behavior.<div><br></div><div>Below is an example playlist. This takes a TS file and breaks it into segments on arbitrary packet boundaries.Â </div><div> <br></div><div><a href="https://hbanyvideodev2.blob.core.windows.net/test02/799864c5-7fed-42dd-afb7-da4127ca93e1_bw2htm1grkeqv6wfazopxg.m3u8">https://hbanyvideodev2.blob.core.windows.net/test02/799864c5-7fed-42dd-afb7-da4127ca93e1_bw2htm1grkeqv6wfazopxg.m3u8</a></div> <div><br></div><div>From what you're saying this should have trouble with seeking (no bitrate changes in this playlist) but should playback okay. Instead I get glitches with the following error messages:</div><div><br> </div><div>W/GStreamer+tsdemuxï¹• 0:00:40.275695802 0x7982a430 tsdemux.c:1569:gst_ts_demux_queue_data CONTINUITY: Mismatch packet 7, stream 5<br></div><div>W/GStreamer+mpegtspacketizerï¹• 0:00:40.450408937 0x7982a430 mpegtspacketizer.c:1371:calculate_skew delta - skew: 0:00:02.375388889 too big, reset skew<br> </div><div><div>W/GStreamer+amcvideodecï¹• 0:01:38.817871097 0x79a50a00 gstamcvideodec.c:1159:gst_amc_video_dec_loop:<amcvideodec-omxqcomvideodecoderavc0> Frame is too late, dropping (deadline 0:00:00.298588890)</div> <div>W/GStreamer+amcvideodecï¹• 0:01:38.818847660 0x79a50a00 gstamcvideodec.c:1159:gst_amc_video_dec_loop:<amcvideodec-omxqcomvideodecoderavc0> Frame is too late, dropping (deadline 0:00:00.256922223)</div><div>W/GStreamer+amcvideodecï¹• 0:01:38.820343021 0x79a50a00 gstamcvideodec.c:1159:gst_amc_video_dec_loop:<amcvideodec-omxqcomvideodecoderavc0> Frame is too late, dropping (deadline 0:00:00.215266668)</div> <div>W/GStreamer+amcvideodecï¹• 0:01:38.830200199 0x79a50a00 gstamcvideodec.c:1159:gst_amc_video_dec_loop:<amcvideodec-omxqcomvideodecoderavc0> Frame is too late, dropping (deadline 0:00:00.173611112)</div><div>W/GStreamer+amcvideodecï¹• 0:01:38.831604007 0x79a50a00 gstamcvideodec.c:1159:gst_amc_video_dec_loop:<amcvideodec-omxqcomvideodecoderavc0> Frame is too late, dropping (deadline 0:00:00.131944445)</div> <div>W/GStreamer+amcvideodecï¹• 0:01:38.834686283 0x79a50a00 gstamcvideodec.c:1159:gst_amc_video_dec_loop:<amcvideodec-omxqcomvideodecoderavc0> Frame is too late, dropping (deadline 0:00:00.090288890)</div></div><div> <br></div><div>Playing the .ts file directly works fine. Any chance this repros for you? Any idea what the issue might be?</div><div><br></div><div>Thanks again for the help.</div><div><br></div><div>Dave</div> </div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 9:01 AM, Dave Walker <span dir="ltr"><<a href="mailto:dave@happybits.co" target="_blank">dave@happybits.co</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I hadn't seen EXT-X-MAP before - neat.<div><br></div><div>I'm only using a single playlist, not a master with different sub-playlists for different bitrates. So the behavior I'm seeing isn't related to bitrate changes. But I'm on 1.2, which I'm now realizing isn't up to date enough. I'll get up to date and then report back.</div> <div><br></div><div>Andoni, Sebastian, thanks to you both.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Dave</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br> <br><div class="gmail_quote">On Thu, Mar 6, 2014 at 8:30 AM, Andoni Morales <span dir="ltr"><<a href="mailto:ylatuya@gmail.com" target="_blank">ylatuya@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-03-06 16:19 GMT+01:00 Dave Walker <span dir="ltr"><<a href="mailto:dave@happybits.co" target="_blank">dave@happybits.co</a>></span>:<div> <br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">The spec I'm reading seems looser than that:Â <a href="http://tools.ietf.org/html/draft-pantos-http-live-streaming-12" target="_blank">http://tools.ietf.org/html/draft-pantos-http-live-streaming-12</a>, with SHOULD language instead of MUST. Particularly in the presence of the new byte range segments (which I know aren't supported by gstreamer yet) I wouldn't think it would be desirable to force every segment to have its own PPS/SPS.</div> </blockquote><div><br></div></div><div>Byterange segments are the same as file segments, except they are packet in a single file, so each "virtual" segment (as defined in the playlist with the range start-stop) should be able to initialize itself. SPS/PPS are not needed at the beginning of the segment the EXT-X-MAP tag is provided, but when it's not there there having these headers is the only way to warranty that playback can start at any segment.<span><font color="#888888"><br> <br></font></span></div><span><font color="#888888"><div>Andoni<br></div></font></span><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div> <br></div><div>But my question is more about the behavior I'm seeing. Would you expect me to be getting glitches and dropouts with segments that *don't* start with a keyframe and PPS/SPS? Does the next stage in the pipeline treat each segment independently, rather than as one big continuous stream? If it's all one big stream I wouldn't think it would matter where the boundaries between segments are.</div> <span><font color="#888888"> <div><br></div><div>Dave</div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 5:34 AM, Andoni Morales <span dir="ltr"><<a href="mailto:ylatuya@gmail.com" target="_blank">ylatuya@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-03-06 4:46 GMT+01:00 Dave Walker <span dir="ltr"><<a href="mailto:dave@happybits.co" target="_blank">dave@happybits.co</a>></span>:<div> <br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra">I'm experimenting with the HLS plugin, and have found that playback behaves much, much better if HLS segments begin with a key frame. Without key frames at the beginning I get skipping, dropped frames, and other glitches.</div> <div class="gmail_extra"><br></div><div class="gmail_extra">I'm wondering why that is? I'm imagining that the HLS demuxer is simply responsible for fetching new content and providing it in a continuous stream to the next element in the pipeline. If that's the case then the exact boundaries between segments wouldn't matter.</div> <div class="gmail_extra"><br></div><div class="gmail_extra">I definitely understand that for seeking, keyframes at the start of segments is crucial. But I'm just doing live streaming.</div></div></blockquote><div><br> </div></div><div>HLS segment *must* start with a PPS/SPS + Keyframe, this is mandatory in the spec. Even if you are not seeking and only doing live streaming, the client will start play at any segment and therefore this segment must be able to initialize the decoder correctly. You are also switching bitrates,Â which means the segment for the new bitrate must also start with a keyframe for a correct transition.<br> <br>Cheers,<br>Andoni <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br> </div><div class="gmail_extra">Thanks.</div><span><font color="#888888"><div class="gmail_extra"><br></div><div class="gmail_extra">Dave</div></font></span></div> <br>_______________________________________________<br> gstreamer-android mailing list<br> <a href="mailto:gstreamer-android@lists.freedesktop.org" target="_blank">gstreamer-android@lists.freedesktop.org</a><br> <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-android" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-android</a><br> <br></blockquote></div><span><font color="#888888"><br><br clear="all"><br>-- <br>Andoni Morales Alastruey<br><br>LongoMatch:The Digital Coach<br><a href="http://www.longomatch.ylatuya.es" target="_blank">http://www.longomatch.ylatuya.es</a> </font></span></div></div> <br>_______________________________________________<br> gstreamer-android mailing list<br> <a href="mailto:gstreamer-android@lists.freedesktop.org" target="_blank">gstreamer-android@lists.freedesktop.org</a><br> <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-android" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-android</a><br> <br></blockquote></div><br></div> </div></div><br>_______________________________________________<br> gstreamer-android mailing list<br> <a href="mailto:gstreamer-android@lists.freedesktop.org" target="_blank">gstreamer-android@lists.freedesktop.org</a><br> <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-android" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-android</a><br> <br></blockquote></div></div></div><div><div><br><br clear="all"><br>-- <br>Andoni Morales Alastruey<br><br>LongoMatch:The Digital Coach<br><a href="http://www.longomatch.ylatuya.es" target="_blank">http://www.longomatch.ylatuya.es</a> </div></div></div></div> <br>_______________________________________________<br> gstreamer-android mailing list<br> <a href="mailto:gstreamer-android@lists.freedesktop.org" target="_blank">gstreamer-android@lists.freedesktop.org</a><br> <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-android" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-android</a><br> <br></blockquote></div><br></div> </div></div></blockquote></div><br></div>