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 4th November 2013, 11:00   #81  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Quote:
Originally Posted by LigH View Post
Compile? Encode, probably.
Yes, Encode.

Quote:
Originally Posted by LigH View Post
BTW, you ask for a maximum of 108 Mbps, this looks like a double 802.11g WLAN rate?
It's the Bitrate of the original video.
Nothing to do with 802.11g.

The goal here is to test how much CPU it takes to decode a High Bitrate 1080p HEVC video, that is all.
108Mbps is higher than a typical Blu Ray with 30Mbps.
If you have anything higher than 108Mbps it will be of help.

I feel Hollywood will be more concentrated on higher bitrate with 1080p resolution, than UHD with lower bitrate.

For example:
The new 100GB discs with 1080p, but with HEVC, Higher Bitrate, Wider Gamut (Rec.2020), 4:2:2/4:4:4 Chroma, and HFR (maybe).
The quality will be comparable to Digital Cinema (2K) finally.

Lets call it Blu Ray 2 shall we.


Quote:
Originally Posted by Brazil2 View Post
Yeah, I already tested this one.

I got 21fps with: 3770K (4.5Ghz), GTX660 (nothing to do with it).

I specifically ask for the 1080p one for the reason I pointed above.

Last edited by James Freeman; 4th November 2013 at 11:07.
James Freeman is offline   Reply With Quote
Old 4th November 2013, 11:26   #82  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,851
Well, I try to understand your point, but again ... it doesn't make much sense to try to reach the bitrate of an already lossy compressed "original" with another lossy compression algorithm. The encoder will mainly try to re-encode the quantization artefacts of the former copy, so you may spend a lot of time, but the result won't tell you much more than the time wasted.

I prefer to use (almost) lossless sources for testing, like Sintel (a Blender render movie which is available in different image dimensions – e.g. 1080p or 4K – and even high color resolution, 16 bpc = 48 bpp) as original, so I can even get a meaningful quality measure; just their downloads can take several days, due to the size of several Gigabytes.

For shorter tests, there is also the Sintel trailer in 1080p@24fps (Y4M, 3.7 GB / PNG.tgz, 900 MB).
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 4th November 2013, 12:25   #83  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
He just wants to measure the decoding performance, artifacts and source quality don't matter for that.

Last edited by sneaker_ger; 4th November 2013 at 12:49.
sneaker_ger is offline   Reply With Quote
Old 4th November 2013, 18:52   #84  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
Join Date: Jan 2007
Posts: 729
Yes, but the resulting file might still not be representative. There could for example be more skips blocks and as a result, the decoding load would be lower than with a video coded from a lossless source.
mandarinka is offline   Reply With Quote
Old 5th November 2013, 01:38   #85  |  Link
pieter3d
Registered User
 
Join Date: Jan 2013
Location: Santa Clara CA
Posts: 114
Note that Main10 profile allows chroma and luma to have separate bits per pixel values, between 8..10 inclusive. So you can have either or both luma/chroma using bitdepths of 9.
pieter3d is offline   Reply With Quote
Old 5th November 2013, 06:55   #86  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,361
Quote:
Originally Posted by pieter3d View Post
Note that Main10 profile allows chroma and luma to have separate bits per pixel values, between 8..10 inclusive. So you can have either or both luma/chroma using bitdepths of 9.
While this feature also existed in H.264, it was not really used by anything and not supported by most of the decoders. I would wager that this will remain the same situation with HEVC.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 5th November 2013, 07:54   #87  |  Link
pieter3d
Registered User
 
Join Date: Jan 2013
Location: Santa Clara CA
Posts: 114
I disagree. While probably it won't be used often, it is part of Main 10 profile, so anyone wishing to build a compliant decoder must support it. I can promise you that all Main10 HW decoders will support it, as part of conformance. Encoders however, probably not unless there is a good special application.
pieter3d is offline   Reply With Quote
Old 5th November 2013, 09:29   #88  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,361
The same thing applies to H.264, yet many decoders didn't handle it, even if they otherwise handled 10-bit decoding - it was just never implemented, because it was never used.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 5th November 2013, 15:23   #89  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Can anyone point me to a link with a 1080p HEVC 30Mbps+ NON-animated (reality) video sample?
I want to compare it with a typical blu ray quality (1080p H.264 30Mbps+).

I want to compare CPU-Load & Picture Quality.

Thanks.

Last edited by James Freeman; 5th November 2013 at 15:26.
James Freeman is offline   Reply With Quote
Old 5th November 2013, 17:04   #90  |  Link
iSunrise
Registered User
 
Join Date: Dec 2008
Posts: 496
Quote:
Originally Posted by James Freeman View Post
...I feel Hollywood will be more concentrated on higher bitrate with 1080p resolution, than UHD with lower bitrate...
Thatīs not how marketing works.
iSunrise is offline   Reply With Quote
Old 5th November 2013, 19:05   #91  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Quote:
Originally Posted by iSunrise View Post
Thatīs not how marketing works.
I can understand that.
4K is alot shinier than HD

What do you think the future of Blu Ray will look like?
James Freeman is offline   Reply With Quote
Old 5th November 2013, 19:28   #92  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,901
Quote:
Originally Posted by James Freeman View Post
What do you think the future of Blu Ray will look like?
Not on-topic for this thread. Please open a new one.
Guest is offline   Reply With Quote
Old 5th November 2013, 21:01   #93  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
Join Date: Jan 2007
Posts: 729
Quote:
Originally Posted by nevcairiel View Post
The same thing applies to H.264, yet many decoders didn't handle it, even if they otherwise handled 10-bit decoding - it was just never implemented, because it was never used.
Well, there were no decoders for High 10 to begin with. There is only CoreAVC and libavcodec and both are software. Also, they probably don't care much about being completely conformant to the whole spec.
mandarinka is offline   Reply With Quote
Old 6th November 2013, 09:05   #94  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,851
Quote:
Originally Posted by James Freeman View Post
Can anyone point me to a link with a 1080p HEVC 30Mbps+ NON-animated (reality) video sample?
The closest lossless source to "reality" I have is "Tears of Steel". I'm just testing an encode of an action cut of one minute, the result may be available today or tomorrow, depending on the speed and resulting bitrate. And due to the efficiency of HEVC, it is not easy to pass the target of 30 Mbps (without padding)...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 6th November 2013, 10:09   #95  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
@LigH

Thank you for the upcoming test video.
A minute of footage will be enough to compare HEVC vs H.264.

Quote:
And due to the efficiency of HEVC, it is not easy to pass the target of 30 Mbps (without padding)...
I have no idea what padding is.
Do you mean HEVC is too efficient so the results are always less than 30Mbps?
If that's the case, its Great!


I thought of a good comparison method.
Visual (SSIM) & File Size:

File Size comparison (same visual quality):
1. x264 encoded to 30Mbps with a resulting X SSIM value.
2. Set HEVC with the same X SSIM value but let it compress to what Bitrate as it wants.

This test is good to compare how much will we able to put into a single defined space, like an optical disc.
For example: How many hours of film will we be able to put into the same size with the same quality.

Visual Comparison (same file size):
1. x264 encoded to 30Mbps with a resulting X SSIM value.
2. HEVC encoded to 30Mbps with a different resulting Y SSIM.

This test is good to visually compare how much better the picture quality will be in the same file size.
James Freeman is offline   Reply With Quote
Old 6th November 2013, 10:35   #96  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,121
I am a bit confused as i havenīt been following H265.

Which encoder is the one i should look at, is it this x265?

And if so, which of them, i see the one linked at first post, and i know the one at Google Source thing?
Or are they the same?

Also, how is it looking, is it still a child to be fed, or is it starting to look like something so to speak?

Thanks
zerowalker is offline   Reply With Quote
Old 6th November 2013, 11:44   #97  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,357
Quote:
Originally Posted by James Freeman View Post
I have no idea what padding is.
When you set the encoder to achieve a target bitrate "X", and the resulting stream has an actual bitrate "less than X", then the encoder may fill the video stream with NULL bytes.

Quote:
Originally Posted by LigH View Post
And due to the efficiency of HEVC, it is not easy to pass the target of 30 Mbps (without padding)...
Correct Still, you could try the following settings:

--- disable B-frames

--- use short GOPs (i.e., more I-frames)

--- use low quantizers (18 or even less)

HTH
filler56789 is offline   Reply With Quote
Old 6th November 2013, 11:53   #98  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,851
Well, yes, it is possible to get quite high bitrates locally. Limiting the encoding efficiency will reduce the required decoding efforts as well, though, therefore I'm trying to create a rather complex video with longer GOPs, severe referencing, and still high bitrates; so the only way to achieve that is a low quantization. CRF 12 appears to be promising... more later.

To keep the bitrate in a closer range, x265 would require a VBV like regulation, though.

And yes, stuffing would mean to fill up the video with non-bitstream junk just to keep the brutto bitrate rather constant; the only known use (to me) for this waste would be DVB bouquets, and maybe optical disk material to avoid buffer overflows.
__________________

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

Last edited by LigH; 6th November 2013 at 11:56.
LigH is offline   Reply With Quote
Old 6th November 2013, 14:43   #99  |  Link
Kurtnoise
Swallowed in the Sea
 
Kurtnoise's Avatar
 
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
Does anybody confirm that the latest x265 builds (with the latest commits from today) are broken using the pipeline ?

I tested my own builds and the ones from x265.cc, all fail...at least with yuv.

Last edited by Kurtnoise; 6th November 2013 at 14:51.
Kurtnoise is offline   Reply With Quote
Old 6th November 2013, 16:36   #100  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,851
Version 0.5+153 (VC12 x86-64) works in general with Y4M file input, but produces artefacts with a complex command line:

Code:
-F 3 -q 23 -b 3 --b-adapt 2 --bframe-bias 30 -w --ref 3 -i 240 --psnr --ssim --rdpenalty 1 --aq-mode 1
Same for piping Y4M via avs2yuv: Works in general, but produces artefacts.

Same for piping raw YUV i420 via avs2yuv: Works in general, but produces artefacts.
__

Hmm. Different command line option set, no artefacts...

Code:
--preset slower --crf 24 -F 6 -w --bframe-bias 30 -i 240 --rdpenalty 1 --aq-mode 1
__________________

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

Last edited by LigH; 6th November 2013 at 17:06.
LigH 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 04:34.


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