Transcoding anything >720p is painful.

I run ancient hardware for desktop/laptop >10yrs old apple stuff running linux. I consume media mainly via rpi4 or android.

What’s a minimum level system capable of trans-coding 4k video to x265 in at the very least real time? Is there a tiny trans-coding device out there somewhere?

Would a NUC do? How old or new to churn out 4k x265

Can I avoid hardware? Are cloud gpu’s a thing?

  • Snowplow8861@lemmus.org
    link
    fedilink
    English
    arrow-up
    37
    ·
    10 months ago

    So I think you may not know about quick sync, an Intel transcoding acceleration feature of Intel gpus in Intel CPUs.

    https://handbrake.fr/docs/en/latest/technical/video-qsv.html

    There’s information about it for I think plex and handbrake and ffmpeg in general. This is how some people do real time transcoding for media servers. But I’m not an expert. I just hope you can be guided with easier search terms.

    • Toaster@lemmy.world
      link
      fedilink
      English
      arrow-up
      19
      arrow-down
      1
      ·
      10 months ago

      What a great example for the community you are, my guy. I love it.

      Speaking up, knowing you don’t have the full answer but can at least point in a general direction, is HUGE in a community full of constant and rapid change where the previous years information could already be outdated or even obsolete.

  • bigredgiraffe@lemmy.world
    link
    fedilink
    English
    arrow-up
    6
    ·
    edit-2
    10 months ago

    As the other person said, NUCs and such are able to do transcodes via Intel QuickSync hardware acceleration, it’s not really possible to transcode 4k in realtime on most CPUs without it.

    You will need at least an 8th gen Intel processor to do HVEC which is what h265 uses, more info is in this chart on Wikipedia about which generations support which things. Anecdotally, this has worked extremely well for me for a long time, definitely worth it.

    Also be aware if you are doing any virtualization you will need to pass the iGPU through to the guest machine.

  • quinkin@lemmy.world
    link
    fedilink
    English
    arrow-up
    6
    ·
    10 months ago

    If time is not a consideration just batch up transcodes with your shitty hardware and nice/renice the process out of the way.

    • SnailMagnitude@mander.xyzOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      10 months ago

      It seems unreasonable with the hardware, even with nice things.

      I run Gentoo, with lots of binaries, on my 2011 iMac just fine but encoding HD video on it feels like abuse.

  • Afiefh@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    ·
    10 months ago

    Sorry, you need hardware.

    If you are doing a ton of encoding, you could even get specialized hardware like amd alevo (spelling?) card which enables you to encode even AV1.

    That being said, what are you doing that requires you to encode h.265 on ancient hardware?

    • SnailMagnitude@mander.xyzOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      10 months ago

      I’m using a 2011 imac & 2010 macbook pro as my main devices. I have an rpi4 as a little media center & personal server.

      2160p x265 looks great on the pi, 2160p x264 is grim. Encoding 2160p on any of my systems is pain.

      Ongoing it would be nice to be able to re-encode the occasional 2160p video faster than a tenth of real time or feeling like I’m overly stressing very old hardware.

      Think I may keep an eye out for a 2nd hand nuc, I like small & quiet and I didn’t realize until posting this thread that cpu encoding is preferred to gpu. A nuc would also be nice for some better retro game action than the pi4.

  • cmnybo@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    3
    ·
    10 months ago

    If you want real time transcoding, then a hardware encoder would be best. Intel CPUs have had hardware H.265 encode support for the last 8 years. Intel ARC GPUs have a very good video encoder, but they require system that supports resizable BAR.

    If you just want to transcode a large number of videos for storage, get a system with loads of CPU cores and run multiple transcodes in parallel. Software encoders produce higher quality video than hardware encoders.

    There are cloud GPUs, but that gets very expensive, very fast. You are much better off buying your own hardware if you need to use it for a longer period of time.

  • HarriPotero@lemmy.world
    link
    fedilink
    English
    arrow-up
    6
    arrow-down
    3
    ·
    10 months ago

    It’s hard to beat a GPU in HEVC encoding performance. SoC:s have comparable performance to dGPU:s in that regard. A used zen/zen2 laptop might be a cheap and tiny workhorse for the purpose. I have a zen/vega10 matebook 2020 that does 1080p at around 2.5-3x real-time at high quality presets. No doubt it could do 4k at faster presets.

    With the hardware in my arsenal I’ve found that AMD>Intel>nVidia, at least quality wise. VideoToolbox on Mac is down there with nVidia, and Apple silicon being pretty slow at it compared to software x265 on the same machine.

  • Faceman🇦🇺@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    3
    ·
    10 months ago

    An intel nuc with an IGPU from the last few generations would do it no problem (even a pentium or i3 from the last few generations would be better than what you have by the sounds of it).

    Or you can grab a cheap used quadro p600 or gt1050 (minimum model with hardware H265 NVENC support) and use that for transcoding or run an app like tdarr, unmanic or fileflows to convert your library to a direct streamable format in the background.

    Why are you even requiring transcode is also something to look at, you should be trying to get your playback devices to play the raw files directly, that means a solid network infrastructure and properly configured software. If they are physically incapable of playing your 4k media then you need to look at upgrading them.

    This all applies whether you are running plex, jellyfin, emby or whatever else.

  • Dandroid@dandroid.app
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    1
    ·
    edit-2
    10 months ago

    I converted all my ripped Blu Rays over the past couple of weeks. I just used ffmpeg. It took a a while to find the right options to keep subtitles and multiple audio channels and such, but eventually I got it all perfect.

    I found that using my GPU made the quality absolute shit. It was about 3x faster than using my CPU though.

      • Dandroid@dandroid.app
        link
        fedilink
        English
        arrow-up
        1
        ·
        10 months ago

        I put it in a script, so I’ll need to check my server later.

        Do we have a remindme bot here?

          • Dandroid@dandroid.app
            link
            fedilink
            English
            arrow-up
            3
            ·
            10 months ago

            Your reminder worked! Here is the command I used. I put it in a script, and would pass it the file I wanted to convert.

            ffmpeg -i "$1" -vcodec libx265 -crf 28 -map 0 -c:s copy "${1%.*}.h265.mkv" > ./convert_logs 2>&1 < /dev/null &

            If I called this script convert_to_h265.sh, I would call it with convert_to_h265.sh some_video.mkv

            Here is an explanation for the options I used:

            ffmpeg is the command
            -i "$1" is the input file. In this case, the argument to the script
            -vcodec libx265 is specifying the plugin to use as libx265
            -crf 28 is specifying the quality/compression rate. I found this one to be pretty acceptable
            -map 0 makes it select ALL audio tracks and ALL subtitle tracks
            -c:s copy copies subtitle tracks
            "${1%.*}.h265.mkv" specifies the output file. In this case, everything up to the last dot, then replace the extension with ‘.h265.mkv’
            > ./convert_logs 2>&1 < /dev/null tells the program to output to a log file instead of writing to your terminal. It also sets the input to nothing, and without that, it won’t work in a script for some reason.
            & tells the whole thing run in the background so it doesn’t hold up your terminal. You can even close your terminal and do other things and check back on it later.

            You can monitor the progress with tail -f convert_logs

            If you want to get fancy, you can even put this in a loop to run on all the files that end in .mkv in the current directory:

            for i in *.mkv; do
                   ffmpeg -i "$i" -vcodec libx265 -crf 28 -map 0 -c:s copy "${i%.*}.h265.mkv" > ./convert_logs 2>&1 < /dev/null
            done
            

            And if you want to get mega fancy, you can have it run recursively for all files that end in .mkv in the current directory and all files in all child directories.

            shopt -s globstar
            for i in **/*.mkv; do
                    ffmpeg -i "$i" -vcodec libx265 -crf 28 -map 0 -c:s copy "${i%.*}.h265.mkv" > ./convert_logs 2>&1 < /dev/null
            done
            

            If you do either of the latter two, I would put it in a script. Let’s call the first one convert_all_to_h265.sh and the second one convert_all_to_h265_recursively.sh. Call them with convert_all_to_h265.sh & and convert_all_to_h265_recursively.sh & if you want to run them in the background.

            You also might want to play around with the -crf 28 value if you want more compression or more quality. The lower the number, the better the quality. It needs to be a value between 0 and 51.

            • MolochAlter@lemmy.world
              link
              fedilink
              English
              arrow-up
              2
              ·
              10 months ago

              Dude this is the most thorough explanation of a single command line I’ve ever had!

              Thanks for the effort, and the line itself.

              • Dandroid@dandroid.app
                link
                fedilink
                English
                arrow-up
                2
                ·
                10 months ago

                I put a hours of research into this, and I felt like documentation was difficult to understand, so I wanted to pass along what I’ve learned! I hope it works for you.

      • Nawor3565@lemmy.blahaj.zone
        link
        fedilink
        English
        arrow-up
        1
        ·
        10 months ago

        If you’re actually ripping bluerays, I would highly recommend using MakeMKV. It’s technically paid software but while it’s in beta you can can a free license key from their forums. BluRays can be formatted oddly and include a bunch of crap you probably don’t want (preroll ads, etc), so when I tried to rip one with jusy ffmpeg it was a pain, but MakeMKV deals with most of that for you and gets a 1-to-1 copy of the movie files + anything like captions and alternate audip tracks.

  • grooving@lemmy.studio
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    2
    ·
    10 months ago

    Try handbrake maybe https://handbrake.fr Might not be exactly what you want but something to look at while you wait for other answers.

    If you are actively making 4k videos through, I think it might be time for you to upgrade.

  • AustralianSimon@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    1
    ·
    10 months ago

    NUC should be fine. I have unmanic running in a container on it converting anything I add to folders.

    • Eager Eagle@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      10 months ago

      it depends, they break even if you run them for many hours a day, but for smaller / quicker workloads they can make a lot of sense

  • HumanPerson@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    ·
    10 months ago

    I would recommend trying to rent a vps for just long enough to transcode and using that. It would be way cheaper than buying new hardware.