BD Rebuilder Beta - Bug Reports Only

[cartman0208]

Originally Posted by jdobbs

It should be keeping the current configuration -- including BT.709. Are you saying it isn't?

Source files are BT.709 with 4K resolution, after BDRB conversion it's BT.2020

[cartman0208]

Unfortunately the issue with european punctuation still exists

- [20:02:14] Reencoding video [VID_00000]
- Source Video: HEVC, 3840x2160
- Rate/Length: 23,976fps, 128.721 frames
- [20:02:14] Performing CQM Prediction...
- Analyzing 1,00 [20:02:23] - Failed video encode, aborted

Changeing punctuation works

- [20:10:04] Reencoding video [VID_00000]
- Source Video: HEVC, 3840x2160
- Rate/Length: 23.976fps, 128,721 frames
- [20:10:04] Performing CQM Prediction...
- Analyzing 1.00 [1.00]
- [20:10:53] Encoding using constant quality mode.

[Sharc]

@jdobbs/cartman:
Just wondering: Is the initial value of 1.0 for the prediction intentional or is it possibly a bug?
It looks like the 128,721 frames are interpreted as 128 frames (a thousands separator issue, I think). Hence it selects the rate factor 1.0.

Edit: Here the frame numbers show with the usual high comma like 175'243 frames and the initial rate factor is 14.5. All ok......

[cartman0208]

Originally Posted by Sharc

@jdobbs/cartman:
Just wondering: Is the initial value of 1.0 for the prediction intentional or is it possibly a bug?
It looks like the 128,721 frames are interpreted as 128 frames (a thousands separator issue, I think). Hence it selects the rate factor 1.0.

Edit: Here the frame numbers show with the usual high comma like 175'243 frames and the initial rate factor is 14.5. All ok......

Good thinking ... If I set both the 1000s separator and decimal separator to "." (which usually is nowhere the case) the logging in the GUI stops completely, where the separator should be

- [21:58:02] Reencoding video [VID_00000]
- Source Video: HEVC, 3840x2160
- Rate/Length: 23.976fps, 128

BDREBUILDER.LOG:

- [21:58:02] Reencoding video [VID_00000]
- Source Video: HEVC, 3840x2160
- Rate/Length: 23.976fps, 128 721 frames
- [21:58:02] Performing CQM Prediction...
- Analyzing 1.00 [1.00]
- [21:58:51] Encoding using constant quality mode.

But even when the separators are set to " ' " and "." ... the initial (and only) number is 1.00 ... I will check the output size

[Sharc]

Something is odd with your settings.
The thousands grouping is a space char rather than ' in your system.
The decimal separator looks ok.
Hence BD RB still assumes a very short file and sets the ratefactor to 1.0 accordingly.
Try to change the thousands separator in your local windows settings.

[jdobbs]

Originally Posted by cartman0208

Source files are BT.709 with 4K resolution, after BDRB conversion it's BT.2020

Are they being imported, or are they from a UHD disc?

[jdobbs]

Originally Posted by cartman0208

Unfortunately the issue with european punctuation still exists



Changeing punctuation works

I am really confused. BD-RB scans the string and replaces any "," with a "."


I'll look at it again.

Can you look at the command line (LASTCMD.TXT) and see if the "," is still there?

[jdobbs]

Originally Posted by Sharc

Something is odd with your settings.
The thousands grouping is a space char rather than ' in your system.
The decimal separator looks ok.
Hence BD RB still assumes a very short file and sets the ratefactor to 1.0 accordingly.
Try to change the thousands separator in your local windows settings.

Is there a standard somewhere in which a ' is used instead of . or , in the thousands separator? I don't think I was aware of that.

So 1 million could be: 1,000,000.00 or 1.000.000,00 or 1'000'000,00?

[Sharc]

Originally Posted by jdobbs

I am really confused. BD-RB scans the string and replaces any "," with a "."


I'll look at it again.

Can you look at the command line (LASTCMD.TXT) and see if the "," is still there?

I think cartman's problem is the 1000s grouping character (which should be '), not the decimal point.

[Sharc]

Originally Posted by jdobbs

Is there a standard somewhere in which a ' is used instead of . or , in the thousands separator? I don't think I was aware of that.

So 1 million could be: 1,000,000.00 or 1.000.000,00 or 1'000'000,00?

I think the notation is a local (national) habit rather than a strict standard. It can therefore be customized in Windows how the numbers should be presented.

[jdobbs]

Originally Posted by Sharc

I think the notation is a local (national) habit rather than a strict standard. It can therefore be customized in Windows how the numbers should be presented.

Still confused as to how that value could be misinterpreted. BD-RB calculates the framecount. I can understand how a string being interpreted as a number could be an issue, or how a number being represented on the screen could show the wrong values because of local representations. But how can a number be misinterpreted when is doesn't change from a number (the actual framecount used in calculations)???

I guess I'm going to have to change my system to a European style locality setting and trace it to find out how this happens.

[Sharc]

Originally Posted by jdobbs

Still confused as to how that value could be misinterpreted. BD-RB calculates the framecount. I can understand how a string being interpreted as a number could be an issue, or how a number being represented on the screen could show the wrong values because of local representations. But how can a number be misinterpreted when is doesn't change from a number (the actual framecount used in calculations)???

I guess I'm going to have to change my system to a European style locality setting and trace it to find out how this happens.

No idea. Somewhere happening a conversion numbers <-> strings?
Windows secrets?

[jdobbs]

I just set my system so that the thousands separator is . and the decimal is , -- and it seems to be working properly. So I'm not sure why cartman0208 is getting an error.

@cartman0208

Can you give me some hints on settings that cause an issue? Ignore what is showing on the screen -- that doesn't matter right now. Are you getting errors when the encode is running? Can you show me the command line being used?

The new NVENC subroutine is structured after the original ones that did X265 encodes. I'm confused why it would be acting differently.

[Edit] I have to correct myself. There is an error -- I just realized the sample file was empty -- and OMG I was using a special system format call to create the string used for a seek command that tells it where to start! I must have been in lala land when I wrote that code. And why was it so hard for me to see when I reviewed it 10 times?

v061.09 should be coming in a little while. I just want to test it with the regional settings first.

[cartman0208]

Originally Posted by jdobbs

Are they being imported, or are they from a UHD disc?

I'll upload a sample ... could take a while

[cartman0208]

This is default in Germany


lastcmd is

"U:\BD_Rebuilder\tools\nvenc\nvencc.exe" --avhw -i "U:\FULLDISC\LUCYUHD\BDMV\STREAM\00000.m2ts" --codec hevc --preset quality --profile main10 --output-depth 10 --repeat-headers --chromaloc 2 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50) --max-cll 1000,400 --qp-min 0 --vbr 0 --vbr-quality 1 --aq-temporal --keyfile "U:\BD-OUTPUT\WORKFILES\VID_00000.CHP" --sar 1:1 --aud --pic-struct --vbv-bufsize 45000 --max-bitrate 48000 --gop-len 24 -o "U:\BD-OUTPUT\WORKFILES\VID_00000.AVS.hevc"

[cartman0208]

Originally Posted by jdobbs

[Edit] I have to correct myself. There is an error -- I just realized the sample file was empty -- and OMG I was using a special system format call to create the string used for a seek command that tells it where to start! I must have been in lala land when I wrote that code. And why was it so hard for me to see when I reviewed it 10 times?

v061.09 should be coming in a little while. I just want to test it with the regional settings first.

Good thing you sorted it out... I was beginning to believe that I messed up my system

[jdobbs]

I'm hoping this version fixes the regional issues reported:

BD-RB v0.61.09

@cartman0208

Can you confirm this is working on your system? Thanks.

Meanwhile I'm going to look at the BT.709 thing and how hard it would be to include HDR10+ in a future version.

One question: Was the BT.709 source an imported file, or was it BT.709 on an original UHD disc? That way I can know if it is the reencoding or the import that causes the mixup.

[cartman0208]

Originally Posted by jdobbs

One question: Was the BT.709 source an imported file, or was it BT.709 on an original UHD disc? That way I can know if it is the reencoding or the import that causes the mixup.

It's an original BD rip... the main movie is fine, also most of the extras

[Edit]
I did two rebuilds and both ran fine, but I still only get - Analyzing 1,00 [1,00] in the log .. at least for the main movie ... is that intended?
[Edit2]
Ok, the former applies only on some sources

[CraigWally]

I'm loving the speed gains on this latest version,
However
Is the "Quicker encode for extras" still working right

I've just tried to The Great Escape BluRay 1080,
and the extras have come out larger than the original with the main movie being compressed more than necessary

I'm just doing some further test, I'll post settings/ini etc later if necessary

EDIT: Hmmm, somethings not right here
If I choose "movie and menus / auto blank extras" - it chooses all the extras, rather than blanking them - seems to be just this disc?!

[jdobbs]

Originally Posted by cartman0208

It's an original BD rip... the main movie is fine, also most of the extras

[Edit]
I did two rebuilds and both ran fine, but I still only get - Analyzing 1,00 [1,00] in the log .. at least for the main movie ... is that intended?
[Edit2]
Ok, the former applies only on some sources

On the one where you get "Analyzing 1,00", can you look at the sample file and see its size? It would be named after the M2TS being sampled, so if the M2TS was 00058 it would be named 00058.AVS.SMPL.m2ts.

I would think the only time you would see a 1,00 would be when the source file was already extremely small. That would be unusual for a feature, you might see it for an extra (like something that hold several still pictures). I've run numerous jobs and I don't think I've ever seen it. It makes me think the sample file still has a length of zero.

Could you post the log from that job? Also, could you post the contents of the INF file for that job?