I have a use case that doesn't exactly require real time communication, but as close as I can get it to make sure my users don't have to wait forever uploading a file after the fact. Our site allows users to record video and audio that we then store on our server.
I moved from flash, because flash, to a WebRTC implementation with a Kurento media server. This works super well with high quality internet connections but is relatively lacking for users with poor connectivity.
I was thinking if I could some how implement a bit of a buffer before feeding the server so that I can make up for dips in connectivity that would be ideal. I understand this isn't what WebRTC was meant for which leads to the question of whether or not there is another solution I should look into?
Any and all suggestions are welcome and appreciated! Thanks!
A buffer wont change WebRTC's realtime characteristics in the face of low bandwidth. With video for instance, WebRTC might degrade either frame rate or resolution to keep up, but no-one has proposed degrading delivery time (dropping realtime-ness). Yours is an interesting use case however.
You could use
MediaRecorder
. It would let you record locally and then send the data as blobs to the server with either websockets or data channels.Here's a fiddle that works in Chrome (which does video only unfortunately) and Firefox:
https://jsfiddle.net/tmwLxjLy
It shows simple recording and then playback of the video 5 seconds later. I'll leave it as an exercise to modify it to cause a continuous 5-second delay.