Video submission issues with Safari 12.1

[Taylor]

Hi

I have been testing Flashphoner in my UAT server across various browsers and devices to confirm that they successfully stream and save the video to the server.

All browsers have been working except for Safari (12.1.1) on Mac (Mojave 10.14.5). I've been getting two different errors and both errors don't always occur (Occurs about 10% of the time).

Issue 1: No Video Saved
This one seems to happen on my UAT site but not on the Flashphoner demo page.

Flashphoner establishes a session, creates and starts publishing a stream, returning a status of "Publishing", and the local video is displaying correctly. When stopping the stream I get a status of "Unpublished" and therefore assume that the video has successfully been published but when I try to find the video on the server it isn't there.

I've gone over the logs for it and found a couple of error logs + inconsistent logs:

23:37:47,025 ERROR       H264AccessUnit - STUN-UDP-pool-38-thread-103 Failed to parse H264 bitstream, Failed to parse H264 frame, no packets

In "issue1-client-flashhphoner.txt" log, line 59.

23:38:56,905 INFO              WSClient - WSClientsKeepaliveThread-72 Close connection for channel [id: 0x548bb1e4, /***.***.***.***:51998 => /10.0.0.140:443] with status code: 1000 ; reason: Disconnected by keep alive

In "issue1-server-flashphoner.txt" log, line 628 (which is different from the usual "Disconnected by closed channel" messages).

Issue 2: Corrupted Video Duration
This one was easier to recreate on the Flashphoner demo page but also didn't happen all the time.

Again Flashphoner successfully goes through establishing a session and publishing then "Unpublished" the stream, the difference being the this time the video can be found in the media server. The issue this time is that it saved with a duration of ~600,000 hours for a video that roughly went for 10 seconds.

Again I've gone over the logs for it and found this:

02:07:34,086 ERROR       RtpVideoPlayer - STUN-UDP-pool-38-thread-105 Full buffer and no synchronization, force it

In "issue2-client-flashphoner.txt" log, line 59.

Some additional configurations made to the server are:

• Setting the WSS port to be on 443 instead of 8443.
• Setting the stream_record_policy to use the stream name.

Any help on either of these issues will be greatly appreciated.

 

[Max]

Good day.
We will test a WCS with this case and write to you a little later.
Write which a WCS version you are using:

cat {WCS directory}/conf/WCS.version

and WebSDK version:

cat {WCS directoty}/client2/client.version

 

[Taylor]

Hi Max

The WCS version is: 5.2.108-3a8140311c1e80789857b139189acf4e74af6e2d
and WebSDK version is: 0.5.28.2753-218c188ea896656b1ca142f02b4f58bf09bd8bf1

 

[Max]

Good day.
Please update your server to the latest build 5.2.220 from this page, it also includes update for WebSDK.
If problem still persists after update, please collect a report as described here, including traffic dump, and send it to support@flashphoner.com. Please do not modify logs and configs collected, they should be sent as is. Our engineers will check.

 

[Taylor]

Hi Max

Currently updating the server with WCS 5.2.220, still need some time to troubleshoot since it's an Amazon EC2 instance that's manually being updated.
Can I get any idea when the latest WCS version will be uploaded to the Amazon Marketplace?

Cheers

 

[Max]

Good day.
The WCS version in Amazon Marketplace will be updated in the coming days.

 

[Max]

Good day.

We have checked report you sent by email and answer your questions:
1. "Overconstrained error" is Webkit issue. Safari can read min and max properties, but does not allow to stream in some resolution. Please check this test https://webrtchacks.github.io/WebRTC-Camera-Resolution/
If ideal property is set, Safari 12.1 and later handles it correctly and scales video to closest supported resolution, but Safari 12 on iOS 12.1 does not. So we had to rollback this fix.
We plan to add ability to set width anf height constraints properties on client side, without WebSDK modifying (internal ticket WCS-2145) and let you know when it's done.
2. The parameter stream_record_policy is obsoleted since buld 5.2.142 due to strong recording refactoring. You should use stream_record_policy_template parameter, fro example
stream_record_policy_template={streamName}
3. Concerning corrupted recordings, seems like incoming stream is out of sync. Please check if issue persists when publishing stream from another source (Chrome browser, other PC/Mac). If yes, and if the issue is not reproduced with our demo server https://demo.flashphoner.com/client2/examples/demo/streaming/stream_recording/recording.html, please check the channel bandwidth and quality between your stream source and UAT server.
Also please provide us corrupted recording files written while collecting the report. If is is not possible, collect a report again, including corrupted recordings example.

 

[Max]

Good day.
We added the ability to set video resolution constraints as you need in WebSDK build 0.5.28.2753.109, so you don't need to modify falshphoner.js to do something like this:

publishStream = session.createStream({
    ...
    disableConstraintsNormalization: true,
    constraints {
        video: {
            width: {ideal: 1024},
            height: {ideal: 768}
        },
        audio: true
    }
}).on(STREAM_STATUS.PUBLISHING, function (publishStream) {
    ...
});
publishStream.publish();

See also doc here.

 

[Taylor]

Hi Max,

Sorry for being away for so long.

Thank you for the help relating to the Overconstrained Issue (https://forum.flashphoner.com/threa...ror-on-specific-version-of-imac-safari.12133/) and now I'm able to get back to finding out why this corruption issue is occuring.

From what I can make out the issue only occurs on Safari browsers, I'm unable to recreate it with other browsers such as Chrome.
Another point to add is that this only seems to be occuring on my demo server because when I try it out on your demo server I am unable to recreate the issue.

My Demo Server Version: v.0.5.28.2753-5.2.267-018743542d11cabedb2fdc2dd34e1fc68e676158
Flashphoner Demo Server Version: v.0.5.28.2753-5.2.266-78d92c941d9670f8ee7392a86fa906b3a71e49f2

There's most likely an issue with my server's configuration but don't have a clue as to why this is happening, especially since this used to work fine with WCS version 5.2.108.

I'll send some more detailed information to support@flashphoner.com and hopefully they'll have an idea as to why this is happening.

Cheers,
Taylor

 

[Max]

Good day.
We've checked your report. It seems like Safari browser sends only two keyframes at the beginning of stream publishing. Please set the following parameter in flashphoner.properties

periodic_fir_request=true

this should help to make browser send keyframes more regularly.

 

[Taylor]

Hey Max

I tried adding `periodic_fir_request=true` but unfortunately it didn't fix the issue.

 

[Max]

Good day.
Please collect a report with periodic_fir_request=true option enabled and send to support@flashphoner.com

 

[Max]

We have checked your logs and raised internal ticket WCS-2258 to investigate this. We let you know on results.

 

[Taylor]

Hi Max

Would like to know how the Safari Issue is going (WCS-2258 ticket).

Not trying to rush anything, just want to know if you're having any luck in recreating the issue or perhaps what the eta is on the solution.

Cheers,
Taylor

 

[Max]

Good day.
We cannot reproduce the issue using Safari 12.1.2 on Mac OS 10.14.6 in our test environment. So, our engineers try to reproduce the problem using logs and dumps you've provided.
Please also provide us SSH access to the server and TeamViewer access to Mac you've testing on, if possible.

 

[Taylor]

Hey Max

Thanks for getting back. I have just sent an email to support with the necessary information for both SSH access and TeamViewer access.

Cheers,
Taylor

 

[Taylor]

Hi Max

Thank you for your help. Adding:

periodic_fir_request=true
video_incoming_buffer_size=100

managed to successfully fix the Safari issue. We've tested multiple times on Safari as well as other devices and no time corruption issues are occurring. We've also checked the synchronisation between audio and video and that seems to be good too.

If it's not too much to ask can I ask why this solution managed to fix the problem. Would be helpful to note it down for later reference.

Cheers,
Taylor

 

[Max]

Good day.
By default, Safari browser sends 3 keyframes when stream is just published, then it stops sending keyframes for a very long time. The parameter

periodic_fir_request=true

makes Safari browser to send keyframes regularly. This affect recording if record rotation is used, new fragment should start from keyframe, so recorder has to wait for it.
In your case, the parameter

video_incoming_buffer_size=100

is the real solution. This parameter defines the count of video packets that should be received by server before if forces stream synchronization even if no audio packets received. By default this count is set to 20 packets, and the following happens:
1. Stream publishing starts, browser sends video packets with no audio
2. Server receives 20 packets and forces the stream synchronization (still with no audio). Video packets go to recorder.
3. Browser sends first audio packets after 30 video packets.
4. Server receives audio and recalculates synchronization. The packets with new synchronization time go to recorder, big synchronization jump brakes it, and recorder writes the wrong metadata to file.
When we set incoming buffer size to 100 packets, server waits until video and audio packets are received then calculates synchronization which is not jumping in this case.

 

[Max]

Good day.
Incoming video packets buffer size incremention is a temporary workaround in your case. Now we're working on permanent fix. Please provide us to support@flashphoner.com a couple of recording examples 2-3 minutes duration with picture and sound to test synchronization, if possible.

 

[Max]

Good day.
We have fixed synchronization issue which led to recording corruption in build 5.2.369. Please update and check.