Audio-only RTMP/HLS bug in 3.2

[jorbig]

We're streaming AAC audio only (32kbps, 22050hz) using RTMP and HLS, but this doesn't work in 3.2, while it does in the versions before. I've tried this with both the native Linux app and also with Docker. Do you need more details or do you already know what the problem is?

[Rokamun]

Hey Jorbig,

Tried it out and can confirm it seems to be an audio only problem. Bitrate or hz of the audio doesn't seem to matter. Should be able to identify what the problem is and fix it with this. I'll let you know once we've made some progress. Thanks for reporting it!

[Rokamun]

Hey there,

Managed to find the problem and resolve it. Fixed in the newest development branch: fd340c97c220e9ab28e5d9232ea58f4b1b351008

If you donwload the newest development builds you'd have the fix: https://r.mistserver.org/dl/mistserver_64Vdev.tar.gz

curl -o - https://releases.mistserver.org/is/mistserver_64Vdev.tar.gz 2>/dev/null | sh

[jorbig]

Thanks for your help! I updated successfully, but still don't get the stream working:

Wed 26 Apr 2023, 10:28:21 | FAIL | Push rejected - stream livestream not configured or unavailable
-- | -- | --
Wed 26 Apr 2023, 10:28:21 | FAIL | onFail 'livestream': Could not connect to stream data
Wed 26 Apr 2023, 10:28:21 | WARN | Unable to open page MstSessionIdc6685849b8db3956e26de62769bcfb719ff84bc31d08fc2a7fdaedac3fa5db3
Wed 26 Apr 2023, 10:28:12 | FAIL | onFail 'livestream': Could not connect to stream
Wed 26 Apr 2023, 10:28:12 | WARN | Unable to open page MstSessionIee882ef1759d89e3e2042a4fde6641b39917c2933cd151527954c2e1488733bc
Wed 26 Apr 2023, 10:28:11 | ERROR | Overwriting old page for MstSTATElivestream
Wed 26 Apr 2023, 10:28:11 | WARN | Received generic error response (no useful content)
Wed 26 Apr 2023, 10:28:02 | FAIL | Session 'Iee882ef1759d89e3e2042a4fde6641b39917c2933cd151527954c2e1488733bc' already locked
Wed 26 Apr 2023, 10:28:02 | WARN | Unable to open page MstSessionIee882ef1759d89e3e2042a4fde6641b39917c2933cd151527954c2e1488733bc
Wed 26 Apr 2023, 10:27:52 | FAIL | Session 'Iee882ef1759d89e3e2042a4fde6641b39917c2933cd151527954c2e1488733bc' already locked
Wed 26 Apr 2023, 10:27:52 | WARN | Unable to open page MstSessionIee882ef1759d89e3e2042a4fde6641b39917c2933cd151527954c2e1488733bc
Wed 26 Apr 2023, 10:27:41 | ERROR | Overwriting old page for MstSTATElivestream
Wed 26 Apr 2023, 10:27:41 | WARN | Received generic error response (no useful content)

I remember ERROR | Overwriting old page for MstSTATElivestream showed up with 3.2 as well, but not with 3.1 and before.

[Rokamun]

That's hinting to the stream livestream being uncleanly shut down and most likely losing it's settings as well if I look at the top log message (as it's saying it's not configured or unavailable. That either means it's locked in shared memory or simply no longer configured).

It might be worth doing a full reset of shared memory to clean up these issues.

You might want to first go to the overview to force the configuration save. Though you could already have some settings missing. It looks like the stream you're trying to push already doesn't exist anymore.

systemctl stop mistserver
rm /dev/shm/*Mst*
systemctl start mistserver

After that try again, but double check whether livestream is still in the streams list as well.

[jorbig]

Thanks, that did the trick indeed. Thank you so much for this very quick bug fix! It even seems that in this version, compared to 3.1 and before, a strange issue is solved where the stream (apparently only) on iOS 15 stopped playback within a minute or so. Does this sound familiar to you?

[nerijus]

The fix is:

diff --git a/src/output/output_hls.cpp b/src/output/output_hls.cpp
index 3add64d1..aad80190 100644
--- a/src/output/output_hls.cpp
+++ b/src/output/output_hls.cpp
@@ -320,7 +320,7 @@ namespace Mist{
         userSelect.clear();
         userSelect[vidTrack].reload(streamName, vidTrack);
         targetParams["video"] = JSON::Value(vidTrack).asString();
-        targetParams["audio"] = "none";
+        targetParams["video"] = JSON::Value(vidTrack).asString();
       }else{
         userSelect.clear();
         userSelect[vidTrack].reload(streamName, vidTrack);

There are 2 identical targetParams["video"] lines now.

[Rokamun]

Hah, good find, that's a typo, should've been targetParams["audio"] we'll change that as well.

For the HLS working better on IOS, that could very well be. We rolled back some changes in HLS (TS based) output because we noticed that the changes we made for Low Latency HLS (TS based) weren't working great for stability. HLS (CMAF based) will still be low latency however.

[nerijus]

The last fix could still be incorrect, as it is now:

        targetParams["video"] = JSON::Value(vidTrack).asString();
        targetParams["audio"] = JSON::Value(vidTrack).asString();

while a few lines below:

        targetParams["video"] = JSON::Value(vidTrack).asString();
        targetParams["audio"] = JSON::Value(audTrack).asString();

The difference is vidTrack vs audTrack.

[nerijus]

ping @Rokamun , it seems it is still not fixed?

[Rokamun]

Forgot to answer I see (or it didn't go through via mail support, not sure which).

That's actually not a typo, despite the commit message saying typo :)

In the track selection of the HLS protocol Mistserver will always try to do vidTrack_audTrack. (For example: http://serveraddress:8080/hls/streamname/1_2/index.m3u8 where 1 would be the video track and 2 would be the audio track that is selected)

Now in the case that there's only 1 track it'll attempt to still put the audtrack as the "second" track to be selected, which is impossible if there's only 1 and the HLS url ends up breaking. (using the same example, but there's only 1 track and it's audio: http://serveraddress:8080/hls/streamname/_1/index.m3u8 is not a valid link)

This part of code tells MistServer that it's allowed to put the audio in the vidTrack part of the url if there's only 1 type of track to be selected. (making it http://serveraddress:8080/hls/streamname/1/index.m3u8 which will properly work)