skewed Chapter points problem

[j-fish]

Hey,
I am Trying to Reauthor a dvd,my problem is that the chapter points are not the same as the original.
I'm working with Pgcdemux(Though i imported the Chapter information from Dvd Decrypter) and Muxman to compile it.
Also i tried to take the Cell Times and multiply them by .999 But still wasnt accurate.

Thanks.

[jsoto]

PgcDemux (and also IFOEdit) extracts the Celltimes from the IFO, and probably they are OK.

What are you doing yo reauthor? If you are recoding the video, then you must tell the encoder to put I-Frames exactly on the celltimes you are going to make the chapters. One chapter has to start just in a cell, and a cell has to begin with an I-Frame

Muxman (and any mux) can only put the chapters in I-Frames. You should have a log telling you the time requested and the time where the chapter is finally located.

Ah!. Welcome to the forum, seems it's your first post..

jsoto

[j-fish]

First of all thanks for the welcoming.
The problem with PgcDemux's chapters points its that sometimes it extracts more chapter than there really are,so i get an error "reference to non existant scene.So i take chapters from Dvd Decrypter(which makes it in the same amount of chapters as the original movie).
I'm Adding subtitle to a movie so i use pgcdemux to spereate audio/video/subpictures and adding my own subtitle.
(http://forum.videohelp.com/viewtopic.php?t=275603 <-- thats the guide i am using)
I don't really understand that I-frames you'r talking about.

[manono]

Hi-

If you are recoding the video, then you must tell the encoder to put I-Frames exactly on the celltimes you are going to make the chapters.

If I'm understanding you correctly, jsoto, setting the chapter points during the encoding isn't such a good idea. By forcing an I-Frame for the chapter you are often breaking the cadence, resulting in a drop to video around that chapter point. This can result in interlacing on some frames around the chapter points for progressive displays. I'm referring to NTSC DVDs, and don't know if it affects PAL or not. Criterion Collection DVDs are notorious for doing this. I once went over one of them around all the chapters and found 34 interlaced frames in an otherwise progressively encoded movie. It's no problem for interlaced TV sets, but if viewing on a computer with PowerDVD, for example, or viewing on an HDTV using a flag reading progressive scan DVD player, the interlacing will often slip through.

About a third of the way down this review, in "The DVD" section, you'll see what I'm talking about:

http://www.mastersofcinema.org/bresson/Words/Criterion_AuHasardBalthazar.html

If he's getting wrong chapter points, I suggest he go through the DVD and find the frames and change the Celltimes.txt when necessary. They should only be set during the authoring stage.

[manono]

i get an error "reference to non existant scene.

Delete the last chapter and author again.

[j-fish]

I'm not Re-coding,Main movie has 21 celltimes,Pgcdemux sees it has 24,if i delete the 3 last cells it will just make the last chapter longer.
And those chapters points(celltime.txt) i get, are really by far, not matching the original's.

[manono]

I said delete the last one and try again.

There can often be more cells than chapters. If you haven't been able to reauthor it yet, then I'm not sure how you know that the celltimes.txt frame numbers don't correspond to the real chapter points, as I've never seen that. My guess is that you're looking at a 23.976fps video, while the chapter frame numbers are for 29.97fps.

[j-fish]

Ok,i deleted the last one and compiled it.
Now the Authored dvd has 23 chapter points.
The times of the chapters are matched in the beginning untill the authored dvd creates those 2 more un-needed chapter points

[manono]

Fit it back into the original DVD using the Replace button in VobBlanker. You'll get the correct chapters back. Either that or locate where the 2 extra cells are and delete them and reauthor.

[j-fish]

Yeah,done that with deleting the 2 extra cells(That worked).
but i didnt know Replacing it with the original would correct the chapters back to how it was

[manono]

Not replacing it with the original, but the original with it.

Since you said you're not reencoding, I'm not real sure what the point of this exercize is. Do you just want to get the movie without any menus or extras? If so, using Shrink in reauthor mode and no compression would have saved you a lot of time and trouble. Did you just want to strip out some audio, but keep everything else? If so, VobBlanker could have easily done it. Anyway, a little more information might save you some work the next time you have a similar project.

[j-fish]

Just read above what guide i am using and yo'll understand.
After i corrected the chapter points by deleting those two,i had to use Voblanker to Re-pattern the subtitle color,so it will the original,but now i am getting that warnning:
Cells to be replaced =24.
Cells in replacing VOB=21
WARNING: Number of Cells lower in replacing title. Blanking last ones

And again i dont have the same amount of Chapters like the original

[manono]

Hehe, if it's not one thing, it's another, eh? First, I apologize for not noticing the link you provided earlier. That's a nice guide, except for one thing. His step 9 involves IFOEdit, and the same thing can be accomplished much more easily using PGCEdit. There's even a post further down that thread by Mystiqq saying the same thing, and detailing how to do it. I also fix the subtitle colors in PGCEdit quite easily.

Second, although you seemed to be surprised last time about using VobBlanker to replace the original movie in the DVD with your reauthored one, its use is detailed in that guide, just the way I would do it. The fact that you have 2 more cells than chapters won't matter. However, a couple of posts back I said, "Fit it back into the original DVD using the Replace button in VobBlanker". That was for the 23 cells (only the last one deleted). If you reauthor again (sorry) with only the last one deleted, and then replace the original with the reauthored one using VobBlanker, you'll get a warning about:

Cells to be replaced =24.
Cells in replacing VOB=23
WARNING: Number of Cells lower in replacing title. Blanking last ones

If I had realized you were following that guide, I wouldn't have mentioned deleting the 2 extra cells. So I apologize again.

But you can ignore that new warning the next time you do it, because it's only a very short section at the very end of the movie, and with any luck, you'll have all your chapters in the right place when going to the chapters menu of the DVD.

[jsoto]

Mmmm,

One chapter can have more than one cell. It is usual that the layer break is inside a chapter, but just at the beginning of a cell.
pgcDemux extracts the CELL-times, not the Chapter-times.
VobBlanker replaces CELLS, so everything works fine with cell-times.
Chapters will be in the original time.
Cell-times are computed in frames (frame number), so no issues about 29,97 or 29,976.

@j-fish
So, which is exactly your problem?

About reencoding and forcing the I-Frame: Well, I usually do it (dvd2svcd does it automatically for you) and never had a problem....Muxing again, cells start exacly where I want. I'm a PAL user, but what you are asking the encoder is to put an I-Frame where it was before, so I cannot see any problem...

jsoto

[jsoto]

The problem with PgcDemux's chapters points its that sometimes it extracts more chapter than there really are,so i get an error "reference to non existant scene. As I said, pgcDemux extracts CELL-times, not chapter times.
But, there is a setting to DO NOT include the last celltime. This is the one that causes Muxman complains. So be sure the "include End time" checkbox is unchecked, or, if you have extracted the cell times with IFOEdit, delete the last one.

jsoto

[manono]

Hi-
One chapter can have more than one cell. It is usual that the layer break is inside a chapter, but just at the beginning of a cell.
pgcDemux extracts the CELL-times, not the Chapter-times.
VobBlanker replaces CELLS, so everything works fine with cell-times.
Chapters will be in the original time.
Cell-times are computed in frames (frame number), so no issues about 29,97 or 29,976.
Was all that for my benefit? In my second post I did say it wrong when I said to delete the last chapter, when I should have said delete the last cell or the last line in the celltimes.txt.

Cell-times are computed in frames (frame number), so no issues about 29,97 or 29,976. I think you meant to say 23.976.

Ah, but for NTSC there are. The cell frame numbers are based on the pulled down 29.97fps frames. If you encode for 23.976 progressive, then you have 20% fewer frames. I should say, I guess, that I do my pulldown after encoding. Check out this post, my reply, and his reply back:

http://forum.doom9.org/showthread.php?p=758720#post758720

I was speculating, wrongly maybe, that j-fish had the same problem. But even if you do the pulldown in CCE during the encoding and also set the chapter points, I think it does sometimes force I-Frames where they might not otherwise be, and cause the problems I described earlier. Otherwise, why would Muxman change the chapter frame numbers sometimes. Here's part of a Muxman log:
Starting scene Segment_1_scn1 at 00:00:00:00
Starting scene Segment_1_scn2 at 00:13:13:06, requested for 00:13:13:00
Starting scene Segment_1_scn3 at 00:20:06:21, requested for 00:20:06:15
Starting scene Segment_1_scn4 at 00:30:13:22, requested for 00:30:13:15
Starting scene Segment_1_scn5 at 00:39:34:10, requested for 00:39:34:00
Starting scene Segment_1_scn6 at 00:48:34:16, requested for 00:48:34:15
Starting scene Segment_1_scn7 at 01:00:39:02, requested for 01:00:39:00
Starting scene Segment_1_scn8 at 01:09:34:28, requested for 01:09:34:15
Starting scene Segment_1_scn9 at 01:19:12:13, requested for 01:19:12:00
Starting scene Segment_1_scn10 at 01:30:15:21, requested for 01:30:15:15
Starting scene Segment_1_scn11 at 01:39:32:07, requested for 01:39:32:00
Starting scene Segment_1_scn12 at 01:48:47:07, requested for 01:48:47:00
I could be wrong, but I interpret that to mean that there was no I-Frame for the original celltime.txt frame number, Muxman chose a nearby I-Frame for the chapter point, and that had the chapters been set during the encoding, I-Frames would have been forced. It may be because of the drop frame flag or the 30/1.001 thing that changes it. I always thought it was basic practice (for NTSC anyway) that you don't set them during the encoding stage, but during the authoring stage. Please correct me if I'm wrong.

[jsoto]

Was all that for my benefit? In my second post I did say it wrong when I said to delete the last chapter, when I should have said delete the last cell or the last line in the celltimes.txt. Not really, just to point out the difference between cells and chapters. May be I read too fast your posts...

I think you meant to say 23.976. Sorry, seems here I was wrong... NTSC in DVD is always 29,97 (90000/3003 fps) isn't it?

Ah, but for NTSC there are. The cell frame numbers are based on the pulled down 29.97fps frames. If you encode for 23.976 progressive, then you have 20% fewer frames. You're right!. Well, NTSC problems....

why would Muxman change the chapter frame numbers sometimes.
I could be wrong, but I interpret that to mean that there was no I-Frame for the original celltime.txt frame number, Muxman chose a nearby I-Frame for the chapter point
, and that had the chapters been set during the encoding, I-Frames would have been forced. It may be because of the drop frame flag or the 30/1.001 thing that changes it.
Well, I have no experience in NTSC and I see there can be the problems you are describing... but in PAL (no pulldown so no problems), my MuxMan logs (and the new IFOs) show a perfect match in the actual cell times and the requested ones if I force the chapter points during the encoding.

jsoto

[mpucoder]

cell times are always in reference to displayed frames, not encoded pictures, and the framerate for NTSC is always 29.97
You can get the celltimes manually to double check by using IfoEdit, just look at the summary for the PGC, frame numbers are in square brackets just to the left of the interpretation of the flags.
Forcing I-pictures (mpeg is encoded as pictures, not frames) does not cause interlacing artifacts, bad IVTC does (although it is recommended to begin cells with rff=0, tff=1. But that is simply a matter of making a 1 or 2 frame adjustment to the forced GOP position). Once encoded properly IVTC should never be a problem, re-encoding should always be done with total disregard for the pulldown flags, ie just stick to re-encoding the pictures, and not reconstructing the frames as they would be displayed.

[manono]

Hi-

NTSC in DVD is always 29,97 (90000/3003 fps) isn't it?

Yes, 29.97003fps

Thanks for taking the time to respond, jsoto. I'm hesitant to post in this forum because some of my real heroes in the video world hang out here, and I'm just a rank amateur. These include you, jeanl, blutach, jdobbs, mpucoder, 2COOL, and others I can't think of at the moment. You folks have developed the tools that have become indispensible to the rest of us in our hobby, and have the answers to the questions we ask. You all know things I'm frantically trying to learn. Maybe some of the NTSC people, such as mpucoder or jdobbs will find this thread and set me straight over anything wrong or stupid I may have said. Yep, sometimes you PAL guys don't know how good you have it. :)

Edit: While I was fumbling for the words, and leaving the computer for a while, mpucoder stepped in.

[manono]

mpucoder-

Then how would you explain the drop to video at every single chapter and nowhere else in most Criterion DVDs. Most of them go 2 2 2 2 for 5 to 15 frames at the chapter points, and 0 1 2 3 0 1 2 3 everywhere else during the movie. Other studios used to have it also, especially Universal DVDs, but they've cleaned up their act. If you didn't see the link I posted earlier, please see "The Video" section about a third of the way down:

http://www.mastersofcinema.org/bresson/Words/Criterion_AuHasardBalthazar.html

Is the reviewer just plain wrong? It doesn't seem logical to me for the IVTC to screw up only at chapter points.

[mpucoder]

It doesn't seem logical to me for the IVTC to screw up only at chapter points.
It does if they are trying to IVTC and encode in one pass, and the program cannot properly handle the situation (forced I-picture). It could also be that the IVTC was done seperately for each cell (which when fed to an encoder is another way to get the I-picture where you want it) and out of step at the start of each. But I'm not really sure if the images in that article are the encoded pictures or a screen capture of playback.

[j-fish]

As I said, pgcDemux extracts CELL-times, not chapter times.
But, there is a setting to DO NOT include the last celltime. This is the one that causes Muxman complains. So be sure the "include End time" checkbox is unchecked, or, if you have extracted the cell times with IFOEdit, delete the last one.

jsoto


"Include End Time" is unchecked by default in Pgcdemux,so that wasnt the case.
So,the question is how can i avoid getting that error("reference to non exsitant scene..") in Muxman before i try to compile it.

Big thanks for the fast and professional help.

[jsoto]

Please send me the IFOs, celltimes.txt and muxman.log. I'll take a look.

jsoto

[j-fish]

ok thanks

[jsoto]

Hi,

MuxMan complains about the last scene (last cell is a blank one, starting at frame 202728).. May be this cell is not fully standard and has no video...

In any case just delete the last line of your celltimes.txt (202728). Muxman will create 23 cells instead of 24, but VobBlanker will add the cell# 24 as a blank one, so your chapters will be ok.


[Cell 21] [V/C Id: 1/21] : time: 00:04:19.27 / 30 fps [Pos: 01:39:22.27] [Frames: 178887] SP/ILVU/DISC/SA:[yes/ no/ no/ no]
[Ch 19] [Pg 19] [Cell 22] [V/C Id: 1/22] : time: 00:04:22.25 / 30 fps [Pos: 01:43:45.22] [Frames: 186772] SP/ILVU/DISC/SA:[yes/ no/ no/ no]
[Ch 20] [Pg 20] [Cell 23] [V/C Id: 1/23] : time: 00:08:51.26 / 30 fps [Pos: 01:52:37.18] [Frames: 202728] SP/ILVU/DISC/SA:[yes/ no/ no/ no]
[Ch 21] [Pg 21] [Cell 24] [V/C Id: 2/ 1] Layer Br.: time: 00:00:01.00 / 30 fps [Pos: 01:52:38.18] [Frames: 202758] SP/ILVU/DISC/SA:[ no/ no/yes/ no]

[j-fish]

Roger that.
thanks for the help:]

[Sir Didymus]

Similar troubles (but less evident to observe, and less easy to recover), arise in case the blanked "troublesome" cell is at the beginning of the PGC...

This situation and some implications related to the a/v synchronisation, was discussed in the PgcDemux thread...

Cheers,
SD

[jsoto]

Similar troubles (but less evident to observe, and less easy to recover), arise in case the blanked "troublesome" cell is at the beginning of the PGC...

This situation and some implications related to the a/v synchronisation, was discussed in the PgcDemux thread...

Cheers,
SDI didn't forget it.., still in the todo. I really have few free time lately...

But , the best way to avoid the problems of the "tiny cells" at the beginning ( ;) ) is to remove them with pgcEdit. In this way, the first cell of the PGC has 0 msec of delay a/v and no problems of synch will arise...


jsoto

[Sir Didymus]

...the best way to avoid the problems of the "tiny cells" at the beginning ( ;) ) is to remove them with pgcEdit. In this way, the first cell of the PGC has 0 msec of delay a/v and no problems of synch will arise...
jsoto

Yes, that's right. Thanks for explicitely pointing out the way to overcome the problem... :)

Also, forgive me for the pressure. It was really not intentional...

Please take the matter as a very low priority...

I just catched the relationship with the j-fish issue, and made it explicit...

Have a nice w/e,
SD

[jsoto]

Also, forgive me for the pressure. It was really not intentional...
Don't worry...
I started to work on it, but I found I cannot trust the pointer to the audio frame header... IFOEdit has a bug here and may be other authoring programs too, so I'm thinking to don't trust at all the audio header pointers and parsing the audio in all cases (as you know, at least I have to do it in mpeg)
So I have to re-write all again.
jsoto