GNOME Bugzilla – Bug 710203
hlssink doesnt fragment audio-only streams
Last modified: 2018-11-03 13:18:26 UTC
Test case: gst-launch-1.0 audiotestsrc ! faac ! mpegtsmux ! hlssink target-duration=2 doesnt generate new segments, while gst-launch-1.0 videotestsrc ! x264enc ! mpegtsmux ! hlssink target-duration=2 works without problems
faac is not forwarding GstForceKeyUnits downstream and mpegtsmux is not not tracking upstream event in the src pad, that's why it doesn't work. This patch for qtmux does that correctly if you want to take a look: https://bug660260.bugzilla-attachments.gnome.org/attachment.cgi?id=252750 I think for audio only streams you should be using AAC + ID3 according to the spec, which won't work either, in this case because id3mux doesn't support GstForceKeyUnit events.
Thanks Andoni, About mpegtsmux, seems that there is already a fix in bug #696032 ?
Created attachment 296203 [details] [review] mpegtsmux: respect force-key-unit when dealing with audio only This makes it work with the example from the reporter but even some audio formats require headers so there is some room for a 'key-unit' event for audio as well. The problem is that the event is defined in the video library. So should we create an audio or just go with the video one for audio?
This whole reliance on the force-key-unit events to do the actual switch-over seems broken to me. I don't think these make sense for audio-only, and I don't think it makes sense for audio encoders to handle them or create audio-specific ones.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/113.