restream/reStream.sh

125 lines
3.0 KiB
Bash
Raw Normal View History

2020-02-12 13:13:14 +01:00
#!/bin/sh
# default values for arguments
Allow choosing the video output 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).
2020-04-02 19:32:59 +02:00
ssh_host="root@10.11.99.1" # remarkable connected through USB
landscape=true # rotate 90 degrees to the right
Allow choosing the video output 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).
2020-04-02 19:32:59 +02:00
output_path=- # display output through ffplay
format=- # automatic output format
2020-04-01 16:51:01 +02:00
# loop through arguments and process them
while [ $# -gt 0 ]; do
case "$1" in
2020-04-01 16:51:01 +02:00
-p|--portrait)
landscape=false
shift
;;
Allow choosing the video output 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).
2020-04-02 19:32:59 +02:00
-s|--source)
ssh_host="$2"
shift
shift
;;
Allow choosing the video output 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).
2020-04-02 19:32:59 +02:00
-o|--output)
output_path="$2"
shift
shift
;;
-f|--format)
format="$2"
shift
shift
;;
2020-04-01 16:51:01 +02:00
*)
Allow choosing the video output 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).
2020-04-02 19:32:59 +02:00
echo "Usage: $0 [-p] [-s <source>] [-o <output>] [-f <format>]"
exit 1
2020-04-01 16:51:01 +02:00
esac
done
2020-03-12 00:17:13 +01:00
# technical parameters
2020-02-12 13:13:14 +01:00
width=1408
height=1872
bytes_per_pixel=2
loop_wait="true"
loglevel="info"
ssh_cmd="ssh -o ConnectTimeout=1 "$ssh_host""
# check if we are able to reach the remarkable
if ! $ssh_cmd true; then
2020-02-12 13:13:14 +01:00
echo "$ssh_host unreachable"
exit 1
fi
2020-03-12 00:17:13 +01:00
fallback_to_gzip() {
echo "Falling back to gzip, your experience may not be optimal."
echo "Go to https://github.com/rien/reStream/#sub-second-latency for a better experience."
compress="gzip"
decompress="gzip -d"
2020-03-12 00:17:13 +01:00
sleep 2
}
# check if lz4 is present on remarkable
if $ssh_cmd "[ -f /opt/bin/lz4 ]"; then
compress="/opt/bin/lz4"
elif $ssh_cmd "[ -f ~/lz4 ]"; then
compress="~/lz4"
fi
2020-02-12 13:13:14 +01:00
# gracefully degrade to gzip if is not present on remarkable or host
2020-03-12 00:17:13 +01:00
if [ -z "$compress" ]; then
echo "Your remarkable does not have lz4."
2020-03-12 00:17:13 +01:00
fallback_to_gzip
elif ! which lz4; then
echo "Your host does not have lz4."
2020-03-12 00:17:13 +01:00
fallback_to_gzip
else
decompress="lz4 -d"
2020-03-12 00:17:13 +01:00
fi
2020-02-12 13:13:14 +01:00
output_args=""
video_filters=""
Allow choosing the video output 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).
2020-04-02 19:32:59 +02:00
# calculate how much bytes the window is
2020-02-12 13:13:14 +01:00
window_bytes="$(($width*$height*$bytes_per_pixel))"
2020-03-12 00:17:13 +01:00
# rotate 90 degrees if landscape=true
$landscape && video_filters="$video_filters,transpose=1"
2020-03-12 00:17:13 +01:00
# read the first $window_bytes of the framebuffer
head_fb0="dd if=/dev/fb0 count=1 bs=$window_bytes 2>/dev/null"
2020-03-12 00:17:13 +01:00
# loop that keeps on reading and compressing, to be executed remotely
read_loop="while $head_fb0; do $loop_wait; done | $compress"
Allow choosing the video output 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).
2020-04-02 19:32:59 +02:00
if [ "$output_path" = - ]; then
output_command=ffplay
else
output_command=ffmpeg
if [ "$format" != - ]; then
output_args="$output_args -f '$format' "
Allow choosing the video output 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).
2020-04-02 19:32:59 +02:00
fi
output_args="$output_args '$output_path'"
Allow choosing the video output 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).
2020-04-02 19:32:59 +02:00
fi
# set frame presentation time to the time it was received
video_filters="$video_filters,setpts=(RTCTIME - RTCSTART) / (TB * 1000000)"
output_args="$output_args -vf '${video_filters#,}'"
2020-03-12 00:17:13 +01:00
set -e # stop if an error occurs
2020-02-12 13:13:14 +01:00
$ssh_cmd "$read_loop" \
| $decompress \
Allow choosing the video output 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).
2020-04-02 19:32:59 +02:00
| "$output_command" \
-vcodec rawvideo \
-loglevel "$loglevel" \
2020-02-12 13:13:14 +01:00
-f rawvideo \
-pixel_format gray16le \
-video_size "$width,$height" \
Allow choosing the video output 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).
2020-04-02 19:32:59 +02:00
-i - \
"${output_args[@]}"