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 30th August 2016, 17:10   #4221  |  Link
x265_Project
Guest
 
Posts: n/a
Accelerating HEVC Adoption

Today I'm publishing a proposal to accelerate HEVC adoption. I look forward to a productive conversation.
http://x265.org/proposal-accelerate-hevc-adoption/
  Reply With Quote
Old 30th August 2016, 22:29   #4222  |  Link
tebugg
Registered User
 
Join Date: Jul 2010
Posts: 14
Quote:
Originally Posted by x265_Project View Post
Today I'm publishing a proposal to accelerate HEVC adoption. I look forward to a productive conversation.
http://x265.org/proposal-accelerate-hevc-adoption/
"Proposal To accelerate HEVC adoption, I propose that HEVC patent licensors agree to the following principles;

All HEVC patent holders should make their patents available through a patent pool
Ideally, all patent holders should join one patent pool
Only one reasonable royalty should be paid per device
Software decoding on consumer devices must be royalty free
Software encoding on consumer devices must be royalty free
Content distribution must be royalty free
There must be a reasonable cap on total royalties owed for HEVC implementations"


would this also mean that any improvements that have not made it to the open source x265 due to patent limitations would then be pushed to the open source and would benefit people like us that use x265 for personal use?

Last edited by tebugg; 30th August 2016 at 22:33.
tebugg is offline   Reply With Quote
Old 30th August 2016, 22:59   #4223  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by tebugg View Post
...would this also mean that any improvements that have not made it to the open source x265 due to patent limitations would then be pushed to the open source and would benefit people like us that use x265 for personal use?
There is no part of the HEVC standard that hasn't made it to x265 due to patent limitations. We license x265 to commercial companies without patent coverage (we explicitly require licensees to identify obtain all necessary patents). Of course, if HEVC patents are too expensive or difficult to license, it hurts our commercial business, and that isn't good for open source adopters, as we won't be able to continue to grow our development team and invest in x265.
  Reply With Quote
Old 31st August 2016, 20:03   #4224  |  Link
x265_Project
Guest
 
Posts: n/a
Netflix presented the results of their large-scale study, comparing x265 to x264 and VP9 (libvpx)...
https://www.youtube.com/watch?v=wi1B...utu.be&t=1h25s

Naturally, if you don't use --tune ssim, results are worse when measured using SSIM. When they avoided --tune psnr and --tune ssim their own visual quality metric showed that x265 delivered the best visual quality. Similarly, when tuned for objective metrics, x265 is the clear winner when measured with objective metrics.
  Reply With Quote
Old 1st September 2016, 04:28   #4225  |  Link
mariush
Registered User
 
Join Date: Dec 2008
Posts: 589
I also noticed that they used 8 bit content (they had higher bit content but they brought it down to 8 bit before passing to encoders) and they used the 8bit encoders - i would have loved to see 10 bit x264 encodings compared to the others.
Also, they didn't mention anything about using -tune animation or something like that when encoding cartoons / anime / whatever with x26* (they said they did apply psycho visual tunings but didn't say in detail what)

Another thing they did was they used preset placebo but I suspect they wouldn't use this in production because 1080p content encoded with placebo may not play on older video cards or some hardware boxes/devices ... it would make sense to lower some parameters at the very least, to get something that's not quite placebo.
mariush is offline   Reply With Quote
Old 1st September 2016, 05:57   #4226  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by mariush View Post
Another thing they did was they used preset placebo but I suspect they wouldn't use this in production because 1080p content encoded with placebo may not play on older video cards or some hardware boxes/devices ...
Why do you say that?
  Reply With Quote
Old 1st September 2016, 07:15   #4227  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
Interesting test. Actually, it is to eliminate the codec libvpx. Who can tell me what means "Visual quality tuned"?
Are these codec parameters resulting from setting a placebo?
Jamaika is offline   Reply With Quote
Old 1st September 2016, 15:49   #4228  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by Jamaika View Post
Interesting test. Actually, it is to eliminate the codec libvpx. Who can tell me what means "Visual quality tuned"?
Are these codec parameters resulting from setting a placebo?
It means they didn't use --tune psnr or --tune ssim, or turn off psy-rd or psy-rdoq. If you watch the presentation, you'll see the explanation.

Also check out my explanation here... http://forum.doom9.org/showthread.ph...49#post1779649

And check out http://www.streamingmedia.com/Articl...ticleID=113346

Last edited by x265_Project; 2nd September 2016 at 18:18.
  Reply With Quote
Old 4th September 2016, 06:45   #4229  |  Link
NikosD
Registered User
 
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
The AVX2 optimizations of x265 have started to play a role.

On the same clip I benchmarked a Sandybridge and a Haswell system using x265 v2.0+5 with the default medium preset without changing any switch.

Core i5-2400 5,94 fps
Core i7-4790 13,09 fps

The Haswell system has faster base clock, faster DDR3 RAM, faster turbo clock, hyperthreading and larger L3 cache.

Clock for clock with the same L3 cache, turbo, RAM speed and hyperthreading, Haswell is not yet twice as fast but is has a significant advantage.
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1)
HEVC decoding benchmarks
H.264 DXVA Benchmarks for all
NikosD is offline   Reply With Quote
Old 4th September 2016, 14:21   #4230  |  Link
JohnLai
Registered User
 
Join Date: Mar 2008
Posts: 448
Quote:
Originally Posted by NikosD View Post
The AVX2 optimizations of x265 have started to play a role.

On the same clip I benchmarked a Sandybridge and a Haswell system using x265 v2.0+5 with the default medium preset without changing any switch.

Core i5-2400 5,94 fps
Core i7-4790 13,09 fps

The Haswell system has faster base clock, faster DDR3 RAM, faster turbo clock, hyperthreading and larger L3 cache.

Clock for clock with the same L3 cache, turbo, RAM speed and hyperthreading, Haswell is not yet twice as fast but is has a significant advantage.
Now that explain why I3-4330 3.5ghz encoding speed is almost similar to overclocked 4.2Ghz I5-3570k....
JohnLai is offline   Reply With Quote
Old 4th September 2016, 19:51   #4231  |  Link
GigaWatt
Registered User
 
Join Date: Apr 2016
Posts: 3
x265 HEVC Encoder

Hi. I'm new to this forum, but I've been following doom9's threads and posts for years. I've been playing around with encoding video and I've found most of my answers in some thread on doom9, but for a few months now, I've been having a problem that I haven't been able to solve by myself.

I've been using x265 as my primary encoder for about a year now with MeGUI and Simple x264/x265 Launcher as frontends. My interests are aimed towards lower bitrates (to about 1000, maybe a little more)... basically, I'm interested in lowering the bitrate as much as possible (in combination with some filters and tuning, mostly grain) and tuning the psychovisual enhancements to achieve maximum subjective quality of the encode. The resolution of the encoded videos is 720p (8 bit sources and encodes). For indexing, I'm using L-SMASH (2 pass encodes). So, basically, I do everything in MeGUI except the encode, which is done in Simple x264/x265 Launcher.

OK, now, let's get to the actual problem. It seems that the --tune grain command in the newer versions of x265 doesn't seem to be working as well as the older ones... at least subjectively. For example, the older versions (to about 1.9+3, that's the last one that was bundled with Simple x264/x265 Launcher and worked "correctly") blured the video at lower bitrates, thus subjectively giving the audience the perception that "this is just how the video was shot/edited". Newer versions (1.9+3 and above) don't seem to do this quite as good as the previous versions, i.e. the video is just more pixelated (not blured).

At first, I thought that it might be a problem with MeGUI or/and Simple x264/x265 Launcher (I'm using the development update server of MeGUI), but apparently, this is not the case.

I haven't done a changelog analysis of x265 (mostly because it's time consuming, something that I don't have much of lately), but I did see some new commands being added in the 2.0 versions of x265 (have no idea if they where there after 1.9+3 and before 2.0x). For example, there is a new CLI command in the analysis chain, --[no-]rskip, which I though might be the culprit so I disabled it (added --no-rskip to CLI). It didn't give me the result I was hoping for. The encode was slightly better, but... not as blured as with the 1.9+3 version. So I tried another approach. Even though --rc-grain is enabled when encoding with --tune grain, I tried adding it in the CLI, just in case. Subjectively, this had no effect on the end result, which probably means that the --tune grain parameter is working correctly and enabling --rc-grain. So, I tried adding --no-slow-firstpass (apparently, --slow-firstpass is enabled by default after 1.9+3), which I thought might "dumb down" the analysis during the first pass and (hopefully) blur the encode. Again, subjectively, there was some improvement, but, not what I was hoping for. So, I tried adding all three commands as custom CLI parameters... as I thought, it didn't help me get the result I was hoping for.

So, my question is, what has changed in the --tune grain parameter since 1.9+3 and how do I get back to doing the encodes the way I want to (blurry, not pixelated).
GigaWatt is offline   Reply With Quote
Old 4th September 2016, 20:07   #4232  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Welcome.

A lot has changed in the "grain" tuning, partially quite deep inside the encoder. Because it was supposed to preserve the grain, not to remove it. You may find all the details in the x265 commit log, but they will be very technical... Best anchor would probably be to analyze the set of basic parameters this complex tuning consists of.

3e53004: grain: improve grain handling settings / Turn off SAO, increase psychovisual settings to better retain high frequency

305a127: rc: fix Rate Control for grainy content / optimize params for tune grain, reduce frequent qp fluctions to prevent grain loss

(Probably a few more...)

To return to the old blurring behaviour, you will certainly not use "--tune grain" anymore. But what instead ... may be too much for me to be able to summarize that. Most probably you would keep SAO enabled, I remember that this feature was most frowned upon by those who preferred to preserve the grain.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 4th September 2016 at 20:15.
LigH is offline   Reply With Quote
Old 4th September 2016, 21:25   #4233  |  Link
GigaWatt
Registered User
 
Join Date: Apr 2016
Posts: 3
Thanks for the welcome . Glad to "officially" be a part of doom9's forum .

Well, the "--tune grain" parameter was the only thing actually gave "good" (blurry) results for me. I didn't mention this before, but I was using it even if the video didn't contain any grain (subjectively) just so that I could get a better psychovisual experience of the video at lower bitrates.

I would say that this is something to think about... adding a new tune parameter in x265? Perhaps "--tune blur" or something similar? I know it's a lot to ask for at this stage of the development (have no idea if that is even in conformance with the HEVC standards), but not everyone is after better quality and preserving grain (although, yes, I have to admit that that would be the goal of any development, making something better, not worse). I think that many web developers will also find a feature like this very handy in online content (save bandwidth and storage, get the same user experience... psychovisually ).

Anyhow, here is what x265 2.0+2 "long help" says about SAO:

Quote:
Loop filters (deblock and SAO):
--[no-]deblock Enable Deblocking Loop Filter, optionally specify tC:Beta offsets Default enabled
--[no-]sao Enable Sample Adaptive Offset. Default enabled
--[no-]sao-non-deblock Use non-deblocked pixels, else right/bottom boundary areas skipped. Default disabled
Basically, it says that it's enabled. Does "--tune grain" disable SAO or has no effect on SAO (stays enabled)? Or, as you suggested, I don't use any tune parameters, just enable all loop filters (--deblock --sao --sao-non-deblock)?

Quote:
Originally Posted by LigH View Post
Best anchor would probably be to analyze the set of basic parameters this complex tuning consists of.
I was afraid I'd get that answer :S. I was hoping to avoid that, but hey, on the plus side, I'll probably learn a lot .

Thanks for your help .
GigaWatt is offline   Reply With Quote
Old 4th September 2016, 21:49   #4234  |  Link
divxmaster
Registered User
 
Join Date: Mar 2015
Location: New Zealand
Posts: 45
I've been getting great results firstly using
QTGMC filter and then smdegrain filter. This does however require a knowledge of avisynth/vapoursynth,
with vapoursynth being much more preferable. I taught myself vapoursynth from scratch/google so perhaps
you can also?

used on 576p, so far ds9, sg1, voyager, the results are incredible. bit rates are 400-600 range. it is super sharp
though when seen up close, but is great at a normal viewing distance.

Note that QTGMC does enhance the picture, even if its not interlaced, in some situations.
I see you use 8bit encodes. If you can, try and use 10 bit. More and more hardware now has 10 bit decode,
including the new kaby lake processor.
You don't need SAO if you use the above filters, and in fact it blurs the picture quite a bit.

Cheers,
Divxmaster
divxmaster is offline   Reply With Quote
Old 4th September 2016, 22:47   #4235  |  Link
GigaWatt
Registered User
 
Join Date: Apr 2016
Posts: 3
I also didn't mention in my first post that I'm familiar with AviSynth scripts and I usually edit the scripts in the end (after being generated with MeGUI). I have't tried VapourSynth at all, but from what I've read, it seems like it's next logical step, so I will try to get into it soon.

I also had great results with MosquitoNR (32, 0 settings), so I used it in combination with "--tune grain" in x265. I haven't tried QTGMC and smdegrain though, but will, thanks for the suggestion . Also, I was afraid of encoding at anything larger than 8-bit, mostly because of the lack of hardware (and, in some cases, also software) support, but I haven't been in pace with the changes in this area, so I wasn't aware that things are not what they used to be in this area. Again, thanks for the input and will try a 10-bit encode .

One problem though. You're encoding at 576p at 400-600. I was getting good results at 700-1000 at 720p with "--tune grain" and MosquitoNR. I dind't have to use --tune grain and MosquitoNR at 900-1000, but with any bitrate below, say... 800 or 850, I used both of them. It also depended on the source. If there was not a lot of movement in the scenes of the video and if the source required black bar cropping (end resolution = 1280 x 534, 536...), the end result would be great even at 700 without "--tune grain" or MosquitoNR. As I said, it depends on the source.

Anyhow, I will try to do an encode with no tune parameters (SAO disabled) and the filters you suggested . Will post with subjective results .
GigaWatt is offline   Reply With Quote
Old 5th September 2016, 04:29   #4236  |  Link
x265_Project
Guest
 
Posts: n/a
Pradeep gave an update on x265 at VideoLan Developer Days...
https://www.youtube.com/watch?v=oT8HueAQZ4w
  Reply With Quote
Old 5th September 2016, 21:32   #4237  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 90
Are there any (official) multilib binaries?
I can only find seperate (official) builds for 8, 10 & 12 bit?
K.i.N.G is offline   Reply With Quote
Old 5th September 2016, 21:34   #4238  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by K.i.N.G View Post
Are there any (official) multilib binaries?
I can only find seperate (official) builds for 8, 10 & 12 bit?
Not "official", but anyway:
https://forum.doom9.org/showthread.p...29#post1778529
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊
LoRd_MuldeR is offline   Reply With Quote
Old 5th September 2016, 22:03   #4239  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
I keep posting irregularly, here and in the VideoHelp forum. Here is an archive on MediaFire, all 7-zip files contain 32-bit and 64-bit builds both as 3-in-1 multilib EXE and as separate EXE and DLL files per bitdepth. It is not "official", just plain, compiled from the Mercurial source repository by GCC in an MSYS/MinGW environment, no additional patches.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 5th September 2016 at 22:06.
LigH is offline   Reply With Quote
Old 6th September 2016, 01:38   #4240  |  Link
x265_Project
Guest
 
Posts: n/a
Help us share the good news on Slashdot! Old school techies deserve to know. Vote for this story here... https://slashdot.org/submission/6278...cient-than-vp9

Edit: We made the front page of Slashdot! Thanks for your help.

Last edited by x265_Project; 6th September 2016 at 18:06.
  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 18:11.


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