GNOME Bugzilla – Bug 794440
hlssink2: Inconsistent fragment duration
Last modified: 2018-03-19 10:25:16 UTC
This bug must be related to splitmuxsink's behavior, that is, the "send-keyframe-requests" property cannot produce consistent fragment duration. To reproduce this bug, below command was used and then the segment duration always fluctuates between 5 ~ 10 seconds. gst-launch-1.0 videotestsrc ! queue ! x264enc ! h264parse ! hlssink2
Have you tried configuring the key-max-int to max into ? Otherwise don't you end up with a mix of requested IDR and the automatic IDR from x264 ?
(In reply to Nicolas Dufresne (stormer) from comment #1) > Have you tried configuring the key-max-int to max into ? Otherwise don't > you end up with a mix of requested IDR and the automatic IDR from x264 ? I tried to configuring key-max-int to very large value and the result was also weird... gst-launch-1.0 videotestsrc ! queue ! x264enc key-int-max=20000000 ! h264parse ! hlssink2 With very large key-max-int value like above command, the splitmuxsink request keyframe only the first time at https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/multifile/gstsplitmuxsink.c#n1726 And then, I could not observe the next request from splitmuxsink.
I can confirm this here. This is a regression in splitmuxsink, it worked not too long ago correctly.
GIT bisect leads to commit 76e458a119926424e9dd5acf3210a592a314d713 Author: Jan Schmidt <jan@centricular.com> Date: Tue Apr 7 23:53:19 2015 +1000 splitmuxsink: Use muxer reserved space properties if present. If the use-robust-muxing property is set, check if the assigned muxer has reserved-max-duration and reserved-duration-remaining properties, and if so set the configured maximum duration to the reserved-max-duration property, and monitor the remaining space to start a new file if the reserved header space is about to run out - even though it never ought to.
Created attachment 369855 [details] [review] splitmuxsink: Allow splitting at exactly the time/bytes threshold 76e458a119926424e9dd5acf3210a592a314d713 changed the conditions from "queued > threshold" to "queued >= threshold", which broke hlssink2 and resulting in too small fragments being created although keyframes would be at *exactly* the configured threshold.
I'm not entirely sure about the > if (queued_gop_time >= mux_reserved_remain) { line in the same function.
Attachment 369855 [details] pushed as 42f5f3d - splitmuxsink: Allow splitting at exactly the time/bytes threshold