H265 way faster than MP4 normal

General Support / Questions
1

Thanks to @Will_Tschumy (see below for link), there is an excellent post regarding the setup of an H265 constant quality profile.

I just ran a few side-by-side tests (one at a time) with the same source TS files.

In general, the H265 jobs converted three times faster than the same MP4 jobs. Additionally, the size of the H265s are nearly 50% smaller than the MP4 equivalents.

This shows how little I know. I would have assumed the exact opposite. But now, I’m trying to figure out if there’s any reason NOT to standardize on H265. So far playback is fine, subtitles are fine, etc. So far … no red flags…

H265 Constant Quality Profile post

At the moment, this appears to be a fortunate discussion topic to find.

BrianGGG

2 Likes
2

That’s very interesting, are both using hardware acceleration?

3

To my untrained eye, yes. Both were using Hardware encoding.
I have attached the logfiles of an identical conversion with the two profiles if you are able to take a quick look.

log.zip (2.2 MB)

On an unrelated note, having so many of the following lines in a DEBUG logfile is really a killer for space and useability. Is that worth a FEATURE request?

2018-02-14T04:52:34 MCEBuddy.AppWrapper.MencoderCropDetect

1 Like
4

Yep they’re close in terms of conversion parameters, the only significant difference is that the mp4 version had an extra filter (hqdn3d) and few other x264 options in the profile that denoises the video and that the final bitrate was about 4Mbps vs 2.4 for the hevc.

Just for a perfect comparison of mpeg4 vs hevc, in your H265 profile change hevc_nvenc to h264_nvenc and keep the rest the same. Now test it and it will give a perfect comparison of the speed of a hevc vs mpeg4 with a nvidia cuda encoder.

5

With the change you suggested above, timings for 264 vs 265 were nearly identical.

If it’s straightforward, can you briefly explain what is holding back the MP4 profile (e.g. why are the additional might or might not be necessary)?

6

Sure, it the set of options being used for encoding. The MP4 profile using a bunch of filters and other enhanced encoding options (I’ve highlighted them below)

ffmpeg-video=-ss 3 -vf yadif=0:-1:1,hqdn3d -vcodec libx264 -b 1400k -x264opts me=hex:trellis=1:subq=8:partitions=all:8x8dct=1:ref=3:rc-lookahead=50:keyint=25:min-keyint=20:bframes=1:weightb=1:level=4.0:b-pyramid=normal:direct=auto:mixed-refs=1:deblock=-1,-1:no-fast-pskip=1:no-dct-decimate=1:b-adapt=0:threads=auto -map 0:v -sn

These are designed to provide the best possible quality and a reasonable small file (determined by the bitrate 1.4Mbps). Hence it’s a slower in encoding but you should get a better quality picture that just a straight forward constant quantizer. You can google the options or see the ffmpeg page to get more details on it (same goes for other encoders also like handbrake and mencoder).

Encoding is always about tradeoff between speed, size and quality and there are many many ways to control those tradeoffs between bitrate, filters and encoding parameters. The bigger the file (higher bitrate) the better the quality, the faster the encoding the lower the quality (generally) - you get the point.

Try this, run the MP4 Normal profile with hardware encoding and then run the MP4 Fast profile with hardware encoding and see the difference. The Fast should be faster because it was fewer other quality control filters and settings.

Having said that if your encoder is taking the same time to encode h265 and h264, all else being the same, that’s awesome because h265 generally produced a much better quality picture at a given bitrate/size. So that’s still the clear winner.

7

One other item that may be related to this.

I noticed today that:
When I use the MP4 profile, my GPU never gets above 20% during FFMPEG encoding
When I use the H265 profile, my GPU goes to 60% and sometimes 70% for FFMPEG

Is there possibly something going on with threading in H265 that is not going on in MP4?
I tried and failed to determine this myself so I am posting the two profiles below. Is there anything in the two profiles below that might drive this behavior?

thanks
BrianGGG

[MKV HVEC Constant Quality]
Description=WARNING: Constant Quality encoding (25) with Nvidia HVEC.
order=ffmpeg, handbrake
AllowH264CopyRemuxing=true
FixedResolution=true
AutoDeinterlace=true
ffmpeg-UsingHardwareEncoding=True
ffmpeg-general=-threads 0 -hwaccel auto
ffmpeg-video=-ss 3 -c:v hevc_nvenc -cq 23 -rc vbr -map 0:v
ffmpeg-audio=-acodec ac3 -ab 192k -map 0:a
ffmpeg-audioac3=-acodec ac3 -ab 384k -map 0:a
ffmpeg-ext=.mkv
ffmpeg-audiodelay=skip
handbrake-UsingHardwareEncoding=true
handbrake-general=–decomb --denoise=“weak” --loose-anamorphic --verbose=2 -T -O
handbrake-video=–start-at duration:3 -e x265 -q 18
handbrake-audio=-E ffac3 -R auto -B 192 -D 0 -a 1,2,3,4,5
handbrake-audioac3=-E ffac3 -R auto -B 384 -D 0 -a 1,2,3,4,5
handbrake-ext=.mkv
handbrake-audiodelay=skip
PreConversionCommercialRemover=true

[MP4 Normal]
Description=Main profile, good quality 1 pass MP4 (H.264/AAC) conversion. Good for most conversions, produces good results and is faster than the two pass conversion.
order=ffmpeg,mencoder,handbrake
mencoder-general=-ss 3 -vf pullup,softskip,yadif=0:-1,hqdn3d,harddup
mencoder-video=-ovc x264 -x264encopts bitrate=1400:me=hex:trellis=1:subq=8:partitions=all:8x8dct:ref=3:rc_lookahead=50:keyint=25:keyint_min=20:bframes=1:weight_b:level_idc=40:b_pyramid=normal:direct_pred=auto:mixed_refs:deblock=-1,-1:nofast_pskip:nodct_decimate:b_adapt=0:threads=auto
mencoder-audio=-oac faac -faacopts br=160:mpeg=4:tns:object=2
mencoder-audioac3=-oac faac -faacopts br=256:mpeg=4:tns:object=2
mencoder-ext=.avi
mencoder-remuxto=.mp4
mencoder-audiodelay=skip
ffmpeg-general=-threads 0
ffmpeg-video=-ss 3 -vf yadif=0:-1:1,hqdn3d -vcodec libx264 -b 1400k -x264opts me=hex:trellis=1:subq=8:partitions=all:8x8dct=1:ref=3:rc-lookahead=50:keyint=25:min-keyint=20:bframes=1:weightb=1:level=4.0:b-pyramid=normal:direct=auto:mixed-refs=1:deblock=-1,-1:no-fast-pskip=1:no-dct-decimate=1:b-adapt=0:threads=auto -map 0:v -sn
ffmpeg-audio=-acodec libfdk_aac -ab 160k -cutoff 18000 -map 0:a
ffmpeg-audioac3=-acodec libfdk_aac -ab 256k -cutoff 18000 -map 0:a
ffmpeg-ext=.mp4
ffmpeg-audiodelay=skip
handbrake-general=–decomb --loose-anamorphic --verbose=2 -f mp4 -O
handbrake-video=–start-at duration:3 -e x264 -b 1400 -x me=hex:trellis=1:subq=8:partitions=all:8x8dct:ref=3:rc-lookahead=50:keyint=25:keyint-min=20:bframes=1:weight-b:level-idc=40:b-pyramid=normal:direct-pred=auto:mixed-refs:deblock=-1,-1:nofast-pskip:nodct-decimate:b-adapt=0:threads=auto
handbrake-audio=-E faac -R auto -B 160 -D 0 -a 1,2,3,4,5
handbrake-audioac3=-E faac -R auto -B 256 -D 0 -a 1,2,3,4,5
handbrake-ext=.mp4
handbrake-audiodelay=skip
PreConversionCommercialRemover=true

8

There could be many reasons, e.g. some of the filters being used in the MP4 profile for denoise and other advanced parameters may not be supported by the GPU and hence may run on CPU. Encoding modes (constant bitrate vs constant quantizer) have different abilities with different GPU, some are more efficient.

Maybe you can run a test for us with different modes in your MKV profile (e.g. instead of -cq 23 use -b:v 1400) and let us know how the GPU fares.

How does your GPU fare if you run your MKV profile and change hevc_nvenc to h264_nvenc? That would be a good comparison of the cards h264 encoding capabilities vs hevc.

9

First test is done. H264 behavior is similar to H265. There is no problem getting over 20% GPU with this provile.
I’ll adjust the H265 as above for the next test soon.

10

I’ve searched and can’t seem to find a definitive answer to this question, so I thought I’d post it here since we’re discussing h265 hardware encoding.
What GPU should I get if I want to do this?
I’ve read many places that hardware encoding (via nvidia) results in poor quality video, is this still the case? Many of the posts I read were quite old.
Also, since I’m running a plex server, i’d love the GPU I choose to be able to use hardware transcoding too…

Thanks in advance for any help.

  • Cguy
11

tagging @Will_Tschumy @NYPLAYER @BrianGGG

12

That’s nonsense - I’ve used both AMD and NVidia cards. The only difference I’ve seen is speed - NVidia cards are faster for the same quality (both from a setting and perceptual perspective). The 1060 is a great value for the money / power. I don’t think you’ll go wrong with either choice but I’ve had better success with NVidia. Good luck!

via
Newton Mail

1 Like
13

Thanks so much Will. That should save me a lot of headaches.