WCS 5.2.1431 Firefox 320x240 H264 stream not working

S

SLM

Member
Just updated WCS to 5.2.1431 and tested it with the demo tools.

Using Firefox 105.0.2 tried the Two way streaming demo. It fails although without errors. Publishing seems to work, clicking on Available reports that the stream is indeed available, and it also said 'Playing', but no stream is displayed (not even a black screen) and no error is produced not even after some time.

Opening Chrome 106.0 I tried to play the stream I published in Firefox using the Player demo. Also no errors but also no stream displayed.

Stopping the publish in Firefox and then starting to publish in Chrome in stead, everything works fine. Publish is okay, playing is okay too. Opening the Player demo in Firefox I started the stream I published in Chrome and this also works.

Media devices
Then I tried the Media Devices demo in Firefox. Without changing any parameters, this test immediately worked (both in Firefox and Chrome). However, I noticed that the stream produced and published in the Two Way Streaming demo in Firefox is a 320x240 pixel stream and the one in Media Devices is 640x480.

When in Firefox I set the dimensions to 320x240 in Media Devices, the playing of the stream also fails (tried playing in Firefox and Chrome).
When in Chrome I set the dimensions to 320x240 in Media Devices, the playing of the stream works both in Chrome and Firefox.

Also noticed that:
When in Firefox I set the dimensions to 320x240 in Media Devices AND strip codec H264, the playing of the stream works fine in Firefox and Chrome (published stream is a VP8 stream by the way).

Anyway, I don't know why a published 320x240 H264 stream in Firefox is not playing in both Firefox and Chrome, but this means I have to revert back to an old WCS version because Firefox is used by a lot of clients.
 
Max

Max

Administrator
Staff member
S

SLM

Member
Situation is reproduced on your demo server.

Tested FF at 13:02 Amsterdam time, stream 6f1d - FAIL
Tested Chrome at 13:04, stream d1db - OK
Played stream d1fb on FF - OK
Tested FF with Media Devices 640x480 at 13:06, stream eff6 - OK
Tested FF with Media Devices 320x240 at 13:08 stream 9d9a - FAIL
Same but strip codec H254 at 13:09 - OK

Edit/
- Device is HP Omen laptop with Windows 11 Home - 10.0.22000 Build 22000
- Processor Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz, 2592 MHz, 6 core('s), 12 logische processor(s)
- Video NVIDIA GeForce RTX 2060
- HP Wide Vision HD Camera

Edit 2/
And as I've said before, the fail is not a hard fail with an error, it just doesn't show the stream on any device or browser when publishing 320x240 H264 in FF.
 
Last edited:
Max

Max

Administrator
Staff member
SLM said:
Same but strip codec H254 at 13:09 - OK

- Video NVIDIA GeForce RTX 2060
Click to expand...
Seems like this is a hardware issue. Please check Bitrate value in publishers statistics at left:
1665364890975.png

If this is 0, it means the browser does not send media traffic at all.
So disabling hardware acceleration in Firefox should help. Clean Use hardware acceleration checkbox and restart browser
1665365073526.png

Or use VP8 codec to publish: browsers do not support hardware acceleration for this codec at all.
 
S

SLM

Member
Video stats
Codec: H264
Codec Rate: 90000
Bytes Sent: 717022
Packets Sent: 1002
Fir Count: 0
Nack Count: 0
Pli Count: 6
Height: 240
Width: 320
Bitrate: 389352


Audio stats
Codec: opus
Codec Rate: 48000
Bytes Sent: 37022
Packets Sent: 914
Nack Count: 0
Bitrate: 16888

---

At the player end:
Video stats

Audio stats

Connection
Quality: UNKNOWN


Also, if it's a hardware issue then we would at least expect an error.

Disabling hard acceleration in FF made no difference by the way.
 
Max

Max

Administrator
Staff member
SLM said:
Also, if it's a hardware issue then we would at least expect an error.
Click to expand...
Usually Javascript code has no access to a hardware layer in browser. So we can't detect a error if the browser does not raise an exception.
Please collect a report as described here including client debug logs and traffic dump (both are mandatory). The traffic dump collection must be started before the stream publishing. One minute is enough. Then, send the report archive (or link if archive size exceeds 30 M) using this form.
Another option is to provide 24/7 AnyDesk access to the PC where the issue is reproducing using this form.
 
S

SLM

Member
I've sent the report tar.

Tested:
FF publish and play (not displaying stream) with twowaystreaming demo
FF publish and play 640x480 with Media Devices demo (works fine)
Chrome publish and play with twowaystreaming demo (works fine) and display same stream in FF (works fine)
 
S

SLM

Member
Also note that :
1. this issue does NOT happen on WCS 5.2.1299 (publishes and streams correctly at 320x240 H264 in FF)
2. publishing a 320x240 H264 stream on a server with WCS 5.2.1299 plays fine in the demo player in FF on a server with WCS 5.2.1431
3. the same issue happens with an external webcam HP Webcam HD2300 on the same laptop
4. the same issue noes NOT happen in Firefox on another laptop, HP Pro Book 450 G6 with WIndows 10 Pro, intel i7-8565u cpu 1.8 ghz, intel uhd graphics 620 and the built in HP HD camera.
 
Max

Max

Administrator
Staff member
We checked the report. Unfortunately, it contains no traffic dump, so we can't reproduce the issue on our test servers, we only can to analyze the logs.
Seems like Firefox does not send key frames while publishing 320x240. Please enable periodic key frame request in server settings:
Code: 
periodic_fir_request=true
If this does not help, enable strict keyframe detection:
Code: 
h264_strict_kframe_detect=true
If this does not help, we need either client debug logs and traffic dump or 24/7 AnyDesk access to the PC where the issue is reproducing.
 
S

SLM

Member
Sorry about that, I already wondered why the log was so small. Forgot to include the pcap, which I sent via Wetransfer just now.

Later today I will test the two settings mentioned above.
 
Max

Max

Administrator
Staff member
We raised the ticket WCS-3613 to investigate the issue. But it may take a time, we'll inform you about progress. A possible workarounds:
1. Do not use 320x240 resolution in Firefox (for example, use 320x180 if it works)
2. Or use VP8 codec

You can also try to enable a strict jitter buffer to collect a frames, it may help too:
Code: 
use_strict_jitter_buffer=true 
jitter_buffer_capacity=30
 
Last edited:
S

SLM

Member
use_strict_jitter_buffer=true
jitter_buffer_capacity=30

Unfortunately this also makes no difference.

What is the consequence of forcing publish to VP8 ? Doesn't that mean a lot of transcoding?
 
Max

Max

Administrator
Staff member
SLM said:
What is the consequence of forcing publish to VP8 ? Doesn't that mean a lot of transcoding?
Click to expand...
VP8 codec is supported by all the modern browsers and OSes, so it can be played without transcoding. But you will need VP8 to H264 transcoding if you're republishing VP8 stream to a third party RTMP server or playing the stream as RTMP from WCS (because RTMP supports only H264) or if you're using Multiple stream recording to one file with subsequent mixing functions (because MKV support for multiple recording is on pre-production testing stage yet).
 
Max

Max

Administrator
Staff member
Good day.
We fixed the issue with keyframe detection in build 5.2.1460. Now, H264 320x240 stream published from Firefox on NVIDIA GPU should play correctly.
Please note that in the dump you provided there is only one keyframe in the beginning of the stream, so it may not play for subscribes who connect later. periodic_fir_request option should help in this case.
 
You must log in or register to reply here.
Top