realtime h.264 encode of http stream using a Pi4

[martincjose]

Hello everyone,

I have a HDHomeRun Extend which I can use to stream OTA TV throughout the house. I have a Linux laptop that I installed VLC on that I use to stream TV when I am outside the house. I use the following VLC command line to do it:

vlc http://192.168.1.223:5004/auto/v2.1 --sout-x264-profile=main --sout-x264-level=0 --sout '#transcode{vcodec=h264,acodec=mp3,vb=1000,ab=32,channels=1,samplerate=22050,width=854,height=480} : standard{access=http,mux=ts,dst=:8080}'

The problem with this is that it takes a lot of CPU. I would like to do something similar using the Raspberry Pi4 since it has a built in h.264 encoder. I tried playing with ffmpeg but couldn't get it going. Any help would be appreciated.

I know I can have the HDHomeRun Extend do the h.264 encoding but where's the fun in that?

Thanks

[tmm1]

What issue did you have with ffmpeg on the Pi?

It should work with -c:v h264_omx

[martincjose]

Everything . I am completely new to ffmpeg and couldn't figure out the command need to take the http video/audio stream, compress it using built in h.264/mp3|aac and send it out on my local machine (Pi4) port 8080 as a mpegts stream. My goal is to view it on another device using VLC.

Thanks

[demonrik]

as @tmm1 mentions - you need to use omx-h264 as the vcodec on a suitably enabled ffmpeg on your rpi.
so need to check which ffmpeg your vlc is running and if enabled

but what exactly are you trying to do?!
The extend already has ability to transcode before you even bring it to your VLC?
If your VLC server is taking up too much CPU I would look to see if you can get the extend to output the transcode you want via the HTTP API optional parameter 'transcode=<profile>' https://info.hdhomerun.com/info/http_api

if your not happy with the extend outputs, you can get better via ffmpeg, but you run in to a few limitations and CPU/memory usage will vary depending on how crazy you get
- rpi encoder maxes out at 1080p30
- no mention of interlaced encoding in spec for RPi4.. so not sure if you have to do a de-interlace for 1080i content anyway
- not clear even if using the HW decoder and encoder if ffmpeg sets up a HW pipeline to reduce copies, otherwise it's going to have to copy the decoded image to the CPU and then copy from CPU to the decoder - which consumes CPU and of course memory
- command line you have has an implicit de-interlace and resize - both consume CPU
- you will consume CPU anyway for audio transcode of AC3 to MP3
- you will also always consume CPU to demux the TS file from the extend, and remux to TS once the transcodes are done
- muxing will likely time sync, and while the CPU isn't technically active, it can report as loaded.

When you say takes a lot of CPU, you don't say how much - it can be quite surprising even with HW accelerators how much CPU is still consumed in the overall flow, never mind how much memory it all consumes as you end up having lots of copies here there and everywhere - particularly with stacks like ffmpeg which is designed for offline file transcoding and not live linear video such as a TS stream from your tuner.
I've done such apps for other HW accelerators and its painful connecting up the various pieces while ensuring optimal perf and resource utilization because the default in most apps is to just make it functional.

So all in all - try the transcode of your Extend - it's pretty good.

[martincjose]

First of all this is not critical and I am just doing this to pass the time and learn something in the process. What I want to do is broadcast the output of HD Extend so that I can stream it and watch outside my house using VLC. I was doing this on my linux PC with the following cli:

vlc http://192.168.1.223:5004/auto/v2.1?tra ... nternet540 --sout-http-user=user --sout-http-pwd=password --sout '#standard{access=http,mux=ts,dst=:8080}'

All I have to do is port forward 8080 to my laptop and I can watch from outside plus I can password protect my stream.

So now I recently purchased a Pi4 and I wanted to do something similar but have the Pi4 do the transcoding. Extend does a very good job of transcoding but I wanted to try the Pi4's built in transcoding and see how it performs. Maybe tweak it for best video at low bit rate, etc.

I know the Pi4 maxes out at 1080p30 but I would be happy with 720p30. Also, all video will be progressive so de-interlacing would not be necessary. If necessary I could passthrough the AC3 instead of transcoding it. Lastly, I was muxing the video and audio into a TS stream. Is there a better (lower cpu) option for streaming? I am open to any suggestions and any help with the cli (vlc and ffmpeg) would be appreciated.

Thanks

[tmm1]

ffmpeg -i http://x:5004/auto/vXX -c:v h264_omx -c:a copy -b:v 4000k -f mpegts transcoded.ts

[martincjose]

Thank you for the cli. I finally got some time to play with this and here is what I found:

Following copies the video stream and compresses the audio to 64Kbps and muxes the stream out on port 8080. I consider this as my baseline. With this 'top' shows approx 13% CPU usage for ffmpeg and 11% for cvlc:

Code: Select all

sudo ffmpeg -i http://192.168.1.223:5004/auto/v2.1 -c:v copy -b:a 64k -f mpegts - | cvlc - --sout '#standard{access=http,mux=ts,dst=:8080}'

Following compresses the video using h264_omx (built in encoder) and also compresses the audio. With this the video is more pixelated (expected) and I can see interlace artifacts. But the main issue is that the CPU for ffmpeg is between 100-120% and approx 3% for cvlc. Shouldn't the built in h.264 encoder offload some of the CPU?

Code: Select all

sudo ffmpeg -i http://192.168.1.223:5004/auto/v2.1 -c:v h264_omx -b:a 64k -b:v 3000k -f mpegts - | cvlc - --sout '#standard{access=http,mux=ts,dst=:8080}'

Also, any other suggestions for streamlining the workflow would be appreciated.

Thanks.

P.S. I tried "-vf yadif" to deinterlace but that caused the output to break up while the CPU went up to 170+%

[kyl416]

The high CPU usage might be because it's using software decoding for MPEG-2 before it transcodes the video to h264. Unfortunately the Pi4 doesn't have a hardware MPEG-2 decoder, only the older models do after you purchase a MPEG-2 license key.

So this is likely a case where the Rasberry Pi3 works better than the latest model. With a Pi3 and the mpeg-2 license key activated you would do something like

Code: Select all

sudo ffmpeg -c:v mpeg2_mmal -i http://192.168.1.223:5004/auto/v2.1 -c:v h264_omx -b:a 64k -b:v 3000k -f mpegts - | cvlc - --sout '#standard{access=http,mux=ts,dst=:8080}'

Also, you might want to leave the audio codec as is with -c:a copy. If you don't specify an audio codec option the mpegts mux transcodes the audio to mp2, and their default transcoding isn't that great when it comes to downmixing 5.1 content to stereo because the center channel (dialogue) gets drowned out by the left, right and surround channels, so if your mobile device supports ac3 decoding you might want to leave it as is. At most it will only be 384 kbps.


BTW, I'm not sure if sudo is a requirement here. It might be needed for VLC to open port 8080 or for ffmpeg to directly access the hw codecs, but you might be able to get around that by adding your username to the netdev, video and render groups.

[martincjose]

Thank you everyone for all the great suggestions. I learned about ffmpeg, c/vlc and Pi4 - but most impotently I learned to stick to using the HDHomeRun Extend encoder. It's much better and easier .