H.265 encoding without hardware support with OBS and FFMPEG

  • 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

  • Well done - it's not easy to get ffmpeg to do when you want because there are so many options and documentation is sparse. The nvidia coder only works with cards that support it, as you found, but I am surprised your PC can do real time H265 encoding without hardware and run obs with a CPU load of 7%. I am just using OBS and nvenc as I have a GTX1060 which has hardware H265 encoding and my CPU load is higher than that. One thing to watch is if you have lots of scenes running in the background you can find a lot of CPU use - e.g. Mulitimedia files that carry on decoding rather than start and stop when activated.


    SV8RV has demonstrated you can run full HD in 66ks 8-PSK with 8/9 coding, so you should certainly be able to run it in 125ks QPSK. Have a go. Getting the audio vs video timing right is a usual problem at low bit rates. Increasing the PCR/PTS value helps with the timing. That's what this parameter is for.


    Moving on to low symbol rates (125 can not really be considered low any more!) we need to reduce audio to of the order of 8kb/s to have enough bandwidth for reasonable 265 Hvideo at 66ks and below. 66ks QPSK might give you a better link budget, but you may be reduced to 640x360 or lower. I think you can do this with your script by making suitable modifications. It might be worth paramatarising this in a script, so you just tell it the data rate (pluto tells you this) and it works out the rest.


    Mike

  • Hi Mike,


    I have a i7-3610QM CPU @ 2,3GHz 8GB RAM and only a few scenes in OBS (test pattern, image show, shack cam and one with an image film of the region here). "First-stage" H.264 encoding is hardware supported.

    Concerning the CPU load, it depends a bit what is fed from OBS to FFMPEG. I only work with 12 FPS and a low resolution, so FFMPEGs work is also not that much.


    Thanks for the hint with PCR/PTS. I could improve the stream quality by increasing that value.


    I have a big big playing field now with that solution and I will also try the lower bitrates. Saw SV8RV's transmission with SR66 and 8PSK. It's really amazing what is possible wit such a small bandwidth.


    I am really happy, that i can work the QO-100 WB transponder with my equipment. Works better than I expected :D


    Thorsten

  • I have a working WB system using OBS and H264 coding.

    Works perfect but l would like to go to H265 so purchased a new PC with a Rijzen 3200 GPU which is supposed to have hardware 265 support.
    After days of experimenting and lots of driver downloads I could not make it work.
    So moved to experimenting with ffmpeg and tried to convert MPeg 2 TS via OBS record and UDP to H265 linked to Pluto via UDP.
    Quite complIcated to find the settings but it seems to work somewhat.
    The quality of pictures is however poor and worse than H264.
    Pluto has trouble accepting the stream and syncs quite difficult even with low input bitrates.
    Playing with parameters for days has not improved things

    Looking at the output of ffmpeg I noticed more dan 50% dropped frames which may be the cause. With different bitrates and fps settings etc the drop % can be improved a little but remains very high.
    The CPU load is 25% or less so cannot cause this.


    Anybody with experience or ideas ?


    Jack

    PA3AXO

  • I am using Nvidia. Don't know if there is support for AMD stuff, probably. You set OBS up to record and set appropriate parameters. This is complex. See the BATC magazine and Wiki. What are you setting in OBS?


    An alternative is to use a hardware box like the H264/H2265 encoder that Evariste F5OEO's firmware supports.


    Mike

  • I'm trying H265 using a Nvidia Card (GTX1650) and this works for bitrates about 360kS (TS-Stream!) and above. I did not find settings for extreme low bitrates yes. 125 kS and 66kS transmit rates .... It's really tricky. Next I'll try the UDP way with OBS using ffmpeg in a batch job.


    Perhaps I must shrink my video down to a stamp size.


    Mike, does the hardware box support these low rates (66, 33 kS)? Usually those stations have no usable audio when receiving them via minitiouner at those rates.


    73 Mike

  • The box doesn't do very low rates, at least not well - when on my main PC I will send the profile for low bit rates for OBS. I can only find an out of date one from 6 months ago on my archive and there are better ones now


    66ks


    FFVCustom=preset=slow profile=main10 tier=high level=6.2 rc=cbr_hq


    35ks


    FFVCustom=profile=main level=4.0 rc=cbr_hq rc-lookahead=10 surfaces=2


    Tomorrow if I remember I will find the newer profile


    It's Tomorrow - or rather was but is now today, or would have been if now was then, whatever...


    The attached seems to work for 66ks 8PSK 5/6 - please ignore the muxer settings which are not right - they are largely ignored by the pluto but matter for other recordings. The important line is the one under video encoder settings. Also not the lower resolution helps, if you want to do good quality full high definition you really need to be using 333ks 3/4 or at least 250k 5/6. It also helps to reduce the frame rate if you can - see the video tab. Keep audio at 32k. OBS Record is used to send the data via UDP to the Pluto.



    Here are settings for 333ks 3/4 I am using this at 1920x1080.




    It's possible to go higher, especially with 8 PSK but 4K video only really benefits from higher bit rates. Static images are fine in 4K but anything moving isn't which undermines the quality. As the transponder is a shared resource high bandwidth needs only to be used when not causing trouble for others. Besides, who want's to see the average ham's mugshot in such high detail?


    Hope this helps.


    Please add better settings if you have them.


    Mike

  • Thanks Michel


    A useful link. Question still remains what would be better for low rates. The examples assume something like 1 Mb/s whereas we are looking at more like 30-300kb/s. I was testing at 66k earlier and the video was OK but not great - like an 80s VCR on LP. I am sure it is possible to do better. The 333ks is fine but again, perhaps could be improved.


    Mike

  • Thank you Mike and Michel. When my first DATV setup will be finished, I'll have only 10-15W into my 1.2m OFS-dish using a POTY.

    So I've to find a setting that I could use to bring a little bit video+audio via the WB transponder.


    Later I'll add more power. We will see...