Audio stream over RTSP problem on new system

[fleduc]

hello i have issues with the definitive system where I lose audio once In flashphoner. It worked with the demo on another system but not anymore with the definitive one.
I can read the stream with video and audio in VLC but I lose audio in flashphoner on your demo page or on my system .
I can send you the stream address if you want to test .
Thanks

 

[fleduc]

i restarted but my demo system . It worked under v.0.5.28.2753-5.2.771 but not anymore on v.0.5.28.2753-5.2.788 even on your demo system. I stream rtsp to webrtc

 

[Max]

Hello

Please send your RTSP url using this private form
We will check on our demo server.

 

[Max]

We checked your stream.
Seems like something is wrong with the stream itself: VLC shows audio track is playing, but there's no sound (silence)

WCS 5.2.771 also shows low audio bitrate, huge video bitrate, and lost packets counters are growing both for audio and video

So we raised the ticket WCS-2929 to investigate it and confirm that latest WCS build shows 0 of audio packets in this case.
At your side, please check your stream source and provide a stream with lower video bitrate to exclude channel bandwidth issues, and with some non-silent audio to test playback.

 

[fleduc]

Hello sorry for the delay . The stream has to be an high quality lowest delay, this is the reason of the high quality . This stream content is changing most of the time, this may explain why you didn't hear any sound at the moment you tested. The streamer is an Aja Helo streaming an H264 constrained @5 Mbps audio 128kps MP4 aac. I still have the issue on your demo link but it's ok on the 771 version I rolled back .

 

[Max]

Please provide a stream from Aja Helo with the following parameters:
- availability 24/7
- non still picture (a timer for example)
- non silent audio (permanent music for example
- bitrate no more than 2500 kbps to exclude channel bandwidth issues
Then, we'll reproduce the issue on our development servers and find a fix or workaround.
If you cannot provide the test stream, please collect a report on the latest WCS build as described here. The report must include:
- publishing client debug logs
- traffic dump
The traffic dump collection should be started after restarting WCS and before RTSP stream capturing, a couple of minutes should be enough.
Please use this private form to send a link to report (it will probably exceed 30 Mb limit to send by email)

 

[fleduc]

Ok, it will be complicated as all the streams are used all day long through vlc for end-user review and approval . I have no way to manage or change the content off what is streamed and when it is . The final idea is to publish on the client website for easier customer access than VLC. Currently on build 771 on the server we have no issues on chrome but video quality issues on safari desktop and mobile and jittered sound. If we switch to 793 we will lose the sound playback. What I can do is the same thing on my test server that I will update and I send you the debug from it. I will need a new demo license to do the test. Is it ok for you ?

 

[Max]

What I can do is the same thing on my test server that I will update and I send you the debug from it. I will need a new demo license to do the test. Is it ok for you ?

Yes, the report can be collected on any server where issue can be reproduced. Please request a trial license here (you can use another email which was not used to get trial before).

 

[fleduc]

Did you get the report I sent you through email ? Thanks

 

[Max]

We received your report. Unfortunately, it contains neither publishing client debug logs nor traffic dump. Maybe it seems too complicated for you
So we need non-still image and non-silent audio in your RTSP stream 24/7 to debug the issue.

 

[Max]

We found an issue on streamer side, there is no audio channels data in RSTP stream SDP. We'll prepare a fix on our side.

 

[fleduc]

Thanks ! Please keep me in touch .

 

[Max]

Good day.
We fixed the issue in build 5.2.803. Please update and check.

 

[fleduc]

Hello, updated to the last build this morning . Sound is now ok in Chrome , but it is still jittering in safari (iOS & Mac OS ) and the video quality is way lower than in chrome. Any idea why ?
Thanks

 

[Max]

Hello

We will re-check your stream if it is reachable.
If not, please send RTSP url from the report page.

 

[Max]

We have tested your URL in VLC.
rtsp://host.net:555/test

No sound. Silence.
Please setup a stream with even sound. We will check on iOS and report.

 

[fleduc]

As reported in the comment area of the rtsp link it will be available with video and Audio in 4 hours for 12 hours . The current stream is silent because this user does not work on sound right now .

 

[Max]

Sound is now ok in Chrome , but it is still jittering in safari (iOS & Mac OS )

Please add the following setting to flashphoner.properties file

opus.encoder.bitrate=64000

In this case, sound is good via WebRTC.

and the video quality is way lower than in chrome. Any idea why ?

Seems like stream video bitrate drops while playing it in Safari browser. We raised internal ticket WCS-2965 to investigate it, please keep the RTSP stream available.
As workaround, you can play the stream in Safari with transcoding to raise video bitrate. This can be set on client side with constraints:

session.createStream({
      name: streamName,
      display: remoteVideo,
      flashShowFullScreenButton: true,
      constraints: {
            audio: true,
            video: {
                width: 1920,
               height: 1080,
                bitrate: 3000
            }
        }
        ...
     }
     ...
).play();

You can also play the stream via HLS in Safari if playback delay is acceptable. In this case, add the following settings to flashphoner.properties

hls_player_width=1920
hls_player_height=1080
hls_min_list_size=2

WCS needs to be restarted to apply the settings.

 

[fleduc]

we are running v.0.5.28.2753-5.2.816- and it does not change anything adding opus.encoder.bitrate=64000.
We'll try your workaround .
Thanks

 

[Max]

Good day.
We fixed the issue in build 5.2.820. Your camera does not set H264 packetization mode in stream SDP, and publish the stream with packetization mode 1. This violates the specification which requires to set packetization mode by default to 0 if it cannot be received from in stream SDP. To workaround this, update the server to build 5.2.820 and add the following parameter to flashphoner.properties

default_packetization_mode=1