BD Rebuilder Beta - Bug Reports Only

[jdobbs]

Originally Posted by Groucho2004

This is the error when avisynth.dll is not in the System32 directory:


What's the reason for the restriction to that directory? When I load avisynth I use something like this:

HINSTANCE hDLL = ::LoadLibrary("avisynth");
if (!hDLL)
{
  sMsg = "Failed to load avisynth.dll";
  return FALSE;
}

It does not matter where avisynth.dll is as long as the "PATH" variable points to it.

That's where the installer puts the DLL. In other words, that's where it's supposed to be. I could always pull the path from the registry, I guess -- but then someone else would complain because the path has to be there. Why not just use the installer and avoid the problem?

[Groucho2004]

Originally Posted by jdobbs

That's where the installer puts the DLL. In other words, that's where it's supposed to be.

Fair enough.

Originally Posted by jdobbs

I could always pull the path from the registry, I guess

Which path?

[scotlandman]

Originally Posted by jdobbs

@scotlandman

You've given me a lot of information -- but haven't told me what issue you are having??? Does it not play back correctly?

@jdobbs

Thank you for your reply and yes you are correct the file would not play as 3D as somehow the MVC smaller file of the two was not included by BD Rebuilder in the ReEncode.

It basically missed the 00872.m2ts file and only encoded the 00800.m2ts file. So would only playback as 2D.

I'm sorry if all my information was slightly missleading I just wanted to provide you with as much as possible, to allow you to see for comparison

I hope this helps you as I would love to use BD Rebuilder to make 3D BD25 movie only backup copies

Kind Regards

Scotlandman

[jdobbs]

Originally Posted by scotlandman

@jdobbs

Thank you for your reply and yes you are correct the file would not play as 3D as somehow the MVC smaller file of the two was not included by BD Rebuilder in the ReEncode.

It basically missed the 00872.m2ts file and only encoded the 00800.m2ts file. So would only playback as 2D.

I'm sorry if all my information was slightly missleading I just wanted to provide you with as much as possible, to allow you to see for comparison

I hope this helps you as I would love to use BD Rebuilder to make 3D BD25 movie only backup copies

Kind Regards

Scotlandman

What you're saying would have no bearing upon whether or not it would play as 3D. The lead-in M2TS would have no effect in that way. The determination as to whether to play back the MVC dependent stream is provided by the MPLS.

Could you post your INI file (BDREBUILDER.INI located in the installation folder) -- what you posted is the INF file from that job, and it doesn't show your settings.

If the 00872.MPLS is the MVC portion of the playback -- then it wouldn't show up anyway except in the demuxing. But I don't know whether that is what is even what is being reported by MediaInfo.

[Sharc]

@jdobbs
My videocam produces 1920x1080@25i (true interlaced 50 temporal shifted fields per second), which I IMPORT with BD-RB.

I tried Alternate Output, .mkv container 1280x720, wanting to keep it interlaced in order to preserve the temporal resolution of the original.

With Video Encoding Option "Resize 1920x1080 to 1280x720" disabled, the interlaced source gets directly resized without field separation, and then encoded as 1280x720@25i (MBAFF)

#Created by BD Rebuilder - v0.47.06 (beta)
LoadPlugin("C:\Program Files VIDEO\DGdecNV\DGDecodeNV.dll")
DGSource("C:\TEMP\BD REBUILDER\WORKFILES\VID_00000.DGI", fieldop=0)
Spline16Resize(1280,720)
LoadPlugin("C:\Program Files Video\BD_Rebuilder\tools\autocrop.dll")
Autocrop(mode=0)
ConvertToYV12().AssumeFPS(25000,1000)

Is this possibly a bug? Shouldn't the interlaced source be field separated, resized on field basis and weaved before encoding?

I know I can encode using "BD or AVCHD compliant structure" at 1920x1080@25i or 1440x1080@25i (MBAFF, TFF) in order to preserve the temporal resolution, however this seems not to work with Alternate Output 1280x720). Maybe I miss something?

[jdobbs]

Originally Posted by Groucho2004

Fair enough.


Which path?

There's a SYSWOW64 path pointer in the registry for 64 bit systems, I'd have to check what exists for 32 bit.

In reality on a 64 bit system that's where the file physically exists after installation of the 32 bit application -- it is found via the redirector when you try to access it in system32. Why system32 is named "32" and holds 64 bit dlls is something only Microsoft could explain.

[jdobbs]

Originally Posted by Sharc

@jdobbs
My videocam produces 1920x1080@25i (true interlaced 50 temporal shifted fields per second), which I IMPORT with BD-RB.

I tried Alternate Output, .mkv container 1280x720, wanting to keep it interlaced in order to preserve the temporal resolution of the original.

With Video Encoding Option "Resize 1920x1080 to 1280x720" disabled, the interlaced source gets directly resized without field separation, and then encoded as 1280x720@25i (MBAFF)

#Created by BD Rebuilder - v0.47.06 (beta)
LoadPlugin("C:\Program Files VIDEO\DGdecNV\DGDecodeNV.dll")
DGSource("C:\TEMP\BD REBUILDER\WORKFILES\VID_00000.DGI", fieldop=0)
Spline16Resize(1280,720)
LoadPlugin("C:\Program Files Video\BD_Rebuilder\tools\autocrop.dll")
Autocrop(mode=0)
ConvertToYV12().AssumeFPS(25000,1000)

Is this possibly a bug? Shouldn't the interlaced source be field separated, resized on field basis and weaved before encoding?

I know I can encode using "BD or AVCHD compliant structure" at 1920x1080@25i or 1440x1080@25i (MBAFF, TFF) in order to preserve the temporal resolution, however this seems not to work with Alternate Output 1280x720). Maybe I miss something?

Yes it should be field separated for resizing, I'll look at that. But you shouldn't expect interlaced output to 720 -- as that should be a progressive format. In reality it should probably be written as 1280x720@50fps to keep the temporal differences.

[Edit]
After further thought, I guess there's really no mandate to prevent output at 720i -- it's just a little odd I guess. I don't think it falls into any broadcast standard.

[scotlandman]

Originally Posted by jdobbs

What you're saying would have no bearing upon whether or not it would play as 3D. The lead-in M2TS would have no effect in that way. The determination as to whether to play back the MVC dependent stream is provided by the MPLS.

Could you post your INI file (BDREBUILDER.INI located in the installation folder) -- what you posted is the INF file from that job, and it doesn't show your settings.

If the 00872.MPLS is the MVC portion of the playback -- then it wouldn't show up anyway except in the demuxing. But I don't know whether that is what is even what is being reported by MediaInfo.

Hi jdobbs

Thanks for letting me know this I wasn't aware of this information.

Here is my BD Rebuilder INI file that I use for each Encode.

[Options]
VERSION=0.47.0.6
ENCODER=0
MODE=3
ENCODE_QUALITY=3
ONEPASS_ENCODING=0
AUTO_QUALITY=0
TARGET_SIZE=24400
PRIORITY_CLASS=2
BD25_SIZE=24400
AUDIO_TO_KEEP=eng;
SUBS_TO_KEEP=all
SD_CONVERT=0
OPEN_GOP=0
RESIZE_1080=0
RESIZE_1440=0
RESIZE_720=0
DEINTERLACE=1
SD_TO_1080=0
IGNORE_3D=0
CONVERT_WIDE=0
DTS_REENCODE=0
AC3_REENCODE=0
AC3_640=1
AC3_192=0
KEEP_HD_AUDIO=1
AVCHD=1
REMOVE_WORKFILES=0
DGDECIM=0
REMOVE_OUTPUT=0
USE_FILTERS=0
BDMV_CERT_ONLY=0
USE_LAVF=0
IVTC_PULLDOWN=0
ASSUME_DVD_PAL=0
FRIMSOURCE=0
COMPLETION_BEEP=0
DGDECNV=0
OUTPUT_SBS=0
NEROAAC=0
SUPTITLE=0
AUDIO_TRACK_LIMIT=1
SUBTITLE_TRACK_LIMIT=0
CUSTOM_TARGET_SIZE=24400

I hope that this is helpful to you I am sorry if my previous attempts to give you information have not been helpful.

Kind Regards

Scotlandman

[jdobbs]

I hope that this is helpful to you I am sorry if my previous attempts to give you information have not been helpful.

No need to be sorry... I appreciate the information.

[Groucho2004]

Originally Posted by jdobbs

There's a SYSWOW64 path pointer in the registry for 64 bit systems, I'd have to check what exists for 32 bit.

I find it easy and safe to retrieve this information through environment variables. For example, if "PROGRAMFILES(X86)" is defined, you're on a 64 Bit OS. On a 64 Bit system, "WINDIR" + "\system32" and "WINDIR" + "\SysWOW64" are the system directories.

Originally Posted by jdobbs

Why system32 is named "32" and holds 64 bit dlls is something only Microsoft could explain.

This is probably the reason.

[scotlandman]

Originally Posted by jdobbs

No need to be sorry... I appreciate the information.

Thank you very much for your kind comments.

Just for further information I do not know if it is at all relevant.

I am running Windows 8.1 Pro in bootcamp in a new MAC Pro 6core 32GB RAM 1TB Flash memory Dual D700GPU

It is pretty awesome for your software as even in 2 pass Very slow completes in 3 hours few minutes

I just wandered if OS had any bearing on the result.

Thanks

[Cedvano]

Originally Posted by jdobbs

Each of those files are probably smaller than the minimum M2TS size for reencoding. You call them "big", but when you have 25 files that combined add up to only 3.5GB on a 25GB backup -- it certainly isn't what I'd call big.

I'd leave the settings as-is, that's you best course of action. The minimum M2TS size is there to save you unnecessary reencoding time. But if you are determined to reencode 25 additional small files... you can always add a smaller MIN_M2TS_SIZE to your INI file (see HIDDENOPTS.TXT).

I have put MIN M2TS and MIN MPLS in 0 or 1 and no more effect.
The bonus take +/- 200 MB / file

General
ID : 0 (0x0)
Complete name : D:\Final_Destination_4_3D\BDMV\STREAM\00001.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 266 MiB
Duration : 3mn 12s
Overall bit rate mode : Variable
Overall bit rate : 11.6 Mbps
Maximum Overall bit rate : 48.0 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : VC-1
Format profile : Advanced@L3
Codec ID : 234
Duration : 3mn 12s
Bit rate : 10.9 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Scan order : Bottom Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.176
Stream size : 250 MiB (94%)

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Format profile : Dolby Digital
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : 129
Duration : 3mn 12s
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel count : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 4.40 MiB (2%)

Text #1
ID : 4608 (0x1200)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 3mn 6s
Delay relative to video : 2s 269ms

Text #2
ID : 4609 (0x1201)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 3mn 6s
Delay relative to video : 2s 269ms

Text #3
ID : 4610 (0x1202)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 3mn 6s
Delay relative to video : 2s 269ms

Text #4
ID : 4611 (0x1203)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 3mn 6s
Delay relative to video : 2s 269ms

Text #5
ID : 4612 (0x1204)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 3mn 6s
Delay relative to video : 2s 269ms

Text #6
ID : 4613 (0x1205)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 3mn 6s
Delay relative to video : 2s 269ms

Text #7
ID : 4614 (0x1206)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 3mn 6s
Delay relative to video : 2s 269ms

Mediainfo on 1 file.

[Sharc]

Originally Posted by jdobbs

Yes it should be field separated for resizing, I'll look at that. But you shouldn't expect interlaced output to 720 -- as that should be a progressive format. In reality it should probably be written as 1280x720@50fps to keep the temporal differences.

[Edit]
After further thought, I guess there's really no mandate to prevent output at 720i -- it's just a little odd I guess. I don't think it falls into any broadcast standard.

Yes, you are right, 1280x720p@50fps (bobbed) for keeping the temporal differences would probably be closer to any standard. Temporal smoothness should outweigh the bob shimmer, I believe.

[jdobbs]

Originally Posted by Groucho2004

I find it easy and safe to retrieve this information through environment variables. For example, if "PROGRAMFILES(X86)" is defined, you're on a 64 Bit OS. On a 64 Bit system, "WINDIR" + "\system32" and "WINDIR" + "\SysWOW64" are the system directories.

I just look for "ProgramW6432" -- if it is there then the O/S is 64 bit, otherwise it is 32 bit.

This is probably the reason.

I was just throwing a cheap shot at Microsoft... I knew why they did it -- it's just counterintuitive, like so many things they do.

[AmigaFuture]

Update for Cloud Atlas chapters.. I bought an SSD and...reinstalled Windows 7, and the Chapters are okay now. I still have the SATA drive, so I'll check into it. I thought you might like an update.

[jdobbs]

Originally Posted by AmigaFuture

Update for Cloud Atlas chapters.. I bought an SSD and...reinstalled Windows 7, and the Chapters are okay now. I still have the SATA drive, so I'll check into it. I thought you might like an update.

Thanks.

[jdobbs]

@scotlandman

Originally Posted by jdobbs

If the 00872.MPLS is the MVC portion of the playback -- then it wouldn't show up anyway except in the demuxing. But I don't know whether that is what is even what is being reported by MediaInfo.

I picked up this disc and am running it. I was correct in assuming 00872 was the MVC portion of the disc. So it wouldn't show in the "Streams" list of BD-RB (as that M2TS is only the dependent view that is associated with 00895.M2TS). So it isn't "missing", as it shouldn't be there.

The job is currently running -- I will post results when it completes (it will likely be several hours).

I'm a little worried that while you said you are using the US version of the disc for which you sent me a link -- your encode's log referenced 00800.M2TS as if it were the file associated with MPLS 00800... but in the commercial disc I am encoding the proper M2TS is 00895, there isn't even a 00800.M2TS on the 3D disc (it only exists on the 2D disc that is included in the 4 disc package)...

[05/16/14] BD Rebuilder v0.47.07 (beta)
[18:06:32] Source:  MARVELS_THE_AVENGERS_3D_00800
  - Input BD size: 41.83 GB
  - Approximate total content: [02:22:54.899]
  - Target BD size: 23.83 GB
  - Windows Version: 6.1 [7601]
  - MOVIE-ONLY mode enabled
  - Quality: Highest (Very Slow), ABR
  - MVC 3D Output Mode enabled
  - Decoding/Frame serving: FRIMDecode
  - Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
[18:06:33] PHASE ONE, Encoding
 - [18:06:33] Processing: VID_00895 (1 of 1)
 - [18:06:33] Extracting A/V streams [VID_00895]
 - [18:16:39] Reencoding video [VID_00895]
   - Source Video: MPEG-4 (AVC), 1920x1080
   - Rate/Length: 23.976fps, 205,592 frames
   - Bitrate: 16,404 Kbs
   - Using FRIMEncoder for MVC encoding
 - [18:16:39] Reencoding: VID_00895, Pass 1 of 1

Are you positive you are using the original 3D disc and it was not pre-processed in any way? I'd hate to think I just threw away $40 (which I can't afford with my limited donations) on a wild goose chase.

[Edit]

The encode just completed. I used the INI settings provided, so the encode used all the settings exactly as reported. This included the "Highest (Very Slow)" setting which extended my encode time to 16 hours. The bottom line is that it completed with no issues, no problems were found when I examined the result, and the movie-only backup plays in 3D exactly as it should.

[Lathe]

Originally Posted by jdobbs

Borders are added to make it compliant. But it isn't done during the import, it is done when processing the imported source. If you look in the BDMV/STREAM folder of the import (the pseudo-BD source) you'll see a file with the extension .ADJ. This holds any adjustments that needs to be made to the source. It is a text file and is made up of AVISYNTH functions (like AddBorders()).

Please forgive me for quoting an older post, but to keep it brief, I did import a 'cropped' MKV file (2.40:1 I believe) and after processing, MediaInfo showed the resulting m2ts file to be the same (not 16x9)

Did I miss something?

Thank you JDobbs for a most excellent program; when I am able, I will definitely send you some funds

[jdobbs]

Originally Posted by Lathe

Please forgive me for quoting an older post, but to keep it brief, I did import a 'cropped' MKV file (2.40:1 I believe) and after processing, MediaInfo showed the resulting m2ts file to be the same (not 16x9)

Did I miss something?

Thank you JDobbs for a most excellent program; when I am able, I will definitely send you some funds

The import will not correct anything -- that's why the result is called a pseudo-BD. The corrections are made when the disc is re-encoded using the pseudo-BD as its source. You will find a folder called PSEUDO in the import folder. It contains the filters that will add borders, resize, or make audio adjustments to make the disc compliant.

The only time you can burn an imported folder to disc without re-encoding is if the source was 100% BD compliant -- and that is very rare.

I've done many imports from MKV in testing -- and BD-RB has always correctly for me.

[Lathe]

Originally Posted by jdobbs

The import will not correct anything -- that's why the result is called a pseudo-BD. The corrections are made when the disc is re-encoded using the pseudo-BD as its source. You will find a folder called PSEUDO in the import folder. It contains the filters that will add borders, resize, or make audio adjustments to make the disc compliant.

The only time you can burn an imported folder to disc without re-encoding is if the source was 100% BD compliant -- and that is very rare.

I've done many imports from MKV in testing -- and BD-RB has always correctly for me.

Thank you, but AFTER the full re-encode, shouldn't the resulting BDMV folder (stream/m2ts) be fully compliant? If so, why would after re-encoding MediaInfo show the resulting m2ts still to be 2.40:1...? Shouldn't the 'missing borders' be replaced once it is done re-encoding?


Here was the exchange that SEEMED to say 'Yes' about this:

ABADDON:

When using the new "Import" feature, and subsequently fully processing, will a video be "uncropped" to restore the compliant resolution (by adding black boarders) if necessary, or simply vertically stretched?
__________________

Last edited by abbadon; 1st October 2012 at 18:21.


omegaman7's Avatar

Quote:

Originally Posted by abbadon View Post
When using the new "Import" feature, and subsequently fully processing, will a video be "uncropped" to restore the compliant resolution (by adding black boarders) if necessary, or simply vertically stretched?

I ran a cropped video recently. Clearly black borders were added in. It came out perfectly
__________________



abbadon

hmmm, that's what I figured was SUPPOSED to happen, but for some reason I keep getting stretch video instead of borders . It's just import and process, right? No extra/hidden options? I'm sure I'm missing something...



That is why I believe I am missing something

Appreciate your time!