HLS and keyframes

[Dave Walker]

Okay, I'm up to date on 1.3 and still seeing the same behavior.

Below is an example playlist. This takes a TS file and breaks it into
segments on arbitrary packet boundaries.

https://hbanyvideodev2.blob.core.windows.net/test02/799864c5-7fed-42dd-afb7-da4127ca93e1_bw2htm1grkeqv6wfazopxg.m3u8

>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:

W/GStreamer+tsdemux﹕ 0:00:40.275695802 0x7982a430
tsdemux.c:1569:gst_ts_demux_queue_data CONTINUITY: Mismatch packet 7,
stream 5
W/GStreamer+mpegtspacketizer﹕ 0:00:40.450408937 0x7982a430
mpegtspacketizer.c:1371:calculate_skew delta - skew: 0:00:02.375388889 too
big, reset skew
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)
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)
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)
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)
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)
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)

Playing the .ts file directly works fine. Any chance this repros for you?
Any idea what the issue might be?

Thanks again for the help.

Dave


On Thu, Mar 6, 2014 at 9:01 AM, Dave Walker <dave at happybits.co> wrote:

> I hadn't seen EXT-X-MAP before - neat.
>
> 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.
>
> Andoni, Sebastian, thanks to you both.
>
> Dave
>
>
> On Thu, Mar 6, 2014 at 8:30 AM, Andoni Morales <ylatuya at gmail.com> wrote:
>
>>
>>
>>
>> 2014-03-06 16:19 GMT+01:00 Dave Walker <dave at happybits.co>:
>>
>> The spec I'm reading seems looser than that:
>>> http://tools.ietf.org/html/draft-pantos-http-live-streaming-12, 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.
>>>
>>
>> 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.
>>
>> Andoni
>>
>>>
>>> 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.
>>>
>>> Dave
>>>
>>>
>>> On Thu, Mar 6, 2014 at 5:34 AM, Andoni Morales <ylatuya at gmail.com>wrote:
>>>
>>>>
>>>>
>>>>
>>>> 2014-03-06 4:46 GMT+01:00 Dave Walker <dave at happybits.co>:
>>>>
>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> I definitely understand that for seeking, keyframes at the start of
>>>>> segments is crucial. But I'm just doing live streaming.
>>>>>
>>>>
>>>> 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.
>>>>
>>>> Cheers,
>>>> Andoni
>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Dave
>>>>>
>>>>> _______________________________________________
>>>>> gstreamer-android mailing list
>>>>> gstreamer-android at lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-android
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Andoni Morales Alastruey
>>>>
>>>> LongoMatch:The Digital Coach
>>>> http://www.longomatch.ylatuya.es
>>>>
>>>> _______________________________________________
>>>> gstreamer-android mailing list
>>>> gstreamer-android at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-android
>>>>
>>>>
>>>
>>> _______________________________________________
>>> gstreamer-android mailing list
>>> gstreamer-android at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-android
>>>
>>>
>>
>>
>> --
>> Andoni Morales Alastruey
>>
>> LongoMatch:The Digital Coach
>> http://www.longomatch.ylatuya.es
>>
>> _______________________________________________
>> gstreamer-android mailing list
>> gstreamer-android at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-android
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-android/attachments/20140307/6eb9bae8/attachment.html>