Open yourcelf opened 10 years ago
yourcelf
commented
10 years ago One further issue that may or may not be related: in the "Equity and Learning in the 21st Century" event today, "Play-for-all" was immediately pausing and not properly playing at the current time (which was a hangout that had been kept open for about an hour). It could be that the player's knowledge of the length of the video was incorrect, and so any "play" was interpreted as reaching the end of the video.
srish
commented
10 years ago @yourcelf I am not sure if this might be related to the issue, but thought of sharing this with you. We had a lot of internet glitches during the LCL event today. We got disconnected many a times during the event because of the ML network. If you will check out the welcome video https://www.youtube.com/watch?v=94jY4Egsgao, you will see that it gets stuck at 4:40 and starts reloading. This is exactly where people started reporting the issues with the video and the HOA stopped. This might be unrelated to this issue, but might be helpful in digging into this problem.
srish
commented
10 years ago Wrote to one of the participants from LCL to know - This is her reply: "It was perfect, but I noticed that suddenly that the video stopped and a spinning sign appeared, indicating that the video was loading. I noticed it coincided with a point when many people joined in."
yourcelf
commented
10 years ago With new video-sync code during LCL 2014-05-06, it appears that sometimes the newly queued video sometimes did not start playing, even though it did receive and process the sync signal. This may only affect admin accts on Firefox -- it worked properly for me with non-admin acct on firefox and chromium.
Sometimes (as in LCL 2014 Apr 29) the synchronized playback in events for a streaming Hangout-on-air video gets into a bad state. Symptoms include pausing to buffer, jumping around within 10-20 seconds of the current time, and not playing or playing with a stutter.
My current theory: this may be a result of varying latencies of video delivery from hangout/youtube. We know that there's a large gap (30 seconds to a minute) for youtube videos streaming from a live hangout. But I've also observed this gap vary between browsers (Chromium seems to have lower latencies than Firefox, by as much as 10-15 seconds -- possibly due to HTML5 codecs used for the video), and might vary between geographies depending on CDN proximity, etc.
Our video sync control, however, broadcasts a single time code for all users, and operates with a 10 second window -- if the player's time differs from the sync time by more than 10 seconds, the player tries to skip to the current sync time. However, if it tries to jump to a time ahead of where there's any data, we'd see buffering and skipping, and if the buffering takes longer than 10 seconds, we'd see the symptoms we had above. This is especially likely if the admin who started the video is in a privileged signal position relative to viewers (e.g. at MIT with its super fast network, fat pipes close to Google, and using Chrome). For those users, it might be necessary to arbitrarily introduce extra delay in order to remain in sync with slower connections.
This issue only effects live streams -- for pre-recorded videos, the current time-sync strategy works fine. But for live events (if we can detect that they are live), we might want a different strategy. The YouTube player has a "live" button/indicator which you can press to jump forward to the player's local tip of the stream, but there's no API access to this function. We might be able to get away with "just pressing play" for each user and not trying to seek in time, but that doesn't work for people who join after the broadcast has started (who would start from the beginning).
Another possible workaround is to wait an arbitrary additional delay (10, 20 seconds?) from when a livestream starts playing before pressing "Play for all", or to increase the allowed window of deviation for individual players (20 or 30 seconds?). As long as the arbitrary delay exceeds variation in when the livestream reaches users, that works; but it's hard to predict that.
Longer term solution: roll our own video broadcast solution (maybe a reflector for WebRTC streams) and get free from the limits of Google's APIs for synchronizing video.