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! :thanks:

[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. Should have used ++ (AlignedSplice) in avs. Also, jsoto's delaycut is a solution to fixing AC3 without reencoding. Still...

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 (http://forum.doom9.org/showthread.php?s=&threadid=84097)

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

[mpucoder]

Hmmm... I just ran mplex and on the console it said audio buffer size 16384, but in the system header it says all audio streams buffer bound is 4096. I also have an audio packet with pts = 62348 and SCR of 15067. Meaning the buffer is holding at least 47281 clocks worth of data. With a duration of 2880 (ac3) that's over 16 frames. This audio is 768 bytes/frame = 12288 bytes. So mplex is using a larger buffer, but not telling the player. Any player that believes the system header could have problems playing these.

But, it does explain why no audio from one VOBU in the next. I'm so accustomed to looking at Scenarist and commercial DVDs.

[violao]

This is of course a question for mplex author. Perhaps we should post it to mjpeg.sourceforge.net? In the meantime I found examples of "delayed" audio that mpucoder talked about and they were muxed with mplex too. I've also tested what happens with different bitrate and it appears that when encoded video bitrate is lower, while audio is constant, for the same source clip, the number of audio frames that extend after the last video pack in a VOB tends to increase. Later at home I will check where will dvdauthor put those frames in the authoring phase.

[bullet_pr00f]

violao,

Quote:
> 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.

Forgive me, but I did not and still do not understand your answer. In your first post, you stated that dvdauthor resets the SCR at each new VOB ID. Resetting the SCR to 00:00:00 at each transition is not the goal! Is It? What would be better is for the SCR to increase steadily (and correctly) across all of the pieces. It doesn't sound to me like DVD Author will do this.

jsoto,

Thank you for the mock strip post -- I will try this. But you stated that this won't fix SCR or elapsed time issues. So why do you think that it will help my situation?

[violao]

Originally posted by bullet_pr00f
Forgive me, but I did not and still do not understand your answer. In your first post, you stated that dvdauthor resets the SCR at each new VOB ID. Resetting the SCR to 00:00:00 at each transition is not the goal! Is It?

I am not sure, but dvdauthor creator thinks that it's the only right thing to do when you mix different video sources (files) into a single PGC. If you did what I suggested then you would end up having PGC with several VOB IDs and in case there were no audio gaps inbetween they would be marked seamless. There will be SCR discontinuity at every VOB ID change, but you won't notice it.

However if you simply must have a single VOB made from your sources, then you should cut+paste into elementary streams but you should know that:

1. AC3 and MPEG audio are frame based, so you cannot cut below 1 frame boundary

2. you should cut MPEG video only at I frames and furthermore the first and last GOP of extracted clips should be closed

3. final elementary streams should have the same duration prior to muxing, otherwise you'll either produce gaps or lose A/V sync

AC3 can be cut with delaycut, MPEG video with Mpeg2Schnitt, command line tool mpgtx, Tmpgenc, etc. Splicing is easy with Tmpgenc, but there are a number of other mpeg join tools around.

So you see, the deeper you go into this, the more complicated it becomes. If I were you I would:

1. vStrip 3 source dvds to cells
2. join adjacent cells together with Vobedit into 3 vob files
3. author with dvdauthor

Of course if you want to put all of them into a single PCG then all sources must have the same audio and video attributes.

[violao]

Originally posted by violao
Later at home I will check where will dvdauthor put those frames in the authoring phase.

Just as I suspected dvdauthor leaves all audio frames in the same VOB, therefore they are not being interleaved with the first VOBU from the following VOB ID. The question remains still - does that resetting affects the playback? Not on my player for sure.

Another thing puzzles me. If mux should really put those last few audio packs in the next VOB in seamlessly branched dvds, where then those audio packs come from? If we have 2 alternative scenes, therefore 2 different cells both leading to a common scene in 3rd cell, then to which of these 2 alternative cells does those few first audio frames in 3rd cell belong?

[mpucoder]

For seamless angles the audio is the same in all branches. For non-seamless angle or seamless multi-story, they both end each angle/story with at least one vobu of the same video and audio before merging. This usually results in another cell just before the merge.

[violao]

Originally posted by mpucoder
Hmmm... I just ran mplex and on the console it said audio buffer size 16384...
However, at the end of console messages it says:


INFO: [lt-mplex] Average bit-rate : 8806800 bits/sec
INFO: [lt-mplex] Peak bit-rate : 8994000 bits/sec
INFO: [lt-mplex] BUFFERING min 42 Buf max 148747
INFO: [lt-mplex] AUDIO_STATISTICS: bd
INFO: [lt-mplex] Audio stream length 409600 bytes.
INFO: [lt-mplex] Frames : 3882421820
INFO: [lt-mplex] BUFFERING min 19 Buf max 3660
INFO: [lt-mplex] MUX STATUS: no under-runs detected.

so it seems that audio buffer will be filled with max 3660 bytes in this example (with extreme bitrates: video 9 Mbps, audio 640 kbps). Perhaps this number should be checked whenever mplex is run, rather than console warnings.

[violao]

Originally posted by bullet_pr00f
Resetting the SCR to 00:00:00 at each transition is not the goal! Is It?
I just checked The Matrix DVD R1 with "white rabbit" and at the beginning of merging VOBs SCR is indeed being reset and audio packs following this reset start from PTS 0. If this DVD is considered compliant, that I guess it's reasonable to conclude that it's safe to mux/join different VOBs with SCR reset inbetween.