BD-Rebuilder, Feature Requests

[jdobbs]

When rebuilding a BD you can either keep all HD-audio or convert all HD-audio to AC3. Are you planning to implement a choice in this matter in the near future? So you can for instance convert the HD-audio of one stream to AC3 and keep the HD-audio of the rest of the streams?I have no near term plans for that. But I may do it when I have completed higher priority tasks.

There are lot more audio conversion choices than you mention. See this link (http://forum.doom9.org/showthread.php?p=1447836#post1447836) for specifics.

[Giljorak]

Would it be possible to get a hidden option to have the ability to use our own alternate.txt file? I have edited the current alternate.txt to better suit my needs and to create a few options that are not in the provided one.

When I download a new version of BD-RB I just remove the alternate.txt from the .zip file and then unzip as usual to my BD-RB program directory.


Thanks for the awesome program.

[meadrocks]

A better method for setting a fixed quality level is to use CRF (Constant Rate Factor). You can experiment and choose the quality level that meets your needs -- and let the size be determined by that. A CRF setting of 23 gives you good quality. A setting of 18 is virtually identical to the source. Lower settings raise output size and improves quality, higher settings lower quality and lowers size. You have to be careful, though, settings that are too low can be very wasteful. If you are using a setting below 16 or so you are likely wasting space without really getting much (if any) quality improvement.



So how do I go about setting the CRF to 20, as I don't really care about file size?

Also I use mkvmerge to make .mkv files. How can I make mp4 files from the .m2ts?

Lastly can I get chapter info in the mkv or mp4 files?

Thanks.

[jdobbs]

So how do I go about setting the CRF to 20, as I don't really care about file size?

Also I use mkvmerge to make .mkv files. How can I make mp4 files from the .m2ts?

Lastly can I get chapter info in the mkv or mp4 files?

Thanks.It's available on the dialog that let's you select the type of MKV output. It defaults to 23 -- just select it (checkbox), change the value to 20 and save.

[jdobbs]

Would it be possible to get a hidden option to have the ability to use our own alternate.txt file? I have edited the current alternate.txt to better suit my needs and to create a few options that are not in the provided one.

When I download a new version of BD-RB I just remove the alternate.txt from the .zip file and then unzip as usual to my BD-RB program directory.


Thanks for the awesome program.I can add that.

[musiclover]

I have no near term plans for that. But I may do it when I have completed higher priority tasks.

There are lot more audio conversion choices than you mention. See this link (http://forum.doom9.org/showthread.php?p=1447836#post1447836) for specifics.

I know there are more audio conversion choices. But not the one I need. Convert some HD audio and keep other HD audio streams.

[jdobbs]

I know there are more audio conversion choices. But not the one I need. Convert some HD audio and keep other HD audio streams.As I said, I have no plans for that in the near future. But I'll add it to my list.

[Giljorak]

I can add that.

:thanks:

[meadrocks]

It's available on the dialog that let's you select the type of MKV output. It defaults to 23 -- just select it (checkbox), change the value to 20 and save.

Well I did Pacific Rim @ 20 & it ended up @ almost 9 Gig. So I'm trying it @ 22, will compare the 2 to see if I see any difference. It should be a good test case since its an action movie with lots of fast moving graphics. I picked MP4 container, 1920x1080, auto-aac. I assume that's the highest video quality & its converting the audio to something smaller than True-HD.

[mparade]

If you have a fixed output size in mind -- it is best to do a two pass encode. It will give you the best quality level at a given size.

But... if a fixed quality is what you have in mind, you probably don't want to use size as your metric. Choosing 2.5 Gig/hour doesn't give consistent quality. Compression difficulty can vary greatly between sources. A high action film with complex images and constant scene changes can require much more bandwidth than, for example, a smoothly filmed source consisting of low motion. Animation (even CGI) generally needs less bandwidth also.

A better method for setting a fixed quality level is to use CRF (Constant Rate Factor). You can experiment and choose the quality level that meets your needs -- and let the size be determined by that. A CRF setting of 23 gives you good quality. A setting of 18 is virtually identical to the source. Lower settings raise output size and improves quality, higher settings lower quality and lowers size. You have to be careful, though, settings that are too low can be very wasteful. If you are using a setting below 16 or so you are likely wasting space without really getting much (if any) quality improvement.

Now, with that said, as I mentioned before -- two pass will always give you the best quality at a given size. So if encode time weren't a factor that you care about, the ideal scenario might be to first do a CRF encode to determine what size results from the quality level you want -- and then do a two pass encode with a bitrate that will result in that size (or slightly smaller).

One way you might be able do this is to use CRF as your first pass and create a stats file -- then calculate the required bitrate based on the size and do a second pass. I haven't tested that, though, so I can't confirm whether it works as well as (or better than) a normal two-pass encode.

Could you please help how to achieve your last paragraph in BD-RB? I would like to test it because this is the exact way I would like to process most of my BD-s..

As far as I know the setup would be as follows, please check if
it is correct or missed something:

- use one pass (CRF) encoding from encoder settings;
- use hiddenopts: FIXED_CRF= desired quality, KEEP_MBTREE=1 to use the stats.mbtree for second pass
- run the first pass CRF encode;
- calculate the required bitrate based on the size (so, I type in a custom target size based on the first pass, right?)

It is quite OK for me until this step. But how to "do a second pass" in BD-RB after a one pass (CRF) encode?

Please help with giving some more info. It would be very appreciated.

Thanks!

[mparade]

Does anyone know what is the bearing of SAMPLE_SIZE &
SAMPLE_GROUP hiddenopts? Unfortunately, it is still not clear to me even after reading the changes.txt.

Please help!

Thank you in advance!

[jdobbs]

Could you please help how to achieve your last paragraph in BD-RB? I would like to test it because this is the exact way I would like to process most of my BD-s..

As far as I know the setup would be as follows, please check if
it is correct or missed something:

- use one pass (CRF) encoding from encoder settings;
- use hiddenopts: FIXED_CRF= desired quality, KEEP_MBTREE=1 to use the stats.mbtree for second pass
- run the first pass CRF encode;
- calculate the required bitrate based on the size (so, I type in a custom target size based on the first pass, right?)

It is quite OK for me until this step. But how to "do a second pass" in BD-RB after a one pass (CRF) encode?

Please help with giving some more info. It would be very appreciated.

Thanks!The stats you're keeping aren't the mbtree stats, its the first pass stats. You could probably do it with TWEAKs (TWEAK_PASS_ONE & TWEAK_PASS_TWO) but you'd have to intercept after the first pass is complete.

[mparade]

The stats you're keeping aren't the mbtree stats, its the first pass stats. You could probably do it with TWEAKs (TWEAK_PASS_ONE & TWEAK_PASS_TWO) but you'd have to intercept after the first pass is complete.

Thank you. It seems a little bit complicated to do....

[laserfan]

...you'd have to intercept after the first pass is complete.
I wonder if it might be possible to ask BD-RB to PAUSE at certain points in the process e.g. before re-build, so if I wanted to redo a subtitle track for example I could do it without having to rebuild (multiplex) the disc multiple times.

[HWK]

I wonder if it might be possible to ask BD-RB to PAUSE at certain points in the process e.g. before re-build, so if I wanted to redo a subtitle track for example I could do it without having to rebuild (multiplex) the disc multiple times.

I would like to see that as well. DVD-RB had it and it was very easy for end user to make changes before certain stage kicked in.

[jdobbs]

I would like to see that as well. DVD-RB had it and it was very easy for end user to make changes before certain stage kicked in.I'll look at it. Maybe I'll put a couple hidden options that tells BD-RB to stop at certain points. Restarting will always pick up where it left off.

The biggest complaint I got for DVD-RB was that all the options confused people without a strong video background. So I'm trying to keep the front end as simple as possible and move the more advanced features to hidden options -- although I will likely add a visual interface to access hidden options at some point.

The 3-click option of DVD-RB confused a lot of people.

[HWK]

I'll look at it. Maybe I'll put a couple hidden options that tells BD-RB to stop at certain points. Restarting will always pick up where it left off.

The biggest complaint I got for DVD-RB was that all the options confused people without a strong video background. So I'm trying to keep the front end as simple as possible and move the more advanced features to hidden options -- although I will likely add a visual interface to access hidden options at some point.

The 3-click option of DVD-RB confused a lot of people.

May be Advanced mode in ini file, as you mention in your post. When option is enabled Bd-RB option with all advanced options available. Also add warning about telling user that you are not responsible if something goes wrong should they choose advanced options and screw something. Similar what you have done with x264 tweaks options in hidden setting file.

Another thing I want to bring up is since tsmuxer support DTS express audio, will we see support from your side in coming days?

[jdobbs]

Another thing I want to bring up is since tsmuxer support DTS express audio, will we see support from your side in coming days?Yeah. I've already finished that and tested it.

[HWK]

Yeah. I've already finished that and tested it.

Excellent, this will make lot of people happy and possibly donation pour in.

[jdobbs]

Excellent, this will make lot of people happy and possibly donation pour in.Based on history, I'd say the odds of that are pretty small. ;)

[HWK]

Based on history, I'd say the odds of that are pretty small. ;)

Very true, unfortunately it is reality. Oh well I will donate $ 60, like I always did before or do you want more instead. :p

[update] All done, 60USD sent to you.

[jdobbs]

Very true, unfortunately it is reality. Oh well I will donate $ 60, like I always did before or do you want more instead. :pNo need. You've done you part, especially with all the help and debugging. I appreciate the thought, though.

[HWK]

No need. You've done you part, especially with all the help and debugging. I appreciate the thought, though.

No worries, that is how community works. Anyways consider donation as a holiday present from me.

[jdobbs]

No worries, that is how community works. Anyways consider donation as a holiday present from me.It is very much appreciated. Happy Holidays to you.

Hmmm... now that I think about it -- you mentioned some 3D discs that used unusual subtitling. I need to pick one up for testing. That's how I use the donations. Can you give me the name again, please?

[HWK]

It is very much appreciated. Happy Holidays to you.

Hmmm... now that I think about it -- you mentioned some 3D discs that used unusual subtitling. I need to pick one up for testing. That's how I use the donations. Can you give me the name again, please?

Jdobbs, you have Avatar because this disc has different mechanism of generating 3D subs. I have Panasonic release of this movie, but others should be same as well.

When I was working with Roman on this, we realized there is separate mpls file which control 3D subs. 00854.mpls control stereo subs and 00850 control other parts.

What is even more interesting is if you import 00850 in tsmuxer you won't see stereo subtitle, however everything else will be there. If on other hand Import 00854.mpls you get stereo subtitle which is offset store in mvc file, but no chapters. Everything else is same with regards to video, audio etc. On final note Roman added code if multiple mpls is added which has same assets only one copy is picked and with this I added both mpls and manage to generate working disc image. Know just imagine how one would find out which mpls to parse for info, especially when you can have like 216 mpls which is indeed true for this film.

Something you may find interesting is number of subtitle in base is way more than in mvc view. Mvc stream contain two stream of subs but there are delta for right and left placement which apply to all subtitle in this case.

Jdobbs, this link provide quite insight and yes that includes Avatar as well, may be it will help you as well.

http://forum.doom9.org/showthread.php?t=169817

[Hobojobo]

-- although I will likely add a visual interface to access hidden options at some point.

That would be really great. :)

[jdobbs]

Jdobbs, you have Avatar because this disc has different mechanism of generating 3D subs. I have Panasonic release of this movie, but others should be same as well.

When I was working with Roman on this, we realized there is separate mpls file which control 3D subs. 00854.mpls control stereo subs and 00850 control other parts.

What is even more interesting is if you import 00850 in tsmuxer you won't see stereo subtitle, however everything else will be there. If on other hand Import 00854.mpls you get stereo subtitle which is offset store in mvc file, but no chapters. Everything else is same with regards to video, audio etc. On final note Roman added code if multiple mpls is added which has same assets only one copy is picked and with this I added both mpls and manage to generate working disc image. Know just imagine how one would find out which mpls to parse for info, especially when you can have like 216 mpls which is indeed true for this film.

Something you may find interesting is number of subtitle in base is way more than in mvc view. Mvc stream contain two stream of subs but there are delta for right and left placement which apply to all subtitle in this case.

Jdobbs, this link provide quite insight and yes that includes Avatar as well, may be it will help you as well.

http://forum.doom9.org/showthread.php?t=169817I have Avatar 3D in my collection. I'll look at it today.

[mparade]

Suggestions:

1. In many movies there can be a lot of extras and having to right-click to blank many VID's can be very tedious at times. I recently did a film where I had to blank 50 or more VID's. Would it be possible to enable BDRebuilder to use a keyboard key such as "b" on the keyboard when we have a VID selected in BDRebuilder to blank it therefore making it more efficient/faster to blank VID's?

2. In seamless branching titles, as well as, series disc (TV Shows) it's impossible to use "Quick Encoding on Extras" as BDRebuilder will encode many of the main movie VID's as extras. Would it be possible to enable the user to tell BDRebuilder what VID's are the main movie and what VID's are extras so that way the main movie would get high quality two-pass encoding settings applied to it while the extras would get the QUICK_CRF settings applied to them? It can be a hidden option just like blanking if you want. One method to possibly employ would be to right-click/use key "e" on keyboard on a VID and mark it as an extra and anything that doesn't have the extra flag assigned to it would get marked as main movie or you could employ the opposite and mark which vid's are the main movie and the ones that aren't marked will get labeled as an extra. This would help a lot of us users out tremendously if this feature was available. I can't stress enough how much this feature would help a lot of us out. :)

If it is true that "BDRebuilder will encode many of the main movie VID's as extras" in seamless branching titles I completely agree with you as I have also a lot of seamless branching BD-s. Last time, I had to keep for reencoding around 5 GB useless (parts of the main movie in other languages) material because they were siblings to the ones that were actually needed. It would be, I think, a very powerful and useful function to be able to blank any m2ts instead of any playlist in edit mode. It could be avoided to
waste "tons" of hard disk space in such encoding projects with seamless branching and be useful mainly for those who are using that kind of storage device for playing (like me) their materials.

[HWK]

I have Avatar 3D in my collection. I'll look at it today.

Just a quick update, I mux Avatar without stereo stream although it worked but display is messed up in terms of spacing and few other things. It is especially visible when screen goes black in the beginning of movie.

[mparade]

Currently if someone wants to run a CRF encode to determine the size for the quality level to reach and then wants to put this value in Custom Target Size to run a two pass encoding afterwards on the source it is very problematic in case of a combination with blanking a very complex (with a lot of playlists to check for blanking/unblanking) source through edit mode. Each time after doing any modification on the target size all the so far blanked/unblanked choices of playlists are overlooked by BD-RB. So, after blanking/unblanking the playlists required, then run a CRF 1-pass encode on the source, then modifying the Custom Target Size (according to the first CRF pass) for e.g. a two pass encode, all the work done so far for blanking/unblanking the playlists for the first time for the CRF encode has already been lost.
Due to some reason BD-RB rechecks the complete source again (after modifying only the target size) in respect of the mode the user previously set up. I have run into the same „problem” several times. I hope it will be solved in advanced mode in the near future. I really hope I am not the only one who would require that..

[montana72]

a disc bluray with a TV series with three 40-minute episodes each, I get to back up each episode will have a bit rate of about 15 kbps, is enough? never before had tried to compress a TV series because they tend to carry more chapters per disc.

Thank you

[jdobbs]

a disc bluray with a TV series with three 40-minute episodes each, I get to back up each episode will have a bit rate of about 15 kbps, is enough? never before had tried to compress a TV series because they tend to carry more chapters per disc.

Thank youSure. That's plenty. You could go much lower than that in most cases.

[Sharc]

Sure. That's plenty. You could go much lower than that in most cases.
15 kbps is plenty? Should it read 15 Mbps?:confused:

[jdobbs]

15 kbps is plenty? Should it read 15 Mbps?:confused:Whoops. I read it as Mbs... 15Kbs is definitely not enough for video. I also don't understand the "chapters per disc" comment.

[montana72]

Yes, sorry, I meant 15 mbps. I am referring to a bluray that has 3 episodes of 40 minutes in length each, not a movie and leaves each episode at 15 mbps each using me a disc of 25 gigabytes.

[mparade]

If setting up the Custom Target Size in settings/setup, according to my experiences the final
output image file size will be around 10% smaller then the size effectively determined in MB. (Maybe BD-RB cannot estimate it in an exact way under certain conditions, e.g. by full disc custom sized backups above BD-9 target size when one part of a full disc backup is encoded the other one kept intact for menus etc.). It is for sure not a „problem” for those at all who e.g. do not care about making a first pass CRF encode and then a second pass (with some interception after finishing the first pass) based on the file size made by the first pass CRF encode recently which were using the quality level they wanted to achieve, and then want to give that target size (or slightly smaller) for the second pass encode. For those who really care about the final output size (because the playback device is e.g. a hard disk drive) should the custom target size be a bit overestimated for the second pass. It would be great to check what is the reason for this around 10% difference between the expected and the effective output sizes. I am just avoiding this issue by calculating always an extra reserve to the output size expected for the two pass encode after the CRF encoding process.

[Sharc]

If setting up the Custom Target Size in settings/setup, according to my experiences the final
output image file size will be around 10% smaller then the size effectively determined in MB. (Maybe BD-RB cannot estimate it in an exact way under certain conditions, e.g. by full disc custom sized backups above BD-9 target size when one part of a full disc backup is encoded the other one kept intact for menus etc.). It is for sure not a „problem” for those at all who e.g. do not care about making a first pass CRF encode and then a second pass (with some interception after finishing the first pass) based on the file size made by the first pass CRF encode recently which were using the quality level they wanted to achieve, and then want to give that target size (or slightly smaller) for the second pass encode. For those who really care about the final output size (because the playback device is e.g. a hard disk drive) should the custom target size be a bit overestimated for the second pass. It would be great to check what is the reason for this around 10% difference between the expected and the effective output sizes. I am just avoiding this issue by calculating always an extra reserve to the output size expected for the two pass encode after the CRF encoding process.
There is no such complicated procedure like "two pass encode after the CRF encoding process"...:confused:
If you want to hit your target size as precisely as possible, go for a 2-pass encode right from the beginning, and you get the best quality which fits your desired size. It will however never be 100.00% accurate due to inherent limitations.
Or simply select BD-RB defaults (strongly suggested) which automatically selects the most efficient encoding method without compromizing quality. And whatever you do, don't worry about the last few % as you won't see a difference anyway.

[mparade]

There is no such complicated procedure like "two pass encode after the CRF encoding process"...:confused:
If you want to hit your target size as precisely as possible, go for a 2-pass encode right from the beginning, and you get the best quality which fits your desired size. It will however never be 100.00% accurate due to inherent limitations.
Or simply select BD-RB defaults (strongly suggested) which automatically selects the most efficient encoding method without compromizing quality. And whatever you do, don't worry about the last few % as you won't see a difference anyway.

Thanks for your answer. I completely agree with you, but it is not my case. Maybe my requests seem to be so special, sorry for that. (As you know, the user is never satisfied with what is currently available within a product, it is not the problem of BD-RB for sure, just a general statement instead). :)

I do not have a target size in mind in the beginning of making my BD-s, I have a quality to reach with a constant CRF instead, but I have to consider the fact also, that for a given target size a 2-pass encoding always give better results than a CRF encoding. So, due to these quality facts and to other circumstances that my playback device is a hard disk (so I am very sensitive for any space wasting procedures) besides willing to keep HD audio tracks, things has become even more complicated to me, unfortunately. I do not really want to make a 2-pass encode after a CRF encode, it is far from my purposes, but this is what currently available in BD-RB for
the ones with such "special" purposes. My short term aim is to get Mr. Dobbs to include a function in BD-RB which lets the user run a second pass encode after the first pass CRF encode using the first pass stats (through e.g. an interception process calling in advanced mode options) to be able to determine the target size for the quality level which had already been determined by the first pass CRF. I really hope Mr. Dobbs will not consider this function as totally useless one...:)

Anyway thank you for the answer and sorry again, if my request is so special that it seems to be confusing.

[Sharc]

I do not have a target size in mind in the beginning of making my BD-s, I have a quality to reach with a constant CRF instead, but I have to consider the fact also, that for a given target size a 2-pass encoding always give better results than a CRF encoding.

No, not really. For a given file size the difference between 1-pass (CRF) and 2-pass encode is almost Nil (not visible in practice) for x264. Simply speaking, in a regular 2-pass encode the first pass is used to determine the CRF plus optimum I,P and B frames placement which is finally applied in the 2nd pass in order to get the desired file size. So your manual back-and-forth strategy with repeated trial-and-error passes (CRF or 2-pass) is pointless IMO. You cannot fix the Quality in a first CRF pass ("now I go for Quality") and then reduce the file size in a second or third pass ("now I adjust the size") in the hope that the Quality from the first run will not be affected.
If you however prefer the trial-and error CRF mode to obtain a certain file size, you could select 1-pass CRF encoding without specifying a FIXED_CRF= in the config file (.ini). BD-RB then does the cyling through the CRF values automatically in a series of prediction passes such as to approximate your desired file size. But again, you may typically end up in the range 92 ..... 98% of your targeted size - but why care?
Sorry if I still got you wrong ....... maybe someone else chimes in.

[mparade]

No, not really. For a given file size the difference between 1-pass (CRF) and 2-pass encode is almost Nil (not visible in practice) for x264. Simply speaking, in a regular 2-pass encode the first pass is used to determine the CRF plus optimum I,P and B frames placement which is finally applied in the 2nd pass in order to get the desired file size. So your manual back-and-forth strategy with repeated trial-and-error passes (CRF or 2-pass) is pointless IMO. You cannot fix the Quality in a first CRF pass ("now I go for Quality") and then reduce the file size in a second or third pass ("now I adjust the size") in the hope that the Quality from the first run will not be affected.
If you however prefer the trial-and error CRF mode to obtain a certain file size, you could select 1-pass CRF encoding without specifying a FIXED_CRF= in the config file (.ini). BD-RB then does the cyling through the CRF values automatically in a series of prediction passes such as to approximate your desired file size. But again, you may typically end up in the range 92 ..... 98% of your targeted size - but why care?
Sorry if I still got you wrong ....... maybe someone else chimes in.

Sorry, but there is some kind of misunderstanding between us. "So your manual back-and-forth strategy with repeated trial-and-error passes (CRF or 2-pass) is pointless IMO". It would be (also a two-pass encode) not much more time consuming than what you are currently doing through a "normal" two pass encode, yet on the other side you can base the file size (which will be same sized or slightly smaller) which is made during the second pass on the quality level you exactly wanted by setting a desired CRF value for the first pass encode also (or two, one for main videos other for the extras).

"You cannot fix the Quality in a first CRF pass ("now I go for Quality") and then reduce the file size in a second or third pass ("now I adjust the size") in the hope that the Quality from the first run will not be affected."

But I do not want to do anything like this.

"to obtain a certain file size, you could select 1-pass CRF encoding without specifying a FIXED_CRF= in the config file (.ini). BD-RB then does the cyling through the CRF values automatically in a series of prediction passes such as to approximate your desired file size. But again, you may typically end up in the range 92 ..... 98% of your targeted size - but why care?"

But I do not have a certain file size in my mind in the beginning
of the process because I am playing from hard disk. I really do not have a desired file size, so only using FIXED_CRF and QUICK_CRF values can be an answer determined by the required quality level, I think, when size control disappears (however I realised some days ago it is not entirely true either).

The small difference you described is not a problem if it is not even higher effectively as you mentioned. (I have experienced 9-10% always and it is even not the same case). I agree that it would be great if Mr.Dobbs can write his comments and help us out with his knowledge whether the "right direction" is followed at all or not. Still I have not convinced that this strategy is faulty and senseless under such special circumstances I actually have and described.

[jdobbs]

The previous discussion was all theoretical. The point of doing CRF on the first pass is to get to a given quality level (without any prediction and completely ignoring size). You just need to tell X264 to create a stats file. The output size could then determine the bitrate to be use for pass 2. The purpose of a second pass would be to improve on the perceived quality at that give size by redistributing the available bandwidth more efficiently. It won't work if you have target size restrictions because the size was determined by the CRF.

But, as I said before, I've never done any quality tests using that method, so I can't say with any certainty whether you'd see any improvement at all over a lone CRF pass.

[Sharc]

The previous discussion was all theoretical. The point of doing CRF on the first pass is to get to a given quality level (without any prediction and completely ignoring size). You just need to tell X264 to create a stats file. The output size could then determine the bitrate to be use for pass 2. The purpose of a second pass would be to improve on the perceived quality at that give size by redistributing the available bandwidth more efficiently. It won't work if you have target size restrictions because the size was determined by the CRF.

But, as I said before, I've never done any quality tests using that method, so I can't say with any certainty whether you'd see any improvement at all over a lone CRF pass.
Ah yes, quality based 2-pass method without size restrictions.
If I remember correctly such tests have been done during x264 development, and over time the 1-pass CRF algo has been optimized to the point where there was little to none improvement with the second pass.

Edit:
.... and oh yes, this reminds me on the discussions related to "Redistribution" in DVD-RB times :D

[mparade]

The previous discussion was all theoretical. The point of doing CRF on the first pass is to get to a given quality level (without any prediction and completely ignoring size). You just need to tell X264 to create a stats file. The output size could then determine the bitrate to be use for pass 2. The purpose of a second pass would be to improve on the perceived quality at that give size by redistributing the available bandwidth more efficiently. It won't work if you have target size restrictions because the size was determined by the CRF.

But, as I said before, I've never done any quality tests using that method, so I can't say with any certainty whether you'd see any improvement at all over a lone CRF pass.

Thank you for the answer. I think I am going to support those quality tests also in some degree in the very near future..:)

[mparade]

Thank you Sharc, too...:D

[jdobbs]

Thank you for the answer. I think I am going to support those quality tests also in some degree in the very near future..:)If that's the case then I guess it's kinda' like running several passes rather than just 2. It might make you feel better, but it really doesn't accomplish anything.

[mparade]

It that's the case then I guess it's kinda' like running several passes rather than just 2. It might make you feel better, but it really doesn't accomplish anything.

I think we should always stay within the reasonability controlled by your knowledge and experiences...

[jdobbs]

I think we should always stay within the reasonability controlled by your knowledge and experiences... Actually I thought I was answering Sharc in that response, but I clicked on the wrong post. :)

Sharc: If I remember correctly such tests have been done during x264 development, and over time the 1-pass CRF algo has been optimized to the point where there was little to none improvement with the second pass.

Me: If that's the case then I guess it's kinda' like running several passes rather than just 2. It might make you feel better, but it really doesn't accomplish anything.

Apparently I didn't have enough "knowledge and experiences" to do something as simple as click on a correct post... :D

[mparade]

In the latest version of BD-RB (v0.39.01) I have added some undocumented features. I didn't want to make them widely available until there was some more widespread testing (so far I'm the only tester). The new features enable a "Movie and Menus" mode and also the ability to selectively blank playlists.

I expect that there will be a need for some additional tweaking before these features are ready for general consumption, so I ask that anyone who would like to test these features post anything they find in this thread.

---------------

1. In order to enable the new features, use the menu "File/View/Edit Config" and add this line to the config/INI file:

ENABLE_TEST=1

2. The "Movie and Menus" selection will now appear in the MODE menu.

3. Movie and Menus works by blanking any playlist (other than menus) that is less than 20 minutes long. The size of playlists to exclude, however, can be modified by setting a parameter called BLANK_THRESHOLD in the config/INI file. The parameter is set by specifying the threshold size (in seconds). The default is 1200 (20 minutes) so if you added this:

BLANK_THRESHOLD=1800

You would raise the threshold and anything less than 30 minutes would be excluded. A point to remember: The threshold isn't related to an individual M2TS file -- it is associated with PLAYLISTS.

4. Sometimes you might want to select for yourself which things to blank/unblank. You can do that by entering "Edit Mode". You enter edit mode by double-clicking on the title of the current disc (right next to the icon and above the Streams List). I may change the way of doing that later. Edit mode will not work unless you have ENABLE_TEST=1 set.

5. When in edit mode, streams that are selected for blanking will be "grayed out" in the streams display. When not in "Edit Mode" they are not visible.

6. "Edit Mode" can only be entered when using either "Full Backup" or "Movie and Menus" modes -- it will not work on a "Movie-Only" backup (for obvious reasons).

7. Also remember -- when you edit (blank or unblank), you selection works against a PlayList. So blanking/unblanking a single item can result in multiple items (any that are siblings to the selected items in any Playlist. Another point: Items that BD-RB has flagged as menus cannot be blanked (normally they won't even show up on a BD-25 backup, but will on a BD-9 because they have to be reencoded).

--------------------

You'll find that by using "Edit Mode" you can get some pretty nice effects. For example, if you select "Full Backup" mode, and then enter edit mode and blank the feature -- you can create a disc that contains only the extras. Combine that with movie-only mode and... you can now create a two disc backup that contains all features of a disc.

You may also find that menus might not be correctly identified 100% of the time... but it's close, and I'm looking for ways to make it more accurate.

Anyway -- please play with it and let me know what you think. Any suggestions for making it more usable will also be appreciated -- but please be reasonable.

Thanks.

I think a function would be great in edit mode through which it would be possible to blank/unblank individual m2ts files rather than the whole playlists in which they are included. The reason for such a demand is coming from experiences. Several times I had to keep „tons” of useless materials in the encoded image files because I was forced by BD-RB to keep the m2ts files in other languages also in those playlists which included the needed m2ts files as well. In my opinion it is wasting hard disk space if the playback device is not an optical one.

A function to tell BD-RB in edit mode which m2ts file has to be considered as extra and which not to be. (Similar more detailed request from Audiophile1178). This would be especially useful for those who want to use e.g. FIX_CRF on main videos and QUICK_CRF on extras besides having a source for seamless branching or extra discs when BD-RB is unable to identify the m2ts files correctly that belong to the extras/main video. (I do not have experiences if BD-RB has problems with identifying an m2ts as main or extra video in an exact way in case of such sources).

I think having both of them would be quite reasonable from at least the user side. They can help to spare a lot of hard disk space in special cases for storage and do a better quality encode by manually identifying the exact type of video source for BD-RB to encode accordingly.

I promise now that I will not have any more feature request for this year. Tomorrow I would like to start compensate the other side..

[Audiophile1178]

If it is true that "BDRebuilder will encode many of the main movie VID's as extras" in seamless branching titles I completely agree with you as I have also a lot of seamless branching BD-s. Last time, I had to keep for reencoding around 5 GB useless (parts of the main movie in other languages) material because they were siblings to the ones that were actually needed. It would be, I think, a very powerful and useful function to be able to blank any m2ts instead of any playlist in edit mode. It could be avoided to
waste "tons" of hard disk space in such encoding projects with seamless branching and be useful mainly for those who are using that kind of storage device for playing (like me) their materials.

Jdobbs, has answered this question in the past and he doesn't want to create the ability for individuals to blank m2ts files that are associated to other playlists as that can obviously cause issues and I agree with him on that subject but I personally don't see any issues with having the ability to tell BDRebuilder on how to encode those m2ts file by marking them as main movie or extras. If you want to mess with m2ts files individually you can modify the playlists to your liking in BDedit as I do to accomplish what you're trying to do and then run it through BDRebuilder.

Every once in a while BDRebuilder won't encode extras as 1-pass crf and will do a 2-pass on a certain extras. I then have to go back and manually encode those parts, as well as, the main title to get the disc exactly as I want it. What's funny is that when this happens BDRebuilder will encode one extra using a crf and another extra that's EXACTLY the same as a 2-pass. This happened to me on a disc that had two of the same opening previews but for different regions. The video was EXACTLY the same but BDRebuilder encoded one of them as 1-pass crf and the other as 2-pass. I didn't understand it's reasoning for doing that as both video files contained the same material.

What I'm currently doing in the meantime with seamless branching titles to get around this issue is to manually blank the Theatrical Cut and merge the Extended Cut into 1 file. I then merge that newly created single m2ts file of the Extended Cut back into the original disc using BDedit. After that I encode in BDRebuilder as I normally do using 1 pass crf for extras and two pass for main movie. The disadvantage to this is that you don't have the theatrical cut of the film on the disc so if you want that you'd have to make another disc with using same method as above but reversed. I have done several discs using this method and it has worked like a charm but having the ability to keep both versions of the film on a disc, as well as, having BDRebuilder encode the main title using 2-pass and extras using 1-pass crf would be most ideal. :)

Regarding series discs, that's another story of its own that's very time consuming. I manually encode each m2ts file and then merge each encoded file back into the original Blu-ray structure. If I had the ability to mark each VID file as an extra or main title that would cut down the processing time drastically. I dread series discs because of this issue as it takes sooo long to do and is easy to make a mistake by not changing something correctly in BDedit. Sometimes on these series discs there are bonus features that are as long or longer than a regular episode and BDRebuilder will do a 2-pass encode on it thinking that it's a main title instead of a 1-pass crf.



I LOVE BDRebuilder and think it's the BEST tool to do Blu-ray encoding but feel as if it's lacking this much needed feature that others would love to have. I know people that avoid encoding series/seamless branching discs because of this missing feature.

[jdobbs]

I agree. This is opening a can of worms (and headaches for me) that I don't want to explore. I already question my decision to create the hidden "ENABLE_TEST" option that allows editing -- and may leave it undocumented forever. It's just too easy to screw the pooch and blame BD-RB. Some people have a tendency to forget that they created a "self inflicted open chest wound" type error, and sometimes conveniently leave out that detail when they post a bug report.

To make it even worse -- sometimes you don't really know what you're removing, as a single M2TS might easily be a part of 30 different playlists, and you end up down a real rabbit hole when you decide to start removing pieces... BD-RB currently follows every individual playlist element, and looks through every reference to it before allowing its removal.

This feature will likely never be on the list. I think that's better handled by BDEDIT, as it requires an understanding of BD structure that is a prerequisite before making this kind of modification.

I want to keep everybody happy, but it also has to be within reason. Sorry.