BD Rebuilder Beta - Bug Reports Only

[jdobbs]

Originally Posted by Audiophile1178

jdobbs, I know you're busy but would you be able to answer my questions?

http://forum.doom9.org/showthread.ph...32#post1396732

http://forum.doom9.org/showthread.ph...83#post1397083

1. The secondary video is encoded at a fixed CRF level (the default is 25) in order to save time. So the size isn't the driver... so in some cases it may be small, others large. The intent is to give the secondary a fixed level of quality as opposed to size. You can adjust the quality level with the SECONDARY_CRF=n hidden parameter. Making the value greater reduces secondary video quality while size gets smaller, lowering it does the opposite.

You can also add SECONDARY_USE_QUALITY=1. That will lower the size of the output -- but make the encoding slower.

2. I'll have to test that disc to see if I can repeat the audio sync problem But it has been a long time since I've seen any reports of sync problems (other than one report related to secondary audio).

3. You need to remove those files after the rip and before the encode with BD-RB. I personally only copy the BDMV and CERTIFICATE folders to hard drive when I'm backing up a disc.

As for the disc with two versions on it... a future version of BD-RB will have the ability to blank video, but that's a way down the road.

[steveg32]

FYI TO ALL,

AnyDVD HD latest version 6.6.4.2 has fix to AVATAR processing errors:

6.6.4.2 2010 05 04
- New (Blu-ray): Added support for new BD+ protections, e.g. "Avatar"

Just finished rip. No errors.

[Audiophile1178]

jdobbs, thanks for the fast reply. Sorry to have to ask twice but I felt like I was getting buried.

One other suggestion, would it be possible to change the Shutdown after REBUILD to something else like sleep or create options in the setup that'll tell it what to do? I like to sometimes login remotely to my computer and can't turn it on if it's shutdown.

Thank you again for all you great work!

[9020V]

Originally Posted by cwh060

I have ripped, processed and burned all three to a 25G BDRE using AnyDVD and BD-RB and played back on my PS3 with no issues at all.

I usually run the files into MultiAVCHD, take out the commercials and trailers, then process with BD-RB. Works every time.

I have heard the latest PS3 update severly limits playback of AVCHD file structures. I have not updated my PS3 firmware.

cwh

I am not using MultiAVCHD (I don't know what that is). I just do a full disc backup with everything and the original file structure (use DVDFAB usually), so I keep trailers and everything. Like I said, the weird thing about the informant was that it played the trailers fine, but not the movie (just blank screened). Movie only backups with strict AVCHD compliance checked in BD Rebuilder of these titles work fine. I am starting to suspect the problem may be DVDFAB, but I can't prove that (well I guess I could re-rip with ANYDVD, but I don't want to risk another coaster).

I'm gonna go buy a BD-RE Sony. I am tired of making BD-R coasters.

What did you rip these titles with, DVDFAB or ANYDVD? Mine did not work with the old firmware or the new firmware.

[jangai]

Running PS3 slim FW 3.30 since two weeks without BD-RB backups reading difficulties (Last one was Avatar).

These last days, PS3 reading persists with error "invalid disk" with an Apollo13 backup... I tried all what I could imagine without success...

BD-RB does'nt seems to see any difficulty with this backup - My computer config seems OK...

Any idea or advice welcome...

[SoniG]

Hi jdobbs, just to say I finished testing all the possibilities to make work multi-m2ts movies with stuttering free but I had absolutely no success. A guy said it was the way TSMUXER demux/remux files that is not really compliant. He posted something to deal with these kind of BD in remuxing one of the mpls to have a one m2ts joined version, unfortunately it's more a workaround than a solution and can't be processed automatically (http://forum.doom9.org/showthread.php?t=150511). I heard you about your clpi interest and you are maybe right. I couldn't test the ATC values as nothing allow to edit it. So now I think only you or Pelican can go further about this. And I'm agree with Capsbackup about TSMUXER. Without saying it's a fantastic tool, I think this is just a good beginning and for many things it had to be improved. If you need help, someone to test things, I'm here.

[jdobbs]

Originally Posted by jangai

Running PS3 slim FW 3.30 since two weeks without BD-RB backups reading difficulties (Last one was Avatar).

These last days, PS3 reading persists with error "invalid disk" with an Apollo13 backup... I tried all what I could imagine without success...

BD-RB does'nt seems to see any difficulty with this backup - My computer config seems OK...

Any idea or advice welcome...

Yes. Send a nasty letter to Sony and tell them to stop screwing up the PS3's firmware (either that or tell them to fire the moron who made the changes). Or even better, buy a real player like the Sony BDP-S360 (about $100) instead of a game that pretends to be a player.

Sorry. I have nothing against the PS3 -- but it obviously is not a BD player.

[jdobbs]

Originally Posted by SoniG

Hi jdobbs, just to say I finished testing all the possibilities to make work multi-m2ts movies with stuttering free but I had absolutely no success. A guy said it was the way TSMUXER demux/remux files that is not really compliant. He posted something to deal with these kind of BD in remuxing one of the mpls to have a one m2ts joined version, unfortunately it's more a workaround than a solution and can't be processed automatically (http://forum.doom9.org/showthread.php?t=150511). I heard you about your clpi interest and you are maybe right. I couldn't test the ATC values as nothing allow to edit it. So now I think only you or Pelican can go further about this. And I'm agree with Capsbackup about TSMUXER. Without saying it's a fantastic tool, I think this is just a good beginning and for many things it had to be improved. If you need help, someone to test things, I'm here.

I know what it is, and I'm working on it. All I really have to do is transfer some information from the original into the new CLPI and adjust the ATC_Delta based upon the new bitrate. Unfortunately the majority of players play back fine (including my two), so the issue doesn't exist for most users and has gone unnoticed. The kicker is that I'll have to "farm out" the debugging (I'm looking for volunteers) since I can't repeat it on my systems.

I'll probably have a fix in the next release. TSMUXER isn't creating a non-compliant stream -- it just doesn't know there is seamless branching involved so there isn't any timing adjustments and links added to the CLPI. I highly recommend that no one try to merge the files together as a solution. That's just silly and will cause more problems than it solves. Patience is a virtue.

[deank]

When tsMuxeR creates playlists with seamlessly connected m2ts, the clpi files are properly generated, so it is not a bug in tsMuxeR. (edit: Well I must I've looked at something else - camcoder files - tsMuxeR clpi generated files do not contain the ATC for seamless connection).

Once you add the delta entries it will probably be okay. I guess that since all individually encoded m2ts files start with nal/aud and IDR frames, most players manage to quickly continue the playback without noticeable glitch or stutter - especially when using software players or BD players with lower access times to the physical media.

An important thing to mention is that the physical layout of 2 or more seamlessly connected clips (m2ts files) it also important. The maximum read-access time allowed for repositioning between the end of one and the start of the next is 706ms for single layer and 710ms for dual layer discs.

If by any chance the burning application (like ImgBurn) decides to put these clips far apart, the access time from one to another may exceed the max allowed and cause a slight stutter, too.

A simple example would be seamlessly connected AV clips 00001.m2ts 00603.m2ts 00311.m2ts 00000.m2ts. Their physical order on the media (BD-R disc) will most probably be SORTED, thus causing longer access times when doing the connection.

Even with the correct delta entries the stutter may occur if the connected clips are not properly written to / positioned in the physical layer of the disc.

If ImgBurn respects the order when project file is parsed to it, a simple test solution would be to parse CERTIFICATE and BDMV folders with their subfolders (except the BDMV\STREAM folder) and then add the m2ts files in respect to their usage in the main movie playlist and then add the rest of the m2ts files (those for extras, menus, etc).

Dean

[SoniG]

jdobbs :My BD are in standby mode! I told you some other guys have the issue with their hardware players. Maybe players as I would say Powerdvd deal better to manage this, but if it's to well manage despite missing datas... When you say you can't repeat it on your systems, did you just tried to install TMT3 and test your backups with it? I don't know what you mean by 'I'll have to "farm out" the debugging (I'm looking for volunteers)', but if I can help...

deank : Interesting minds. These kind of files/playback management that cause issues are so obvious and could come from so many places. Unfortunately, from 3 frames freeze, everybody can see it!

[jdobbs]

Originally Posted by SoniG

jdobbs :My BD are in standby mode! I told you some other guys have the issue with their hardware players. Maybe players as I would say Powerdvd deal better to manage this, but if it's to well manage despite missing datas... When you say you can't repeat it on your systems, did you just tried to install TMT3 and test your backups with it? I don't know what you mean by 'I'll have to "farm out" the debugging (I'm looking for volunteers)', but if I can help...

deank : Interesting minds. These kind of files/playback management that cause issues are so obvious and could come from so many places. Unfortunately, from 3 frames freeze, everybody can see it!

I don't test with software players -- they have more bugs than BD-RB does, and you'd never be able to put your finger on anything. I only test on standalone players.

By "farm out" -- I mean I'll have to ask someone who actually experiences the issue to test it for me before I release it. Since the software is "beta" I should be able to do it anyway -- but a lot of people are using as if it is a final product no matter what I say (as can be seen by some of the post referencing "coasters" or "wasted time") -- so I have to be careful with releases that change formats considerably so I don't get inundated with comments.

[crl2007]

What deank and SoniG are trying to say is to use eac3to as a demuxer, because tsMuxer has a bug when it comes to joining m2ts files from branched titles. It freezes on standalone players at the joining point. It continues, but it stutters where tsmuxer joins them. But if you demux with eac3to and recompile with tsmuxer it is ok. Tested.

[deank]

@crl2007: No. You miss the point and that's the reason for your posts in the BDEdit thread. Neither eac3to or tsMuxeR can recreate a branched playlist.

[crl2007]

They can't, but demuxing with eac3to by eac3to.exe -demux movie.mpls would result a h264 stream that will not stutter in standalone players. For keeping the branched structure, you have to edit every single mpls by hand.

[jdobbs]

Originally Posted by deank

@crl2007: No. You miss the point and that's the reason for your posts in the BDEdit thread. Neither eac3to or tsMuxeR can recreate a branched playlist.

Exactly. BD Rebuilder rebuilds the playlist using the original and information from the new encoding. Besides, what we're talking about here is the CLPI file...

@crl2007: It's inaccurate to call it a bug in TSMUXER... it was never designed to create seamless branched titles. That's like saying a hammer has a bug because it doesn't saw wood very well. By the way, there also isn't a bug in the way it demuxes seamless titles -- you just have to know how to use it correctly, and most people don't.

I know how the CLPI is supposed to be built, and I'll rebuild it for seamless branched & multiangled titles. Now whether that will get around any seek/latency issues based on physical location of M2TS files on the disc remains to be seen. I'm optimistic, though, especially since the majority of standalone players don't even show issues with no ATC_Delta at all...

[crl2007]

Yes, standalone players don't show issues if ATC Delta entries aren't present.

I've done 3 tests:

1. Only tsMuxer and in standalone stuttered at join point.
2. demuxed elementary streams with eac3to and feed them to tsmuxer, worked like a charm in standalone. ( no ATC in clpi )
3. Used ClownBD ( eac3to + tsmuxer ) and the resulted BD disc played with no stutters in standalone player. ( no ATC in clpi )

BD-RB is not a tool for re-authoring, it just does for BD's what DVD Rebuilder does for DVD's. But I tell you, those ATC entries aren't the stutter cause.

[tandi]

hi, jdobbs
sorry i know you're been busy
if you have time to look the problem i got
have try it again , but still have same problem

[SoniG]

Originally Posted by jdobbs

By "farm out" -- I mean I'll have to ask someone who actually experiences the issue to test it for me before I release it.

You can count on me, if you care about my poor software players. By the way I don't know what bugs you are talking about, TMT3 plays my originals and manage stuffs from them perfectly well!

[jdobbs]

Originally Posted by crl2007

Yes, standalone players don't show issues if ATC Delta entries aren't present.

I've done 3 tests:

1. Only tsMuxer and in standalone stuttered at join point.
2. demuxed elementary streams with eac3to and feed them to tsmuxer, worked like a charm in standalone. ( no ATC in clpi )
3. Used ClownBD ( eac3to + tsmuxer ) and the resulted BD disc played with no stutters in standalone player. ( no ATC in clpi )

BD-RB is not a tool for re-authoring, it just does for BD's what DVD Rebuilder does for DVD's. But I tell you, those ATC entries aren't the stutter cause.

Well, your opinion is yours. I'm absolutely certain you are wrong and I can also assure you that the problem isn't TSMUXER vs EAC3TO. But let's just leave it at that. If you follow the specs it will work (unless the player violates the spec). Right now there needs to be an adjustment to TSMUXER's seamless branching code in order to correct it to spec (for seamless branching only).

You're also making some apples to oranges comparisons that don't apply at all. What in the world does your ClownBD movie-only output have to do with this issue even in the slightest????? Hell, BD-RB's movie-only output doesn't have the issue either.

[jdobbs]

Originally Posted by tandi

hi, jdobbs
sorry i know you're been busy
if you have time to look the problem i got
have try it again , but still have same problem

To everyone:

A quote from the first post of this thread:

If you decide to download and test -- please post any errors you find in this thread. Don't push bug resolution or keep asking for a fix. I will get to the reported bugs, but only when I can find the time.

I work on issues at a macro level, not an individual level. I prioritize based upon importance of the issue and the number of people I think are affected. Please do not keep asking about your individual issues. I will fix all bugs -- but I will do it at the time I think is most appropriate in the grand scheme of things.