[Matroska-devel] Control Track proposal draft

Steve Lhomme 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
etc

- 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 :
<tracks>
   <track>
     <UID value="1234"/>
     <type value="audio"/>
     <enable value="1"/>
   </track>
   <track>
     <UID value="4567"/>
     <type value="audio"/>
     <enable value="2"/>
   </track>
</tracks>

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 :
<event_unregister value="EVENT_SKIP_TO_NEXT_RELEASE"/>

> 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, 
EVENT_HOTSPOT_3_SELECTED, etc...

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 mailing list