Hi,
the last weeks I played around with OBS, H.264 encoding and streaming via RTMP to my Pluto. Because of my limitations of RF power (about 20W) and dish size (about 73cm) I am bound to lower DATV bitrates (<=125kBit/s), but it works so far to send moving images via QO-100.
Now that i saw what H.265 can do, I tried to get the "nvenc_hevc" encoder working in OBS, but it seems, that this set needs hardware support, which my NVIDIA GT650M can't offer. My expectation was, that in case of no HW support this encoder uses software encoding through "libx265" which FFMPEG should support. But it doesn't and OBS doesn't show a "libx265" selection in the dropdown (like the "libx264").
A inquiry at the OBS forum wasn't succesfull, those guys live in their "4K-Twtich-Youtube" world and claimed, that H.265 software encoding will not work because of the CPU load (although i explained the background and that i want to use very low bitrates).
Anyway, until my HDMI/H.265 encoder arrives from China, i searched and found a solution to create a H.265 encoded stream for the Pluto with software encoding. This solution works fine for me with SR125, a 384x306 image size with 12 FPS and 12kHz mono audio and i would say the quality is some kind of "crispy clear" compared to the same conditions encoded with H.264.
What I use is:
The FIRM2201RC gives the possibility to feed the Pluto with UDP packets (thanks to DD4YR for that hint) instead of the common RTMP streaming described on the Pluto documentation page. This UDP stream can be created in OBS by recording to an URL instead of a file. Unfortunately software encoding is only possible with H.264, but not with H.265.
To work around this, the UDP stream is not sent to the Pluto directly, but to a local FFMPEG instance running which transcodes the stream from H.264 to H.265, downscales audio (thanks to G0MJW for the hint) and send another UDP stream to the Pluto.
The FFMPEG instance runs in a console window here with the following parameters:
ffmpeg -i "udp://localhost:7272" -vcodec libx265 -crf 33 -preset superfast -b:v 40k -acodec ac3_fixed -strict experimental -b:a 12k -ar 12000 -vf scale=384:-2:flags=lanczos -r 12 -f mpegts "udp://192.168.0.199:8282?pkt_size=1316"
-
-i "udp://localhost:7272"
FFMPEG listens locally at port 7272 for UDP input
-
-vcodec libx265
Selects the H.265 software encoder
-
-crf 33
Selects the "Constant Rate Factor" for quality (the lower the better)
-
-preset superfast
Selects the compression (the faster, the less delay, but the higher bitrate)
-
-b:v 40k
Set video bitrate to 40 kbit/s
-
-acodec ac3_fixed
Selects the AC3 audio encoder (more downscaling possibilities than AAC)
-
-strict experimental
Seems to be needed for the AC3 encoder (don't know exactly why)
-
-b:a 12k
Set audio bitrate to 12 kBit/s
-
-ar 12000
Set the audio sample rate (corresponds to the bitrate)
-
-vf scale=384:-2:flags=lanczos
Scale down the image to width 384 pixel, height is chosen automatically according to a parameter "n", use the "Lanczos" scaling filter (sharp)
-
-r 12
Set output feamerate to 12 FPS
-
-f mpegts
Use "MPEGTS" as output streaming container
-
"udp://192.168.0.199:8282?pkt_size=1316"
Send the output as UDP to IP:PORT with given packet size (copied from Robert 
)
I tried a lot of parameters for FFMPEG and also for OBS to get a good result and it wasn't always clear for me, why some combinations work and some not. The OBS settings can be found at the attachments. Also the Pluto transmit parameters I used ("PCR/PTS" and "PAT period" ar not really clear for me).
Just start FFMPEG, then start RECORDING(!) (not streaming) in OBS and PTT ("Switch ON") at the Pluto.
The H.265 output was really good via QO-100:
CPU usage for OBS was about 5..7%, for FFMPEG about 3..5%
The over-the-air stream is at its upper capacity level, but it works fine with my rig.
Maybe there are some improvements and optimizations one can do and I would appreciate if they could be shared here...
73, Thorsten
