Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 27th January 2022, 08:20   #21  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 239
Quote:
Originally Posted by jriker1 View Post
Not done encoding yet, however I think ffmpeg is ignoring the high tier setting. At least this is part of the output I copied from the screen:

Press [q] to stop, [?] for help
x265 [info]: HEVC encoder version 3.5+21-8a15ef537
x265 [info]: build info [Windows][GCC 11.2.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main profile, Level-5.1 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices
If you still manually set vbv limits that are bellow Main tier for that level It might do that i guess

Quote:
Originally Posted by benwaggoner View Post
TS? Transport stream?
Topic/thread starter 😀
excellentswordfight is offline   Reply With Quote
Old 28th January 2022, 02:11   #22  |  Link
jriker1
Registered User
 
Join Date: Dec 2003
Posts: 449
OK so conversion done. So changing the keyint=24 made it track real fast audio and video, but when I'm jumping quickly thru the footage still had the issue where when I took my hand off the jump forward button the playback was jumpy. Even stopping the video and playing still did it. Going back 10 seconds or so played thru that area fine then. Ugh. Oh and the footage even though the call was:

ffmpeg.exe -i <input>.mkv -c:v libx265 -x265-params level=51:high-tier=1:repeat-headers=1:colorprim=bt709:transfer=bt709:colormatrix=bt709:crf=13:chromaloc=0:no-sao=1:info=0:range=limited:vbv-maxrate=17500:vbv-bufsize=17500:keyint=24 -vf crop=1920:816:0:2 -preset slower -pix_fmt yuv420p -sn -an <output>.hevc

The footage itself was 1920*816 (2.35:1), at 23.976 (24000/1001) FPS, HEVC (Main@L5.1@Main)

With the DTS Master audio - stutters
With the DTS Core extracted - Fine now with the keyint
Converted to AC3 audio - Fine

Guess I either leave the audio I guess and don't fast forward, switch to DTS Core or get the Emby folks to look into issues with their player and DTS XLL audio. Think the core sounds quieter than the master audio but may be me.

Last edited by jriker1; 28th January 2022 at 03:33.
jriker1 is offline   Reply With Quote
Old 28th January 2022, 16:07   #23  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,106
Sounds likely a player-specific issue. Are you using --no-open-gop?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 28th January 2022, 20:53   #24  |  Link
jriker1
Registered User
 
Join Date: Dec 2003
Posts: 449
Quote:
Originally Posted by benwaggoner View Post
Sounds likely a player-specific issue. Are you using --no-open-gop?
No, but I can do another conversion and try it. Only concern I'm having is do we think based on info so far, that the video is an issue?
jriker1 is offline   Reply With Quote
Old 28th January 2022, 23:09   #25  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 239
Quote:
Originally Posted by jriker1 View Post
OK so conversion done. So changing the keyint=24 made it track real fast audio and video, but when I'm jumping quickly thru the footage still had the issue where when I took my hand off the jump forward button the playback was jumpy. Even stopping the video and playing still did it. Going back 10 seconds or so played thru that area fine then. Ugh. Oh and the footage even though the call was:

ffmpeg.exe -i <input>.mkv -c:v libx265 -x265-params level=51:high-tier=1:repeat-headers=1:colorprim=bt709:transfer=bt709:colormatrix=bt709:crf=13:chromaloc=0:no-sao=1:info=0:range=limited:vbv-maxrate=17500:vbv-bufsize=17500:keyint=24 -vf crop=1920:816:0:2 -preset slower -pix_fmt yuv420p -sn -an <output>.hevc

The footage itself was 1920*816 (2.35:1), at 23.976 (24000/1001) FPS, HEVC (Main@L5.1@Main)

With the DTS Master audio - stutters
With the DTS Core extracted - Fine now with the keyint
Converted to AC3 audio - Fine

Guess I either leave the audio I guess and don't fast forward, switch to DTS Core or get the Emby folks to look into issues with their player and DTS XLL audio. Think the core sounds quieter than the master audio but may be me.
Just courious, why are you using souch low crf with very aggresive vbv limits for that crf range? And using a level that way above that resolution and vbv restrictions?

From the information you har given us it seems to be audio relatated, but i’ve seen x265 to have some vbv issues in the past. What happens if you use:


ffmpeg.exe -i <input>.mkv -c:v libx265 -x265-params level=41:vbv-maxrate=20000:vbv-bufsize=20000:repeat-headers=1:colorprim=bt709:transfer=bt709:colormatrix=bt709:crf=18:chromaloc=0:no-sao=1:info=0:range=limited:keyint=96 -vf crop=1920:816:0:2 -preset slower -pix_fmt yuv420p -sn -an <output>.hevc

If the issue persist that at least should rule out bitrate/vbv/level/tier issues.

Last edited by excellentswordfight; 28th January 2022 at 23:17.
excellentswordfight is offline   Reply With Quote
Old 29th January 2022, 14:39   #26  |  Link
jriker1
Registered User
 
Join Date: Dec 2003
Posts: 449
Quote:
Originally Posted by excellentswordfight View Post
Just courious, why are you using souch low crf with very aggresive vbv limits for that crf range? And using a level that way above that resolution and vbv restrictions?
Is that limited for 1080p? When I used to create my videos thru Premiere Pro and a difference here, was using NeatVideo to get rid of some of the noise, I was using 8,000 for a CBR and 10,000 for shows I liked a lot. I was trying to reproduce CBR with ffmpeg but it's my understanding those settings set thte upper limit to how high a bitrate the encoder can use. This would be a lot higher than what I used to do. I think. And picture seems very clean.
jriker1 is offline   Reply With Quote
Old 29th January 2022, 23:08   #27  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,336
Don't use VBV to try to get CBR, it isn't meant for that and it isn't good at it.

Do you really need to cap the max rate? Pick a higher crf without VBV (or the normal VBV for the level) for better quality at the same size. If you want to always get the same size use 2-pass and target a bitrate. If you want a flatter bitrate distribution for some reason use qComp.

VBV is designed to avoid buffering issues when streaming over a network or off of slow storage. It is not designed to cutoff the bitrate of all the high motion scenes. The rate control works better if you let it fluctuate as it desires, with VBV only stepping in rarely to keep extreme bitrate spikes within the limits of the hardware.
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 1st February 2022, 23:57   #28  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,106
Quote:
Originally Posted by jriker1 View Post
Is that limited for 1080p? When I used to create my videos thru Premiere Pro and a difference here, was using NeatVideo to get rid of some of the noise, I was using 8,000 for a CBR and 10,000 for shows I liked a lot. I was trying to reproduce CBR with ffmpeg but it's my understanding those settings set thte upper limit to how high a bitrate the encoder can use. This would be a lot higher than what I used to do. I think. And picture seems very clean.
Unless you're trying to do real-time streaming over a constrained bitrate, CBR really doesn't make sense. Compared to VBR, at the same file size, CBR will look worse in difficult sections while wasting bits in easier sections.

For stuff that'll be played of a drive, VBR (either 2-pass VBR or using CRF) will be flat-out better most of the time.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 2nd February 2022, 00:01   #29  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,106
Quote:
Originally Posted by Asmodian View Post
Don't use VBV to try to get CBR, it isn't meant for that and it isn't good at it.

Do you really need to cap the max rate? Pick a higher crf without VBV (or the normal VBV for the level) for better quality at the same size. If you want to always get the same size use 2-pass and target a bitrate. If you want a flatter bitrate distribution for some reason use qComp.

VBV is designed to avoid buffering issues when streaming over a network or off of slow storage. It is not designed to cutoff the bitrate of all the high motion scenes. The rate control works better if you let it fluctuate as it desires, with VBV only stepping in rarely to keep extreme bitrate spikes within the limits of the hardware.
VBV is required to meet profile @ level decoder requirements, so it is required for compatibility with lots of hardware decoders.

x265 generally picks a sane default level based on the input, and then constrains VBV appropriately for that, so setting VBV isn't needed in a lot of cases. But we want VBV to be used by the encoder in almost all cases.

Also, if you know you have a better decoder available, setting that and VBV can improve quality. For example, encoding 2160p24 would default to Level 5 and thus a 25 Mbps max VBV. But if targeting a Level 5.1 decoder, max VBV can be raised to 40 Mbps, which can help quality with high complexity or grain.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 2nd February 2022, 13:13   #30  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 239
Quote:
Originally Posted by benwaggoner View Post
VBV is required to meet profile @ level decoder requirements, so it is required for compatibility with lots of hardware decoders.

x265 generally picks a sane default level based on the input, and then constrains VBV appropriately for that, so setting VBV isn't needed in a lot of cases. But we want VBV to be used by the encoder in almost all cases.

Also, if you know you have a better decoder available, setting that and VBV can improve quality. For example, encoding 2160p24 would default to Level 5 and thus a 25 Mbps max VBV. But if targeting a Level 5.1 decoder, max VBV can be raised to 40 Mbps, which can help quality with high complexity or grain.
I mentioned this to you before, x265 does not behave like that by default. if level and vbv is unspecified x265 does not use vbv, its only when level is manually set it will use vbv and when level is set it will prioritize high tier if tier is unspecified.

It's also in the docs
Quote:
--level-idc
...
Beware, specifying a decoder level will force the encoder to enable VBV
Quote:
--vbv-bufsize
...
Default 0 (vbv disabled)

Last edited by excellentswordfight; 2nd February 2022 at 15:41.
excellentswordfight is offline   Reply With Quote
Old 2nd February 2022, 18:05   #31  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,106
Quote:
Originally Posted by excellentswordfight View Post
I mentioned this to you before, x265 does not behave like that by default. if level and vbv is unspecified x265 does not use vbv, its only when level is manually set it will use vbv and when level is set it will prioritize high tier if tier is unspecified.
Right. I keep forgetting because I never, ever do an encode without setting --level-idc. I like to know where I can trust it to decode reliably to reduce risk of encoder and decoder issues getting conflated.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Reply

Tags
ffmpeg, h.265

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 23:11.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.