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.