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. |
8th January 2020, 03:34 | #1301 | Link | |
Registered User
Join Date: Jan 2010
Posts: 27
|
Quote:
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 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. |
|
8th January 2020, 11:43 | #1302 | Link | |
Registered User
Join Date: Oct 2018
Posts: 33
|
Quote:
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. |
|
11th January 2020, 02:43 | #1303 | Link | |
Registered User
Join Date: Jan 2010
Posts: 27
|
Quote:
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. |
|
12th January 2020, 14:06 | #1304 | Link | |
Registered User
Join Date: Dec 2019
Posts: 16
|
Quote:
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 |
|
12th January 2020, 17:34 | #1305 | Link |
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 |
13th January 2020, 21:54 | #1307 | Link |
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 |
13th January 2020, 22:12 | #1308 | Link | |
Registered User
Join Date: Jan 2015
Posts: 286
|
Quote:
an error like your's was posted here. A bios update of the mainboard fixed that issue for Tom. |
|
13th January 2020, 22:48 | #1309 | Link | |
Registered User
Join Date: Jan 2002
Location: USA
Posts: 249
|
Quote:
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. |
|
13th January 2020, 23:20 | #1310 | Link | |
Registered User
Join Date: Jan 2015
Posts: 286
|
Quote:
Maybe it helps if you test it with staxrip 2.0.6.2 or updated x265 from my sig. Reinstall vcredist... |
|
14th January 2020, 21:34 | #1311 | Link | |
Registered User
Join Date: Feb 2019
Posts: 29
|
Quote:
|
|
14th January 2020, 23:20 | #1312 | Link | |
Registered User
Join Date: Jan 2015
Posts: 286
|
Quote:
look here http://forum.doom9.org/showthread.ph...19#post1886119 http://forum.doom9.org/showthread.ph...90#post1886190 better feedback during encoding progress... |
|
15th January 2020, 23:17 | #1313 | Link | |
Registered User
Join Date: Oct 2018
Posts: 33
|
Quote:
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. |
|
16th January 2020, 11:44 | #1314 | Link | |
Registered User
Join Date: Jan 2010
Posts: 27
|
Quote:
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. |
|
17th January 2020, 14:57 | #1316 | Link |
Registered User
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?) |
18th January 2020, 06:52 | #1317 | Link | |
Registered User
Join Date: Jan 2002
Location: USA
Posts: 249
|
Quote:
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. |
|
19th January 2020, 16:02 | #1319 | Link | |
Registered User
Join Date: Oct 2018
Posts: 33
|
Quote:
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. |
|
19th January 2020, 19:07 | #1320 | Link | |
Registered User
Join Date: Jan 2015
Posts: 286
|
Quote:
|
|
Tags |
aac, hdr, hevc, nvenc, staxrip, x264, x265 |
Thread Tools | Search this Thread |
Display Modes | |
|
|