[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