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).
Previously, arguments were examined by a for loop, but this loop is not
affected by the `shift` commands executed inside of it.
Because the loop always advances one argument further on each iteration,
this bug goes unnoticed with the `--portrait` option (`shift` is called
once, which matches the behavior of the loop). However, handling of the
`--destination` argument is broken because of that (`shift` is called
twice but the loop only advances one argument).
This commit replaces the `for` loop by a `while` loop which always
examines the next argument and properly takes `shift`s into account.
This is based on the following SO answer:
<https://stackoverflow.com/a/7069755/3452708>
Changed the README to reflect the command line options added with
bcf62e3. Also incorporates the SSH timeout of 1 second added by the
initial PR (#10).
Co-authored-by: Aaron David Schneider <aaron.david.schneider@gmail.com>
f3fora