It is strongly recommended to run Futatabi on a separate machine from Nageru,
not the least because you probably want a different person to operate the replay
-while the producer is operating Nageru.
+while the producer is operating Nageru. (See :ref:`coop`.)
Like Nageru, Futatabi uses your GPU for nearly all image processing.
However, unlike Nageru, Futatabi requires a powerful GPU for interpolation;
that comes with Futatabi), it is capable of sending all of its cameras as one
video stream (see :ref:`futatabiformat`), so you can start Futatabi with
- ./futatabi http://path.to.nageru.host/multicam.mp4
+ ./futatabi http://nageru-server.example.org/multicam.mp4
If you do not have a running Nageru installation, see :ref:`sampledata`.
recorded frames, all metadata about clips, and preferences set from the menus
(interpolation quality and cue point padding). If you quit Futatabi and
restart it (or you go down as the result of a power failure or the likes),
-it will remember all the state and frames for you.
+it will remember all the state and frames for you. As a special case,
+if you give */dev/null* in place of an input URL or file, you can keep using
+your workspace without getting any new frames added.
+
+.. _basicui:
Basic UI operations
'''''''''''''''''''
Nageru can be operated using either the keyboard and mouse, or using a MIDI
controller with some help of the mouse. In this section, we will be discussing
-the keyboard and mouse only; see :ref:`midi` for details on using MIDI
+the keyboard and mouse only; see :ref:`midi-futatabi` for details on using MIDI
controllers.
A clip in the clip list consists simply of an in and an out point; it represents
click the “Play” button (space on the keyboard); the result will both be
visible in the top screen and go out live over the network to Nageru.
-On top of these basics, there are many possible workflows; we'll discuss only
-two. Try out a few and see which ones fit your style and type of event.
+.. _speed:
+
+Controlling the playback speed
+''''''''''''''''''''''''''''''
+
+.. _coop:
+
+Working with your producer
+''''''''''''''''''''''''''
+
+Generally, we recommend that the producer (Nageru operator) and slow motion
+operator (Futatabi operator) sit closely together and can communicate verbally.
+Good cooperation between the two is essential to get a good final product;
+especially the switches to and from the replays can be a critical point.
+
+The general rule for working together is fairly obvious: The producer should
+switch to a replay when there's something to show, and switch away when there's
+nothing more to show (or, less ideally, when something live takes priority).
+Generally, when you have a playlist ready, inform your producer; they will
+count you in (three, two, one, go). At one, start playing so that you have some
+margin. If the Nageru theme is set up correctly (see :ref:`talkback`), they will
+know how much is queued up so that they can switch back before the replay runs
+out, but it doesn't hurt to give a warning up-front. The producer might also
+be able to request replays of specific events, or ask you to save something
+for later if they can't show it right now (e.g. a foul situation that wasn't called).
+
+Replay workflows
+----------------
+
+On top of the basics outlined in :ref:`basicui`, there are many possible
+workflows; we'll discuss only two. Try out a few and see which ones fit your
+style and type of event.
Repeated cue-in
'''''''''''''''
Futatabi will simply output the received JPEG frame directly to the output
stream, which can be a different resolution from the interpolated frames.
+Also, even though Futatabi exists to make a fixed-framerate stream out of
+something that's not, the output stream can be variable-framerate (VFR) due to
+pauses and frame drops. In particular, when the stream is paused, frames are
+only output about every 100 milliseconds.
+
Finally, the subtitle track with status information (see :ref:`talkback`) is
not marked as metadata due to FFmpeg limitations, and as such will show up
raw in subtitle-enabled players.
-.. _midi:
+.. _midi-futatabi:
Using MIDI controllers
----------------------
+This section assumes you have already read the section about
+`MIDI controllers in Nageru <audio.html#midi-controllers>`__. MIDI controllers
+in Futatabi are fairly similar, but there are also some important differences,
+since they control replay and not audio:
+
+ * There is no concept of a bus (there is only one video output channel).
+ Thus, the concept of guessing also is obsolete.
+ * Since there are no buses, there are also usually plenty of buttons
+ and controls, rendering the bank concept less useful. It *is* supported,
+ but activity highlights (to show which bank is active) are not.
+ * Finally, outputs (controller lights and button lights) frequently have
+ more than one state depending on the velocity sent, e.g. 1 for on and 2 for
+ blinking. Thus, the Futatabi MIDI mapping editor allows you to change the
+ note velocities from the default 1.
+
+Futatabi has been tested with the `Behringer CMD PL-1 <https://www.musictribe.com/Categories/Behringer/Computer-Audio/DJ-Controllers/CMD-PL-1/p/P0AJF>`;
+it is not originally designed for slow motion, but provides everything you
+need (a jog wheel, a slider that works as a T bar for master speed, and plenty
+of buttons) at a fraction of the price of a “real” slow motion remote.
+A sample MIDI mapping is included with Futatabi.
+
+Futatabi currently does not support classic RS-422 controllers, only MIDI
+controllers.
+
Monitoring
----------
Tally and status talkback
'''''''''''''''''''''''''
+In addition to the verbal communication between the two operators
+(see :ref:`coop`), it is also useful to have automatic communication
+between Nageru and Futatabi. This goes both ways.
+
+First, Futatabi can consume :ref:`Nageru's tally data <tally>` like any camera
+can; give the correct channel URL to *--tally-url* on the Futatabi command line,
+and the color around the live view will show up when you are ready or playing
+(e.g. *--tally-url http://nageru-server.example.org:9096/channels/2*).
+
+Second, Futatabi can export its current status in two ways. The simplest is
+through a REST call; the HTTP server that exposes the stream also exposes
+the endpoint */queue_status* (e.g. http://futatabi-server.example.org:9096/queue_status).
+This contains the same text as is below the live window, ie., how much time
+is queued or left.
+
+The same status is also exported programmatically in the video output from
+Futatabi, as a subtitle track. This allows the Nageru theme not only to display
+it if desired, but even to act automatically to switch to a different channel
+when the playlist is nearing its end. (See :ref:`subtitle-ingest` for information
+on how to digest such information from the Nageru side.)
+
+Each subtitle entry is displayed momentarily before the frame it belongs to,
+and has the following format:
+
+ Futatabi 1.8.2;PLAYING;6.995;0:06.995 left
+
+The semicolon-separated columns are as follows:
+
+ * The first column is the identifier for the Futatabi version in use; if the format
+ should ever diverge between versions, it can serve as a way to distinguish between
+ them if needed. (The version may also change without the format changing.)
+ For now, however, you can ignore it.
+ * The second column is either PLAYING or PAUSED, depending on the current status.
+ * The third column is how many seconds is queued up (PAUSED) or remaining (PLAYING).
+ It is always in C locale, no matter what the user has set (ie., the decimal point
+ will always be a period). Note that this does not take into account the master
+ speed (see :ref:`speed`).
+ * Finally, the fourth column is a human-readable string, the same as is exposed
+ on the /queue_status endpoint above.
+
Prometheus metrics
''''''''''''''''''
+
+Like Nageru, Futatabi supports a series of Prometheus metrics for monitoring;
+see :doc:`monitoring` for general information. Futatabi provides entirely different
+metrics, though, mostly related to performance. There is no predefined Grafana
+dashboard available at the current time.
projects / nageru-docs / blobdiff