Statistics
| Branch: | Revision:

## janus-gateway / plugins / janus_recordplay.c @ 793d18b1

 1 /*! \file janus_recordplay.c   * \author Lorenzo Miniero   * \copyright GNU General Public License v3   * \brief Janus Record&Play plugin   * \details This is a simple application that implements two different   * features: it allows you to record a message you send with WebRTC in   * the format defined in recorded.c (MJR recording) and subsequently   * replay this recording (or other previously recorded) through WebRTC   * as well.   *   * This application aims at showing how easy recording frames sent by   * a peer is, and how this recording can be re-used directly, without   * necessarily involving a post-processing process (e.g., through the   * tool we provide in janus-pp-rec.c).   *   * The configuration process is quite easy: just choose where the   * recordings should be saved. The same folder will also be used to list   * the available recordings that can be replayed.   *   * \note The application creates a special file in INI format with   * \c .nfo extension for each recording that is saved. This is necessary   * to map a specific audio .mjr file to a different video .mjr one, as   * they always get saved in different files. If you want to replay   * recordings you took in a different application (e.g., the streaming   * or videoroom plugins) just copy the related files in the folder you   * configured this plugin to use and create a .nfo file in the same   * folder to create a mapping, e.g.:   *   * [12345678]   * name = My videoroom recording   * date = 2014-10-14 17:11:26   * audio = mcu-audio.mjr   * video = mcu-video.mjr   *   * \section recplayapi Record&Play API   *   * The Record&Play API supports several requests, some of which are   * synchronous and some asynchronous. There are some situations, though,   * (invalid JSON, invalid request) which will always result in a   * synchronous error response even for asynchronous requests.   *   * \c list and \c update are synchronous requests, which means you'll   * get a response directly within the context of the transaction. \c list   * lists all the available recordings, while \c update forces the plugin   * to scan the folder of recordings again in case some were added manually   * and not indexed in the meanwhile.   *   * The \c record , \c play , \c start and \c stop requests instead are   * all asynchronous, which means you'll get a notification about their   * success or failure in an event. \c record asks the plugin to start   * recording a session; \c play asks the plugin to prepare the playout   * of one of the previously recorded sessions; \c start starts the   * actual playout, and \c stop stops whatever the session was for, i.e.,   * recording or replaying.   *   * The \c list request has to be formatted as follows:   *  \verbatim  {   "request" : "list"  }  \endverbatim   *   * A successful request will result in an array of recordings:   *  \verbatim  {   "recordplay" : "list",   "list": [ // Array of recording objects   { // Recording #1   "id": ,   "name": "",   "date": "",  ` "audio": "