2025-01-01, 11:15 PM
Are you using your Arc GPU to convert your media to AV1? Or just for transcoding?
2025-01-01, 11:15 PM
Are you using your Arc GPU to convert your media to AV1? Or just for transcoding?
2025-01-01, 11:58 PM
Just for transcoding, I haven't jumped in the AV1 bandwagon yet, since I only have one device with support for it, and none of my other JF users own one.
Server specs => OS: Debian 12 | GPU: Arc A380 | CPU: Ryzen 5 5600X | 64GB RAM | 56TB
2025-01-03, 11:51 PM
I'm encountering this odd error when trying to convert this DV7.6 file to HDR10. I've been perfectly successful with all my other DV files, so I'm not sure what's going on with this one. I attached the error plus the file info.
2025-01-04, 01:19 AM
(2025-01-03, 11:51 PM)lakinreid Wrote: I'm encountering this odd error when trying to convert this DV7.6 file to HDR10. I've been perfectly successful with all my other DV files, so I'm not sure what's going on with this one. I attached the error plus the file info. You can try -bsf:v:0 or figure out the stream ID of the included image and do a negative mapping after your -map 0.
Jellyfin 10.10.3 LSIO Docker | Ubuntu 24.04 LTS | i7-13700K | Arc A380 6 GB | 64 GB RAM | 79 TB Storage
2025-01-04, 06:22 PM
There is an embedded image that, for whatever reason, ffmpeg considers a "video". Do what bitmap said. Specify the stream. PROBABLY stream 0.
2025-01-14, 10:18 PM
@error101
Your problem is more likely that our dovi metadata logic hits an edge case of the HEVC encoding so that not all metadata in all frames are removed, and the leftovers created the "blinking" effect you are seeing. A jellyfin-ffmpeg fix is coming in a few days (by the end this weekend if nothing bad happens).
Today, 01:06 AM
(This post was last modified: Today, 01:07 AM by BotchedMiracle. Edited 1 time in total.)
I used the updated single line command to strip DV out of my videos since HDR10 plays way more nicely on LG Panels. Seriously, DV is always out of sync, or just choppy. No idea why, everything in the chain supports it. I think even my Xbox has issues with it.
Just wanted to say it's fantastic and hasn't failed me yet for the 5 or 6 files I've used it on. I've documented it and it will be a normal part of my routine. However, an out of the box tool or non-automated plugin in Jellyfin would be nice.
Today, 05:55 AM
Spoke too soon, now I see a problem.
I initially was doing this with smaller files, which worked great. Now i did it with a much bigger file. The file I tried to strip DV from was 35 GB. I have 32 GB of RAM installed. My unraid system doesn't consume too much ram. Usually 8 GB max with at LEAST 24GB to spare. This procedure loads the entire file in RAM (I think?). It crashed my Unraid system once it ran out of space (I'm pretty sure). Only reason I assume this is because I happened to have my Unraid system monitor on my screen once everything went unresponsive, and it said it was about to max out the RAM, updating every few seconds, then everything froze. Bonus points that I was in the middle of a data disk rebuilding from parity but I guess that's on me. That procedure is reatsrting now luckily with no issues. Didn't expect the FFMPEG process to load the entire file into RAM to complete. Is that normal? I haven't changed any Jellyfin transcode path defaults in unraid, I assumed it was writing to the appdata folder, which on my system is set to always be my SSD cache. Let me know if I'm misunderstanding something.
52 minutes ago
(This post was last modified: 51 minutes ago by TheDreadPirate. Edited 1 time in total.)
(Today, 05:55 AM)BotchedMiracle Wrote: Spoke too soon, now I see a problem. Remove "-max_interleave_delta 0" from the command. That is an optional parameter, not necessary for the DV removal process. What is it does is ensure that the various video/audio/subtitle tracks are evenly distributed in the output file. If the source file is poorly muxed and the various tracks are spread out across the file, ffmpeg will keep loading the file into memory until it encounters each track. https://ffmpeg.org/ffmpeg-formats.html#:...20(output) |
|
|