Recording - first couple of seconds are skipped
I'm embedding a recorder into our pages, and there seems to be a lag between start of the recording as shown on the screen and the actual recording - when I view the saved video, the first ~4 seconds are missing. As a side effect, if recorded video is 5 seconds or shorter, Ziggeo is stuck verifying it forever, and Network tab in browser dev tools shows lots of server requests with "Cannot read the video" error.
Any idea why this is happening? The settings we use seem to be pretty straightforward:
ziggeoApp = new ZiggeoApi.V2.Application({
token: <app token>,
webrtc_streaming: true
});
recorder = new ZiggeoApi.V2.Recorder({
element: el,
attrs: {
theme: 'elevate',
themecolor: 'blue',
picksnapshots: false,
timelimit: 120,
'expiration-days': 90,
'input-bind': 'VideoMessageID'
}
});
recorder.activate();
-
Hi,
The short info would be that this is caused by the use of webrtc_streaming.
So if you removed that from your code or set it as false, you will immediately see an improvement with your videos working just right.
Now the reason why that happens is because for the streaming to work (not specific to our system, this is how the protocol is defined and as such implemented into browsers) is to have first few seconds as handshakes if you will.
This must be the actual video and audio data, it can not done upfront, and this is when the recorder will talk with several different servers in order to sync everything together.
You can see this in Skype or any other live recording where videos are passed to servers right away as lower video quality or with no sound. Now as the communication continues longer, it all works.
Same is with our system, since the underlaying protocols are same. Which means that first few seconds are just not enough to actually have some video data that can be see later on.
As such webrtc_streaming is good only for longer recordings.
In general the best tests are with the same length as your customers would have, while the minimal recommended recording times would be as follows:
- For non webrtc_streaming videos (standard WebRTC or Flash): above 5 seconds
- For any webrtc_streaming videos around 10 seconds and more
WebRTC also has other factors that you should be aware of such as depending on the bandwidth, which means that if your bandwidth falls down, the quality of video will fall as well (just like Skype was to get pixelated at some moments).
Hope this helps.
Regards,
Bane1 -
Just to add so it is a bit more clear.
With webrtc_streaming, if the videos are longer, the data that was part of the sync process would not actually be available to us as our different servers would have small fractions of un-synced data.
Only the details that are properly synced are actually available.
This is why the first few seconds can be lost, as well as why the videos must be longer than those first few seconds.
0 -
@Bane - thank you so much, that explains it and it makes sense. The videos in our case would usually be 1-2 mins long, but I disabled WebRTC anyway because videos can be recorded from anywhere, so varying bandwidths and mobile devices could be a problem.
Thanks!
0 -
Hi,
I am glad to hear that it helped :)
Just to mention, WebRTC and webrtc_streaming are not the same, so WebRTC is good to use, while webrtc_streaming will be good for live video we will have, just not for standard recordings.
* The reason why I mention this is because WebRTC is turned on by default in our v2. This is browser based API that you can rely on, with Flash just as a failsafe (so you do not need to think if your customers would have Flash installed or not).
On the other hand webrtc_streaming is the protocol utilizing WebRTC and network protocols to have the video uploaded right away to another side - currently our servers.
Regards,
Bane1 -
Hi @Bane,
Thanks again - I did confuse two different things with each other (never worked with embedded video before :))
0 -
Hi,
All good. Just wanted to make sure I mention it since WebRTC by itself is great.
* Did not want his little brother to give him a bad name :)
0
Please sign in to leave a comment.
Comments
6 comments