Jump/Call/Link TitleType flags in VMG_TT_SRPT

[r0lZ]

I am trying to understand exactly how to set the bits 2 to 5 of the TitleType byte in the VMG_TT_SRPT table.

As far as I know, bit 3 must be set when there is at least one Jump, Call or Link command in a BOV pertaining to the title.
Similarly, bit 4 must be set when there is at least one Jump/Link/Call in the pre or post commands of the title, and bit 5 must be set when there are Jump/Link/Calls in the cell commands.
Bit 2 must also be set when at least one of the other bits is set, and must be clear otherwise.

That seems straightforward, but there are several things that I don't understand.

Is it possible to have bit 2 clear? In other words, have you ever encountered a Title without any CallSS or JumpVTS_TT to jump elsewhere? If such a title exists, the playback must stop when it has finished playing, right? So, what's the purpose of that bit 2? How could it be used by a player?

Also, almost all commercial DVDs I have checked so far are not following exactly the rules above. For example, a title that has a LinkTailPGC in the cell commands has NOT the bit 5 set! Why? Does it mean that only the commands jumping outside the current title have to be taken into account? If it's the case, the Link commands cannot be taken into account, as they have to jump somewhere in the same title. Or should I consider only the commands jumping outside the current PGC, but possibly in another PGC pertaining to the same not-one_sequential Title?

Anyway, it seems that almost all commercial DVDs treat those bits differently. That means that it's again a DVD-Specs problem, and probably that the players do NOT use those bits at all. Anyway, I can't imagine a good reason for the presence of those flags.

If someone could help clarify this question, I would be very happy! Thanks!

[spyhawk]

Is it possible to have bit 2 clear? In other words, have you ever encountered a Title without any CallSS or JumpVTS_TT to jump elsewhere? If such a title exists, the playback must stop when it has finished playing, right? So, what's the purpose of that bit 2? How could it be used by a player?Bit 2 is cleared when there are no Jump/Link/Call in pre/post/cell/button commands. The only way to jump elsewhere is through the use of NextPGCN link in a not-one-sequential title, and I have encountered such DVD.

If those commercial DVDs are not following the DVD spec rules does not mean you shouldn't. :) And you're right, we can't expect all the standalones to follow as well, as you know some are more strict, especially the Sony ones, than others.

For example, a title that has a LinkTailPGC in the post commands has NOT the bit 5 set! Why? Does it mean that only the commands jumping outside the current title have to be taken into account?You mean in the cell command. :) I'd say you fix it to have bit 5 set when the DVD is saved. If you're worry about how the tracing will behave, just ignore these bits and trace normally.

Let the players handle the behavior of JLC commands when such appropriate bits are not set properly. So as a rule of thumb, save the DVD via PgcEdit and you'll have a compliant DVD, according to DVD spec. ;)

[r0lZ]

Bit 2 is cleared when there are no Jump/Link/Call in pre/post/cell/button commands. The only way to jump elsewhere is through the use of NextPGCN link in a not-one-sequential title, and I have encountered such DVD.
Hum, I still don't understand. The NextPGCN link cannot be used to jump to another title, as, as you said, it can be used only in a non-one_seq title to jump to another PGC pertaining to the same title. Therefore, although it is possible to jump to another PGC, it is not possible to jump to another title without a Call or Jump command. Since the Title Play Map table is, as its name implies, a table of the titles, I still can't understand why bit 2 is needed, as IMO, it has to be set anyway (unless, as I said, the playback ends at the end of the title with an exit command, and I have never seen that in a commercial DVD.)

You mean in the cell command. :)Oops, yes, of course! I've fixed my previous post.

So as a rule of thumb, save the DVD via PgcEdit and you'll have a compliant DVD, according to DVD spec. ;)I have just modified PgcEdit to set those bits according to the commands, but that was not the case before. I just copied the original bits without modifying them. (And, BTW, no players have had problems so far, including my old and very picky Sony.)

[spyhawk]

Hum, I still don't understand. The NextPGCN link cannot be used to jump to another title, as, as you said, it can be used only in a non-one_seq title to jump to another PGC pertaining to the same title. Therefore, although it is possible to jump to another PGC, it is not possible to jump to another title without a Call or Jump command. Since the Title Play Map table is, as its name implies, a table of the titles, I still can't understand why bit 2 is needed, as IMO, it has to be set anyway (unless, as I said, the playback ends at the end of the title with an exit command, and I have never seen that in a commercial DVD.)Yes, that's what I mean. When you mentioned to jump elsewhere, I didn't realize you mean to another title. Maybe bit 2 is used as an indicator whether bits 3-5 should be checked or not. Maybe a guru can chime in for a possible answer. I wonder if a DVD Verifier will catch this situation.

[bigotti5]

As far as I know, bit 3 must be set when there is at least one Jump, Call or Link command in a BOV pertaining to the title.
Similarly, bit 4 must be set when there is at least one Jump/Link/Call in the pre or post commands of the title, and bit 5 must be set when there are Jump/Link/Calls in the cell commands.
Bit 2 must also be set when at least one of the other bits is set, and must be clear otherwise.
Imho mpucoders site is wrong here, bits are used as following:
2 = exist
3 = button bit
4 = jump/call bit
5 = exist in cell and/or button bit

Examples:

0001 -> link in pre/post only (no link/jump elsewhere)
0101 -> jump in pre/post (no jump elsewhere)
0111 -> not valid (bit 3 requires bit 5)
1001 -> link in cell (no jump elsewhere)
1101 -> jump in cell
1011 -> link in button (no jump elsewhere)
1111 -> jump in button
1111 -> link in button and jump in cell

Tested with scenarist in accordance to interra verifier, philips does not check these bits.

[r0lZ]

Thanks, but I'm ever more confused.

What does bit 2's "exist" mean exactly? What is supposed to exist? At least a link in any location, unless bit 4 is also set, in which case it would mean that at least a Jump or Call exists in any location (and possibly also some links)?
And, again, I don't understand why that bit is necessary, as, imo, a jump or call exists almost always in a title.

According to your info, I understand this:
- bit 2 must be set if there are link, jump or calls somewhere in the title.
- bit 3 must be set if there are link, jump or calls in BOVs.
- bit 4 must be set if there are jump or calls somewhere in the title. (If it is set, that means that the player has no way to know if there are also links somewhere.)
- bit 5 must be set if there are link, jump or calls in BOVs or in cell commands.

1111 -> jump in button
1111 -> link in button and jump in cellSame code, but not same description!
When all bits are set, the decoding is very difficult. We know that there are BOVs with link, jump or calls, but we know nothing about the pre, post and cell commands.

Is it correct?

If it's correct, I really wonder how a player could even use those bits! It can decode some bit configuration accurately, but in other cases, it is impossible to know exactly where is what! So, what's the point?
Anyway, I can't understand why the authors of the specs did that. Is it really necessary for a player to know this information? When it encounters a Jump, Link or Call, it executes it. That's all! No need for this crap! And the fact that the Philips Verifier doesn't check those bits is a good indication that they are not very useful, and probably never used. Stupid specs! :devil:

[bigotti5]

Correct

If it's correct, I really wonder how a player could even use those bits! It can decode some bit configuration accurately, but in other cases, it's almost impossible to know exactly where is what!
Anyway, I can't understand why the authors of the specs did that. Is it really necessary for a player to know this information? When it encounters a Jump, Link or Call, it executes it. That's all! No need for this crap! And the fact that the Philips Verifier doesn't check those bits is a good indication that they are not very useful, and probably never used. Stupid specs!
Dont know if players really evaluates this information....
Maestro for example, always sets 1111 (even there are no link/jump/call commands at all) and Interra does not complain...
Above is only my conclusion...no reasonableness check of the specs

[r0lZ]

Thanks! It's what I thought. Indeed, fooling the player by saying that there are jump/call/links everywhere cannot hurt.

I think I will verify the commands in the PGC itself, but not in the BOVs, as, if the user has not scanned the VTS for BOVs, I have no way to check the commands, and I don't want to force the user to do the scanning just to set those flags. (However, I suppose I can assume that there are no BOVs if there are no subpic stream defined for that VTST.)

[blutach]

I thought it was a bitwise flag.

5 4 3 2
Cell? Pre/Post? Button? Any?

So, 0000 is OK for something like a DVD Shrink re-authored DVD (which has no BOVs), where the only command is Exit. Or as spyhawk has said, where only Next/Prev PGCN is non-zero.

And 0101 would be the norm (no cell command or BOV) while 1101 would include something like a LinkTail PGC cell command.

But I guess bigotti5 has a different view.

0111 -> not valid (bit 3 requires bit 5)Ifoedit doesn't complain about this - commands only in button and pre/post. In fact, IfoEdit and mpucoder's info matches.

Re bit 2, it seems that if any of bits 3, 4 or 5 are on, bit 2 must be.

@r0lZ - good idea to verify the command in the PGCs but not BOVs. One caveat - if bit 3 is on (in the original), it might be a good hint that there are BOVs and so perhaps if a scan hasn't been done already, pop up a message to the user that it might be useful to do one. This would be especially useful in a not one sequential title (bit 6 is set), where BOVs seem to be found frequently.


EDIT: I am looking at a not one seq PGC now. It's an extra in the form of a little game with BOVs. The playback type is 125, which implies 1111. Ifoedit says it is invalid! Yet, 63 is not invalid. :confused:

Regards

[r0lZ]

I thought it was a bitwise flag.

5 4 3 2
Cell? Pre/Post? Button? Any?
I thought that also, as I trust mpucoder, but bigotti's view seems more compatible with what I've found in the the commercial DVDs.


So, 0000 is OK for something like a DVD Shrink re-authored DVD (which has no BOVs), where the only command is Exit. Or as spyhawk has said, where only Next/Prev PGCN is non-zero.I agree that 0000 is possible, although very rare in a commercial DVD, but again I disagree on the NextPGCN link idea. Don't forget that it's the whole title that must be taken into account. A not-one_sequential title made of several PGCs has always a way to return to the menu, and that's not possible with the NextPGCN links only (or with a Link command). There must be a Call (on in some rare cases a Jump) to quit the Title.

@r0lZ - good idea to verify the command in the PGCs but not BOVs. One caveat - if bit 3 is on (in the original), it might be a good hint that there are BOVs and so perhaps if a scan hasn't been done already, pop up a message to the user that it might be useful to do one. This would be especially useful in a not one sequential title (bit 6 is set), where BOVs seem to be found frequently.Good idea, but the problem is that I need the button info to set the bits when I save the DVD only. It might be very frustrating to be warned to scan the DVD for BOVs when you have finished to edit it! IMO, I should verify those bits when the DVD is loaded. But having the same dialog popping up each time you load the DVD can be an annoyance too. Not sure what I will do...

[blutach]

In theory, quit via Exit could be possible in a not one seq PGC (i.e. this title could be re-authored in DVD Shrink with no menu).

As for bigotti's view, I'm a confused as to bits 3 and 5. Why would you have a button bit and then a cell and/or button bit? Not that anything with the specs makes a real lotta sense, but the way we have tradionally understood it seems to be more logical.

Anyway, I don't think it is all that relevant. Most players check the PUOps (bits 0 and 1), I would think and that's it.

As for this:

For example, a title that has a LinkTailPGC in the cell commands has NOT the bit 5 set! I have examined a few DVDs today and most with just a LinkTailPGC cell command have 52 (cell + pre/post command set).

Regards

[r0lZ]

OK, I've added the dialog to ask the user if he wants to scan for BOVs when at least one title has been found with bits 3 and 6 set (meaning that there are Jump/Link/Calls in the buttons of a non-sequential title). Of course, this dialog is not shown if the option to scan for BOVs automatically at startup is ON, and when the same DVD is reloaded. It is also possible to hide the dialog during the current PgcEdit session, or permanently.
(I cannot trust sufficiently bit 3 to assume that there are BOVs in a sequential title, as this bit is set anyway in many DVDs. Pity!)

Of course, the fact that this dialog is shown doesn't mean that there are BOVs in the DVD, as the bit 3 might have been set anyway, and, similarly, the fact that it is not shown doesn't mean that there are no BOVs, as there might be BOVs in a sequential title. But it's a good way to warn the user in some cases. Thanks for the suggestion, Blu!

I have also implemented bigotti's method to set the Jump/Call/Link bits.
However, currently, the button bits are set anyway if the scanning for BOVs has been made and there are buttons in the title (but the button commands are not checked) and also if the scanning has not been done and there is at least one subpic stream defined for the title and the button bit was set in the original DVD.

I don't want to do much more to set those useless bits more accurately.

(Note to the beta testers: a small dialog is shown on screen when PgcEdit changes those flags, during a maximum of 2 seconds, when the "debug" flag is set. I will remove this dialog later, but currently, I want to have some visual feedback. In the meantime, you can turn this dialog off by disabling the debug mode. The same message is added in the log anyway.)

Thanks to the helpers!

[r0lZ]

In theory, quit via Exit could be possible in a not one seq PGC (i.e. this title could be re-authored in DVD Shrink with no menu).I agree, but I haven't seen that in a commercial DVD yet (although I imagine that exit could be used with the parental management if the user doesn't know the code, but here in Europe, the parental management is almost never implemented.)

As for bigotti's view, I'm a confused as to bits 3 and 5. Why would you have a button bit and then a cell and/or button bit? Not that anything with the specs makes a real lotta sense, but the way we have tradionally understood it seems to be more logical.Yes, but the specs are usually NOT logical at all! Anyway, it's why I have added the debug dialog in the current version of PgcEdit. If PgcEdit changes the flags too often, I might go back to mpucoder's method.

I have examined a few DVDs today and most with just a LinkTailPGC cell command have 52 (cell + pre/post command set).Not the case in The Simpson series, for example. I see often 0x14 (Jump/Call + exist.)

The problem is that it will be very difficult to know who is right, as those bits seems to be set with no obvious logic, and differently by the different authoring programs. Bigotti, can you say where you have found the information?

[bigotti5]

Bigotti, can you say where you have found the information?

Created small projects in scenarist, step by step.
First without any link/jump/call.
Second with link in post only and so on.

I have examined some commercial titles and my conclusion seems to be true for
Scenarist
Toshiba Authoring
Sony Authoring
Spruce (for DVDs with Spruce logo in VIDEO_TS.VOB)
not found a Panasonic/MEI DVD in my collection

[r0lZ]

And you forgot Maestro (always 1111.)
Thanks!

[bigotti5]

And you forgot Maestro (always 1111.)

Seems there are two versions of Spruce Maestro....
One that creates a 154 kB 13 black frames dummy VIDEO_TS.VOB and always 1111
and another with 174 kB spruce logo VIDEO_TS.VOB following the rules above.

[mpucoder]

I finally got around to looking into this and found definitive information in the Philips RW verifier manual (not the same as the verifier for pressed DVDs). You can get a copy at http://www.ip.philips.com/download_attachment/4119/4119.pdf
Look for error 6531, there the bits are spelled out, and Bigotti is almost correct.
The bits are as follows:
name bit meaning
TT_PB_TY1 5 J/L/C as cell or button of title
TT_PB_TY2 4 J/L/C as pre/post
TT_PB_TY3 3 J/L/C as button of title
TT_PB_TY4 2 J/L/C exist

Only bit 5 is incorrectly described on my site

[bigotti5]

Found an error message in www to enlighten bit 5 (TT_PB_TY1)
Bit5 set to 1 means jump/call command in cellcommand or in a forced activated button
ERROR(TT_SRP,1101): TT_PB_TY1 is '1b' although Jump/Call Instruction does not exist in the cell command or "FOAC_BTNN" in TT_DOM. VI5-111.
ERROR(TT_SRP,1121): TT_PB_TY3 is '1b' in spite of Link/Jump/Call Instruction not existing in "BTN_CMD" in TT_DOM. VI5-111.

[r0lZ]

Thanks so much mpucoder! Things are much more clear now.

However, the +RW Verifer manual is still ambiguous:

[DVD+VR] ERROR 6531 (ref. [DVD+VR] 3.3.2.2)
ERR_DVDVR_VMGI_TT_PB_TY_ILL_TT_PB_TY
TT_SRP[]: The TT_PB_TY () must specify .
TT_PB_TY1 must specify ‘0’: No Link/Jump/Call instruction as a Cell Command or Button
Command in any Title.
TT_PB_TY2 must specify ‘1’: All Titles contain Link/Jump/Call instructions as a Pre- or Post
Command.
TT_PB_TY3 must specify ‘0’: No Link/Jump/Call instruction as a Button Command in any Title.
TT_PB_TY4 must specify ‘1’: All Titles contain a Link/Jump/Call instruction in the Title Domain.What does it means by "any title" and "all titles"? Those bits are set on a per title basis, right?

[EDIT] And, bigotti, your finding seems to confirm that those bits are set on a VTS basis, as the message says "in TT_DOM. VI5-111." So, again, I don't understand!

Also, I wonder if it is true that bit 5 means in cell and in forced activated button.

[bigotti5]

that those bits are set on a VTS basis, as the message says "in TT_DOM. VI5-111."

Imho no.
Every title is an independent TT_DOM...

ERROR 6531 is for Recordable DVD (DVD+VR)
As I unterstand this errormessage "0101" is the only possible flag in DVD+VR.
Title handling in DVD+VR is different from DVD Video
only one_seq_titles allowed
256 ptt per title
Full titles and Playlist titles
free space must be flagged as Full Title
.....

[r0lZ]

OK, that's what I thought, and hoped! :)
Thanks!

[mpucoder]

As bigotti5 said, DVD+RW is a subset of DVD for home recorders. All titles are identical in DVD+RW (also known as DVD+VR). So the bits are always 0101. The author of the manual wrote the description in that context, a 1 bit means JLC exist for all titles, a 0 bit means no JLC for any title.
But the description of each bit also lets us determine the meaning of the bit in the broader DVD-ROM sense.