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. |
30th August 2016, 17:10 | #4221 | Link |
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/ |
30th August 2016, 22:29 | #4222 | Link | |
Registered User
Join Date: Jul 2010
Posts: 14
|
Quote:
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. |
|
30th August 2016, 22:59 | #4223 | Link |
Guest
Posts: n/a
|
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.
|
31st August 2016, 20:03 | #4224 | Link |
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. |
1st September 2016, 04:28 | #4225 | Link |
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. |
1st September 2016, 15:49 | #4228 | Link | |
Guest
Posts: n/a
|
Quote:
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. |
|
4th September 2016, 06:45 | #4229 | Link |
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 |
4th September 2016, 14:21 | #4230 | Link | |
Registered User
Join Date: Mar 2008
Posts: 448
|
Quote:
|
|
4th September 2016, 19:51 | #4231 | Link |
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). |
4th September 2016, 20:07 | #4232 | Link |
German doom9/Gleitz SuMo
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. Last edited by LigH; 4th September 2016 at 20:15. |
4th September 2016, 21:25 | #4233 | Link | ||
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:
Quote:
Thanks for your help . |
||
4th September 2016, 21:49 | #4234 | Link |
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 |
4th September 2016, 22:47 | #4235 | Link |
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 . |
5th September 2016, 04:29 | #4236 | Link |
Guest
Posts: n/a
|
Pradeep gave an update on x265 at VideoLan Developer Days...
https://www.youtube.com/watch?v=oT8HueAQZ4w |
5th September 2016, 21:34 | #4238 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
https://forum.doom9.org/showthread.p...29#post1778529
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
|
5th September 2016, 22:03 | #4239 | Link |
German doom9/Gleitz SuMo
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.
Last edited by LigH; 5th September 2016 at 22:06. |
6th September 2016, 01:38 | #4240 | Link |
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. |
Thread Tools | Search this Thread |
Display Modes | |
|
|