BD Rebuilder Beta - Bug Reports Only

[jdobbs]

Originally Posted by MrVideo

Who knows what the hell CBS is doing with their H.264/4:2:2 encoders.

As a test, I captured 100MB of the same transponder stream using the professional Tandberg IRD. That is this file. It has good in the filename, but for some reason BDRB doesn't like it either.

So, I went back and ran one of the previous files I captured with the same IRD, on the same computer, and that file was still liked by BDRB. That file is 230MB and it is here.

I'm curious what you find out about those two files and why one is working. They might give you more clues as to why BDRB is doing what it is doing.

As a test, you might want to force no VFR testing to see how x264 handles those video streams. If x264 deals with them just fine and converts them to H.264/4:2:0 interlaced, without any issues, it might be easier to code in a no-VFR option instead of trying to code around the weird timestamps.

I got those two files for testing, in case you want to remove them.

The only problem with a no-VFR flag is that the underlying frame rate of VFR can't be determined without a scan. You find, for example, a 23.976 VFR stream might report 20.70fps. In order to import into a Blu-Ray (even pseudo) it has to be converted to a standard frame rate (there are values in the MPLS and CLPI files that need to be set based upon the rate).

[MrVideo]

Originally Posted by jdobbs

I got those two files for testing, in case you want to remove them.

Deleted.

The only problem with a no-VFR flag is that the underlying frame rate of VFR can't be determined without a scan. You find, for example, a 23.976 VFR stream might report 20.70fps. In order to import into a Blu-Ray (even pseudo) it has to be converted to a standard frame rate (there are values in the MPLS and CLPI files that need to be set based upon the rate).

As you can see, those files are for network airing, meaning they are 29.97 1080i. No idea why they are time-coded the way they are.

The "promo" file that works I'm guessing will still show those weirdly ordered time stamps. But, it encodes just fine during the backup phase, resulting in a 29.97 1080i file. Mediainfo shows that it is 1080i29.97. Indicating that it did just fine without VFR. This is assuming that the time stamps are indeed messed up. The BDMV structure was created without error (AFAIK).

I agree with your 23.976 example. But, in this weird case, an override might just be what the doctor ordered. Adding such an override option would have to come with a stern warning that it is for advanced users.

I await the report on the time stamps of the two files, especially the 170905 file.

[Nav1]

Hi, Jdobbs has not post for long long time. Now the new movies are coming out with Dolby Atmos 7.1 ch. Bd Rebuilder does not recognize 7.1 ch. Any future update for Dolby Atmos 7.1 ch. Thanks.

[Lathe]

Originally Posted by MrVideo

I did some more digging and discovered that when a MKV file is created and a TrueHD audio stream is added to the output, the AC3 core is stripped out. Sounds kinda stupid to me. Now to find out why that is done.

UPDATE: Found out why: https://github.com/mbunkus/mkvtoolni...rueHD-and-AC-3

Uh... yeah... (cough...) that is what I said several posts ago...

[MrVideo]

Originally Posted by Lathe

Uh... yeah... (cough...) that is what I said several posts ago...

Not the why.

[Lathe]

Originally Posted by MrVideo

Not the why.

Yeahhhhhhhhhhhhhhhhhhh, BUT... you said it like 'Oh, I found out that when you mux an MKV for SOME reason the AC3 core is stripped out...'

[gonca]

TrueHD has the core "interleaved" into the HD.
MKV spec doesn't allow that. The solution by the Mosu is to mux AC3 and HD tracks seperately.
This was discussed in this thread long ago

[MrVideo]

Actually, if you read what I pointed to, the spec doesn't allow two different codecs in the same track. IMHO, that is just silly. If it is a legit audio stream, it should be allowed. But, I didn't write the spec.

And, I wanted to find out what that "some" reason was.

[jdobbs]

Originally Posted by Nav1

Hi, Jdobbs has not post for long long time. Now the new movies are coming out with Dolby Atmos 7.1 ch. Bd Rebuilder does not recognize 7.1 ch. Any future update for Dolby Atmos 7.1 ch. Thanks.

Untrue. You can just leave the audio track intact. Although I personally don't recommend it. It uses way too much space for a difference that no human ear can detect... but, hey, if wasting space for no purpose rocks your boat -- more power to you.

The last time jdobbs posted, by the way, was about 4 hours before you said he hadn't posted in a "long, long time".

[jdobbs]

Originally Posted by gonca

TrueHD has the core "interleaved" into the HD.
MKV spec doesn't allow that. The solution by the Mosu is to mux AC3 and HD tracks seperately.
This was discussed in this thread long ago

But... to be clear, if they are muxed separately they don't comply with the Blu-Ray standard and won't be imported into the BD structure.

[jdobbs]

Originally Posted by MrVideo

Deleted.

As you can see, those files are for network airing, meaning they are 29.97 1080i. No idea why they are time-coded the way they are.

The "promo" file that works I'm guessing will still show those weirdly ordered time stamps. But, it encodes just fine during the backup phase, resulting in a 29.97 1080i file. Mediainfo shows that it is 1080i29.97. Indicating that it did just fine without VFR. This is assuming that the time stamps are indeed messed up. The BDMV structure was created without error (AFAIK).

I agree with your 23.976 example. But, in this weird case, an override might just be what the doctor ordered. Adding such an override option would have to come with a stern warning that it is for advanced users.

I await the report on the time stamps of the two files, especially the 170905 file.

The one you marked as "good" was 170904. I looked at it -- and it isn't "good". When I import it, it also returns a frame rate of 59.97. Here are the beginning timecodes for that one:

334
367
434
468
501
534
568
601
634
668
701
734
768
801
835
868
901
935
968
1001
1035
1068
1101
1135
1168
1202
1235
1252
1268
1285
1302
1302
1318
1318
1335
1335
1352
1352

As you can see, this one is even stranger. In the beginning it uses timecodes for each frame. Then it switches to timecodes for each field -- and then switches to fields with the top and bottom fields both having the same display timecode.

The 170905 file wasn't seen by MEDIAINFO as variable, so with default settings it would probably import ok because BD-RB would only scan when MEDIAINFO finds variable. But if I force a scan it's timecodes are pretty much like the others -- except there are only a couple examples of identical times for the fields. I believe MEDIAINFO doesn't scan the entire file, only a sampling, so my guess is that it missed those.

I'll can add a hidden option to disable VFR scanning. But I wouldn't recommend leaving it set -- because it would be unpredictable what would happen when you run into a true VFR source, and I'm seeing more and more of those lately.

[MrVideo]

Originally Posted by jdobbs

The one you marked as "good" was 170904. I looked at it -- and it isn't "good".

I think you mean 170924. I marked it as "good" meaning that it was captured using the good IRD. Obviously there is no "good" IRD. It was just plain timing.

The 170905 file wasn't seen by MEDIAINFO as variable, so with default settings it would probably import ok because BD-RB would only scan when MEDIAINFO finds variable. But if I force a scan it's timecodes are pretty much like the others -- except there are only a couple examples of identical times for the fields. I believe MEDIAINFO doesn't scan the entire file, only a sampling, so my guess is that it missed those.

I seem to be missing the value in the mediainfo report that indicates that the file is VFR. When I look at both files, they are both reported as 29.97 fps. What am I missing?

I'll can add a hidden option to disable VFR scanning. But I wouldn't recommend leaving it set -- because it would be unpredictable what would happen when you run into a true VFR source, and I'm seeing more and more of those lately.

Thanks. I understand. I just need it for these feeds from CBS.

[gonca]

Originally Posted by jdobbs

But... to be clear, if they are muxed separately they don't comply with the Blu-Ray standard and won't be imported into the BD structure.

Agreed, but the issue appears to be MKV, either creating or using as a source.
Many valid MKVs contain codecs which are not BD compliant, and the user should be aware of that since BD_RB is primarily about the creation of spec compliant output

Not a BD_RB issue

[Lathe]

Originally Posted by gonca

Agreed, but the issue appears to be MKV, either creating or using as a source.
Many valid MKVs contain codecs which are not BD compliant, and the user should be aware of that since BD_RB is primarily about the creation of spec compliant output

Not a BD_RB issue

Yep... gonca is right!

[Lathe]

Originally Posted by jdobbs

Untrue. You can just leave the audio track intact. Although I personally don't recommend it. It uses way too much space for a difference that no human ear can detect... but, hey, if wasting space for no purpose rocks your boat -- more power to you.

You will have to excuse JD... He is a great guy and a frigg'n BRILLIANT designer, but, sadly, do to firing guns and heavy artillery for many years now (he was in a gang and then in special forces) his hearing just isn't quite what it used to be...

[gonca]

Originally Posted by Lathe

You will have to excuse JD... He is a great guy and a frigg'n BRILLIANT designer, but, sadly, do to firing guns and heavy artillery for many years now (he was in a gang and then in special forces) his hearing just isn't quite what it used to be...

Just don't let him work on a roof, he will break his neck.

Yep...  gonca is right!

Remember that

[Lathe]

Originally Posted by gonca

Just don't let him work on a roof, he will break his neck.

[MrVideo]

Originally Posted by Lathe

[...]do to firing guns[...]

Maybe it was due to firing guns.

[Lathe]

Originally Posted by MrVideo

Maybe it was due to firing guns.

DOHHHHH! one F#%'n mistake, and guess WHO finds it...? GRRRRRRRRRRRRRRRRRR!

[MrVideo]

Would you expect anything less? Then again, you probably insert those just to see if I will find them.