BD Rebuilder Beta - Bug Reports Only

[AmigaFuture]

That's kinda' correct, but not completely. Yes, SRTs are converted to SUP (so they are BD compliant) during import into the PSEUDO-BD folder. But... the original SRT is retained as well (in the PSEUDO folder). Then when you run a ALTERNATE job (to make an MKV) against the PSEUDO-BD folder, BD-RB recognizes that an SRT exists and adds it to the MKV. MKV players like SRT subtitles, but most won't recognize PGS streams (there are probably some that do, but I'm not familiar with them).

I was just going through the code and noticed something... I already added the option to keep the SUPs some time ago apparently (long enough [2012] that I didn't remember it). Look at this option in HIDDENOPTS.TXT:

MKV_MUXSUPS=n n = 0/1 - If set to "1" (default), ALTERNATE/MKV output will include selected .SUP subtitles

It started defaulting to "1" in 2013, so by default the selected SUPs should be included in the MKV file... :o

I think I did it so that an MKV file created with BD-RB could later be imported to BD without losing the original subtitles.

Right, all this agree with. Hmm.. I think I wasn't clear enough. I shall attempt to break it a bit more because I'm think I'm being misunderstood.

SUP files are being brought into MKVs fine. I remember the creation of MKV_MUXSUPS=n and that it became 1 as default. I was very happy about that. I do recall. Hehe. What my aim has been is focus on SRT files for MKV and MP4.

SRTs are being converted and imported into MKV fine. But since MP4 doesn't allow for them (yet), they're being rejected by MP4Box, makes sense. I've also been testing that outside of BD-RB because I'd forgotten. Like you, it's been some time. I don't use MP4 container often.

When my T.V. when kaput...and I bought another, I noticed the first few MKV's SRT's were not being read or noticed within the container. Checked documents and there isn't any, anymore for most T.V.s now. Argh! Which is why I asked the question here. So, I did the next step to be sure T.V.'s USB "Movie" feature is working correctly. I extracted SRT which was below the PGS streams. I didn't realize or notice or consider that THAT is the challenge as to why SRTs aren't being read. So, extracted and renamed SRT to match "Movie.srt"... Voila!! "Okay, why Not from the container?"

I still didn't notice, or consider the PGS's are above the SRT in MKVs.

I started checking with MP4 container, thinking there's a preference by LG in their newer WebOS features. That's when I noticed BD-RB, or some process isn't injecting the SRT into MKV or MP4 _when_ importing an MKV.

Still, I hadn't reflected about PGS's in MKV at this point. So, I started messing with BD-RB and MKVmerge's GUI some. As well as YAMB.

Dead-end...not going anywhere. "Is it Inside the MKV??" I started checking that. With a test of using MKV's GUI I shifted the SRT above the multiple PGS sreams. Star Wars for the example, and noticed the T.V. from USB now allows me to select from multiple SRT streams. Wooohoo!! HAHA!

In the meantime, I also learned that BD-RB is injecting SRT when it's created from Tesseract...from BD. But not when importing an MKV to Alternate MKV to remove PGS, as I was doing that to only test stuff. So, if you download an SRT from somewhere and add it using MKVMERGE GUI, and later import into BD-RB the SRT is being converted, not left alone and injected at MKV creation. That's what I was hoping for.

So, I learned multiple things buying a new T.V., and I hope this helps to clarify what I thought might be a bug AND the reason for my request. :-D I was a bit confused annnnnd.....slightly frustrated for a little while. Not towards you, but why SRT wasn't working. Never tested, since 2012, that the order of SRTs would matter to anything. Ha!

Now you know why I requested the ability to inject SRTs into MKV (without converting to SUP; by way of Hidden Option) and MP4 (which seems to happen automatically by MP4Box but into a different format instead of leaving it SRT)... I thought MP4 was already being done, but I...admit I didn't recall.

:D Hope that helps, JD.

P.S. If anyone is interested, the LG Smart TV with WebOS plays MKV containers fantastic. I haven't noticed ANY glitches. Using lossless video and DTS or rerendered DTS to AC3 works great also. Only thing, doesn't read PGS or chapters but has very functional skip/FF.

Another donation coming soon, as I'm reminded just how cool and helpful BD-RB is.

[MrVideo]

Not true. It can't leave it alone, because it isn't compliant (it doesn't have a core). There are lots and lots of dependencies based on that -- and I'd have to rewrite a significant amount of code to cover all the bases. I'm not willing to do that just so someone can keep a non-compliant EAC3 rather than a compliant AC3 stream.
As I said, at that stage of the game, who cares if it is compliant or not. Non-compliant video is allowed to pass. When the Backup stage is done, then it can convert to AC3. Isn't it simple to call the DD+ to AC3 subroutine from the Backup stage and just not call it from the initial stage?

That said, I'm not the only one. I'm sure the list will grow.

Any update on the VFR issue? Mediainfo reports that it isn't VFR, yet VFR still happens.

[MrVideo]

Why am I so against recoding DD+ to AC3? Dolby Digital was not designed/meant to be recoded. Minute errors and artifacts are introduced when doing so. The ABC network used to delivery AC3 @ 640k to it affiliates, but stopped doing so. I suspect because of the recoding issue. Instead they now deliver MP2 streams that are now recoded to AC3 5.1. Is that any better? I really do not know. NBC uses the same delivery method. Unfortunately the PBS network satellite delivery is AC3. But, since I capture that feed, there is no recoding on my part. The CW and CBS use Dolby-E, which was designed for recoding at the broadcast end for air. I too recode that to AC3 5.1 @ 640k.

Unless the DD+ is left alone in the first stage, for those of us who need it, I will be forced to recode to DTS. Why DTS? I can recode at a higher bitrate, which will hopefully reduce any minute errors and artifacts during the recoding process. Do I have any proof? Nope. But it has to be better than recoding EAC3 to AC3.

[MrVideo]

BDRB is getting a false positive. I do not know how, since mediainfo seems to be reporting that the video is CFR, which it really is.

I had an idea as to why it is happening. I try and capture the sat feed with the Tandberg IRD via ASI. But sometimes the signal will not lock and I have to use the consumer TeVii USB receiver. Both receivers are used to capture the satellite transport streams as TS files. But, for some reason, the TS file captured by the TeVii trips up BDRB into thinking that the video is VFR. Why it trips up BDRB is unknown.

I need a way to override the VFR scanning and related VFR-CFR conversion. As previously reported that process screws up and produces 59.94 video instead of leaving it at 29.97.

To help find out why things are going wrong, I can supply a 100MB sample to be analyzed.

Thanks.

[MrVideo]

As JD mentions above, 'tweak' is a simple but excellent Avisynth filter to use.
He also said the it can be found under SETUP. But, when I do Settings->Setup, I find no such area in which to add AVISynth filters.

I want to try adding SelectEvery(2,0) in order to get rid of the double frames caused by the improper operation of VFR->CFR (see above posts regarding this issue).

I need to try something until this issue is resolved.

Thanks.

[Lathe]

He also said the it can be found under SETUP. But, when I do Settings->Setup, I find no such area in which to add AVISynth filters.

I want to try adding SelectEvery(2,0) in order to get rid of the double frames caused by the improper operation of VFR->CFR (see above posts regarding this issue).

I need to try something until this issue is resolved.

Thanks.

Heh, okay... there is NO possible way a smart guy like you could possibly have missed this, but, just in case... :)

http://lathe-of-heaven.com/AVS01.gif

http://lathe-of-heaven.com/AVS02.gif

[varekai]

Heh, okay... there is NO possible way a smart guy like you could possibly have missed this, but, just in case... :)
That's funny... :D

[MrVideo]

Heh, okay... there is NO possible way a smart guy like you could possibly have missed this, but, just in case... :)
I was looking for a box in which to enter the text. I wasn't expecting a checkbox having to be ticked first. Silly me for thinking that. Oh well.

Thanks.

[AmigaFuture]

Sometimes the most simple solution is the best..even when we see it and we recognize it's a little different than we thought; but still don't check it because it's not what we thought. I remember the first time I wanted to enter in something also and notice the option to check. So I did. ;-)

Lathe, I will admit, too, that was funny. But the Ugly Windows 10 would have been what fooled me... Not. :-)

[SquallMX]

jdobbs is going to need a lot more info than that.

When blanking titles without an audio track (mostly annoying legal warnings) BDRebuilder replace them with a black screen of 0.480 secs with an audio track (audio id 1100). This causes a error in the internal logic of most Warner titles related to predefined audio tracks for languages other than English, that results in the main movie playing using the main audio track (audio id 1100) instead of the proper dub track (audio id 1101/1102/1103...).

[Lathe]

I was looking for a box in which to enter the text. I wasn't expecting a checkbox having to be ticked first. Silly me for thinking that. Oh well.

Thanks.

Sure thing mate. The reason I knew about it is that I've actually used it before, so that's why... :) Not being an AVS expert, I don't know if there are any limits to the script you can use, but for the basic stuff I do (tweak, etc.) it seems to work okay.

[MrVideo]

Well, that didn't work. The frame rate is still an incorrect 59.94fps. I'm sorry, but this needs to be fixed. Relying on MediaInfo, which is getting a false positive, is causing BDRB to do things it isn't supposed to. There needs to be an override option to force no VFR.

[jdobbs]

Well, that didn't work. The frame rate is still an incorrect 59.94fps. I'm sorry, but this needs to be fixed. Relying on MediaInfo, which is getting a false positive, is causing BDRB to do things it isn't supposed to. There needs to be an override option to force no VFR.Try setting "IMPORT_VFR_SCAN=1" If set, BD-RB will collect all the timecodes and check for VFR itself. I'll have to check whether it will override MEDIAINFO.

Interestingly, I rarely have ever seen a false positive on VFR.

[TatanScorp]

When I import a MKV file into BDrebuilder it reads "Importing MKV"
then "Collecting audio/video streams from source" After building a pseodo Bd structure Bd rebuilder shows only a vid and subtitle track but no audio. It's a Atmos tract but at least it should show 7.1 tract. How do I get the audio?

Thanks

[MrVideo]

Try setting "IMPORT_VFR_SCAN=1" If set, BD-RB will collect all the timecodes and check for VFR itself. I'll have to check whether it will override MEDIAINFO.
It still does VFR to CFR, doubling the frame rate.
Interestingly, I rarely have ever seen a false positive on VFR.
I have a 100MB test file that I can upload for you to use as a test.

[jdobbs]

It still does VFR to CFR, doubling the frame rate.

I have a 100MB test file that I can upload for you to use as a test.I'd appreciate it if I can get the file.

[jdobbs]

When I import a MKV file into BDrebuilder it reads "Importing MKV"
then "Collecting audio/video streams from source" After building a pseodo Bd structure Bd rebuilder shows only a vid and subtitle track but no audio. It's a Atmos tract but at least it should show 7.1 tract. How do I get the audio?

ThanksI don't think I've ever tried importing an Atmos track. But... I believe it isn't a legal audio track for blu-ray unless it is inside a Dolby TrueHD wrapper. I can tell you this -- in the version of the BD standard that I have (a few years old) there isn't a single reference to the term "Atmos". My guess is that TSMUXER rejects it -- but, as I said, I've never actually tried.

[MrVideo]

But... I believe it isn't a legal audio track for blu-ray unless it is inside a Dolby TrueHD wrapper.
Or Dolby Digital Plus.

[jdobbs]

The test file is here (http://vidiot.com/CW-H264-test-170923-422.ts).
Once you have it, I will delete it. If need be, I can get you one that works.Got it.

[TatanScorp]

I don't think I've ever tried importing an Atmos track. But... I believe it isn't a legal audio track for blu-ray unless it is inside a Dolby TrueHD wrapper. I can tell you this -- in the version of the BD standard that I have (a few years old) there isn't a single reference to the term "Atmos". My guess is that TSMUXER rejects it -- but, as I said, I've never actually tried.


I don't get it. I'm getting the Atmos tract off of a Blu-ray disk, and yes TSmuxer doesn't recognize the track. Isn't the Atmos just meta data plus the Dolby True HD 7.1? The two Blu-rays I have with Atmos are John Wick and John Wick 2.

[jdobbs]

I don't get it. I'm getting the Atmos tract off of a Blu-ray disk, and yes TSmuxer doesn't recognize the track. Isn't the Atmos just meta data plus the Dolby True HD 7.1? The two Blu-rays I have with Atmos are John Wick and John Wick 2.Kinda', yes, but... there's an independent track contained in it. The problem is that on a Blu-Ray disc it is packaged together with a normal Dolby track (as one stream) so it is treated as an extension to it. When an MKV is created they are separated. Unless they are recombined it is not a legal track. That makes sense since Atmos isn't officially a part of the standard. The same concept applies to other audio types as well. Support for Atmos is optional but not required -- so there has to be a fallback audio stream for players that don't support it.

The bottom line is that the audio track you are trying to mux isn't a legal Blu-Ray audio track -- so, as would be expected, it is rejected.

[MrVideo]

When an MKV is created they are separated. Unless they are recombined it is not a legal track.
I was curious about this, so I went looking for info and found a site that has a boatload of Dolby trailers, several of which have ATMOS.

I used mkvmerge to look at the content of one of them and there was just one video stream and one audio stream (TrueHD Atmos).

It looks like the author of tsmuxer is going to have to update his program to accept TrueHD-Atmos audio streams. Until then BDRB is going to end up without the audio stream because tsmuxer doesn't like it.

[MrVideo]

Got it.
OK, deleted. Let me know if you want a sample where BDRB doesn't think it is VFR.

[jdobbs]

I was curious about this, so I went looking for info and found a site that has a boatload of Dolby trailers, several of which have ATMOS.

I used mkvmerge to look at the content of one of them and there was just one video stream and one audio stream (TrueHD Atmos).

It looks like the author of tsmuxer is going to have to update his program to accept TrueHD-Atmos audio streams. Until then BDRB is going to end up without the audio stream because tsmuxer doesn't like it.If it is TrueHD-Atmos it will likely accept it. My guess would be the ones that fail would be Atmos only...

[jdobbs]

OK, deleted. Let me know if you want a sample where BDRB doesn't think it is VFR.The timecodes indicate VFR since there isn't consistent separation. Here is a short partial look at some display timecodes (in ms):
352
418
452
485
518
552
585
619
635
652
669
685
685
702
702
719
719
735
735
752
752
769
769
785
785
802
819
835
852
869
886
902
919
936
952
969
986
1002
1019
1036
1052
1069
1086
1102
1119
1136
1152
1169
1186
1202
1219
1236
1253
1269
1286
1303
1319
1336
1353
1369
1386
1403
1419
1436
1453
1469
1486
1503
1519
1536
1553
1570
1586
1603
1620
1636
1653
1670
1686
1703
1720
1736
1753
1770
1786
1803
1820
1836
1853
1870
1887
1903
1920
1937
1953
1970
1987
2003
2020Just guessing, it looks like some of the frames have two fields with the same display timecode and others (most) have two fields that are temporally separated. I don't think that's normal. With that said, it also looks like BD-RB is mixing up the field timecodes with frame timecodes, causing the framerate speedup.

[Edit] I just checked a couple other interlaced sources. They only include timecodes for frames (not fields) -- so I guess that's why the issue with framerate doubling hasn't occurred before. When BD-RB scans and determines VFR, it has to then use the minimum separation of timecodes to determine the actual underlying frame rate.

Also, I'm pretty sure the non-temporally separated display timecodes on the fields is also why MEDIAINFO is also reporting the rate as "Variable". I'm going to have to write code for special cases when each field includes a timecode to prevent framerate doubling. But that won't necessarily prevent what we saw here with the determination of VFR caused by consecutive identical timecodes... I'll have to give that some more thought.

[Lathe]

I don't get it. I'm getting the Atmos tract off of a Blu-ray disk, and yes TSmuxer doesn't recognize the track. Isn't the Atmos just meta data plus the Dolby True HD 7.1? The two Blu-rays I have with Atmos are John Wick and John Wick 2.

So far TSMuxer has never accepted an MKV file where the the original TrueHD track has been muxed in with it. As JD said, AFAIK, EVERY time you convert or mux a TrueHD track to MKV it always rips out the AC3 core. It is an easy fix though. All you have to do is use EAC3to or with the GUI like I do, UsEac3to, drop in the MKV file, choose the True track, and select as your output THD+AC3. That way, EAC3to puts the AC3 core back into the file (thus now making it 'legal') and the resulting THD+AC3 file WILL now be accepted by TSMuxer. As far as the Atmos stuff, that I'm not sure about...

[MrVideo]

So far TSMuxer has never accepted an MKV file where the the original TrueHD track has been muxed in with it.
But, the tsmuxer author should release a new version where TrueHD audio is accepted, as it is legal Blu-ray audio.

But that is a topic for the tsmuxer thread.

[MrVideo]

Just guessing, it looks like some of the frames have two fields with the same display timecode and others (most) have two fields that are temporally separated.
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 (http://vidiot.com/CW-H264-test-good-170924-422.ts). 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 (http://vidiot.com/CW-H264-promos-170905.ts).

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.

[jdobbs]

But, the tsmuxer author should release a new version where TrueHD audio is accepted, as it is legal Blu-ray audio.

But that is a topic for the tsmuxer thread.No. It is not. Support for TrueHD is optional in a player. That's why the core is required to be muxed with TrueHD.

[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/mkvtoolnix/wiki/TrueHD-and-AC-3

[jdobbs]

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 (http://vidiot.com/CW-H264-test-good-170924-422.ts). 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 (http://vidiot.com/CW-H264-promos-170905.ts).

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]

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]

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/mkvtoolnix/wiki/TrueHD-and-AC-3

Uh... yeah... (cough...) that is what I said several posts ago... http://lathe-of-heaven.com/rolleyes2.gif

[MrVideo]

Uh... yeah... (cough...) that is what I said several posts ago... http://lathe-of-heaven.com/rolleyes2.gif
Not the why.

[Lathe]

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...'

http://lathe-of-heaven.com/rolleyes2.gif

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

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". :rolleyes:

[jdobbs]

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 agoBut... 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]

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]

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]

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]

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... http://lathe-of-heaven.com/yes.gif gonca is right!

[Lathe]

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... http://lathe-of-heaven.com/no.gif

[gonca]

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... http://lathe-of-heaven.com/no.gif

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

Yep... gonca is right!
Remember that

[Lathe]

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


http://lathe-of-heaven.com/this.gif http://lathe-of-heaven.com/yes.gif

[MrVideo]

[...]do to firing guns[...]
Maybe it was due to firing guns. :D

[Lathe]

Maybe it was due to firing guns. :D

DOHHHHH! http://lathe-of-heaven.com/doh.gif one F#%'n mistake, and guess WHO finds it...? GRRRRRRRRRRRRRRRRRR! http://lathe-of-heaven.com/angry.gif

[MrVideo]

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