git.sesse.net Git - nageru-docs/blob - futatabi.rst

   1 Futatabi: Real-time instant replay with slow motion
   2 ===================================================
   3
   4 Futatabi (after the Japanese word *futatabi*, 再び, meaning “again” or
   5 “for the second time”) is a system for instant replay. Even though Futatabi
   6 is meant to be used with Nageru, shares some code with it and is built from
   7 the same source distribution, it is a separate
   8 application. Futatabi is meant for slow motion for e.g. sports broadcasts, but
   9 can also be used as a more generic multitrack recorder for later editing.
  10
  11 Futatabi supports *interpolated* slow motion, meaning you do not need to buy
  12 a high-speed 120 fps camera to get smooth 60 fps output after slowdown—Futatabi
  13 will automatically synthesize in-between frames for you during playback.
  14 Good interpolation, especially in realtime, is a difficult problem, and not all
  15 content will do equally well. Most content should do quite acceptably, especially
  16 considering that half of the frames will actually be originals, but you
  17 will need to see in practice what actually works for you. Interpolation can
  18 also be used for frame rate conversion (e.g. 50 to 59.94 fps).
  19
  20 Futatabi currently uses a GPU reimplementation of
  21 `Fast Optical Flow using Dense Inverse Search (DIS) <https://github.com/tikroeger/OF_DIS>`_
  22 by Kroeger et al, together with about half of the algorithm from
  23 `Occlusion Reasoning for Temporal Interpolation Using Optical Flow <https://www.microsoft.com/en-us/research/publication/occlusion-reasoning-for-temporal-interpolation-using-optical-flow/>`_
  24 (to do the actual interpolation based on the estimated
  25 optical flow), although this may change in the future.
  26
  27 Since Futatabi is part of the Nageru source distribution, its version number
  28 mirrors Nageru. Thus, the first version of Futatabi is version 1.8.0,
  29 which is the Nageru version when it was first introduced.
  30
  31
  32 System requirements
  33 -------------------
  34
  35 It is strongly recommended to run Futatabi on a separate machine from Nageru,
  36 not the least because you probably want a different person to operate the replay
  37 while the producer is operating Nageru.
  38
  39 Like Nageru, Futatabi uses your GPU for nearly all image processing.
  40 However, unlike Nageru, Futatabi requires a powerful GPU for interpolation;
  41 a GTX 1080 or similar is recommended for interpolated 720p60. (Futatabi
  42 was initially developed on a GTX 950, which is passable, but has little
  43 performance margin.) If you have a slower GPU and are happy with worse
  44 quality, or just wish to test, you can use a faster preset, or turn off
  45 interpolation entirely. Futatabi requires OpenGL 4.5 or newer.
  46
  47 For other required libraries, see :ref:`compile`; when you build Nageru,
  48 you also build Futatabi.
  49
  50
  51 Getting started
  52 ---------------
  53
  54 Sample multicamera data
  55 '''''''''''''''''''''''
  56
  57 Good multicamera sample video is hard to come by, so it can be hard to
  58 test or train before an actual event. To alleviate this, I've uploaded some
  59 real-world video from the very first event where an early version of Futatabi
  60 was tested. (There are some issues with the JPEG quality, but it should
  61 largely be unproblematic.) You are free to use these for training or
  62 demonstration purposes. Do note that they will not be displayed entirely
  63 correctly in most video players (see :ref:`futatabiformat`), although
  64 they will certainly be watchable.
  65
  66 There are two files:
  67
  68  * `Trøndisk 2018, finals only (MJPEG, 77 GB) <https://storage.sesse.net/trondisk2018-finals-multicam-mjpeg.mkv>`_:
  69    The final match, in MJPEG format (about 30 minutes). This can be downloaded
  70    and then fed directly to Nageru as if it were a real camera stream
  71    (remember the --slow-down-input option).
  72  * `Trøndisk 2018, entire tournament (H.264, 74 GB) <https://storage.sesse.net/trondisk2018-multicam-h264.mp4>`_: The entire tournament,
  73    with no cuts (about 12 hours). However, due to space and bandwidth
  74    constraints, it has been transcoded to H.264 (with some associated
  75    quality loss), and needs to be transcoded to MJPEG before Nageru can use it.
  76
  77 Both files are mixed-resolution, with some cameras at 1080p59.94 and some
  78 at 720p59.94 (one even switches between matches, as the camera was replaced).
  79 They contain four different camera angles (overview camera on crane, detail camera
  80 in tripod, two fixed endzone overhead cameras) with differing quality depending
  81 on the camera operators. In short, they should be realistic input material
  82 to practice with.
  83
  84
  85 Transferring data to and from Nageru
  86 ------------------------------------
  87
  88 .. _futatabiformat:
  89
  90 Video format specification
  91 ''''''''''''''''''''''''''
  92
  93 Futatabi expects to get data in MJPEG format only; though MJPEG is old,
  94 it yields fairly good quality per bit for an intraframe format, supports
  95 4:2:2 without too many issues, and has hardware support through VA-API
  96 for both decode (since Ivy Bridge) and encode (since Skylake). The latter
  97 is especially important for Futatabi, since there are so many high-resolution
  98 streams; software encode/decode of several 1080p60 streams at the same time
  99 is fairly taxing on the CPU if done in software. This means we can easily
 100 send 4:2:2 camera streams back and forth between Nageru and Futatabi without having
 101 to scale or do other lossy processing (except of course the compression itself).
 102
 103 However, JPEG as such does not have any way of specifying things like color
 104 spaces and chroma placement. JFIF, the *de facto* JPEG standard container,
 105 specifies conventions that are widely followed, but they do not match what
 106 comes out of a capture card. Nageru's multicam export _does_ set the appropriate
 107 fields in the output Matroska mux (which is pretty much the only mux that can
 108 hold such information), but there are few if any programs that read them and give
 109 them priority over JFIF's defaults. Thus, if you want to use the multicam stream
 110 for something other than Futatabi, or feed Futatabi with data not from Nageru,
 111 there are a few subtle issues to keep in mind.
 112
 113 In particular:
 114
 115   * Capture cards typically send limited-range Y'CbCr (luma between 16..235
 116     and chroma between 16..240); JFIF is traditionally full-range (0..255
 117     for both). (See also :ref:`synthetictests`.) Note that there is a special
 118     private JPEG comment added to signal this, which FFmpeg understands.
 119   * JFIF, like MPEG, assumes center chroma placement; capture cards and most
 120     modern video standards assume left.
 121   * JFIF assumes Rec. 601 Y'CbCr coefficients, while all modern HD processing
 122     uses Rec. 709 Y'CbCr coefficients. (Futatabi does not care much about
 123     the actual RGB color space; Nageru assumes it is Rec. 709, like for capture
 124     cards, but the differences between 601 and 709 here are small. sRGB gamma
 125     is assumed throughout, like in JFIF.)
 126
 127 Many players may also be confused by the fact that the resolution can change
 128 from frame to frame; this is because for original (uninterpolated) frames,
 129 Futatabi will simply output the received JPEG frame directly to the output
 130 stream, which can be a different resolution from the interpolated frames.
 131
 132 Finally, the subtitle track with status information (see :ref:`talkback`) is
 133 not marked as metadata due to FFmpeg limitations, and as such will show up
 134 raw in subtitle-enabled players.
 135
 136
 137 Monitoring
 138 ----------
 139
 140 .. _talkback:
 141
 142 Tally and status talkback
 143 '''''''''''''''''''''''''
 144
 145 Prometheus metrics
 146 ''''''''''''''''''