From b7c5f0cf52c985aa8bc60cf2962ecad3f2a87aab Mon Sep 17 00:00:00 2001 From: Sacha Chua Date: Sat, 28 Nov 2020 08:30:55 -0500 Subject: Updated --- 2020/organizers-notebook.org | 129 +------------------------------------------ 1 file changed, 1 insertion(+), 128 deletions(-) (limited to '2020/organizers-notebook.org') diff --git a/2020/organizers-notebook.org b/2020/organizers-notebook.org index 925e2f8b..b50635e9 100644 --- a/2020/organizers-notebook.org +++ b/2020/organizers-notebook.org @@ -42,134 +42,7 @@ - Speaker continues with extended presentation if they want - will be recorded *** Scenarios **** Prerecorded presentations - - O1 streams presentation to both endpoints (is there a neat command-line way to do this?) - https://stackoverflow.com/questions/7869190/is-it-possible-to-pull-a-rtmp-stream-from-one-server-and-broadcast-it-to-another - or maybe IceCast can handle the splitting +- Amin will play it on his computer and stream from there **** Tech issues - If can't be easily resolved, play pre-recorded talk early and try again later (or follow up) - Stream a technical issues slide to the end point -**** Speaker can stream directly from computer over RTMP - - Can skip BigBlueButton entirely if they want - - Speaker starts streaming to talk endpoint - - O2 verifies that it's playing and communicates with speaker through collaborative pad - - O1 switches conference stream to talk endpoint -**** Speaker is giving another talk soon - - Stay in same room - - O2 checks in near the time of the next talk - - O2 stops and restarts recorder, giving it the next talk's stream endpoint -** If we have one room per talk (except for speakers with multiple) - O1 - main organizer, O2 - secondary organizer or volunteer - -*** Overview - - one room per talk - - O1 joins the appropriate room and streams it to the main conference stream (or sets the fallback mount) - - O2 streams the talk room to the individual talk room -*** Before the conference - - Do tech checks and get alternative ways to contact speakers (phone number? IRC nick? Something that goes ding?) - - Turn on audio alert - - Install Mute Tab extension -*** Tech check - - Explain process - - Test audio, webcam, screensharing, collaborative pad -*** Shortly before the presentation - - Speaker joins talk room - - O2 makes speaker presenter and moderator (so they can kick out recorder when done), does tech check - - Speaker tries screen sharing and webcam, then returns to uploaded presentation - - O2 starts secondary stream and recording, checks individual page - - O2 notifies O1 with link to the talk room - - O1 joins meeting - - O1 sets conference stream to individual talk endpoint - - O2 starts recording in BBB -*** During the presentation - - Speaker presents, keeping an eye on the collaborative pad for questions - - O1 stays with speaker to help with questions and timing - - O2 wanders off to do the tech check with the next person and pings O1 when ready -*** After the presentation - - O1 announces next steps: If you want to continue the conversation, go to the individual talk page - - O1 goes to next talk when ready - - Speaker continues with extended presentation if they want -*** After the extended presentation (if any) - - Speaker removes the recorder/streamer user to end the stream and recording - - Speaker stops the BBB recording -*** Scenarios -**** Prerecorded presentations - - O1 streams presentation to both endpoints (is there a neat command-line way to do this?) - https://stackoverflow.com/questions/7869190/is-it-possible-to-pull-a-rtmp-stream-from-one-server-and-broadcast-it-to-another - or maybe IceCast can handle the splitting -**** Tech issues - - If can't be easily resolved, play pre-recorded talk early and try again later (or follow up) - - Stream a technical issues slide to the end point -**** Speaker can stream directly from computer over RTMP - - Can skip BigBlueButton entirely if they want - - Speaker starts streaming to talk endpoint - - O2 verifies that it's playing and communicates with speaker through collaborative pad - - O1 switches conference stream to talk endpoint -**** Speaker is giving another talk soon - - Stay in same room - - O2 checks in near the time of the next talk - - O2 stops and restarts recorder, giving it the next talk's stream endpoint - -** Other description - -#+begin_example - All right, time to figure out the schedule [22:25] - What I had in mind is that most people will be anonymously viewing - through the stream viewer on the main conference page or on the - individual talk pages - I (or whoever the secondary organizer is, here referred to as O2) - will run around doing tech checks with people. The check-in room is - mostly just so that my computer goes ding, but IRC will probably work - too if I remember to check erc-track or /msg =) [22:26] - O1 (probably Amin) will join the current talk's room and broadcast - that to the main conference stream. Alternatively, if whatever - streaming docker thingy I make turns out reasonably reliable, he can - just use Icecast to update the fallback for the main conference mount - to be the talk's streaming mount. [22:27] - If a speaker wants to keep talking, the streaming thingy will just - keep listening to and streaming that room to the individual talk - mount, and people can continue watching the talk on the individual - talk's page. [22:28] - Questions will be organized in the talk's section in the - collaborative pad (might be Etherpad), since that'll be easier than - having an organizer check three or four different IRC channels - [22:29] - Ideally, the speaker would keep the collaborative pad open, keep - answering questions, and then wrap up at some point. - I think this is better than having audience members join the room - directly because (a) we want to respect the FSF's bandwidth use, (b) - we don't want to tie up organizer resources in monitoring mute/webcam - status, (c) questions can be handled faster than text, and (d) no one - else has to fuss around with sound setup, worrying about - echo/feedback, and so on. [22:31] - If speakers announce their arrival by a message in #emacsconf-org and - we're good about keeping that low-traffic, we can use that instead of - a staging room. [22:33] - Worked reasonably well last year. - If people are watching via the streaming pages instead of in BBB, - then we can bounce people watching individual streams back to the - main stream by setting the Icecast fallback for the individual talk - to the main stream. [22:34] - Alternatively, we can change the Icecast fallback to an image that - tells them that the stream has ended and that they can go to the main - conference if they want. [22:35] - (or a short video that says that, or whatever we can do with Icecast - - needs testing) - At the moment, my BBB account is set up to have a maximum of four - rooms + my home room, so I'm planning for a different model that - involves directing speakers (via BBB or the home room) to whichever - room is available. I'll go to that room for the tech check and set up - the individual talk stream to feed to the source for the individual - talk page. Amin will go between rooms to stream them and to be around - if needed. They can occupy that [22:40] - room for the remainder of their talk. When we need to move the main - conference stream on, Amin will help the speaker wrap up, and then - Amin will move to the next room that is ready. The speaker can stay - in their original room for the remainder of their talk. If we run out - of rooms because everyone kept talking for a long time, I'll step in - and ahem nicely. -#+end_example - -* Conference recorder -Goals: -- Connect to BBB room and stream to room mount (liveRTMP?) -- Have a convenient way to switch the fallback mounts of the individual talk mount points -- cgit v1.2.3