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. |
5th August 2020, 10:42 | #29802 | Link |
Registered User
Join Date: Mar 2006
Posts: 75
|
Check out this IC Graphite Pad, supposed to work just as good as the best thermal pastes, but with no drying out or installation errors:
https://youtu.be/YpphKzmDiJM https://www.amazon.com/dp/B07CKVW18G |
5th August 2020, 16:40 | #29803 | Link | |
Special SeeD
Join Date: Nov 2002
Location: Mexico
Posts: 333
|
Quote:
Code:
[08/03/20] BD Rebuilder v0.61.09 [21:37:28] Source: THE_FAST_AND_THE_FURIOUS_2001 - Input BD size: 57.81 GB - Approximate total content: [02:36:40.348] - Target BD size: 24.41 GB - Windows Version: 6.2 [9200] - Quality: Better (Faster), CRF - Decoding/Frame serving: FFMPEG - Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640 [21:37:32] PHASE ONE, Encoding - [21:37:32] Processing: VID_00165 (1 of 4) - [21:37:32] Extracting A/V streams [VID_00165] - [21:37:37] Reencoding video [VID_00165] - Source Video: HEVC, 3840x2160 - Rate/Length: 23.976fps, 576 frames - [21:37:37] Performing CRF Prediction... - Analyzing 15.80 15.30 14.95 [14.95] - [21:37:53] Encoding using constant rate factor. - [21:38:40] Video Encode complete - [21:38:40] Processing audio tracks - Track 4352 (eng): Keeping original audio - [21:38:40] Multiplexing M2TS - [21:38:44] Blanking: VID_00252 (2 of 4) - [21:38:44] Blanking: VID_00253 (3 of 4) - [21:38:44] Processing: VID_00294 (4 of 4) - [21:38:44] Extracting A/V streams [VID_00294] - [21:48:00] Reencoding video [VID_00294] - Source Video: HEVC, 3840x2160 - Rate/Length: 23.976fps, 153,721 frames - [21:48:00] Performing CRF Prediction... - Analyzing 15.90 8.45 4.72 2.86 1.93 1.46 1.23 1.11 1.06 1.03 1.02 1.01 [1.01] - [21:49:38] Encoding using constant rate factor. - Performing size-correcting second pass... - [09:34:24] Video Encode complete - [09:34:24] Processing audio tracks - Track 4352 (eng): Keeping original audio - Track 4354 (spa): Keeping original audio - Track 4357 (eng): Keeping original audio - [09:34:24] Multiplexing M2TS [09:35:24]PHASE ONE complete [09:35:24]PHASE TWO - Rebuild Started - [09:35:24] Rebuilding BD file Structure [09:35:44] - Encode and Rebuild complete Code:
[Status] LABEL=THE_FAST_AND_THE_FURIOUS_2001 VERSION=v0.61.09 SOURCE_SIZE=62073708041 SOURCE_VIDEO_SIZE=60550053888 TARGET_SIZE=26214400000 REDUCTION=.407774134977166 RESIZE_1080=0 RESIZE_1440=0 AUDIO_TO_KEEP=all KEEP_HD_AUDIO=-1 SUBS_TO_KEEP=all BACKUP_MODE=0 MOVIEONLY_TYPE=0 USE_LAVF=0 INSTANCES=1 DGDECNV=0 DGDECIM=0 FRIMSOURCE=0 FFMS2=0 SSIF_MODE=0 UHD_V3_MODE=0 QUICK=0 ENCODE_STEP=0 COMPLETED=4 REBUILD_COMPLETE=1 [00165] AUDIO=1 PGS= VIDEO2=0 V2MBRATE=0 M2TS_TARGET=78560708 NSTART=27000000 NEND=28081079 NSIZE=80283648 FLINK=0 MLINK=0 [00294] AUDIO=101001 PGS=1111111111111 VIDEO2=0 V2MBRATE=0 M2TS_TARGET=24612185139 NSTART=27000000 NEND=315515101 NSIZE=23796996096 FLINK=0 MLINK=0 So software encoding CRF prediction is definitely buggy, at least in version 61.09. Looks like its using FFMPEG for getting the sample data but the results are static images (crazy DTS/PTS values?) so the prediction calculates a very low CRF value: Code:
"D:\Archivos de Programa\BD Rebuilder UHD\tools\ffmpeg.exe" -ss 5998.7456 -i "L:\BLU-RAYS\4K\THE FAST AND THE FURIOUS 2001\BDMV\STREAM\00294.m2ts" -frames 48 -an -sn -codec copy -f mpegts - >> "C:\TEMP\WORKFILES\00294.AVS.SMPL.m2ts" Last edited by jdobbs; 6th August 2020 at 12:59. Reason: Too wide |
|
6th August 2020, 01:34 | #29805 | Link | |
Registered User
Join Date: May 2007
Location: Wisconsin
Posts: 2,132
|
Quote:
__________________
My Total Eclipse 2017 Photos My Nov 2019 Game of Thrones Tour My NEOWISE Comet Photos 2020 Last edited by MrVideo; 6th August 2020 at 01:42. |
|
6th August 2020, 12:50 | #29806 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,975
|
Quote:
Last edited by jdobbs; 6th August 2020 at 12:55. |
|
6th August 2020, 13:04 | #29807 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,975
|
Quote:
The reason I think it is important to get CQM & CRF working well ISN'T just speed. My testing shows that you get BETTER QUALITY at the same size using CQM/CRF than you do with one-pass VBR bitrate encoding. NVENCC has no true two-pass option and X265 is so slow on UHD that you want to try and avoid two-pass. So the time comparison shouldn't be between one-pass and CQM/CRF -- but between CQM/CRF and a two pass encode (averaging across multiple discs -- not just one). A second pass in CQM/CRF mode only occurs when the final target size is exceeded to a point where it won't fit on the target disc. It's also important to point out that the reason BD-RB has to create an alternate prediction method for HEVC is because AVISYNTH doesn't handle HEVC well. The problems stem from the fact that when trying to seek (SelectRangeEvery) with AVISYNTH on an HEVC source you don't seem to land on (or adjust from) i-frames and you get garbage output -- making the method used for AVC prediction (upon which I spent a considerable amount of time) is a non-starter. Part of the purpose of the "test" releases is to figure out a good way to predict without using AVISYNTH. So the new method (for HEVC) uses FFMPEG to pull out sections of the source M2TS and combines them into an M2TS to use as the prediction source. With all that said... I'm working on trying to make the initial CQM/CRF value more accurate. But it ain't easy... and that's why you don't see CQM/CRF prediction algorithms laying around waiting for someone to pick one up to use. Last edited by jdobbs; 6th August 2020 at 13:44. |
|
6th August 2020, 16:00 | #29808 | Link |
Moderator
Join Date: Oct 2001
Posts: 20,975
|
BD Rebuilder v0.61.10
Unless I've missed something in testing, I think the latest version is very close to release for public consumption. Please download and do some testing on this release:
BD Rebuilder v0.61.10 Summary of changes: Code:
- Added support for NVIDIA NVENC encoding. - Corrected an error that could cause BD-RB to exit in failure when attempting a size- correcting second pass in CRF mode while doing a UHD backup. - Added code that will update the HDR flags in the MPLS file for sources in which HDR was not established until after reencoding on full backups. - Fixed an error in which MPEG2 sources may not make video adjustments detected during import when reencoding. This could result in stretched or compressed images. - Created a workaround for a problem with converting PAL to NTSC flags during import which could confuse TSMUXER's recognition of video resolution. - Added code to adapt to UHD sources that are not sized to either 3840(h) or 2160(v). - Corrected an issue in which video sources that are an odd size during import might use the wrong resizing when HEVC encoding is enabled. - Fixed a bug in which large audio offsets detected during import were not being interpreted correctly. - Fixed a bug that could cause undersizing when an AC3 stream is kept intact because the original is smaller than the selected reencoder bitrate. This typically only happens on DVD imports. - Fixed an error that could result in wrong aspect ratio on imported sources that are being resized. - Corrected an issue in which some command line settings were not being set when a non-UHD source is output as V3. - Added a routine to ensure formatting of CRF values consistent. - Updated CQM prediction routines. - Fixed an issue that can cause the CQM/CRF sample file to have a zero length when used in other-than-US regions. - Modified NVENCC options to eliminate vbrhq from the command line, as it is targeted to be deprecated. Replaced by "vbr" and manually enabling "--multipass 2pass-full" (the newer equivalent of vbrhq). - Rewrote the "Bitstream Exception" TSMUXER error workaround routine so it now uses a more efficient method -- and better adjusts audio sync. It also now adjusts for Dolby Vision exception errors. - Fixed an issue in which BT709 sources were not being encoded with proper settings. - Increased the accepted value of the THREADS hidden option from 16 to 128. Note: While 128 is accepted for x264 -- realistically you should never set it that high. - Added support for HDR10+ A JSON file is created concurrently with video extraction. HDR10+ streams are now identified in the streams list by a "+" next to "HEVC". Note that "*" indicates Dolby Vision. "*+"=both. - Changed the ALTERNATE settings so creating a preset that outputs HEVC to MP4 is now allowed. - Updated the included version of MP4BOX to support HEVC. - Updated the included versions of X265 to a newer (v3.2.1) release. - Other minor corrections and cosmetic fixes. |
6th August 2020, 16:37 | #29809 | Link | |||
Special SeeD
Join Date: Nov 2002
Location: Mexico
Posts: 333
|
Quote:
Quote:
https://mega.nz/file/NXpgmSJb#LPjgIr...0bdzKUTdTOTmog Looks like even FFMPEG is incapable of properly read the "00294.AVS.SMPL.m2ts" file created for CRF prediction, and that is the reason for the ultra low values that results in a oversized file. Quote:
EDIT: I Think I found the culprit, "-frames 48" removing it from lastcmd.txt creates a proper output file!!! Looks like FFMPEG is actually capable of properly decoding the prediction file, but for some reason, BD-RB is parsing a incorrect parameter for "-frames" that cut the prediction file to early. EDIT 2: Still present in 0.61.10 (obviously). Last edited by jdobbs; 6th August 2020 at 20:11. Reason: Fix? |
|||
6th August 2020, 18:46 | #29810 | Link | |
Registered User
Join Date: Jun 2010
Location: Germany
Posts: 205
|
Quote:
|
|
6th August 2020, 20:31 | #29811 | Link |
Moderator
Join Date: Oct 2001
Posts: 20,975
|
@SquallMX
The "-frames 48" is a bit confusing. I'll have a look at it. If it were taken from the command line that is creating the SAMPLE it would make more sense. The sample file is created using groups of 48 frames (about 2 seconds each), each starting with an iframe (the start of which is pulled from the CLPI's EP_map table). FFMPEG is run multiple times outputting 48 frames with each iteration giving an approximate 1% of the entire source file (by default, it is adjustable with HIDDENOPTS and it can be a larger percentage sample on smaller files). Why it is in the command line used to encode the sample makes me think there has to be a bug somewhere. The question is "why is it not happening to me?" I assume the source being encoded is larger than 4800 frames? Can you send me (or post) your settings (the contents of BDREBUILDER.INI). Maybe something in the settings is triggering the glitch. [Edit] Never mind. I found it. It was a mistake in coding and you were absolutely right. No wonder the prediction was so far off. It appears to be left over from a test I was doing to compare encoding 48 frames at a time as opposed to extracting them with FFMPEG beforehand and then encoding the group. Since most of my recent testing has been using NVENCC (the logic flow of which was copied from the X265 routine) -- I guess I just outright failed to switch it back from the test code in the X265 routine. Thanks for the help in identifying that bug. I'll put in a fix, test it, and get another version up. I'm also working on improving the prediction algorithm on small streams -- so it will probably be a day or two (at the most). Last edited by jdobbs; 7th August 2020 at 01:32. |
6th August 2020, 21:05 | #29812 | Link |
Registered User
Join Date: Mar 2010
Posts: 10
|
Thanks for the reply. Ya its something I've just had to deal with for several years, but just trying to find out if there were any new developments. BTW, It only happens if it goes through BD-Rebuilder first, as the software player (PowerDVD) plays the original 3D discs fine without artifacts. I know 3D is not a priority and is dying , but I'm still a huge 3D fan. Thanks for all the cool BD Rebuilder developments over the years .
|
6th August 2020, 21:33 | #29813 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,975
|
Quote:
|
|
6th August 2020, 21:43 | #29814 | Link | |
Registered User
Join Date: Jan 2009
Posts: 1,368
|
@jedihyte
Quote:
|
|
6th August 2020, 22:49 | #29815 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,975
|
Quote:
Last edited by jdobbs; 7th August 2020 at 01:33. |
|
7th August 2020, 06:22 | #29816 | Link | |
Registered User
Join Date: Dec 2006
Location: Long Beach, Ca USA
Posts: 99
|
Howls Moving Castle
It failed on making alternative output; mp4, x265, auto-aac. version is 61.10
Quote:
Code:
[00041] caption=MP4 Container, HEVC 1920x1080, Auto-AAC vEncoder=1 vBitrate=2000 vKeyint=Auto aBitrate=* aType=1 vFormat=5 cType=5 |
|
7th August 2020, 18:31 | #29819 | Link |
Registered User
Join Date: Jun 2010
Location: Germany
Posts: 205
|
More of a feature request:
Is it possible to turn quality up even more? like: Code:
--preset quality --multipass 2pass-full Or is that already covered by the QUALITY_ULTRA hidden switch? |
7th August 2020, 23:47 | #29820 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,975
|
Quote:
Note, however: QUALITY_ULTRA doesn't apply to NVENCC, only X264 & X265. I ran numerous tests on numerous sources using that setting. Even though the encode slowed down significantly (making you think it does more), the SSIM results were worse than the next lower setting (quality, without multipass). All the existing settings position in the quality list were based on SSIM values first and encode speed second. My results could be wrong... but it would have to be wrong on every source I tried. If you want, though, you can still use that setting by editing the INI file and changing ENCODE_QUALITY to a value of 4. But I wouldn't recommend it. Just as an aside: Have you tested the HDR10+ capability I added to v0.61.10? My player doesn't support HDR10+ so I could only do limited testing (header and value checks, etc.). Last edited by jdobbs; 8th August 2020 at 00:20. |
|
|
|