Allow choosing the video output

matteodelabre commented 4 years ago

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

./reStream.sh -o remarkable.mp4

Caveat: The recorded file plays back too fast. I am not sure how to fix this. (Edit: Fixed, see below.)

Create an UDP MPEG-TS stream

./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).

matteodelabre commented 4 years ago

Update: I fixed the bug where recorded videos play back too fast by using the setpts filter to assign each frame’s presentation timestamp with the time it is received by the encoder. This is based on an example in ffmpeg’s man pages: https://ffmpeg.org/ffmpeg-filters.html#Examples-141.

matteodelabre commented 4 years ago

This sounds totally reasonable, I applied your suggested changes to my branch. I also took the opportunity to fix the merge conflicts.

There’s a slight inconvenience caused by replacing arrays with variable substitutions which arises when $output_args contains multiple arguments. ffmpeg receives them all as a single argument and therefore fails. To fix this I took advantage of the $@ array which IIRC is POSIX-compliant.

rien / reStream