obsproject
OBS can generate non-compliant, unjoinable HLS streams
Operating System Info
Ubuntu 22.10
Other OS
No response
OBS Studio Version
29.0.1
OBS Studio Version (Other)
No response
OBS Studio Log URL
n/a
OBS Studio Crash Log URL
No response
Expected Behavior
HLS requires that each media segment be independently decodable, this ensures that a decoder can join at any point in the stream.
Current Behavior
Under certain configurations, OBS can generate HLS uploads whose media segments are not independently decodable, resulting in an unjoinable stream.
For context: I work at YouTube on Live streaming. Today YouTube is able to support noncompliant HLS uploads from OBS, albeit with reduced reliability of the resulting live stream broadcasts. It would be nice if OBS would always produce compliant HLS streams; then in the future, YouTube could eventually begin to reject noncompliant HLS.
The root cause of this lies within FFmpeg: https://trac.ffmpeg.org/ticket/10148
The purpose of this ticket is to make the problem more discoverable, and get more eyeballs on it. I don't expect we'll need any code change within OBS proper to fix it.
Steps to Reproduce
Stream HLS to YouTube or elsewhere.
Use the x264 software encoder, and set x264 options 'aud=1 global-header=1'.
The stream will "work" but in fact it's unjoinable at all segments after the first. These segments do not include the SPS and PPS metadata needed for a decoder to join.
I suspect the same problem occurs with hardware encoders that happen to behave similarly to those x264 settings, but I haven't confirmed this.
Anything else we should know?
No response
To confirm this since it's not clear in the report, when you say "use the x264 software encoder" you mean by configuring it through the ffmpeg Custom Output mode in advanced recording settings, correct? We don't use ffmpeg for x264 under any other circumstances.
EDIT: The question is still relevant for any troubleshooting, but I see that the bug is with the muxing process, not the encode.
As an additional note, in the future please provide log files when opening issue reports, even if you feel they are not relevant they contain invaluable environment information.
No, this isn't Custom Output mode, just normal HLS output.
And yes, it's the muxer that has trouble. IIRC, obs-ffmpeg-mux calls libavformat (from FFmpeg) which contains mpegtsenc.c where the bug is.
Isn't this effectively a duplicate of #7954 ?
Please always provide a log file.
When will be the next OBS update? Can we make sure the FFmpeg fix https://github.com/FFmpeg/FFmpeg/commit/e0cb89c354ea654bccc524a8a45321b93cb256d3 is included in the next update?
Yes, this looks like it's probably a dup of #7954.
BTW the fix in FFmpeg exists in both master and in the release/6.0 branch already.
I'm trying to understand the scope of this. Obviously ffmpeg 6.0 introduces/fixes functionality to retransmit PPS/SPS headers for each segment, however we have the repeat_headers option on all AVC encoders in OBS, which in theory should provide the same result. When this option is enabled, however, is not reliable.
My question is: Since there are no OBS logs attached to this issue, can you verify whether ensuring that this setting is on affects the joinability of the produced segments?
Checking in on this. Do we know if repeat_headers affects the behavior here?
Here's the log file from a representative run: https://obsproject.com/logs/gBsHy7G5LzTpZyTr
Sorry for not including that originally.
The log shows passing "aud=1 global_header=1" to the x264 encoder, which is a reliable way to see the bug with no dependency on a hardware encoder.
This may not be representative. I'll guess that most instances of this bug in the wild are not using x264, but some hardware encoder that emits AUDs (same behavior as "aud=1") and also emits a global header instead of repeating headers (same behavior as "global_header=1")
The "repeat_headers" bit should avoid the bug if the encoder respects it. Some HW encoders or their drivers may ignore repeat_headers. It doesn't appear that VA-API has any way to pass the repeat_headers signal through to the underlying hardware and driver so there's no guarantee about its behavior.
Two VA-API hardware encoders available to me did not tickle the bug. They were a recent Intel iGPU and an AMD radeon rx6600. Both repeat headers by default.