Encoding Discussion Megathread (ffmpeg, Handbrake, AV1, etc...) - Printable Version

Encoding Discussion Megathread (ffmpeg, Handbrake, AV1, etc...) - Printable Version

+- Jellyfin Forum (https://forum.jellyfin.org)
+-- Forum: Off Topic (https://forum.jellyfin.org/f-off-topic)
+--- Forum: General Discussion (https://forum.jellyfin.org/f-general-discussion)
+--- Thread: Encoding Discussion Megathread (ffmpeg, Handbrake, AV1, etc...) (/t-encoding-discussion-megathread-ffmpeg-handbrake-av1-etc)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12

RE: Encoding Discussion Megathread (ffmpeg, Handbrake, AV1, etc...) - TheDreadPirate - 2024-12-04

What is the full ffmpeg command you used?

And can you run this command and share the output?

Code:
ffprobe -loglevel error -i "video.mkv" -select_streams v -show_entries stream -v quiet -of json

RE: Encoding Discussion Megathread (ffmpeg, Handbrake, AV1, etc...) - TheDreadPirate - 2024-12-04

Circling back to the cropdetect. Two things

1) I got accelerated decoding working with crop detect.
2) I've recently re-encountered an edge case that I've encountered a few times in the past.

The accelerated command looks like this. It doesn't make crop detection happen any faster, in fact it slows things down by about 50%, but it massively lowers the CPU usage.

Code:
ffmpeg -init_hw_device vaapi=va:,driver=iHD,kernel_driver=i915 -init_hw_device qsv=qs@va -filter_hw_device qs -hwaccel qsv -hwaccel_output_format qsv -ss 120 -t 5:00 -i Bookworm.mkv -vf hwdownload,format=p010le,fps=1/2,cropdetect=mode=black:reset=60 -f null - 2>&1

It's probably the hwdownload slowing things down. But, as you mentioned, I couldn't find a QSV filter to do everything in hardware.

You will have to do some detection first with ffprobe. The pixel format filter needs to match the video. "p010le" for 10-bit video and "nv12" for 8-bit video are the two that QSV supports.

Regarding #2. If, at the start of the cropdetect at the -ss timestamp, your video has a different aspect ratio, either for stylistic effect or because it is a small logo on an all black background, the cropdetect will get it wrong if the windows isn't large enough. Your -t 5:00 helped me with that. I had been using "-ss 120 -to 180". MOST videos will have go back to 16:9 or 21:9 by the end of that 5 minute window.

But I have a new movie where there is an extended intro/prelude with a different resolution and aspect ratio than the rest of the movie that lasts the entirety of the 5 minute cropdetect window. Extending how long crop detect goes on for seems like a waste.

I'm debating how to handle this edge case. Two crop detects at different time stamps? Pick the one with the larger canvas? Each crop detect at a dynamic start time depending on the length of the video?

RE: Encoding Discussion Megathread (ffmpeg, Handbrake, AV1, etc...) - bitmap - 2024-12-05

I would skip further in. I've been using -ss 300 (five minutes into the media) to avoid detecting any intros. It's arbitrary, but you're less likely to get anything odd in this way. The example I found had cropdetect running for 10 minutes, likely to avoid situations like the edge case you describe. I would pick a length for -ss that is going to fit MOST cases. Considering skipping five or seven minutes into the media is unlikely to result in those odd aspect ratio or long intro problems and it's still short enough that you're not likely to hit something midway through. Even if you do, that's why uniq sorts and picks the most frequent value. Dunno if you've ever run cropdetect with full terminal output, but it's....verbose.

(2024-12-04, 06:05 PM)TheDreadPirate Wrote: What is the full ffmpeg command you used?

And can you run this command and share the output?

Code:
ffprobe -loglevel error -i "video.mkv" -select_streams v -show_entries stream -v quiet -of json

My go to is libsvtav1 if I have issues with HWA encoding. I ran this media through that and was happy with the results as far as size and quality. I've just not seen this sort of artifacting before...

RE: Encoding Discussion Megathread (ffmpeg, Handbrake, AV1, etc...) - bitmap - 2024-12-06

Here's the full command I used for that messed up encode:

Code:
MEDIA="Media" && INPUT="Media.mkv" && \

cd "/mnt/media/Media" && \

mkdir -p "/mnt/media/${MEDIA}" && \

echo "Calculating crop values..." && \

cropval=$(jffmpeg -ss 300 -i "${INPUT}" -t 5:00 -filter:v fps=1/2,cropdetect -f null - 2>&1 | awk '/crop/ { print $NF }' | tr ' ' '\n' | sort | uniq -c | sort -n | tail -1 | awk '{ print $NF }') && \

cw=$(echo "${cropval#*crop=}" | cut -d : -f 1) && ch=$(echo "${cropval#*crop=}" | cut -d : -f 2) && \

cx=$(echo "${cropval#*crop=}" | cut -d : -f 3) && cy=$(echo "${cropval#*crop=}" | cut -d : -f 4) && \

jffmpeg -init_hw_device qsv=qs:/dev/dri/renderD129 -hwaccel qsv -hwaccel_output_format qsv -qsv_device /dev/dri/renderD129 -filter_hw_device qs \

  -analyzeduration 200M -probesize 1G -extra_hw_frames 40 -i "${INPUT}" \

  -map 0:v:0 -map 0:a:0 -map 0:s:0 \

  -c copy -c:v:0 "av1_qsv" -preset "veryslow" -low_delay_brc 1 -extbrc 1 -look_ahead_depth 40 \

  -adaptive_i 1 -adaptive_b 1 -b_strategy 1 -bf 39 \

  -global_quality:v:0 22 \

  -filter:v "hwupload=extra_hw_frames=40,vpp_qsv=cw=${cw}:ch=${ch}:cx=${cx}:cy=${cy}:denoise=8:format=p010le,scale_qsv=mode=2:h=720:w=-1" \

  -filter:s "hwupload=extra_hw_frames=40,vpp_qsv=scale_mode=2:w=1920:h=-1" \

  -c:a libopus -b:a 192k -ac 2 \

  -metadata title="${MEDIA}" \

  -metadata:s:a:0 title='Stereo' -metadata:s:a:0 language='eng' -disposition:a:0 default \

  -metadata:s:s:0 title='English' -metadata:s:s:0 language='eng' -disposition:s:0 0 \

  "/mnt/media/${MEDIA}/${MEDIA} [Bluray-720p AV1 10bit OPUS 2.0][JA][EN].mkv"

It's a piece of media I struggled with to get a reasonable size or much of a reduction at all with av1_qsv, so I was trying to reduce it to 720p and keep bitrate high. The result is what you see above. Reproducible through multiple encodes.