Jellyfin Forum
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-11-08

Our chat over in troubleshooting got me to come back here and update my process.  Now that jf-ffmpeg7 has Dolby Vision removal bundled, it turned a multi-step workflow into a "one liner".  This also removed a bunch of steps I needed to take to keep video, audio, and subtitles in sync.

I had some additional discussions with Nyanmisaka about how to handle video with a lot of film grain, which caused significantly reduced quality due to the randomness.  I had considered your de-noise approach, but ended up choosing to preserve the film grain.   So I explored some additional parameters Nyanmisaka had suggested to try to better use the available bit rate.

Code:
        ffmpeg \               
                -y \
                -init_hw_device vaapi=va:,driver=iHD,kernel_driver=i915 \
                -hide_banner \
                -stats \
                -fflags +genpts+igndts \
                -loglevel error \
                -init_hw_device qsv=qs@va \
                -filter_hw_device qs \
                -hwaccel qsv \ 
                -hwaccel_output_format qsv \
                -extra_hw_frames 40 \
                -i "$INPUTFILE" \
                $chapterSelect \       # only used when splitting one file into many, usually TV shows
                -map_chapters 0 \
                -map 0:v \
                -c:v av1_qsv \ 
                -pix_fmt yuv420p10le \
                -q:v 22 \
                -look_ahead_depth 40 \
                -preset veryslow \
                -vf vpp_qsv="$FILTERS" \
                $audioCommand \   # dynamically selected English and Japanese tracks (anime only), converts to OPUS w/VBR.  If lossless tracks present, ignore lossy tracks.
                $subCommand \      # dynamically selected English and Japanese tracks (anime only), copies unmodified.
                -map 0:t? \
                -disposition:s 0 \
                -low_delay_brc 1 \
                -extbrc 1 \
                -adaptive_i 1 \
                -adaptive_b 1 \
                -b_strategy 1 \
                -bf 39 \
                -max_muxing_queue_size 2048 \
                -max_interleave_delta 0 \
                -avoid_negative_ts disabled \
                "$outputFile"

Specifically

Code:
### decode side
                -extra_hw_frames 40 \  # new to me.  the same as -filter:v:0 "hwupload=extra_hw_frames=64 in your command???
### encode side
                -look_ahead_depth 40 \
                -low_delay_brc 1 \
                -extbrc 1 \ 
                -adaptive_i 1 \   # new
                -adaptive_b 1 \  #new
                -b_strategy 1 \  #new
                -bf 39 \  #new

The last four made a huge difference, both in terms of quality and just general bit rate.

Here is a file size comparison with and without just those last four lines.  Everything else is the same.

Code:
-rw-rw-r--  1 chris jellyfin  4751175286 Nov  8 15:00 Jinroh-adaptiveFrames.mkv
-rw-rw-r--  1 chris jellyfin 13693462719 Nov  8 15:16 Jinroh-noAdaptiveFrames.mkv
-rw-rw-r--  1 chris jellyfin 27340883707 Oct  2 20:19 Jinroh-original.mkv

My git has my full automation script. Still a WIP. I think I've got it to where it will handle just about any edge case. At least edge cases I've encountered. Now comes clean up, finding efficiencies, and making it pretty.

https://github.com/solidsnake1298/Arc-Encoding-Automator

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

Back to an old discussion @TheDreadPirate and I had regarding auto-cropping (if you trust cropdetect at all). I snagged some awk from somewhere and another person offered an expansion that sorts all results from a sample size of your choice and selects the one which occurs most often in cropdetect output. Pretty cool, actually!

Code:
REMOVED

In my experience, past black screens and REALLY dark scenes, this is a thoroughly accurate way to crop out black bars. Then you would use this variable in your filter:

Code:
REMOVED

Make sure to crop prior to other hardware-based filters (e.g., vpp_qsv) or you'll need to use hwdownload and figure out formats. Easier just to crop from the start.

Okay, so using the crop filter with ANY hw-based filters doesn't seem to work at all. However, you can utilize vpp_qsv to the same effect with a tiny bit of extra work (which I've already done):

Code:
cropval=$(jffmpeg -ss 120 -i "${i}" -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) && \

And then your vpp_qsv filter would look like this:

Code:
-filter:v "hwupload=extra_hw_frames=64,vpp_qsv=cw=$cw:ch=$ch:cx=$cx:cy=$cy:denoise=6"

Of course with hwupload and denoise optional, just copy/pasted from my script. If scaling, you have to use a separate filter (e.g., scale_qsv) as it doesn't seem to respect scale_mode, w, and h parameters when using crop functions.

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

I missed that you had some new posts since my last one. I'm still semi-automated since I'm altering based on what type of media as well as age. The easier media are seasons or shows where you expect a level of consistency.

Code:
                -adaptive_i 1 \  # new
                -adaptive_b 1 \  #new
                -b_strategy 1 \  #new
                -bf 39 \  #new

I don't know what these do so I haven't played with them. I also don't see the -bf parameter in the av1_qsv encoder help. I guess -bf is to set the number of b-frames? I don't really understand what that means.

Quote:-extra_hw_frames 40 \  # new to me.  the same as -filter:v:0 "hwupload=extra_hw_frames=64 in your command???

I don't think so. On the decode side (i.e., option comes before before the file), this would throw extra frames on the device on the front-end. What the advantage is I'm not sure. Possibly faster decoding? The video filter portion (i.e., option after the input file) is for encoding. Based on what you have there, I wonder if look_ahead_depth should match the number of extra frames uploaded to the hw device in my own code...

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

Yes, the documentation stated that the decode extra_hw_frames needs to match the encode look_ahead_depth. 40 frames was the recommendation as a balance between quality and bit rate. I haven't tried mismatching them to see what happens.

I also have not had any luck with hardware crop detection. The problem that I currently have is when the arbitrary time stamp I put in my script. Sometimes picking up the all of the studio credits, etc., throwing off the crop detect. But your version seems more flexible and I will definitely borrow that.

-bf is for b-frames. Default is 0, disabled, -1 is auto, positive values sets the max number of frames in between b-frames. Looking at the documentation, I've been using an invalid number. Or is no longer a valid number. Valid positive values are 1 thru 16.

Quote:adaptive_i
This flag controls insertion of I frames by the QSV encoder. Turn ON this flag to allow changing of frame type from P and B to I.
Quote:adaptive_b
This flag controls changing of frame type from B to P.
Quote:b_strategy
This option controls usage of B frames as reference.

These options, when combined with extbrc and low_delay_brc allows ffmpeg to maximize bit rate, which frame type to use and when, etc. Essentially all of them together allows ffmpeg to make better use of the available bit rate as defined by -q:v in my case.

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

Actually "-bf 39" is a valid value. The forum post I read stated it has to be lower than the look_ahead_depth and recommended a bf value of 39. It was also the thread that recommended extra_hw_frames and look_ahead_depth be 40. I set it to 16, based on what the ffmpeg documentation said was the highest valid value, and the file size difference is pretty significant.

Code:
-rw-rw-r--  1 chris chris    24054028429 Dec  3 12:41 'The Lord of the Rings - The Return of the King (2003)-bf16.mkv'
-rw-rw-r--  1 chris chris    20396465931 Dec  3 13:59 'The Lord of the Rings - The Return of the King (2003)-bf39.mkv'
-rw-r--r--  1 chris chris    52982399272 Dec  2 17:25 'The Lord of the Rings - The Return of the King (2003).mkv'

When I get home, I will see if there is a perceivable difference in quality. I'm not sure why a higher bf would result in a lower bit rate. The description implies that a lower number reduces the number of frames between b-frames. B-frames are supposed to be more efficient.

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

So I'm not getting the same results that you are. I need some other things to test on and benchmark since animated content is most of what I've done since throwing these in there. I will test with/without tomorrow if I can to check size differences and visual quality. First ep I did tonight looked stellar in 1080p at 342 MB. Normally I would expect an episode to be 400-500+ MB depending on a few factors, so this may be a size reduction but I won't be sure until I play around.

As for b-frames -- my understanding of them is the same. A lower value for -bf reduces the number of frames between subsequent b-frames (i.e., the b-frame interval). However, when reading up on this, I think the documentation might be completely off -- which never happens with ffmpeg. I think the higher values for -bf are the number of b-frames allowed before a subsequent I- or P-frame. Here's a blog that seems to describe this phenomenon, although this doesn't discuss AV1 encoding with b-frames and I have no idea where he got the measurements/visualizations for P, B, and I frames...

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

Interesting. That description of -bf makes a lot more sense than the ffmpeg documentation based on my results. BTW, I did not notice a difference between the two versions, but I also don't have a 4K monitor/TV to properly pixel peep.

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

Another b-frame related tid bit I just found regarding the -b_strategy parameter.

Quote:0 - Always use the maximum number of B-frames (default).
1 - Avoid B-frames in high motion scenes. See the b_sensitivity option to tune this strategy.
2 - Places B-frames more or less optimally to yield maximum quality (slower). You may want to reduce the speed impact of this option by tuning the option brd_scale.

The Internet is doomed if Doom9 ever ceases to exist. All these years later, I am still learning from that forum.

https://forum.doom9.org/archive/index.php/t-146689.html

FYI, b_sensitity is deprecated.

https://www.ffmpeg.org/doxygen/3.0/structAVCodecContext.html#a4730fd97a8d71d9ca712c1df1c646f1e:~:text=AVCodecContext%3A%3Ab_sensitivity

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

Okay, tested with one of my favorite media and, using the settings discussed, I halved the size of my previous encode, which is a very significant reduction (4.1 GB --> 1.9 GB). At first glance and spot checking, everything looks pretty good. I'm guessing this is highly dependent upon the media -- animation it doesn't seem to do much, although my test cases haven't been particularly grainy.

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

Holy cow, I tried this with a stubborn piece of media from the 80's and the results were....entirely unexpected. No real change in file size, but awesome artifacts and color shifts (R+G removed?).

   

Any thoughts on what might cause this? Using vpp_qsv to crop and light denoise, scale_qsv to take from bloated 1080p down to 720p for more manageable size.