Encoding Discussion Megathread (ffmpeg, Handbrake, AV1, etc...)

[bitmap]

I have an issue with my ffmpeg command.
When using preset 5, I am unable to seek through the movie in jellyfin. It only shows 5 seconds in length, which extends while playing.

But when using preset 6 or higher, the movie plays perfectly fine.
Here is the command:

Code:

ffmpeg -i in.mkv -map 0 -c:s copy -c:v libsvtav1 -pix_fmt yuv420p10le -svtav1-params tune=0:irefresh-type=2:enable-overlays=1:scd=1 -g 240 -movflags +faststart -preset 5  -ac 6 -c:a libopus -b:a 256k -crf 30 out.mkv

I tried both jellyfin-ffmpeg and the latest build from github.
Does anyone have suggestions? I would be very thankful.

Okay, so a few things (and I do the same thing since I don't trust a lot of software to do what it says).

• irefresh-type=2 is unnecessary as that's the default
  
• there's no reason to turn on enable overlays if you're not inserting images as an overlay on top of the video
  
• my guess is that this has to do with your keyframe setting, which looks like it's set at ~10 seconds for standard film frame rate (~24 FPS)
  

Now in my experience, libsvtav1 actually does a pretty good job at figuring out where to put keyframes and you don't really get any compression advantage by moving them further apart. So I might honestly try without the manual keyframe setting and re-encode. It may be that more keyframes are helpful with a larger amount of data between the two -- I know my encodes at 5 and 4 were a few hundred MB difference in size at 1080p and 1+ GB difference in size at 4K depending on bitrate/CRF. Revised?

Code:

ffmpeg -i in.mkv -map 0 -c:v libsvtav1 -preset 5 -crf 30 -pix_fmt yuv420p10le -svtav1-params tune=0:scd=1 -movflags +faststart -c:a libopus -ac 6 -b:a 256k -c:s copy out.mkv

I moved things around because uh...I'm a little OCD about grouping like with like as far as flags go...makes for easier debugging.

[TheDreadPirate]

I had an epiphany yesterday. While my PC and TVs are not HDR compliant, my Pixel 6a is HDR capable up to 800nits. But DV 7.6 is not mobile/streaming dongle friendly. So definitely going to be re-doubling my efforts to convert most of my HDR content, almost all is DV 7.6, to DV 8.1 or HDR10.

I will report back with any progress I make.

[manu98]

I have an issue with my ffmpeg command.
When using preset 5, I am unable to seek through the movie in jellyfin. It only shows 5 seconds in length, which extends while playing.

But when using preset 6 or higher, the movie plays perfectly fine.
Here is the command:

Code:

ffmpeg -i in.mkv -map 0 -c:s copy -c:v libsvtav1 -pix_fmt yuv420p10le -svtav1-params tune=0:irefresh-type=2:enable-overlays=1:scd=1 -g 240 -movflags +faststart -preset 5  -ac 6 -c:a libopus -b:a 256k -crf 30 out.mkv

I tried both jellyfin-ffmpeg and the latest build from github.
Does anyone have suggestions? I would be very thankful.

Okay, so a few things (and I do the same thing since I don't trust a lot of software to do what it says).

• irefresh-type=2 is unnecessary as that's the default
  
• there's no reason to turn on enable overlays if you're not inserting images as an overlay on top of the video
  
• my guess is that this has to do with your keyframe setting, which looks like it's set at ~10 seconds for standard film frame rate (~24 FPS)
  

Now in my experience, libsvtav1 actually does a pretty good job at figuring out where to put keyframes and you don't really get any compression advantage by moving them further apart. So I might honestly try without the manual keyframe setting and re-encode. It may be that more keyframes are helpful with a larger amount of data between the two -- I know my encodes at 5 and 4 were a few hundred MB difference in size at 1080p and 1+ GB difference in size at 4K depending on bitrate/CRF. Revised?

Code:

ffmpeg -i in.mkv -map 0 -c:v libsvtav1 -preset 5 -crf 30 -pix_fmt yuv420p10le -svtav1-params tune=0:scd=1 -movflags +faststart -c:a libopus -ac 6 -b:a 256k -c:s copy out.mkv

I moved things around because uh...I'm a little OCD about grouping like with like as far as flags go...makes for easier debugging.

Thanks for your answer. Unfortunately, removing the keyframe option does not help.
I did not use it originally, but it was one of many things I tried out.

Do you have any other suggestions?

[bitmap]

So my epiphany on the mapping and codec choice front -- I always tried to avoid "multiple codec spec" message -- is that if your media is simple enough, negative mapping is the way to go and you should always choose -c copy flag right off the bat. Here's why: if you have a media file that contains ASS subs, several TTF attachments, jpeg/mjpeg video stream attachments, those don't necessarily show in a mediainfo or regular ffprobe that you might use to investigate how you'd be batch encoding similar/same media (e.g. remuxed/ripped Blurays).

If you do a -map 0 or -map 0:v, you'll grab those mjpegs and a -c:v hevc_qsv will try to convert them, which is NOT what you want. Furthermore, if you only map your subs and not your attachments, you lose styling pretty much entirely. Plus, occasionally attachments are problematic. So with a simple file, say it has three audio tracks, four subtitle tracks. You don't know about images or attachments -- you could dig in and figure it out, but why bother? Figure out which of the tracks you DON'T want and use the stream indices -- I prefer stream-specific indices, like the following:

Code:

ffmpeg -i in.mkv -map 0 -map -0:a:2 -map -0:s:2 -map -0:s:3 -c copy -c:v:0 hevc_qsv -preset slow -crf 20 -c:a:1 libopus -b:a:1 128k -ac:a:1 2 -filter:a:1 "<filtergraph>" out.mkv

In this way, you map EVERYTHING, set it all to be copied, and override individual preferences. So in this case, maybe I'm copying the lossless DTS-MA, turning the DD+ into a low-quality stereo track, and converting just the main video track into HEVC while leaving any other possible video tracks (i.e., m/jpeg video images) alone. You can strip these out with explicit maps, but it's easier to leave them alone and it doesn't hurt anything to copy them over unless you're trying to REALLY slim down your files. Note, very importantly, that I'm using a stream specifier on my c:v flag, so it becomes c:v:0 to avoid causing ffmpeg to try and convert any possible m/jpeg streams to convert using whatever codec I've specified, which will cause the process to error out. There might be more eloquent ways to avoid this, but there's no training here...just figuring it the f**k out.

This method also ensures you keep all attachments (TTF files for ASS styling) and should keep HDR/DV metadata. I'm not sure that it keeps side data, however. You can dump that to a file with a flag, but I couldn't figure out how to keep that with the file. I have, however, re-encoded a LOT of DV content to AV1 with this method that now parses as DV, even though AV1 does not support DV.

More complex media definitely require explicit mapping, but -c copy is still something I can't recommend enough. Even if you're re-encoding just about everything. Use -map 0:v to grab all possible jpeg streams or -map 0:v:0 to only grab the main video stream, if you have to map streams explicitly (e.g., there are 40+ streams present and you only want...four), you can still use some tricks.

Language mapping (all media streams that match specified language):

Code:

-map 0:m:language:eng

Optional mapping (example -- map all attachments that might exist, won't cause errors if no attachments, just skips):

Code:

-map 0:t?

Make sure you still use -c copy right after your maps as a standard practice, even if you're converting all known streams. You're likely catching streams you don't know about...or you might want to catch streams that you don't know about.

[bitmap]

Thanks for your answer. Unfortunately, removing the keyframe option does not help.
I did not use it originally, but it was one of many things I tried out.

Do you have any other suggestions?

Have you tried without scene change detection? There were a few things I tried when I was first experimenting with SVT-AV1 that sound really cool that jacked up my files. Super resolution was one of them, overlays was another suggested as something that could reduce filesize and increase clarity but in the end does nothing. I recall turning on scene change detection as well and turning it off after having issues, but I don't recall if it was because of performance issues or due to the same kind of seek problems that you're having. My understanding is that SCD tries to find the best spot to throw in keyframes, but I'm not sure what goes on behind the scenes and what actually changes. So...I have two suggestions to try. First would be try turning off SCD and see what happens. Second would be to go back to where your original command was (-ish) and try preset 4:

Code:

ffmpeg -i in.mkv -map 0 -c:v libsvtav1 -preset 4 -crf 30 -pix_fmt yuv420p10le -svtav1-params tune=0:scd=1 -movflags +faststart -c:a libopus -ac 6 -b:a 256k -c:s copy out.mkv

You could even add back in your keyframe call if you want (-g 240).

The reason I feel this is a valid suggestion is because I don't think most people are sure what the difference between the presets is. There isn't great (or any, that I've found) documentation on what preset "5" vs. "4" actually means when using SVT-AV1...we all assume it's "quality" and "encoding time" which, in general, is true, but why? What settings are changed when going from 6 > 5 > 4? I've settled pretty well into preset 4 when I'm not running things through my A380 since the time savings aren't that significant and the quality difference -- I've found -- can be quite striking, particularly when looking at 4K HDR, but even at 1080p. Any lower, it's probably not worth the extra clock cycles.

[manu98]

Thanks for your answer. Unfortunately, removing the keyframe option does not help.
I did not use it originally, but it was one of many things I tried out.

Do you have any other suggestions?

Have you tried without scene change detection? There were a few things I tried when I was first experimenting with SVT-AV1 that sound really cool that jacked up my files. Super resolution was one of them, overlays was another suggested as something that could reduce filesize and increase clarity but in the end does nothing. I recall turning on scene change detection as well and turning it off after having issues, but I don't recall if it was because of performance issues or due to the same kind of seek problems that you're having. My understanding is that SCD tries to find the best spot to throw in keyframes, but I'm not sure what goes on behind the scenes and what actually changes. So...I have two suggestions to try. First would be try turning off SCD and see what happens. Second would be to go back to where your original command was (-ish) and try preset 4:

Code:

ffmpeg -i in.mkv -map 0 -c:v libsvtav1 -preset 4 -crf 30 -pix_fmt yuv420p10le -svtav1-params tune=0:scd=1 -movflags +faststart -c:a libopus -ac 6 -b:a 256k -c:s copy out.mkv

You could even add back in your keyframe call if you want (-g 240).

The reason I feel this is a valid suggestion is because I don't think most people are sure what the difference between the presets is. There isn't great (or any, that I've found) documentation on what preset "5" vs. "4" actually means when using SVT-AV1...we all assume it's "quality" and "encoding time" which, in general, is true, but why? What settings are changed when going from 6 > 5 > 4? I've settled pretty well into preset 4 when I'm not running things through my A380 since the time savings aren't that significant and the quality difference -- I've found -- can be quite striking, particularly when looking at 4K HDR, but even at 1080p. Any lower, it's probably not worth the extra clock cycles.

Thanks for your feedback. Using preset 4 results in the same behaviour, unfortunately.

Things are getting really strange now. I limited the length of the new video file, so I could test more options.
But when limiting the video time, it suddenly works!

Working:

Code:

ffmpeg -i in.mkv -to 0:2:0 -map 0 -c:v libsvtav1 -preset 5 -crf 30 -pix_fmt yuv420p10le -svtav1-params tune=0:scd=1 -movflags +faststart -c:a libopus -ac 6 -b:a 256k -c:s copy out.mkv

Not working:

Code:

ffmpeg -i in.mkv -map 0 -c:v libsvtav1 -preset 5 -crf 30 -pix_fmt yuv420p10le -svtav1-params tune=0:scd=1 -movflags +faststart -c:a libopus -ac 6 -b:a 256k -c:s copy out.mkv

I could send you both samples via DM, if you want to have a closer look?

[Nickatron]

I'm not sure if this is the right thread, but it is somewhat transcoding related. I have HEVC transcoding set up and working on my server, and I can get playback of it fine on my PC, but not on android. Is there any way to set the android app to prefer h.265 over h.264 like we can on the PC app?

[TheDreadPirate]

What codec is the media encoded with? Is the android device direct playing instead of transcoding?

[Nickatron]

What codec is the media encoded with?  Is the android device direct playing instead of transcoding?

I can get it to do both. Direct play works fine (all codecs obviously), encode with h.264 works fine, but h.265 does not. H.265 transcoding works fine on the desktop app, so I know it is working server side. I did do some more research today, and it seems like it is a bug with the android app. https://jellyfin.org/docs/general/clients/codec-support

I'll mess with Kodi and see if I can get it working through their app, as that is listed among the clients. But if you know of any other android clients that are recommended, I would love to know. Thank you!

[TheDreadPirate]

The codec used for a transcode is determined by the client, IIRC. I know Rokus ask for H265. My Android based clients have always asked for H264 regardless if they support H265 (transcoding for burning in unsupported subtitles on Android TV but codec is otherwise supported).