[FFmpeg-user] weird seek behaviour in hls streams

[Daniel Oberhoff]

> On 19. Apr 2018, at 14:48, Daniel Oberhoff <danieloberhoff at googlemail.com> wrote:
> 
> 
>> On 18. Apr 2018, at 12:30, Gyan Doshi <gyandoshi at gmail.com> wrote:
>> 
>> 
>> 
>> On 4/18/2018 3:19 PM, Daniel Oberhoff wrote:
>> 
>>> Ok, i investigated some further. The source of the problem seem to be the start offsets that are “weird” around hls. For one all our hls recordings report a start offset of 1.4s, and we have no idea where that is from (the source has no such offset).
>> 
>> I haven't looked at your console output yet, but this is the demux/decode delay used in MPEG-TS files.
>> 
>> Add -muxdelay 0 to your HLS generation command to skip this offset.
> 
> ok, i cannot find any documentation about the concept of these delays. so you have a pointer?


I just played with this option. So when generating hls it reduces the offset, but not completely. i.e. in one test instead of 1.4s i have 0.08s. This may seem small, but we use this on clips which later get concatenated, and there 80ms is perceivable and annoying when playback moves from one segment to the next.

Also i was wondering, is it possible to do seeking/clipping with “sub-frame” accuracy? I.e. move to the middle between two frames, such that it will be displayed on for a fraction of the time? Same with clipping (i.e. -t)? Again, for concatenating continuous segments this otherwise leads to perceivable jitter. We do have a workaround by using a fixed fps and quantizing manually and using -vframes, but it feels very kludgy.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://ffmpeg.org/pipermail/ffmpeg-user/attachments/20180419/a037286d/attachment.sig>