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 > MPEG-4 Encoder GUIs

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 8th January 2020, 03:34   #1301  |  Link
frenchfries
Registered User
 
Join Date: Jan 2010
Posts: 27
Quote:
Originally Posted by ukmark View Post
Thanks for your reply. I'm referring specifically to the "LA-ICQ" mode that is available for QSV H264 (along with 2 other "LA" modes - "LA" and "LA-HRD" ).

With QSV HEVC there are no such "LA" modes. Wouldn't the encoder just ignore the "la-quality" and "la-window-size" options when using "ICQ" for QSV HEVC?

My best guess is that these settings would be 'activated' when using the "LA" modes for QSV H264 but 'ignored' for QSV HEVC?? I'll try your settings, run a quick test and look in the StaxRip log to see if these 2 "la" settings are mentioned when using QSV H264 and QSV HEVC.

EDIT: Just did a quick test on a very short clip using these 2 "la" settings ("la-quality slow" and "la-window-size 15"). I noticed that when choosing "LA-ICQ" for QSV H264 an extra setting appeared in the "Slice Decision" settings in the StaxRip GUI that is not shown when choosing "ICQ" for QSV HEVC - namely "Lookahead Depth". Also in the StaxRip log for "LA-ICQ" QSV H264 I see the following section where it mentions the "Lookahead" settings for depth and quality (but not window size), but this line is not present when using "ICQ" QSV HEVC. This would lead me to believe that QSV HEVC has not (yet) implemented "lookahead".

From StaxRip QSV encoding log:-
Output H.264/AVC High @ Level 4
1280x720p 1:1 23.976fps (24000/1001fps)
Target usage 1 - best
Encode Mode LA-ICQ (Intelligent Const. Quality with Lookahead)
Lookahead depth 30 frames, quality slow <------- This line does not appear when using QSV HEVC ICQ settings with "la-quality slow" and "la-window-size 15".

I find that QSV HEVC ICQ is very good and just wish the LA-ICQ was implemented for HEVC as it is with H264. It may give that extra bit of quality (at similar bitrates to x265) that would make me switch from CPU software encoding to GPU hardware encoding (I notice the difference between the two mainly in dark scenes). I'm tempted to get a 10th gen Ice Lake laptop as Intel have touted some big improvements for QuickSync - but I'll wait until we get more info as time goes by. I'm hoping in a few more Intel 'generations' that GPU encoding could become the norm (due to competition from Ryzen, NVidia and from consumer demand etc).
Thanks for clarifying. The LA mode for H265 definitely doesn't exist. Disregard all I said about that. I actually knew this but clearly forgot :/

You can see it in a trimmed --check-features i just ran
Code:
Codec: HEVC
             CBR   VBR   AVBR  QVBR  CQP   LA    LAHRD ICQ   LAICQ VCM
RC mode       o     o     x     x     o     x     x     o     x     o
10bit depth   o     o     x     x     o     x     x     o     x     o
Fixed Func    x     x     x     x     x     x     x     x     x     x
Interlace     x     x     x     x     o     x     x     x     x     x
VUI info      o     o     x     x     o     x     x     o     x     o
Trellis       x     x     x     x     x     x     x     x     x     x
Adaptive_I    x     x     x     x     x     x     x     x     x     x
Adaptive_B    x     x     x     x     x     x     x     x     x     x
WeightP       o     o     x     x     o     x     x     o     x     o
WeightB       o     o     x     x     o     x     x     o     x     o
FadeDetect    x     x     x     x     x     x     x     x     x     x
B_Pyramid     o     o     x     x     o     x     x     o     x     o
 +ManyBframes o     o     x     x     o     x     x     o     x     o
PyramQPOffset x     x     x     x     o     x     x     x     x     x
MBBRC         o     o     x     x     x     x     x     o     x     o
ExtBRC        o     o     x     x     x     x     x     x     x     x
Adaptive_LTR  x     x     x     x     x     x     x     x     x     x
LA Quality    x     x     x     x     x     x     x     x     x     x
QP Min/Max    x     x     x     x     x     x     x     x     x     x
IntraRefresh  o     o     x     x     o     x     x     o     x     o
No Deblock    o     o     x     x     o     x     x     o     x     o
No GPB        o     o     x     x     o     x     x     o     x     o
Windowed BRC  x     x     x     x     x     x     x     x     x     x
PerMBQP(CQP)  o     o     x     x     x     x     x     o     x     o
DirectBiasAdj x     x     x     x     x     x     x     x     x     x
MVCostScaling x     x     x     x     x     x     x     x     x     x
SAO           x     x     x     x     x     x     x     x     x     x
Max CTU Size  x     x     x     x     x     x     x     x     x     x
TSkip         x     x     x     x     x     x     x     x     x     x
That being said, I'm surprised you see it as lower quality output then with X265 as I see the reverse using the settings i previously posted and with X265 with little tuning using a CRF of 18 and slower.

Quicksync seems to finish in around 4 hours or so with a smaller file size and subjectively better quality using stax's video compare tool, than X265 which takes a couple of days.

I only have access to 24 threads at home so maybe more oomph is required but TBH that's too power prohibitive for me.
frenchfries is offline  
Old 8th January 2020, 11:43   #1302  |  Link
ukmark
Registered User
 
Join Date: Oct 2018
Posts: 33
Quote:
Originally Posted by frenchfries View Post
Thanks for clarifying. The LA mode for H265 definitely doesn't exist. Disregard all I said about that. I actually knew this but clearly forgot :/

You can see it in a trimmed --check-features i just ran
Code:
Codec: HEVC
             CBR   VBR   AVBR  QVBR  CQP   LA    LAHRD ICQ   LAICQ VCM
RC mode       o     o     x     x     o     x     x     o     x     o
10bit depth   o     o     x     x     o     x     x     o     x     o
Fixed Func    x     x     x     x     x     x     x     x     x     x
Interlace     x     x     x     x     o     x     x     x     x     x
VUI info      o     o     x     x     o     x     x     o     x     o
Trellis       x     x     x     x     x     x     x     x     x     x
Adaptive_I    x     x     x     x     x     x     x     x     x     x
Adaptive_B    x     x     x     x     x     x     x     x     x     x
WeightP       o     o     x     x     o     x     x     o     x     o
WeightB       o     o     x     x     o     x     x     o     x     o
FadeDetect    x     x     x     x     x     x     x     x     x     x
B_Pyramid     o     o     x     x     o     x     x     o     x     o
 +ManyBframes o     o     x     x     o     x     x     o     x     o
PyramQPOffset x     x     x     x     o     x     x     x     x     x
MBBRC         o     o     x     x     x     x     x     o     x     o
ExtBRC        o     o     x     x     x     x     x     x     x     x
Adaptive_LTR  x     x     x     x     x     x     x     x     x     x
LA Quality    x     x     x     x     x     x     x     x     x     x
QP Min/Max    x     x     x     x     x     x     x     x     x     x
IntraRefresh  o     o     x     x     o     x     x     o     x     o
No Deblock    o     o     x     x     o     x     x     o     x     o
No GPB        o     o     x     x     o     x     x     o     x     o
Windowed BRC  x     x     x     x     x     x     x     x     x     x
PerMBQP(CQP)  o     o     x     x     x     x     x     o     x     o
DirectBiasAdj x     x     x     x     x     x     x     x     x     x
MVCostScaling x     x     x     x     x     x     x     x     x     x
SAO           x     x     x     x     x     x     x     x     x     x
Max CTU Size  x     x     x     x     x     x     x     x     x     x
TSkip         x     x     x     x     x     x     x     x     x     x
That being said, I'm surprised you see it as lower quality output then with X265 as I see the reverse using the settings i previously posted and with X265 with little tuning using a CRF of 18 and slower.

Quicksync seems to finish in around 4 hours or so with a smaller file size and subjectively better quality using stax's video compare tool, than X265 which takes a couple of days.

I only have access to 24 threads at home so maybe more oomph is required but TBH that's too power prohibitive for me.
Thanks. I just tried your settings. For x265 I usually have 720p 10bit HEVC, CRF 24 and AQ-Mode 3, preset Medium as the extra settings - this gives me very good quality. Maybe with an ICQ of 17 vs x265 CRF 18, the bit rates are increased enough to the point where QSV is at least as good as x265 - I just find that CRF24 for x265 gives me very good quality and was hoping that ICQ 24 would do the same at similar bit rates - and it does in all but darker scenes.

I did try comparing an encode with your settings using ICQ 24 (= CRF 24??) and although the QSV was very good, it did lose some definition in the darker muddier scenes. In the brighter scenes it was as good as x265 and encoded about 6x faster. I'm checking the output using my laptop and getting very close to the screen - I would think that normal viewing on a TV would probably not show a difference - but I'm picky about dark scenes

I might try lowering the ICQ to see where the dark scenes match the quality of x265 and then see what the final bit rates are. I don't mind QSV being larger file size but I don't want it to be double the size of x265. I probably only encode about 3 times per week, so speed is not that important to me - but I am seeing that QSV is getting close to x265 at my CRF of 24.

Last edited by ukmark; 8th January 2020 at 13:34.
ukmark is offline  
Old 11th January 2020, 02:43   #1303  |  Link
frenchfries
Registered User
 
Join Date: Jan 2010
Posts: 27
Quote:
Originally Posted by ukmark View Post
Thanks. I just tried your settings. For x265 I usually have 720p 10bit HEVC, CRF 24 and AQ-Mode 3, preset Medium as the extra settings - this gives me very good quality. Maybe with an ICQ of 17 vs x265 CRF 18, the bit rates are increased enough to the point where QSV is at least as good as x265 - I just find that CRF24 for x265 gives me very good quality and was hoping that ICQ 24 would do the same at similar bit rates - and it does in all but darker scenes.

I did try comparing an encode with your settings using ICQ 24 (= CRF 24??) and although the QSV was very good, it did lose some definition in the darker muddier scenes. In the brighter scenes it was as good as x265 and encoded about 6x faster. I'm checking the output using my laptop and getting very close to the screen - I would think that normal viewing on a TV would probably not show a difference - but I'm picky about dark scenes

I might try lowering the ICQ to see where the dark scenes match the quality of x265 and then see what the final bit rates are. I don't mind QSV being larger file size but I don't want it to be double the size of x265. I probably only encode about 3 times per week, so speed is not that important to me - but I am seeing that QSV is getting close to x265 at my CRF of 24.
Try messing with the amount of ref frames and b frames. That's where the smaller file sizes come into it. I've tested considerably higher amounts of both before with only a small performance decrease but diminishing returns kicks in and it doesn't get much smaller.

What profile in QSV are you using? eg. fastest or best

Interesting that you don't seem happy with dark scenes. That's where i do a lot of my subjective analysis as it's the most obvious to compare but my results are the opposite, at least with the settings I use.
frenchfries is offline  
Old 12th January 2020, 14:06   #1304  |  Link
Mzvasturbo
Registered User
 
Join Date: Dec 2019
Posts: 16
Quote:
Originally Posted by Mzvasturbo View Post
Sory for asking again but how can i make 30second or 1minute samples with staxrip. Because i realy dont want to encode whole movie and waste 50hours of rip time just to try different settings.
It is hard to find a simple tool to trim a 4k hdr remux.
So after trying diferent things i found out mkvtoolnix can do the job.
Now i am playing with hevc adaptive quantization and my movie rips are getting smaller and smaller
Mzvasturbo is offline  
Old 12th January 2020, 17:34   #1305  |  Link
Yanak
Registered User
 
Join Date: Oct 2011
Posts: 275
This comes maybe too late but simply use trim in Staxrip :

- Load a video into Staxrip
- Open the preview mode
- Move the slider at the bottom to the start of a test scene you want to encode or cut
- Right click in the preview window to bring the menu then :
- "Cut" > "Begin Selection" ( Home key shortcut)
- Move slider to the end of the scene or navigate using shortcuts and from the Menu > "Cut" > "End selection" ( End key shortcut )
- Close the preview mode, the video is trimmed.

From there launch the encode with your encoder test settings, only this selected section of the video will be done, or you can also cut it into a new video without re-encoding like mkvtoolnix have done for you :

just need to select "MKV" as output container and "Copy/Mux" in the list instead of x264 or x265 encoder,
same for the audio track if you want to keep it use "Copy/Mux" instead of opus or whatever audio codec is set, but as it's a video encoding test probably going with "No Audio " will be better.

Like i said a bit late but might serve
Yanak is offline  
Old 13th January 2020, 20:53   #1306  |  Link
chipxtreme
Registered User
 
Join Date: Feb 2019
Posts: 47
NVEnc 4.60 is out
chipxtreme is offline  
Old 13th January 2020, 21:54   #1307  |  Link
neo_sapien
Registered User
 
Join Date: Jan 2002
Location: USA
Posts: 249
I've been getting this error for about a year or so when using the latest StaxRip, most recently when using version 2.0.6.0. Often when I get the error, it's a bummer because it's during 30 hour encodes of film sources, using QTGMC Slower to stabilize the film grain (which can reduce the bitrate needed by up to 75% with some film sources without smoothing out the rest of the details too much), at the cost of reducing my encoding speed to about 3fps on my Ryzen 1700X (with x265 Slow).

Here's the error I'm getting:

------ Error Video encoding using x265 3.2+9-971180b100f8 Patman ------
Video encoding using x265 3.2+9-971180b100f8 Patman failed with exit code: -1073741819 (0xC0000005)
The exit code might be a system error code: The instruction at 0xp referenced memory at 0xp. The memory could not be s.

Help?

More info: The issue pops up at random, it's not really reproducible. If I try to encode it again, I might get no crashes, or it might crash at a different point, there's little chance that it would crash at exactly the same frame (it would be like lightning striking in the same place twice). Here's another bit of error code:

avs2pipemod[info]: finished, wrote 9461 frames [85%].
avs2pipemod[info]: total elapsed time is 1182.232 sec.
avs2pipemod[error]: only wrote 9461 of 11004 frames.

Last edited by neo_sapien; 13th January 2020 at 22:40. Reason: more info
neo_sapien is offline  
Old 13th January 2020, 22:12   #1308  |  Link
Patman
Registered User
 
Patman's Avatar
 
Join Date: Jan 2015
Posts: 286
Quote:
Originally Posted by neo_sapien View Post
I've been getting this error for about a year or so when using the latest StaxRip, most recently when using version 2.0.6.0. Often when I get the error, it's a bummer because it's during 30 hour encodes of film sources, using QTGMC Slower to stabilize the film grain (which can reduce the bitrate needed by up to 75% with some film sources without smoothing out the rest of the details too much), at the cost of reducing my encoding speed to about 3fps on my Ryzen 1700X (with x265 Slow).

Here's the error I'm getting:

------ Error Video encoding using x265 3.2+9-971180b100f8 Patman ------
Video encoding using x265 3.2+9-971180b100f8 Patman failed with exit code: -1073741819 (0xC0000005)
The exit code might be a system error code: The instruction at 0xp referenced memory at 0xp. The memory could not be s.

Help?
Hi neo_sapien,

an error like your's was posted here. A bios update of the mainboard fixed that issue for Tom.
__________________
Tools for StaxRip | x264 - x265
Patman is offline  
Old 13th January 2020, 22:48   #1309  |  Link
neo_sapien
Registered User
 
Join Date: Jan 2002
Location: USA
Posts: 249
Quote:
Originally Posted by Patman View Post
Hi neo_sapien,

an error like your's was posted here. A bios update of the mainboard fixed that issue for Tom.

I tried a BIOS update a while back. I also tried doing an extensive memtest86 check on my memory (I think it was 24 hours or more). When I upgraded to StaxRip 2.0.6.0 it stopped for a while, and I thought the issue was resolved, and then recently it came back.
neo_sapien is offline  
Old 13th January 2020, 23:20   #1310  |  Link
Patman
Registered User
 
Patman's Avatar
 
Join Date: Jan 2015
Posts: 286
Quote:
Originally Posted by neo_sapien View Post
I tried a BIOS update a while back. I also tried doing an extensive memtest86 check on my memory (I think it was 24 hours or more). When I upgraded to StaxRip 2.0.6.0 it stopped for a while, and I thought the issue was resolved, and then recently it came back.
The error code returns a hardware failure or hardware problem.

Maybe it helps if you test it with staxrip 2.0.6.2 or updated x265 from my sig. Reinstall vcredist...
__________________
Tools for StaxRip | x264 - x265
Patman is offline  
Old 14th January 2020, 21:34   #1311  |  Link
MrBrownCow
Registered User
 
Join Date: Feb 2019
Posts: 29
Quote:
Originally Posted by Patman View Post
The error code returns a hardware failure or hardware problem.

Maybe it helps if you test it with staxrip 2.0.6.2 or updated x265 from my sig. Reinstall vcredist...
@@Patman I'm sure you have said before but can you verify what the difference is between the x265 and x265 custom builds you have please? Not sure which one to use for win 10 64bit and 2.0.6.2 staxrip.
MrBrownCow is offline  
Old 14th January 2020, 23:20   #1312  |  Link
Patman
Registered User
 
Patman's Avatar
 
Join Date: Jan 2015
Posts: 286
Quote:
Originally Posted by MrBrownCow View Post
@@Patman I'm sure you have said before but can you verify what the difference is between the x265 and x265 custom builds you have please? Not sure which one to use for win 10 64bit and 2.0.6.2 staxrip.
Hi MrBrownCow,

look here

http://forum.doom9.org/showthread.ph...19#post1886119

http://forum.doom9.org/showthread.ph...90#post1886190

better feedback during encoding progress...
__________________
Tools for StaxRip | x264 - x265
Patman is offline  
Old 15th January 2020, 23:17   #1313  |  Link
ukmark
Registered User
 
Join Date: Oct 2018
Posts: 33
Quote:
Originally Posted by frenchfries View Post
Try messing with the amount of ref frames and b frames. That's where the smaller file sizes come into it. I've tested considerably higher amounts of both before with only a small performance decrease but diminishing returns kicks in and it doesn't get much smaller.

What profile in QSV are you using? eg. fastest or best

Interesting that you don't seem happy with dark scenes. That's where i do a lot of my subjective analysis as it's the most obvious to compare but my results are the opposite, at least with the settings I use.
Hi again. I have messed with b and ref frames and from very quick testing I upped both ref and b frames to 16 (although QSV encoder sets a max of 15 for ref frames during the encode). With these values so high I was able to lower the ICQ to 22 and get about the same file size as CRF 24 with x265 (10bit HEVC for both). I always use the "best" quality setting for QSV HEVC.

Encode times did not increase a lot - still about 5x faster than x265 software encoding.

I have just ordered a new Intel i7-1065G7 laptop so I will be testing again when that comes. I'm sure encode times will improve substantially from my current i5-7200u PC. However, I'm much more interested to see if visual quality has improved.

The comparison tool in StaxRip is a great aid, as I believe you recommended it. When comparing side by side the x265 with the QSV encodes, I see VERY slightly more detail in some scenes on the x265 encode - but this is not global - only on some scenes - and the difference is only noticeable on these freeze frames in the comparison tool - and unnoticeable during normal playback on my laptop.

So, all in all, when the new PC comes I will be defaulting to QSV HEVC - the settings are 10 bit, quality best, b-frames and ref frames 16 and icq 22

Maybe with the new version 7 of QS that has been introduced with 10th gen Ice Lake laptops, there will be that extra bit of quality. I plan on testing that.

Not sure if StaxRip has to be modified if there are any new settings available with version 7 of QS - time will tell.

Last edited by ukmark; 16th January 2020 at 01:05.
ukmark is offline  
Old 16th January 2020, 11:44   #1314  |  Link
frenchfries
Registered User
 
Join Date: Jan 2010
Posts: 27
Quote:
Originally Posted by ukmark View Post
Hi again. I have messed with b and ref frames and from very quick testing I upped both ref and b frames to 16 (although QSV encoder sets a max of 15 for ref frames during the encode). With these values so high I was able to lower the ICQ to 22 and get about the same file size as CRF 24 with x265 (10bit HEVC for both). I always use the "best" quality setting for QSV HEVC.

Encode times did not increase a lot - still about 5x faster than x265 software encoding.

I have just ordered a new Intel i7-1065G7 laptop so I will be testing again when that comes. I'm sure encode times will improve substantially from my current i5-7200u PC. However, I'm much more interested to see if visual quality has improved.

The comparison tool in StaxRip is a great aid, as I believe you recommended it. When comparing side by side the x265 with the QSV encodes, I see VERY slightly more detail in some scenes on the x265 encode - but this is not global - only on some scenes - and the difference is only noticeable on these freeze frames in the comparison tool - and unnoticeable during normal playback on my laptop.

So, all in all, when the new PC comes I will be defaulting to QSV HEVC - the settings are 10 bit, quality best, b-frames and ref frames 16 and icq 22

Maybe with the new version 7 of QS that has been introduced with 10th gen Ice Lake laptops, there will be that extra bit of quality. I plan on testing that.

Not sure if StaxRip has to be modified if there are any new settings available with version 7 of QS - time will tell.
I'm glad the ref and b frames worked out for you.

I am extremely interested in your results with your forthcoming ice lake system as I was looking to do some tests with some hardware from work as well when it becomes available.

Please post your findings regarding absolute performance as well as any potential quality increases, although the latter is obviously likely to be anecdotal.

Intel has publicly stated that there is an ~2x performance increase for Ice Lake as well as 422 and 444 support, which probably is of no use to most people. However, the new hardware HDR tone mapping may appeal to some, particularly when used in conjunction with real time transcodes such as with plex or emby.

I am unaware of any quality changes as i think the doubling of EUs and duplicated decoders as well as an EU cache bump is what brings the performance gain.
EDIT - There may actually be some changes as Ice Lake has support for HEVC using only the media engines without using the shaders i.e. low power mode which does not exist in Kaby, coffee, comet etc.

Tiger Lake though is a different beast, as I believe it will double again i.e. ~4x speed of Kaby Lake but is supposed to have new HEVC units and wait for it, AV1 encode support. My concern is that the new HEVC hardware may make for a step back in quality. I suppose we'll see towards the end of the year supposedly, although I really expecting a launch early 2021.

The biggest news for me would be the release of the LP versions of Xe as I hope they simply copy the media units or even duplicate them again for extra performance as I would love to transcode directly on my server rather than having to do it on my laptop.

Last edited by frenchfries; 16th January 2020 at 11:51.
frenchfries is offline  
Old 17th January 2020, 11:34   #1315  |  Link
chipxtreme
Registered User
 
Join Date: Feb 2019
Posts: 47
NVEnc 4.61 is out
chipxtreme is offline  
Old 17th January 2020, 14:57   #1316  |  Link
Taurus
Registered User
 
Taurus's Avatar
 
Join Date: Mar 2002
Location: Krautland
Posts: 903
@all:
If someone is doing a manual update:
NVEnc 4.61 & NVEnc 4.60 are throwing an exception on my machine.
4.59 and former are doing nice.
Just to be warned.....
No time for troubleshooting at the moment.
This is on Win7 64bit (what else?)
Taurus is offline  
Old 18th January 2020, 06:52   #1317  |  Link
neo_sapien
Registered User
 
Join Date: Jan 2002
Location: USA
Posts: 249
Quote:
Originally Posted by Patman View Post
The error code returns a hardware failure or hardware problem.

Maybe it helps if you test it with staxrip 2.0.6.2 or updated x265 from my sig. Reinstall vcredist...
I tried Staxrip 2.0.6.2 and reinstalling vcredist but still get the same error, so I'm trying a workaround; splitting the encode into segments using Preview and Cut Points. If I'm encoding content that has 200,000 frames, then I might do it like this without audio or chapters or subtitles:

Job 1: frame 1 to 35,000
Job 2: frame 35,001 to 70,000
Job 3: frame 70,001 to 105,000
Job 4: frame 105,001 to 140,000
Job 5: frame 140,001 to 175,000
Job 6: frame 175,001 to 200,000

Then append parts 1 through 6 in MKVToolNix GUI and add audio, chapters and subtitles to make the content whole again. This way if I get an error in a 25 hour encode when I'm 80% in, I haven't lost 20 hours of CPU time with nothing to show for it.

Is this a reasonable way to go about it? I was worried that this might result in async audio.
neo_sapien is offline  
Old 19th January 2020, 01:01   #1318  |  Link
chipxtreme
Registered User
 
Join Date: Feb 2019
Posts: 47
Quote:
Originally Posted by Taurus View Post
@all:
If someone is doing a manual update:
NVEnc 4.61 & NVEnc 4.60 are throwing an exception on my machine.
4.59 and former are doing nice.
Just to be warned.....
No time for troubleshooting at the moment.
This is on Win7 64bit (what else?)
4.61 works fine for me, Win 10 64 bit, Ryzen 3900X and 1070 GPU.
chipxtreme is offline  
Old 19th January 2020, 16:02   #1319  |  Link
ukmark
Registered User
 
Join Date: Oct 2018
Posts: 33
Quote:
Originally Posted by frenchfries View Post
I'm glad the ref and b frames worked out for you.

I am extremely interested in your results with your forthcoming ice lake system as I was looking to do some tests with some hardware from work as well when it becomes available.

Please post your findings regarding absolute performance as well as any potential quality increases, although the latter is obviously likely to be anecdotal.

Intel has publicly stated that there is an ~2x performance increase for Ice Lake as well as 422 and 444 support, which probably is of no use to most people. However, the new hardware HDR tone mapping may appeal to some, particularly when used in conjunction with real time transcodes such as with plex or emby.

I am unaware of any quality changes as i think the doubling of EUs and duplicated decoders as well as an EU cache bump is what brings the performance gain.
EDIT - There may actually be some changes as Ice Lake has support for HEVC using only the media engines without using the shaders i.e. low power mode which does not exist in Kaby, coffee, comet etc.

Tiger Lake though is a different beast, as I believe it will double again i.e. ~4x speed of Kaby Lake but is supposed to have new HEVC units and wait for it, AV1 encode support. My concern is that the new HEVC hardware may make for a step back in quality. I suppose we'll see towards the end of the year supposedly, although I really expecting a launch early 2021.

The biggest news for me would be the release of the LP versions of Xe as I hope they simply copy the media units or even duplicate them again for extra performance as I would love to transcode directly on my server rather than having to do it on my laptop.
Received the i7 10th gen laptop. Brief testing - very strange results with QSV HW encoding. The graphics driver version really makes a huge difference and has been flaky. The Lenovo driver (non-DCH) and the latest Intel driver (DCH) give different results. It seems that the drivers will have to be improved over the next few months. I had one occasion (doing a test on 2 mins of video) where the output was noticeably different between the first and second test - same input file, same driver, same settings etc - I can't figure that one out, but I swear nothing changed - apart from the output quality getting better. The speed increase is about 70% for HW encoding. The API version used by QSV is now 1.30, on KL it was 1.27 and there are some extra features auto plugged into the encode settings - tskip is new setting, sao is now set to "all" (was "none" on KL), CTU is now 64 (was 32 on KL).

Another observation is that ICQ 22 on Kaby Lake seems the same as ICQ 19 on Ice Lake(!) with the current Ice Lake driver. I used the same input file with the same settings and encoded a QSV HEVC video on Ice Lake with the exact same settings as Kaby Lake (ICQ 22 and all the extra settings identical), and the file was 35% smaller(!). At first I thought maybe quality had somehow been magically maintained with a 35% smaller file - but no, the quality was noticeably inferior on Ice Lake. To get the same video bit rate, I had to lower the ICQ value from 22 to 19 on Ice Lake (flaky drivers again??)

For SW encoding I'm getting about triple the speed (pleased with that) - and the quality is identical to Kaby Lake (which it should be as the graphics driver is not used in SW encoding AFAIK).

I think once the drivers get improved, then QSV HW encoding looks promising. I'm seeing some excellent quality (at times), but as I say, the graphics drivers seem flaky right now.

Last edited by ukmark; 19th January 2020 at 16:26.
ukmark is offline  
Old 19th January 2020, 19:07   #1320  |  Link
Patman
Registered User
 
Patman's Avatar
 
Join Date: Jan 2015
Posts: 286
Quote:
Originally Posted by neo_sapien View Post
I tried Staxrip 2.0.6.2 and reinstalling vcredist but still get the same error, so I'm trying a workaround; splitting the encode into segments using Preview and Cut Points. If I'm encoding content that has 200,000 frames, then I might do it like this without audio or chapters or subtitles:

Job 1: frame 1 to 35,000
Job 2: frame 35,001 to 70,000
Job 3: frame 70,001 to 105,000
Job 4: frame 105,001 to 140,000
Job 5: frame 140,001 to 175,000
Job 6: frame 175,001 to 200,000

Then append parts 1 through 6 in MKVToolNix GUI and add audio, chapters and subtitles to make the content whole again. This way if I get an error in a 25 hour encode when I'm 80% in, I haven't lost 20 hours of CPU time with nothing to show for it.

Is this a reasonable way to go about it? I was worried that this might result in async audio.
Change your x265.exe with a version from here and test again.
__________________
Tools for StaxRip | x264 - x265
Patman is offline  
Closed Thread

Tags
aac, hdr, hevc, nvenc, staxrip, x264, x265

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 00:42.


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