[Matroska-users] chapters and subchapters interpretation in case of EditionFlagOrdered=1 - analysis / questions

Michal Soltys soltys at ziu.info
Sun Jan 29 15:57:51 CET 2012


Hi,

I've been experimenting recently with a bit more complicated scenarios, 
and in effect all splitters I've tried so far (haali, mpc-hc builtin, 
LAV) give me somewhat different (or none at all) behavior.

The first question is just confirmation, the second one I'm the most 
curious about.

1) What is the "reference" behavior if EditionFlagOrdered=0 ?

The "reference" here I'd expect:

- editions presented separately by gui, (sub)*chapters in expected order 
grouped by editions, ChapterTimeEnd w/o any real functionality in such case

 From the splitters, I get:

Haali: editions supported, subchapters ignored
LAV: editions flattened, subchapters present (from all editions, sorted)
mpc-hc: editions none, subchapters present
all of the above: ChapterTimeEnd has no function

If ChapterTimeEnd is to actually have some function here - what would it 
be ?

2) What is the "reference" behavior if EditionFlagOrdered=1 ?

This is far more interesting - actually, the only splitter trying to do 
something here is Haali (all the other ones seem to silently ignore 
EditionFlagOrdered).

I'd expect Haali's typical behavior is "reasonable" - although it pretty 
much *requires* ChapterTimeEnd to be explicitly defined on every chapter 
- if it's not, then Haali interpretes such chapter as *out of the flow* 
(relative to "new" playlist-based clip) which may lead to somewhat 
unexpected results. For example consider:

Clip's total length = 23

EditionFlagOrdered = 1
chapter 1 start = 5
chapter 1 end = 10
chapter 2 start = 15
chapter 2 end = 20
chapter 3 start = 5
chapter 3 end = 20
chapter 4 start = 21
chapter 4 end = 22 or undefined

- the effect of the above, when 'chapter 2 end' is explicitly set:

4 ordered chapters are available, of lengths: 5, 5, 15, 1 - spanning 
expected parts of the original clip. the "new" clip as presented by the 
player will have 26 minutes.

- the effect of the above, when 'chapter 2 end' is *not* set:

3 ordered chapters are available, of lengths: 5, 5, 15 - spanning 
expected parts of the original clip. the "new" clip as presented by the 
player will have 25 minutes. 4th chapter will be available as well, with 
timecodes relative to the "new" clip, so with reference to original clip:
[5..10] [15..20] [5..20] [16..20]
                             ||
             "new" clip = [21..25]

If "4th" chapter had timecodes beyond the "new" clip (e.g. if we removed 
chapter 3), the playback would be permanently stopped.

If any subchapters are defined - their interpretation is precisely as 
above (ITOW - (sub)+chapters are just a visual clue for the sake of the 
interface, well almost - the fallback end times still have to be taken).

The question:

Is this correct interpretation ? According to 
http://www.matroska.org/files/matroska.pdf - ChapterTimeEnd if not 
present, it has clearly defined fallbacks - in order, *original clip's*: 
next chapter's start, parent's end, segment's end. There's no mention 
anywhere, that "if there's no ChapterTimeEnd, the chapter is to be 
treated as relative to the "new" clip (playlist)". And it kind of leads 
to a mess of context-dependent interpretation of ChapterTimeStart.

So, shouldn't Haali (and all other splitters) follow this behavior ? 
Looking at the example above, I'd expect (fallback to segment's end):
[5..10] [15..20] [5..20] [21..23]

and "new" clip would have the length of 27 minutes.



More information about the Matroska-users mailing list