Solved: Seamless branching gone wrong. Can someone asist?

[LogicDeLuxe]

Edit: problem solved and link updated.

I'm trying to create a multi-angle and seamless branching demo DVD with a tool I'm coding. So far, it works most of the time, except I got one scene which totally fails on my standalone SEG player. (which is very picky about correct buffering.)
On it, all runs perfectly seamless, except for VOB id 5, Cell 2. There, the video gets very jerky and also plays one chunk from VOB id 4 inbetween which it is not supposed to. This problem does not occur on any of my software players and neither on the PS3.

There must be some detail I did not think of yet, or some unnoticed bug. Can someone please check my test image? Maybe you can find an oversight.

Note, that there are no seamless angle pointers yet, which is on my todo list. However, since neither VOB id 4 nor 5 are part of any multi-angle scene, that can't be the problem.

Get the image (7 MB) here: http://www.abmischung.de/branchtest.7z

[Emulgator]

PCGEdit finds 2 (VTS 1, TTN 1) respectively 3 (VTS 1 TTN 2) cells flagged as seamless
where gaps exist and therefore the seamless flag should be unset.
Maybe this helps ?

[LogicDeLuxe]

Thanks for taking a look.

What gap is PGCedit exactly refering to? Is it that some sectors are skipped? There are always jumps of a couple of seconds somewhere when seamless branching or multi-angle is involved, which should be perfectly fine and merely requires a slightly lower bitrate to give the player room to refill its buffers.
Or has the gap todo with audio? Every VOB id's frame count is a multiple of 4 which makes it possible to the cut AC3 audio to the exact same duration (for PAL video), which I did. I also made sure, that there are no AC3 frames omitted, which most multiplexers do with a negative audio delay specified, unfortunately, but IFOedit doesn't.

The problem doesn't occur at the seams anyway, which seem to work perfect, except in the middle of VOB id 5, Cell 2. Is there anything in particular I have to look for at cell boundaries (within the same VOB id) in interleaved streams maybe?

In the meantime, I got multi-angle pointers implemented, but like I expected, it has no effect on this particular issue.

[Ghitulescu]

Originally Posted by LogicDeLuxe

This problem does not occur on any of my software players and neither on the PS3.

I very much doubt that you can spot seamless issues with any software player, as this occurs only when the player has insufficient buffering (memory is expensive in a standalone).

[kolak]

Originally Posted by LogicDeLuxe

I'm trying to create a multi-angle and seamless branching demo DVD with a tool I'm coding. So far, it works most of the time, except I got one scene which totally fails on my standalone SEG player. (which is very picky about correct buffering.)
On it, all runs perfectly seamless, except for VOB id 5, Cell 2. There, the video gets very jerky and also plays one chunk from VOB id 4 inbetween which it is not supposed to. This problem does not occur on any of my software players and neither on the PS3.

There must be some detail I did not think of yet, or some unnoticed bug. Can someone please check my test image? Maybe you can find an oversight.

Note, that there are no seamless angle pointers yet, which is on my todo list. However, since neither VOB id 4 nor 5 are part of any multi-angle scene, that can't be the problem.

Get the image (7 MB) here: http://www.fileden.com/files/2012/2/...amless_test.7z

Seamless branching is very tricky on DVD. What tool are you using for encoding, muxing? It requires big attention on encoding stage and muxing. I don't know any single app which can do it (according to DVD spec) except Toshiba authoring system, which you can't even buy So multiangle yes, but seamless branching good luck Even if you make it working on your player than it may fail on next 10 players.
PS3 is not the same as standalone DVD player, so not good for testing.

[LogicDeLuxe]

It doesn't seem to be a cell boundary issue. I tried moving the chapter mark at the beginning of VOB id 4 so that VOB ids 4 and 5 can have just one cell each. The playback problem remains the same and still occurs in the second half of VOB id 5.

Originally Posted by kolak

What tool are you using for encoding, muxing? It requires big attention on encoding stage and muxing.

I know. I encoded with HCenc with closed GOP. Audio and Video is then cut with Cuttermaran into pieces and multiplexed with IFOedit (which is the only multiplexer I found which doesn't drop audio frames.) The audio delay is set to -192 ms during multiplexing to match what PTS says on cell boundaries. Then I join all the multiplexed VOBs with dvdauthor and interleave them with the tool I'm coding.

I don't know any single app which can do it (according to DVD spec) except Toshiba authoring system, which you can't even buy So multiangle yes, but seamless branching good luck

I find that strange since seamless branching is similar to multi-angle, but actually less restrictive.

Even if you make it working on your player than it may fail on next 10 players.

I hope, I can prove that it doesn't some day.

PS3 is not the same as standalone DVD player, so not good for testing.

I know, it is just another software player with good scaling (except it scales 720 pixel rather than the correct 704 to 16:9 width). But the more players I can test it on, the more can I be sure that my DVD structure works.

[Ghitulescu]

Originally Posted by LogicDeLuxe

I find that strange since seamless branching is similar to multi-angle, but actually less restrictive.

Both use more or less the same algorithm - interleaving of programs in order to allow a standalone, with a very limited on-board memory and with a max. 2x optical drive, to follow one of the paths without causing underbuffer.

[kolak]

Originally Posted by LogicDeLuxe

It doesn't seem to be a cell boundary issue. I tried moving the chapter mark at the beginning of VOB id 4 so that VOB ids 4 and 5 can have just one cell each. The playback problem remains the same and still occurs in the second half of VOB id 5.

I know. I encoded with HCenc with closed GOP. Audio and Video is then cut with Cuttermaran into pieces and multiplexed with IFOedit (which is the only multiplexer I found which doesn't drop audio frames.) The audio delay is set to -192 ms during multiplexing to match what PTS says on cell boundaries. Then I join all the multiplexed VOBs with dvdauthor and interleave them with the tool I'm coding.I find that strange since seamless branching is similar to multi-angle, but actually less restrictive.I hope, I can prove that it doesn't some day.I know, it is just another software player with good scaling (except it scales 720 pixel rather than the correct 704 to 16:9 width). But the more players I can test it on, the more can I be sure that my DVD structure works.

Closed GOP is not enough. Use strict, fixed GOP structure, CBR rather than VBR, <7.5Mbit, etc
As I said- good luck- there are not many commercially released discs with seamless branching, because there are compatibility problems. Many players will never play such a disc fine anyway and this will be player's fault, not yours.
You are relying on many apps, which may have some bugs etc, so really good luck
Let us know if you make it working fine on few players

[LogicDeLuxe]

Originally Posted by kolak

Closed GOP is not enough. Use strict, fixed GOP structure, CBR rather than VBR, <7.5Mbit, etc

I will try that. I wonder what is the reason for CBR or fixed GOP structure, except that GOPs have to be the same duration for each angle that is.
Angle change does only occur at an ILVU boundary, so why is a fixed GOP structure so important?

[Emulgator]

If ILVU then maintaining CBR AND Closed GOPs AND similar GOP structure safely delivers close (in terms of block distance)
skips when performing an angle change.
So after a GOP is played and angle change is to be performed even with the minimum buffer
the decoder always gets to see the next angle's playable I-frame data soon enough
because it is indeed already in the buffer and/or the head doesn't have to move too far.
This would be a very different scenario with VBR, where a more bit-hungry angle would require reading
far ahead from its more bit-content partner angle.
Then when user calls an angle change both positions in sector counts would differ much more.
Harder to be able play the other angle from the same piece in time without a reasonable switching/searching delay, I guess.

[LogicDeLuxe]

I got it sorted. Here is the new image: http://www.abmischung.de/branchtest.7z

The problem with the last image was that some entries in the nav packs for next ILVU's size were wrong. Apparently, the majority of players don't use that entry, but rely on the tables in the IFO files instead, thus didn't display this error.

Thanks for your suggestions anyway.

[Emulgator]

Hats off. You did it.

[LogicDeLuxe]

My seamless branching and multi-angle authoring is in a usable state now. It is PAL only, though.
I tested it with quite some movies and also several different players.
I have put a demo iso file to a more permanent place on my homepage here: http://www.abmischung.de/video_examples_en.html

[Emulgator]

Wow. You did it again. Multiangle and seamless.
Your software is a muxer only ? Do you have to control encoder manually?

Now with real-life footage and what about CGOP, bitrate modes, CBR (or even VBR, which deviation ranges allowed ?)

[LogicDeLuxe]

Originally Posted by Emulgator

Wow. You did it again. Multiangle and seamless.
Your software is a muxer only ?

It is in two parts. A multiplexer and an interleaver. I needed to code my own multiplexer as I found that non of the available fulfilled my needs. They all had major bugs and/or limitations preventing me from making flawless transitions. It also fixes some frequent subtitle errors on the fly.

Do you have to control encoder manually?

Of course. There is a lower bitrate limit on interleaved parts and just before and after that. There is a useful table in "DVD Demystified" for choosing the appropriate max bitrate to use. And I have to control where I put closed GOPs. And I have to make sure that a new GOP starts where I want the transition to be.

Now with real-life footage and what about CGOP, bitrate modes, CBR (or even VBR, which deviation ranges allowed ?)

CBR is not really necessary, as long as the max bitrate is honored. Closed GOPs are required in multi-angle sections, since otherwise you would see glitches when changing angles. And you have closed GOPs at the start of any new VOB id. You don't need them anywhere else. Also GOPs have to have the same framecounts in all angles.

[Emulgator]

That's impressive. Congratulations.