Raspberry guide

Temper your expectations

dizqueTV with ffmpeg transcoding can be pretty expensive. So running dizqueTV in the Pi might mean a reduction in the final picture quality in comparison to running it on a beefier computer. Of course, if you configure dizqueTV to fully direct play, this wouldn't be an issue, but disabling ffmpeg normalization comes with its own drawbacks.

Compiling from source

FFMpeg

dizqueTV needs ffmpeg version 4.2.x . Although greater ffmpeg versions might work, it's been mainly tested with 4.2.4. So this is a small guide on how to compile FFMpeg from source with a lot of codec support and in the specific 4.2.4 version.

Mostly the guide at https://pimylifeup.com/compiling-ffmpeg-raspberry-pi/ works pretty well. There is only one thing we have to change in order to have ffmpeg 4.2.4 specifically instead of the latest version. Instead of using the last (really long) command on that guide, do this:

git clone https://github.com/FFmpeg/FFmpeg.git ~/FFmpeg \
  && cd ~/FFmpeg \
  && git checkout n4.2.4 \
  && ./configure \
    --extra-cflags="-I/usr/local/include" \
    --extra-ldflags="-L/usr/local/lib" \
    --extra-libs="-lpthread -lm -latomic" \
    --arch=armel \
    --enable-gmp \
    --enable-gpl \
    --enable-libaom \
    --enable-libass \
    --enable-libdav1d \
    --enable-libdrm \
    --enable-libfdk-aac \
    --enable-libfreetype \
    --enable-libkvazaar \
    --enable-libmp3lame \
    --enable-libopencore-amrnb \
    --enable-libopencore-amrwb \
    --enable-libopus \
    --enable-librtmp \
    --enable-libsnappy \
    --enable-libsoxr \
    --enable-libssh \
    --enable-libvorbis \
    --enable-libvpx \
    --enable-libzimg \
    --enable-libwebp \
    --enable-libx264 \
    --enable-libx265 \
    --enable-libxml2 \
    --enable-mmal \
    --enable-nonfree \
    --enable-omx \
    --enable-omx-rpi \
    --enable-version3 \
    --target-os=linux \
    --enable-pthreads \
    --enable-openssl \
    --enable-hardcoded-tables \
  && make -j$(nproc) \
  && sudo make install

After that

/usr/local/bin/ffmpeg -version

Should show n4.2.4 as the version

You can save some storage space by deleting the ~/ffmpeg that was storing the whole ffmpeg project tree.

dizqueTV with node

• Install nodejs and npm. Recommended version is 12.18 , just because that's the version where dizqueTV is being tested. Higher versions may work but not tested. Installing a specific nodejs version in your raspberry Pi (or any linux environment) is a task on itself that's outside the scope of this write up, but you can read guides such as this one on the matter. You'll need the right nodejs build for your architecture (uname -m to know your current OS' architecture)

• Now you can install from source. Download the tar.gz from the dizquetv release you want to install or clone the git repository using git. This is for version 1.2.2:

cd some_workdir
git clone https://github.com/vexorian/dizquetv.git
cd dizquetv
git checkout 1.2.2

• Install packages

npm install

• Build dizquetv

npm run build

• Run dizquetv:

npm start

• You will also need to install a proper ffmpeg version.

Open dizqueTV

After npm start you should be able to open the dizqueTV web UI by using "IP:8000" in a web browser, where IP is the pi's IP. After this you can configure dizqueTV as usual. Make sure to change the ffmpeg location in the web UI to /usr/local/bin/ffmpeg

Docker

Docker images for raspberry Pi (or rather ARM architecture) are not currently available , but we'll hopefully have some eventually.

Tested configurations

If you disable ffmpeg features, dizquetv shouldn't have trouble with even 1080p video or perhaps 4K in the pi. But without ffmpeg normalization, the stream would break when switching between videos change. To avoid those issues we would need to do the transcoding in the pi.

Raspberry 4B (4GB of RAM though that probably doesn't matter that much):

In this pi I was able to get a 640x360 resolution stream to work just fine. The only changes were to increase the number of ffmpeg threads to 5 (Don't ask me why this improves performance on a 4 threads device, I guess it's because ffmpeg has more time to decode while waiting for network) and the vide bitrate to 1000.

720p might be possible by tweaking the settings further, but I figure that proper-quality 360p is better than low-quality 720p.