Problem transcoding when source file is h.265

[muzicman0 84]

@cayarsThe newer RTX line of Nvidia has some serious upgrades specifically for HEVC encoding.  You can go as low as a GTX 1660 (NOT the 1650), or any of the RTX line, and you will get better encodes.

You will want a Turing family chip (but again, not the 1650, even though it does have the Turing, it has the old h.265 encoder).

https://developer.nvidia.com/video-encode-decode-gpu-support-matrix

[Carlo 4560]

Funny, I was thinking the GTX 1660 (Turing) but was wondering if QuickSync might be better or worse?

Any experience between the two?

[muzicman0 84]

The company i work for has stopped supporting quick sync,  not because of quality,  but stability and speed. No personal experience outside of work though. 

[PenkethBoy 2068]

@cayars Yep a 1660 or newer 20 series would be what i would look at as @muzicman0 suggested

[PenkethBoy 2068]

14 hours ago, muzicman0 said:

@PenkethBoy, have you figured out a decent way on your Nvidia encodes to get dark scenes to not have banding?  I have really good quality, other than mostly dark/black scenes.

I dont appear to have that problem - what are you using to encode?

could you give a screenshot of what you mean?

[Happy2Play 9780]

Was wondering why this topic stayed unread. Deleted multiple dups.

[muzicman0 84]

17 minutes ago, PenkethBoy said:

I dont appear to have that problem - what are you using to encode?

could you give a screenshot of what you mean?

Well...I didn't think it would be that hard to get a screenshot...but now that I am looking, I can't see it.  Maybe it was happening before I updated the FFMPEG command I use...who knows.  However, just in case anyone has any improvements to be made, here is my CLI that I use for TV episodes:

ffmpeg.exe -ss 00:00:10 -y -i "\\10.3.0.124\rtv\Stargirl\DC's-Stargirl.Stars-&-S.T.R.I.P.E.-Part-One-S01E12.ts" -vf yadif=0:-1:0 -c:v hevc_nvenc -rc:v constqp -qp 23 -preset slow -rc-lookahead 32 -g 600 -c:a copy "T:\TV\Stargirl\Season 01\Stargirl - S01E12 - Stars & S.T.R.I.P.E. (1).mp4"

Really the only time I see any issues is in some fast moving scenes.  Overall though, it get's good quality.  I've thought about lowering the GOP to see if that helps, but haven't gotten around to trying it yet.

I get just a bit over 5x native speed with this, so a 1 hour show takes ~10-12 minutes to encode using the Nvidia GTX 1660.

[PenkethBoy 2068]

Mine is similar

From one of my scripts

$ArgumentList = '-hide_banner -loglevel +level -hwaccel_device 0 -hwaccel d3d11va -i "{0}" -vf yadif -map 0:v:0 -c:v:0 hevc_nvenc -preset {2} -qp 25 -level 5.1 -tier high -map 0:a -c:a copy -map 0:s? -c:s copy -map_chapters 0 -map_metadata 0 "{1}"' -f $oldVideo, $newVideo, $GPUPreset

where $oldvideo is mapped to {0}
$newvideo is mapped to {1}
and
$gpupreset is mapped to {2} - i tend to use medium rather than slow

-hwaccel_device 0 -hwaccel d3d11va - give HW decoding (on windows) with gpu 0 - might be "1" if you have two gpus in a machine

and i use a slightly less aggresive -qp of 25

Map_chapters and map_metadata with "0" maintian these if they exist

-map 0:s? means copy sub tracks if they exist in the file

The $argumentlist is then passed to ffmpeg

with the above i get for 1080p episodes x8 on my 980ti - would have expected faster with the 1660 - but we would need to test the same file (as input quality also matters) to see if its just the different in options that makes the big difference - as i suspect it might be the qp value and the gpupreset that makes yours a bit slower

Edited September 3, 2020 by PenkethBoy

[PenkethBoy 2068]

1 hour ago, Happy2Play said:

Was wondering why this topic stayed unread. Deleted multiple dups.

yep was having an issue with posting after i had quoted a post - thanks for deleting those

[Carlo 4560]

1 hour ago, muzicman0 said:

I get just a bit over 5x native speed with this, so a 1 hour show takes ~10-12 minutes to encode using the Nvidia GTX 1660.

Is that a Ti model or just normal 1660?

[muzicman0 84]

normal 1660.

[muzicman0 84]

31 minutes ago, PenkethBoy said:

Mine is similar

From one of my scripts

$ArgumentList = '-hide_banner -loglevel +level -hwaccel_device 0 -hwaccel d3d11va -i "{0}" -vf yadif -map 0:v:0 -c:v:0 hevc_nvenc -preset {2} -qp 25 -level 5.1 -tier high -map 0:a -c:a copy -map 0:s? -c:s copy -map_chapters 0 -map_metadata 0 "{1}"' -f $oldVideo, $newVideo, $GPUPreset

where $oldvideo is mapped to {0}
$newvideo is mapped to {1}
and
$gpupreset is mapped to {2} - i tend to use medium rather than slow

-hwaccel_device 0 -hwaccel d3d11va - give HW decoding (on windows) with gpu 0 - might be "1" if you have two gpus in a machine

and i use a slightly less aggresive -qp of 25

Map_chapters and map_metadata with "0" maintian these if they exist

-map 0:s? means copy sub tracks if they exist in the file

The $argumentlist is then passed to ffmpeg

with the above i get for 1080p episodes x8 on my 980ti - would have expected faster with the 1660 - but we would need to test the same file (as input quality also matters) to see if its just the different in options that makes the big difference - as i suspect it might be the qp value and the gpupreset that makes yours a bit slower

I have been trying to get hwaccel working on decoding for my ffmpeg stream, I incorporated what you had, and it worked, so thanks for that!  It didn't improve speed though.  Although, the speed difference is probably medium preset vs slow.  I did a quick benchmark comparison online, and the 980 vs the 1660 are very similar in speed.

 

[PenkethBoy 2068]

@muzicman0

As i was curious i have just done a few simple tests on one file

original file 53 mins long 1080p 23.98fps - bit rate 8608 kb/s - file size 3.19GB - h264

1) using qp 25 and gpu preset of medium - took approx 00:06:54 at x7+ - file size 1.2GB - bit rate 3250 kb/s - i.e my normal settings

2) using qp 23 and gpu preset of slow - took approx 00:06:58 at 7x+ file size 1.55GB bit rate 4184 kb/s - your settings

3) using qp 25 and gpu preset of slow - took approx 00:06:54 at 7+x file size 1.2GB bit rate 3250 kb/s - for comparison with 1) - so same result as medium - hmmmm

4) using qp 25 and preset fast - took approx 00:05:31 at 9+x file size 1.19GB bit rate 3125 kb/s - for comparison with 1) 

5) using qp 30 and preset medium - took approx 00:06:08 at 8+x file size 617MB bit rate 1624 kb/s - qp 30 is more aggressive than 25 at reducing the bit rate (i edited my previous post as i had it wrong) - just checked and this re encode is still fine - no obvious artifacts from a quick watch

So it appears that qp has more effect than the gpu preset - which does not appear to change anything much for slow and medium - maybe they have more effect on higher bit rate files or if the gpu is fast enough we dont see much effect?

Gpu preset fast does the re encode quicker with minimal changes to bit rate - i think this is why i just went with medium from my testing a couple of years ago

Note - I did not bother looking at the quality of each file in these quick tests - which might have an affect on any choice someone would make for the options

[PenkethBoy 2068]

49 minutes ago, muzicman0 said:

I have been trying to get hwaccel working on decoding for my ffmpeg stream, I incorporated what you had, and it worked, so thanks for that!  It didn't improve speed though.  Although, the speed difference is probably medium preset vs slow.  I did a quick benchmark comparison online, and the 980 vs the 1660 are very similar in speed.

 

did you compare the 980 or the 980TI - which is a bit (10%?) quicker than the 980

[Carlo 4560]

28 minutes ago, PenkethBoy said:

did you compare the 980 or the 980TI - which is a bit (10%?) quicker than the 980

1660 has B-frame support and the 980 doesn't correct?

[PenkethBoy 2068]

no idea never looked

[muzicman0 84]

35 minutes ago, PenkethBoy said:

@muzicman0

As i was curious i have just done a few simple tests on one file

original file 53 mins long 1080p 23.98fps - bit rate 8608 kb/s - file size 3.19GB - h264

1) using qp 25 and gpu preset of medium - took approx 00:06:54 at x7+ - file size 1.2GB - bit rate 3250 kb/s - i.e my normal settings

2) using qp 23 and gpu preset of slow - took approx 00:06:58 at 7x+ file size 1.55GB bit rate 4184 kb/s - your settings

3) using qp 25 and gpu preset of slow - took approx 00:06:54 at 7+x file size 1.2GB bit rate 3250 kb/s - for comparison with 1) - so same result as medium - hmmmm

4) using qp 25 and preset fast - took approx 00:05:31 at 9+x file size 1.19GB bit rate 3125 kb/s - for comparison with 1) 

5) using qp 30 and preset medium - took approx 00:06:08 at 8+x file size 617MB bit rate 1624 kb/s - qp 30 is more aggressive than 25 at reducing the bit rate (i edited my previous post as i had it wrong) - just checked and this re encode is still fine - no obvious artifacts from a quick watch

So it appears that qp has more effect than the gpu preset - which does not appear to change anything much for slow and medium - maybe they have more effect on higher bit rate files or if the gpu is fast enough we dont see much effect?

Gpu preset fast does the re encode quicker with minimal changes to bit rate - i think this is why i just went with medium from my testing a couple of years ago

Note - I did not bother looking at the quality of each file in these quick tests - which might have an affect on any choice someone would make for the options

qp making a difference completely makes sense to me.  I think either I tried without the preset and it didn't work, or someone said online that it was required...either way, I would think qp would override any preset setting...

34 minutes ago, PenkethBoy said:

did you compare the 980 or the 980TI - which is a bit (10%?) quicker than the 980

just the 980.

[PenkethBoy 2068]

29 minutes ago, muzicman0 said:

 qp would override any preset setting...

i think the preset still works as the fast preset did have an effect in reducing the time

[muzicman0 84]

I was wrong...the hwacel still didn't work.  it produced only audio on my system for some reason.

[PenkethBoy 2068]

are your nvidia driver up to date - have had issues with some versions in the past

i'm using 452.06 and 442.74 work ok before i updated recently

Edited September 3, 2020 by PenkethBoy

[muzicman0 84]

451.67, so certainly not old by any stretch.  Not sure if it is the absolute latest though.  

 

This would be representative of what I tried:

ffmpeg.exe -ss 00:00:10 -y -hwaccel_device 0 -hwaccel d3d11va -i "\\10.3.0.124\rtv\Stargirl\DC's-Stargirl.Stars-&-S.T.R.I.P.E.-Part-One-S01E12.ts" -vf yadif=0:-1:0 -c:v hevc_nvenc -rc:v constqp -qp 23 -preset slow -rc-lookahead 32 -g 600 -c:a copy "T:\TV\Stargirl\Season 01\Stargirl - S01E12 - Stars & S.T.R.I.P.E. (1).mp4"

 

Edited September 3, 2020 by muzicman0
additional info

[PenkethBoy 2068]

have you tried a non ts file as a test?

how old is your ffmpeg is it recent also?

[muzicman0 84]

1 minute ago, PenkethBoy said:

have you tried a non ts file as a test?

how old is your ffmpeg is it recent also?

no, I haven't tried anything other than ts files.

not sure what version ffmpeg is, but I just updated in early May.  So I believe it is fairly new.

It's not a big deal, more of a nice to have.

[PenkethBoy 2068]

ok - fine

one thing i would do though is update your command line with

-map 0:v:0 -c:v:0

and 

-map 0:a -c:a copy -map 0:s? -c:s copy

that will ensure that more than one video/audio channel will get copied and if IIRC if they are in a funky order as TS files are very variable  in quality, things are more robust and will cover edge cases more