tsMuxeR Blu-ray output and Fixclpi

[jdobbs]

Most of the time I'm getting 2 error messages


D:\multiAVCHD>"c:Users\Dean Kasabow\Desktop\multiAVCHD\tools\fixclpi.exe" AVCHD_testpip

FixCLPI v2.30, jdobbs softworks

Fixing CLPI files in directory tree.
- AVCHD_testpip\BDMV\BACKUP\CLIPINF\00000.clpi ep tables corrected.
- AVCHD_testpip\BDMV\BACKUP\CLIPINF\00001.clpi ok.
Target does not appear to be a CLPI file.
- AVCHD_testpip\BDMV\BACKUP\CLIPINF\01300.clpi ok.

After 01300.clpi I get runtime error 5 "File already open" and I get the same error with all files with names above 01000.clpi. (my menu files) and the files are not open in any other application.Interesting. I've done a lot of testing and haven't had issues. I also ran it against CLPI files that have high numbers (e.g. "20001.CLPI"). As for the "Target does not appear to be a CLPI file." -- it is designed specifically for TSMUXER output, that means the header on the file has to be "HDMV0200" -- it's possible that some AVCHD files may have "HDMV0100" (if something has patched it after TSMUXER). I guess I could go back and change it so it accepts both.

I'll check and make sure the files are closed... it's possible I may have left something open when I get an error.

[Edit] Yep, just checked. I don't close the file before exiting the module when I give the "Target does not appear to be a CLPI file." error. Bad programming... I'll fix it and make a new release. I'll also allow "HDMV0100" as the header.

[deank]

Thanks. And - yes - those with 'not valid' error are with 0100 header. :)

[MB2]

OK, my mate has had a chance to test some discs i sent him...

2 of which were done on earlier versions of BDRB but run with FIXCLPI - They dont work, have sound tho.

I did also Predator 2 with the new version of BDRB 0.20.1 - and that doesnt work :-(

[jdobbs]

OK, my mate has had a chance to test some discs i sent him...

2 of which were done on earlier versions of BDRB but run with FIXCLPI - They dont work, have sound tho.

I did also Predator 2 with the new version of BDRB 0.20.1 - and that doesnt work :-( Use the new version that will be posted in a few minutes. Can't make any recommendations on the BDRB 0.20.1 issue. I have reports from those with Panasonic that say it works ok now. Try the new version that will be posted in a few minutes.

[rack04]

Use the new version that will be posted in a few minutes. Can't make any recommendations on the BDRB 0.20.1 issue. I have reports from those with Panasonic that say it works ok now. Try the new version that will be posted in a few minutes.

I can confirm. My BD35 plays flawlessly now.

[jdobbs]

I've compiled a new version of FixCLPI.EXE (v2.31). You can download it from this link (http://www.jdobbs.net/freeware/fixclpi_v231.zip). Updates to this one:

- Added code to recognize issues in previously "fixed"
CLPI files, and correct.
- Corrected an error in that could result in "file
already open" error in directory mode.
- Added "HDMV0100" as an acceptable header for the
identification of valid CLPI files.

[MB2]

His player is the BD55. Sorry, should have said.

Will try the new fixclpi

[MB2]

Just as a side note, what version of TSremux should i be using? Have been using 1.8.8b

[jdobbs]

I have been using 1.8.4 because it is that last "public" release. But I think 1.8.8 is ok. I've had issues reported with BDRB with the newer ones (1.8.18 & 1.8.19), causing me to move back to 1.8.4 in my release -- but can't confirm them myself.

[MB2]

So in theory,

Having stripped Predator 2 using TSremux 1.8.8b, then doing rebuilder in v.0.20.1 should this disc have worked (in the BD55) without the need for fixclpi?

[jdobbs]

If you preprocessed the original with TSMUXER before running BDRB than I can't guarantee anything. BD-RB is meant to be run against original sources (excluding AnyDVD processing, since that has been thoroughly tested).

I can say that I've seen problems with TSMUXER processing sources that were previously run through TSMUXER. So at best I can say its unpredictable.

[MB2]

Is there anything youd suggest i do to the source created by TSremux before i start with BDRB... I must have well over 120 on HD's (all movie only using TSremux). Would doing the FIXCLPI before help then running BDRB?

[jdobbs]

I wish I could help, but I'm not even sure what the issue is. Here's an example: If I take a multipart video that has been encoded, mux it into several M2TS files, and then try to use those as a source for a multipart mux with a single audio stream, it will be way out of sync. If I do the exact same mux, but use the exact same .264 files that were used to create the M2TSs, it will work correctly with perfect sync. The only difference is the fact that in the first method I am remuxing from previously TSMUXER created M2TS files. I've had other issues as well. In fact, I've tried, in the past, to demux to elementary streams so I can start over again from scratch and even that didn't even seem to work.

Sorry. But all I can say is that TSMUXER seems to be fine as long as it isn't working with a source it created itself. Either that, or I've just run into some uncommon strangeness. The example I used above, though, forced me to rewrite part of BD-RB because it was happening to others too.

If those HDs are in blu-ray formant you use FixCLPI on them, they should be corrected and be fine. I just wouldn't run them through BD-RB... since it is going to use TSMUXER again.

Just so you know, it is my intention to eventually build my own muxer for BD-RB, and at that point maybe this will become a non-issue.

[setarip_old]

@jdobbsIf you preprocessed the original with TSMUXER before running BDRB than I can't guarantee anything. BD-RB is meant to be run against original sources (excluding AnyDVD processing, since that has been thoroughly tested).

I have been using "MakeMKV" (to decrypt and convert to MKV) instead of "AnyDVD HD" and then "TSMuxer" (To create a proper BluRay movie-only "package") for all of my BluRay ripping. I have then successfully, without incident) used BD-RB to compress several of them to fit on DVD-9s (Notwithstanding the difficulty I recently encountered regarding the small clip from "The Santa Clause 3")...

[mrr19121970]

I got a Run-time error '6': Overflow


I still get this error with V0.231.

Here's the offending file:

http://www.megaupload.com/?d=N8YJAOBT

[jdobbs]

I still get this error with V0.231.

Here's the offending file:

http://www.megaupload.com/?d=N8YJAOBTThanks for providing the file. I ran against it and got the same error. The PTS value was wildly high and caused an overflow when I used the upper bits in a calculation. I'll have to figure out a way to fix it -- because even though the value is exceptionally unusual, it is completly legal.

[~bT~]

Try this...

fixCLPI GUI v0.02b.exe (http://clownbd.techxt.com/Downloads/fixCLPI GUI v0.02b.exe)

Includes v2.31
:thanks: mr

[shon3i]

jdobbs tsMuxeR_1.8.20(b) is out, can you check please is there same problem?

[jdobbs]

I just tried v1.8.20(b) The packet count variable did not need correction in the blu-ray output I tested for this version, but the COARSE/FINE tables still needed to be corrected.

[laserfan]

I just muxed something with 1.8.20, my "thing" being accurate chapter marks (seeks, landings, whatever you want to call skipping-ahead accurately by chapter) and the resulting mux had a few issues. Applying fixclpi 2.31 made those issues go away, so I'm glad to find out that fixclpi still works despite that it wasn't developed with 1.8.20 output.

I will say tho also that the problems were with only a few chapter marks out of 38. And also, I muxed another program the other day where fixclpi was not needed at all i.e. the chapter landings worked fine (I applied fixclpi anyway).

So I don't know what's up with tsmuxer in that sometimes it's good and sometimes it's not--I might have guessed that if the 00001.clpi file had problems, you'd always be able to see them on playback but apparently not.

[jdobbs]

Some very small encodes may not need it... but pretty much every one I've tested does...

It's a really easy fix... I hope they get to it soon.

[psme]

Thanks for the great effort. But the fixCLPI GUI does not work with 8.3 filename. Took me a while to notice and I need to change back all those old encoding in PS3 format, back to blu-ray file naming to apply the new fix...

regards,

Li On

[jdobbs]

I don't think I understand what you mean?

[mrr19121970]

I guess he means you're looking for *.CLPI, whereas he has *.CPI after running AVCHMe.

[jdobbs]

Hmm... but is that BD compatible? It sure doesn't sound like it.

[deank]

Right... BD is .clpi/.mpls/.m2ts/.bdmv (indx/mobj/hdmv 0200), AVCHD is .cpi/.mpl/.mts/.bdm (indx/mobj/hdmv 0100).

[mrr19121970]

@ JDobbs.

Can you please look at these 2 files:

Original (http://clownbd.techxt.com/Downloads/While She Was Out/Original/00000.clpi)

tsMuxeR-fixCLPI (http://clownbd.techxt.com/Downloads/While She Was Out/tsMuxeR-fixCLPI/00001.clpi)

In the original you can jump chapters & fast forward etc. However in tsMuxeR (every version) jumping chapter or ffwding just takes you back right to the start.

Any ides ?

Thanks.

[jdobbs]

Where did these come from? The first one is a legitimate CLPI. The second one looks trashed and only has 7 COARSE and 7 FINE entries. It wasn't created by FixCLPI -- because I just ran FixCLPI against the first one and it found nothing to change (and left it intact). Also, the second one looks like it has nothing in common with the first one (completely different SPN and PTS values)

[nwg]

Is the m2ts packet size to match the clipinf size?

[jdobbs]

Is the m2ts packet size to match the clipinf size? Was this directed at me? If so, I don't think I understand the question.

[nwg]

Was this directed at me? If so, I don't think I understand the question.

It was a general question but I hoped you would know.

After fixclpi the clipinf and m2ts packet size are different. The prog by mrr19121970 makes them the same using his clipinf editor.

so are they supposed to be the same or different as your fixclpi prog and his does them differently.

http://www.apah20.dsl.pipex.com/pics/clipinf.jpg

[deank]

jdobbs' fixclpi fixes different things, not m2ts packet information stored in clpi files.

[jdobbs]

Actually it does fix the packet count... if you use a folder as the input parameter and it finds a correspoinding "..\STREAM\" entry in the path. But in the CLPI files posted there is no way of knowing if they match, because I don't have the size of the M2TS to compare.

[nwg]

jdobbs' fixclpi fixes different things, not m2ts packet information stored in clpi files.

But they interfere with each other and change each other. If I use that clipeditor to fix the length so they both are the same as what m2ts is then re-run fixclpi, the clipinf packet size is back to what is was before. Just want to know if both programs are needed.

I using the fixclpi gui 0.02 and using the Blu Ray folder as input.

[mrr19121970]

Where did these come from? The first one is a legitimate CLPI. The second one looks trashed and only has 7 COARSE and 7 FINE entries. It wasn't created by FixCLPI -- because I just ran FixCLPI against the first one and it found nothing to change (and left it intact). Also, the second one looks like it has nothing in common with the first one (completely different SPN and PTS values)

The 1st one is from the original disc, and the 2nd one from tsMuxer (1.8.22) and fixCLPI (2.31)

FixCLPI v2.31, jdobbs softworks

Fixing CLPI files in directory tree.
- D:\DEMUX\While She Was Out\While She Was Out\BDMV\BACKUP\CLIPINF\00001.clpi packet count fixed
- D:\DEMUX\While She Was Out\While She Was Out\BDMV\BACKUP\CLIPINF\00001.clpi ok.
- D:\DEMUX\While She Was Out\While She Was Out\BDMV\CLIPINF\00001.clpi packet count fixed
- D:\DEMUX\While She Was Out\While She Was Out\BDMV\CLIPINF\00001.clpi ok.


I'll run it through tsMuxeR again (without fixCLPI)

[jdobbs]

If you are using one of the newer versions of TSMUXER, the value is correct and shouldn't be changed (at least on single M2TS muxes).

[jdobbs]

The 1st one is from the original disc, and the 2nd one from tsMuxer (1.8.22) and fixCLPI (2.31)

FixCLPI v2.31, jdobbs softworks

Fixing CLPI files in directory tree.
- D:\DEMUX\While She Was Out\While She Was Out\BDMV\BACKUP\CLIPINF\00001.clpi packet count fixed
- D:\DEMUX\While She Was Out\While She Was Out\BDMV\BACKUP\CLIPINF\00001.clpi ok.
- D:\DEMUX\While She Was Out\While She Was Out\BDMV\CLIPINF\00001.clpi packet count fixed
- D:\DEMUX\While She Was Out\While She Was Out\BDMV\CLIPINF\00001.clpi ok.


I'll run it through tsMuxeR again (without fixCLPI) Well the tables won't necessarily match because the SPN values will almost undoubtedly change, and since TSMUXER resets the PTS baseline, the PTS values won't match either. Let's see what the CLPI looks like just from TSMUXER (no FixCLPI) -- as that is more likely to be the source of the problem. FixCLPI just uses the values in the table and corrects the missing COARSE entries related to SPN roll-over.

If the problem is thought to be FixCLPI, I would need to see the same CLPI before and after FixCLPI (not the original).

[nwg]

If you are using one of the newer versions of TSMUXER, the value is correct and shouldn't be changed (at least on single M2TS muxes).

If that is to me then I used 0.21 of TsMuxer. Thank you.

[jdobbs]

I just went back and did some testing. It appears that if you do a simple blu-ray mux, the packet count is correct (at least on the three I tried), but if you use splitting, all the CLPI packet count values are still wrong even with the latest versions.

[mrr19121970]

I guess that tsMuxeR has FBR the CLPI file. Here is the original created by v1.8.22:

tsMuxeR only (http://clownbd.techxt.com/Downloads/While She Was Out/tsMuxeR/00001.clpi)

[jdobbs]

Yep. This one looks goofy also.

This is why I keep using v1.8.4 for my BD-RB muxing -- because, even though I know it isn't perfect, I know what doesn't work right consistently (and I can fix it), and I don't have to worry about new issues that are introduced.

[MB2]

@jdobbs

Which version of TSremux is inside BDRB?

[jdobbs]

v1.8.4. The last one that was publicly released by smlabs.

[mrr19121970]

tsMuxeR v1.8.4 didn't do much better:

V1.8.4 (http://clownbd.techxt.com/Downloads/While She Was Out/tsMuxeR_V184/00001.clpi)

[jdobbs]

Is there something odd about the source, or do you have the encode set to some incredibly long GOP length (keyint) or structure? That could affect the spacing of the PTS values used for the EP tables. Also, if you set the chapter values in TSMUXER to something odd, you might get something like this.

[mrr19121970]

No the source is an original BD demuxed with eac3to (While She Was Out), the video stream is VC1 1080i/50 which tsMuxeR GUI simply refuses to accept. The CLI accepts it, and detects it correctly:


D:\DEMUX\While She Was Out>"E:\TVIX\tsMuxeR\tsMuxeR_1.8.4(b)\tsMuxeR.exe" "D:\DE
MUX\While She Was Out\While She Was Out.meta" "D:\DEMUX\While She Was Out\While
She Was Out_184"
SmartLabs tsMuxeR. Version 1.8.4(b) http://www.smlabs.net
VC-1 muxing fps not set. Get fps from stream.
Decoding VC-1 stream (track 1): Profile: Advanced@3 Resolution: 1920:1080i Frame rate: 25
Decoding DTS stream (track 2): Bitrate: 1536Kbps Sample Rate: 48KHz Channels:

[laserfan]

Gosh another version 1.8.23 today...obviously with all the recent new releases there is alot of work being done on tsMuxeR at present and we can only hope I guess that Roman or whoever is working on it is paying some attention to these Doom9 threads!!??!! One might also assume they are seeing some very large number of hits on their ftp site and are aware of the outside scrutiny!

[laserfan]

I tried tsMuxeR 1.8.23 (latest as of the time of this post!) and it had one or two messed-up chapter marks/time codes and applied fixclpi 2.31 and it fixed the problems. So tsMuxeR is still broke but thankfully fixclpi still works:

C:\>fixclpi e:\video.bluray
FixCLPI v2.31, jdobbs softworks

Fixing CLPI files in directory tree.
- e:\video.bluray\BDMV\BACKUP\CLIPINF\00001.clpi packet count fixed
- e:\video.bluray\BDMV\BACKUP\CLIPINF\00001.clpi corrected.
- e:\video.bluray\BDMV\CLIPINF\00001.clpi packet count fixed
- e:\video.bluray\BDMV\CLIPINF\00001.clpi corrected.

[Visor]

I made a lot of streams a while back that had long GOPs -- I can confirm that when you use them you will get video delays at chapter points. For Blu-ray compatibility you need to make sure the GOPs are no more than one second long. In BD-RB I set them to 24 as the default. If you stick to that rule the chapters should sync up immediately.
Are you referring to --keyint 24?
Yes. And, of course, you have to also use "--min-keyint 1" along with it.

So that's it! I've been pulling my hair out all week trying to figure out why my Sony BDP-S350 was having a hard time fast-forwarding, rewinding, and chapter-jumping certain downloaded AVCHDs/BD9s. I would've assumed it was just a limitation of the player, but some other discs scanning just fine. I tried using FixClpi, remuxing with TSRemux, using h264info to write PPS... nothing worked to improve scanning or chapter response. Finally, I stumbled onto a couple of very interesting links in addition to this one:

http://forum.handbrake.fr/viewtopic.php?f=14&t=6346
http://forum.doom9.org/showthread.php?t=136327&highlight=keyint

I downloaded MediaInfo and compared slow AVCHDs vs. fast ones, and guess what? The keyints were vastly different. A fast disc would have a typical keyint of 24 and a minimum of 2, whereas a slow disc would have numbers at least 10 times that size (eg. 240/24). According to the above second link, MeGUI's "SA-Blu-ray" profile defaults to low keyint numbers, which in turn leads towards a smoother scanning & chapter jumping experience. I wish people would use that profile more often. I know it could potentially result in a small sacrifice in video quality, but I would prefer to have the same smooth scanning capabilities as an actual Blu-ray Disc.

Thanks guys! I can sleep again. :p

Visor

[G_M_C]

It's actually very simple;
GOP length in Bluray specifications is named as 1 second if you use max bitrate > 15 Mbps. GOP length is 2 sec for max bitrate < 15 Mbps. Out of this it follows that key-int is always equal to the framerate (rounded of to the nearest whole number) when bitrate is > 15 Mbps, and 2 x framerate for streams with < 15 Mbps.

In the same spec is determined that minimum key-int is always set to 1.

See also this usefull post, where i tried to centralize al these sort of questions; But sadly the thread did not "take off" http://forum.doom9.org/showthread.php?t=141376