[Ogg a11y] a generic mapping of text codecs into Ogg

[ogg.k.ogg.k at googlemail.com]

> According to what I read (e.g.
> http://www.alanflavell.org.uk/charset/text-direction.html) character
> sets have implicit directionality. Further, since it is possible that
> bi-directionality in text is required, directionality is treated more
> often as a property of a piece of text, rather than a general property

I agree with this, but my point is different:
Some Unicode glyphs do indeed imply directionality, but only as a
l2r/r2l sense. Most of the time, you will be able to split text in such
chunks. However, I do not think there is any indication of whether
the text should be vertical or not. This is comforted by reading the
last paragraph of "Content, or Presentation ?" in the link you quote:
> (e.g. http://www.nirdagan.com/hebrew/standards.html). As for

> horizontal text, this seems to be regarded as a formatting matter.
> Thus, I don't think there is a need to do more than there is right
> now.

I assume you mean vertical text: yes, it is regarded as a formatting
matter, it seems. If you consider this outside the purview of the text
codec specification, then fine. Pango actually does something similar,
where vertical text is just rotated, and the bidi algorithm is used as is,
as if the text was horizontal.
I'm just mentioning this as I had to go through these issues when I
recently implemented vertical text rendering in libtiger.

>> It also seems it would be good to have a separate package that would map
>> those
>> canonical types to i18n strings, so media players can be relieved of
>> having to
>> track both changes/additions to the list and their associated translations
>> in
>> various languages (similar to the maintained list of translations of ISO
>> 639
>> language tags).
>
> As with message headers, I would simply prescribe ASCII here. Done so
> in the wiki.

Not my point: while these category identifiers are ASCII, you will want a
player to refer to them, when presenting a list to the user, by "normal" names
in the user's language. For instance, referring to a SUB track as "subtitles"
in English. What I meant was that maintaining a list of per language
translations
of these categories would be a good thing for players wanting to display the
categories as "human readable" strings.

> We are focusing here on *text* codecs (which makes me very reluctant
> to incorporate any image stuff at all - not sure that can be held up

That's fair enough.

> My intention with the keepalive is that the previous packet in a text
> codec stream is being repeated to bridge a long gap in the stream and
> enable faster seeking. So, while we could just make it a special empty
> packet that links back to the previous packet, I would think that at

Not make it so, just allow it, at the codec's discretion, I think, since a
decoder does not need to know anything about the actual contents.

> As for bandwidth concerns - the idea of the repeat is to bridge a
> "period of hunger". Also, text packets tend to be really small. So, I
> see no harm in repeating the full packet - as long as it's marked as a
> copy and therefore a continuation of a previous text segment.

For overlapping events, you will have to either repeat *all* active events
in a repeat packet, in which case you cannot have this packet be a copy
(modulo packet type) of the previous data packet, since it might have to
cover any number of them.
Unless you have a way to tag those repeats with the 'ID' of a previous
packet, to avoid having the reference being the previous one, but any
one before (presumably not too far before).

>> EOS: while a separate EOS page is not mandated anymore, the wording "For
>> text
>> codecs, there is a sequence of header pages, a sequence of data pages, and
>> an
>> EOS page, which finishes the stream." still suggests that the EOS page
>> is separate.
>
> Ah yes. I have removed "For text codecs", since that is confusing.

What I find confusing is that the wording distinguishes between "a sequence of
data pages" and "and an EOS page". It implies that the second isn't part of the
first. I may be the only one to read this thus though.

> The identification of a keepalive packet is not important for seeking.
> For seeking purposes, it is only important to get a backlink to the
> first still active data packet, and that can be fulfilled by a repeat
> with an accurate granulepos. However, it is important from a logical
> POV to identify the packet as a repeat and not as a new starter,
> because otherwise we can have a different "decoded" data to the one we
> "encoded". That's not acceptable.

I do not understand what you mean here by different data.
But, while a repeat fits the bill, mandating it enforces the repeat, for no
good reason since the data inside is unneeded for seeking. If you think
the extra bandwidth is OK, then fine.

> I believe it still is an in-order repeat of the previous packet. We
> could add to these repeat packets a further granulepos that points to
> it's original page. I am wondering if it is necessary though.

Unnecessary if you mandate the repeat to be *of the previous packet".
But doing so forces you to either forbid overlapping events, or send a
repeat containing data for all currently active events (in which case,
technically, it's not a copy of the previous packet anymore, but of the
N previous ones (with possible "dead" packets in between)).

I apologize if I'm sounding pedantic, here, but hey, it's supposed to end
up as normative :)