BD Rebuilder Beta - Bug Reports Only

[daberti]

Originally Posted by jdobbs

1. That's correct. Although it may be used in next release, depending upon whether I get to it.
2. If you trim to less than 5000 frames, MULTIPROCESS will also not be used.

Great thanks
Great thanks also for your precious software.

Edit
The promised results: ALTERNATE, CRF20, 1080p, High Quality.
First with MULTIPROCESS=1
Last without.
In both cases High Quality brought about 100% CPU usage on all of 4 Cores.
----------------------
[09/08/14] BD Rebuilder v0.48.05 (beta)
[19:56:41] Source: L_UOMO_CHE_FISSA_LE_CAPRE_00000
- Input BD size: 20,18 GB
- Approximate total content: [01:34:03.971]
- Windows Version: 6.1 [7601]
- MOVIE-ONLY/ALTERNATE OUTPUT mode enabled
- Mode: MKV Container, 1920x1080, Auto-AAC
- Decoding/Frame serving: X264/LAVF
- Audio Settings: AC3=0 DTS=0 HD=0 Kbs=640
[19:56:45] PHASE ONE, Encoding
- [19:56:45] Processing: VID_00000 (1 of 1)
- [19:56:45] Extracting A/V streams [VID_00000]
- [20:07:03] Reencoding video [VID_00000]
- Source Video: VC-1, 1920x1080
- Rate/Length: 23,976fps, 135.320 frames
- [20:07:03] Reencoding: VID_00000, Pass 1 of 1
- [23:22:36] Video Encode complete
- [23:22:36] Processing audio tracks
- Track 4352 (ita): Reencoding audio to AAC...
[23:35:00]PHASE ONE complete
[23:35:00]PHASE TWO - Rebuild Started
- [23:35:00] Building ALTERNATE OUTPUT Structure
[23:36:47] - Encode and Rebuild complete
[23:36:47] JOB: L_UOMO_CHE_FISSA_LE_CAPRE finished.
----------------------
[09/09/14] BD Rebuilder v0.48.05 (beta)
[09:27:06] Source: L_UOMO_CHE_FISSA_LE_CAPRE_00000
- Input BD size: 20,18 GB
- Approximate total content: [01:34:03.971]
- Windows Version: 6.1 [7601]
- MOVIE-ONLY/ALTERNATE OUTPUT mode enabled
- Mode: MKV Container, 1920x1080, Auto-AAC
- Decoding/Frame serving: X264/LAVF
- Audio Settings: AC3=0 DTS=0 HD=0 Kbs=640
[09:27:06] PHASE ONE, Encoding
- [09:27:06] Processing: VID_00000 (1 of 1)
- [09:27:06] Extracting A/V streams [VID_00000]
- [09:39:02] Reencoding video [VID_00000]
- Source Video: VC-1, 1920x1080
- Rate/Length: 23,976fps, 135.320 frames
- [09:39:02] Reencoding: VID_00000, Pass 1 of 1
- [10:49:51] Video Encode complete
- [10:49:51] Processing audio tracks
- Track 4352 (ita): Reencoding audio to AAC...
[11:02:34]PHASE ONE complete
[11:02:34]PHASE TWO - Rebuild Started
- [11:02:34] Building ALTERNATE OUTPUT Structure
[11:02:48] - Encode and Rebuild complete
[11:02:48] JOB: L_UOMO_CHE_FISSA_LE_CAPRE finished.

[Sharc]

There seems to be no direct relation between the Auto Quality terminology and the x264 --preset.
For example (with AUTO_BIAS=3):
- Auto Quality: Good (Very Fast), Two pass
- lastcmd.txt: --preset superfast
(the reduction source/target is 36/23 GB)
Is this possibly a bug, or does BD-RB just use its own terminology?

[jdobbs]

Originally Posted by Sharc

There seems to be no direct relation between the Auto Quality terminology and the x264 --preset.
For example (with AUTO_BIAS=3):
- Auto Quality: Good (Very Fast), Two pass
- lastcmd.txt: --preset superfast
(the reduction source/target is 36/23 GB)
Is this possibly a bug, or does BD-RB just use its own terminology?

BD-RB uses its own terminology, mainly to avoid confusion. I don't believe the settings in X264 are clear, in terms of actual quality, to most people. For example, you get a very high level of quality that is appropriate for almost all encodes with the "medium" preset -- but the term "medium" doesn't reflect that. The X264 presets represent speed more than quality (fast, veryfast, slow, slower, etc.).

[Sharc]

Originally Posted by jdobbs

BD-RB uses its own terminology, mainly to avoid confusion. I don't believe the settings in X264 are clear, in terms of actual quality, to most people. For example, you get a very high level of quality that is appropriate for almost all encodes with the "medium" preset -- but the term "medium" doesn't reflect that. The X264 presets represent speed more than quality (fast, veryfast, slow, slower, etc.).

o.k., thanks. Nice to see how fast it goes; I changed from BD5/9 to BD25 only recently.

[Lathe]

Since we are SORT of talking about speed, I'm curious about something. I had upgraded to the newest version and for some odd reason I guess I must have forgotten to set the 'Use internal LAVF' like I always do (I never really do any resizing or anything other than occasionally throw in some x264 tweaks) So, I'm running this encode overnight and normally say I have it set for High Quality 2 Pass and a few x264 tweaks; usually a Blu-ray of about 28 Gigs or so would take about an hour or a bit more for the first pass and then about maybe 6-8 hours or so for the second pass.

Well, when I went to bed I noticed on the screen that the frame server being used was Directshow, which I normally never use; I am guessing that it is the default setting. Anyway, when I got up this morning and looked at it, it had already run about 9 hours and it has about another 8 to go! Also, I did notice before going to bed that the frame rate for the first pass seemed slower than usual.

I am just curious since I happened inadvertently to use Directshow this time, with all other things being equal, why would it take so much longer and be so much slower (fps @ about 2.5 instead of with LAVF about 6-7)? My CPU is normally topped out; now, it is pretty close to that, maybe running at about 90-95%.

And this time, I was looking forward to it maybe being a little faster because I am using my new SSD drive. Appreciate any insight...

[omegaman7]

Had a dvd encode recently take 6hrs using X264 frameserving. I usually use DGDecNV, but since I was watching some videos at the same time, I switched it. My CPU usage was averaging 22 - 30%. Not sure what could have caused this. Been pretty busy, so I haven't been able to post. I'll have to see if I can repeat this. Because my recent reorganizing has lost the information

JD, the HC encoder is used for DVD, eh? Is it 6 core capable?

I noticed the progress now shows pass 2 for DVD's. Is it possible that this change has caused the slowness?

[Sharc]

Originally Posted by Lathe

....normally say I have it set for High Quality 2 Pass and a few x264 tweaks; ....
....I am just curious since I happened inadvertently to use Directshow this time, with all other things being equal, why would it take so much longer .....

Did you parhaps make any changes to your "few x264 tweaks"; or setting QUALITY_ULTRA=..... ?

[Capsbackup]

I noticed this too a week or so back.
This was the explanation.

Originally Posted by omegaman7

I noticed the progress now shows pass 2 for DVD's. Is it possible that this change has caused the slowness?

Originally Posted by jdobbs

It always did a 2 pass encode, I just changed the way it is presented to better reflect it. In previous versions the 2nd pass started at 50%...

[omegaman7]

I'm simply wondering if the code somehow had an adverse reaction I suppose it would be quite a stretch. And I know damn near nothing about coding.

[Lathe]

Originally Posted by Sharc

Did you parhaps make any changes to your "few x264 tweaks"; or setting QUALITY_ULTRA=..... ?

Oh no, nothing like that; just what I always use when I want to fine tune an encode. Everything is the same that I usually do except that I unintentionally must have left the frame server as the default which I guess is Directshow.

I have about 4 more hours to go (I just got back from work) AND, I've had an unrelated issue for quite a while where my computer freezes for no apparent reason. So, I'm holding my breath and hoping that it gets through this unusual marathon encode for the next 4 hours

[jdobbs]

Originally Posted by omegaman7

Had a dvd encode recently take 6hrs using X264 frameserving. I usually use DGDecNV, but since I was watching some videos at the same time, I switched it. My CPU usage was averaging 22 - 30%. Not sure what could have caused this. Been pretty busy, so I haven't been able to post. I'll have to see if I can repeat this. Because my recent reorganizing has lost the information

JD, the HC encoder is used for DVD, eh? Is it 6 core capable?

I noticed the progress now shows pass 2 for DVD's. Is it possible that this change has caused the slowness?

It is multi-threaded, but I don't how far it takes it.

[Lathe]

Hmmm, I wonder if I somehow changed something without realizing it...? I am running another encode tonight and I DID change the frame server back to LAVF like I usually use. Granted, this Blu-ray is almost 35 Gigs which would make some difference, but still the first pass, with all my usual settings which normally takes about 1 to 1 1/2 hours took about 2 hours 10 minutes and the 2nd pass is slated to take like 15 hours! Very strange; it has never taken that long before. I wonder if something is different with this new version (4805) or if I have missed something somewhere. I'm working off my SSD drive too. Quite odd...

One interesting difference though, is that when using the directshow frame server, when it began it's first pass I got a runtime error prompt (one that I have been getting at times when using x264 - I attached a picture of it a page or two earlier here on this thread) I clicked 'OK' and it continued. And then when it began it's 2nd pass, I got the same error again and it wouldn't continue until I had clicked 'OK'. However, tonight with LAVF, it smoothly began both passes just fine without any prompts.

Maybe my machine is haunted...

[omegaman7]

Any changes to how Pseudo files are created?

[jdobbs]

Originally Posted by Lathe

Hmmm, I wonder if I somehow changed something without realizing it...? I am running another encode tonight and I DID change the frame server back to LAVF like I usually use. Granted, this Blu-ray is almost 35 Gigs which would make some difference, but still the first pass, with all my usual settings which normally takes about 1 to 1 1/2 hours took about 2 hours 10 minutes and the 2nd pass is slated to take like 15 hours! Very strange; it has never taken that long before. I wonder if something is different with this new version (4805) or if I have missed something somewhere. I'm working off my SSD drive too. Quite odd...

One interesting difference though, is that when using the directshow frame server, when it began it's first pass I got a runtime error prompt (one that I have been getting at times when using x264 - I attached a picture of it a page or two earlier here on this thread) I clicked 'OK' and it continued. And then when it began it's 2nd pass, I got the same error again and it wouldn't continue until I had clicked 'OK'. However, tonight with LAVF, it smoothly began both passes just fine without any prompts.

Maybe my machine is haunted...

The size of the input disc isn't really that important in terms of encode time. How many frames are you encoding?

As for the default changing to Directshow... there used to be a different indicator in the INI for each possible decoder. There now is only one that has a value set for each of the possible decoders. So as of a couple of versions back, you will default to Directshow until you change it. It will then stay with your choice until you change it again.

[jdobbs]

Originally Posted by omegaman7

Any changes to how Pseudo files are created?

No changes.

[Lathe]

Originally Posted by jdobbs

The size of the input disc isn't really that important in terms of encode time. How many frames are you encoding?

As for the default changing to Directshow... there used to be a different indicator in the INI for each possible decoder. There now is only one that has a value set for each of the possible decoders. So as of a couple of versions back, you will default to Directshow until you change it. It will then stay with your choice until you change it again.

Thanks for letting me know. Unfortunately my comp DID crash during the encode last night, so I don't have the specs; but, I will carefully check it out when I try again.

[jdobbs]

Originally Posted by Lathe

Thanks for letting me know. Unfortunately my comp DID crash during the encode last night, so I don't have the specs; but, I will carefully check it out when I try again.

If x264 is crashing on your system (as you mentioned earlier), it's highly probable your system isn't stable. I'd open up the box and see if you have accumulated dust on your processor heatsink that may be causing overheating.

[Lathe]

Originally Posted by jdobbs

If x264 is crashing on your system (as you mentioned earlier), it's highly probable your system isn't stable. I'd open up the box and see if you have accumulated dust on your processor heatsink that may be causing overheating.

Excellent suggestion; thanks JD.

[daberti]

Originally Posted by Lathe

Excellent suggestion; thanks JD.

It would be a good idea to install a temperature monitoring sw like CoreTemp.
It also has Temperature limiting features.

@JD
I've noticed that with CRF elapsed a certain amount of time the X264 encoding speed greatly improves.
I suspect the first 30% or alike is done before speed increase.
Could you please explain?

Thanks

[jdobbs]

Originally Posted by daberti

It would be a good idea to install a temperature monitoring sw like CoreTemp.
It also has Temperature limiting features.

@JD
I've noticed that with CRF elapsed a certain amount of time the X264 encoding speed greatly improves.
I suspect the first 30% or alike is done before speed increase.
Could you please explain?

Thanks

I can think of no reason why the speed would change mid-encoding. It may be possible that there was some high level of complexity in the first 30%, but that's unlikely. It's more likely it is something other than BD-RB/X264. Perhaps some background process was running on your PC?