PgcEdit 0.5

[lamster]

Originally posted by 2COOL
Why do we need to have an unused GPRM? It is possible to use a used GPRM.

You're assuming that there's no JumpSS-FP command. If there is, then your assumptions regarding what values r15 (in your example) may have when the First Play PGC is entered may not be correct.

(Which ties in rather nicely with r0lZ' comment, "I will do it for any search string." I'd like an easy way to see if anything jumps back to the FP PGC, to know how paranoid I need to be in my programming.)

[2COOL]

Originally posted by lamster
You're assuming that there's no JumpSS-FP command. If there is, then your assumptions regarding what values r15 (in your example) may have when the First Play PGC is entered may not be correct.

All GPRMs are set at 0 at DVD insert. I was using any GPRM, since they are at 0, setting them to 1, go back to FP, and setting back to it's original value 0.

(Which ties in rather nicely with r0lZ' comment, "I will do it for any search string." I'd like an easy way to see if anything jumps back to the FP PGC, to know how paranoid I need to be in my programming.)

There is. Just right click on First Play PGC and select "go to calling command". If anything pops up in the inquiry, then you'll know.

[lamster]

Originally posted by 2COOL
All GPRMs are set at 0 at DVD insert. I was using any GPRM, since they are at 0, setting them to 1, go back to FP, and setting back to it's original value 0.

It's 0 at DVD insert, but if some other PGC does a "JumpSS-FP", which jumps to the First Play PGC, then[list=1][*]r15 could have any value at that point, including 1;[*]the assumption that the value to reset it to is 0 is also invalid.[/list=1]

[2COOL]

Originally posted by lamster
r15 could have any value at that point, including 1

I know "1" was a bad example. That's why in my Jump2PGC, I had values like 12345, 11111, 22222, ... to select from.

the assumption that the value to reset it to is 0 is also invalid.

I like to look at this as a small minor loop. Start at point A, play intro title, and return to point A with original value (0) before executing original FP commands.

[EDIT] OK, now I'm having doubts. I've had a long day of work and just got home. I will research again.

[lark]

Originally posted by jeanl
blutach this looks like the problem another user was having on the forum (can't find the message again, the search utility is simply useless when you have threads that are 20 pages long ).
There was a bug in the original DVD2AVI code that got carried through to PgcEditPreview. Can you preview the vob? (that should work)...
Jeanl

well, in this case it wasn't 20 pages (not even 20 posts): http://forum.doom9.org/showthread.php?s=&threadid=93771

regards
t

[jeanl]

Originally posted by lark
well, in this case it wasn't 20 pages (not even 20 posts): http://forum.doom9.org/showthread.php?s=&threadid=93771

regards
t

I do have a tendency to exaggerate!
Thanks Lark!
jeanl

[2COOL]

OK, how's this. SPRM 6 (PGC Number) is 0 at default. As also with GRPM(15). As soon as a Title is accessed, sprm(6) gets a value of 1 and will never revert back to 0.

Before

VMG , First-Play PGC

************* pre commands
1 (JumpSS) Jump to VTSM 1, Root menu (TNN 1)

_________________________________________________

After

VMG , First-Play PGC

************* pre commands
1 if ( gprm(15) < sprm(6:PGC number) ) then { Goto line 3 }
2 (JumpTT) Jump to Title 1
3 NOP
4 (JumpSS) Jump to VTSM 1, Root menu (TNN 1)

The only disclaimer here is that if FP is executed the third time around, grpm(15) shouldn't be a 0 or else Title 1 will play again. Of course, we have 15 other gprms to work with and at least one of them should be greater than zero at this point.

or we could also do this

After

VMG , First-Play PGC

************* pre commands
1 if ( gprm(15) != sprm(6:PGC number) ) then { Goto line 3 }
2 (JumpTT) Jump to Title 1
3 NOP
4 (JumpSS) Jump to VTSM 1, Root menu (TNN 1)

[r0lZ]

Originally posted by 2COOL
With so much posts recently in regards to intros creations, I looked at the "Import First-Play Clip" macro and came up with 2 questions.

1. Why do we need to have an unused GPRM? It is possible to use a used GPRM. Here's one of my First Play PGC examples. RED are new commands.

Before

************* pre commands
1 (JumpSS) Jump to VTSM 1, Root menu (TNN 1)


After

************* pre commands
1 if ( gprm(15) == 1 ) then ( Goto line 4)
2 Set gprm(15) =(mov) 1
3 (JumpTT) Jump to Title 2 //Imported Title
4 Set gprm(15) =(mov) 0 //GPRM reset back to default 0
5 NOP
6 (JumpSS) Jump to VTSM 1, Root menu (TNN 1)


2. Why can't we have a value of 255 for an infinite still Title? The Title would display indefinite until the user presses Play.

With your method, you reset the GPRM to 0 after the intro clip has been played. Therefore, if the FP-PGC is called again by an original command somewhere in the DVD, the intro clip will be played again, and we don't want that!
Try with a DVDShrink reauthored DVD with 2 or 3 clips: the intro clip will be played before each reauthored title.

[EDIT:] Obsolete post. I've not read the answers before posting. Error!

[blutach]

Originally posted by jeanl
blutach this looks like the problem another user was having on the forum (can't find the message again, the search utility is simply useless when you have threads that are 20 pages long ).
There was a bug in the original DVD2AVI code that got carried through to PgcEditPreview. Can you preview the vob? (that should work)...
Jeanl

Yeah, I rememeber that. When I try to preview the menu VOB, either with the preview in 0.5.6B4 or the one you sent me, it hangs PgcEditPreview.exe and processor % goes up to 100%.

Regards

[lark]

Originally posted by blutach
preview in 0.5.6B4

hmm, what's that?

regards
t

[r0lZ]

Originally posted by lark
hmm, what's that?

Well, I've uploaded Beta 6 at VideoHelp. The new preview, which should fix the problem, is included in this beta (but not referenced in the history).

Please note that the Jump2PGC macro is still in a somewhat experimental state.

[r0lZ]

Originally posted by northwind
Is this a known problem?



can't read "::buttons::butinfo(0,errorcode)": no such variable
can't read "::buttons::butinfo(0,errorcode)": no such variable
while executing
"if {[info exists ::menus($cur_vts,$cur_lu,$cur_pgc,numbuttons)] && $::buttons::butinfo($cur_vts,errorcode)==0} {
set cellpostable $::menus($cur_..."
(procedure "simulate_play" line 127)
invoked from within
"simulate_play"
invoked from within
"if {$idx == "-"} {
::main::set_listbox_selection end
set idx [lindex [::main::get_selection_indexes] 0]
bell
} elseif $::tr::now_playin..."
(procedure "step" line 5)
invoked from within
"step "
(procedure "::tr::dvd_trace" line 329)
invoked from within
"::tr::dvd_trace"
(command bound to event)

Will have a look... Thanks!

[lark]

Originally posted by r0lZ
I've uploaded Beta 6 at VideoHelp. The new preview, which should fix the problem, is included in this beta (but not referenced in the history).

ok, thx. i can confirm that menu has background image (for my src).

regards
t

[blutach]

Will try B6 and revert. Thanks r0lZ and lark for alerting me to that "old" thread (3 whole days LMAO).

EDIT: Beta 6 doesn't work for me.

Regards

[r0lZ]

Originally posted by blutach
EDIT: Beta 6 doesn't work for me.

So, could you send me a small DVD to test?

[blutach]

I would, but if I put the menu through VobBlanker (just to blank the only cell with audio and get it down to a couple of Mb) or MenuShrink (which shrinks them all), PgcEdit reads all the menu PGCs beautifully!

What was that site to upload the DVD? I can zip it up - it's only about 6Mb once I blanked the title VOBs?

EDIT: I'll try to email it.

Regards

[jeanl]

Originally posted by blutach
I would, but if I put the menu through VobBlanker (just to blank the only cell with audio and get it down to a couple of Mb) or MenuShrink (which shrinks them all), PgcEdit reads all the menu PGCs beautifully!

What was that site to upload the DVD? I can zip it up - it's only about 6Mb once I blanked the title VOBs?

EDIT: I'll try to email it.

Regards

www.yousendit.com

works really well.
jeanl

[jeanl]

Thanks blutach, I got the files. I looked into it and traced the problem back to a part of the code that I don't understand very well, where the original author commented out part of the code saying:

// This code is designed to ignore false (emulated) leading
// SEQUENCE_HEADER_CODEs. But it precludes decoding MPEG1
//  because it would trigger this. I'll wait until I see
// how real the issue is before doing anything. So far it is
// just one VOB reported and the notifier no longer even has
// it.

When I re-enable the code that was commented out, things work normally. From what I understand, this particular vob has a "false - emulated leading SEQUENCE_HEADER_CODE", which is what causes DVD2AVI to fail. I'm not sure I know what that means, nor do I see that in the VOB file (but I don't really know where to look, it's hard to figure out where you are in the file with DVD2AVI!). What I know is that this fake sequence header has the wrong picture height/width, which is then responsible for the later failure. The code that I re-enabled skips the fake sequence header and goes to the next one, which has the right data...

I'm going to look into it a bit more to see what's going on. In the meantime, if anybody has any input/hint on that, I would really appreciate it.

jeanl

[jeanl]

This is a good one! Check this out:



Look at the binary value for the VOBU_SRI circled in red. 0x0000001b3! This matches exactly SEQUENCE_HEADER_CODE and DVD2AVI isn't very smart about it! So it's fooled into thinking this is the beginning of a mpeg sequence header, smack in the middle of the VOBU_SRI block! If it wasn't so sad, it would be funny!

Anyway, I'm not too sure what to do about it. I could leave the code that was originally commented out, but then preview will fail on MPEG-1 files. I'm not sure how important that is.
Any opinion?
jeanl
EDIT: The reason why everything works well if MenuShrink or Vobblanker is used to still this guy is because the VOBU_SRI pointers are all reset! AH AH AH!

[mpucoder]

When I first heard of this "false (emulated) header" thing I thought it might be something dumb like this. While header emulation IS impossible within the video stream, it is only within the video stream. When interpretting a system stream (mpeg-1) or program stream (mpeg-2) there are two levels of context, the system level, and the elementary stream level. Looks like DVD2AVI tried to take a shortcut and not recognize pack headers or pes headers. If it did the entire NAV pack would get skipped as it is a private stream, not part of the video.

Why does mpeg-1 fail if the code is compiled? Is it possibly because mpeg-1's pack header is different than mpeg-2's? If so there is a simple way to know you are in mpeg-2, and it is even mentioned in the spec. The presence of any extension header means mpeg-2 (it was not used in mpeg-1). For that matter (just looked it up on my site) the pack header for mpeg-2 is recognizable by the value in the byte following the start code.