BD Rebuilder Beta - Bug Reports Only

[jdobbs]

Good find. Someone should really post these issues in the H.264 forum as it's an x264 issue.



I can see a fix and really some needed cleanup from the last few posts, removing one or the other TARGET_SIZE parameters in the ini, wouldn't fixing it be better then re-introducing an old bug?

Did you get around to removing --stats and --pass from crf encodes as well? Fix it? It's the O/S or it would work the same every time, it's not like the code is changing between calls. I don't know what TARGET_SIZE has to do with anything... if you read the posts you'll see that there is no relationship to the settings... it's random.

As I said in my previous response. The "--stats" and "--pass" parameters are there for a reason. There is no reason to remove them as they have no negative effect.

[leChameleon]

Removed. I'll post side by side comparisons.

[turbojet]

Fix it? It's the O/S or it would work the same every time, it's not like the code is changing between calls. I don't know what TARGET_SIZE has to do with anything... if you read the posts you'll see that there is no relationship to the settings... it's random.

Maybe I'm misunderstanding but what I've gathered by reading the posts is if TARGET_SIZE and/or CUSTOM_TARGET_SIZE are edited through the ini it doesn't pick up pass 2 stats on problematic OS's, if it's set through gui it doesn't. If it's not this could it be non-english versions of Windows?

Also is there any purpose in 2 different target_size parameters?

As I said in my previous response. The "--stats" and "--pass" parameters are there for a reason. There is no reason to remove them as they have no negative effect.

I didn't notice but what purpose do they serve with --crf?

[jdobbs]

I went through the posts, and there is no consistency. Not once is there a time when taking a single action results in the same result and is repeatable. That's the key...

This isn't the first microsoft system call to show issues, and I'm sure it won't be the last. It's very possible that this is the reason I switched to a window search the first time around... I remember there was something goofy related to the call -- but don't remember exactly what.

TARGET_SIZE is the size that is selected and is in use, and it changes every time you make a choice from the menu.

CUSTOM_TARGET_SIZE is size that can be selected from the menu and stays persistent while other selections are made.

If you use a CRF and it oversizes (which happens often), your only choice is to then start over and do another CRF (with another possible over/undersize) or redo it with a two-pass. If, however, you do a CRF with and keep the pass/stats data, you can do a simple second pass and resize exactly while taking advantage of the data collected during the CRF pass. And there is no real reason not to do it.

[turbojet]

I went through the posts, and there is no consistency. Not once is there a time when taking a single action results in the same result and is repeatable. That's the key...

This isn't the first microsoft system call to show issues, and I'm sure it won't be the last. It's very possible that this is the reason I switched to a window search the first time around... I remember there was something goofy related to the call -- but don't remember exactly what.

Does it have to do with getting PID? If so that could make pause/resume which has been requested by quite a few before a pretty sticky thing to implement if you were planning on it. Well it would have the same type of bug windows search has, it wouldn't know what process BD-RB is really using.

TARGET_SIZE is the size that is selected and is in use, and it changes every time you make a choice from the menu.

CUSTOM_TARGET_SIZE is size that can be selected from the menu and stays persistent while other selections are made.

Oh I understand now, guess they are in some ways needed if you are simply relying on the ini for both.

If you use a CRF and it oversizes (which happens often), your only choice is to then start over and do another CRF (with another possible over/undersize) or redo it with a two-pass. If, however, you do a CRF with and keep the pass/stats data, you can do a simple second pass and resize exactly while taking advantage of the data collected during the CRF pass. And there is no real reason not to do it.[/QUOTE]

Oh I see, but isn't requiring the user to re-encode something you are trying to avoid?

Maybe when the sizing issues are resolved you'll remove them or have an option to remove them?

Call me anal or what have you but being someone that does browse and use the WORKFILES folder for various testing and such the first thing I do is delete all the stats files except main movie, sometimes there's well over 100 which makes it tough to browse files.

[MikeyBK]

No turbojet, you aren't anal..lol.... in fact I like some of what you post, but there is also such a thing as overdoing things. I'm like you in many other processes, especially video editing, but a somewhat wise, perhaps more like a wise'ass', member once said something to me that makes too much sense to ignore.... "while most search for ways to make things easier or more efficient, I'm over there trying to complicate the whole process by testing too much"... kinda like you appear to be doing with BD-RB... right GaPony??:p:)

[PurpleMan]

Another bug report:

Using v0.22.02 with Starship Troopers, all the extras failed to encode becuase BD-RB has put the FieldDeinterlace() before the ConvertToYV12() in the AVS scripts.

FieldDeinterlace required YV12/YUY2 input.

Had to edit all the AVS's myself (and disable BD-RB's overwriting them) in order to get it to complete.

[PurpleMan]

Good find. Someone should really post these issues in the H.264 forum as it's an x264 issue.

It's not a x264 bug, it's a WMVideo Decoder bug.

I tried rendering the m2ts in graphedit, attached ffdshow at the end (after the decoder), and enabled OSD. It then shows 23.975 as the framerate. Which means that x264 is getting the same input.

[turbojet]

Another bug report:

Using v0.22.02 with Starship Troopers, all the extras failed to encode becuase BD-RB has put the FieldDeinterlace() before the ConvertToYV12() in the AVS scripts.

FieldDeinterlace required YV12/YUY2 input.

Had to edit all the AVS's myself (and disable BD-RB's overwriting them) in order to get it to complete.

While it should be fixed there is a better way to approach interlaced by putting KEEP_INTERLACING=1 in the ini the movement is more fluid even on a progressive TV and the encode is much more efficient and actually 30p is not in the standards neither is 720x576 25p.

It's not a x264 bug, it's a WMVideo Decoder bug.

I tried rendering the m2ts in graphedit, attached ffdshow at the end (after the decoder), and enabled OSD. It then shows 23.975 as the framerate. Which means that x264 is getting the same input.

It happens with MPEG2 (ffdshow/powerDVD decoders) and AVC (ffdshow/coreAVC/powerDVD decoders) sources as well, with the sources I used DivX H.264 outputs 23.976024 which is correct from WMVideo decoder. x264 outputs 25, 29.970030, 50 and 59.940060 correctly from all decoders mentioned. However I'm using Windows 7 that has a newer WMVideo through ffdshow, ffdshow is reporting 23.976 fps through graphstudio but I get 23.975986 after encoding.

[MikeyBK]

Well I finally had a failure... on the Fired Up Bluray, which is a seamless branched title.... Failure to retrieve audio.

Only has TrueHD, so not sure what's the problem. I'll give it a few more tries with differing settings and if no go, will append the title into a single m2ts using TSMuxer and try that.

[turbojet]

Well I finally had a failure... on the Fired Up Bluray, which is a seamless branched title.... Failure to retrieve audio.

Only has TrueHD, so not sure what's the problem. I'll give it a few more tries with differing settings and if no go, will append the title into a single m2ts using TSMuxer and try that.

You can usually get a more informative error if you use tsmuxer with the <AUD_.meta file that failed> <output folder> from command line.

[jdobbs]

It's not a x264 bug, it's a WMVideo Decoder bug.

I tried rendering the m2ts in graphedit, attached ffdshow at the end (after the decoder), and enabled OSD. It then shows 23.975 as the framerate. Which means that x264 is getting the same input. That's what I suspected. It's easy to fix. I've added the --fps switch to X264 in the next version.

[jdobbs]

Another bug report:

Using v0.22.02 with Starship Troopers, all the extras failed to encode becuase BD-RB has put the FieldDeinterlace() before the ConvertToYV12() in the AVS scripts.

FieldDeinterlace required YV12/YUY2 input.

Had to edit all the AVS's myself (and disable BD-RB's overwriting them) in order to get it to complete. So if the input isn't in YV12 or YUY2, what is it? I've done Starship Troopers before -- but I'll try it again. I guess it wouldn't hurt to put the ConvertToYV12() before it. The problem is that I also need to put the (future) editable filters there also and I wanted to avoid multiple conversions as they are time comsuming.

[jdobbs]

Oh I see, but isn't requiring the user to re-encode something you are trying to avoid?

Maybe when the sizing issues are resolved you'll remove them or have an option to remove them? You obviously either didn't read my answer or don't understand it. There IS NO SIZE CONTROL IN CRF!!!!!! CRF is quality based and creates whatever size you need in order to get to the specified quality level. So OVERSIZING HAPPENS whether you like it or not -- even with the best estimating algorithm and it will never "be resolved".

I appreciate your contributions, but this is a silly discussion over something that makes absolutely no difference -- and this is my last post on the subject. Continuing an argument like this gives a person the impression that you are more interested in appearing to be right than listening to the reasoning behind the settings.

End of discussion. Let's go on to something else.

[jdobbs]

While it should be fixed there is a better way to approach interlaced by putting KEEP_INTERLACING=1 in the ini the movement is more fluid even on a progressive TV and the encode is much more efficient and actually 30p is not in the standards neither is 720x576 25p. Please don't suggest this. I put it in to make it possible -- but the statement "more fluid even on a progressive TV" just isn't accurate. Many standalone/high-end monitors show combing pretty much on every interlaced source -- and its annoying as hell. The default is the default because in most cases it works better.
Does it have to do with getting PID? If so that could make pause/resume which has been requested by quite a few before a pretty sticky thing to implement if you were planning on it. Well it would have the same type of bug windows search has, it wouldn't know what process BD-RB is really using. No, I get the PID ok. But when I search the existing windows for a handle that matches what is returned from a call to GetWindowThreadProcessId() in order to capture it for use, it apparently isn't finding a match. So the only alternative is to grab the first X264 window that is available.

Of course that's only an educated guess -- as I've never actually seen it happen on my system.

[MikeyBK]

TSMuxer is detecting overlapped frames and removing the frames, quite a lot. The resulting appended BDMV is having all kinds of crackling audio.... only if a append the seamless branched playlist with TSMuxer, while downconverting the TrueHD to AC3, will the output be stable and run properly through BD-Rebuilder.

This is only on the Bluray Fired Up.... odd.

[setarip_old]

@MikeyBK

Hi!This is only on the Bluray Fired UpWhich version?

[MikeyBK]

@MikeyBK

Hi!Which version?

Either versions of the movie, either playlist loaded into BD-RB will result in the failure to retrieve audio error. The unrated version is simply a playlist with several different m2ts files which makes that version about 50 seconds longer.

[turbojet]

That's what I suspected. It's easy to fix. I've added the --fps switch to X264 in the next version.

This won't fix anything, the x264 devs know about it and so hopefully a fix will be forthcoming. --fps is bit identical for 25, 29.970030, 50, 59.940060 fps currently and when 23.976024 is fixed it should also be bit identical. As far as I know RipBot264 only uses it because avs2yuv always outputs 25 fps without it.

You obviously either didn't read my answer or don't understand it. There IS NO SIZE CONTROL IN CRF!!!!!! CRF is quality based and creates whatever size you need in order to get to the specified quality level. So OVERSIZING HAPPENS whether you like it or not -- even with the best estimating algorithm and it will never "be resolved".

I appreciate your contributions, but this is a silly discussion over something that makes absolutely no difference -- and this is my last post on the subject. Continuing an argument like this gives a person the impression that you are more interested in appearing to be right than listening to the reasoning behind the settings.

End of discussion. Let's go on to something else.

I've been using x264 for about 2 years now and I realize CRF has no sizing control but if what you said about the workflow being add up all CRF extras + everything else to achieve video bitrate (many guis can already obtain this within 5 MB of the target) what reason is there to give an option to do a second pass on the extras like you are insisting?

It seems you are keeping these files for the same reason you always encoded audio which you've now given an option for.

Since very early days of DVD-RB it has hit within 10 MB of target 99% of the time for me and I never remember it having a bunch of files that were never used lying around.

Please don't suggest this. I put it in to make it possible -- but the statement "more fluid even on a progressive TV" just isn't accurate. Many standalone/high-end monitors show combing pretty much on every interlaced source -- and its annoying as hell. The default is the default because in most cases it works better.

I thought you cared about standards, where is 480p, 576p 29.97p in the standards?

We are obviously viewing from different BD players then, interlaced content on retail BD's play just fine on Panasonic BD30 on a samsung LCD TV. In fact Panasonic's don't play 576p for sure and probably not 480p or 29.97p either.

[GaPony]

I don't see you helping your case any... If RipBot works so well for you, why are you messing around with BD_Rebuilder? Maybe just leaving it alone until it matures to a useable level for your needs might be better.

Don't take this as a slam. Simply an observation.

[PurpleMan]

That's what I suspected. It's easy to fix. I've added the --fps switch to X264 in the next version.

What I'm interested in, is whether or not it's an actual problem with our already backed (previously encoded) discs.

I mean, if the backed up BD plays at 23.975, does that mean we have an audio desync?

[kilbowie54]

I'm having problems with the latest version of BD Rebuilder.
Log:
[22:57:10] BD Rebuilder v0.22.02 (beta)
- Source: CRANFORD_01
- Input BD size: 13.94 GB
- Approximate total content: [00:58:16.351]
- Target BD size: 4.27 GB
- MOVIE-ONLY mode enabled
[22:57:10] PHASE ONE, Encoding
- [22:57:10] Extracting audio/subs [VID_00000]
- [23:01:47] Reencoding: VID_00000 (1 of 1)
- Encode failed. Retrying.
[00:41:32]PHASE ONE aborted by user request
-----------------------
[00:43:14] BD Rebuilder v0.20.09 (beta)
- Source: CRANFORD_01
- Input BD size: 13.94 GB
- Approximate total content: [00:58:16.351]
- Target BD size: 4.27 GB
- MOVIE-ONLY mode enabled
[00:43:18] PHASE ONE, Encoding
- [00:43:18] Extracting audio/subs [VID_00000]
- [00:51:16] Reencoding: VID_00000 (1 of 1)
- Encode failed. Retrying.
[01:10:04]PHASE ONE aborted by user request
-----------------------
[10:31:04] BD Rebuilder v0.22.02 (beta)
- Source: CRANFORD_01
- Input BD size: 13.94 GB
- Approximate total content: [00:58:16.351]
- Target BD size: 4.27 GB
- MOVIE-ONLY mode enabled
- Resuming from previously started job.
[10:31:06] PHASE ONE, Encoding
- [10:31:06] Reencoding: VID_00000 (1 of 1)
- Encode failed. Retrying.
- Encode failed. Retrying.
- Reached retry limit. Aborting.
[10:32:26] - Failed video encode, aborted

x264.exe stops working every time at "Current Progress 0.50% Overall Progress 0.25%.
I wonder if it's connected to a Windows Vista update ALLOWED? One of the updates was a "Cumulative Update for Media Center for Windows Vista (KB967632)"?
Any help greatly appreciated.
Thanks

[turbojet]

Workaround for the 23.975 fps problem (http://forum.doom9.org/showthread.php?p=1295847#post1295847) until x264 is fixed.

What I'm interested in, is whether or not it's an actual problem with our already backed (previously encoded) discs.

I mean, if the backed up BD plays at 23.975, does that mean we have an audio desync?

Technically yes but it's so small of a change that unless you have a very long clip like 10+ hours you won't notice it.

I'm having problems with the latest version of BD Rebuilder.
Log:
[22:57:10] BD Rebuilder v0.22.02 (beta)
- Source: CRANFORD_01
- Input BD size: 13.94 GB
- Approximate total content: [00:58:16.351]
- Target BD size: 4.27 GB
- MOVIE-ONLY mode enabled
[22:57:10] PHASE ONE, Encoding
- [22:57:10] Extracting audio/subs [VID_00000]
- [23:01:47] Reencoding: VID_00000 (1 of 1)
- Encode failed. Retrying.
[00:41:32]PHASE ONE aborted by user request
-----------------------
[00:43:14] BD Rebuilder v0.20.09 (beta)
- Source: CRANFORD_01
- Input BD size: 13.94 GB
- Approximate total content: [00:58:16.351]
- Target BD size: 4.27 GB
- MOVIE-ONLY mode enabled
[00:43:18] PHASE ONE, Encoding
- [00:43:18] Extracting audio/subs [VID_00000]
- [00:51:16] Reencoding: VID_00000 (1 of 1)
- Encode failed. Retrying.
[01:10:04]PHASE ONE aborted by user request
-----------------------
[10:31:04] BD Rebuilder v0.22.02 (beta)
- Source: CRANFORD_01
- Input BD size: 13.94 GB
- Approximate total content: [00:58:16.351]
- Target BD size: 4.27 GB
- MOVIE-ONLY mode enabled
- Resuming from previously started job.
[10:31:06] PHASE ONE, Encoding
- [10:31:06] Reencoding: VID_00000 (1 of 1)
- Encode failed. Retrying.
- Encode failed. Retrying.
- Reached retry limit. Aborting.
[10:32:26] - Failed video encode, aborted

x264.exe stops working every time at "Current Progress 0.50% Overall Progress 0.25%.
I wonder if it's connected to a Windows Vista update ALLOWED? One of the updates was a "Cumulative Update for Media Center for Windows Vista (KB967632)"?
Any help greatly appreciated.
Thanks

Try the workarounds for interlaced VC-1 (http://forum.doom9.org/showthread.php?t=146924). That update shouldn't have any effect.

[PurpleMan]

Technically yes but it's so small of a change that unless you have a very long clip like 10+ hours you won't notice it.


Not exactly true. for a 2 hours movie that would introduce around 35ms of gradual desync. Don't know about you, but I usually notice this and it's annoying :)

[PurpleMan]

Workaround for the 23.975 fps problem (http://forum.doom9.org/showthread.php?p=1295847#post1295847) until x264 is fixed.


Do you know of a workaround to an already encoded h264 stream? Surely there is a way to change the header from 23.975 to 23.976.

Thanks

[kilbowie54]

Thanks for your reply.
I've read through the "workarounds for interlaced VC-1" thread. The file in question is VC-1 1080i so I guess that's the underlying problem?
Unfortunately, I'm not sure how to apply the suggested workarounds. I'm not as technically advanced as many of the guys that post on here.
I'm running Vista 32 bit so the Windows 7 workaround doesn't apply. I don't use TMT - my backups are played on a standalone Denon 2500BT.
I looked at the BD-REBUILDER.INI but I can't see where to apply the suggested workaround.
Is there any help that you can give me in simple terms?

Thanks.

[turbojet]

What I'm interested in, is whether or not it's an actual problem with our already backed (previously encoded) discs.

I mean, if the backed up BD plays at 23.975, does that mean we have an audio desync?

You are correct, I was overestimating by quite a bit. It's 27ms for 2 hours if my math is correct
23.976024 - 23.975986 = 0.000038 skew per second
60 seconds x 120 minutes = 7200 seconds
0.000038 * 7200 = 0.2736 seconds

Is that correct?

Thanks for your reply.
I've read through the "workarounds for interlaced VC-1" thread. The file in question is VC-1 1080i so I guess that's the underlying problem?
Unfortunately, I'm not sure how to apply the suggested workarounds. I'm not as technically advanced as many of the guys that post on here.
I'm running Vista 32 bit so the Windows 7 workaround doesn't apply. I don't use TMT - my backups are played on a standalone Denon 2500BT.
I looked at the BD-REBUILDER.INI but I can't see where to apply the suggested workaround.
Is there any help that you can give me in simple terms?

Thanks.

If you are targeting BD25 you can open the ini and put in MIN_M2TS=<size in MB just above the m2ts that's failing>

If you are targeting DVD if the problematic m2ts is small you can use the min_m2ts too. If the untouched m2ts would take up significant space you can use this tool (http://www.mediafire.com/download.php?exagzvt2xzu) to use windows 7's VC-1 decoder in vista or use powerDVD decoder (http://www.mediafire.com/download.php?mkyqtmkzmz3).

[turbojet]

Do you know of a workaround to an already encoded h264 stream? Surely there is a way to change the header from 23.975 to 23.976.

Thanks

Ya

- Change the framerate with tsmuxer or mkvmerge or mp4box to something other than 23.976 you get 'changed output'
- Insert 'changed output' into tsmuxer, change fps to 23.976 and output

[PurpleMan]

You are correct, I was overestimating by quite a bit. It's 27ms for 2 hours if my math is correct
23.976024 - 23.975986 = 0.000038 skew per second
60 seconds x 120 minutes = 7200 seconds
0.000038 * 7200 = 0.2736 seconds

Is that correct?


well, according to your calculation, it's not 27ms, it's 270ms.

1 second = 1000 ms
so 0.2736 seconds = 0.2736 * 1000 = 273.6ms

Either way:

1) can we fix an already encoded h264 file to play at 23.976?

2) are you sure that the BD will play at 23.975 on the current state? I mean, 23.975 is out of spec for BD, plus the fact that the m2ts container is flagged as 23.976 (again, because 23.975 is out of spec). So for all we know, a BD player actually plays it as 23.976 even though we feed it as 23.975 for x264.

Your thoughts?

and P.S.
I asked before, but nobody replied. do you know the exact size in bytes that fit on a BD-R 25? is it 25,000,000,000 bytes?
I just want to know when BD-RB gives an undersized/oversized output.

Regards,
-purpleman2k

[turbojet]

well, according to your calculation, it's not 27ms, it's 270ms.

1 second = 1000 ms
so 0.2736 seconds = 0.2736 * 1000 = 273.6ms

I was thinking that too but people would certainly be reporting it if it was.

Either way:

1) can we fix an already encoded h264 file to play at 23.976?

2) are you sure that the BD will play at 23.975 on the current state? I mean, 23.975 is out of spec for BD, plus the fact that the m2ts container is flagged as 23.976 (again, because 23.975 is out of spec). So for all we know, a BD player actually plays it as 23.976 even though we feed it as 23.975 for x264.

Your thoughts?

1) see my previous post

2) since it is so close to 23.976024 players may just play it as 23.976024 which would explain why there's no async. I'm pretty sure 23.975 isn't part of the BD standard, we may just be lucking out that it plays.

and P.S.
I asked before, but nobody replied. do you know the exact size in bytes that fit on a BD-R 25? is it 25,000,000,000 bytes?
I just want to know when BD-RB gives an undersized/oversized output.

Regards,
-purpleman2k

25,025,314,816 bytes according to this (http://www.emedialive.com/articles/readarticle.aspx?articleid=11420#ivb)

[PurpleMan]

1) see my previous post


Your previous post (if I understand correctly) only solves the problem for new encodes (by editing the AVS), I'm talking about an already encoded file.


2) since it is so close to 23.976024 players may just play it as 23.976024 which would explain why there's no async. I'm pretty sure 23.975 isn't part of the BD standard, we may just be lucking out that it plays.


I'm not sure of that at all. Like people in the other thread (the x264 one you referred to) said, when you put the raw video in a container (in our case m2ts) and the container is flagged as 23.976, a player will play at that rate, regardless of what is in the raw header. Of course, I have no way to verify this.




25,025,314,816 bytes according to this (http://www.emedialive.com/articles/readarticle.aspx?articleid=11420#ivb)

Thank you :)

[turbojet]

Your previous post (if I understand correctly) only solves the problem for new encodes (by editing the AVS), I'm talking about an already encoded file.

this one (http://forum.doom9.org/showthread.php?p=1295903#post1295903)

I'm not sure of that at all. Like people in the other thread (the x264 one you referred to) said, when you put the raw video in a container (in our case m2ts) and the container is flagged as 23.976, a player will play at that rate, regardless of what is in the raw header. Of course, I have no way to verify this.

Ya I don't know either.

Thank you :)

No problem

[kilbowie54]

Hi again.
Installed Windows 7's VC-1 decoder in vista but x246.exe stopped working at 0.40% on the video re-encode. Tried the PowerDVD decoder - same problem at 0.70% this time.
Is this "VC-1 1080i" a problem that's unfixable at present? I have the same build of BD-RB running at present on another quad core PC (Vista 64 bit) working with a VC-1 file that's 1080p and it's doing OK - at 37% and no problems.
Maybe I should just be grateful for what I can get to work!
If anyone's got any other ideas, I'd like to try them anyway.

Thanks again for all your help.

[turbojet]

Hi again.
Installed Windows 7's VC-1 decoder in vista but x246.exe stopped working at 0.40% on the video re-encode. Tried the PowerDVD decoder - same problem at 0.70% this time.
Is this "VC-1 1080i" a problem that's unfixable at present? I have the same build of BD-RB running at present on another quad core PC (Vista 64 bit) working with a VC-1 file that's 1080p and it's doing OK - at 37% and no problems.
Maybe I should just be grateful for what I can get to work!
If anyone's got any other ideas, I'd like to try them anyway.

Thanks again for all your help.

I haven't seen reports of video so far that hasn't worked. Unfortunately no developers are currently working on fixing this issue. ffdshow may in due time. Could you cut a few seconds of where the encoder fails with tsmuxer and uncheck all streams but the video stream, output to m2ts and upload it to a site like mediafire (http://www.mediafire.com/)?

Others and I can then help resolve the problem then.

[kilbowie54]

Thanks - I'll work on that. As I said earlier, I'm not that skilled technically and trying to understand codecs can leave me with a headache!
Thanks again.

[jdobbs]

I've been using x264 for about 2 years now and I realize CRF has no sizing control but if what you said about the workflow being add up all CRF extras + everything else to achieve video bitrate (many guis can already obtain this within 5 MB of the target) what reason is there to give an option to do a second pass on the extras like you are insisting?

It seems you are keeping these files for the same reason you always encoded audio which you've now given an option for.

Since very early days of DVD-RB it has hit within 10 MB of target 99% of the time for me and I never remember it having a bunch of files that were never used lying around. I said I wouldn't comment -- but since you can't let anything go...

I tried to explain the reasoning but you're too bullheaded to back off. Bottom line: It's my damn program and I'll do it the way I think best, if you don't like it use something else.

[jdobbs]

[Removed]

[Capsbackup]

@kilbowie54;
You could try to run the problem .m2ts/.mpls thru tsmuxer and select change frame rate, 24000/0001 and check remove pulldown box and then create a new .m2ts or bluray, if those options are available within tsmuxer. This has worked for me before, but if the source is truly interlaced, this probably will not work.

[jdobbs]

BD-RB already puts the framerate as 23.976 when it muxes with TSMUXER.

[Capsbackup]

BD-RB already puts the framerate as 23.976 when it muxes with TSMUXER.

I was referring to changing the original .m2ts to 23.976fps before using BD-RB on it. I know it is a long shot, but it did work for me on Terminator 3, region A. This troublesome disc had no audio sync from the very beginning and got worse as it played. But after this change, audio sync was perfect and BD-RB reencoded it to BD-5 perfectly.

[turbojet]

I said I wouldn't comment -- but since you can't let anything go...

I tried to explain the reasoning but you're too bullheaded to back off. Bottom line: It's my damn program and I'll do it the way I think best, if you don't like it use something else.

Sigh, you completely misunderstand me.

Anyhow I see you are showing the same type of behavior you showed with encoding audio insisting for months that it must be done, so I'll just let it runs it's course.

I was referring to changing the original .m2ts to 23.976fps before using BD-RB on it. I know it is a long shot, but it did work for me on Terminator 3, region A. This troublesome disc had no audio sync from the very beginning and got worse as it played. But after this change, audio sync was perfect and BD-RB reencoded it to BD-5 perfectly.

Wasn't this also fixable by keeping it interlaced?

[jdobbs]

@turbojet

See my comment in the X264 thread (http://forum.doom9.org/showthread.php?p=1295847#post1295847).

If X264 is outputing a rate of 23.975986, and my calculations are correct you would be off by one frame (1/24th of a second) every 7.3 hours of contiguously encoded video.

If anybody can detect that, they'd better be wearing a cape.

[kooibosmania]

hi JDobbs

Great work i love ur app

bug Report

on all the movies from startrek the extra's have a trailing m2ts file of 230MB

this m2ts file becomes the first to be reencoded and it fails.
i dont know what this track is but has many audio and subs but is very short ( 0007FFF8 - 00082329 ) i have been struggeling with this.
Maby it is an option to let the user select the faulty m2ts and remove it from the qeue.
but as it is part of an mpls file i dont know if it is possible to implement in ur programming.

i know it is very difficult to programmaticly determine whats what

adding the min m2ts size does not remove this m2ts from qeue

-----------------------
[16:25:20] BD Rebuilder v0.22.02 (beta)
- Source: STAR_TREK_III_THE_SEARCH_FOR_SPOCK
- Input BD size: 42,95 GB
- Approximate total content: [04:26:34.144]
- Target BD size: 22,71 GB
[16:25:22] PHASE ONE, Encoding
- [16:25:22] Extracting audio/subs [VID_00064]
- [16:25:22] Reencoding: VID_00064 (1 of 13)
- Error in attempt to multiplex: MUX_00064.meta
[16:25:23] - Failed to build structure, aborted

Thanks and keep up the good work

[Capsbackup]

@turbojet;
Wasn't this also fixable by keeping it interlaced?

No, not by BD-RB. That is why I opened a new thread, to try to see if it would be more noticeable. It was not given much response. Apparently just a rare disc and authoring. Oh well, just trying to present experiences and results, so I just brought it up again in case it might help someone or this topic. :)

[jdobbs]

I was referring to changing the original .m2ts to 23.976fps before using BD-RB on it. I know it is a long shot, but it did work for me on Terminator 3, region A. This troublesome disc had no audio sync from the very beginning and got worse as it played. But after this change, audio sync was perfect and BD-RB reencoded it to BD-5 perfectly. So you're saying that demuxing it first using the fps parameter rather than encoding from the original stream (using the framerate tagged to the stream) actually resulted in a different outcome?

That's just scary.

[Capsbackup]

So you're saying that demuxing it first using the fps parameter rather than encoding from the original stream (using the framerate tagged to the stream) actually resulted in a different outcome?

That's just scary.

That is correct. If your curious, try Terminator 3, Region A.
And from a previous post:http://forum.doom9.org/showthread.php?t=146884
Maybe rare, but it worked.

[jdobbs]

Hi again.
Installed Windows 7's VC-1 decoder in vista but x246.exe stopped working at 0.40% on the video re-encode. Tried the PowerDVD decoder - same problem at 0.70% this time.
Is this "VC-1 1080i" a problem that's unfixable at present? I have the same build of BD-RB running at present on another quad core PC (Vista 64 bit) working with a VC-1 file that's 1080p and it's doing OK - at 37% and no problems.
Maybe I should just be grateful for what I can get to work!
If anyone's got any other ideas, I'd like to try them anyway.

Thanks again for all your help. This whole hybrid VC-1 source issue is just a pain... unfortunately there is currently no fix for BD-5/9 output, because it has to be reencoded to get the bitrate down to the required level. As for BD-25, I'll look into ways of detecting it so I can automatically just keep it intact (assuming it isn't so large a source stream as to cause space issues).

[Capsbackup]

This whole hybrid VC-1 source issue is just a pain... unfortunately there is currently no fix for BD-5/9 output, because it has to be reencoded to get the bitrate down to the required level. As for BD-25, I'll look into ways of detecting it so I can automatically just keep it intact (assuming it isn't so large a source stream as to cause space issues).

This method would work on Terminator 3, but again, probably a rare disc.

[jdobbs]

Anyhow I see you are showing the same type of behavior you showed with encoding audio insisting for months that it must be done, so I'll just let it runs it's course. Sigh...

You know, between the two of us I think we know just about everything there is to know.

You seem to know everything except that you're wrong -- and I know that.

[jdobbs]

hi JDobbs

Great work i love ur app

bug Report

on all the movies from startrek the extra's have a trailing m2ts file of 230MB

this m2ts file becomes the first to be reencoded and it fails.
i dont know what this track is but has many audio and subs but is very short ( 0007FFF8 - 00082329 ) i have been struggeling with this.
Maby it is an option to let the user select the faulty m2ts and remove it from the qeue.
but as it is part of an mpls file i dont know if it is possible to implement in ur programming.

i know it is very difficult to programmaticly determine whats what

adding the min m2ts size does not remove this m2ts from qeue

-----------------------
[16:25:20] BD Rebuilder v0.22.02 (beta)
- Source: STAR_TREK_III_THE_SEARCH_FOR_SPOCK
- Input BD size: 42,95 GB
- Approximate total content: [04:26:34.144]
- Target BD size: 22,71 GB
[16:25:22] PHASE ONE, Encoding
- [16:25:22] Extracting audio/subs [VID_00064]
- [16:25:22] Reencoding: VID_00064 (1 of 13)
- Error in attempt to multiplex: MUX_00064.meta
[16:25:23] - Failed to build structure, aborted

Thanks and keep up the good workCan you post the contents of MUX_00064.meta?

I'll pick up a copy of that disc. I've been meaning to get the BD versions of the STAR TREK movies anyway.