[Matroska-devel] Control Track proposal draft
steve.lhomme at free.fr
Sun Aug 15 18:55:04 CEST 2004
Steve Lhomme wrote:
> In some case it would be useful to get/set a list of values. Like the
> like of tracks available for playback or the chapters that are before or
> after a given timecode.
Like the _number_ of tracks...
> Some examples of named variables :
> - playback mode (integer - read/write) : stop, pause, play
> - timecode scale (integer - read/write) : to change the playback speed,
> but is not enough for audio because of the samplerate
> - current timecode (integer - read/write) : allow the jump function
> - current chapter (integer - write) : allow jump to a chapter
The integer is a chapter UID. The chapter can be a hidden one, but not
an disabled one. For this, the Control Track should have a way to
enable/disable a chapter UID (or hide it, or a track UID).
That leads to the list problem. I can think of a few systems :
- something similar to the MIB (IIRC). You know the result is a list,
you need the number of items and you can iterate through that list :
GetNumberOfTracks(), GetNextTrack(), SelectTrack() and for each, you can
read track parameters, using the UID given by GetNextTrack()
- something like properties in SciTE. Where you would have something like :
* track.number = 2
* track.0.enable = false
* track.1.enable = true
* track.0.UID = 1234
* track.1.UID = 4567
- when reading a named value could be return as an XML (or whatever
format) content. For basic variables it would just be something like
<playback_mode value="pause"/> (the same could be used to the value).
But for more complex systems if could be :
This XML (could be written in EBML in the file) is my preferred choice.
The drawback is that if you need just one element you will get the whole
thing at once. But the messages are extensible, eg the return elements
could contain more info depending on the player (the language could be
given) and that wouldn't break anything.
I think the MIB way is too complicated (too many calls for nothing). But
the SciTE way could be another good alternative. As XML it's all based
on strings but doesn't have the parsing complexity needed, and you can
only retrieve the info you need. The same system could be used to set
values. But as it's not hierarchical, it wouldn't fit to create
conditional code and mathematical operations.
> The Control Track should be allowed to set custom named variables.
> Because of memory limits there could have in some players, it should be
> possible to know the max number of available named variables for each
> type :
> - custom max integer variables available (integer - read)
This could be used, in the example of Mike, to store the UID of the next
chapter to jump to after the credits.
The custom variable should have fixed named too IMO. Then it's up to the
author/developper to deal with the meaning of the variables, like a
processor register (that's how the DVD system works AFAIK).
> The code to unregister the event :
> <event_register value="EVENT_SKIP_TO_NEXT_RELEASE"/>
OK, this is ugly. Because from the "player" point of view, you just
register the hook to something else. That means you have to call it
whenever this event occurs. So it should be like this instead :
> 4) Hotspots
> We should be able to set the shape and request a hook on it, and unset a
> hotspot... Will be covered later...
This one is tricky. First we should have a look at what a DVD permits
and see how we can adapt it. IMO it should be scalable enough to allow
Picture In Picture, ie define the content of each hotspot and be able to
put a static picture or a moving picture. As I don't expect it to be
supported anytime soon, it should just be scalable to that... But we
should be able to create basic rectangles (X/Y position, width/height
all in pixel coordinates in reference to the DisplayPixel values)with an
alpha blending level and with a programmable hook. As for custom
variables, on some systems there could be a max number of hotspots
supported, so the hooks could have names associated to the hotspot
"number" like EVENT_HOTSPOT_1_RELEASE, EVENT_HOTSPOT_2_PRESS,
A Hotspot should also have localised names that could be rendered if
there is no image (audio-only file) or for blind people.
More information about the Matroska-devel