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 16th February 2020, 21:31   #1  |  Link
Marsu42
Huba Huba
 
Marsu42's Avatar
 
Join Date: Aug 2005
Location: Palumbian Jungle
Posts: 63
AVC to HEVC transcoding advice for low bitrate sources

I'm currently trancoding a video archive to save space. The videos are AVC with vastly different bitrates from 1.5 to 15 MBps, usually with little motion.

With my former, extremely old PC (Core1 Quad) using x265 was a no-go. With my more currrent PC (Haswell Dual) I could switch if there is a clear advantage. Yes, I know, your boxes are waaaaaaaay faster.

I'm downsizing to 720p to save some further space and because my usual monitor isn't full hd anyway.

=> QUESTION: Is there a low source bitrate threshold like 3-5 MBps that could result in _worse_ transcoding quality AVC=>HEVC than AVC=>AVC? Or is HEVC encoding too similar to AVC so it doesn't make a difference? Or does HEVC result in significantly enhanced quality in transcoding in any case?

I'm thinking of the different artifact types, which is why transcoding different image formats like dct-jpeg and wavelet-jpeg2000 isn't a good idea with low quality sources.
__________________
"The innocent have nothing to fear" :stupid:

Last edited by Marsu42; 17th February 2020 at 01:01. Reason: typo
Marsu42 is offline   Reply With Quote
Old 19th February 2020, 13:39   #2  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,507
If you need to save space, you need to save space. If you're very concerned about transcoding artifacts, you should get a cheap 6TB drive and just offload all the things you'll rarely want to watch.

That said, although 1.5 MBps is pretty close to the limit of watchable quality h.264 1080p and 15MBps is way overkill for my tastes, if you're going to downsample it to 720p and put everything at an even ~1MBps, you won't get much better results with HEVC than AVC, unless you have a high tolerance for blur. At that point you pick your poison, and it might come down to the codec you have a hardware decoder for on every device. There's no easy threshold where x265 gets better or worse than x264, but there are definitely times when you have to pick what you sacrifice as you pile on the bit pressure. Overall, x264 is tuned by default for a noisier, sharper picture. x265 is tuned by default for softer, smaller pictures. You can get in deep to adjust either one, but if you're going to crank out a bunch of 720p vids, it'd be easier to decide what you like up-front and just go with that.
__________________
There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order.
foxyshadis is offline   Reply With Quote
Old 19th February 2020, 17:10   #3  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Germany
Posts: 961
Quote:
Originally Posted by Marsu42 View Post
=> QUESTION: Is there a low source bitrate threshold like 3-5 MBps that could result in _worse_ transcoding quality AVC=>HEVC than AVC=>AVC? Or is HEVC encoding too similar to AVC so it doesn't make a difference?
I'm thinking of the different artifact types, which is why transcoding different image formats like dct-jpeg and wavelet-jpeg2000 isn't a good idea with low quality sources.
I got what you mean, but most of the time it's not a matter of codecs, it's a matter of transform.
The reason you get way worse result if you encode an image in JPEG first and then JPEG2000 is that JPEG uses the Discrete Cosine Transform while JPEG2000 uses the Wavelet Transform, so you'll end up with the worse of them both. Anyway, in case of H.264 and HEVC, the Transforms are quite similar: DCT and Hadamard for H.264, DCT and DST for H.265 HEVC, so you won't notice an added detail loss caused by the math behind it if you use H.265 instead of H.264 or vice-versa but you will see the one introduced by the fact that you're making the lossy of the lossy, so quantization etc (i.e you're gonna lose something anyway no matter what). The thing is that linear algebra wise, though, you're fine; I hope that answers your question.

Last edited by FranceBB; 19th February 2020 at 17:17.
FranceBB is offline   Reply With Quote
Old 4th June 2020, 15:22   #4  |  Link
burnix
Registered User
 
Join Date: Jan 2003
Posts: 44
If you have to re-encode to save space and all video are similar content just use x265 (not intel qsv) in crf mode. You can obtain some good result.

Or for a few bucks just buy a nvidia 1050 card and use ffmpeg + nvenc + vbrhq 800kbps. For 720p that ok.

I use ffmpeg + nvenc + vbrhq 900kbps on hdtv recording (i let in 1920*1080) and on 42' screen is was ok (some block on ultra move scene)
burnix is offline   Reply With Quote
Old 4th June 2020, 18:36   #5  |  Link
RanmaCanada
Registered User
 
Join Date: May 2009
Posts: 156
Quote:
Originally Posted by burnix View Post
If you have to re-encode to save space and all video are similar content just use x265 (not intel qsv) in crf mode. You can obtain some good result.

Or for a few bucks just buy a nvidia 1050 card and use ffmpeg + nvenc + vbrhq 800kbps. For 720p that ok.

I use ffmpeg + nvenc + vbrhq 900kbps on hdtv recording (i let in 1920*1080) and on 42' screen is was ok (some block on ultra move scene)
Instead they should get a Turing based card as it has B frame support. Also a more updated encode engine. I believe a 1660 is the bare minimum.

https://developer.nvidia.com/video-e...support-matrix
RanmaCanada 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 03:09.


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