Nearing the filling of my 14.5TB hard drive and wanting to wait a bit longer before shelling out for a 60TB raid array, I’ve been trying to replace as many x264 releases in my collection with x265 releases of equivalent quality. While popular movies are usually available in x265, less popular ones and TV shows usually have fewer x265 options available, with low quality MeGusta encodes often being the only x265 option.

While x265 playback is more demanding than x264 playback, its compatibility is much closer to x264 than the new x266 codec. Is there a reason many release groups still opt for x264 over x265?

  • iturnedintoanewt@lemm.ee
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    8 months ago

    If your Jellyfin collection starts to grow big enough, and x264 transcoding on the fly is as easy as passing through the GPU these days…it’s pretty much a no brainer. You have small files, and if someone still needs x264 (which would need to be specifically a Firefox streamer, as I believe Chrome supports it, and the Jellyfin apps also support it if your computer/phone does), the transcoding on the fly can be done using about 1-2% of the server CPU. I did something like 12 simultaneous different transcodes once, and my oldish i5 9500T held its ground perfectly, I think it reached about 35% CPU at the peak of it.

    • Saik0@lemmy.saik0.com
      link
      fedilink
      English
      arrow-up
      2
      ·
      8 months ago

      9500T has quicksync. That’s why you’re transcodes were only 1-2% on the cpu. You were doing transcoding on the built in gpu.

      It is NOT trivial to do transcode without hardware decoding. How much utilization was on your 630 iGPU in that scenario?

      • iturnedintoanewt@lemm.ee
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        8 months ago

        Well it’s a Jellyfin server. I bought a CPU that CAN transcode, for this specific purpose. Without hardware decoding, CPU usage scales quite quickly, but it could still hold 3-4 streams at 60fps I believe. At any rate, I bought this 2nd hand microPC with the specific purpose of being a Proxmox server with Jellyfin transcoding. And so, between having to consider further hard drive upgrades, or using the transcode function…I kinda choose the cheapest one since it’s at hand.

        • Saik0@lemmy.saik0.com
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          8 months ago

          Congrats? I’m running my Plex server on enterprise hardware. There’s no onboard gpu for decoding because that’s not the purpose of that hardware. I do have a graphics card in there to do transcodes, and intimately monitor that usage. My original statement still holds. “which could be a problem if you’re CPU limited or have no GPU for hardware transcoding.”

          Transcoding may not be that accessible/useful for some people. I’d rather waste some drive space than do transcodes for every user, but that’s because I have 400TB(not a typo) of space but don’t have enough space to put in any card that takes up more than 1pci slot. In my mind throwing another 20TB drive into my configuration is easier and cheaper than transcoding. In a couple of years we’re going to be having this discussion for AV1 anyway.

          Edit: Oh, and 3-4 streams at 60fps, isn’t enough description… really doesn’t cover the most taxing part of the transcode process, which is resolution. 3-4 1080p streams is much easier than even 1-2 4k streams. Considering that content is trending towards higher resolutions rather than higher framerates, I’m not sure what you’re getting at. My T600 can do 3-4 4k streams before it starts running into problems. That should be something like 15-16 1080p streams. Considering my library, I’d still rather have the drives in a more accessible format that will direct play on more devices than transcode my 60-100mbps 4k videos. Keep the transcoding for those that really need it rather than making it the default answer.