Timestamps in Joined VOB are not correct!

[bullet_pr00f]

Although I am relatively new to DVD authoring, I have read (and enjoyed) many of the guides on this site. Most of the techniques that I used, I found in one/more of them.

I am trying to make one joined movie out of clips from several other movies. I used the start/end feature of DVDShrink to extract the various pieces. Then I renamed the pieces (in sequence) and have used two different methods to join them together:
1) Allow DVD lab to join the VOBs on import
2) Use VOBEdit to join the streams
In both cases, the joined VOB (result) will “play” correctly but I don’t think that the timestamps internal to the VOB are correct. When I try to bring this VOB into DVD lab – to place chapter markers, the navigation is all wrong. The timeline displayed is not even sequential.

If I demux the streams (from either DVD lab) or VOBEdit, the audio (.ac3) has the correct length, but the video (.m2v) file produces is too short. I even demuxed the pieces and tried to assemble them demuxed, but the result audio file is always the correct size, but the m2v file is too short. This means when the two streams are re-assembled the video/audio is out of sync.

For example:
Clip 1 from Movie 1: 00:01 thru 03:00
Clip 2 from Movie 2: 05:00 thru 06:00
Clip 3 from Movie 3: 02:00 thru 02:30

Assembled in order 1,2,3

Leads to a timeline 00:01 thru 03:00, 05:00 thru 06:00 and 02:00 thru 02:30. The navigation is messed up because there are in effect two entries for 02:00.

I have searched this forum (and others) and I have not seen any discussions of timestamps internal to the VOB, but based on my experience – I must conclude that the VOB itself somehow knows the timestamp for each frame? How can I reset these values so that my joined VOB has one flow of time?

[mpucoder]

Which timestamps are you looking at, the 2 in the NAV pack (cell elapsed time), or the one in the GOP header? After multiplexing the GOP timestamp is irrelevant. And actually the cell elapsed time is not what controls playback, but the pts value for the first frame in the GOP.

[mrslacker]

I too have recently made a disc from joined VOB series and I am equally as perplexed by the SCR, PTS, and "this->lba" values. They don't seem to be updated in the VOBs to reflect a new continuous stream.

The resulting disc plays just fine, able to jump from chapter to chapter. However, the point-and-click seek and the fast forward functions in mplayerc do not work properly. When I click past the joint time, the video jumps to the corresponding location in the first half! Fast forwarding after the joint shows the corresponding video from the first half in FF. Presumably these functions are reading fallacious PTS or lba information from the vobs?

Starting with two sets of 3 vob files going from vob/cellid 01/01-01/10 and 01/11-01/20, I joined the vobs using VobEdit's "Join CellVob files" function, keeping the general V/C layout. I created IFOs with IfoEdit for the resulting 5 vob files. The PTS and SCR in the both the NAV packs and GOP headers seem unchanged. My first thought was to set SCR discontinuity for the joint cell, but that didn't solve the anomolous playback behaviour.

I can clearly see the values that aren't updated to reflect a continuous stream in VobEdit. Am I missing a step or is this an issue with joining VOBs with VobEdit? Thanks for the insight. I'm out of my league on this one!

[mpucoder]

I've never used that function of VobEdit, so anything I say is just based on your observations and my knowledge of DVD.

It's possible to join two multiplexed vobs so long as the vob/cell numbers are unique. That condition seems to be satisfied.
The joint itself will be a non-seamless discontinous joint (cell category = 2).
That makes it OK for the clock to reset. And being non-seamless it will pause, but that can't be helped when using seperately multiplexed vobs (to be seamless requires moving some audio packs into the second vob).

BUT the "this->lba" must be corrected. These values are the sector number of the vobs relative to the start of the titleset. The player uses them to check its location.

For random acces by time the time map needs to be rebuilt, I'm not sure if either VobEdit or Ifoedit did this. It sounds as if the two tables were simply joined together. Or, perhaps, regenerated by scanning the vobs and using "this->lba" values, which will point to the first vob.

One thing to check would be that table. Using IfoEdit scan the VTS_TMAPTI table looking for a reset in the values. You don't need to look at every value, it should stand out when they reset.

[violao]

From what I remember from a discussion with Scott Smith, the creator of dvdauthor, if you strip a part of VOB ID, be it a single cell or more of them, then the rest of VOB will have SCR discontinuity. If you rearrange the order of cells you will have SCR moving backwards at cell changes. So I think the right way to do this would be to create NEW VOB ID for every discontinuity in resulting SCR and make sure that SCR is reset to 0 at every VOB ID change. dvdauthor does exactly that.

...to be seamless requires moving some audio packs into the second vob...

@mpucoder - Why did you say that?

[mpucoder]

That was in reference to joining seperately multiplexed vobs. To see what this is about take a look at any two adjacent VOBUs within a cell. Look at vobu_e_ptm (NAV pack, offset 0x3d) this is the end of video time. Now look at the audio packs in the next VOBU and you will see that they are presenting BEFORE that time. This is due to buffering in the player, which leads to a greater delay between scr and pts for video than audio. Bigger video buffer, bigger delay.
With me so far?
Now when a multiplexer finishes, all the remaining audio is placed in the last VOBU. When a player encounters this it must play out the audio, as the 4K audio buffer is not large enough to hold it all, before starting the next VOBU. Meantime the video is continuing to decode, so by the time the player can begin the next VOBU it is out of video. This makes it impossible to play seamlessly if joined with another vob.

btw, the opposite of this, the seamless joint, is why demuxing by cell or vobid can lead to huge negative delays (the first VOBU contains audio from the previous cell, which gets added to the beginning)

[mrslacker]

Originally posted by mpucoder
BUT the "this->lba" must be corrected. These values are the sector number of the vobs relative to the start of the titleset. The player uses them to check its location.

For random acces by time the time map needs to be rebuilt, I'm not sure if either VobEdit or Ifoedit did this. It sounds as if the two tables were simply joined together. Or, perhaps, regenerated by scanning the vobs and using "this->lba" values, which will point to the first vob.

One thing to check would be that table. Using IfoEdit scan the VTS_TMAPTI table looking for a reset in the values. You don't need to look at every value, it should stand out when they reset.

The values in VTS_TMAPTI are monotonically increasing. However, the "this->lba" values reset to zero (along with SCR, PTS, et al) in a Nav pack of VTS_1_03.VOB, where the joint occurs. I assumed VobEdit would correct the values, but it does not.

I have used both the "Join clips" and "Join CellVob files" functions of VobEdit, using vobs with fixed vobids and using a new vobid for the second set of vobs. In any scenario, I have always used unique vob/cell numbers as you advised. I don't think VobEdit is going to get the job done in this particular case.

I was trying to avoid concatenating streams before muxing, as I'm having a hard time with audio sync in the second half. The audio seems to lead the video, and it has been a challenge for me to determine why or what the delay should be. Even an avs using source(avi1)+source(avi2) loses sync. Individual avs files for each source have no problem. Frame rates are exactly equal. Sigh. [EDIT]Should have used ++ (AlignedSplice) in avs. Also, jsoto's delaycut is a solution to fixing AC3 without reencoding. Still...[/EDIT]

Anyway, Is there a way to correct the lba values in VTS VOBs? Or is joining two titles into one VTS too unorthodox? By the way, regardless of the cell type (2, 8, or 10), the anomalous behavior persists. Thanks again.

[jsoto]

Try a IFOEdit's mock strip. I'm pretty sure it fixes this-->lba pointers

jsoto

[mrslacker]

Originally posted by jsoto
Try a IFOEdit's mock strip. I'm pretty sure it fixes this-->lba pointers

:smack forehead: Ah, yes! I'll try that. How could I forget doing it repeatedly before you added the feature to VobBlanker? Thanks jsoto.

[violao]

Originally posted by mpucoder
btw, the opposite of this, the seamless joint, is why demuxing by cell or vobid can lead to huge negative delays (the first VOBU contains audio from the previous cell, which gets added to the beginning)

Are you implying that seamless transition between vobs is not possible unless audio from the previous VOB extends to the next VOB? That would mean that it's impossible to mux VOBs separately and then concatenate them in authoring tool into a seamless PGC, unless we muxed delayed audio previously. That confuses me because I made a number of tests that show it's possible to do that as long as there are no audio gaps inbetween.

[mpucoder]

I'm not implying, I'm stating it. The "run-out" at the end of a multiplex disrupts the interleaving of video and audio. The SCR also extends beyond its normal limit to allow metered data flow through the audio buffer.
The duration of any VOBU can be determined by subtracting vobu_s_ptm from vobu_e_ptm. This value will be the product of the number of frames multiplied by frame duration (3003 for NTSC, 3600 for PAL). Now look at the difference between two "normal" VOBU starting (NAV pack) SCR values. It will be the same as the duration of the previous VOBU, or just slightly greater (due to borrowing a little time). Now you can't do the same for two seperately multiplexed vobs, but you can look at the last SCR and notice that it extends well beyond NAV_scr + vobu_e_ptm - vobu_s_ptm.

But that does not make it impossible for an authoring program to join the vobs seamlessly. It just means you cannot simply butt them together, you have to do some remuxing.

You should be able to find examples of seamless vob joins. In them you will see the first audio having pts times lower than the video or vobu_s_ptm. This is audio that "belongs" to the previous vob.

[mpucoder]

If, on the other hand, you are talking about demuxing, seperately muxing, and then joining - this is different. This is where two wrongs make a right. All the demuxers I've seen do not handle audio properly when demuxing by VobID. They start and stop at the vob boundary, rather than looking at pts values. This results in the audio for the first vob being short, hence a short run-out at the end. The second or later vobs will start with audio that belongs to the previous vob, and have a huge negative delay. And if you multiplex them with that delay you end up with a vob that can be joined almost seamlessly (depending on how the negative delay was handled, if any audio was discarded).

[violao]

Originally posted by mpucoder
If, on the other hand, you are talking about demuxing, seperately muxing, and then joining - this is different...

No, I was talking about authoring, not re-authoring. Supposing we have fresh new video/audio to be muxed and authored for a new dvd. Do we need this "delay" in that case in your opinion?

[mpucoder]

I'm not sure what delay you are referring to. All multiplexers work this way because the video buffer is larger than the audio.

[bullet_pr00f]

Thanks to everyone for responding to my post. After reading all the posts, I thought that I should clarify my problem a little.

The “joined” VOB actually plays well – there might be a small pause, but if it is there, it is not really noticeable. So while I appreciate the comments regarding the seamless/join/demux boundaries – they don’t seem very pertinent to the issue that I described.

Also, the posts that describe using IFOEdit or other tools to change the IFO files really don’t help. I don’t have and don’t need IFO files. When you import a VOB file into DVD-LAB, it seems to read the VOB file alone without looking at its IFO file.

So that brings me back to my original thought – the discontinuity in the timeline occurs in the VOB itself. After looking through the file(s) with VOBEdit, it looks to me that the SCR values in the NAV packs do not increase continually – but rather jump around because the VOB files were just “joined” without re-setting the SCR timeline. Shouldn’t a tool be able to start indexing at the first NAV pack 00:00:00 and then start incrementing from there? Is there a tool that will do this?

Jsoto – I have seen several posts that lead me to believe that VOBBlanker might be able to help, but I cannot figure out how to use these tools to regenerate correct VOB files. What is a “mock strip”?

If no such tool exists, does anyone have experience demuxing the VOB to its pieces (ac3 and m2v) and the joining the pieces. Why does my video stream always end up so much shorter (a couple of minutes) than my audio piece?

Thanks to all for your time/posts.

[violao]

Originally posted by mpucoder
To see what this is about take a look at any two adjacent VOBUs within a cell. Look at vobu_e_ptm (NAV pack, offset 0x3d) this is the end of video time. Now look at the audio packs in the next VOBU and you will see that they are presenting BEFORE that time.

I'm not sure about the "delay" either, but I cannot confirm this. I've just checked the VOBUs from a dvd that I created. VOBs were muxed from audio/video separately with mplex from mjpegtools and authored into 1 seamless PGC with dvdauthor 0.6.9. These are the PTS numbers seen by Vobedit from 2 adjacent VOBUs:

0 - 1st VOBU start 0 end 350
start 16619 - end 70619
1st video PTS - 16619
1st audio PTS - 16619
...
last audio PTS - 62699

350 - 2nd VOBU start 70619 end 124619
1st video PTS - 77819
1st audio PTS - 71339
...

We can see that the audio from the 2nd VOBU is indeed played before 1st video frame from the same VOBU, but not before the previous VOBU end. I've even stripped this dvd with vStrip, recoded some VOBs, remuxed them back with original AC3 audio and reauthored it back with dvdauthor and it still plays seamlessly. The question of course is can we trust what Vobedit tells us?

Perhaps I also have to say that I make PAL dvds which makes it very easy for me to match AC3 audio/video duration. I even made this particular dvd perform seamless jumps of 900000 sectors in my cheap standalone player (this will be explained in a separate thread). Or have I just been lucky using mplex/dvdauthor?

[violao]

Originally posted by bullet_pr00f
Shouldn’t a tool be able to start indexing at the first NAV pack 00:00:00 and then start incrementing from there? Is there a tool that will do this?

I think I did answer this question. Freeware dvdauthor does exactly what you need. It resets SCR at every new VOB supplied in xml description file with:

<vob file="somefile.mpg"/>

The problem of "does audio need to extend to next VOB" still remains unanswered.

[jsoto]

IFOEdit's mock strip

Beware AFAIK it does not fix SCR, PTSs or elapsed time issues, but fixes this-->lba pointers.

VobBlanker currently fixes elapsed times (when cutting cells) but SCR and PTSs are untouched, sorry.

jsoto

[mpucoder]

This brings up a question I had about mplex and its audio buffer size. It looks like mplex uses a larger audio buffer than is standard. That would allow it to have a larger delay, and not have to span. Do me a favor, open the vob with VobEdit, click on a NAV pack, and enable SysHdr (at the bottom of VobEdit). That will let you see the buffer sizes, the one I'm interested in is "all audio streams" STD buffer bound.

btw - the video starts at vobu_s_ptm. If the first pts is larger it is because you have a closed GOP. Look at the details of the first frame header, it should say the "temperal (sic) sequence number" is 2. This little gem led to the negative audio delay myth. The pts is for the first decoded frame, but in this case that is the third displayed frame. Subtract tsn * frame_duration (in this case 2 * 3600 = 7200) from pts and you have vobu_s_ptm.
Note to NTSC_landers - you also have to check rff on the B frames (tsn 0 and 1) as they will delay presenting tsn 2.

[jsoto]

That will let you see the buffer sizes, the one I'm interested in is "all audio streams" STD buffer bound.

4096 in IFOEdit (mplex based) muxed VOBs