SM
Software Mansion•4mo ago
odingrail

HTTP adaptive stream playlist is changing target duration on the fly

Greetings everyone. I hope you are doing well! I'm encountered very strange behaviour: I have following for my video track configuration: 
    [
      encoding: :H264,
      track_name: name,
      segment_duration: Membrane.Time.milliseconds(3000),
      max_framerate: 24
    ]
    [
      encoding: :H264,
      track_name: name,
      segment_duration: Membrane.Time.milliseconds(3000),
      max_framerate: 24
    ]
The similar segment_duration is configured for my AAC track. The behaviour is following: The video playlist is initialized with correct #EXT-X-TARGETDURATION of 3 Then parts starting to load, and they loading more then for 3 seconds. After the segment is completed, the #EXT-X-TARGETDURATION becomes 9 😵‍💫 The audio playlist is working just fine. Please help me to debug the issue and I'll create a PR with fix if it needed.
4 Replies
odingrail
odingrailOP•4mo ago
odingrail
odingrailOP•4mo ago
As a result, I have a problems with syncing 9 seconds video segment with 3 seconds audio ones.
varsill
varsill•4mo ago
Hello @odingrail ! Could you check what is the keyframe interval for your video stream? Based on the the produced playlist, it seems that the second keyframe appears almost 9s after the first one, so the segment duration is almost 9s. Even though you set the segment_duration to 3 seconds, it gets overriden, as according to the HLS RFC, the EXT-X-TARGETDURATION cannot be shorter than the duration of the longest segment. Best wishes!
odingrail
odingrailOP•4mo ago
Yeap, I can confirm the GOP size makes a difference. However, I still struggling to align the #EXT-X-TARGETDURATION:4 acoss the audio / video playlist. For some reason, the audio one is always shorter, for example if video is 4 the audio is 3. With video partial segment being consistent value I provided as partial_segment_duration and audio deviate from this value..

Did you find this page helpful?