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 6th November 2019, 06:22   #7161  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by Magik Mark View Post
What value shall I use?
This depends. maxrate sets a specific maximum bitrate ceiling while buffer size sets a buffer, which usually should be higher than maxrate
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 6th November 2019, 18:34   #7162  |  Link
Majorlag
Registered User
 
Join Date: Jul 2016
Posts: 19
Quote:
Originally Posted by Magik Mark View Post
What value shall I use?
For the values, you can use anything you want, but I would recommend using values to meet a certain Tier and Level so you can get Hardware accelerated decoding. You can see those at https://en.wikipedia.org/wiki/High_E...y_Video_Coding, under Tiers and levels section.

I usually set bufsize and maxrate as the same. I cannot find anywhere that shows how high bufsize can be set to to maintain DXVA hardware decoding, so I use the following for all my encodes for x265.

480p:--vbv-bufsize 12000 --vbv-maxrate 12000
1080p:--vbv-bufsize 20000 --vbv-maxrate 20000
2160p:--vbv-bufsize 25000 --vbv-maxrate 25000

These have all resulted in DXVA compatible files.
Majorlag is offline   Reply With Quote
Old 7th November 2019, 04:34   #7163  |  Link
aymanalz
Registered User
 
Join Date: May 2015
Posts: 68
Quote:
Originally Posted by froggy1 View Post
With my settings above and HME turned on, I can shave ~100 MiB of an encode. Encoded Blade Runner once with and once without HME. The result was 100 MiB in size reduction with better subjective quality when HME is on
What was the total filesize, from which you shaved off 100 Mb? I mean, what was the percentage reduction in bitrate? Also, what was the video resolution?

I'm trying to figure out if HME is worthwhile for me, given that the encoding is significantly slower.
aymanalz is offline   Reply With Quote
Old 7th November 2019, 11:39   #7164  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 240
Quote:
Originally Posted by Majorlag View Post
For the values, you can use anything you want, but I would recommend using values to meet a certain Tier and Level so you can get Hardware accelerated decoding. You can see those at https://en.wikipedia.org/wiki/High_E...y_Video_Coding, under Tiers and levels section.

I usually set bufsize and maxrate as the same. I cannot find anywhere that shows how high bufsize can be set to to maintain DXVA hardware decoding, so I use the following for all my encodes for x265.

480p:--vbv-bufsize 12000 --vbv-maxrate 12000
1080p:--vbv-bufsize 20000 --vbv-maxrate 20000
2160p:--vbv-bufsize 25000 --vbv-maxrate 25000

These have all resulted in DXVA compatible files.
encoding 2160p with 25000??? Level 5.1 @ High10 allows 160000 for vbv
__________________
AMD Ryzen 9 5950X, 32GB DDR4-3200 CL16, RTX 3060, 2TB NVMe PCIE4.0, NAS with 8x16TB HDD
jlpsvk is offline   Reply With Quote
Old 7th November 2019, 13:18   #7165  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 322
Quote:
Originally Posted by jlpsvk View Post
encoding 2160p with 25000??? Level 5.1 @ High10 allows 160000 for vbv
And main teir is 40000.

If the only concern is level compatibility then I usually just set --level in the command line and x265 will automatically set the vbv and limit max ref frames etc to be compliant. But afaik some decoders will not handle such big bufsize even though they specification says that it supports a specific level, so there is viability to set custom (lower) values to ensure playback on an targeted device. But all my hevc level 5.1 devices have had no playback issues with encodes using the values in high teir though.

Last edited by excellentswordfight; 7th November 2019 at 13:40.
excellentswordfight is offline   Reply With Quote
Old 7th November 2019, 18:13   #7166  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by aymanalz View Post
What was the total filesize, from which you shaved off 100 Mb? I mean, what was the percentage reduction in bitrate? Also, what was the video resolution?

I'm trying to figure out if HME is worthwhile for me, given that the encoding is significantly slower.
Resolution was 1080p and file size with HME on was 3.7 GiB while with HME off was a bit over 3.8 GiB. Slowdown, IIRC, was about 5-6%

In the end, I recommend doing your own tests and see if it's worthy
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 7th November 2019, 23:29   #7167  |  Link
Majorlag
Registered User
 
Join Date: Jul 2016
Posts: 19
Quote:
Originally Posted by jlpsvk View Post
encoding 2160p with 25000??? Level 5.1 @ High10 allows 160000 for vbv
I guess I could expand my reasoning as for why I would use those settings, since I do only encodes of 29.97fps video, then according to the graph I only need level 5.0, (4,096x2,160@30.0). I could set 5.1 spec, which allows up to 60fps, I don't encode 60fps, but I always use 10bit. I also use the 4k Ultra Blu-ray specifications at http://www.blu-raydisc.com/assets/Do...per_150724.pdf which says Main10 (which I understand to be Main10bit) or High (which I understand to be High8bit) or 5.1 Level max settings.

So I try to make sure I am as compatible with all my encodes as I can possible be. I hope I read the specs correctly.

Last edited by Majorlag; 7th November 2019 at 23:31.
Majorlag is offline   Reply With Quote
Old 8th November 2019, 04:13   #7168  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by excellentswordfight View Post
And main teir is 40000.

If the only concern is level compatibility then I usually just set --level in the command line and x265 will automatically set the vbv and limit max ref frames etc to be compliant. But afaik some decoders will not handle such big bufsize even though they specification says that it supports a specific level, so there is viability to set custom (lower) values to ensure playback on an targeted device. But all my hevc level 5.1 devices have had no playback issues with encodes using the values in high teir though.
Lots of real-world devices support > main tier but not all of high tier. UHD Blu-ray supports 80 Mbps Level 5.1, for example. For typical long-GOP distribution encoding, the Main Tier limits are fine for transparent quality with most sources.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 8th November 2019, 12:14   #7169  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 322
Quote:
Originally Posted by benwaggoner View Post
Lots of real-world devices support > main tier but not all of high tier. UHD Blu-ray supports 80 Mbps Level 5.1, for example. For typical long-GOP distribution encoding, the Main Tier limits are fine for transparent quality with most sources.
Table 2-3–Specification of BD-ROM Primary video streams: Primary VideoCodec: HEVC (Main 10, High Tier,Level 5.1) Max. bitrate 100Mbps

http://www.blu-raydisc.com/assets/Do...per_150724.pdf

The different disctypes will then have different maximum ts bitrates though, I guess that the discs that allow for 81.7 Mbps are the most common.

But when it comes to bufsize, is it common that that devices has a smaller buffer then the allowed maxrate for the supported level? If I remember it correctly HD blurays specified a smaller one (30 vs 40Mbps), and the same was true for PS3 and xbox360 compliant encodings.

If I read the whitepaper correctly, it looks like this is the bufsize specificaiton for UHD-Bluray for the HEVC stream:

"DPB1 Decoded picture buffer for HEVC stream: 93312000 [bytes]"

Last edited by excellentswordfight; 8th November 2019 at 13:52.
excellentswordfight is offline   Reply With Quote
Old 8th November 2019, 23:48   #7170  |  Link
cap5lock
Registered User
 
Join Date: Sep 2017
Posts: 10
Other than using external film grain filter,
Is there any x265 parameters to ignore bluray film grain/noise to further reduce size ?
cap5lock is offline   Reply With Quote
Old 9th November 2019, 04:01   #7171  |  Link
RanmaCanada
Registered User
 
Join Date: May 2009
Posts: 328
Quote:
Originally Posted by cap5lock View Post
Other than using external film grain filter,
Is there any x265 parameters to ignore bluray film grain/noise to further reduce size ?
Anything with high grain should only be encoded in x264 (or just remuxed) as x265 still can not handle it anywhere near as well. I believe the last time someone tested it, they were doing the original Alien, and the re-encode came out larger than the source.

Unless it's magically gotten better since then.
RanmaCanada is offline   Reply With Quote
Old 9th November 2019, 05:04   #7172  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
Depends on the intended use case. If you're going for total transparency you might have a harder time. If you're trying to get down to 10-15 Mbps for 1080p you'll probably get good results with the grain tuning and some nice slow settings, but it might be hard to get a reduction if you're coming from a BluRay source.

Getting down to a lower bitrate without blowing up and maintaining some of the grain texture is usually possible, but always difficult. Grain is hard no matter what.

I'm hoping the film grain synthesis tools in AV1 get explored soon - I've always thought this was a great idea.

I also wonder if the new MPEG-5 LC-EVC / enhancement layer systems could be used to encode a cleaner version of the video and then grain synthesis information as an enhancement layer / noise model, kind of like V-Nova Perseus but tuned for grain.
Blue_MiSfit is offline   Reply With Quote
Old 9th November 2019, 06:18   #7173  |  Link
Zebulon84
Registered User
 
Join Date: Apr 2015
Posts: 21
Quote:
Originally Posted by Blue_MiSfit
I'm hoping the film grain synthesis tools in AV1 get explored soon - I've always thought this was a great idea.
It seams Netflix is working on an AV1 film grain synthesis : AOMedia 2019 Research Symposium - 04 : Netflix.
Zebulon84 is offline   Reply With Quote
Old 9th November 2019, 09:51   #7174  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 322
Quote:
Originally Posted by RanmaCanada View Post
Anything with high grain should only be encoded in x264 (or just remuxed) as x265 still can not handle it anywhere near as well. I believe the last time someone tested it, they were doing the original Alien, and the re-encode came out larger than the source.

Unless it's magically gotten better since then.
Its gotten alot better then the early days. In my experience x265 have no issue with grain and fine detail, and is imo better then x264 at ”normal” levels (crf18 ~6-9Mpbs if we are discussing 1080p SDR). The issue is that it needs at least preset slow (combined with no-sao and some deblock), and that makes it much slower then x264. I have yet seen x265 be tuned at then same speed as x264 (slower/veryslow with tune film) with better detail retention.

With that said, is x264 better for 1080p sdr to achive near lossless quality at high bitrates? Sure, especialiy if speed also is concidered. But that is not the focus for x265 or most hevc encoders.

Last edited by excellentswordfight; 9th November 2019 at 10:45.
excellentswordfight is offline   Reply With Quote
Old 9th November 2019, 12:55   #7175  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 90
Quote:
Originally Posted by Zebulon84 View Post
It seams Netflix is working on an AV1 film grain synthesis : AOMedia 2019 Research Symposium - 04 : Netflix.
The danger of that is that many people/companies will use that as an excuse to apply exagerated loss of detail information and 'mask' it with some added synthetic film grain applied to give the false illusion of detail retention (while the information that 'makes sense' is gone). If you know what i mean...
Lets hope they use a good implementation that prevents this as good as possible.

Last edited by K.i.N.G; 9th November 2019 at 13:14.
K.i.N.G is offline   Reply With Quote
Old 9th November 2019, 20:39   #7176  |  Link
Fishman0919
FishmanMod Android Dev
 
Fishman0919's Avatar
 
Join Date: Apr 2004
Location: Somewhere else, maybe Arizona Bay
Posts: 1,143
Odd there are no x265 3.2.1 builds around...
__________________
"Cinderella story, out of nowhere,
former greenskeeper, now about
to become the Masters champion.
It looks like a mirac- it's in the hole!"
Fishman0919 is offline   Reply With Quote
Old 9th November 2019, 20:57   #7177  |  Link
redbtn
Registered User
 
redbtn's Avatar
 
Join Date: Jan 2019
Location: Russia
Posts: 105
Quote:
Originally Posted by Fishman0919 View Post
Odd there are no x265 3.2.1 builds around...
Yeah, it was released a few days ago but there is no build anywhere.
redbtn is offline   Reply With Quote
Old 9th November 2019, 21:49   #7178  |  Link
agressiv
Registered Loser
 
agressiv's Avatar
 
Join Date: Dec 2004
Posts: 117
LAVF Patch

Is there any guide to compiling x265 on Windows with an LAVF/Smash patch?

I grabbed the Yuuki source and threw it into my cross-compile script, but get a ton of errors lavf.cpp on and I'm not knowledgeable enough to troubleshoot. I had to hack apart the script as it was to not overwrite the Yuuki version with the current mercurial branch.

One of 50+ errors:
/home/agressiv/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp.text+0x11): undefined reference to `avcodec_free_context'
agressiv is offline   Reply With Quote
Old 9th November 2019, 22:49   #7179  |  Link
agressiv
Registered Loser
 
agressiv's Avatar
 
Join Date: Dec 2004
Posts: 117
Quote:
Originally Posted by redbtn View Post
Yeah, it was released a few days ago but there is no build anywhere.
https://mega.nz/#!vBgRzKbD!SoaO5Lgh9...DVyCiVv9IemkT0

Here's one I compiled - 3.2.1, x64 bit MSVC compiled with 8/10/12 bit support.
agressiv is offline   Reply With Quote
Old 10th November 2019, 02:45   #7180  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
Quote:
Originally Posted by agressiv View Post
Is there any guide to compiling x265 on Windows with an LAVF/Smash patch?

I grabbed the Yuuki source and threw it into my cross-compile script, but get a ton of errors lavf.cpp on and I'm not knowledgeable enough to troubleshoot. I had to hack apart the script as it was to not overwrite the Yuuki version with the current mercurial branch.

One of 50+ errors:
/home/agressiv/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x11): undefined reference to `avcodec_free_context'
cmake -DENABLE_LSMASH=ON -DENABLE_LAVF=ON -DENABLE_STATIC_LAVF=ON path/

You'll need windows gcc compiled ffmpeg being installed in your x86_64 include & lib.

I have full rakefile to compile Yuuki and Asuna binaries.
__________________
Projects
x265 - Yuuki-Asuna-mod Download / GitHub
TS - ADTS AAC Splitter | LATM AAC Splitter | BS4K-ASS
Neo AviSynth+ filters - F3KDB | FFT3D | DFTTest | MiniDeen | Temporal Median
MeteorRain is offline   Reply With Quote
Reply

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 11:55.


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