[Boards: 3 / a / aco / adv / an / asp / b / biz / c / cgl / ck / cm / co / d / diy / e / fa / fit / g / gd / gif / h / hc / his / hm / hr / i / ic / int / jp / k / lgbt / lit / m / mlp / mu / n / news / o / out / p / po / pol / qa / r / r9k / s / s4s / sci / soc / sp / t / tg / toy / trash / trv / tv / u / v / vg / vp / vr / w / wg / wsg / wsr / x / y ] [Home]
4chanarchives logo
10-bit HEVC video encoding thread
Images are sometimes not shown due to bandwidth/network limitations. Refreshing the page usually helps.

You are currently reading a thread in /g/ - Technology

Thread replies: 153
Thread images: 19
File: HEVC_LMAO.png (668 KB, 1020x482) Image search: [Google]
HEVC_LMAO.png
668 KB, 1020x482
Video Encoder: https://sourceforge.net/projects/megui/
Latest 10-bit x265 encoder: https://builds.x265.eu/
Why 10-bit encoders are better than 8-bit ones: http://www.x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf

720p 800 Kbps 10-bit HEVC sample: http://www.mediafire.com/download/6fob4pzy0voaapu/10-bit+HEVC.7z
720p 10-bit H264 samples: http://www.mediafire.com/download/oo5luitse6izc2c/10-bit+H264.7z
10-bit H264 samples include 800, 1144, 1344, and 1600 Kbps bitrates. All samples include 96 vbr stereo Opus audio

10-bit HEVC encoding speed estimates if using the fast preset, an ABR of 800 Kbps, and transcoding a HQ 720p version of big buck bunny

Intel Pentium 4 (1 physical core @ 3.6 GHz): ~1.5 FPS

Intel Atom x5-Z8300 (4 physical cores @ 1.4-1.8 GHz): ~3.5 FPS

AMD Athlon 5350 (4 physical cores @ 2.1 GHz): ~8 FPS

Intel i3-4170 (2 physical cores @ 3.7 GHz): ~16 FPS

AMD A8-7600 (4 physical cores @ 3.2-3.8 GHZ): ~16 FPS

Intel i7-4770K (4 physical cores @ 3.5-3.9 GHz): ~30 FPS

AMD FX-9590 (8 physical cores @ 4.7-5.0 GHZ): ~30 FPS

Intel i7-5960X (8 physical cores @ 3.0-3.5 GHz): ~50 FPS
>>
Neat
>>
Like so many have said in the past thread, we are not ready for HEVC 100% but we are getting there. There is still no HW support for 10-bit HEVC decode on most laptops and virtually all phones. Encoding times are still rather long even on desktop processors. I would advise you all to NOT attempt to encode 1080p HEVC unless you have something better than an i3/A8 CPU as encoding times will be excruciatingly painful.
>>
The encoders on public trackers fucking trigger me. They often use a x264 file as a source and instead of medium speed they choose super fast with 2 pass encode.

I thought I knew nothing about encoding, but apparently these kiddo's are worse.
>>
File: HEVC_test.png (282 KB, 2800x900) Image search: [Google]
HEVC_test.png
282 KB, 2800x900
I want to apologize for the pic I posted last thread, I made a mistake in what preset I used to encode. I used the fast preset not the slow preset. Again sorry for that fuck-up.

pic related is the corrected version
>>
>>54788712
Their mission is to upload the file asap.
>>
>>54788597
>Intel i7-5960X (8 physical cores @ 3.0-3.5 GHz
literally why, getting 4.4GHz is trivial.
>>
When will x265 become mainstream?
>>
File: old_town-PSNR.png (21 KB, 1070x575) Image search: [Google]
old_town-PSNR.png
21 KB, 1070x575
>>54788712
>They often use a x264 file as a source and instead of medium speed they choose super fast with 2 pass encode.
lol yeah, you never use a 2-pass ABR or choose something faster than the "fast" preset.

>>54788751
It's in vain since they use a shitty 2-pass ABR desu. They would have much better quality and maybe even take less time if they used the fast preset with a CRF value.
>>
>>54788768
My estimates only reflect the processors on stock settings because not all can be overclocked much. However if you did manage to overclock an i7-5960X to 4.4GHz then you might get close to 60 FPS which is pretty cool.
>>
>>54788777
When the anime and piracy groups properly adopt it.

>all those tears when Daiz drops the HEVC on the lowtier weebs
>>
>>54788777
Nice lucky trips.

Well it all depends on how soon phone/laptop manufacturers adopt HW HEVC decoding for their products so soon. Maybe in the next 1-2 years we will see HW HEVC decoding on most phones and laptops.

See for HEVC to go mainstream people must be able to play their chinese cartoons/movies on their phones and laptops without sacrificing battery too much or causing it to constantly overheat. Cheap (maybe $300) 8-core Zen processors with i7-5960X stock multi-core performance are going to be sold as soon as Q4 2017 so encoding HEVC won't really be a problem. The real problem preventing HEVC from going mainstream is HW decoding support.
>>
>>54788874
>if you did manage to overclock an i7-5960X to 4.4GHz

Its not even a question of if really, as long as you have a halfway decent cooler 4.4GHz is dead simple.

4.5GHz+ can be tricky on Haswell-E, especially on the 5960x, but I have yet to see a single 5960x that couldn't get stable at 4.4GHz and 1.3v. I'm sure there are a few out there that just have shit OC potential, but most of those Intel bins for 5930k/5820k stock.
>>
HEVC is pretty neat. Some shows have been getting great-looking ~800mb 1080p releases for a 40min show.
>>
>>54788954
HW decoding support doesn't help with 10 bit, does it? I don't think anyone builds 10 bit decoders in hardware.
>>
>>54788925
>When the anime and piracy groups properly adopt it.
This too.

>all those tears when Daiz drops the HEVC on the lowtier weebs
Hopefully Daiz will put HEVC on hold until more HW decoding support arrives. We already have HEVC HW support on carrizo APU laptops I think.
>>
>>54788973
Realistically the 5960x tops out at 4.2 average. 4.5~4.5 sells for above retail and is considered golden.
>>
>>54788597
>HEVC
this is a free software board desu.
>>
File: 1463209205141.gif (3 MB, 200x155) Image search: [Google]
1463209205141.gif
3 MB, 200x155
>>54789016
>tfw your 5820k is stable at 4.7GHz and under 1.3v
>>
>>54788981
Unfortunately the encoders don't know what the fuck they're doing. They could lower that file size further and still maintain relatively good quality.
>>
>>54789041

Are the chinese making fun of Americans in that gif?

https://www.youtube.com/watch?v=gPbVRpRgHso
>>
>>54789041
Doubt it's stable. Try running occt.
>>
File: videosupport.jpg (131 KB, 1072x878) Image search: [Google]
videosupport.jpg
131 KB, 1072x878
THANK YOU BASED NVIDIA
>>
>>54789074
I read GPU encoding leads to lower compression and more key frames (lower quality)
>>
>>54788984
>HW decoding support doesn't help with 10 bit, does it?
It does, HW decoding in general extends battery life and reduces heat output on devices.

>I don't think anyone builds 10 bit decoders in hardware.
For phones and laptops? Pretty much, which is a shame, 10-bit video is far superior than 8-bit video.
>>
>>54789067
It's CPU-z validated and can run Cinebench R11.5 and R15 without crashing. I will try an encode later tonight at those settings and see if it crashes. If it doesn't then it's stable enough for my uses. I'm not doing 24/7 number crunching. I do encoding and some desktop usage.
>>
>>54788716
Why is HEVC bigger than H.264?
>>
>>54789155
The hwbot encoding test is actually very difficult to pass. I'd say if you can pass that at least a few times it's probably stable enough for daily use.
>>
>>54789178
I mean it's already fairly impressive that it boots to 4.7GHz at 1.274, i've seen a 5820k struggle at 4.5GHz with 1.3v.
>>
Nvidia will have GP107 for notebooks, HEVC Main10/Main12 hardware decoding will be available

Intel will have HEVC Main10 hardware decoding in Kaby Lake Core iX CPUs & Apollo Lake SoCs for low cost PCs
>>
>>54789142
>It does, HW decoding in general extends battery life and reduces heat output on devices.
In theory, but it's not worth anything if nothing has 10-bit decoding hardware.

Are 8-bit decoders totally useless for 10-bit video? Is there no way whatsoever to take advantage of the 8-bit hardware with a 10-bit file?
>>
>>54789230
Skylake has hybrid/partial Main10 decoding but it's horribly slow and useless for 4K and not power efficient at all compared to a full hardware decoder
>>
>>54789198
My 5930k boots to 4.7 as well but I could only 4.4 1.38v out of it. I beat it to hell though and passed every stress test. Occt large data set was the hardest and forced me down from a stable 4.5 1.25v.
>>
If you were trying to maximize core count for encoding purposes, what kind of setup would be most cost effective?

Does RAM matter at all?
I imagine regular spinning disks would be fine because of how shit slow the process is.

I'm thinking some kind of Xeon E5 v1.
Engineering samples sound somewhat dangerous for this task though.
>>
File: 1.png (74 KB, 746x412) Image search: [Google]
1.png
74 KB, 746x412
Not bad, was expecting worse.
>>
>>54789270
Those $50 12 core sandy bridge xeons
>>
>>54789218
>"UVD 6.1: STONEY (HEVC=Yes, Max.Size: 4K, Supports 10bit Color Channel Depth for Ultra Blu-ray Video)"

https://en.wikipedia.org/wiki/Unified_Video_Decoder

It looks like stoney ridge APUs (x86 excavator) will also feature 10-bit HEVC HW decoding support. Carrizo APUs and Rx-3xx GPUs already support 8-bit HEVC HW decoding.
>>
>>54789303
NO

None of the Rx-3xx supports HEVC decoding, not even Main 8bit, Tonga does not support Main 8bit at all
>>
>>54789270
If you don't need it 24/7, I'd consider renting a server. A beefy EC2 instance is <$2 per hour. A comparable machine would cost you on the order of $4000.
>>
>>54789270
>If you were trying to maximize core count for encoding purposes, what kind of setup would be most cost effective?
I'd wait for AMD to deliver ZEN. Their 8-core flagship is supposed to compete with the i7-5960X at least on stock settings.

>Does RAM matter at all?
Not really. Video encoding doesn't use a lot of RAM or bandwidth. As long as you have like 1GB free of RAM then you should be okay.

>I imagine regular spinning disks would be fine because of how shit slow the process is.
This I'm not so sure. Maybe an SSD might speed up encoding but probably not by much.
>>
>>54789365
>"The UVD version in "Fiji"- and "Carizzo"-based graphics controller hardware is also announced to provide support for High Efficiency Video Coding (HEVC, H.265) hardware video decoding"

https://en.wikipedia.org/wiki/Unified_Video_Decoder#UVD_6

Are you sure? Did AMD not keep their word? I heard you have to be using the latest catalyst driver and a compatible video player (MPC-HC I think) to be able to have HEVC HW decoding available.
>>
>>54789481
Tonga is UVD 5.0, don't you even see the entry above UVD 6.0?

The wiki page is wrong, period.
>>
Should I be using hyperthreading when encoding?
>>
File: 1391062469603.png (273 KB, 580x500) Image search: [Google]
1391062469603.png
273 KB, 580x500
>>54789035
VP9 is a nice video codec that all streaming websites should adopt because you don't have to pay anything to use it. However for personal use HEVC beats VP9 in terms of ease of use and encoding speed. We also have growing HW decoding support for HEVC (mostly 8-bit for now).
>>
>>54789527
Not really. Hyperthreading is only really useful when a program can only efficiently use 1 or 2 threads (ie ARMA 3). HEVC encoding can efficiently use all the threads you have. Whether you turn on hyperthreading on or not won't really affect performance much.
>>
>>54789282
Nice. Looks like you can get away with encoding 1080p HEVC video.
>>
When will the 720p meme end?

Come on, it's fucking $current_year, guys.
>>
>>54789725
hahaha. No but seriously encoding HEVC is a heart fucking experience unless you have a really nice CPU like >>54789282 does.

Hopefully AMD Zen will change all of that.
>>
>>54789403
Is AMD Zen 8 reel cores or 8 fake cores?
>>
File: 919023478.jpg (111 KB, 625x625) Image search: [Google]
919023478.jpg
111 KB, 625x625
Here is a screenshot comparison of the big buck bunny rips I did

800 Kbps 10-bit HEVC vs 800 Kbps 10-bit H264: http://screenshotcomparison.com/comparison/174224

800 Kbps 10-bit HEV vs 1600 Kbps 10-bit H264: http://screenshotcomparison.com/comparison/174225
>>
>reencoding

LMAO
M
A
O
>>
>>54789826
They're real.

http://wccftech.com/amd-zen-cpu-performance-double-fx-8350/
>>
File: image_26.jpg (15 KB, 181x166) Image search: [Google]
image_26.jpg
15 KB, 181x166
>>54789887
Go away placebofag. I bet you use 384KHz sample rate/128-bit FLACS.
>>
>>54789873
Sorry for being clueless, but what is the approximate bitrate for "normal" (typical quality with typical encoding) 720p video?

Is 800 Kbps a lot or a little compared to the files most people play?
>>
>>54789977
Thanks YIFY
>>
>>54790036
>Sorry for being clueless, but what is the approximate bitrate for "normal" (typical quality with typical encoding) 720p video?
It depends on the source and can vary greatly but generally 1000-2000 Kbps 10-bit H264 is good for chinese cartoons and 2000-4000 Kbps is good for action movies. Because we cannot gauge what the best exact bitrate is for encoding a specific video and because ABR is inherently inefficient we use a CRF value instead. Generally for 10-bit H264, 22 CRF will give you okay quality, 16 CRF will give you high quality, and 28 CRF will give you yify quality across all resolutions and source types. You can see why using a CRF is the smarter choice.

>Is 800 Kbps a lot or a little compared to the files most people play?
Depends on the source. This would be okay for chinese cartoons most likely. But again using a bitrate is inefficient and you'll get better quality output if you use a CRF value.
>>
>>54790089
Not saying we should all aspire to encode videos to yify quality. Even the creator of YIFY himself said his movies looked like shit. His goal was to distribute small file size movies that people with even dial-up connections could see. He chose compactness over quality.

Anyway there is a point where video will look exactly the same as the source while being magnitudes smaller. A ~4-6GB 720p 10-bit H264 rip will look pretty much the same as the 15-20GB 720p blu-ray source if encoded right.
>>
Why have you not joined the Nvidia HEVC Main12 master race, /g/?
>>
>>54790627
>Why have you not joined the Nvidia HEVC Main12 master race, /g/?
12-bit HEVC is pretty fucking dumb, the benefits stop at 10-bit. Anything above that is placebo.
>>
>>54789170
I'm sorry I forgot to answer you. Well honestly I'm not sure but the file size difference was very little and insignificant at the end (like 2%). The ABR in 10-bit HEVC might work a little different than the ABR in 10-bit H264, I know the CRF values are not compatible. I did input 800 as the ABR for both 10-bit HEVC and 10-bit H264 when I did those encodes.
>>
>>54790683
What exactly is the point of 10-bit anyway? I was under the impression this referred to color space. I have a few Blu-Ray movies, but most of my stuff is on DVD. I don't think MPEG2 had 10-bit color per channel. If anyone could enlighten me on the subject of why it's so important when the original source was 8-bit, I would be grateful.
>>
>What exactly is the point of 10-bit anyway?
To reduce color banding and improve the quality of video while maintaining the same bitrate compared to 8-bit video.

>I was under the impression this referred to color space. I have a few Blu-Ray movies, but most of my stuff is on DVD. I don't think MPEG2 had 10-bit color per channel. If anyone could enlighten me on the subject of why it's so important when the original source was 8-bit, I would be grateful.
See the PDF link I posted at the start of the thread up there.
>>
>>54791084
Whoops meant to quote you to >>54791194
>>
>>54789051
I'd rather they improve the quality as much as possible and make the releases 1GB. It's not like anyone's short on space/bandwidth these days.
I'm not sure I've ever seen a "perfect" 1080p TV release where textures don't shift around due to compression. Especially in faces. those really make bad compression stand out.
>>
figure i will ask here

Im on an ancient cpu and am waiting on zen, so upgrading while it would be the best option, isn't one im taking.

I have a 280X

Is there ANY video editing program that uses the fucking gpu to render the video, I don't care about it being "lower quality" all I want is to encode at least 720p in real time, god knows my 5770 could do that for 1080p, but for some reason the 280x refuses to do anything.

hell, is there an open source video editor that isn't a complete bitch to use?
>>
>>54791862
>I'd rather they improve the quality as much as possible and make the releases 1GB. It's not like anyone's short on space/bandwidth these days.
True we even have unlimited internet on phones now. However making the releases 1GB for the sake of making them 1GB doesn't really make much sense. Instead they should use a CRF value that will make each episode vary in file size due how much motion it has. This will improve overall quality and keep file sizes down. Nobody should follow in the steps of bloatgirls.

>I'm not sure I've ever seen a "perfect" 1080p TV release where textures don't shift around due to compression. Especially in faces. those really make bad compression stand out.
Actually they make encodes that do not use a CRF stand out. When you use an ABR the encoder will target a specific bitrate not quality so if there is a scene that temporarily needs 2-5 Mbps of bitrate it will become bitrate starved and you will notice artifacts. Even 2-pass ABR will suffer this same problem though quality will be a little better.

Fact is when you use a CRF the encoder will target a specific quality and only use the bitrate derived from things like motion and video dimensions to match that quality. The only reason ABR exists is if you need to maintain a specific bitrate (ie streaming/ fitting video in a dvd).
>>
>>54792080
I don't think any video editor does that. GPU HW encoding has always been spotty at best with AMD GPUs.

If you're going the open source route then you're gonna have to tough it out and learn how to use blender as a video editor.

As for the real-time 720p encoding thing, you can already do that by using the ultrafast preset.

What CPU do you have? I can get more than 20 FPS encoding 720p 10-bit HEVC video with the ultrafast preset and 22 CRF.

GPU encoding is like using the ultrafast preset btw.
>>
page nine save rave
>>
>>54792130
>Even 2-pass ABR will suffer this same problem though quality will be a little better.

Do you even know how 2-pass ABR works? 1st pass calculates a CRF that fits the filesize, and second pass is a CRF encode at that chosen CRF. If it's anything like x264, there's literally no difference between 1 pass CRF that gets you that filesize and 2-pass ABR.

1-pass CRF will get you the exact same results as 2-pass ABR. If you don't care about a certain filesize, then sure go ahead with CRF. If you are a professional mastering studio and you need to cram a studio ProRes 4:2:2 onto a BD disk at the maximum quality, you probably will encode at 80 Mbps 2-pass ABR instead of doing trial and error to find an optimal CRF that will max out bitrates on the disk.
>>
>>54792453
Phenom II 955 black

Thing is good enough for general computer and works for playing games, but I want to do anything remotely cpu intensive it shows its lack of power, zen is the deadline, I either get zen or I get a 6 core intel.
>>
>>54794818
>Do you even know how 2-pass ABR works? 1st pass calculates a CRF that fits the filesize, and second pass is a CRF encode at that chosen CRF. If it's anything like x264, there's literally no difference between 1 pass CRF that gets you that filesize and 2-pass ABR.
WRONG. The CRF targets quality whereas the 2-pass ABR targets a file down to the MB. Yes both will look identical in the end but the 2-pass ABR takes longer and you have no fucking idea what the overall quality of the video will be. With CRF you will know the quality but not the filesize. ie you know CRF 28 will look like shit and 16 CRF won't.
>>
>>54794755
Whoah, thanks for saving my thread anon-kun, I thought it was finished and bankrupt.
>>
>>54794878
Sorry, I got that confused with 2-pass VBR/bitrate.
But you should read this.

http://forum.doom9.org/showthread.php?t=167963
>>
Why and how does 10 bit help me?
>>
>>54794818
>If you are a professional mastering studio and you need to cram a studio ProRes 4:2:2 onto a BD disk at the maximum quality, you probably will encode at 80 Mbps 2-pass ABR instead of doing trial and error to find an optimal CRF that will max out bitrates on the disk.
Good point but this rarely applies to the average user/pirate. By the time you finish doing 1 2-pass ABR encode you could have done 2 CRF encodes.
>>
>>54794955
It's not twice as slow. Maybe 1.5 or something.
1st pass to determine what CRF to use is much faster than a normal CRF encode.

And even if it was twice as slow, 2-pass VBR is still beneficial for targeting a certain filesize. If you're trying to cram 80 Mbps onto a disk, CRF 16 and CRF 17 might be a +/- 5 Mbps difference, which is gigantic.
>>
>>54794952
>Why and how does 10 bit help me?
PDF link is at the start of the thread but generally it's because "muh reduced color banding".
>>
>>54795003
>And even if it was twice as slow, 2-pass VBR is still beneficial for targeting a certain filesize. If you're trying to cram 80 Mbps onto a disk, CRF 16 and CRF 17 might be a +/- 5 Mbps difference, which is gigantic.
It is twice as slow unless you're dumb enough to turn turbo first-pass on. Targeting a file size is rarely needed now. I mean most people have probably never used a CD/DVD in the last 5 or so years.

I'm not saying 2-pass ABR is completely useless but for the average user it's not really needed anymore.
>>
>>54788712
Look on the bright side: At least they're better than the encoders in actual encoding studios
>>
>OP still using lossy material for the encodes
>I told you to use the lossLESS version of Big Buck Bunny to do your testing
>anything less is just fucking stupid
>stupid fucking people will be the death of us all
>>
>>54788984
>HW decoding support doesn't help with 10 bit, does it? I don't think anyone builds 10 bit decoders in hardware.
HEVC hardware decoders will support 10 bit, whether by choice or otherwise.
>>
>>54789599
>HEVC beats VP9 in terms of ease of use and encoding speed
>encoding speed
does it really? all I see is people not knowing how to use the proper flags to encode VP9, like -speed
>>
>>54795468
VP9 isn't ready for personal use yet. Last I checked it doesn't even have a CRF mode.
>>
>>54795526
YouTube already uses VP9 by default on Chrome and Firefox.
>>
>>54795543
>crf is the quality value (0-63 for VP9). To trigger this mode, you must use a combination of crf <q-value> and b:v 0. bv MUST be 0.
http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide

It looks like a crf is already available for vp9.
>>
>>54788597
How do I select h265 in megui?
>>
>>54795857
Go to: settings
Go to: external program configuration
Check: x265
Click: save

It should now download the latest 8-bit x265 encoder to the "tools" folder in the Megui directory.

Finally just replace the old x64 x265 encoder there with the latest one from: builds.x265.eu
>>
File: 10bit.png (10 KB, 500x566) Image search: [Google]
10bit.png
10 KB, 500x566
>>54788597
What is this?

nwe video format? new player?

I can't open any of these links at the moment, dumb it down for me
>>
File: Untitled.png (126 KB, 1523x1015) Image search: [Google]
Untitled.png
126 KB, 1523x1015
I don't really know if I'm doing this right.
>>
>>54795944
Hevc used to be a piece of shit. It would take forever to encode and in the end you would only shave like 30% off the total file size. Now it's faster to encode and compression efficiency seems to have hit 50%.

Also it turns out 8-bit encoders are a piece of shit because of color banding and because they use higher bitrates for the same bitrate.
>>
>>54795983
>babbys first encoder
Use megui family
>>
>>54795983
>43fps
holy shit mang, what cpu do you have? That's fucking fast for hevc.
>>
>>54789112
yea gpu encoding is garbage currently.
other than intel sync w/e the fuck it is
>>
>>54795992
I'm trying it out and the GUI is shit and confusing. I'm sure it allows a lot more fine control over your settings, but it could use a lot of work on organization.
>>
>>54796002
2x Xeon X5650
>>
>>54788597
>a HQ 720p version of big buck bunny
Which one of the sample files does this correspond to?
>>
>>54796075
also the motherboard I'm using has a feature called "Intel Enhanced Turbo Boost" that lets all cores run at the turbo clock all the time. It might help.
>>
>>54795983

>using a lossy encode the OP made from a lossy encode to make yet another lossier encode
>stupid fucking people will be the death of us all
>>
>>54796070
>go to: create avs script
>chose: file indexer
>apply filters if desired
>save
>select x265 settings
>select audio file if not automatically imported
>click autoencode and chose MKV
wow that was hard
>>
>>54796084

The OP is using the low quality 720p lossy version of Big Buck Bunny. If you want the actual proper footage to do testing, use the lossless version:

https://media.xiph.org/

Get the 720p one (4.7GB)
>>
>>54796075
>>54796095
That's pretty fucking noice. You could probably encode 1080p in real time. Meanwhile I'm stuck with my shitty pentium laptop.
>>
>>54788671
>i3/A8 CPU
I forgot for a second /g/ is hilariously poor. Thanks for reminding me.
>>
>>54796115
OP used >>54788716
The h264 video has a bitrate of 5mbps. I wouldn't really call this low quality.

Anyway we got >>54789873 which is enough to compare the codecs.
>>
>>54796143
No most have chinkpads and $700+ phones. It's not that they're poor but for some twisted reason they spend more on their phones than they do on a real computer.
>>
>>54796179
>tfw encoding 10bit 4k HEVC @ 60 fps on my phone
>>
Is this Daiz approved?
>>
File: Untitled.png (383 KB, 1677x1133) Image search: [Google]
Untitled.png
383 KB, 1677x1133
>>54795983
I switched to megui. I installed h265, then used the 1-click encoder and set an ABR of 800 and used the fast preset. The file being transcoded is the 1600 ABR h264 sample file.

Am I doing this correctly?
>>
>>54796198
kek

I wonder how soon that will be possible though. Most flagship phones must have reached at least pentium 4 performance by now.
>>
>>54796115
It doesn't matter what file is used, it only matter that all the tests are done to a standard. The fps numbers don't mean anything if you use different source files.
>>
>>54796212
>fast preset
>correct
Use slow or slower preset, it could make better compression with same quality.
>>
>>54796234
I'm trying to do the same test as the OP

>10-bit HEVC encoding speed estimates if using the fast preset, an ABR of 800 Kbps, and transcoding a HQ 720p version of big buck bunny

>fast preset

When I'm doing jobs myself I always use settings for best quality possible even if it takes a long time.
>>
>>54796212
I did the same test using the sample h265 file and it's about the same speed.
>>
>>54796224
this. I only cared about encoding speed. hevc used to take like 2 days to encode a movie on a desktop lmao
>>
You kids just don't understand anything. If you're using material that is already lossy by nature (which the OP used for his/her encodes as source material) then you're doing it wrong to test for actual visual quality - I don't give a fuck about framerates, I have an 8-core/16-thread machine so it's irrelevant.

If you take lossy material and encode it you're basically taking material that's already had the significant quality of it ripped out and now what you're working with is less than you should be resulting in an encode that certainly can be done much faster because the encoder doesn't have as much actual source material to work with.

If you want to "standardize" it then use a lossless video clip aka the Big Bunny 4.7GB lossless one as the source material for any and all test encodes and then check your results against what others have.

Again, encoding frame rate means shit if the result is horrid in terms of visual quality.
>>
>>54796269
Okay well you didn't have to do that at all. What led you to conclude that a "sample" file had to be encoded again?
>>
>>54796234
>>54796247
see >>54788841

dumb placebofags
>>
>>54796293
Because the OP never specified which file was to be used. I don't know what "HQ 720p version" refers to.
>>
File: file.png (47 KB, 377x515) Image search: [Google]
file.png
47 KB, 377x515
10 bit is great i was sold once i came over this specific file.

1.5 GB for 720p video with 12 language tracks and 40 subtitle tracks.

now this is what im talking about.
the 1080p variant is only 4gb to boot.
>>
>>54796281
OP probably only meant to show encoding speed and compare quality between codecs, you don't need a lossless source to do that. The source he had was gad a 5mbps bitrate for the video, that's at least 6 times more bitrate than a yify encode. OP did good, stop nitpicking.
>>
>>54796281
You're missing and/or dismissing the whole of the current discussion, but you have made one good point in that if the source material isn't good to begin with the higher fps number for encoding can be misleading because it will look like it takes less time to do a job than it will when you actually get around trying to do something worthwhile.

So I will try a high quality file and post the results. I have some 4k video samples that are even more intense than that 4.7GB lossless one I will try.
>>
>>54796306
It refers to >>54788716 which states a ~400MB .MOV file of big buck bunny. Probably in the blender website.
>>
>>54796338
>encoding 4k hevc
god help anon
>>
>>54796338

>I have some 4k video samples that are even more intense than that 4.7GB lossless one I will try.

If they're lossy material (which I'll bet they are) then you're wasting your time - higher resolution doesn't mean shit in that respect.

Someday you kids will figure this shit out.
>>
>>54796363
You know pirates use lossy sources for many of their rips. Also blu-ray is actually lossy. crf 0 is NOT used and instead some arbitrary bitrate is used instead.

I think OP went above and beyond the call of duty and showed us a more realistic encoding scenario imho.
>>
>>54796363
100,000 kbps average

Don't know if it's lossy or not. Goes beyond my knowledge. But's a lot of data to chew up.
>>
>>54796363
lmao nobody was even comparing the quality why are you sperging out? as long everyone uses the same source to compare speeds it's absolutely fine.

yeah of course you shouldn't convert lossy to lossy. Oh and water is wet.
>>
>>54796398
Actually that one didn't open in megui, so I decided to try this file.
http://demo-uhd3d.com/fiche.php?cat=uhd&id=105
>>
>>54796409
Use mkvtoolnix to mux files megui rejects.
>>
>shitty nonfree codecs

Kek. Daala is going to BTFO h265 when it's released in 2035.
>>
File: giphy.gif (405 KB, 320x180) Image search: [Google]
giphy.gif
405 KB, 320x180
>>54796451
my sides
>>
File: 10bit.png (10 KB, 500x566) Image search: [Google]
10bit.png
10 KB, 500x566
>>54795944
>10 bit face
fixed
>>
>>54796451
AV1 is superior and will incorporate Daala features

http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/A-Progress-Report-The-Alliance-for-Open-Media-and-the-AV1-Codec-110383.aspx

Companies got sick of the Jewery MPEG-LA & HEVC Advanced patent pools licensing shit and totally cutting them out with superior AV1 no royalties codec
>>
>>54796409
It ran at about 1.5 fps. I set ABR to 100,000 and forgot to set it back. Didn't see the setting in megui to use original bitrate. "Placebo" setting?
>>
>>54796512
Why did you set it to 100,000kbps and why did you use the placebo setting? Nobody uses the placebo setting. Either use the fast or slow preset.
>>
>>54796537
I set it to 100,000 kbps because the first file I was going to use had about that average bitrate and I did not see a setting to use original bitrate.

I didn't use the placebo setting. I was asking if that is what the placebo setting corresponds to.
>>
File: CZLtx1DUsAA_i1g.jpg-large.jpg (41 KB, 576x521) Image search: [Google]
CZLtx1DUsAA_i1g.jpg-large.jpg
41 KB, 576x521
>>54796510
mfw phones will never catch up to the latest flavor of the year codec

mfw forever forced to transcode
>>
>>54796537
>Either use the fast or slow preset.
Also I tend to never use presets at all if I can avoid it. Either original bitrate or one to suit the particular video.
>>
>>54796543
No familia.

Look if you're targeting quality use a constant quality/crf value instead. 28 is the default, anything lower means more quality and anything higher means less quality.

If you want lossless hevc output then use a crf of 0.
>>
>>54788777
>When will x265 become mainstream?

3-4 years. It's not even close to ready and there's no hardware support except on hardware coming out this year so we have to wait another 2 years after that for adoption to take place and then another 2 years for companies to gradually introduce it.
>>
>>54796567
The presets have NOTHING to do with the bitrate, you choose that later or alternatively use a constant quality/crf value like a normal human being.

The presets only tell the encoder how much to compress the video at any given bitrate/crf. ie crf 28 + ultrafast preset will produce the same quality out put as crf + fast preset but it will encode fast at the cost of a bigger file size.
>>
>>54796577
That's good to know. I'll see if I can switch over to this instead of AVC and Handbrake.
>>
File: dqruyk.png (74 KB, 1143x430) Image search: [Google]
dqruyk.png
74 KB, 1143x430
getting about 6fps on default medium encode
>>
>>54796598
aha

Is that why some anons are able to get much longer and better looking webm files than I am even though I have carefully managed the bitrate of my videos?
>>
Nvidia has supported HEVC Main10 hardware decoding since Jan 2015 with GTX 960 release and August 2015 with GTX 950 release
>>
>>54796624
Pretty much family member. You were only supposed to set a CRF value for webms, nothing else. 63 meant your webm would look like shit and 4 it would look like source but be huge as fuck. All you had to do was pic a number in between to stay below 3MB or whatever.
>>
File: Alliance-for-Open-Media_230.png (21 KB, 230x129) Image search: [Google]
Alliance-for-Open-Media_230.png
21 KB, 230x129
Why are we wasting our time with volunteer efforts like x265 when the open-source AV1 codec will be out in 2017 and be superior with actual professional development and support from a coalition of Amazon, Cisco, Google, Intel Corporation, Microsoft, Mozilla, Netflix, AMD, ARM, and NVIDIA?

http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/A-Progress-Report-The-Alliance-for-Open-Media-and-the-AV1-Codec-110383.aspx

We are going to skip x265 and HEVC and go directly to AV1.

Fuck x265. Complete waste of time.
>>
>>54796908
Because AV1 is a meme. We already have VP9 and HEVC, party's over.
>>
>>54796933
>We already have VP9 and HEVC, party's over.

AV1 is targeting 50% improvement over those. Those codecs are already dying. They are only around because there's no competition. AV1 will clean house.

AV1 is the future. Your browser, TV, every PC you own will be playing it.
>>
>>54796908
>HEVC declared pain in the ass to even license
>``go fuck yourself we're making our own"
>giant ass corporations backing one codec
>patent trolls sued out of existence
>>
>>54797169
Just like what happened to H.264 right?
>>
>>54796980
Unless it gets hardware decoding support like hevc this meme codec can fuck off.
>>
what i sbetter youtube VP9 or 10-bit HEVC?
is youtube going to use 10-bit HEVC?
>>
>>54799796
>what i sbetter youtube VP9 or 10-bit HEVC?
10-bit HEVC. VP9 does have 10-bit encoding but it takes too long to encode so nobody uses it.
>is youtube going to use 10-bit HEVC?
No they don't want to pay the HEVC royalty jews which demand 0.5% in royalty fees for using HEVC commercially. This is like billions of dollars in fees tyat Youtube would pay over time. Thus they did the smart thing and used VP9 which is free to use commercially.
Thread replies: 153
Thread images: 19

banner
banner
[Boards: 3 / a / aco / adv / an / asp / b / biz / c / cgl / ck / cm / co / d / diy / e / fa / fit / g / gd / gif / h / hc / his / hm / hr / i / ic / int / jp / k / lgbt / lit / m / mlp / mu / n / news / o / out / p / po / pol / qa / r / r9k / s / s4s / sci / soc / sp / t / tg / toy / trash / trv / tv / u / v / vg / vp / vr / w / wg / wsg / wsr / x / y] [Home]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.
If a post contains personal/copyrighted/illegal content you can contact me at [email protected] with that post and thread number and it will be removed as soon as possible.
DMCA Content Takedown via dmca.com
All images are hosted on imgur.com, send takedown notices to them.
This is a 4chan archive - all of the content originated from them. If you need IP information for a Poster - you need to contact them. This website shows only archived content.