Some questions on One_Sequential_PGC_Title PGCs

[jsoto]

I'm working on TMAPTI creation from scratch, and I have some doubts on One_Sequential_PGC_Title PGCs.

These kind of PGCs are the only ones allowed to have entries in TMAPTI, so the question is..

How to detect if a PGC is One_Sequential_PGC_Title without trusting the TT_SRPT table flag in VIDEO_TS.IFO?

In fact, I have a lot of questions...
a) After verifying the PGC playback mode is sequential, and there is no still time, is it enough to check if this is the only one PGC in the Title or do you need to check the NextPGC/PrevPGC pointers too? (like WinDVD does)

b) So, is is legit that NextPGC/PrevPGC pointers point to a PGC belonging to other Title in the same VTS or do they have to point to a PGC of the same title?

c) Could be more than one entry PGC in a group of PGCs of the same Title?

d) Talking about PGCs belonging to the same Title, have they to be linked using NextPGC/PrevPGC pointers or it is optional?

I've done some tests in PowerDVD and WinDVD
Both of them trust the TT_SRPT table flag in VIDEO_TS.IFO, but WinDVD also checks the NextPGC/PrevPGC pointers (and there is a known bug in this check).
None of both checks if there are more than one PGC in the Title. In a multi-PGC title, hacking the one_sequential_PGC flag in titles table of VIDEO_TS.IFO, and creating the TMAPTI table entries, both players allow to navigate using the seekbar!!.

jsoto

PS: What do you think about a checkbox to allow VobBlanker to create TMAPTI entries even in PGCs non one_Sequential_PGC_Title PGCs?

[mpucoder]

There can be dummy PGCs in a title. They will have the same title number, be non-entry, and not linked - they do not matter to this. Only one PGC can be marked as the entry PGC for each title, and it is one-sequential if:
sequential
no still time
no links (prev or next) to another PGC
That last check needs to be "to another PGC", as there are a lot of titles with next pointing to the same PGC, even though the spec is not clear on whether this is allowed. And although it doesn't matter to this check, prev and next must not point to PGCs of another title.

[r0lZ]

PS: What do you think about a checkbox to allow VobBlanker to create TMAPTI entries even in PGCs non one_Sequential_PGC_Title PGCs?The PgcEdit's Rebuild Time Map Tables function builds a table for not one_sequential titles as well. I guess it's not a problem. Compliant players will not use it, and that's all.

[jsoto]

@mpucoder,
Many thanks for the clarifications. As usual, you know all the answers...

@r0lZ
OK, I'm going to create a TMAPT table for all PGCs, even the not one_sequential ones. Probably I'll add a note in the Log to point out this...

I'm also going to do a check to warn the user if a non one_seq PGC can be changed to a true one_seq (to allow the goto functions like the seekbar).

jsoto

[bigotti5]

PS: What do you think about a checkbox to allow VobBlanker to create TMAPTI entries even in PGCs non one_Sequential_PGC_Title PGCs?

Maestro for example creates TMAPT tables for not_one_seq titles too, so it should not be a problem at all.

That last check needs to be "to another PGC", as there are a lot of titles with next pointing to the same PGC, even though the spec is not clear on whether this is allowed.

All verifiers states Next/Prev pointers have to be 0 in a one_seq_title, one states a Next/Prev pointer must not point to itself (Specification Page Number:VI4-203)

[jsoto]

(Specification Page Number:VI4-203)
@bigotti5
Which specs are you refering to?

One more question, not related with One_seq_title PGCs, but with TMAPTI table

Is there any limitation/restriction in the number of entries in a TMPAT table? When the number of seconds has to be increased to reduce the number of entries?
I'm currently using 3600 as the maximum number of entries, so
num_secs=duration_in_secs/3600+1;

jsoto

[spyhawk]

I think maximum number of entries per title is 2048 in TMAPI table. Someone with the specs verify that please.

[blutach]

That's true - it has been verified by mpucoder - see here (http://forum.doom9.org/showthread.php?p=830448#post830448).

Regards

[bigotti5]

Which specs are you refering to?

Verifier comments the error messages with spec pages, in case of Next/Prev pointers to itself with DVD Spec Page Number:VI4-203

[r0lZ]

I'm also going to do a check to warn the user if a non one_seq PGC can be changed to a true one_seq (to allow the goto functions like the seekbar).Excellent idea. I'll add that in PgcEdit too! ;)

[r0lZ]

Speaking of non-one_sequential titles, I wonder if this flag must be ON for titles with the Random or Shuffle flags ON in the PGC. I suppose that a random or shuffle title does not use the time map anyway, but again I'm not sure.
Someone can clarify? :thanks:

[bigotti5]

Random or shuffle PGCs must be flagged as not_one_sequential
Byte 8 in TT_SRPT > 64
Random or shuffle PGCs can hold only one PTT assigned to the first PG

[r0lZ]

Thanks. I didn't know this One PTT limitation, too. Re-thanks!

[r0lZ]

Still some questions...

In IfoEdit, I see for the not one_sequential flag:not one_sequential (random, shuffle, stills, loops, or more than one pgc)It is easy to check the random, shuffle and more than one pgc conditions, but I don't know how to check easily for stills. And what's that "loops" stuff? :confused:

[jsoto]

That's true - it has been verified by mpucoder - see here (http://forum.doom9.org/showthread.php?p=830448#post830448).

Regards

Thanks, I knew mpucoder had answered this question to r0lZ before, but I was unable to find the post searching by TMAPTI... Now, I see, the trick is search for VTS_TMAPTI ;)

stills: I assume still time in PGC (byte 0xA3) equal to zero, but, may be, cell still time has to be checked in cells playback table too...

loops: No idea... I hope it is no related to VM commands...

jsoto

[blutach]

Still some questions...

In IfoEdit, I see for the not one_sequential flag:It is easy to check the random, shuffle and more than one pgc conditions, but I don't know how to check easily for stills. And what's that "loops" stuff? :confused:Could stills be PGCs within the title that have celltime set at 255 (ie BOV)?

Regards

[r0lZ]

Hum, I don't understand why a still time (either the global PGC still time or the cell still times) should have any influence on the way the time map is used. If, for example, a cell is an animated menu with BOVs and an infinite still time, it will be played normally until the end of the playback is reached. Why should it be impossible to seek in the cell before it has reached the "still phase"?

If loops are what Jsoto thinks at, it's again the same problem: it's not because a cell is repeated several times that it should be impossible to seek to a specific time when it is playing.

But it's perhaps again one of those stupid limitations in the DVD specs, without technical reasons.

BTW, I have added a function in PgcEdit to "fix" the not-one_sequential flags in the Title Play Map table. Currently, I check only the presence of several PGCs belonging to the same Title, and the random and shuffle play modes. In all other cases, I assume the flag can be cleared. If someone thinks it's not sufficient, please let me know...

[bigotti5]

stills: I assume still time in PGC (byte 0xA3) equal to zero, but, may be, cell still time has to be checked in cells playback table too...

I did some tests in scenarist

Cell with still time 5 -> title is one_seq and TMAPTI created
Cell with still time 255 -> title is one_seq and TMAPTI created
Cell with VOBU still (Byte 1 = 64) -> title is one_seq and TMAPTI created

PGC still is only possible in random or shuffle PGCs.

Any still time is ignored in TMAPTI entries (VOBU still is treated as a 13 frame video).

loops: No idea... I hope it is no related to VM commands...
VM commands does not affect at all.

As opposed to Interra verifier and my post#5 it is possible to set NextPGC (PrevPGC) to itself, this forces the player to loop the PGC (if there are no post or cell commands) and scenarist marks the PGC as not_one_seq.

[jsoto]

As opposed to Interra verifier and my post#5 it is possible to set NextPGC (PrevPGC) to itself, this forces the player to loop the PGC (if there are no post or cell commands) and scenarist marks the PGC as not_one_seq. And... in this case, does scenarist create the TMAPTI entries?
jsoto

[bigotti5]

And... in this case, does scenarist create the TMAPTI entries?

No - scenarist does not create TMAPTI tables for not_one_seq titles at all.

[r0lZ]

Thanks. That confirms what I thought.

IMHO, when the title is sequential but has Prev/NextPGCN links pointing to itself, it is probably safe to clear the not-sequential flag, as almost all players (except some software players) are perfectly happy with those conditions. Some players will refuse to seek to a specific time, but that doesn't hurt.

Also, IMO, although illegal, it should be possible to clear the not-one_sequential_title flag even when the Title is made of several PGCs and all PGCs except the entry PGC are dummies, or made of never played cells (due to pre-commands jumping elsewhere). My standalone players are able to use the time map successfully in those cases.

[jsoto]

although illegal, it should be possible to clear the not-one_sequential_title flag even when the Title is made of several PGCs and all PGCs except the entry PGC are dummies, If I understood well mpucoder (see 2nd post in this thread) this IS a one_seq_title PGC (if all others in the same title are dummies).
jsoto

[r0lZ]

Wonderful confirmation! Thanks!

[mpucoder]

Yes, that would be a one-sequential if the PGC is sequential. Thanks to Bigotti5 for a more concise explanation of "random, shuffle, stills, and loops". Often the material on my website assumes the reader has also read DVD Demystified, which uses the same wording.

[bigotti5]

Some more comments to shuffle, random and sequential titles.

Shuffle or random PGCs can hold only one PTT assigned to first PG.
Makes sense because PG playback is random/shuffle, so you would not be able to access a specified PTT.



All PGs in shuffle or random PGCs are to be non-seamless.
It is confirmed that in case of PGC whose PG Playback mode is with Random, or Shuffle, the first Cell of each PG, Seamless flag shall be 0.
The following is why it should be non-seamless connection.
The following is described in the last paragraph of Table M.1 in P. VIX-74 of Book Part 3. Seamless playback flag Current Cell is 0, and STC discontinuity flag of Current Cell is 1 in case that Current Cell is the first Cell of a PGC in any allocation.
The above interpretation is valid, since all the first Cell of each PG in PGC will be able to be played back as the first Cell of PGC with Random/Shuffle playback. (http://www.dvdforum.org/booksub/fvn007.htm)

Shuffle or random PGCs must not hold CallSS commands.
Maybe resume state in CallSS is not valid for random/shuffle PGCs.

From what I have read some players (e.g all Sony) would have problems even with jump commands in post command area of shuffle PGCs (cant test, have no sony), so you have to create multi-pgc titles and use linkPGC.


Older players cant handle random/shuffle PGCs with more than eight PGs.

this IS a one_seq_title PGC (if all others in the same title are dummies).Yes, that would be a one-sequential if the PGC is sequential.
Not sure about this (verifiers will complain about this).
Imho dummies does not make sense in titles, you cannot use title dummies to access any PGC in menu domain, resume cell cant be specified. Same with remote menu button, player cant store resume state.
CallSS Jumps directly to a specific program chain within....the current values of the navigation timer and all GPRM registers are left unchanged, and the Cell Number, first navigation pack address of the current Cell, PGC playback control status, Video Title Set Number, and SPRM registers 4-8 are also saved.

[r0lZ]

Thanks mpucoder and bigotti5!

My old Sony DVP-S725D accepts PTTs in random/shuffle PGCs, and display them correctly (of course not in increasing order) in its led display.
It hangs at the end of the last random PG. Maybe it's because the jump was a CallSS. I don't remember.
It can resume to the correct location, when the menu has been called with the remote.

BTW, I wonder if the resume cell specified in CallSS commands is a cell in the entry PGC of the title, or a cell in the last PGC played in multi-pgcs titles, when the CallSS is executed. In the first case, it should be possible to use dummies in Titles, as long as the first PGC is not a dummy. And it is impossible anyway to call a menu with the remote when a dummy is executed, as there is not enough time to activate the remote.

My Sony has probably a bug, as the first PG it plays in random or shuffle mode is always the first PG of the PGC.

I don't know much more, as random/shuffle titles are very rare in commercial DVDs.

[bigotti5]

I wonder if the resume cell specified in CallSS commands is a cell in the entry PGC of the title, or a cell in the last PGC played in multi-pgcs titles, when the CallSS is executed

Cant beleive...you must not forgot that SPRM6 (PGC# in title) is stored too to resume correct cell in title....

[r0lZ]

Yes, but that's when the resume point is inside the PGC, when the user has called a menu with the remote.
I have never seen a player resuming in the middle of a cell after a CallSS. Anyway, with CallSS, the resume point cannot be the current playback position, since when a command is executed, the title has finished playing, or is between 2 cells if a cell command is executed. It doesn't make sense to resume at the end of the PGC.
In this second case, I don't understand why it is important to save all that info, as the only things needed are the VTS, PGC (or TTN?) and cell numbers. Resuming to the beginning of a cell is really easy, and doesn't require to save, for example, the nav timer.

So, IMO, there are two types of resume points. The first one can be anywhere in the title, but cannot be created by a VM command, and the other one is created by a CallSS, and must be at the beginning of the cell specified in the command. There is no valid nav timer for this type of resume point.

Right?

So, my question is still valid: is the resume cell of a CallSS in the current PGC, or in the first PGC of the current Title? The fact that SPRM 5 (VTS_TTN) is also saved might be because of that.

[blutach]

Imho dummies does not make sense in titles ...I have seen plenty of dummy PGCs in the title domain in commercial DVDs. Of course, there is video in other PGCs, but IMHO, it is not a problem. Of course, the specs might say different.

For an example, if you have the Lost series (either series 1 or 2), the title that directs which eps is to be played has many dummies, along with some credits (in various languages).

Regards

[r0lZ]

Hum, I've just found a DVD (Wallace and Gromit Z2) with a lot of non-dummies PGCs used like dummies. They have a tiny cell, never played.
BTW, in the VTST domains, all entry PGCs (Root, Subpic, etc...) have also a tiny dummy cell. Is it also a requirement? The non-entry PGCs are true dummies, or true menus with played video.

[bigotti5]

is the resume cell of a CallSS in the current PGC, or in the first PGC of the current Title? The fact that SPRM 5 (VTS_TTN) is also saved might be because of that.

To resume (CallSS by a VM command) you need at least
SPRM4 (for the VTS)
SPRM6 (if it is a multi-PGC title) or SPRM7 (valid only in a one_seq_title)
Cell (specified in command)

There is no valid nav timer for this type of resume point.

?
Nav timer is not saved, CallSS stops the countdown of the navigation timer (or the count up of any GPRM registers in counter mode)

[r0lZ]

Sorry, I mean the time elapsed in the current cell (or PGC.) Obviously, this timing is saved in the first type of resume point, as the player is able to resume exactly where you pressed the menu button.

[spyhawk]

I have seen plenty of dummy PGCs in the title domain in commercial DVDs. Of course, there is video in other PGCs, but IMHO, it is not a problem. Of course, the specs might say different.I assume these dummy PGCs must belong to a VTS_Title in a multi-PGC title. I haven't encountered a DVD with this yet. I remember in early v3 of DvdReMake Pro that it allows creation of dummy PGCs in the title domain, then after some discussion it was changed in later version to include a blank cell when adding a PGC.

all entry PGCs (Root, Subpic, etc...) have also a tiny dummy cell. Is it also a requirement?It's not a requirement in VTSM domain. The same is true for VMG domain, e.g. entry PGC (Title menu).

To resume (CallSS by a VM command) you need at least
SPRM4 (for the VTS)
SPRM6 (if it is a multi-PGC title) or SPRM7 (valid only in a one_seq_title)
Cell (specified in command)So in what situation is SPRM 5 being used?

[blutach]

@spyhawk - your assumption is correct. At least one PGC has some video. Although 2COOL proved this requirement not be a practical one.

Regards

[r0lZ]

spyhawk, thanks for your answer.

According to mpucoder, only the entry PGC ot a multi-pgc title must have video content. And I confirm that many commercial DVDs are authored this way. But, as I said above (http://forum.doom9.org/showthread.php?p=899493#post899493), it's not always the case.

[bigotti5]

So in what situation is SPRM 5 being used?

maybe resuming from the VTSM domain, where SPRM5 would be enough

..only the entry PGC ot a multi-pgc title must have video content. And I confirm that many commercial DVDs are authored this way.

...and these titles are one_sequential?

[mpucoder]

You can create many complex situations that still qualify the title as one-sequential using either seamless or non-seamless branching. The title has a single PGC which contains the normal path of the movie, with no next or prev links. The other PGCs are accessed via BOV, however, this does not affect the timeline of the title's entry PGC. Non-entry PGCs in a title may or may not have content (the term "dummy" usually refers to a PGC with no content). The author may decide to use a dummy to determine which extra feature to show then branch to the PGC to show it, etc.

[r0lZ]

...and these titles are one_sequential?No. I haven't said that.

[vad74]

Hi bigotti5 and all profi.
I have a question about "shuffle" PGC playback. I create DVD with many music video clips. Now I want that clips play back random (shuffle). How I need edit PGC for it. I use DvdReMake for edit DVD. Where I need set "shuffle" mode? In each PGC with clip, or in each PG?

[r0lZ]

Shuffle mode is a per-PGC setup.

In shuffle mode, a certain number of PGs of the PGC are played randomly, then the playback ends normally (by executing the post commands.) Therefore, you have to set shuffle mode on the PGC, and set the number of PGs to play to the number of PGs in the PGC (or less or more if you wish.)

Note that the seamless flags of the first cell of each PG MUST be clear! Also, a PGC played in random mode must be declared as not-one_sequential and should contain only one chapter made of several PGs (but apparently, this last requirement is ignored by most players.)

Anyway, take care, as some players don't support shuffle or random mode properly. It's the case of my old and expensive Sony. It plays always the first PG at the beginning (why?) and then the other PGs in shuffle mode. At the end of the playback, is... exits! No matter what I put in the post or cell commands, or in the NextPGCN link, it cannot return to the menu.

[vad74]

r0lZ thanks.
My DVD must contain only one chapter? Why? I want make menu where user can choose any clip.
And in result, I want add 2 "play All" buttons in menu. If select first - clips play serially. If second - clips play "shuffle". How make it?

[bigotti5]

My DVD must contain only one chapter? Why? I want make menu where user can choose any clip.

Not the DVD - the Shuffle PGC (Title) should contain only one chapter

And in result, I want add 2 "play All" buttons in menu. If select first - clips play serially. If second - clips play "shuffle". How make it?

You have one title containing all clips using PTT (chapters).
Link your menu play serially button to this title (PGC).
Use Pgcedit to clone this title (PGC).
From this new created title (PGC) remove all PTT except the first, set PGC to shuffle mode, set shuffle counter and link your menu shuffle button to this new PGC.

[r0lZ]

... and don't forget to clear the seamless flags of all PGs, if necessary.

BTW, don't worry. Even when you will play the shuffle Title, you will be able to skip to the next clip with the remote, as the Next Chapter button of the remote jumps to the next Program (PG) and not to the next chapter. However, the chapter number displayed by the player will still be 1.

[vad74]

bigotti5 if I "clone this title (PGC)" DVD will be contain 2 title with equal clips. I dont have memory for it. Volume of my Title equal full memory of DVD-R. If I make 2 title I must reduce bitrate or total time of clips. I dont want it.
For DVD edit I use DVDReMake.

[blutach]

@vad,

clone with PgcEdit (http://www.videohelp.com/~r0lZ/pgcedit/index.html). Use the New play all title function (and then change the chaptering and shuffle mode for the new title).

I have noticed that DVD Remake Pro (http://www.dimadsoft.com/dvdremakepro/index.php) in some cases, copies a PGC but adds it as new video content instead of simply copying the same cells. I am sure you are experiencing the same effect. If you wish to work in DVDRMP, use the substitute function, to substitute the old cells for the new ones.

Regards

[r0lZ]

Yep, cloning a PGC (in PgcEdit) doesn't change the size of the VOB files. The new PGC is just another way to access the same video cells.

[vad74]

I understand!!! PGC not contain video stream. PGC have only link to cells of video stream, and I can add PGC with link to one video stream.
In DVD Remake VTS contain one ProgramChains. ProgramChains contain many PGC. PGC contain Program with Cells. In menu for PGC I click Duplicate. And it created new PGC2 with my video. But DVD size not increase! Each PGC1 and PGC2 have equal size. PGC2 I can do Shuffle mode. Thanks for all.

[blutach]

Looks like you're on the right track.

Regards