WebRTC:VP8 player loader keeps spinning

[Peter P.]

Hi
We have an issue with the VP8 codec that is not present in 5.2.940 but seems to have started from 5.2.944 (maybe even 5.2.942) and newer.
Unfortunately, it is a bit difficult to reproduce. It helps leaving out H264 in the flashphoner.properties file codecs list and then starting and stopping
the stream from the sending side. We cannot reproduce it by using demo.flashphoner.com and simply stripping the H264 codec.
The issue has been reproduced on both Chrome and Edge.
The receiving video player will then keep on spinning its loading graphics and not show the video, even though the browser seems to be receiving network trafic corresponding to receiving a video.

I hope you can help
Please let me know if you need more info.

 

[Max]

Good day
Please clarify: do you stripping H264 codec from server settings like this:

#codecs                   =opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,h264,vp8,flv,mpv
codecs                   =opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,vp8,flv,mpv

If yes, how do you play a stream: via WebRTC or via HLS? In the last case, only audio can be played because HLS supports H264 only.
Please also check if the problem is reproducing in Media Devices example, it will show some WebRTC stats for publisher and player, so you can see if media packets are sent and received

Usually, playback cannot be started if no keyframes received from publisher. In this case, the parameter

periodic_fir_reques=true

should help
Also, Web SDK should be updated to latest build 2.0.168 when using WCS build 5.2.942 and later.

 

[Peter P.]

Hi Max,
Thanks for the quick reply.
To answer your questions we strip H264 the way you described it and use Webrtc.
We already have periodic_fir_request=true and the newest WebSDK.
Unfortunately, we cannot reproduce it on your demo site (we cannot change flashphoner.properties) and on our server we have shutdown the demo feature. But I will see if we can enable the demo on our site to get more info.

 

[Max]

Unfortunately, we cannot reproduce it on your demo site (we cannot change flashphoner.properties) and on our server we have shutdown the demo feature. But I will see if we can enable the demo on our site to get more info.

You can deploy Web SDK examples to another web server and connect to your WCS server via websocket wss://your-wcs-server:8443. So it is not necessary to enable demo feature, just open websocket port 8443 and WebRTC media ports to test.
If the problem is reproducing with Media Devices example, please collect a report as described here, including traffic dump at server side. The traffic dump should be started to collect before stream publishing. Then, send the report archive using this form.

 

[Peter P.]

Hi Max,

We finally have some time to look into the issue again.
The form you have provided fails with the following error:

Cообщение <1628152969.610ba4897c40a@flashphoner.com> для support@flashphoner.com не было доставлено через ApMailer\Smtp. Ошибка: 104: Не удалось считать данные из сокета. Ошибка: Undefined index: cert_private_key

We have discovered that the issue does not happen when we change the constraints:

Sending constraints	Receiving constraints	Has issue?
audio:false	no constraints set (defaults to true)	YES
audio:true	audio:true	No
audio:false	audio:false	No

Furthermore, we are receiving this error when it happens in the server_logs:

ERROR RtpVideoPlayer - STUN-UDP-pool-41-thread-2 Full buffer and no synchronization, force it

In that relation we have tried the suggestion in this thread setting the following option:

video_incoming_buffer_size=100

But that did not work either.

 

[Max]

We have discovered that the issue does not happen when we change the constraints:

We tried to reproduce the issue with our demo server in Media Devices example (to easily change the constraints). It is playing correctly:

Server build on demo: 5.2.998, WebSDK build 2.0.180
Please check if the issue reproducing in MediaDevice example on your server. If yes, please provide SSH access to your server with publishing/playing ability using this form.

The form you have provided fails with the following error:

We received your report, but we see a lot of streams which is published on a short time. And we do not see any keyframes from publisher.
Please check if periodic FIR request is enabled

periodic_fir_reques=true

Furthermore, we are receiving this error when it happens in the server_logs:

This is normal behavior if you're publishing video only stream. No audio, so it cannot be synchronized with video.

We have discovered that the issue does not happen when we change the constraints:

Again: we cannot reproduce this. But the workaround is simple: set the constraints properly at players end.

 

[Peter P.]

Thank you for your help!

We have tried to create a test case on media devices, but it is apparently not easy to reproduce
For now we will just try to keep the constraints the same on both ends, but might return to this issue
at a later point in time.

Best regards
Peter