Blu-Ray~DVD Backup & Conversion

[jdobbs]

Do you have keyint set to 24. If it is higher you can find yourself waiting for the next one -- for example, if you used the default 250 value it could be a 10 sec wait.

[GZZ]

@SET IN_TITLE=FILETITLE
@SET IN_BITRATE=5240
TIME /T
"E:\X264\x264.exe" "%IN_TITLE%.AVS" --bitrate %IN_BITRATE% --level 4.1 --sar 1:1
--aud --vbv-bufsize 14745 --vbv-maxrate 17500 --filter 0,0 --bframes 3 --direct auto
--keyint 24 --min-keyint 1 --subme 2 --analyse none --me dia --threads auto --thread-input
--progress --no-psnr --no-ssim --stats "stats2.log" --pass 1 --output NUL
TIME /T
"E:\X264\x264.exe" "%IN_TITLE%.AVS" --bitrate %IN_BITRATE% --level 4.1 --sar 1:1 --aud
--vbv-bufsize 14745 --vbv-maxrate 17500 --filter 0,0 --ref 3 --mixed-refs --bframes 3
--keyint 24 --min-keyint 1 --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1
--analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input
--progress --no-psnr --no-ssim --stats "stats2.log" --pass 2 --output "%IN_TITLE%.264"
TIME /T
PAUSE

I use the script you provided earlier in this post.

the --b-rdo --bime command has change to --subme7 in the newest x264 encoder. But it still have some chapter problems.

[laserfan]

Do you have keyint set to 24. If it is higher you can find yourself waiting for the next one -- for example, if you used the default 250 value it could be a 10 sec wait.
No--great idea I will try that!!! :)

[jdobbs]

I use the script you provided earlier in this post.
...But it still have some chapter problems.The chapter problems would probably more likely be related to the muxing rather than the encode. What I meant was to manually force the framerate in TSMUXER when you create the BD directory.

[jdobbs]

No--great idea I will try that!!! :) Don't forget to also add "--min-keyint 1", the default is 25, I believe, and you have to get smaller than the 24...

[GZZ]

The chapter problems would probably more likely be related to the muxing rather than the encode. What I meant was to manually force the framerate in TSMUXER when you create the BD directory.

How do you force the framerate, by setting the "Change FPS to" Dropdown box ?

[jdobbs]

How do you force the framerate, by setting the "Change FPS to" Dropdown box ?Yes. I've been told that for some reason there seems to be an issue with correctly detecting/applying the framerate during the mux.

[GZZ]

I tried it on a 1080p@25 fps movie without any lock. I have an image created before I forced the fps and after. Still the same chapters which have a long delay (picture freeze and audio play) until 5 sec. later it all plays fine.

[G_M_C]

I use the script you provided earlier in this post.

the --b-rdo --bime command has change to --subme7 in the newest x264 encoder. But it still have some chapter problems.

I've been making many BD9's up till now, and i havent seen anyting like your problem ...

So ... i'll give some advise too ;)

First try to upgrade to this (patched !) build, or let Megui do an autoupdate (wont matter; You'll get the same patched revision r999): http://forum.doom9.org/showthread.php?p=1191102#post1191102

Then try to modify a few things in your commandline
(i give only the second pass, port / copy settings to the first yourself if needed);

This is the line you use

"E:\X264\x264.exe" "%IN_TITLE%.AVS" --bitrate %IN_BITRATE% --level 4.1 --sar 1:1 --aud
--vbv-bufsize 14745 --vbv-maxrate 17500 --filter 0,0 --ref 3 --mixed-refs --bframes 3
--keyint 24 --min-keyint 1 --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1
--analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input
--progress --no-psnr --no-ssim --stats "stats2.log" --pass 2 --output "%IN_TITLE%.264"

I use these settings;
I Use a keyframe-interval of max 1 second (so keyframe-interval == framerate, rounded off), min-keyint=1.

--level 4.1 --keyint set yourself --min-keyint 1 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 6 --trellis 2 --partitions none --ipratio 1.2 --pbratio 1.2 --vbv-bufsize 22000 --vbv-maxrate 16000 --scenecut 32 --me umh --merange 24 --threads auto --thread-input --psy-rd 0.8:0.8 --aq-strength 0.8 --progress --output "output" "input" --mvrange 511 --aud --nal-hrd --sar 1:1 --b-adapt 2

PS: Others speak only of keyframe-interval of 24, so try with a DVD-RW to see what works best.

Try looking at the key-int setting. I use it the way i describe above, and i've never had problems.

I'll advise you to set the vbv-buffer options like above, but i've been reading up on this subject, and those settings might not be correct (depend on the player / chipset actually). Fact is that i've never had problems, so i keep using them untill I notice some faults.

The other options given in red; I'll advise you to put in your commandline, especially the --mvrange 511 --aud --nal-hrd part. There are many reports on "--nal-hrd" that say that it is needed for blu-ray compabillity. On the other hand; There are also many reports that say that tsmuxer add those flags, but i'll trust x264 better in this ;)

The other options i give are just options to improve your quality, so that won't hurt ;)

As allways, use an DVD-RW to test !

And lately i've been setting tsMuxeR "into split mode", splitting to 2 GiB. tsMuxeR still makes the whole movie into 1 Br, but makes all M2TS files 2 GiB long, and seamlessly playing one after the other. I've noticed (and so has a friend with a PS3) that the final disk loads a bit faster .. have no clue why though

[GZZ]

--b-rdo --bime isnt supported in x264 r999 at www.x264.nl its replaced by --subme 7. But you have them both in your script ? Mistake ?


the version you posted of x264 r999 is the one I use.

[G_M_C]

--b-rdo --bime isnt supported in x264 r999 at www.x264.nl its replaced by --subme 7. But you have them both in your script ? Mistake ?


the version you posted of x264 r999 is the one I use.

Sorry, i just quoted an old post of mine; Forgot to change that. The rest of my post is accurate though !

(PS: I've set it to subme 8, or sometimes even 9 ;) )

[GZZ]

I have to read up on a lot of the options. Many I dont understand.

like this one: --psy-rd 0.8:0.8 --aq-strength 0.8


Does it improve quality ?

[G_M_C]

I have to read up on a lot of the options. Many I dont understand.

like this one: --psy-rd 0.8:0.8 --aq-strength 0.8


Does it improve quality ?

My eyes say so, test it and see :)

[GZZ]

Should all the option from 2pass be in 1 pass or are there anyway you can see if it makes sense to use it in 1 pass ?

[G_M_C]

I'm not gonna spoon-feed you .... :rolleyes:

Do some of the reasoning /work /searching yourself please

[Sophocles]

jdobbs

A little off topic. You won't mind if I stir a little excitement regarding BD RB. I would like to get some of my online buddies stirred up a little.:scared:

[jdobbs]

Not at all. Actually it's pretty close to beta release. I've done several in-a-row without needing any new adjustments.

The down-side: Man, series discs take a long, long time... I just backed up my copy of Lonesome Dove as a test to a BD-9. There are over 4 hours of video there, and it looks beautiful. :)

[GZZ]

Really looking forward to test your beta version and also buy a licens for it.

Are you using the script I posted above ? :script:

[rack04]

jdobbs,

Do you have a command line to mux to blu-ray disc structure using tsMuxeR?

[jdobbs]

Actually the details would be in the .meta file -- but it changes based upon the source.

[jdobbs]

Really looking forward to test your beta version and also buy a licens for it.

Are you using the script I posted above ? :script:Not exactly. Similar, though.

[laserfan]

I have only done a couple of these, but they look gorgeous and play perfectly and I have been using --vbv-bufsize and maxrate of 30000.

I don't know why earlier comments cite DVD speed of 2x is a limitation, when AFAICT the speed limit is actually 3x???

[G_M_C]

I have only done a couple of these, but they look gorgeous and play perfectly and I have been using --vbv-bufsize and maxrate of 30000.

I don't know why earlier comments cite DVD speed of 2x is a limitation, when AFAICT the speed limit is actually 3x???

Have you a document / site that says so ? Cause that high bitrates dont seem to work in mine, giving stuttering !

EDIT:
PS: Setting --vbv-maxrate to 30000 doesnt automatically mean that your file will eventually get a bitrate that high. Set vbv-buffer to 30000 also, and encode something like episode 7 of Planet Earth (Great Plains) or episode 3 (Fresh water) from their origingal sources(!!) Then see what bitrate you get on the rising flock of birds (somewhere in the middle of "Great Plains") or the flock of white geese taking off (end of the episode of "Fresh Water").

Both these scenes are renownd for their bitrate extremes, and are used often to test a computers capabillities to decode (stretching many of them to the max and bringing them down to their knees).

[jdobbs]

I have only done a couple of these, but they look gorgeous and play perfectly and I have been using --vbv-bufsize and maxrate of 30000.

I don't know why earlier comments cite DVD speed of 2x is a limitation, when AFAICT the speed limit is actually 3x??? My player stutters and stops at bitrates that high (unless written to a BD-RE) -- and frankly the quality doesn't seem to noticably improve. I'm sticking to the lower maximums.

[GZZ]

Can confirm that Jdobbs value for Maxrate and bufsize also works very well on Dual-layer DVD9 played on a PS3.

My DVD-burner dont even read dual layer with more the 2-3x on the outer ring. So keeping the max bitrate under 2x DVD speed, then you will be safe and compatible with more players.

[laserfan]

Setting --vbv-maxrate to 30000 doesnt automatically mean that your file will eventually get a bitrate that high. Set vbv-buffer to 30000 also, and encode something like episode 7 of Planet Earth (Great Plains) or episode 3 (Fresh water) from their origingal sources(!!) Then see what bitrate you get on the rising flock of birds (somewhere in the middle of "Great Plains") or the flock of white geese taking off (end of the episode of "Fresh Water").

Both these scenes are renownd for their bitrate extremes, and are used often to test a computers capabillities to decode (stretching many of them to the max and bringing them down to their knees).Of course, right now I can't seem to find the "3x is OK for BD5/BD9" right now but I recall having seen it on a Blu-ray chart in some wiki somewhere. I will continue to look again for it.

Dunno what to make of G_M_C and jdobbs stuttering players, maybe my BH200 player is superior to yours (!) in that it was designed also for HD DVD where the 3x DVD speed was/is "legal".

Also, I noted that Atak puts 30000 into bufsize and maxrate in RipBot264 and he seems to continually migrate his updates towards "compatibility" with multiple players.

I don't intend to make a lot of backups by this method, but until I make one that hiccups in any way I will stick by 30000/30000 myself.

P.S. I have Planet Earth (HD DVD) so maybe I'll try that torture test someday. I haven't watched that series yet myself, but I recall similar scenes from "Winged Migration" that were hell to convert to Xvid!

[laserfan]

After more reading, it seems clear that 30000 is the right number (bufsize and maxrate) for a BD-spec encoding, but the question of playback on a red laser DVD remains open i.e. whether a BD spec encoding will play on DVD-5/9 media.

I found one thread that suggests BD player mfrs might have deliberately disabled the ability to play DVD media. Look here (http://forum.beyond3d.com/showpost.php?p=1046340&postcount=1) (yes it's about BD media but maybe the same thought process applies). Given the proliferation of HD camcorders and the AVCHD spec, which indeed is 2x, makes me wonder if some players will work PARTIALLY but then are specifically crippled to not play a DVD at >2x speed.

As mentioned earlier in this thread, my own player the BH200 lost the ability to play EITHER type (AVCHD or BD5/BD9) with its most recent firmware. I had to revert to an older firmware to get my BD5s to play. So now I wonder if this may not have been deliberate on LG's part... :eek: :confused:

[jdobbs]

As I recall the BD-9 FAQ said 3x, while AVCHD rules (which I read some time ago) said 2x. Either way -- it is silly to add a huge maximum bitrate when you know it might cause problems. This is especially true when you know there is very little improvement as a result. I'd also say it is an odd setting to have a maximum bitrate that is 6 or more times higher than the average.

Even at 3x 30000 is inherently too high -- because the actual 1x limit is somewhere around 9300Kbs after the disc overhead that has to be read along with the stream (the M2TS file has about 6-7% overhead). That would make the "best case" somewhere around 27000. In addition you have to subtract from the 27000 for the combined bitrate of all the audio tracks. Buffering can absorb some of this -- but not if it is sustained for a while (like a high action scene).

All the reasoning by others in the world isn't going to convince me to set the maximum to something that common sense tells me is too high. Especially for a purpose that doesn't seem to accomplish anything that I can see...

[Sophocles]

he down-side: Man, series discs take a long, long time... I just backed up my copy of Lonesome Dove as a test to a BD-9. There are over 4 hours of video there, and it looks beautiful.

I'm looking forward to tackling these big beast. I figure my Quad core should give some idea of what is going to be needed down the road when Nehalem takes over the encoding crown.

[laserfan]

All the reasoning by others in the world isn't going to convince me to set the maximum to something that common sense tells me is too high. Especially for a purpose that doesn't seem to accomplish anything that I can see...
I was not referring to "reasoning by others" jdobbs, I was referring to the actual "experience" of those who have had longer history doing this than you have, namely the MeGUI and RipBot264 developers.

Still, if your player (a Sony?) and G_M_C's (a Panny I think?) both have experienced stutters with 30,000 bufsize and maxrate, then I won't argue with your experience. And thus altho my BH200 appears to play these discs just fine, since my BH200 likely has a finite life then Common Sense tells me to encode to the lowest common denominator.

Although I suppose by the time my BH200 dies there will likely be a new "4096p" standard or "SuperBit BD" format or something that will inspire me to want the new discs anyway, instead of re-encoding the 3x 1080p discs I made way back in two-thousand-ought-eight! :p

[jdobbs]

Based on the changes I keep seeing across the board on all these settings and the inconsistencies between all the expert postings -- I'd say it's still pretty much a guessing game and I wouldn't put too much faith in any recommended settings I've seen. That's the reason that, while I'll look at other recommendations, I draw my own conclusions as to what is the best choice.

Even experience is no substitute for math. As I explained, even if 3x is the correct assumption, the value 30000 is still too high. You can't rely on buffering of high bursts to save you or eventually you'll get bit.

[jdobbs]

I'm looking forward to tackling these big beast. I figure my Quad core should give some idea of what is going to be needed down the road when Nehalem takes over the encoding crown. Soon. A few more tests and I'll post a beta.

[magic144]

that sounds very superb - I look forward to assisting with beta testing this little baby too

I have mostly been mucking around with MeGUI (and DGAVCIndex) and making .mkv's which play just fine and dandy on my HTPC

however, I think I would be very interested in seeing a more universal solution allowing BD authoring and multi-platform playback

the main reason I went down the HTPC playback route initially was that I'd read that NOT cropping many of these wider aspect ratio movies (i.e. with the black bars top and bottom of frame) leads to ineffeciencies in x264's encoding thereof... tho admittedly I haven't seen the practical evidence/maths to back this up yet! - plus the *scene* rules (by *them*) describe no-cropping as a no-no for these reasons... but since they are a shadowy bunch, I don't suppose we'll ever be able to ask them why!

re: vbv buffer sizes and things, I've so far been using the DXVA-HD-HQ param set from MeGUI which is far and away higher than anything discussed here (probably OK for HTPC, but I didn't realize the constraints on standalones before!) - I believe it's 50000 for both!!

anyway, cheers for the good news,

m

ps - btw, might be worth talking with Sharktooth about his take on all the various 'black art' x264 cmdline params, since MeGUI has honed a very extensive set of parameter sets over the last few weeks/months for almost all playback platform scenarios

fwiw, this is the cmdline param set that my slightly-modified MeGUI x264 profile leads to...
(but like I said, this is no doubt much more geared towards HTPC boundaries)

program --pass 2 --bitrate 1000 --stats ".stats" --level 4.1 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-adapt 2 --weightb --direct auto --filter -1:-1 --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 50000 --vbv-maxrate 50000 --me umh --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input"

[jdobbs]

re: vbv buffer sizes and things, I've so far been using the DXVA-HD-HQ param set from MeGUI which is far and away higher than anything discussed here (probably OK for HTPC, but I didn't realize the constraints on standalones before!) - I believe it's 50000 for both!! You have to be careful not to confuse the limits. If you are writing to a BD-RE or BD-R you can use a value of up to 40Mbs, with all streams adding up to no more than 48Mbs (not sure where the 50Mbs comes from -- it is definitely above the blu-ray standard, so I would assume it is used for something else??).

But on a DVD-R, it is much lower. It is possible that 3x is the standard for support (that's what the authoritative guide says). If that is so, then the raw read from the drive (after demodulation, error correction and buffering) is 30.24Mbs. Figure in 7% M2TS and formatting overhead and you lower that to 28.21Mbs. Then subtract a single 640Kbs AC3 audio track and you are already down to 21.81Mbs. You then have to adjust for any other audio tracks and/or the subtitles. Leaving yourself a little room puts you at the 17.5Mbs that was in the batch file example I used. (I decided to be more exact this time)

Like I said, buffering might compensate for a short burst going higher -- but you shouldn't depend on it.

The bottom line is that the standalones are simply following the rules, and so should any encode you intend to play on them.

[magic144]

I'm guessing on an HTPC, the DVD+R(-R) read rate is typically much more than 3x?
I certainly have never seen seen stuttering on HTPC playback using these settings (...yet...)

e.g. for my SH-203B DVD drive, this link shows DVD+R DL read speeds varying from 5.13x to 12.30x
which I guess is anywhere from about 50000+ to 126000+ Mbit/s (or did I get that entirely wrong)
http://www.cdfreaks.com/reviews/Samsung-SH-S203B-DVD-Burner-Review/Reading-performance.html

However, from everything you've said jdobbs, standalone machines are much more constrained (and in a media-dependent way!)

m

ps, the --bitrate 1000 is just a default in the cmdline above
typically, when MeGUI calculates the bitrate for an 'average' movie reencode to fit on a DVD+R DL (~9GB), I end up with a bitrate parameter of more like 10000-11000 - I think this is a 'target' bitrate, but obviously by no means an upper bound...

pps - yeah, from the Wikipedia (font of all knowledge?!) webpage on Blu-Ray discs...
http://en.wikipedia.org/wiki/Blu-ray_Disc#Codecs

"BD-Video movies have a maximum data transfer rate of 54 Mbit/s, a maximum AV bitrate of 48 Mbit/s (for both audio and video data), and a maximum video bitrate of 40 Mbit/s"

...therefore, I don't see any reason why any re-encode of a BD-Video source would EVER require a video bitrate of > 40Mb/s (regardless of the supported maximum read rates of the underlying media/hardware combo!) - also HDDVD has a lesser requirement...

[jdobbs]

If you want to see reliable specs go here (http://www.emedialive.com/Articles/ReadArticle.aspx?ArticleID=11392). I've found it to be right on everything so far.

"BD-Video movies have a maximum data transfer rate of 54 Mbit/s, a maximum AV bitrate of 48 Mbit/s (for both audio and video data), and a maximum video bitrate of 40 Mbit/s"
Again -- be careful. Those maximum values refer to BD writeable/rewritable discs (BD-RE/BD-R), not DVD-R or DVD+R (BD-5/BD-9). The BD-5 and BD-9 maximums are as I mentioned. Putting a 40Mbs maximum bitrate on a BD-9 is a recipe for certain failure. I would highly recommend you keep it under 20Mbs -- and 17.5Mbs is a good balance.

When you're encoding in the 3500-5000Kbs average bitrate range (typical for BD-5/BD-9) having a 17.5Mbs ceiling gives you a burst (maximum) rate of more than 3x the average... that is plenty.

[Added] By the way -- if you set the level to 4.0, which I've seen in some of the recommended settings, the ITU-T Rec. H.264 standard puts a fixed 20Mbs maximum bitrate limit on it anyway.

[laserfan]

Based on the changes I keep seeing across the board on all these settings and the inconsistencies between all the expert postings -- I'd say it's still pretty much a guessing game...Well, I think that's true among Users, but the Developers ought to know how x264 works, shouldn't they?

ps - btw, might be worth talking with Sharktooth about his take on all the various 'black art' x264 cmdline params, since MeGUI has honed a very extensive set of parameter sets over the last few weeks/months for almost all playback platform scenarios... --vbv-bufsize 50000 --vbv-maxrate 50000

But on a DVD-R, it is much lower. It is possible that 3x is the standard for support (that's what the authoritative guide says). If that is so, then the raw read from the drive (after demodulation, error correction and buffering) is 30.24Mbs. Figure in 7% M2TS and formatting overhead and you lower that to 28.21Mbs. Then subtract a single 640Kbs AC3 audio track and you are already down to 21.81Mbs. You then have to adjust for any other audio tracks and/or the subtitles. Leaving yourself a little room puts you at the 17.5Mbs that was in the batch file example I used.
I should make it clear, in case anyone's mistaken my comments for any sort of "expert opinion" (I am not an expert! :eek:) that I'm only putting forth my thoughts here to try to get this cleared-up. I don't know jdobbs that your "common sense" approach is correct, that's all. Your MATH is obviously correct, and I have no argument with your thought process, but I don't know that this rationale truly applies against the --vbv-bufsize and --vbv-maxrate options in x264. I don't understand vbv (duh), but it seems apparent that some of the guys in this thread about x264 not respecting maximums (http://forum.doom9.org/showthread.php?t=141715&highlight=x264) do understand the implications of the settings wrt both the encoding and decoding processes. I thought of attempting a post in there (as G_M_C has visited already too) but am not sure how to ask much less how to interpret an answer. :o:

magic144 you said I think you're using an HTPC--that's cheating (for purposes of this thread anyway). We're trying to establish how to encode for BD standalone players.

jdobbs and G_M_C have said they've tested higher bufsize and maxrate with stuttery results. Given all the confusion about BD standards and standalone players manufactured to a moving target of specs it sure would be nice to know "the truth" about 3x playback, once cited as an advantage HD DVD had over BD as if BD wasn't capable of it.

But I digress--someone needs to address I think the implications of the --vbv options specifically to DVDR media in standalone players! :scared:

[magic144]

@laserfan - I thought I had made the distinction clear that I was quoting some figures based on using an HTPC (on top of which I said I was using .mkv container encodes!) - I realize full-well that this discussion is all about zeroing in on the specific restrictions associated with standalone BluRay playback hardware in conjunction with DVD5/DVD9 media (authored in a BluRay video container format)! Mostly I was trying to emphasize how much more restrictive the standards are compared with the practical capabilities of today's optical drives in a PC environment :-)

@jdobbs - I assumed that BD-Video meant BD-ROM media. I didn't mean to imply that those rates would/should apply to DVD media.

I seem to have been misunderstood a lot so far...!

Like I said, I have been doing a lot of DVD9 (cropped) 720p encodes so far - most around 11000 avg/target bitrate - that is already twice as much as a lot of 'scene' encodes, so I don't believe a cap of 17500 is going to seriously affect anybody's viewing experience...

m

[jdobbs]

Well, I think that's true among Users, but the Developers ought to know how x264 works, shouldn't they? Yes. But then x264 can be used for much more than just blu-ray. There are a lot of options in x264 -- and the developers understand the implications of all of them. The questions arise in asking ourselves what is really blu-ray compliant, since that's the goal of blu-ray backup.

I don't understand vbv (duh),... It's really not that complicated. When you're dealing with variable bitrates you have to have somewhere to buffer the variability of it. You always want bytes available when you reach for them so the buffer needs to have something in it -- and when data comes in faster than you are decoding you need them to be kept there until you reach for them. An important clarification is that it isn't even really called VBV in H.264, it's the Coded Picture Buffer (CPB). Same purpose, though. So when you hear someone talk about the CPB you can relate it to the VBV function.

[laserfan]

It's really not that complicated. When you're dealing with variable bitrates you have to have somewhere to buffer the variability of it. You always want bytes available when you reach for them so the buffer needs to have something in it -- and when data comes in faster than you are decoding you need them to be kept there until you reach for them. An important clarification is that it isn't even really called VBV in H.264, it's the Coded Picture Buffer (CPB). Same purpose, though. So when you hear someone talk about the CPB you can relate it to the VBV function.So you're saying that the buffer size, for example, has to be chosen such that "for any image the player has to decode at one instant, the amount of buffer space the decoder may have to allocate can't get bigger than x"...? So it's building the video stream to that size which the decoder can deal with in any given instant?

Ouch, my head hurts again. Glad you are "on the case"--although a lot of people seem to be building "mini-blu-rays" now it does also seem that no one (else) has been discussing this specific question.

[jdobbs]

Actually they aren't "mini blu-rays". Apparently the standard includes a BD-9 format (which curiously includes both DVD-9 and DVD-5 disc sizes).

[jdobbs]

Not sure why this thread got closed... if I did it, it was an accident. Just reopened it.

[GZZ]

Thats what happen jdobbs, good to see it open again. :)

After I changed my script for x264 TSmuxer sees my stream as 1920:1084p and not 1920:1080p. I can see from my log and my avs script that the output is 1920:1080p and all other programs (dgavcdec, mediainfo etc.) see the stream as 1920:1080p except for TSmuxer, anyone know if this is a TSmuxer issue, only problem is that it mux the subtitle in the same resolution as my video and then they dont work in powerdvd, so I have to change that manually in my meta file. Pretty wierd problem. Anyone tried this ?

[Adub]

There is the possibility that it is actually a bug in TSMuxer.

[mouw]

been making BluRay movie backUps now 4about 2mos
learned quite a bit here on Doom9 & AVSforum threads
using RipBot264 with eXcellent results (27+ BD9/BD-R) NO Coasters
PlayBack is Sony BDP350 -> IN7210 PJ -> 9ft screen w/surround sound
i can see small differences in PQ w/BD9 but not much on BD-R
even though BD-R 25g is compressed from 30-40g original m2ts file
looking forward to JDOBBS upComing App/GUI

more on my Routine (http://forum.doom9.org/showthread.php?p=1196419#post1196419)

[jdobbs]

Well... just fixed something in BD Rebuilder that had been giving me problems for a while. It shouldn't be long before I can post it. Right now I'm concentrating on the "full backup" of BDs on to BD-9 or BD-5 -- so far it looks pretty good.

[vwpassion]

@jdobbs

Will BD Rebuilder support menu encoding? From what I've seen menus on blurays are usually around 20 - 400 mb give or take... I could imagine by encoding them it wouldn't be a huge problem to keep them on the BD (unless they are very big).

[magic144]

hi jobbs,
just wondering if your bd-rebuilder solution will be based around tsmuxer or eac3to (or if that will be independent/up-to-the-user somehow)

seems that eac3to is quite mature these days and capably handles things like branching/versions (removing video/audio gaps) ... I must admit I'm not overly familiar with tsmuxer these days

[jdobbs]

The first beta release will use TSMUXER with some post-mux tweaking by my own code. Soon after I will release a version with my own code for muxing that doesn't require TSMUXER. I decided to go that way to avoid delays.

[magic144]

sounds good - actually thinking about it, I guess dvd-rebuilder is totally ripper independent, which is why I was asking

thing about Blu is there are more variations than with DVD
so many more codecs! (AVC, VC-1, MPEG-2, not to mention all the audio...)

one more question, does this BD-9 re-authoring allow you to re-use the subtitles "as-is" - the one bugbear I have with my current process/workflow is that I have to tediously convert all the subs via OCR to .srt for use in this .mkv format - freedom from that would be fantastic, although the downside is there wouldn't be any freeware PC playback solutions... if only DirectVobSub supported native BD subs!