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 > (HD) DVD, Blu-ray & (S)VCD > DVD & BD Rebuilder

Reply
 
Thread Tools Search this Thread Display Modes
Old 6th August 2020, 21:33   #29821  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,662
Quote:
Originally Posted by jedihyte View Post
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 .
Sorry I wasn't more help. Maybe someone else in the forum has experienced the same issue and found a solution -- anyone?
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net
jdobbs is offline   Reply With Quote
Old 6th August 2020, 21:43   #29822  |  Link
Ch3vr0n
Registered User
 
Join Date: Jan 2009
Posts: 1,348
@jedihyte

Quote:
Originally Posted by jdobbs View Post
Sorry I wasn't more help. Maybe someone else in the forum has experienced the same issue and found a solution -- anyone?
i have asked that before and supposedly using a newer version of FRIM than the one that currently comes with BDRB fixes that issue. I have it downloaded, i just havent had the time to test it. https://www.videohelp.com/software/FRIM
Ch3vr0n is offline   Reply With Quote
Old 6th August 2020, 22:49   #29823  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,662
Quote:
Originally Posted by Ch3vr0n View Post
@jedihyte



i have asked that before and supposedly using a newer version of FRIM than the one that currently comes with BDRB fixes that issue. I have it downloaded, i just havent had the time to test it. https://www.videohelp.com/software/FRIM
I'll download it and test to see if it causes any interface issues.
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net

Last edited by jdobbs; 7th August 2020 at 01:33.
jdobbs is offline   Reply With Quote
Old 7th August 2020, 06:22   #29824  |  Link
meadrocks
Registered User
 
Join Date: Dec 2006
Location: Long Beach, Ca USA
Posts: 97
Howls Moving Castle

It failed on making alternative output; mp4, x265, auto-aac. version is 61.10

Quote:
----------------------
[08/06/20] BD Rebuilder v0.61.10
[17:10:20] Source: HOWLS_MOVING_CASTLE_00200
- Input BD size: 32.77 GB
- Approximate total content: [01:59:27.243]
- Windows Version: 6.2 [9200]
- MOVIE-ONLY/ALTERNATE OUTPUT mode enabled
- Mode: MP4 Container, HEVC 1920x1080, Auto-AAC
- Quality: High Quality (Default)
- Decoding/Frame serving: DirectShow
- Audio Settings: AC3=0 DTS=0 HD=0 Kbs=640
[17:10:20] PHASE ONE, Encoding
- [17:10:20] Processing: VID_00100 (1 of 3)
- [17:10:20] Extracting A/V streams [VID_00100]
- [17:15:44] Reencoding video [VID_00100]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 17,911 frames
- [17:15:44] Reencoding: VID_00100, Pass 1 of 1
- Analyzing 21.50 23.70 [23.70]
- [17:30:53] Video Encode complete
- [17:30:53] Processing audio tracks
- Track 4352 (eng): Reencoding audio to AAC...
- [17:38:06] Processing: VID_00102 (2 of 3)
- [17:38:06] Extracting A/V streams [VID_00102]
- [17:46:32] Reencoding video [VID_00102]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 147,121 frames
- [17:46:32] Reencoding: VID_00102, Pass 1 of 1
- Analyzing 21.50 21.80 [21.85]
- [20:12:38] Video Encode complete
- [20:12:38] Processing: VID_00103 (3 of 3)
- [20:12:38] Extracting A/V streams [VID_00103]
- [20:13:01] Reencoding video [VID_00103]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 6,810 frames
- [20:13:01] Reencoding: VID_00103, Pass 1 of 1
- Analyzing 21.45 18.50 17.95 17.70 [17.70]
- [20:18:48] Video Encode complete
[20:18:48]PHASE ONE complete
[20:18:48]PHASE TWO - Rebuild Started
- [20:18:48] Building ALTERNATE OUTPUT Structure
- ERROR in attempt to mux (MP4BOX)
[20:19:10] - Failed to REBUILD
-----------------------
[20:19:10] PROCESSING BATCH FILE [2]
Code:
[00041]
caption=MP4 Container, HEVC 1920x1080, Auto-AAC
vEncoder=1
vBitrate=2000
vKeyint=Auto
aBitrate=*
aType=1
vFormat=5
cType=5
meadrocks is offline   Reply With Quote
Old 7th August 2020, 09:25   #29825  |  Link
MrVideo
Registered User
 
MrVideo's Avatar
 
Join Date: May 2007
Location: Wisconsin
Posts: 1,710
Quote:
Originally Posted by jdobbs View Post
but when I changed your blocking from CODE to QUOTE (so I could get line wrapping and better read the command line) and saw what was actually happening I realized I was zigging when I should have been zagging.
Keep it code wrapped, but manually cut long lines with returns. Especially useful when the included text is really long. Long quotes are very annoying.
MrVideo is offline   Reply With Quote
Old 7th August 2020, 11:33   #29826  |  Link
BuddTX
Registered User
 
Join Date: Mar 2006
Posts: 71
Quote:
Originally Posted by jdobbs View Post
Status update: Got pretty much everything reported in bug reports fixed. Currently working on HDR10+ support. I'll probably be releasing the next version in a day or two.
NICE! Thank you!
BuddTX is offline   Reply With Quote
Old 7th August 2020, 18:31   #29827  |  Link
cartman0208
Registered User
 
Join Date: Jun 2010
Location: Germany
Posts: 131
More of a feature request:

Is it possible to turn quality up even more?
like:
Code:
--preset quality --multipass 2pass-full
I just tried the commandline ... encoding speed drops by another 25% but that wouldn't matter for me ... still around 20x faster than CPU

Or is that already covered by the QUALITY_ULTRA hidden switch?

cartman0208 is offline   Reply With Quote
Old 7th August 2020, 23:47   #29828  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,662
Quote:
Originally Posted by cartman0208 View Post
More of a feature request:

Is it possible to turn quality up even more?
like:
Code:
--preset quality --multipass 2pass-full
I just tried the commandline ... encoding speed drops by another 25% but that wouldn't matter for me ... still around 20x faster than CPU

Or is that already covered by the QUALITY_ULTRA hidden switch?

Funny you should ask. Yes, you can get that with a hidden switch. But I left that one off the non-hidden list purposely.

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.).
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net

Last edited by jdobbs; 8th August 2020 at 00:20.
jdobbs is offline   Reply With Quote
Old 8th August 2020, 00:09   #29829  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,662
Update:

I'm currently still working on CQM/CRF encode prediction improvements. In testing, I'm finding that maybe my current prediction tables for HEVC/2160p sources using X265 may need to be adjusted. Unfortunately the means encoding multiple sources at every possible CRF value so I can calculate the relationship of each value to all the rest. It's just taking forever to do that at 4-7fps.

I'm also tuning the actual encode routine to prevent some of the anomalies that have been reported.
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net
jdobbs is offline   Reply With Quote
Old 8th August 2020, 00:24   #29830  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,662
@meadrocks

Can you post the ALTERNATE preset you used for HEVC/MP4 output? I tested it on different sources and it worked for me.

I notice you are using a multipart source. Try it on a single part source and see if that's related to the problem. I'd do it but my system is bogged down doing prediction table encodes.
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net
jdobbs is offline   Reply With Quote
Old 8th August 2020, 00:40   #29831  |  Link
meadrocks
Registered User
 
Join Date: Dec 2006
Location: Long Beach, Ca USA
Posts: 97
Quote:
Originally Posted by jdobbs View Post
@meadrocks

Can you post the ALTERNATE preset you used for HEVC/MP4 output?
Sorry, where do I find that info?
Do you mean this?
[00041]
caption=MP4 Container, HEVC 1920x1080, Auto-AAC
vEncoder=1
vBitrate=2000
vKeyint=Auto
aBitrate=*
aType=1
vFormat=5
cType=5

Last edited by meadrocks; 8th August 2020 at 00:45.
meadrocks is offline   Reply With Quote
Old 8th August 2020, 08:23   #29832  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,725
Quote:
Originally Posted by jdobbs View Post
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.
I have some doubt whether NVIDIA's 2pass method contributes much to quality in the sense of best match with the original or highest SSIM. They write:
Quote:
As a result, with 2-pass rate control modes, NVENC can distribute the bits more optimally within the frame and can reach closer to the target bitrate, especially for CBR encoding. Note, however, that everything else being the same, performance of 2-pass rate control mode is lower than that of 1-pass rate control mode. The client application should choose an appropriate multi-pass rate control mode after evaluating various modes, as each of the modes has its own advantages and disadvantages.
In earlier tests I found that disabling -aq resulted in better SSIM than using it. The explanation is probably that -aq is to some extent a psychovisual optimization which conflicts with PSNR -- and possibly also with SSIM --optimization.
From NVIDIA on Spatial AQ:
Quote:
Spatial AQ mode adjusts the QP values based on spatial characteristics of the frame. Since the low complexity flat regions are visually more perceptible to quality differences than high complexity detailed regions, extra bits are allocated to flat regions of the frame at the cost of the regions having high spatial detail. Although spatial AQ improves the perceptible visual quality of the encoded video, the required bit redistribution results in PSNR drop in most of the cases. Therefore, during PSNR-based evaluation, this feature should be turned off.
Perhaps we see a similar effect with the 2pass modes?

Last edited by Sharc; 8th August 2020 at 08:33.
Sharc is offline   Reply With Quote
Old 8th August 2020, 11:18   #29833  |  Link
cartman0208
Registered User
 
Join Date: Jun 2010
Location: Germany
Posts: 131
Quote:
Originally Posted by jdobbs
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.
Quote:
Originally Posted by Sharc
I have some doubt whether NVIDIA's 2pass method contributes much to quality in the sense of best match with the original or highest SSIM. They write:
Quote:
As a result, with 2-pass rate control modes, NVENC can distribute the bits more optimally within the frame and can reach closer to the target bitrate, especially for CBR encoding. Note, however, that everything else being the same, performance of 2-pass rate control mode is lower than that of 1-pass rate control mode. The client application should choose an appropriate multi-pass rate control mode after evaluating various modes, as each of the modes has its own advantages and disadvantages.
Well that is surprising ... and I though 2pass gives the ultimate quality ...
Do you see the same on the other quality settings, where 2pass is involved?

Quote:
Originally Posted by jdobbs
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.).
Actually my player also doesn't support HDR10+ while my TV does
I'm still in the process of evaluating players ... (any suggestions?)
I was hoping to get the meta information in an alternate output.

[edit]
Tried an encode of a HDR10+ disk... all fine up to the point where the source resolution (or compression) changes:
Code:
---------------------
[08.08.20] BD Rebuilder v0.61.10
[09:59:02] Source:  HOBBS_AND_SHAW
  - Input BD size: 87,50 GB
  - Approximate total content: [04:37:04.228]
  - Target BD size: 47,36 GB
  - Windows Version: 6.2 [9200]
  - Quality: Ultra-High (Extremely Slow), CQM
  - Decoding/Frame serving: NVENCC
  - Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
[09:59:05] PHASE ONE, Encoding
 - [09:59:05] Processing: VID_00165 (1 of 63)
 - [09:59:05] Extracting A/V streams [VID_00165]
 - [09:59:10] Reencoding video [VID_00165]
   - Source Video: HEVC, 3840x2160
   - Rate/Length: 23,976fps, 576 frames
 - [09:59:10] Performing CQM Prediction...
   - Analyzing 18,40 21,55 22,00 [22,08]
 - [09:59:32] Encoding using constant quality mode.
 - [09:59:51] Video Encode complete
 - [09:59:51] Processing audio tracks
   - Track 4352 (eng): Keeping original audio
 - [09:59:51] Multiplexing M2TS
 - [09:59:56] Processing: VID_00294 (2 of 63)
 - [09:59:56] Extracting A/V streams [VID_00294]
 - [10:05:08] Reencoding video [VID_00294]
   - Source Video: HEVC, 3840x2160
   - Rate/Length: 23,976fps, 195.520 frames
 - [10:05:08] Performing CQM Prediction...
   - Analyzing 18,90 21,45 21,75 [21,75]
 - [10:10:56] Encoding using constant quality mode.
 - [11:49:51] Video Encode complete
 - [11:49:51] Processing audio tracks
   - Track 4352 (eng): Keeping original audio
   - Track 4353 (deu): Keeping original audio
 - [11:49:51] Multiplexing M2TS
 - [11:51:52] Processing: VID_00368 (3 of 63)
 - [11:51:52] Extracting A/V streams [VID_00368]
 - [11:52:10] Reencoding video [VID_00368]
   - Source Video: HEVC, 3840x2160
   - Rate/Length: 23,976fps, 14.728 frames
 - [11:52:10] Performing CQM Prediction...
   - Analyzing 20,15 23,20 24,60 24,90 [24,90]
 - [11:52:38] Encoding using constant quality mode.
 - [12:00:04] Video Encode complete
 - [12:00:04] Processing audio tracks
   - Track 4352 (eng): Keeping original audio
 - [12:00:04] Multiplexing M2TS
 - [12:00:09] Processing: VID_00369 (4 of 63)
 - [12:00:09] Extracting A/V streams [VID_00369]
 - [12:00:16] Reencoding video [VID_00369]
   - Source Video: MPEG-4 (AVC), 1920x1080
   - Rate/Length: 23,976fps, 5.241 frames
 - [12:00:16] Performing CQM Prediction...
   - Analyzing 16,35 [12:00:17] - Failed video encode, aborted
Also tried an alternate output that fails if autocrop is enabled. Without ... went fine, but the MKV output file flickers when played directly on my TV, like the brightness meta info is switched on and off every half a second ...

Last edited by cartman0208; 8th August 2020 at 18:08.
cartman0208 is offline   Reply With Quote
Old 8th August 2020, 11:55   #29834  |  Link
Ch3vr0n
Registered User
 
Join Date: Jan 2009
Posts: 1,348
I tried the new FRIM, decode worked, encode process was stuck at , FPS (yes just a comma, that's not a typo) on my 9900k, then just failed on the newer one. Encoding wouldn't even start (after enabling dual GPU in the bios and installing the proper drivers and rebooting). Could be because the newer 1.30 zip contains a whole lot more files than the default 1.27. I just copied over the same 4 files and renamed the new FRIMDecode32.exe etc to FRIMDecode.exe

Tried the default one. Only copied the audio track for some reason. 26GB down to under 3GB for the main title including HD audio, yeah that aint right

oh and that is with the 61.05 version (i'll wait for the newer one until it gets updated with a newer frim)

Last edited by Ch3vr0n; 8th August 2020 at 12:11.
Ch3vr0n is offline   Reply With Quote
Old 8th August 2020, 22:50   #29835  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,662
Quote:
Originally Posted by cartman0208 View Post
Also tried an alternate output that fails if autocrop is enabled. Without ... went fine, but the MKV output file flickers when played directly on my TV, like the brightness meta info is switched on and off every half a second ...
Interesting. That would make sense, since the metadata is inserted into i-frames (about every half second).
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net
jdobbs is offline   Reply With Quote
Old 8th August 2020, 22:58   #29836  |  Link
cartman0208
Registered User
 
Join Date: Jun 2010
Location: Germany
Posts: 131
In the alternate output with intact video there's no such issues ... does that mean the metadata only fits to the original P, B and I-Frame sequence (or at least I-Frame interval)?
I guess, it's pretty hard to synchronize that in a reencode
cartman0208 is offline   Reply With Quote
Old 8th August 2020, 23:45   #29837  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,662
Quote:
Originally Posted by cartman0208 View Post
In the alternate output with intact video there's no such issues ... does that mean the metadata only fits to the original P, B and I-Frame sequence (or at least I-Frame interval)?
I guess, it's pretty hard to synchronize that in a reencode
It should be by scene, and a scene should always start with an i-frame. So my belief is that the sequence within that GOP (P & B frames) shouldn't matter.

In order to make sure the metadata matches the original i-frame positioning, BD-RB grabs the frame numbers of all i-frames in the original and uses them to force i-frames at the same position in the reencode (in the .CHP file).

That takes place for sure when creating a new BD structure. It's possible that I may be losing that when doing ALTERNATE output. It may be affected by the ability to create much longer GOP sequences in ALTERNATE files. For example, in a BD there is a limit as to how long a GOP can be (typically it's every 24 frames for a film source). But in ALTERNATE output you often (very often) see it expanded to 240 frames. That might play havoc with positioning of the metadata (just speculating)

The actual placement of the metadata in the newly encoded stream is done by X265 or NVENCC using a JSON file that was created from the original source.

This is all speculation until I look at the code and do some testing. I'll take a look and see what I can find. Unfortunately I'm no expert on HDR10+ and/or exactly how JSON files are applied. BD-RB uses 3rd party software to create the JSON and X265/NVENCC to apply it.

The downside is that the reason most people use GOP lengths of 240 is for encoding efficiency. If you have to keep the original i-frame positions, that goes out the window. Generally an encoder senses scene changes and inserts an i-frame when it changes -- that makes it even more complex. I believe the .CHP file overrides that, since it explicitly forces i-frames at certain points.

[Edit] Oh, and by the way, the --multipass option does seem to give better SSIM values in all the other modes. It's just in QUALITY mode that I saw that anomaly.

[Edit - again] I just scanned a JSON file, and there seems to be an entry in the file for every frame in the source. That would seem to imply that the scene change information would be kept correctly even if I didn't use the .CHP to force i-frames. Any experts out there want to chime in?
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net

Last edited by jdobbs; 9th August 2020 at 00:41.
jdobbs is offline   Reply With Quote
Old 9th August 2020, 00:46   #29838  |  Link
cartman0208
Registered User
 
Join Date: Jun 2010
Location: Germany
Posts: 131
Quote:
Originally Posted by jdobbs View Post
That takes place for sure when creating a new BD structure. It's possible that I may be losing that when doing ALTERNATE output. It may be affected by the ability to create much longer GOP sequences in ALTERNATE files. For example, in a BD there is a limit as to how long a GOP can be (typically it's every 24 frames for a film source). But in ALTERNATE output you often (very often) see it expanded to 240 frames. That might play havoc with positioning of the metadata (just speculating)
So just removing vKeyint=Auto from the alternate.txt could solve the problem?
I didn't know what to set and left it on all presets to Auto, since it's usually a good choice
cartman0208 is offline   Reply With Quote
Old 9th August 2020, 01:26   #29839  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,662
Quote:
Originally Posted by cartman0208 View Post
So just removing vKeyint=Auto from the alternate.txt could solve the problem?
I didn't know what to set and left it on all presets to Auto, since it's usually a good choice
After my last edit comment on my post, I'm not so sure. Since the JSON file contains data on every frame, it implies that the encoder can put a keyframe anywhere it wants -- but it can force one at the point where the metadata changes (a new scene) in the JSON file and add an SEI to the i-frame [keyframe] implementing the new metadata.

So that kinda' puts the theory of the GOP length as the cause as less likely.
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net
jdobbs is offline   Reply With Quote
Old 9th August 2020, 10:22   #29840  |  Link
cartman0208
Registered User
 
Join Date: Jun 2010
Location: Germany
Posts: 131
Quote:
Originally Posted by jdobbs View Post
After my last edit comment on my post, I'm not so sure. Since the JSON file contains data on every frame, it implies that the encoder can put a keyframe anywhere it wants -- but it can force one at the point where the metadata changes (a new scene) in the JSON file and add an SEI to the i-frame [keyframe] implementing the new metadata.

So that kinda' puts the theory of the GOP length as the cause as less likely.
OK, as you said... I had a look at source and output and the Keyframes match .. so that should not be the issue ...
I'll do some more testing on other sources
If that is fruitless, maybe we could join in here

[edit]
I ran several encodes with NVEnc ... all the same flickering while playing.
Then I decided to make a SW encode and despite the fact that Mediainfo is almost identical, the SW encoded file with HDR10+ Metadata looked very good on my TV

Last edited by cartman0208; 9th August 2020 at 22:35.
cartman0208 is offline   Reply With Quote
Reply

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 09:55.


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