BD Rebuilder Beta - Bug Reports Only

[colinhunt]

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 (http://forum.doom9.org/showthread.php?p=1793045#post1793045) in that release as well.
This is fantastic news - looking forward to testing the fix! Thank you!

[jdobbs]

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]

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]

@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]

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]

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]

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]

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]

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! :D

[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]

@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!:goodpost: 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]

@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.

/LDHave 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]

- 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.

[jdobbs]

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.Nope. That is an incorrect statement. I do it all the time. If you capture from satellite, for example, it's 1080p at 29.97fps. If you look at it (and it is an original film source) you'll see that every 5th frame is repeated. Telecining doesn't imply interlaced video. In this case it just represents converting 23.976fps original video to 29.97fps by repeating a frame. It's hard-telecined (meaning it doesn't use flags to create the additional frame). Mixing odd/even fields from two frames of an interlaced source to add an additional frame is one type of telecining -- but not the only one.

Anyway, it's meant as an additional tool for those who need it (like me), not as a focus for a debate on semantics.

[LowDead]

- Fixed an issue in which the HDMV header on
CLPI filse of AVCHD backups could be created
incorrectly.

Thanx. Will try it tonight.

//LD

[MrVideo]

If you look at it (and it is an original film source) you'll see that every 5th frame is repeated. Telecining doesn't imply interlaced video. In this case it just represents converting 23.976fps original video to 29.97fps by repeating a frame.
Must be DirecTV or Dish, since 1080p isn't allowed for ATSC compliant transmissions. All 1080 cable channel sources (AMC, TNT, etc.) that have scripted dramas will be 1080i 2:3 pulldown.

Here is some tidbit info. Warner Bros. programs that are fed to Canada (CTV, etc.) can either be 1080i 2:3 pulldown or 1080i repeat frame. If they feed from a file source, it is repeat frame. If they feed from a tape source, it is 2:3 pulldown. It is 1080i because it is for OTA.

Lately they have mostly been feeding from files. Programs include shows like Supergirl, Flash, Arrow, Big Bang Theory, Lucifer.

Oh, there are no 1080p feeds via my satellite captures. :rolleyes:

[jdobbs]

Must be DirecTV or Dish, since 1080p isn't allowed for ATSC compliant transmissions. All 1080 cable channel sources (AMC, TNT, etc.) that have scripted dramas will be 1080i 2:3 pulldown.

Here is some tidbit info. Warner Bros. programs that are fed to Canada (CTV, etc.) can either be 1080i 2:3 pulldown or 1080i repeat frame. If they feed from a file source, it is repeat frame. If they feed from a tape source, it is 2:3 pulldown. It is 1080i because it is for OTA.

Lately they have mostly been feeding from files. Programs include shows like Supergirl, Flash, Arrow, Big Bang Theory, Lucifer.

Oh, there are no 1080p feeds via my satellite captures. :rolleyes:The 1080i sources that have the repeated frame usually aren't actually 1080i. They are progressive (meaning there is no temporal difference between the two fields). So you have a 1080p source at 23.976 -- with a repeated frame thrown in to make it 29.97 that is just flagged as 1080i to make it compliant with ATSC transmission standards. That's a good thing -- because you can recover the original film source easily as progressive. It can also be true with those using pulldown flags.

Oh, there are no 1080p feeds via my satellite captures.Must be component capture, eh?

[jdobbs]

Thanx. Will try it tonight.

//LDSee if it fixes the playback problem on your old Sony player as well... I'm hoping it might.

[MrVideo]

The 1080i sources that have the repeated frame usually aren't actually 1080i. They are progressive (meaning there is no temporal difference between the two fields). So you have a 1080p source at 23.976 -- with a repeated frame thrown in to make it 29.97 that is just flagged as 1080i to make it compliant with ATSC transmission standards. That's a good thing -- because you can recover the original film source easily as progressive. It can also be true with those using pulldown flags.
OK, I see where you are coming from. I strictly call 1080i video as 1080i video, even if it has progressive content. And yes, recovering the 23.976 content from the repeat frame source is easy with the AVS selectevery() filter. The 2:3 pulldown has a couple of AVS filter ways in which to do that. I then get true 1080p23.976. Plays nice and smooth that way.

GDMX does the 2:3 pulldown, or repeat frame, conversion on the fly. Their sources are 1080p23.976.

Must be component capture, eh?
Nope, direct satellite IRD (PCI card & USB) controlled via TSReader to TS (Transport Stream) file, or professional satellite IRD via ASI card/TSReader to TS file. 10' and 12' dishes.

[MrVideo]

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

[...]

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.

That worked. Until a permanent fix is found, I'll have to do this trick if I have more than one page and short title text.

[jdobbs]

OK, I see where you are coming from. I strictly call 1080i video as 1080i video, even if it has progressive content. And yes, recovering the 23.976 content from the repeat frame source is easy with the AVS selectevery() filter.Since the repeated frame might change at scene changes or cuts, I use Decimate(cycle=5) or tDecimate() depending upon the selection in the INI file.

[MrVideo]

Since the repeated frame might change at scene changes or cuts, I use Decimate(cycle=5) or tDecimate() depending upon the selection in the INI file.
Because my files are from the 1080p23.976 sub-masters, the repeat frame cadence is intact throughout the file. When I edit the file, with VideoReDo, to tighten up the commercial blacks, I remove frames in groups of 5, so that the cadence is kept. That way the selectevery() won't have an issue.

Using selectevery() with BDRB is possible, only if the user knows which frame is the first of the two repeat frames, and there is an INI setting for it. Not worth doing though.

The repeated frame should never change at scene changes. All scripted shows are produced/edited at 23.976. So, when converted to 2:3 pulldown or repeat frame, the cadence of either is kept throughout the telecined file. Only when commercials are added during play out can the cadence be lost. That is where editing programs like VideoReDo can allow you to edit telecined sources and get back the repeat frame cadence. But, my files do not have commercials, so that isn't a problem.

[LowDead]

See if it fixes the playback problem on your old Sony player as well... I'm hoping it might.

The clpi works in bdedit now and seems to be ok. No luck with the old sony though. I can't think of anything else to check. Would it be possible for you, if you have the time, to do a quick comparison with either multiAVCHD (with avchd output) or AVCHDCoder. The output from them both work in the old sony.

//LD

[Lathe]

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.

WOW! You were seriously busy JD! Thank you!

BTW, are there any updates with x264? I didn't notice any new versions in this build mentioned. Do you know if there are still any speed issues using it with LAVF? Is BDRB still using x264L-64.exe for LAVF?

[Sharc]

- Fixed an issue in which selecting output to
3D/SBS for movie-only encoding could have
and unexpected impact on a full 3D backup.

This means, when selecting "Full backup" mode the setting "Enable 3D SBS/OU for Movie-only output" is now just ignored, right?

[colinhunt]

I have updated the first post of this thread with a link to the latest version of BD-RB (v0.50.21).
Aww yeah - thank you! I'll start running tests immediately. Y'know, this might merit another donation from yours truly...

[Yordan5]

Interesting results. I shrank Jack Reacher Never Go Back (movie only) from approx. 28Gb to 14.5Gb twice for testing purposes. Using BD-RB Default settings (Auto Quality: Good (Very Fast), ABR) took approx 1h 50min and the resulting copy according to BDInfo was with 16mb average bitrate. Second job was with High Quality (Default), ABR and took 6hrs with the copy having average bitrate of 10Mb. I cannot see obvious difference in visual quality but thought that the Higher Quality setting should've produced higher bitrates copy. Might as well stick with the faster settings then.

[jdobbs]

The clpi works in bdedit now and seems to be ok. No luck with the old sony though. I can't think of anything else to check. Would it be possible for you, if you have the time, to do a quick comparison with either multiAVCHD (with avchd output) or AVCHDCoder. The output from them both work in the old sony.

//LDI know they aren't the same. I found a couple of inconsistencies in multiAVCHD that I corrected based upon the specification.

What I will do, though, is look for other things (like the header issue you reported).

[jdobbs]

WOW! You were seriously busy JD! Thank you!

BTW, are there any updates with x264? I didn't notice any new versions in this build mentioned. Do you know if there are still any speed issues using it with LAVF? Is BDRB still using x264L-64.exe for LAVF?That's a tough one for me -- as the speed issue seems to come and go at will when I'm testing it. For right now, yes, it is still using X264L-64.exe for LAVF.

[jdobbs]

This means, when selecting "Full backup" mode the setting "Enable 3D SBS/OU for Movie-only output" is now just ignored, right?Yes. So you can leave it checked and it shouldn't affect full backups anymore. I haven't given up on your request -- but I wanted to correct the obvious error for this release.

[jdobbs]

Interesting results. I shrank Jack Reacher Never Go Back (movie only) from approx. 28Gb to 14.5Gb twice for testing purposes. Using BD-RB Default settings (Auto Quality: Good (Very Fast), ABR) took approx 1h 50min and the resulting copy according to BDInfo was with 16mb average bitrate. Second job was with High Quality (Default), ABR and took 6hrs with the copy having average bitrate of 10Mb. I cannot see obvious difference in visual quality but thought that the Higher Quality setting should've produced higher bitrates copy. Might as well stick with the faster settings then.Actually it would be the opposite. Using high quality settings uses more "bells and whistles" (at the expense of encoding speed) that can get the same quality with a lesser size (lower bitrate). This was a CRF encode, I assume?

[Sharc]

I am still getting the error when trying to import HUFFYUV compressed .avi sources. I assume that the codec has not yet been added to the list (http://forum.doom9.org/showpost.php?p=1792828&postcount=25467) in v0.50.21, or do I miss something?

[LowDead]

I know they aren't the same. I found a couple of inconsistencies in multiAVCHD that I corrected based upon the specification.

What I will do, though, is look for other things (like the header issue you reported).

Thank you for looking into it. I also tested an avchd output made from tsMuxeR just to see and it too worked on both the old Sony and the PS3.

//LD

[jdobbs]

I am still getting the error when trying to import HUFFYUV compressed .avi sources. I assume that the codec has not yet been added to the list (http://forum.doom9.org/showpost.php?p=1792828&postcount=25467) in v0.50.21, or do I miss something?No. Sorry it hasn't. Just for testing, can you provide me with a short clip to use for importing?

[jdobbs]

Thank you for looking into it. I also tested an avchd output made from tsMuxeR just to see and it too worked on both the old Sony and the PS3.

//LDThe problem with TSMUXER is that it doesn't provide a capability to include a menu or to have multiple selectable items.

[LowDead]

The problem with TSMUXER is that it doesn't provide a capability to include a menu or to have multiple selectable items.

Yes, it was only a quick test.

//LD

[jdobbs]

Yes, it was only a quick test.

//LDTo be honest, at this point I think the problem is with the player... but I'm open to being proven wrong -- so I'll do some investigation.

I really wish I hadn't given that old Sony player away. I could sure use if for testing...

[MrVideo]

I really wish I hadn't given that old Sony player away. I could sure use if for testing...
I have a Sony BDP-S350 that you can have for the cost of shipping. I even have the original box. I will never use it again.

[Sharc]

No. Sorry it hasn't. Just for testing, can you provide me with a short clip to use for importing?
Here a .zip (http://www.mediafire.com/file/2hgacw58h1rc9n2/Captures.zip) with 3 samples of lossless captures in .avi container: HFYU (Huffyuv), ULY2 (from the UTVideo suite) and LAGS (Lagarith).
My preference for importing in BD-RB would be HFYU.

[colinhunt]

jdobbs, I hate to be the bearer of bad news... but I did Hobbit 3D disc 2 (movie only to .iso) on 05021, and the L/R views are still reversed.

[jdobbs]

Here a .zip (http://www.mediafire.com/file/2hgacw58h1rc9n2/Captures.zip) with 3 samples of lossless captures in .avi container: HFYU (Huffyuv), ULY2 (from the UTVideo suite) and LAGS (Lagarith).
My preference for importing in BD-RB would be HFYU.I assume you know that they will be converted to AVC when they are imported.

[jdobbs]

jdobbs, I hate to be the bearer of bad news... but I did Hobbit 3D disc 2 (movie only to .iso) on 05021, and the L/R views are still reversed.Which Hobbit? I have Hobbit, Desolation of Smaug, 3D (bought for a bug report) -- any chance that's the one?

Are you absolutely positive they are reversed? It's not something left over from a previous attempt? I tested it pretty thoroughly.

Outline exactly what you're doing and also provide the log and INI contents -- and I'll look at it. Also make sure you mention any "tweaking" you may be doing with other tools.

[Sharc]

I assume you know that they will be converted to AVC when they are imported.
Yes (same as DivX).

Edit:
Captures to x264 AVC lossless (format profile High 4:4:4 Predictive@L3) can be imported without conversion. I tested it with x264vfw which is available from Komisar or MasterNobody.