software:relive

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
software:relive [2017/08/29 13:54] – [Setting up Relive in the VOC setup] florolfsoftware:relive [2024/01/03 16:49] (current) – [Relive integration in media.ccc.de (voctoweb)] andi
Line 3: Line 3:
 Documentation for the relive system is contained within its git repo ''git@c3voc.de:hls-relive'' mirrored at https://github.com/voc/hls-relive -> README.md Documentation for the relive system is contained within its git repo ''git@c3voc.de:hls-relive'' mirrored at https://github.com/voc/hls-relive -> README.md
  
-It's currently deployed at live.ber:/home/relive/git/ +It's currently deployed at live.alb:/home/relive/git/  
  
 == Setting up Relive in the VOC setup == Setting up Relive in the VOC setup
  
-  On live.ber, in ''/home/relive/git/configs'' create an appropriate config for your event (look at other files in that directory or in the old/ subdirectory for inspiration). The filename will be used as the conference name from here on. +Login to server  
-  - After a minute, a cronjob will run and download the schedule, etc. (If you are impatient, you can run ''/home/relive/git/scripts/foreach-project.sh /home/relive/git/scripts/get-fahrplan.sh'' manually) +  ssh relive@relive.c3voc.de 
-  - Start the scheduler (run as user relive): ''./launcher.sh yourconferencename'' +  cd git  
-  - In the streaming-website configuration, set ''RELIVE_JSON'' to point to ''%%http://live.ber.c3voc.de/relive/yourconferencename/index.json%%''+  screen -dR 
 + 
 +  - Create an appropriate config for your event in `live.alb:/home/relive/git/configs
 +    - either by using `./gen_event_config.py <conference slug>`, or 
 +    - manually: copy `cfg.example`, look at other files in that directoryor in the `old/subdirectory for inspiration. The filename will be used as the conference name from here on. 
 +  - After a minute, a cronjob will run and download the schedule, etc. (If you are impatient, you can run `/home/relive/git/scripts/foreach-project.sh /home/relive/git/scripts/get-fahrplan.shmanually) 
 +  - Start the scheduler (run as user relive, inside of a screen/tmux session): `./launcher.sh <conference slug>` 
 +  - In the streaming-website configuration, set ''RELIVE_JSON'' to point to ''%%http://relive.c3voc.de/relive/<conference slug>/index.json%%''
  
 Note that the ''index.json'' file is also only regenerated periodically, so it might be a minute or two before that URL actually works. Note that the ''index.json'' file is also only regenerated periodically, so it might be a minute or two before that URL actually works.
-== README 
  
-(this might be out of date, check the README in the git repo when in doubt) 
  
-<code> +== Relive integration in media.ccc.de (voctoweb)
-HLS ReLive +
-==========+
  
-This set of tools records portions of an HLS stream into separate +When an event in voctoweb has no recordings, voctoweb will try to find the corresponding relive recording. This only works if the conference acronym matches the acronym used in the relive system
-playlists for timeshifting and to bridge the time until the actual +
-recordings are available.+
  
-Components +To use this feature, first create the conference in voctoweb and in c3tracker. In theory there are multiple variants, but this one is the one we currently use:
-----------+
  
-The ReLive system consists of several tools and cron jobssome of which +* To enable this workflow for you conferenceenable the "releasing-relive-voctoweb" worker group which is handled by a modified version of CRS worker `script-A` living in a screen (user voc).  
-can be used independently from the rest.+* [[https://github.com/voc/voctopublish/blob/feature/relive/voctopublish/create-event-by-ticket.py|create-event-by-ticket.py]] is able to create an event in voctoweb, based on the CRS Ticket ID. 
 +* This script can be called during any state transition, we currently use `scheduled` -> `recording` of the recording ticket 
 +  * TODO: When we use this step, we should rename or migrate the deployment of of this script from releasing to storage, as it confuses tracker operators when the releasing host does the recording step.
  
-### record.pl+If you need re-create the session, run following commands:
  
-`record.pl` records HLS streams that are being generated locally by 
-watching the corresponding directory with inotify. It cannot record 
-streams via HTTP, nor will it perform any magic (like trying to figure 
-out at what position in the source m3u8 it stopped recording) when being 
-restarted: It will simply add a discontinuity header to the output m3u8 
-and resume adding segments. It turns out that this makes things much 
-simpler and is enough for our use case. 
  
-Usage: `record.pl in-directory in-m3u8 out-directory`+``` 
 +ssh voc@releasing.c3voc.de 
 +screen -
 +cd /opt/crs/tools/tracker3.0 
 +source tracker-profile-relive.sh 
 +export LOCALFILE=tracker-profile-relive.sh 
 +./bin/crs_run script-A-recording+relive-scheduler.pl  
 +```
  
-The m3u8 in the output directory will be named `index.m3u8`. +== README
- +
-### scheduler.pl +
- +
-`scheduler.pl` is responsible for starting and stopping recording +
-processes as dictated by the conference schedule. See below for +
-configuration details. +
- +
-When sent a `SIGHUP`, it will reload its schedule, spawning or killing +
-recording subprocesses as necessary. Running recording subprocesses +
-which are still valid w.r.t. the new schedule remain untouched. +
- +
-When sent a `SIGINT` or `SIGTERM` it shuts down all recording +
-subprocesses and then terminates itself. +
- +
-Recording subprocesses are started via `wrapper.sh` which takes care of +
-setting up their environment (creating one directory per schedule event +
-to store the recording, amongst other things) and starting them. +
- +
-### genpage.pl +
- +
-`genpage.pl` looks through the directory with all the recordings, +
-cross-referencing them with the schedule and media.ccc.de, to find out +
-whether a proper release has happened yet. All this data is collected +
-and written into a file called `index.json` in the top-level recording +
-directory, which can then be used by the streaming frontend. +
- +
-A recording can be in one of four states: +
- - not_running: Transitory state where the recording directory has been +
-   created, but doesn't contain any data yet. +
- - live: There is data present, but the playlist is not finished yet. +
- - recorded: There is data present and the playlist is finished. +
- - released: A recording of this talk has been found on media.ccc.de +
- +
-A recording can move from the *recorded* state back to *live* if the +
-recording is restarted for some reason. Other than that, recordings +
-progress monotonically from *not_running* to *released*. +
- +
-Starting from the *live* state, a thumbnail is generated. Once a +
-recording is *recorded*, the HLS files get remuxed into a faststarted +
-mp4 for easy download. +
- +
-The `index.json` file contains an array of objects. A fully populated +
-object looks like this: +
- +
-    { +
-       "thumbnail" : "//live.dus.c3voc.de/releases/relive/1549/thumb.jpg", +
-       "status" : "released", +
-       "duration" : 5399, +
-       "room" : "HS 7", +
-       "playlist" : "//live.dus.c3voc.de/releases/relive/1549/index.m3u8", +
-       "id" : "1549", +
-       "title" : "Btrfs – Das Dateisystem der Zukunft?", +
-       "release_url" : "http://media.ccc.de/browse/conferences/froscon/2015/froscon2015-1549-btrfs_das_dateisystem_der_zukunft.html" +
-    } +
- +
-### check_released.pl +
- +
-`check_released.pl` is a helper used by the `get-releases.sh` script. It +
-ensures that only events which have at least one recording on media.ccc.de are +
-marked as *released*. +
- +
-### Cron jobs +
- +
-There are three cron jobs: +
- +
-  - calling get-releases.sh to download and cache the list of recordings +
-    already released on media.ccc.de +
-  - calling get-fahrplan.sh to download the schedule +
-  - calling genpage.pl to update `index.json` etc. +
- +
-Configuration +
-------------- +
- +
-All scripts take the union of `global_config` in the root of the git +
-repository as their configuration. This configuration is extended by a +
-project-specific configuration in the `configs` subdirectory. See the +
-`.example` files in the respective directories. These files also contain +
-comments explaining the various options.+
  
-Setting up for a new conference +Please read the [[https://github.com/voc/hls-relive/blob/master/README.md|README]] in the repository, it is being kept up to date with regard to the general behavior of the relive system.
--------------------------------+
  
-The following steps are necessary to set up ReLive for a new conference:+== FAQ
  
-  - update the configuration file appropriately +The `/video/relive/<conference>/<id>/index.m3u8is empty/broken, how can I regenerate the file? 
-  - launch the recording scheduler: `./launcher.sh projectname+  * simply rename or remove the file, it will be generated in the next run (or trigger it manually)
-    You'll probably want to do that in a screen session.  +
-     +
-</code>+
  • software/relive.1504007645.txt.gz
  • Last modified: 2017/08/29 13:54
  • by florolf