Re: [Dvdauthor-users] Seamless Branching & multiple VOBs

[Andre B. <be...@ib...>]

Re,

On Thu, Feb 26, 2004 at 05:06:28PM +1300, Steven Ellis wrote:
> Andre Beck said the following on 16/02/2004 10:13 p.m.:
> 
> >So far, this works straightforward - but I have problems playing the
> >resulting disc on my standalone (Pioneer DV525). The problems are
> >almost systematic and look like this:
> 
> Now in my case I have a Philips DVD 711 player, but I have some similar 
> problems to you.

They even seem to make clearer what happens, as they coincide with
observations I've made after the first post.
 
> >1) When playback changes to a new VOB (not a new cell of the same
> >   VOB), the counters on the standalone freeze. The time display
> >   freezes at the last timestamp of the former cell, so does the
> >   title/chapter display: I still see the number of the former
> >   chapter. Note that replay is actually fine, it's just the timers
> >   that freeze.
> 
> My player gets jittery at the branch points. Starts up and then after a 
> few seconds bounces back to the start of the branch. Plays fine from 
> that point onwards.

That fits the picture I'm starting to get. In the approx 64s time
phase where the old chapter is displayed and timers are frozen, when
I press the *Next* button on my RC (that should jump to the next
chapter), the player actually jumps *back* to the beginning of the
chapter that is already playing. It appears as if on a higher level
of conciousness, the player is not aware that it is already playing
that new chapter and considers itself still frozen at the end of the
former one, while the lower level is already decoding and replaying
that new chapter. Consequently, a press an Next forces it to jump
back.

What you see is different, but not that much - your player resolves
some discrepancy in its internal navigation by jumping to the start
of the new chapter, while mine just awakes from it with some sort
of hickup - mostly. It sometimes freezes, which is worse.
 
> >3) Sometimes, but not always (no systematics found so far), that
> >   first cell/chapter of a new VOB, after displaying the abovementioned
> >   anomalies, will later freeze entirely. Preferably it does so when
> >   it comes to an end and should jump to the next cell (jumping over
> >   the opening titles), but I have also seen it freeze earlier or not
> >   at all. Freezing in this case means, the complete playback freezes
> >   as if there had been a pause="inf" in the cell.
> 
> Haven't had this one

IMO it's all just symptoms of something beeing wrong with cell navigation
at the points where VOBUs from one VOB end and those from the next one
start. If I had to guess, I'd say there are overlapping cells or some-
such. I even thought I'd made them myself (by letting the last cell in
the first VOB faultily end in end="-1"), but I rechecked and found that
all my cells end in a timestamp that is within that VOB (and isn't even
the last one).

Here it strikes me again that I don't really know whether timestamps in
a cell are inclusive or exclusive. In a sequence like

<cell start="0" end="10" />
<cell start="10" end="-1" />

is the frame at timestamp 10 (aka frame 250) the one where cell 1 ends,
or is it the one where cell 2 starts, or both? If both, the player
knows they don't need to play twice if the cell is not jumped to, I
assume. I just am not sure whether it would be better to say

<cell start="0" end="10" />
<cell start="10.04" end="-1" />

to make clear what is meant, but then again, dvdunauthor of a commercial
DVD shows clearly that the ending timestamp of one cell is typically
the exact same as the start of the next one, they are thus inclusive
and dealt specially with if played sequential. As they are just time-
stamps in the presentation time space, not actually references to
frames, this makes sense in some way.

> >The building process emits a lot of "WARN: do not know how to compute
> >the audio gap" messages, but otherwise no problems (I got rid of all
> >the unclosed GOPs for instance).
> 
> I got the GOP errors as well. I haven't tweaked the GOPs on the MPEG, 
> not sure how to with the Linux tools i'm using (mpeg2enc and avidemux2), 
> but i'm considering putting small pauses between the cells to see if 
> that will suffice.

If I understand it correctly, open GOPs aren't really a problem here,
just an inconvenience. If a cell starts with an open GOP, it will
start displaying with some blank frames (or the former frame will
freeze), but no other problems. If you can find a GOP border in
a black intersection, it will not disturb at all.

In some attempt to make it perfect (and make sure that this isn't the
reason for my problems), I used TMPGEncs manual GOP structure capability
to place GOP-starts at the exact locations where I wanted them, and placed
another I-Frame directly in front of that GOP-opening I-Frame so it
must end up closed. This is a hack, too, but TMPGEnc doesn't allow a
manually placed new GOP to be made closed.
 
> I'll be interested to hear how your experiments go.

The problem is still there in alpha 893, and it is fully systematic
now that I have tested it over and over again. What I have to add is
the jumping back on next, which coincides with the jumping back you
see. Hopefully that helps Scott finding the problem.

Andre.
-- 
                  The _S_anta _C_laus _O_peration
  or "how to turn a complete illusion into a neverending money source"

-> Andre Beck    +++ ABP-RIPE +++    IBH Prof. Dr. Horn GmbH, Dresden <-