VOB analysis question on navigation and timecodes

[konran]

Hello all,

I've discussed a similar subject in the MPEG-2 Encoding forum and I continue this here because it deals with VOB file internals. I'm writing some analysis stuff for MPEG-1/2 files and therefore also for VOB's.

Now I'm struggling with VOB files which are 2nd, 3rd or higher in a sequence of files in the same VTS. When I examine the NAV packs in the header I'm getting timecode values in the beginning that are greater than at its end.

e.g.: VTS_01_2.VOB has 2225sec (VOB ID = 1) on the 1st VOBU and 1729sec (VOB ID = 2) on its last VOBU. So I assume that this is caused by multiplexing the 4 movies into this VTS and the VOB files are splitted anywhere to assure the 1GB file size limit without regarding movie boundaries. Is that correct?

In my interface I only examine single MPEG files and I don't parse the IFO file. Therefore, if I'm right with my assumption of above, is it possible to read timecodes of any VOB file in a sequence of 1 VTS without using the IFO and if yes, how would one do it as fast as possible without reading a whole VOB file? Is there another way than jumping around to find all VOB ID increments (or decrements if I come from the end)?

BTW: Is I correct that the NAV packs in a VOB are always n * 2048 bytes away from another?

If not and if I have to use the IFO: is there a documented interface to interpret an IFO file?

Regards,
Konran

[blutach]

As you have already seen, your VOBIDs are different - the SCR, PTM and general presentation timimgs can change with a VID change and if you have 4 distinct bits of video in there (i.e. not a single movie), I would say this is certainly happening. Look at the timings in the last navpack of VID 1 and compare to the next one at the very start of VCID 2/1 (for example). You can easily find the last navpack of a VID using PgcEdit - double click on the movie and look at the Last VOBU Start for the movie that corresponds to VOB ID 1. (e.g. 731,324 would refer to LBA 207,037 in VTS_XX_2.VOB, assuming _1.VOB was "full size" of 524,287 sectors).

And yes, ALL packs are 2048 long. So, the navpacks are 2048 * n away from each other. The next one is found by using the VOBU end address relative in the DSI stream 2 (0x040f). See http://www.mpucoder.com/DVD/dsi_pkt.html for more info.

Regards

[Alex_ander]

Here's a mirror with open access:
http://dvd.sourceforge.net/dvdinfo/index.html

[blutach]

The sourceforge site, while having much the same as mpucoder's, is not quite a "mirror". But it should suffice for konran's purposes.

Regards

[konran]

Thanks a lot indeed ...
You can easily find the last navpack of a VID using PgcEdit - double click on the movie and look at the Last VOBU Start for the movie that corresponds to VOB ID 1. (e.g. 731,324 would refer to LBA 207,037 in VTS_XX_2.VOB, assuming _1.VOB was "full size" of 524,287 sectors).

And yes, ALL packs are 2048 long. So, the navpacks are 2048 * n away from each other. The next one is found by using the VOBU end address relative in the DSI stream 2 (0x040f).
... ok, I can see that with PgcEdit and with vobu_ea of the DSI packet I'm able to jump over each VOBU easily. I'm mpucoder member - so I'm getting the pages in full but I did not realize that the vobu_ea offset is relative and measured in DVD sized sectors.

Also the IFO format is explained ... so if I would parse it I think I could jump to each VOB ID start quite fast. But if I have a VOB file isolated from the rest of the "DVD's world" I more likely want to handle a single VOB file. So is there a chance to jump over bigger amounts than VOBU's without parsing the IFO?

i.e. can I calculate the end of a whole VOB ID set of all VOBU's without parsing the IFO to find the break over between e.g. VOB ID 1 and VOB ID 2?

And: what is the meaning of nv_pck_lbn Logical Block Number (sector) of this block for a PCI packet? Is it sector absolute within the total sectors of a whole VTS (i.e. all related VOB files added that give the amount of sectors)?

Regards,
Konran

[r0lZ]

Just to clarify: when the VOB ID changes, a new VOB begins. VOB means "Video OBject", and it's an independent unit containing video (not to be confused with VOB file: the VOB files can be cut almost anywhere, just before a new nav pack.) Therefore, a new VOB must have its timings and Cell IDs reset, as blutach said. On the other hand, the Cell IDs change at each new cell, for example at the chapter points. They do not imply a reset of the timings.

A title can be made on a single VOB, but often, it is divided into several VOBs. For example, many authoring programs start a new VOB at the layer break point. (But that's not mandatory: a new Cell ID is sufficient.) It is theoretically possible to author a single title with many VOBs (say one for each cell) but I have never seen that.

A new VOB is also mandatory when the player must jump non-seamlessly from a cell to another. Although it's rarely used in movies, it's extremely frequent in games and menus. You will also find often a little black cell at the end of the movie. That cell is an additional chapter, needed only to allow the user to jump to the end of the title with the Next Chapter button of the remote. It doesn't need to be just after the movie. It can be, for example, at the very end of the VOB files. Of course, in this case, it must have a new VOB ID.

Things are much more complicated in interleaved material (multi-angle or multi-story titles.) Each interleaved cell must have a new VOB ID. For example, suppose cell 1 of a movie is a normal cell, and the following cell is multi-angle. The sequence of VOB/Cell IDs will be something like this:
1/1 2/1 3/1 2/1 3/1 2/1 3/1 2/1 3/1 ... 4/1 ...
Where the 1/1 is the first cell, the 2/1 and 3/1 cells are two interleaved cells but only one is played (respectively angle 1 and 2), and 4/1 is the fourth cell (the third played cell). Cell 2/1 has continuous timings, but you have to skip cell 3/1, which has its own continuous timings, or vice versa, depending of the angle you want to show.

Take care also at the ARccOS/RipGuard protected material. They include dummy cells to confuse the rippers. Some of them may be completely unreadable, or may contain intentional errors. They are usually short cells at the beginning and/or end of the movie.

[r0lZ]

So is there a chance to jump over bigger amounts than VOBU's without parsing the IFO?

i.e. can I calculate the end of a whole VOB ID set of all VOBU's without parsing the IFO to find the break over between e.g. VOB ID 1 and VOB ID 2?
I don't think so. But if you read only the navpacks, you can skip the other packs (video/audio/subpic material) easily.

BTW, note that the IFOs contain also a table of the starting sectors of each VOBU: the VTS_VOBU_ADMAP (and the VTSM_VOBU_ADMAP for the menus.)

[konran]

Fine, clarifying is always helpful :)
So I'm almost sure that I will run into trouble on multi-angle formatted VOBs. The main thing of interest for my application is the amount of frames in an MPEG file. That's the reason why I want to read most accurate timing information out of the single files. I know that these timing not always are as exact as needed - but I'll take it if I don't have other things. The requested feature is to calculate the duration/frame count of a file before fully reading it. After that the file will be fully processed anyway, so I don't want to parse a file twice.
I don't think so. But if you read only the navpacks, you can skip the other packs (video/audio/subpic material) easily.
Yes, that is better than my previous attempt of parsing all PES headers. But it's only about half a second and I have to jump a lot to reach a VOB ID's end and the starting point of the next one...
BTW, note that the IFOs contain also a table of the starting sectors of each VOBU: the VTS_VOBU_ADMAP (and the VTSM_VOBU_ADMAP for the menus.)
It might make sense to implement two interfaces: One that works on a "real" DVD or mirror of one that knows about IFO and their original VOB file naming and a second interface that works on isolated VOB files disregarding the file naming conventions and not knowing any IFO stuff. So the second one would only be able to estimate the distance between two VOB ID's based on duration and size of a single VOBU and the PTM of the VOB ID that follows the previous one. Thus I would be able to jump back from a VOB ID somewhere near to its start and iterate until I get the last NAV pack of the previous VOB ID and the first NAV pack of the following VOB ID in core - really hard stuff!

BTW: Could vob_v_s_ptm (PTM of first video frame in first GOP of VOB) at offset 433 and vob_v_e_ptm (PTM of last video frame in last GOP of VOB) at offset 437 of the DSI NAV packet help me in any way?

Regards,
Konran

[r0lZ]

Well, deducing the number of frames from the duration is probably difficult. In slide shows, for example, the duration of a single frame is extended and has usually the same duration than the audio. Also, the short black cell used to skip to the end of the movie with the remote is usually made of a single frame, but due to requirements of the DVD-Video standard, its duration must be at least approx 1/2 second (12 frames in PAL; I'm not sure for NTSC.) I've already tried to compute the number of frames from the PGC durations stored in the IFOs, but due to those difficulties, I haven't been able to do it. I don't know if the PTMs in the VOB files must follow the same rules.

Since I'm not a specialist of the structure of the MPEG stream and VOB files, I leave your question about the PTMs to others, but given their descriptions, I suppose they can be useful.

BTW, if you adopt your idea of a double interface, imo the user should have the possibility to force your program to use the VOB-only method, even if the IFOs are available, as there are many DVDs with wrong cell durations or VOBU sectors (especially in the ARccOS/RipGuard protected cells.) It might be useful to use your program as a verifier. :)

[konran]

Hi r0lZ,
according to the difficulties you explained I prefer to implement the VOB-only method alone. So I'm independent of other files and as you say that unreliable situations exist with IFO's.
I know that there are always uncertainties in the MPEG world and these uncertainties cummulate the more files and dependencies are involved to analyze one single file. Calculating the frame count is only 100% sure if the whole MPEG stream is parsed, GOP time code is unreliable, a file may be broken, etc. So I have to live with some uncertainties and estimate the frame count from informations given as good as even possible...
BTW, if you adopt your idea of a double interface, imo the user should have the possibility to force your program to use the VOB-only method, even if the IFOs are available, as there are many DVDs with wrong cell durations or VOBU sectors (especially in the ARccOS/RipGuard protected cells.) It might be useful to use your program as a verifier. :)
I don't know if my program (a bitrate viewer that will be a functional variant of DVD-lab Pro's embedded nice but broken tool) can be a verifier for your needs ... you may try it when my tool is released ... it will be for free.

Also I don't know the requirements of the special stuff you mentioned like video stills or ending cells - what I know meanwhile is, that the only thing I have to determine usable informations on VOBs are timing informations and jump addresses. With timing informations and framerate codes I can calculate a frame count, jump addresses give only the possibility to read other NAV packs for further information but they don't deliver anything valuable duration information.

Unlikely I don't have VOB files for testing purposes that contain the specialities you mentioned (video stills and/or ending cells with 1/2 sec duration), so I don't know what my program will do with it. My first tests of calculations with some VOB files give interesting results: The PTM codes of the DSI packets (vob_v_s_ptm at packet offset 0x2c, vob_v_e_ptm at packet offset 0x30) and the PCI packets (vobu_s_ptm at packet offset 0x0c, vobu_e_ptm at packet offset 0x10) and the framerate code within the cell elapse time deliver exactly all things needed to calculate the duration of a single VOB file and the frame count associated. It works for some files tested last night - each of them have two VOB ID's spanning one VOB file. The calculated frame count was exactly the same as FFMpeg is able to read on full MPEG parsing afterwards.

So I'll add an estimation for jumping between VOB ID's if I have more than two VOB ID's spanning one VOB file and I hope it will be as fast as the rest I already have. My parsing time for a 1GB VOB file is about 0.2sec now.

Regards,
Konran

[r0lZ]

Good work!

BTW, you can certainly find easily some GOPs with still frames in any (preferably still) menu on a commercial DVD. Games and slideshows (with sound) are also good candidates.

Are you working with PAL streams? Don't forget that NTSC has the additional difficulty of the "drop frames". A real nightmare imo. Since I live in PAL land, I have never studied that question, but you can find valuable info on this forum.

I'm not sure your program can be used as a verifier, but if it reports any error it finds in a log (for example when a nav pack is corrupt) it will be valuable anyway. IMO, since there are plenty of errors and discrepancies in many VOBs, it is really necessary to verify carefully the validity of every pack you read. A warning in case of problem is obviously a good thing.

[konran]

BTW, you can certainly find easily some GOPs with still frames in any (preferably still) menu on a commercial DVD. Games and slideshows (with sound) are also good candidates.
Well, I don't use any games and I don't have DVD slideshows as well. The top level part of my interface handles anything below 11MB with a full frame reader, i.e. the whole file will be parsed and each frame header read is counted. So very often the first VOB file of a VTS will fit into this size limit and it reads all frames in there. That's done in less that 0.2 sec. Maybe I'll get a problem on multiangle VOB's, but I don't have any for testing purposes.
If possible it would be fine if you can provide a link on a test file that has some of these features (multiangle, video stills, last cell with longer duration than one frame) and that is larger than 11MB?!
Are you working with PAL streams? Don't forget that NTSC has the additional difficulty of the "drop frames".
Yes, I also live in the PAL's world and I was struggling with the drop frame flag in the beginning of my project - long before I was thinking even about VOB's. So the low level part that handles the GOP and picture headers really do handle the drop frame flag.
Now on the higher NAV pack level with VOB's I think it won't be a problem: the framerate bits only allow 25fps and 30fps - so NTSC duration does always map to 30fps (?! I think it couldn't be different using only 2 bits). The bitrate viewer counts the amount of frames passed by the decoder, not just the physical amount of frames. With drop frame flag set the decoder internally has to copy a frame which results in a lower bitrate summary and a higher frame count at the end.
I'm not sure your program can be used as a verifier, but if it reports any error it finds in a log (for example when a nav pack is corrupt) it will be valuable anyway. IMO, since there are plenty of errors and discrepancies in many VOBs, it is really necessary to verify carefully the validity of every pack you read. A warning in case of problem is obviously a good thing.
The debug version of my program displays tons of text messages while the release version doesn't. I don't think that I can use the final program directly as a verifier ... but it is all written in C++. Each MPEG, PES and VOB stream type has its own class and verification method. An exception is the slice block within the picture data. That is quite very low level and I don't check that deeply because it is hard bitwise work. That's a no-no.
I think that I could extend my interface easily with more functionality on the verification methods in the classes and implement a full file parser that steps into each MPEG header - maybe when I'm done with the bitrate viewer ;)

Regards,
Konran

[blutach]

@konran

Almost every commercial DVD has stills - even if only in the menu domain.

Regards

[konran]

Almost every commercial DVD has stills - even if only in the menu domain.
Yes - but in those cases I tried up to now they reside in the very small VOB files which I don't read with the NAV pack reading algorithm, I parse them directly and so I get each picture header.

Regards,
Konran

[Alex_ander]

If you want a slide show of this type for experimenting (still image sequence with audio), it can be quickly created by converting to still each cell in any movie at hand (with DVDRemake or VOBBlanker). The cells keep seamless attributes at this and are reduced to single GOP (like 12 frames) with single I-frame stored, the video length and file size are determined by audio track.
Such a track is often used in DVDA's video folder for compatibility with video only players or used as an extra title in a video DVD. It is also possible to have a seamlessly played hybrid type video (not all cells reduced to still+audio) in title domain.

[konran]

Thanks, I surely will do it and create a slideshow. Now first the priority is getting the standard stuff running. With that I have again a problem: If I have more than 2 VOB ID's spanning one VOB file I should estimate the jump sector size to go to the end of the current or start of the next VOB ID. Unfortunately there is lack of information to do that properly from a single NAV pack without reading much more subsequent NAV packs following the first.

As I understand it in the NAV PCI packet there is the relative length of the VOBU in sectors and the cell elapse time tells of about how long the current cell will be played. But the NAV pack doesn't tell how many VOBU's are made up for this cell. Is that correct?

[blutach]

Often times those cell elapsed times are inaccurate (especially after editing the DVD a bit - just do a cut in VobBlanker to see what I mean). Each navpack tells you where the next navpack is (VOBU end address relative) and you can easily parse them to find where the cell ends. But, no the navpack doesn't tell you how many VOBUs make up the cell, for that you need to parse them or look in the IFO files, referring to a combination of the C_ADT and VOBU_ADMAP tables.

Regards

[konran]

Fine, Les - that's good to know that there's no easy way to get the cell lengths without reading the IFO file. So, as I decided to code only the IFO independent version, I prepared the first attempt to iterate with a sector speed factor from the first and last VOBUs of a VOB file and jump between them to get all the different VOB ID's. It needs further testing but it works on an example with 3 VOB ID's spanning a 500MB file in 47ms. The timing summary gives the exact frame count. I'll see what happens with video stills later on after coding some more stuff for safety.

Regards, Konran

[blutach]

Remember that a PGC can be made up of lots of Vob IDs and / or VCIDs. The VOBs gives no indication of PGCs. So, if your BR viewer is to give the average BR of a PGC, it will, perforce, have to parse the IFOs to find out which cells actually make up the PGC in question (PGCITI table). Otherwise, the viewer will give the BR of the VOBs, which I guess is what you are trying to do.

http://www.digital-digest.com/~blutach/gl2.gif

Regards

[konran]

Otherwise, the viewer will give the BR of the VOBs, which I guess is what you are trying to do.
Yes, you're right with that. The bitrate viewer reads MPEG files, not superiour structures like PGC chains.

Nice graphic you posted :)

Regards, Konran

[konran]

Well, my interface now works fine with the standard video part of VOB's. The iteration algorithm seems to be sufficient. Where it not works is: video stills! I created a slide show with from 20 pictures, PAL 16:9, each one 5s long and one audio track of 300s. My interface gets a front NAV pack of VOB ID 1 and a difference value of 300s in GOP PTM start/end values and a framerate code of 25fps. The last NAV pack is also VOB ID 1, same duration of 300s and a SCR (system clock reference) of 10s. So the 300s are the length of the audio as it dominates the number of frames in this VOB. I think I can't handle a video still because none of the information given leads to an amount of 20 frames. I only can see that a so very different value of SCR compared to the VOB's duration will tell that this method is impossible. Am I right ... or is there some other advice?

Regards, Konran

[blutach]

Do you really care about the BR of a still?

Regards

[konran]

No, but I should know at least that it is a slide-show, still or such-some to avoid offering preview values for the viewer. The frame reader afterwards finds the correct amount of frames of 20 (for this example) and the preview scales its window for 300 frames. On a VOB size that is only about 50MB like this one it doesn't really matter because the preview is updated so fast with the final view - so it can't be merely seen. If it would be a slide-show of some hundred MB's one would see a jumpy rescaling of the output.

If I know that it is a slide-show before displaying it I wouldn't supply a frame count estimation - therefore the interface makes a guess from the file size ... and should scale to something like 20 frames or a value in the same decade.

Regards, Konran

[konran]

Hello again, it takes a certain amount of time to go on in my project because I'm active in my leisure time only ... but now most of things for VOB analysis are stable and done. One open question remains for the moment:

The DSI packet delivers valuable information to determine if a VOBU has audio packets and or subpicture packets. From SRI array offset values I can distinguish between a normal video sequence and a slide-show because the latter one has less VOBU's with video than the full amount of VOBU's for a cell. But I don't see anything that tells me if the current VOBU I'm working on even has video itself. The preceeding VOBU and/or the following VOBU if exist would tell it if the referenced VOBU has video.

Is it possible to get the video status for the current VOBU directly?

Also remaining is work on multi-angle material because I don't have any test sources with more than the default angle. For the moment I'm not sure what will happen if I feed my interface or the ffmpeg frame reader with VOB files that contain interleaved VOBU packets, i.e. with ILVU offset pointers filled in the DSI packets. It could be possible that the frame reader counts all frames that are interleaved within all angles in there. So for now I would predict that I don't support multiangle.

Any idea for test sources with multi-angle movies?

The rest of my VOB-only method works fine and fast - a combination of estimation for long-distance jumps and iterative jumps with the +/- 0.5 ... 120 seconds SRI intra-cell pointers. That works really nice.

Regards, Konran

[blutach]

But I don't see anything that tells me if the current VOBU I'm working on even has video itself.
Eh? Each VOBU starts with a navpack and an I frame.

As a good test disk for multi-angle, you could try The Simpsons Movie. IIRC, the main movie has 3 angles.

Regards

[r0lZ]

Eh? Each VOBU starts with a navpack and an I frame.
I disagree. A slideshow with audio can have many nav packs followed by audio packs only. IMO, only the first VOBU of a cell must have video packs.
I don't know if you can know if there are video packs by analyzing the nav pack only.

[konran]

Eh? Each VOBU starts with a navpack and an I frame.
Ehm, I can't commit that. I compiled a slide-show with DVD-lab PRO with 20 still frames, each one 15 seconds long and an audio track of 300 seconds. My normative scan reads the first 11MiB of a file and the last 11 MiB. Scanning the front tells me in the first NAV pack that there is one or more video frames and the DSI pointer of the next VOBU is valid, the DSI pointer of the next VOBU with video is 0xbfffffff so that the first cell has one VOBU with video and subsequent VOBU's with audio only.

For the ending buffer I'm scanning for start codes 0x000001b3 (sequence header), 0x000001b8 (GOP header) and the video stream code I've found during the front scan which was 0x000001e0. I found neither within the last 11MiB but I watched out for and saved two blocks with 0x000001bf (the last NAV pack). This one has a DSI pointer of preceeding VOBU and VOBU with video which are both the same and point backward anywhere in the last cell. But the last VOBU indeed doesn't have video because there is no block with a startcode of 0x000001e0.
As a good test disk for multi-angle, you could try The Simpsons Movie. IIRC, the main movie has 3 angles.
Hmm, OK ... but I'm not a fan of the Simpsons, therefore I wouldn't buy that one. Any other suggestions for action movies, mystery, SCI FI or nature that accomplish multi-angle?

Regards, Konran

PS: Oops, r0lZ - you were a bit faster than me ;-)

[r0lZ]

Snow White (at least the french edition.) But it's not really sci fi or nature! ;)
Verify the law in your country, but for testing purposes only, it is usually accepted to rent the DVD.

(BTW, have you seen my previous reply? I agree with you.)

[blutach]

Ach! Of course. A slideshow/stills can start with a video frame and then just add navpacks up to the allotted time. Now, where's that I'm with stupid emoticon? :)

Here it is! :stupid: :stupid:

Regards

[Alex_ander]

I compiled a slide-show with DVD-lab PRO with 20 still frames, each one 15 seconds long and an audio track of 300 seconds.
Did you use 'slide show' mode or 'audio title' mode of DVDLab?
In first case it produces full GOP encoding (for better compatibility, as announced for new versions), the second option gives video with MPEG stills.

[mpucoder]

Is it possible to get the video status for the current VOBU directly?

Yes, look at vobu_1stref_ea (offset 0x413-0x416), this points to the first reference frame (ie the I frame of the GOP) and is zero if there is no video.
If the VOBU contains video its duration can be determined by looking at vobu_se_e_ptm (offset 0x041-0x044), if this is zero the duration is vobu_e_ptm - vobu_s_ptm (offsets 0x03d-0x040 and 0x039-0x03c respectively, the VOBU presentation duration). If non-zero the actual video duration is vobu_se_e_ptm - vobu_s_ptm (the remainder of the VOBU is virtual frames).

As I believe you noted, the SRI pointers can tell you where the next/previous video VOBU is.

Also you can look at vob_v_s_ptm and vob_v_e_ptm (offsets 0x433-0x436 and 0x437-0x43a respectively) to determine the run time (not necessarily the video duration) of any VOB.

[konran]

Great answers, thanks to all :) :thanks:
Snow White (at least the french edition.)
Ok, I'll give it a try if I get it here - french will be fine.
(BTW, have you seen my previous reply? I agree with you.)
Yes, well :cool:
Did you use 'slide show' mode or 'audio title' mode of DVDLab?
I suppose it's the 'slide show' mode ... I'm using DLP 2.5beta and just clicked the slide show wizard. I even don't know the 'audio title' mode you mentioned - but as you say its result would give me an additional - whenever strange - video format that could cause hickups in my program if I don't track it...
Yes, look at vobu_1stref_ea (offset 0x413-0x416), this points to the first reference frame (ie the I frame of the GOP) and is zero if there is no video.
Wow, thanks for clarification! I was asking myself almost infinit times what this one is about - using it will surely make my interface more stable.
If the VOBU contains video its duration can be determined by looking at vobu_se_e_ptm (offset 0x041-0x044), if this is zero the duration is vobu_e_ptm - vobu_s_ptm (offsets 0x03d-0x040 and 0x039-0x03c respectively, the VOBU presentation duration). If non-zero the actual video duration is vobu_se_e_ptm - vobu_s_ptm (the remainder of the VOBU is virtual frames).
Up to now I've used the green ones as I didn't see any sense of the red one. Fine, I'll add the red one.
Also you can look at vob_v_s_ptm and vob_v_e_ptm (offsets 0x433-0x436 and 0x437-0x43a respectively) to determine the run time (not necessarily the video duration) of any VOB.
Here the green ones also work fine - when the VOB file of interest has only one VOB ID. If there are spanning VOB ID's in the file it is a combination of the values mentioned above, depending on the amount of VOB ID's spanning the whole file.

Regards, Konran

[blutach]

Yes, look at vobu_1stref_ea (offset 0x413-0x416), this points to the first reference frame (ie the I frame of the GOP) and is zero if there is no video.
If the VOBU contains video its duration can be determined by looking at vobu_se_e_ptm (offset 0x041-0x044), if this is zero the duration is vobu_e_ptm - vobu_s_ptm (offsets 0x03d-0x040 and 0x039-0x03c respectively, the VOBU presentation duration). If non-zero the actual video duration is vobu_se_e_ptm - vobu_s_ptm (the remainder of the VOBU is virtual frames).

Also you can look at vob_v_s_ptm and vob_v_e_ptm (offsets 0x433-0x436 and 0x437-0x43a respectively) to determine the run time (not necessarily the video duration) of any VOB@mpucoder

A couple of questions re the bits I have bolded:

#1. I made a 3 second blank with muxman (see enclosed VOB) and vobu_se_e_ptm - vobu_s_ptm of the first navpack is 0 (and vobu_e_ptm > vobu_se_e_ptm). Is this correct?

#2. I guess you mean GOP, right?

Regards

[konran]

#2. I guess you mean GOP, right?

No, with VOB mpucoder is right ... the difference of vob_v_e_ptm and vob_v_s_ptm delivers the runtime of the complete VOB ID and it can be found in any VOBU - as far as I've read them - and there were many.

Regards, Konran

[blutach]

Yes, I see now. I should have looked at my own example more closely :)

Thanks for that.

Regards

[konran]

Again many thanks for this explanation :thanks: :
Yes, look at vobu_1stref_ea (offset 0x413-0x416), this points to the first reference frame (ie the I frame of the GOP) and is zero if there is no video.
If the VOBU contains video its duration can be determined by looking at vobu_se_e_ptm (offset 0x041-0x044), if this is zero the duration is vobu_e_ptm - vobu_s_ptm (offsets 0x03d-0x040 and 0x039-0x03c respectively, the VOBU presentation duration). If non-zero the actual video duration is vobu_se_e_ptm - vobu_s_ptm (the remainder of the VOBU is virtual frames).
... and my feedback on it:

1.) vobu_1stref_ea always gives me an idea of correctness in my iteration if I've found a VOBU with video I can deal with.

2.) Taking care of vobu_se_e_ptm and using this one or vobu_e_ptm in the right place leads to exact VOBU runtime values. This works also for slide-shows. I've done a cross-check with a slide-show and post-processed it to validate, if all this is correct. In fact I get a first VOBU with video for each cell and a certain amount of VOBU's w'out video following. SRI pointer arrays allow me jumping very fast to the next cell. When I collect the runtimes of each VOBU with video found I get 20 * 40ms and have exactly my 20 frames of the slide-show. Even if it is not necessary to show the bitrate of a slide-show it is good to know that processing such a file this way really goes very fast.

So I think I'm done with VOB file now ... unless I don't detect things during tests that should not have happened.

Regards, Konran