> On 19. Apr 2018, at 14:48, Daniel Oberhoff <[email protected]> > wrote: > > >> On 18. Apr 2018, at 12:30, Gyan Doshi <[email protected]> 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.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
