MuxMan 1.44: VIDEO_TS.IFO Appears Truncated

[Richard1485]

Normally, when I select the VIDEO_TS.IFO of a DVD in a software player, it plays the whole movie; however, when I do this with the output from MuxMan, it plays only up to the end of the first chapter. The chapters I wish to use load successfully, and the whole movie is contained in the VOBs. It sounds like the same problem that was discussed in this thread (http://forum.doom9.org/showthread.php?t=166538).

I would appreciate some help.


MuxMan version 1.4.4
new project database size 400, base 10040018.
new pointer management list size 50.
new clipboard database size 20, base 74c068.
Opened project file X.mxp
Accepted audio X

19:42:36 Begin multiplex VTS01.
Title Segment List
Segment_1 non-seamless
Buffering audio track 1 file X.
Maximum audio duration 449182 fields.
Multiplex delay set to 25257.
Positioned X to 00:00:00:00
Starting scene Segment_1_scn1 at 00:00:00:00
Starting scene Segment_1_scn2 at 00:00:21:00, requested for 00:00:20:25
Starting scene Segment_1_scn3 at 00:01:57:02, requested for 00:01:56:29
Starting scene Segment_1_scn4 at 00:04:15:15, requested for 00:04:15:10
Starting scene Segment_1_scn5 at 00:08:17:15
Starting scene Segment_1_scn6 at 00:10:06:17, requested for 00:10:06:04
Starting scene Segment_1_scn7 at 00:12:48:26, requested for 00:12:48:14
Starting scene Segment_1_scn8 at 00:15:03:17, requested for 00:15:03:04
Starting scene Segment_1_scn9 at 00:16:19:19, requested for 00:16:19:10
Starting scene Segment_1_scn10 at 00:18:19:17, requested for 00:18:19:16
Starting scene Segment_1_scn11 at 00:19:35:27, requested for 00:19:35:14
Starting scene Segment_1_scn12 at 00:21:12:19
Starting scene Segment_1_scn13 at 00:23:47:25
Starting scene Segment_1_scn14 at 00:25:39:04, requested for 00:25:38:20
Starting scene Segment_1_scn15 at 00:29:18:10, requested for 00:29:18:09
Starting scene Segment_1_scn16 at 00:31:18:17, requested for 00:31:18:04
Starting scene Segment_1_scn17 at 00:33:26:27, requested for 00:33:26:14
Starting scene Segment_1_scn18 at 00:35:44:07, requested for 00:35:43:24
Starting scene Segment_1_scn19 at 00:36:40:01, requested for 00:36:39:24
Starting scene Segment_1_scn20 at 00:38:22:15, requested for 00:38:22:05
Starting scene Segment_1_scn21 at 00:40:25:10, requested for 00:40:25:04
Starting scene Segment_1_scn22 at 00:44:08:16, requested for 00:44:08:05
Starting scene Segment_1_scn23 at 00:45:56:14
Starting scene Segment_1_scn24 at 00:50:01:04
Starting scene Segment_1_scn25 at 00:52:04:17, requested for 00:52:04:04
Starting scene Segment_1_scn26 at 00:52:07:16, requested for 00:52:07:15
Starting scene Segment_1_scn27 at 00:53:45:00, requested for 00:53:44:29
Starting scene Segment_1_scn28 at 00:57:05:07, requested for 00:57:04:29
Starting scene Segment_1_scn29 at 00:57:29:29
Starting scene Segment_1_scn30 at 01:00:22:17, requested for 01:00:22:14
Starting scene Segment_1_scn31 at 01:03:12:01, requested for 01:03:11:25
Starting scene Segment_1_scn32 at 01:05:11:21, requested for 01:05:11:14
Starting scene Segment_1_scn33 at 01:07:36:27, requested for 01:07:36:14
Starting scene Segment_1_scn34 at 01:12:48:05, requested for 01:12:47:24
Starting scene Segment_1_scn35 at 01:15:57:05, requested for 01:15:56:29
Starting scene Segment_1_scn36 at 01:17:42:22, requested for 01:17:42:09
Starting scene Segment_1_scn37 at 01:18:49:05, requested for 01:18:48:24
Starting scene Segment_1_scn38 at 01:21:58:24, requested for 01:21:58:14
Starting scene Segment_1_scn39 at 01:24:41:07, requested for 01:24:40:29
Starting scene Segment_1_scn40 at 01:26:46:06, requested for 01:26:45:24
Starting scene Segment_1_scn41 at 01:29:23:14, requested for 01:29:23:00
Starting scene Segment_1_scn42 at 01:33:33:25
Starting scene Segment_1_scn43 at 01:37:23:07, requested for 01:37:23:00
Starting scene Segment_1_scn44 at 01:39:19:25, requested for 01:39:19:24
Starting scene Segment_1_scn45 at 01:40:39:05, requested for 01:40:39:04
Starting scene Segment_1_scn46 at 01:42:45:11, requested for 01:42:44:29
Starting scene Segment_1_scn47 at 01:44:18:16, requested for 01:44:18:15
Starting scene Segment_1_scn48 at 01:45:56:07, requested for 01:45:55:24
Starting scene Segment_1_scn49 at 01:48:10:26, requested for 01:48:10:20
Starting scene Segment_1_scn50 at 01:52:30:10, requested for 01:52:30:09
Starting scene Segment_1_scn51 at 01:54:36:04
Starting scene Segment_1_scn52 at 01:58:07:26, requested for 01:58:07:19
Starting scene Segment_1_scn53 at 02:00:18:22, requested for 02:00:18:10
Starting scene Segment_1_scn54 at 02:04:45:20
SeqEnd at E7E5FAE2.
Bytes remaining in buffer = 0.
Bitrate - avg: 4648338, min: 185293 (lba 2152266), max: 8729403 (lba 642394).
Shortest GOP has 5 fields, longest GOP has 30 fields.
Fields: 454713, VOBU: 14749, Sectors: 2152276.

19:43:42 Begin multiplex VMG.
19:43:42 End multiplex.
Summary of Virtual Memory Management
VM base 10040000, reserved 5c000000, commited 00010000, free 5d68, disposable 0.

handle 1, size a298 (41600 data), owner 80000001, time 0, locks 1 0 0, lcnt 1.
Locked by DBinit.
handle 0, size 5d68 (23888 data), owner 0, time 0, locks 0 0 0, lcnt 0.

[r0lZ]

Please load the DVD in PgcEdit, select the main movie in the right pane, and use the Info -> PGC menu. Post the output here within [ CODE ] marks. I'll try to help...

[Richard1485]

Thanks for your willingness to help. I loaded the DVD into PGCEdit. There are several items visible on the pane on the left, and I'm not sure which to select.

http://i57.tinypic.com/2ptoxtz.png

Moreover, I cannot see a PGC Menu option under the Info tab. If I select VTST 1.1 and go to Info → PGC, this is the result.

VTST 1 , 1 TTN 1 (0:21) Title 1 - Chapters: 1, Programs: 1, Cells: 1

********** pre commands:
********** post commands:
********** cell commands:



Playback time: 00:00:21.00 (at 30 fps)
PG Playback mode: sequential
PUOs: 0 (0x00000000)
NextPGCN: 0
PrevPGCN: 0
GoUpPGCN: 0
PGC Still Time: 0
Audio stream 1 status: 0x00008000 (stream=0)

BOVs Chap. Prog. Cell Type Seam- Ang VOBU Cell Cell Playback End Entry First Last Last VOB Cell
(PTT) Flags less Still Still Cmd. Time Time VOBU ILVU VOBU VOBU ID ID
Joint Time # sector End Start End

? 1 1 1 2 no - no 0 0 00:00:21.00 00:00:21.00 0 0 5103 5242 1 1

[r0lZ]

OK, obviously, there is only one chapter, and its duration is 21 seconds. That's very strange indeed, and I don't know what has caused that problem. I have never encountered it. Try to redo the mux, and double-check if your chapter file is correct before loading it in muxman.

I'm sorry, but I can't help much more.

[Richard1485]

I've tried repeating the mux without success. Moreover, I tried chapter files created in different ways. MuxMan seems to accept only frame numbers.


625
3509
7660
14925
18184
23054
27094
29380
32986
35264
38179
42835
46160
52749
56344
60194
64314
65994
69065
72754
79445
82694
90034
93724
93825
96749
102749
103499
108674
113755
117344
121694
131034
136709
139869
141864
147554
152429
156174
160890
168415
175290
178794
181174
184949
187755
190674
194720
202509
206284
212629
216550
224570

[r0lZ]

Yes, I know. But are you sure that your movie has more than 224570 frames? Muxman doesn't like out of range frame numbers.

[Richard1485]

It does after being pulled down. I took the frame-numbers from the original DVD and used them for the remuxed DVD.

[r0lZ]

OK, then I give up. I don't know why muxman doesn't work as expected. Try to contact mpucoder...

[Richard1485]

Thanks for your time. :D Mpucoder is a a moderator for this sub-forum, so perhaps he will see the thread at some point.

[Sir Didymus]

Hi! My impression is that before the remux of the DVD, you did some reencoding of the video stream without telling your MPEG2 encoder about the placement of I frames at the suitable points (scene change locations).

The frequent discrepancies in the MuxMan log between the chapter locations requests and the actual locations provided by MuxMan in the authoring session tend to suggest that this is the case.

If this discrepancy happens also for the last chapter, then the authoring engine may try to set the last chapter point so close to the end of the stream to be unable to complete properly its work.

If you want to make a simple test, please remove the last entry from the chapter file with a text editor. I guess that you should be able to properly create a DVD with 53 chapters...

This is just a test, of course, since you are looking for a DVD with 54 chapters, not 53... :-)

The proper solution to you issue (again, I guess) is to reencode your video by instructing the MPEG2 encoder to insert I frames at the desired location for the chapter splitting, at the scene changes...

Cheers,
SD

Edit: now that I think about... A similar issue could arise when the last cell of your DVD is just a void cell (a short cell containing just one or more black frames)... Well, let's see first of all what happens once you remove the last entry from your chapter file...

[r0lZ]

I wonder also what happens if the file is muxed without a chapter file at all. If it works, it is certainly possible to add the chapters later with VobBlanker. Anyway, your test is easier and should be tried first.

[Richard1485]

Hi! My impression is that before the remux of the DVD, you did some reencoding of the video stream without telling your MPEG2 encoder about the placement of I frames at the suitable points (scene change locations). The frequent discrepancies in the MuxMan log between the chapter locations requests and the actual locations provided by MuxMan in the authoring session tend to suggest that this is the case.


You are right, but if MuxMan repositioned the chapters to the nearest I-frame, as is suggested by the log, why would the result be problematic? The new times are as near to the original ones as makes no difference.

Deleting the last chapter made no difference, but without chapters the DVD muxes successfully. This suggests that the format of the chapter file might be an issue. Celltimes from PGCDemux and ChapterGrabber produce the same result though, and MuxMan does recognize the chapters because the scenes button in the segment contents tab changes accordingly.

[Sir Didymus]

<<
if MuxMan repositioned the chapters to the nearest I-frame, as is suggested by the log, why would the result be problematic?
>>
It was just a speculation... If the last scene contains a single GOP, missing to hit precisely the last chapter point makes the job of the authoring engine impossible... But this seems different from your scenario, apparently...

<<
without chapters the DVD muxes successfully.
>>
This is a good news... At the minimum, you can add manually the chapters with VobBlanker, one by one, as suggested by r0lZ
...

<<
This suggests that the format of the chapter file might be an issue. Celltimes from PGCDemux and ChapterGrabber produce the same result though, and MuxMan does recognize the chapters because the scenes button in the segment contents tab changes accordingly.
>>
?!? Sorry, what you say sounds odd to me... Initially you say that the format of the chapter file might be an issue. I am convinced it is not. In the MuxMan log the scene change requests are all listed, so the format itself of the chapter file is not an issue. This is out of discussion. What might be an issue is not the syntax, but the semantics... I mean, there are apparently some reasons which prevent the authoring to complete successfully by using 54 and 53 chapters... Maybe it is worth to try with 1 or 2? :-)

[r0lZ]

It does after being pulled down. I took the frame-numbers from the original DVD and used them for the remuxed DVD.IMO, the problem is here. The film after pulldown has not the same number of frames that the original. Therefore the frame numbers of the original chapter files do not match. I suppose it's what causes the error. But obviously muxman has a bug here, as it should at least complete the job (possibly with misplaced chapter points).

[Richard1485]

Initially you say that the format of the chapter file might be an issue...
...This is out of discussion.

I agree with your reasoning. In writing about the format, I was thinking out loud – mentioning a possibility but showing that I did not think it likely. I'm sorry if that didn't come across.

Maybe it is worth to try with 1 or 2? :-)

Yes. I'll try that and see what happens.

The thing is though that the same chapter file works in DVD-Lab Pro, and the chapters are correctly placed, albeit with the same minor difference in timing caused by moving them to the nearest I-frame. (I know you are going to ask why I don't simply use DVD-Lab Pro, and the answer is that there are circumstances in which I wish to have the option of using MuxMan, which is why I am trying to solve the problem, rather than just accepting it.) Moreover, the original DVD is almost completely soft telecined, so although it is logical to think that pulldown might be the cause of the problem, I'm not sure that it is.

EDIT: With one or two chapters, I get the same result. Furthermore, if I delete only the first chapter, the output plays up to the new first chapter (= the old second chapter) and then stops.

[Sir Didymus]

IMO, the problem is here. The film after pulldown has not the same number of frames that the original...

The idea is right, even though there is still something confusing... After applying pulldown (soft or hard) the number of frames becomes higher or equal to the original, so there should be no reason for the original chapter points to provoke issues due to their misplacement, at least in theory...


19:43:42 Begin multiplex VMG.
19:43:42 End multiplex

This is VERY strange. The mux time is too short. Muxman is just starting its job, maybe creating the first chapter, then it stops working!


Opened project file X.mxp

Ha!!! I think your issue is here. You are using a MuxMan project file which is broken for some reasons. I don't know why I didn't notice that before! Maybe you may want to share the content of this X.mpx file, but this is not so relevant, after all. Please in all of your testing, just start every MuxMan session by avoiding to load any previously saved mpx project! Let's just start from scratch, with the plain MuxMan GUI, by loading manually only the video, the audio and the chapter file containing 53 or 2 or just 1 chapter. I hope this should work.

[Richard1485]

^ You are right. It now works. Here is the new log.

MuxMan version 1.4.4
new project database size 400, base 10040018.
new pointer management list size 50.
new clipboard database size 20, base 69c068.
Accepted audio X.ac3
new graphics buffer size 1244160.

11:28:08 Begin multiplex VTS01.
Title Segment List
Segment_1 non-seamless
Buffering audio track 1 file X.ac3.
Maximum audio duration 449182 fields.
Multiplex delay set to 25257.
Positioned X.m2v to 00:00:00:00
Starting scene Segment_1_scn1 at 00:00:00:00
Starting scene Segment_1_scn2 at 00:00:21:00, requested for 00:00:20:25
Starting scene Segment_1_scn3 at 00:01:57:02, requested for 00:01:56:29
Starting scene Segment_1_scn4 at 00:04:15:15, requested for 00:04:15:10
Starting scene Segment_1_scn5 at 00:08:17:15
Starting scene Segment_1_scn6 at 00:10:06:17, requested for 00:10:06:04
Starting scene Segment_1_scn7 at 00:12:48:26, requested for 00:12:48:14
Starting scene Segment_1_scn8 at 00:15:03:17, requested for 00:15:03:04
Starting scene Segment_1_scn9 at 00:16:19:19, requested for 00:16:19:10
Starting scene Segment_1_scn10 at 00:18:19:17, requested for 00:18:19:16
Starting scene Segment_1_scn11 at 00:19:35:27, requested for 00:19:35:14
Starting scene Segment_1_scn12 at 00:21:12:19
Starting scene Segment_1_scn13 at 00:23:47:25
Starting scene Segment_1_scn14 at 00:25:39:04, requested for 00:25:38:20
Starting scene Segment_1_scn15 at 00:29:18:10, requested for 00:29:18:09
Starting scene Segment_1_scn16 at 00:31:18:17, requested for 00:31:18:04
Starting scene Segment_1_scn17 at 00:33:26:27, requested for 00:33:26:14
Starting scene Segment_1_scn18 at 00:35:44:07, requested for 00:35:43:24
Starting scene Segment_1_scn19 at 00:36:40:01, requested for 00:36:39:24
Starting scene Segment_1_scn20 at 00:38:22:15, requested for 00:38:22:05
Starting scene Segment_1_scn21 at 00:40:25:10, requested for 00:40:25:04
Starting scene Segment_1_scn22 at 00:44:08:16, requested for 00:44:08:05
Starting scene Segment_1_scn23 at 00:45:56:14
Starting scene Segment_1_scn24 at 00:50:01:04
Starting scene Segment_1_scn25 at 00:52:04:17, requested for 00:52:04:04
Starting scene Segment_1_scn26 at 00:52:07:16, requested for 00:52:07:15
Starting scene Segment_1_scn27 at 00:53:45:00, requested for 00:53:44:29
Starting scene Segment_1_scn28 at 00:57:05:07, requested for 00:57:04:29
Starting scene Segment_1_scn29 at 00:57:29:29
Starting scene Segment_1_scn30 at 01:00:22:17, requested for 01:00:22:14
Starting scene Segment_1_scn31 at 01:03:12:01, requested for 01:03:11:25
Starting scene Segment_1_scn32 at 01:05:11:21, requested for 01:05:11:14
Starting scene Segment_1_scn33 at 01:07:36:27, requested for 01:07:36:14
Starting scene Segment_1_scn34 at 01:12:48:05, requested for 01:12:47:24
Starting scene Segment_1_scn35 at 01:15:57:05, requested for 01:15:56:29
Starting scene Segment_1_scn36 at 01:17:42:22, requested for 01:17:42:09
Starting scene Segment_1_scn37 at 01:18:49:05, requested for 01:18:48:24
Starting scene Segment_1_scn38 at 01:21:58:24, requested for 01:21:58:14
Starting scene Segment_1_scn39 at 01:24:41:07, requested for 01:24:40:29
Starting scene Segment_1_scn40 at 01:26:46:06, requested for 01:26:45:24
Starting scene Segment_1_scn41 at 01:29:23:14, requested for 01:29:23:00
Starting scene Segment_1_scn42 at 01:33:33:25
Starting scene Segment_1_scn43 at 01:37:23:07, requested for 01:37:23:00
Starting scene Segment_1_scn44 at 01:39:19:25, requested for 01:39:19:24
Starting scene Segment_1_scn45 at 01:40:39:05, requested for 01:40:39:04
Starting scene Segment_1_scn46 at 01:42:45:11, requested for 01:42:44:29
Starting scene Segment_1_scn47 at 01:44:18:16, requested for 01:44:18:15
Starting scene Segment_1_scn48 at 01:45:56:07, requested for 01:45:55:24
Starting scene Segment_1_scn49 at 01:48:10:26, requested for 01:48:10:20
Starting scene Segment_1_scn50 at 01:52:30:10, requested for 01:52:30:09
Starting scene Segment_1_scn51 at 01:54:36:04
Starting scene Segment_1_scn52 at 01:58:07:26, requested for 01:58:07:19
Starting scene Segment_1_scn53 at 02:00:18:22, requested for 02:00:18:10
Starting scene Segment_1_scn54 at 02:04:45:20
SeqEnd at F0603E1A.
Bytes remaining in buffer = 0.
Bitrate - avg: 4800169, min: 185293 (lba 2222567), max: 8729403 (lba 513741).
Shortest GOP has 5 fields, longest GOP has 30 fields.
Fields: 454713, VOBU: 14749, Sectors: 2222577.

11:30:03 Begin multiplex VMG.
11:30:03 End multiplex.

The begin and end times for the mux are still the same though.

One other thing that I noticed is that the frame numbers produced by PGCDemux and ChapterGrabber are slightly different. Here are the first few. PGCDemux is on the left.


625 624
3509 3506
7660 7652
14925 14910
18184 18166
23054 23031


The difference is small, but I wonder which to use in future. ChapterGrabber also included 0, whereas PGCDemux did not.

[r0lZ]

I have always used PGCDemux or PgcEdit to grab the frame numbers and I have never had any problem. I don't know ChapterGrabber.

[Sir Didymus]

The same here: always used (with total confidence) PGCDemux and PgcEdit to grab the frame numbers. No experience with ChapterGrabber.

<<
The begin and end times for the mux are still the same though.
>>
My mistake... Based on my faulty memory... :-)

The timestamps in your original log are all OK; there is no video in the VMG domain in your scenario and all of the mux time is spent on the VTS01...

OK. Bye!

[bigotti5]

Chaptergrabber use drop timecodes, Pgcdemux non drop timecode.

[Richard1485]

OK. Bye!

Bye! I'd like to thank both you and r0lZ for your patience.

Chaptergrabber use drop timecodes, Pgcdemux non drop timecode.

Thanks. That explains the difference. As we are not dealing with black-and-white TV, perhaps it is better to use ChapterGrabber.

[r0lZ]

Drop/non-drop time codes are not at all related to color vs. black and white. I would suggest to use the program that gives the correct number of frames: PgcDemux (or PgcEdit).

[Richard1485]

Drop/non-drop time codes are not at all related to color vs. black and white.

Of course there's no difference nowadays.

I would suggest to use the program that gives the correct number of frames: PgcDemux (or PgcEdit).

I thought that nowadays everything uses drop timecodes, so I don't understand why PGCDemux uses non-drop.

[r0lZ]

Because it's the way the time codes are stored in the IFOs. I can't explain more. Luckily, I live in PAL land, and I have never understood correctly that crazy NTSC frame rate problems.

[Richard1485]

Because it's the way the time codes are stored in the IFOs. I can't explain more.

That's all right. I guess that because no frames are ever really dropped the IFOs have to use non-drop timecodes.

[Sir Didymus]

@Richard1485
Well, PgcDemux & PgcEdit & MuxMan, are all compatible each other and using non drop-frame TC as their timestamp standard... So...

A nice explaination about the origin of the drop-frame TC and the historical relationship with the NTSC colour standard is:
--> wikipedia --> SMPTE timecode

@r0lZ
Believe me, the reading is simple and interesting, even for PAL land people, like myself, whose brain is rigidely running at 25 fps... :-)

A nice discussion on "Scenarist project setting; drop or non drop", also nice for other historical reasons is here:
http://forum.doom9.org/showthread.php?t=94293

[Richard1485]

PgcDemux & PgcEdit & MuxMan, are all compatible each other and using non drop-frame TC as their timestamp standard... So...

In that case, the case is closed. :D