Video Streaming Corruption

[Taylor]

Hello

We have an issue were a number of users have been getting corrupted videos using the stream publishing but we are unable to figure out why or re-create it.

We think one of the factors may be the OS - Browser, Windows 10 - Chrome, as they all have the same user agent, however when we attempted on the same OS - Browser it went through fine.

I cannot share the videos for privacy reasons, so I'm hoping that by at least sharing the meta-data there might be a pattern/hint that'll lead to fixing it. Our only idea is that it's either due to the Os - Browser or a poor internet connection.

Each of them have attempted to do recordings multiple times but have ended up with the same results.

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.54 Safari/537.36
OS: Windows 10
Browser: Chrome

WCS: 5.2.944-5acbc64fdeb97e83bdf77d41ee2b17e1e4059e73
Web SDK: 2.0.168-a8c61f9ba0f76ff2f159a4ca4cf1f355c27f59e1

Media Server Settings:
periodic_fir_request=true
record_audio_codec_channels=1

Video 1:

File Size: 47.7kB​

Duration: 0 seconds​

Video - Dimensions: 320x240​

Video - Codec: H.264 (Constrained Baseline Profile)​

Video - Frame Rate: 20 fps​

Video - Bit Rate: 7514 kbps​

Audio - Codec: N/A​

Audio - Channels: 0​

Audio - Sample Rate: 0 Hz​

Audio - Bit Rate: N/A​

Time Between Start and Stop Streaming: 60 seconds approx.​

Video 2:

File Size: 64.1kB​

Duration: 1 second​

Video - Dimensions: 320x240​

Video - Codec: H.264 (Constrained Baseline Profile)​

Video - Frame Rate: 30 fps​

Video - Bit Rate: 397 kbps​

Audio - Codec: MPEG-4 AAC​

Audio - Channels: Mono​

Audio - Sample Rate: 44100 Hz​

Audio - Bit Rate: 74 kbps​

Time Between Start and Stop Streaming: 50 seconds approx.​

Video 3:

File Size: 8.2kB​

Duration: 0 seconds​

Video - Dimensions: 320x240​

Video - Codec: H.264 (Constrained Baseline Profile)​

Video - Frame Rate: N/A​

Video - Bit Rate: N/A​

Audio - Codec: N/A​

Audio - Channels: 0​

Audio - Sample Rate: 0 Hz​

Audio - Bit Rate: N/A​

Time Between Start and Stop Streaming: 19 seconds approx.​

Video 4:

File Size: 42.5kB​

Duration: 0 seconds​

Video - Dimensions: 320x240​

Video - Codec: H.264 (Constrained Baseline Profile)​

Video - Frame Rate: 13 fps​

Video - Bit Rate: 2499 kbps​

Audio - Codec: MPEG-4 AAC​

Audio - Channels: Mono​

Audio - Sample Rate: 44100 Hz​

Audio - Bit Rate: 74kbps​

Time Between Start and Stop Streaming: 58 seconds approx.​

Video 5:

File Size: 23.2kB​

Duration: 0 seconds​

Video - Dimensions: 320x240​

Video - Codec: H.264 (Constrained Baseline Profile)​

Video - Frame Rate: 30.33 fps​

Video - Bit Rate: 5434 kbps​

Audio - Codec: N/A​

Audio - Channels: 0​

Audio - Sample Rate: 0 Hz​

Audio - Bit Rate: N/A​

Time Between Start and Stop Streaming: 49 seconds approx.​

Our recorded video for comparison (working fine):

File Size: 252.2kB​

Duration: 5 seconds​

Video - Dimensions: 320x240​

Video - Codec: H.264 (Constrained Baseline Profile)​

Video - Frame Rate: 25 fps​

Video - Bit Rate: 296 kbps​

Audio - Codec: MPEG-4 AAC​

Audio - Channels: Mono​

Audio - Sample Rate: 44100 Hz​

Audio - Bit Rate: 74 kbps​

Time Between Start and Stop Streaming: 5 seconds​

Thanks

 

[Max]

Good day.

I cannot share the videos for privacy reasons, so I'm hoping that by at least sharing the meta-data there might be a pattern/hint that'll lead to fixing it. Our only idea is that it's either due to the Os - Browser or a poor internet connection.

This seems like publisher channel issue. For all the corrupted recordings duration is shown 0 or 1 second, and file size is too small for corresponding publishing time. This means packets loss, or audio-video synchronization problems, or both reasons leading to a small amount of media data in file.
So you should recommend to those clients to use more reliable network, for example LTE instaed of 3G, Wi-Fi instead of LTE, wired connection instead of Wi-Fi etc.
Also, you can use TCP for publishing, this should help to eliminate packet loss.

session.createStream({
    name: streamName,
    display: localVideo,
    ...
    transport: "TCP"
}).on(STREAM_STATUS.PUBLISHING, function (stream) {
...
}).publish();

Some our customers also claim the latest Chrome build 95.0.4638.54 problems on relatively old GPUs. The main symptom is 100% GPU load in Chrome task manager. In this case, hardware acceleration disabling in browser settings may help.

 

[Taylor]

Hello Max

Thank you for the quick reply. This is the kind of answer I was hoping for.

I will let the team know about the potential issue with the latest Chrome build and what we can do regarding the potential issue that it's due to an unreliable network.

As for setting transport publishing to TCP, while that is definitely something I'd like to try out, since we cannot recreate the issue and it'll require code changes, it may not be possible for me to implement and test this at this time.

Once again, thank you so much for the reply.