SOLVED: Artifacting when transcoding H264 source only when seeking

[5fish]

Hello everyone,
I'm encountering an issue where transcoding an H264 source causes severe green artifacts ONLY once a seek is performed, or when the playback is started from a saved position (not the beginning).

2 log files were created when starting playback from a saved position, and the second indicates errors:
https://v.5fish.me/r/FFmpeg.Transcode-20...db8f96.log
https://v.5fish.me/r/FFmpeg.Transcode-20...2c29e4.log
Similarly, 2 logs were created with the same errors in the second log when playing from the beginning, then seeking.

Playing the video from the start without seeking allows playback without issue:
https://v.5fish.me/r/FFmpeg.Transcode-20...006d0d.log

I'm running the official Jellyfin 10.10.3 server binary for Windows, but have encountered the issue on 10.10.1, as well as on a fresh 10.10.3 install on a separate machine (Windows, NVENC).
Both NVENC and software transcoding have the same issue, and transcoding to H264 instead of HEVC did not help either.
I have also tried replacing the jellyfin-ffmpeg binary with older versions (7.0.2-5, 6.0.1-8), but no change.
All playback was done on the Jellyfin Web Player on both Chrome and Firefox.
The source file plays and seeks without issue on VLC.

Any suggestions would be appreciated, and I can provide further logs if needed.
Thanks!

[TheDreadPirate]

Try remuxing your file. Something is likely corrupt with the file. Often times the video and audio are fine, but the container is corrupt or malformed.

In a command prompt

Code:

cd C:\Program Files\Jellyfin
ffmpeg.exe -fflags +genpts+igndts -i "D:\Mediaserver\Anime\data\media-link\shows\Baccano! (2007)\Season 1\Baccano! (2007) - S01E05 - 005 - Jacuzzi Splot Cries Gets Scared and M... [HDTV-720p][10bit][x264][AAC 2.0][JA]-MTBB.mkv" -map 0 -codec copy -max_muxing_queue_size 2048 -max_interleave_delta 0 -avoid_negative_ts disabled newFile.mkv"

Add the new file to your library and try again.

[5fish]

Thanks for the quick reply and detailed instructions.
I've given the remux a shot, but unfortunately seem to be getting the same result:
https://v.5fish.me/r/FFmpeg.Transcode-20...626bd2.log
https://v.5fish.me/r/FFmpeg.Transcode-20...b2411e.log
I can verify that the remuxed file does also play & seek without issue in VLC, and is different from the original file (different CRC).

[nyanmisaka]

These H264 High 4:4:4 files are encoded by a broken version of the x264 encoder.

Simply remuxing will not do anything. Something else must be done to repair them.

https://github.com/jellyfin/jellyfin-ffm...-741722767

[5fish]

Thanks for the further info.
I unfortunately was running into the same issue after attempting patching in SEI data as suggested in the linked GitHub issue, but have settled on re-encoding and that seems to have done the job. 🙂