SOLVED: HWA AMD VAAPI Stuttering

[floppy]

I have this weird stuttering that only happens on select media, I've not been able to pin point what actually differs from the media, I've attached some transcode log example and the stuttering result.

The only thing I can see that differs is the bad transcode input stream uses bt709

I'm using an RX580 with VAAPI in the latest linuxserver docker image



Bad Transcode: 
  stuttertranscode.txt (Size: 70.44 KB / Downloads: 73)
Good Transcode: 
  goodtranscode.txt (Size: 33.93 KB / Downloads: 61)

Vainfo: 
  vainfo.txt (Size: 1.5 KB / Downloads: 81)
OpenCL: 
  opencl.txt (Size: 2.05 KB / Downloads: 98)
Vulcan
  vulcan.txt (Size: 3.83 KB / Downloads: 60)

I can't upload an example video so hopefully a discord link will be okay   

https://cdn.discordapp.com/attachments/3...36/bad.mp4
https://streamable.com/za5c7g

[bitmap]

Quick look? This right here:

Code:

-filter_complex "[0:3]scale=s=1920x1080:flags=fast_bilinear[sub];[0:0]setparams=color_primaries=bt709:color_trc=bt709:colorspace=bt709,scale_vaapi=format=nv12:extra_hw_frames=24,hwdownload,format=nv12[main];[main][sub]overlay=eof_action=pass:shortest=1:repeatlast=0,hwupload_vaapi"

You have more complex subs being burned in through a complex filter and the video is being scaled in the stuttering transcode. I'll look more in-depth in a bit when I have time...

[floppy]

Quick look? This right here:

Code:

-filter_complex "[0:3]scale=s=1920x1080:flags=fast_bilinear[sub];[0:0]setparams=color_primaries=bt709:color_trc=bt709:colorspace=bt709,scale_vaapi=format=nv12:extra_hw_frames=24,hwdownload,format=nv12[main];[main][sub]overlay=eof_action=pass:shortest=1:repeatlast=0,hwupload_vaapi"

You have more complex subs being burned in through a complex filter and the video is being scaled in the stuttering transcode. I'll look more in-depth in a bit when I have time...

This is it! Turning off burned in subtitles resolved the stuttering, but now there is no subtitles, quick find on the cause, hopefully there is a simple solution

[bitmap]

Could you post a mediainfo or ffprobe of the file to provide more context on why the subs are being burned in? Guessing with anime the subs are too complex to display natively. If they're ASS/SSA and you're using a client that supports swapping players, you could try a different one (e.g., VLC might support more complex subs than ExoPlayer, built-in, or web). If they're PGS, DVD, VOB, etc... you'd want to find SRT subs. The down side for anime is you miss out on signs/songs translations. Personally, I don't care, but I've learned over time that I'm (in some cases literally) a heretic in a lot of the communities that I'm a part of so...

[floppy]

Could you post a mediainfo or ffprobe of the file to provide more context on why the subs are being burned in? Guessing with anime the subs are too complex to display natively. If they're ASS/SSA and you're using a client that supports swapping players, you could try a different one (e.g., VLC might support more complex subs than ExoPlayer, built-in, or web). If they're PGS, DVD, VOB, etc... you'd want to find SRT subs. The down side for anime is you miss out on signs/songs translations. Personally, I don't care, but I've learned over time that I'm (in some cases literally) a heretic in a lot of the communities that I'm a part of so...

ASS/Complex subs are preferable when working as it will overlay the subs in the correct place on the screen with good font/styling, it's a deal breaker for me personally without. I've been using CPU encoding as it works flawlessly however reduces the speed of encoding and strains the system much more

FFprobe: 
  ffprobe.txt (Size: 4.89 KB / Downloads: 50)

[bitmap]

Oh I'm well aware of why folks would prefer ASS over another format. My anime collection would make teenage me extremely jealous. If only adult me had time to watch it like teenage me did. Time makes fools of us all.

[nyanmisaka]

Upgrading to JF 10.9 should fix issue.

[floppy]

Upgrading to JF 10.9 should fix issue.

Nope, same issue: 
  transcode.txt (Size: 16.88 KB / Downloads: 65)

Code:

ujellyfin:
    image: jellyfin/jellyfin:unstable
    container_name: ujellyfin
    network_mode: 'host'
    group_add:
      - "109"
      - "44"
    volumes:
      - ./configs/ujellyfin/config:/config
      - ./configs/ujellyfin/cache:/cache
      - /storage/downloads:/downloads
    devices:
      - /dev/dri/card0:/dev/dri/card0
      - /dev/dri/renderD128:/dev/dri/renderD128
    restart: 'unless-stopped'

Code:

Server: mserv
Version: 10.9.0
Operating System:
Architecture: X64

[floppy]

I solved it, upgrading to ffmpeg6 manually worked, I'll write a quick guide on how I did that in case anyone has the same issue in the future

This assumes you're using docker

Code:

docker compose exec jellyfin /bin/bash;
cd ~;
curl -L https://github.com/jellyfin/jellyfin-ffmpeg/releases/download/v6.0-6/jellyfin-ffmpeg6_6.0-6-bullseye_amd64.deb --output ffmpeg.deb;
dpkg -i ffmpeg.deb;

That should get you up and running with ffmpeg6 and removed stuttering with subtitles

[bitmap]

I don't know how other folks handle their containers, but you can set this up as a pre-launch step for your container. Put a startup script in your custom init scripts folder that does a wget or curl call for jellyfin-ffmpeg6 and forces the update over version 5. Makes it essentially invisible, but will add a few seconds to "boot" time for your container.