VTS_TMAP and Time Unit: format?

[r0lZ]

I'm currently writing a function to regenerate the VTS_TMAPTI table, but I'm a little bit confused.

How can I compute the Time Unit to use for a specific PGC?
I understand that the table can be very large if the Time Unit is 1 second, but since the number of entries is coded on 2 bytes, it is theoretically possible to have 65535 entries, and that's sufficient for more than 18 hours! So, why is it needed to use a Time Unit > 1 sec? Is it a limitation to the length of the VTS_TMAP tables?
In the examples that I have analysed, the number of entries is always less than +- 1500.

Also, when exactly do I have to set the discontinuity bit? Seems it is always set on the last entry of each cell. But, on mpucoder's site, I read "if VOBU time codes are discontinuous with previous." Is it really "previous", or "next"?

And I need another confirmation: there is one time map per PGC. In a non-sequential title made of several PGCs, there are several tables (one per PGC). Right?
For a dummy PGC, I have to create a table with 0 entries, and a Time Unit > 0. Right again?

Thanks in advance!

[mpucoder]

How can I compute the Time Unit to use for a specific PGC?
I understand that the table can be very large if the Time Unit is 1 second, but since the number of entries is coded on 2 bytes, it is theoretically possible to have 65535 entries, and that's sufficient for more than 18 hours! So, why is it needed to use a Time Unit > 1 sec? Is it a limitation to the length of the VTS_TMAP tables?
In the examples that I have analysed, the number of entries is always less than +- 1500.
The limit is 2048 entries, so
time_unit = max( ((time_in_seconds+2047)/2048), 1); //seconds per entry
and the number of entires is time_in_seconds / time_unit
Also, when exactly do I have to set the discontinuity bit? Seems it is always set on the last entry of each cell. But, on mpucoder's site, I read "if VOBU time codes are discontinuous with previous." Is it really "previous", or "next"? We had a long discussion about this elsewhere, the conclusion was that no one is sure when to set it, or that it matters.
And I need another confirmation: there is one time map per PGC. In a non-sequential title made of several PGCs, there are several tables (one per PGC). Right?
For a dummy PGC, I have to create a table with 0 entries, and a Time Unit > 0. Right again? Every PGC needs a table, PGC's that are not one_sequential (dummies, multiple PGC titles, random, shuffle) have a table with 0 entries and 0 time_unit

[r0lZ]

A million thanks, mpucoder!

[Grave]

would it be possible to create tmapti also for nonsequential/multipgc? (force recreating tmapti)
i often see dvds with trailers/extras put all in one title and without tmap its impossible to just seek into middle of trailer for example:

VTST 2, 1 TTN1 (1:33:58) Title 4 (has tmap entries)
VTST 2, 2 TTN2 (1:27) Title 5 (has tmap entries)
VTST 2, 3 TTN2 (1:29) (0 tmap entries)
VTST 2, 4 TTN2 (1:33) (0 tmap entries)
VTST 2, 5 TTN2 (1:15) (0 tmap entries)
VTST 2, 6 TTN3 (0:30) Title 6 (has tmap entries)

[r0lZ]

Well, currently, I need a function to rebuild a valid TMAP after a PGC has been modified (cells deleted or added.) If I can find a suitable TMAP for all cells in the IFOs, I'll use it. If the TMAP is missing, or has too few entries, I will need to recreate it from scratch, by looking in the VOBs. This will be a relatively long process, so, I try to avoid it whenever possible.

Anyway, I plan to add also a function to rebuild the TMAPs of all Titles of the current domain, or of the whole DVD. This function will probably never be called automatically, but you will be able to call it yourself if you need it.

[mpucoder]

You could create the time maps for such PGCs, but no compliant player will use them. There are reasons why there is no map -
random/shuffle - these guys exist outside our concept of linear time
multi-pgc - this would require the player to search all the time maps in the order used by the title to locate a particular time relative to the start of the title. This was considered too complicated at the time the specs were drawn up, hence time maps work only relative to one pgc, not one title.

[r0lZ]

Yes, I know that. Anyway, if a time map exists for a non-sequential PGC, it will not hurt. Most players will simply ignore the time map, but will not crash. Right?

And I think the PGCs w/o time map reported by Grave are sequential titles, but probably with some PUOs to prohibit skipping them. Removing the PUOs and building a time map should be sufficient to convert them to regular titles.

[r0lZ]

Another question. In a multi-angle PGC, which cell should I use for the time map? The first angle cell?

[bigotti5]

Scenarist uses VOBUs only from first angle in TMAPT table

[mpucoder]

Yes, only the first angle gets referenced.

[r0lZ]

Thanks!

[r0lZ]

Yet another question.
Is it necessary, prohibited or allowed to include the very first nav pack of a PGC in the time map?
For example, for PGC 1, if the first cell is the first cell in the VOB file, do I have to include a first entry with LBA 0?
I see that sometimes in commercial DVDs, but not always. I'm puzzled!

[mpucoder]

The first entry is time_unit seconds into the movie (no need to search a table for time 0). LBA 0 would qualify only if it is a slideshow and the duration of the vobu is long enough (look at vobu_e_ptm - vobu_s_ptm of those DVDs) For example if the time unit is 1 and the duration is at least 90000 then LBA 0 would be the correct vobu for 00:00:01:00 You can also use cell elapsed time, but with NTSC that gets problematic. According to the Philips verifier the non-drop timecode used by cell elapsed time is NOT the basis of a time map, but ptm is, and one second is always 90000 (for this purpose, and according to them).

[r0lZ]

OK, thanks again.

Of course, I have used the cell elapsed time! :( Luckily, it's easy to change.
I used the cell elapsed time because I though it was easier, since there is little difference between NTSC and PAL. But if one second is always 90000 ticks, it's even simpler!

And what about a PGC with only one still frame without audio? In this case, I've seen one entry in the table, with, of course, the first and only nav pack of the cell. Is it right? Anyway, I suppose the time map is useless in this case.

And do I have to take into account the cell still times? I suppose (and hope) not!

Also, in ARccOS protected titles, there are often some cells in the PGC with bad or empty nav pack, or no nav packs at all. Though this is of course illegal, what is the best way to handle these cells? Can I repeat the same entry several time to fill the cell time (taken from the PGC cell table)?

[mpucoder]

No, cell still time is not considered. The other cases are a crap shoot. A single frame still in Muxman produces a table with no entries (I'll run that by the verifier later).
What does an Arccos protected disk with such bad structure have for a time map?

[r0lZ]

OK, I have modified my code to use the PTM values instead of the cell elapsed times. Also, the first entry is removed if vobu_e_ptm - vobu_s_ptm < 90000 * time unit, and if the PGC time is greater than time unit. (Currently, I leave at least one entry for a non-dummy PGC. Let me know if it's not the right way, but it's what I see in several examples.)

But the slideshow cells are more complicated that I though. How should I handle the cells that are in the middle of the PGC? When vobu_e_ptm - vobu_s_ptm > time unit, should I include the same nav pack several times in the table? Seems logical, or the table will have too few entries.

I am currently ripping the only ARccOS protected DVD I have. I'll report how the time map looks later...

[mpucoder]

A vobu can be listed more than once, but with a maximum duration of 1.2 seconds there should not be a third entry.
The rule for which vobu to list is simple once you have the time in clock ticks (time = (entry_number + 1) * time_unit * 90000) List the vobu if vobu_s_ptm <= time < vobu_e_ptm
Note that itis < not <= vobu_e_ptm. If the time is == vobu_e_ptm then it will be the next vobu, as its vobu_s_ptm will equal time.

[r0lZ]

OK, thanks.

For the ARccOS protected PGCs, I see a time map covering the bad sectors, exactly as if they were legal and readable. However, the cell times of those cells in the IFOs are often completely wrong, and are even often 0:00:00.0! But there are also other "errors" in the cell table. Sometimes, several cells have the same VOB/Cell IDs, but with different VOBU sectors! :eek:
IMO, the best way to get rid of this crap is to remove the protected cells completely, and rebuild the time map from scratch. But that's the job of the ripper.
Anyway, my function will fail when a blank nav pack will be encountered. Those protections are really a nightmare! :scared:

[r0lZ]

List the vobu if vobu_s_ptm <= time < vobu_e_ptm
That's easy, but the VOBU will be listed only if its start time is less or equal to the current time. I though it was necessary to select the closest VOBU, which is not always the previous one. Anyway, this little error cannot be really harmless.

[mpucoder]

Yeah, I have the advantage of working with correct data.
I just checked with the verifier, and it is an error to have the time unit non-zero if there are no entries (this was what I meant by a "table with no entries"). So I'll be changing my code a little to not produce the table if the PGC elapsed time is less than one second. This also eliminates the max function to ensure a non-zero time unit if there is a table.

[r0lZ]

Can you clarify? This means that a PGC with only a still frame (w/o audio) cannot have a time map?

Yeah, I have the advantage of working with correct data.Yes, for me, the good old days are over! Now, it is necessary to assume that a DVD structure can contain virtually anything! Pitty! :(

[mpucoder]

I made a single frame still with no audio, so the total duration was 12 frames. This is too short for a map - there is no entry for time 00:00:01:00, so for this case there should be no map.
However, this was the only cell in the PGC. The elapsed time of previous cells does get taken into account. So if you have 3 cells like this, the third would finally make the PGC long enough for a map.

[r0lZ]

Yes, I understand that.

BTW, what is the best method to know the exact duration of a cell? I can't trust the cell time in the IFOs, so, should I look at the last VOBU's vobu_e_ptm?

[mpucoder]

I need to further clarify - this was an NTSC still, so MuxMan set the duration to 15 frames (not 12 - that is the PAL value). Also in NTSC it takes only 2 cells like this to get a table entry as the second cell starts at 45045 and ends at 90090 (relative to vob_s_ptm), which qualifies it as the first entry.

I found the trickiest part of this was accounting for shared vobs. For example PGC_1 uses vobs 1 and 3, while PGC_2 uses vobs 2 and 3. Now imagine vob 1 is 2.0 seconds long, while vob 2 is 2.5 seconds long. The indexing of vob 3 will be totally different for the two PGCs.

[blutach]

The limit is 2048 entries, so
time_unit = max( ((time_in_seconds+2047)/2048), 1); //seconds per entry
and the number of entires is time_in_seconds / time_unit@mpucoder

After finding out the number by applying MAX, I think you need to apply the INT function as well.

So a 2 hour PGC would work as follows:

(MAX((2*3600+2047)/2048,1)=MAX(4.5151,1)=4.5151
INT(4.5151)=4 = time unit in seconds

Regards

[mpucoder]

MuxMan uses no floating point values at all (not even in the FDCT/IDCT), there is no need, so all operations are with integers, and result in integers.
As a result I don't think to say "integer divide".

[bigotti5]

@r0lz

more about time maps, discontinuity entrys and so on you can find at

http://freepatentsonline.com/6108281.html
respectively
http://freepatentsonline.com/6108281.pdf

....The discontinuity flag 201 is one-bit data (bit b31), which indicates, by use of the value "0" or "1", whether or not the VOBU having the head address indicated by the time unit address #n and the next VOBU having the head address indicated by the next time unit address #n+1 are included in the same cell. Namely, the flag is set up (with bit value "1") if there is discontinuity of the cell between the current time unit address and the next time unit address.....

[r0lZ]

Thanks for the info! Those patent are not easy to read, though! :( Anyway, in all examples I have analysed, the discoutinuity flag is set according to your quote: just before a cell change.


I still need to understand something.
The first nav pack of a cell has usually a vobu_s_ptm between 20000 and 35000. However, its cell elapsed time is normally 0. Should I take this first vobu_s_ptm delay into account when building the time map? In other words, should I assume that the first cell of the PGC starts at time 0, or at the time specified by vobu_s_ptm in its first VOBU?

And, when there are several cells in the PGC, how do I compute the correct start time of the first VOBU of the next cell? I suppose it's the (computed) elapsed time of the previous VOBU plus its vobu_e_ptm. But Should I add also the vobu_s_ptm of the first nav pack of the new cell?

[mpucoder]

Thanks Bigotti5! I think I already have a copy of that patent but never made it all the way through without falling asleep. edit: It was a different one which some of you might want to read - us patent 6553180
r0lZ - this is the video, or multiplex, delay - the cause of many demux timing problems (at least 2 discussions about it in subtiles forum).
Here's one way to handle it via a variable we will call "delta" which is added to either vobu_s_ptm or vobu_e_ptm when making comparisons to the target time:
For the first cell set delta to the negative of vobu_s_ptm.
For every new cell add vobu_e_ptm of the previous vobu, and subtract vobu_s_ptm of the new vobu. If the cells are contiguous this will do nothing, but if there is a skipped cell or a clock reset this will account for it.
In MuxMan only vobu_e_ptm is checked against the target time, in a while loop which creates one entry each iteration and increments the target by 90000*time_unit. Surrounding that loop is a bunch of while loops that walk the navigation.

edited to revise the logic.

[r0lZ]

Yes, I've figured it myself! Thanks anyway.

Currently, I've tested my function with several time maps, and I have exactly the same result... except that sometimes, I have one additional entry at the end of the PGC. Seems this problem occur only when the last cell is a tiny black cell of one second or so, and when there is a cell command on the previous cell. Apparently, this cell is not included in the original time map. I think it will not hurt to leave the additional entry. Anyway, my computations are right. :)

Last thing to do: I have to cope with the missing nav packs of ARccOS DVDs. I still don't know how to handle this case... :(

[mpucoder]

I wish I'd gotten bigotti's information a day earlier as I just released a new version. Anyway, bigotti, check your limits at mpucoder.com - it's a tradition (when someone provides new information).

[bigotti5]

@mpucoder

thx for lifetime access

Here is a list of us-patents referring to DVD-Video
maybe helpfull

5097349 Mixture ratio of main picture and sub-picture
4953035 Address of sub-picture information
5315400 Selection of subtitle
5043826 Sub-picture corresponding to main picture
5063551 Run length limited code
5016113 Form of sub-picture
5065252 Mixture of main picture and sub-picture
5336844 Presentation Data
6463210 Aspect ratio
5679911 Selection by classification information
5895876 Selection by classification information
5466883 Selection of subchannel
5740152 Structure of SYNC Codes
5608715 Multi layer
5886965 Cell contents
5892983 Time map
6085267 Time map
5758008 Cell elapse time
5636186 Audio channel contents
5787222 Interactive reproduction
6160951 Interactive reproduction
5987066 Digital data transmitting
5917857 Digital modulation
6215952 User operation restriction
6085021 Access restriction flag
6157769 DSI Still, Cell Still
6501903 Cell Still
6006004 DSI , PCI separation
6396997 Highlight information
6148138 Control by NAV pack
6212330 VOB unit search information
6137954 VOB unit search information
5933569 Parental ID
6122434 Parental ID
6031962 VOB ID, Cell ID
5889746 Text information
6091674 Time search map
6108281 Time search map
6088506 Highlight PTS
6266478 Highlight information
5966352 Seamless agle change flag
5936925 Audio frame alignment
6034942 Audio frame alignment
6108486 Audio frame number
6104684 Attribute information
5742569 Cell contents information
5805537 First access unit pointer
6014495 24 bit data alignment
6236804 Minimum readout rate
5960152 Audio frame structure
5721591 Interleaved unit size for seamless play
5966182 Interleaved unit size for seamless play
5793726 Random reproduction mode
5748256 Color control of subtitle
5889564 Position-information for displaying subtitle
5455684 Data search information entry point
5568274 Data search information entry point
6816667Determining run times of DVD titles

DVD-Video – AC3,DTS,MPEG Audio

6694030 Muting when switching Audio Bit Streams IEC958
5214678 Digital transmission using subband coding
5481643 Matrixing of bitrate reduced sgnals
5323396 Universal subband coder format
5777992 Universal subband coder format
5539829 Universal subband coder format
5530655 Universal subband coder format
6289308 Universal subband coder format
6691086 Universal subband coder format
5610985 Three channel transmission of L, R and C
5544247 SB splitting prior to multiplexing L, R, C
5818943 SB splitting prior to multiplexing L, R, C
5850456 7-channel backwards compatible encoding
5878080 N channel compatible with 2- and 1- channel



and the most important

7043142 Digital video system

Time map information TMAPI is used upon executing special playback (e.g., cell playback in the order unique to each user using user defined PGC) and time search.
Time map information TMAPI includes time map generation information TMAP—GI, one or more time entries TM—ENT#L to TM—ENT#r, and one or more VOBU entries VOBU—ENT#1 to VOBU—ENT#q.
Each VOBU entry contains information of the size and playback time of VOBU. The VOBU size is presented in units of sectors (2 kbytes), and the playback time is presented in units of video fields (one field= 1/60 sec in NTSC; one field= 1/50 sec in PAL).
Since the VOBU size is presented in units of sectors, as described above, VOBU can be accessed using addresses in units of sectors.
Each VOBU entry includes reference picture size information 1STREF—SZ, VOBU playback time information VOBU—PB—TM, and VOBU size information VOBU—SZ.
Note that VOBU—PB—TM represents the playback time of VOBU of interest in units of video fields. On the other hand, reference picture size information ISTREF—SZ represents the size of the first reference picture (corresponding to I-picture in MPEG) of VOBU of interest in units of sectors.
On the other hand, each time entry contains address information (VOBU—ADR) of the corresponding VOBU, and time difference information (TM—DIFF). This time difference information indicates the difference between the playback time designated by the time entry and the VOBU presentation start time.
Assuming that the time interval (time unit TMU) between two successive time entries is 10 sec, this time entry interval corresponds to 600 fields in, e.g., NTSC video.
Normally, the "time interval between neighboring VOBUs" is expressed by the number of fields in the VOBU entry. As another method, "count value from a given VOBU to the next VOBU by a clock counter" may be used to express the "time interval between neighboring VOBUS".
For example, the "time interval between neighboring VOBUs" can be expressed by the "difference value between the value of presentation time stamp at the start position of one VOBU and the value of PTS at the start position of the immediately succeeding VOBU".
In other words, "the time interval in a specific unit can be expressed by the difference value of the clock counter in that unit".
Time map generation information TMAP—GI shown in FIG. 25 includes TM—ENT—Ns indicating the number of time entries in that time map information, VOBU—ENT—Ns indicating the number of VOBU entries in that time map information, time offset TM—OSF for that time map information, and address offset ADR—OFS of that time map information.
When a value (10 seconds or equivalent) corresponding to 600 fields in NTSC video (or 500 fields in PAL video) is used as time unit TMU, time offset TM—OSF is used to represent the time offset within TMU.
When the VOBU size is expressed by the number of sectors, address offset ADR—OFS is used to indicate a file pointer from the beginning of an AV file.
Time entry TM—ENT shown in FIG. 25 includes VOBU—ENTN indicating the number of the corresponding VOBU entry, TM—DIFF indicating the time difference between the playback time of VOBU designated by the time entry, and the calculated playback time, and VOBU—ADR indicating the target VOBU address.
When time unit TMU is expressed by 600 fields in NTSC (or when time unit TMU is expressed by 500 fields in PAL), the "calculated playback time" with respect to time entry #j is given by TMU×(j-1)+TM—OSF.
On the other hand, VOBU—ADR indicates the target VOBU address by the total size of VOBUs preceding VOBU of interest when the VOBU size is expressed in units of sectors.
In the aforementioned data structure, in order to start playback from the middle of certain VOBU, that access point must be determined. This access point is assumed to be a time entry point.
This time entry point is located at a position separated from the position indicated by movie address information of VOBU by the time difference indicated by time difference information TM—DIFF in time entry TM—ENT. This time entry point serves as a special presentation start point (or time search point) indicated by time map information TMAPI.

[neuron2]

Anyway, bigotti, check your limits at mpucoder.com Can I get that too? :)

[mpucoder]

One of the dangers of reading patents is that not all are depicting what was adopted as the DVD-Video specification. Even the one I mentioned is actually for DVR, but contains some information relevant to DVD-Video in general. Using 60 fields as one second will get you many errors with the Philips verifier, as whoever wrote it interpretted the spec to mean that one second is 90000 ticks of the clock. I don't think it makes any difference, but I changed MuxMan to comply with the verifier and thereby satisfy those who use it as an indicator of compliance.

@neuron2 - you have always had lifetime membership. If there is something else you are requesting, please PM me.

[blutach]

Can I get that too? :)I think you need to support the Red Sox and the Pates Don!

Regards

[neuron2]

please PM me Did you perhaps miss my PM? Thank you.