BD Rebuilder Beta - Bug Reports Only

[colinhunt]

Originally Posted by jdobbs

I'm surprise I haven't gotten this reported before

I have a feeling I probably did, or at least tried to, quite a long time ago... but it's likely I didn't provide you with enough data back then.

I'm pretty sure that is the issue you're experiencing. I'll get a fix in for the next release. It might be a few days, though, as I want to also address Sharc's issue in that release as well.

This is fantastic news - looking forward to testing the fix! Thank you!

[jdobbs]

Originally Posted by colinhunt

I have a feeling I probably did, or at least tried to, quite a long time ago... but it's likely I didn't provide you with enough data back then.


This is fantastic news - looking forward to testing the fix! Thank you!

Fixed for the next release.

[jdobbs]

@Sharc

I started looking at the issue you reported -- and, while it's been awhile since I worked on it, I don't think I ever intended for output to SBS to work with full backups. It was meant for Movie-Only (mainly ALTERNATE output).

So the question is: Are you reporting this as a bug because setting that flag is causing issues on full backups (when it shouldn't) -- or do you actually want to create a full backup in which all the 3D sources are converted to SBS? The only reason I can think that anyone would ever want the latter is if they have a 3D monitor hooked up to a 2D player. That seems counter-intuitive since a 3D monitor is a lot more expensive than a 3D player.

Can you clarify?

[Lathe]

Originally Posted by MrVideo

You can't rip out the AC3 core and have AC3 5.1 to put back into a Blu-ray. If you rip out the AC3 core, you are left with only the TrueHD portion. While doing some digging, I found an old posting:

So, if you have a MKV file that contains only AC3, because the TrueHD was thrown away, there is no way to get back the TrueHD.

As for mkvmerge's handling of TrueHD+AC3, I found the following:


Now comes the tricky part. If you've created a MKV file with a newer mkvmerge, so that you have both audio tracks, getting it back into the required Blu-ray spec is going to be tough. Why? Because the two audio tracks must be interleaved in a very special way. The first quote seems to imply that eac3to can be used to interleave the two streams into a single TrueHD+AC3 for Blu-ray use. I've never tried it.

Yes, my friend... But, you are overthinking it... All I am saying is that when you have an MKV file that MediaInfo SHOWS has a TrueHD audio stream, that stream has had the core removed. So, simply by using UsEac3to (or eac3to) you can generate and add back in the AC3 core. I've done it many times.

This guy above says that when he tries to mux his MKV file into a playable Blu-ray, the resulting file is only the AC3 @640 part of it. I don't know the 'ins & outs' of it in detail, but quite a while ago I was having the exact same thing happen and I found threads (probably here) that explained how to use eac3to to add the 'core' back in so that TSMuxer can recognize and process it.

That's all...

[Sharc]

Originally Posted by jdobbs

@Sharc

I started looking at the issue you reported -- and, while it's been awhile since I worked on it, I don't think I ever intended for output to SBS to work with full backups. It was meant for Movie-Only (mainly ALTERNATE output).

So the question is: Are you reporting this as a bug because setting that flag is causing issues on full backups (when it shouldn't) -- or do you actually want to create a full backup in which all the 3D sources are converted to SBS? The only reason I can think that anyone would ever want the latter is if they have a 3D monitor hooked up to a 2D player. That seems counter-intuitive since a 3D monitor is a lot more expensive than a 3D player.

Can you clarify?

I reported is as a bug, but probably I mis-interpreted the documentation: The selection in the setting menu is indeed for "Enable 3D SBS/OU Movie-only output", but from the changes.txt:

April 7th, 2014 - v0.47.04
- Implemented 3D Full Backup Mode. Note that
BD-RB converts 3D method so that the SSIF
folder is no longer required -- the method
is 100% compliant with the BD standard.
(v0.47.03)

So my (generous) conclusion was that when selecting "Full backup" plus "Enable 3D SBS/OU Movie-only output", the feature will be encoded SBS and the rest (menus + extras) will be encoded as in-muxed MVC/FRIM. I found that this actually happens with the files, but the disc is not playable (because playlists and clpi are not processed accordingly, I think).

But as you write SBS has been intended for Movie-only, it's not a bug, and I shouldn't select "Full backup".
Could it be read as a feature request? Well, I understand that the 3D wave seems to have swapped over us, so maybe it's not worth the efforts....

[jdobbs]

Originally Posted by Sharc

I reported is as a bug, but probably I mis-interpreted the documentation: The selection in the setting menu is indeed for "Enable 3D SBS/OU Movie-only output", but from the changes.txt:

So my (generous) conclusion was that when selecting "Full backup" plus "Enable 3D SBS/OU Movie-only output", the feature will be encoded SBS and the rest (menus + extras) will be encoded as in-muxed MVC/FRIM. I found that this actually happens with the files, but the disc is not playable (because playlists and clpi are not processed accordingly, I think).

But as you write SBS has been intended for Movie-only, it's not a bug, and I shouldn't select "Full backup".
Could it be read as a feature request? Well, I understand that the 3D wave seems to have swapped over us, so maybe it's not worth the efforts....

The interesting thing is that whether I meant to or not, the setting does have an effect on full backup mode. So I have to either fix that, or make it work for both modes.

[Lathe]

Hmmm, for some odd (but excellent) reason, now with this current version my CRF is working for the very first time. As my log of the running process shows below, the constant rate factor IS indeed being used in the current pass encode, and this for the very first time ever! So, that is good...

I was curious though, the log also shows a set output size (my poor@ss guess, really) BUT, it is indeed using the constant rate factor on the 2nd video stream, and I'm assuming that it will also do so on the last video stream, which is the primary movie file.

Sooooo... why is it showing an output size...?

----------------------
[01/13/17] BD Rebuilder v0.50.20
[21:35:49] Source: VID00000
- Input BD size: 29.49 GB
- Approximate total content: [02:04:23.014]
- Target BD size: 14.36 GB
- Windows Version: 6.2 [9200]
- Quality: High Quality (Default), CRF
- X264 Tweak(s) enabled
- Decoding/Frame serving: DirectShow
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=192
[21:35:49] PHASE ONE, Encoding
- [21:35:49] Processing: VID_00003 (1 of 3)
- [21:35:49] Extracting A/V streams [VID_00003]
- [21:35:55] Reencoding video [VID_00003]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 1,374 frames
- [21:35:55] Reencoding: VID_00003, Pass 1 of 1
- [21:36:24] Video Encode complete
- [21:36:24] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [21:36:24] Multiplexing M2TS
- [21:36:28] Processing: VID_00004 (2 of 3)
- [21:36:28] Extracting A/V streams [VID_00004]
- [21:37:03] Reencoding video [VID_00004]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 34,330 frames
- [21:37:03] Encoding using constant rate factor.


My ini:

[Options]
VERSION=0.50.0.20
ENCODER=0
MODE=0
ENCODE_QUALITY=2

TWEAK_PASS_TWO=--ref 4 --deblock -3:-3 --psy-rd 1.00:0.25 --me umh --subme 8 --trellis 2 --direct auto
ONEPASS_ENCODING=1
IVTC_480i=0
IVTC_METHOD=0
AUTO_QUALITY=0
FIXED_CRF=20
AUTO_BIAS=3
B_PYRAMID=1
QUICK_CRF=24
ENABLE_TEST=1
ENABLE_BLANKING=1

ARCHIVE_ENABLE=1
ARCHIVE_LIMIT=1
ARCHIVE_265=0
ARCHIVE_AUDIO_100
ARCHIVE_CRF=18

KEEP_HD_LPCM=1
USE_ZLIB=0

ALTERNATE_BLURAY=0
ENCODER_MENU=1
MBTREE=1

MENU_BACKGROUND=D:\EXECUTABLES\BD-RBV05017\BD_Rebuilder\misc\menuback.jpg
MENU_AUDIO=D:\EXECUTABLES\BD-RBV05017\BD_Rebuilder\tools\blankclip\blank.ac3
IMPORT_THRESHOLD=1
QUICK_PLAY_THRESHOLD=1
MENU_AUTO_BACKGROUND=1
MENU_AUTO_DVDAUDIO=1
AUTO_QUALITY=0
AUDIO_TO_KEEP=eng;
SUBS_TO_KEEP=eng;

SD_CONVERT=0
OPEN_GOP=0
RESIZE_1080=0
RESIZE_1440=0
RESIZE_720=0
DEINTERLACE=1
SD_TO_1080=0
IGNORE_3D=1
CONVERT_WIDE=0
DTS_REENCODE=0
AC3_REENCODE=0
AC3_640=0
AC3_192=1
KEEP_HD_AUDIO=1
AUDIO_DRC=0
DECODER=0
AVCHD=1
REMOVE_WORKFILES=0
REMOVE_OUTPUT=0
USE_FILTERS=0
BDMV_CERT_ONLY=0
IVTC_PULLDOWN=0
ASSUME_DVD_PAL=0
FRIMSOURCE=0
COMPLETION_BEEP=0
OUTPUT_SBS=0
NEROAAC=0
SUPTITLE=0
PGSTOSRT=0
AUDIO_TRACK_LIMIT=0
SUBTITLE_TRACK_LIMIT=0
CUSTOM_TARGET_SIZE=14700
TARGET_SIZE=23700
PRIORITY_CLASS=0
QUICK_EXTRAS=1
WIDE_PERCENT=40
WIDE_OFFSET=.85
AVSFilter01=Sharpen(.3)
[Paths]
WORKING_PATH=C:\_______MEDIA\_BDRB\
SOURCE_PATH=J:\_______VID00000

[Lathe]

So, the encode finished and coincidentally the overall finished size was about 14.6 Gigs... Uh, that was uncannily very close to the wild 'guess' I made when I set the output size (see above)

BUT... the video was definitely using a CRF of 20 when it re-encoded. Sooooo, was I just amazingly brilliant in my guess as to what I THOUGHT the output size should be using a CRF of 20, or did BDRB in some way use the expected output size even though it did indeed use CRF 1 pass on the encode...???

I thought when you use CRF 1 pass that the output size is disregarded, right...? So:

1. Why did the log file show an intended output size...?

2. Although definitely using a CRF 1 pass encode, how the hell could have hit so close to what I just happened to have put in as an output size...?

3. When using CRF 1 pass, shouldn't the output size be greyed out anyway?

I mean, I am ecstatic that the CRF is finally working and I'm not getting the constant, stupid, meaningless, and inaccurate 'AnyDVD short titles' error that I ALWAYS got before when I tried to use CRF encoding, but I don't understand how the supposedly 'disregarded' output size factored into it this time.

[gonca]

Can you post LASTCMD.txt Lathe?

[jdobbs]

Originally Posted by Lathe

So, the encode finished and coincidentally the overall finished size was about 14.6 Gigs... Uh, that was uncannily very close to the wild 'guess' I made when I set the output size (see above)

BUT... the video was definitely using a CRF of 20 when it re-encoded. Sooooo, was I just amazingly brilliant in my guess as to what I THOUGHT the output size should be using a CRF of 20, or did BDRB in some way use the expected output size even though it did indeed use CRF 1 pass on the encode...???

I thought when you use CRF 1 pass that the output size is disregarded, right...? So:

1. Why did the log file show an intended output size...?

2. Although definitely using a CRF 1 pass encode, how the hell could have hit so close to what I just happened to have put in as an output size...?

3. When using CRF 1 pass, shouldn't the output size be greyed out anyway?

I mean, I am ecstatic that the CRF is finally working and I'm not getting the constant, stupid, meaningless, and inaccurate 'AnyDVD short titles' error that I ALWAYS got before when I tried to use CRF encoding, but I don't understand how the supposedly 'disregarded' output size factored into it this time.

Choosing CRF should hit your target. BD-RB is supposed to do a couple of sample passes to predict what CRF is needed to hit the target. But I didn't see the prediction in you log...

[edit]. Oh, I see, you used a forced CRF. That just means you had a lucky guess at the CRF needed to hit your output size.

The target size will show in the log, even if you've chosen to ignore it.

[jdobbs]

Originally Posted by Sharc

Could it be read as a feature request? Well, I understand that the 3D wave seems to have swapped over us, so maybe it's not worth the efforts....

Can you give me an example of where it would be useful? I don't think I get the actual application of such an output? If the extras, etc., were encoded in normal (in-mux) 3D -- that would imply you have a 3D player. So what is the advantage of having the feature in SBS format?

[Sharc]

Originally Posted by jdobbs

Can you give me an example of where it would be useful? I don't think I get the actual application of such an output? If the extras, etc., were encoded in normal (in-mux) 3D -- that would imply you have a 3D player. So what is the advantage of having the feature in SBS format?

Yes, I do have a 3D player. My justification of SBS is the compression for the NAS. SBS gives better visual quality than MVC/FRIM when compressing to <<BD25. So I could make a full disc backup say at CRF20 which results in an SBS feature size of say 6 .. 10GB (depending on the source of course). I can then copy the compressed SBS feature .m2ts to the NAS for streaming and keep the full backup on a (underutilized) BD25 with the menu and Extras.
It is not terribly important, so you could perhaps just gray out the "Enable 3D SBS/OU movie-only output" when "Full backup" is selected which would prevent users to produce non-playable discs.

[Lathe]

Originally Posted by jdobbs

Choosing CRF should hit your target. BD-RB is supposed to do a couple of sample passes to predict what CRF is needed to hit the target. But I didn't see the prediction in you log...

[edit]. Oh, I see, you used a forced CRF. That just means you had a lucky guess at the CRF needed to hit your output size.

The target size will show in the log, even if you've chosen to ignore it.

Oh, I see (I think...) So, when choosing CRF 1 pass generally, you WOULD select an output size and BDRB would then approximate what CRF value to use to render that output size, right?

BUT... if you use FORCED CRF as I have in my ini, THEN BDRB, although showing whatever output size was entered, goes ahead and just uses the Forced CRF and ignores the output size, right?

This is just frigg'n AWESOME man because this is the very first time it has actually worked without throwing that stupid error!

[geheim]

@jdobbs
Did you ever look into the issue where 3D subtitle depth is lost if reencoding with FRIM?? You said some time ago that you would try if it would be possible to set a constant depth value to the Subs which would be good because flat subtitles often cut through objects in 3D movies which makes a bad visual Feeling...
Thanks for your effort!

[raul124]

Originally Posted by geheim

@jdobbs
Did you ever look into the issue where 3D subtitle depth is lost if reencoding with FRIM?? You said some time ago that you would try if it would be possible to set a constant depth value to the Subs which would be good because flat subtitles often cut through objects in 3D movies which makes a bad visual Feeling...
Thanks for your effort!

I too need to turn off the subtitles because of bad visual feeling.

[LowDead]

@jdobbs: Seems to be problem with the clpi files. The header looks wrong, should be HDMV0100 for AVCHD, now it only says HDMV. Tried to hexedit that but didn't help. So seems to be more problem with that as BDedit complains about the file packets and also no info comes up. index.bdmv, MovieObject.bdmv and the mpls files looks to be fine.

/LD

[MrVideo]

I found a minor bug with the Page/Prev/Next labels.

It seems that the left margin of the page label is set to the left margin of the selection text. The right margin of the prev/next text is equal to the right margin of the selection text.

The problem is that when the titles of the selection text is only one word long, the total length is too short, resulting in the text for PREV to be situated on top of the page # text.

I think the temporary cure, in my case, is to put a bunch of spaces at the end of the text of one of the titles.

[jdobbs]

Originally Posted by LowDead

@jdobbs: Seems to be problem with the clpi files. The header looks wrong, should be HDMV0100 for AVCHD, now it only says HDMV. Tried to hexedit that but didn't help. So seems to be more problem with that as BDedit complains about the file packets and also no info comes up. index.bdmv, MovieObject.bdmv and the mpls files looks to be fine.

/LD

Have you run any other software on them or edited them? I just checked several AVCHD titles that I've done recently -- and they all have the HDMV0100 header and BDEdit opens them fine. I'll do a couple more as a test and see if I can find anything.

[Edit] Never mind. I found it. It has been fixed for the next release. It can only happens when doing non-movie-only AVCHD backups.

[jdobbs]

I have updated the first post of this thread with a link to the latest version of BD-RB (v0.50.21). Changes for this release:

- Corrected an error in which 3D sources in
  SBS/OU output mode were not forced to be
  encoded when the original was small enough
  to fit on the target.
- Added a new hidden option. IVTC_1080p will
  force inverse telecining on 1080p sources
  that have a framerate of 29.97fps.  Care
  should be taken -- as this should only be
  set when you know the source was originally
  filmed at 24fps (23.976).
- Added a new filter prefix. "L:nnnnn". It
  applies the specified filter only when the
  M2TS being encoded is found in the playlist
  specified by "nnnnn". As an example, a line
  containing "l:00001Tweak(bright=10.0)" would
  increase the brightness only on video that
  is a part of playlist 00001.
- Corrected a "CreateQuickMenu(), 0000, 4020" 
  error that can occur when using a complex 
  font for a Quick Menu or Import.
- Fixed an issue in which reencoding audio to
  ALTERNATE/Auto-AC3 from an Auto-AC3 (VBR)
  source could result in blank output.
- Fixed an issue in which a 3D source feature
  that is flagged for the base view to be the
  right picture (atypical) was not carrying 
  over when outputting to a non-ALTERNATE 
  movie-only structure.  The result would be 
  an apparent swapped left/right picture.
- Corrected a problem in which .SRT files
  that had the same name (minus extension) as
  an imported file source were not being 
  imported on containers other than the .MKV 
  format.
- Fixed an issue in which selecting output to
  3D/SBS for movie-only encoding could have
  and unexpected impact on a full 3D backup. 
- Corrected a problem in which variable frame
  rate sources could, under certain conditions
  result in out-of-sync audio during the file 
  import process.
- Fixed an issue in which the HDMV header on
  CLPI files of AVCHD backups could be created 
  incorrectly.
- Updated the included version of X265.EXE to 
  the latest release (v2.2.17).
- Updated the included version of X265-64.EXE 
  to  the latest release (v2.2.17).
- Other minor corrections and cosmetic fixes.

[MrVideo]

Originally Posted by jdobbs

- Added a new hidden option. IVTC_1080p will
  force inverse telecining on 1080p sources
  that have a framerate of 29.97fps.  Care
  should be taken -- as this should only be
  set when you know the source was originally
  filmed at 24fps (23.976).

Dumb question. How can you IVTC 1080p video? 720p59.94, but not 1080p. IVTC is done on 1080i video.

1080p means that the 1080i was deinterlaced, making IVTC impossible.