BD Rebuilder Beta - Bug Reports Only

[jdobbs]

Originally Posted by turbojet

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]

Originally Posted by jdobbs

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]

Originally Posted by 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.

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

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

Originally Posted by turbojet

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]

Originally Posted by 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.

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.

Originally Posted by PurpleMan

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]

Originally Posted by 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.

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]

Originally Posted by PurpleMan

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]

Originally Posted by 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.

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]

Originally Posted by turbojet

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]

Originally Posted by turbojet

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.

Originally Posted by turbojet

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 Up

Which version?

[MikeyBK]

Originally Posted by setarip_old

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

Originally Posted by jdobbs

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.

Originally Posted by jdobbs

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.

Originally Posted by jdobbs

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.