This reducec the dropbear cpu usage to basically
nothing, since the traffic does not need encryption
anymore.
This option uses the nc command on the client side.
So this will not work with windows as of now!
Instead of simply playing back the frames through `ffplay`, I thought it
might be interesting to be able to record the sequence to a video file
or to use it as part of a stream.
I have in mind the use case of making educational videos/live streams
where the tablet can be used as a kind of remote blackboard by teachers,
which is especially relevant currently. But there are certainly other
use cases!
Changes
=======
This commit adds two new options to that effect:
* `-o --output`: Path of the output as understood by `ffmpeg` (usually a
file name). If this is `-` (as it is by default), the existing behavior
of playing the stream through `ffplay` is restored.
* `-f --format`: When recording to an output, this option can be used to
force the encoding format. If this is `-` (again, the default),
`ffmpeg`’s auto format detection is used (based on the file extension).
Because of the possible confusion between the newly added `--output`
option and the existing `--destination` option for specifying the source
address, I suggest renaming the `--destination` option to `--source`
(this is implemented in this commit).
Examples
========
Record to a file
----------------
```sh
./reStream.sh -o remarkable.mp4
```
Caveat: The recorded file plays back too fast.
I am not sure how to fix this.
Create an UDP MPEG-TS stream
----------------------------
```sh
./reStream.sh -o "udp://127.0.0.1:1234" -f "mpegts"
```
This sends frames over UDP to the specified port using the MPEG-TS
format (see <https://trac.ffmpeg.org/wiki/StreamingGuide>). This stream
can then be connected, for example, to OBS for live streaming (see
<https://connect.ed-diamond.com/Linux-Pratique/LP-096/Enrichir-sa-diffusion-de-contenus-multimedias-avec-OBS>
in French).
