Find herein, my comments on some of Emmanuel's remarks.
> ContentAvailable and Group IsRunning event.
> The doc stated that MTF want to add a note in 9.3 saying that all
> ingredients have their content available when the group isRunning event is
> generated.
> I understand that this would be interesting for some of you since it should
> simplify things but it seems to introduce a contradiction where there
> wasn't one before. IsRunning is a synchronous event while ContentAvailable
> is an asynchronous one. I definitely don't see how a synchronous event may
> occur after some asynchronous ones.
> In order to do this, MTF wants to redefine the activation behaviour of the
> Root class. Heavy change at this step of standardization IMHO. Moreover, I
> do have the feeling that we go round in circles.
I agree with Emmanuel, this is a TECHNICAL CHANGE, which is not
completely clarified IMHO.
In addition, the clarification about ContentAvailable event seems to be
again a
TECHNICAL CHANGE.
> Preload, Unload
> It seems nice, great, to me that Unload and Preload can be targeted to
> object without content. This seems essential to me since many objects
> (rectangle, link, etc...) must be prepared before being targeted an action
> and you often don't want to activate it in order to be able to do this.
> Here, it seems that these actions were initially provided to prepare the
> content while in fact we need something to make an object available to fit
> many actions' provisions of use.
Emmanuel is right. Moreover, such a need could be satisfied by using
Run and Stop elementary actions in an OnStartUp, without introducing
such a change.
> Regarding Issue 7:
> It is said : "It is an authoring error not to handle this situation properly".
> I don't like this attitude. To me, when MHEG just sets a trap to authors,
> it is just less likely to be used in the future.
Agreed:-) And a clarification seems to be still needed about the engine
behaviour
in such cases.
> The fourth point (Clarification : The number of MHEG stream components can
> not change) would rather be "The number *and type* of stream components. It
> seems important to me that the new stream content is of the exact same type
> in terms of multiplex components as the initial one.
> Moreover, MTF wants to let the application domain specify how to deal with
> encoded substreams. I think we should at least advise to reuse the same
> componentTag in the new stream.
> Regarding clarification for 37.1.2.
> The term "clarification" seems funny to me since there is no clarification
> but MTF simply lets the application domain deal with this problem. Again, I
> think that we should suggest to use the componentTag attribute of the
> stream components to assign substreams to objects in the multiplex content.
I think that the SetData on streams in realy an application domain
feature.
Indeed, the constrainst & semantics may be different from standalone to
broadcasted environments.
Therefore, what should be clarified is what the application domain shall
specify.
> Issue 36: lineOrientation.
> Again, this is not a clarification but a workaround. This seems really bad
> to me. There are still so many things that depends on the application
> domain that this kind of basic description should definitely be clarified
> in MHEG-5.
> Especially when it is said in MHEG that "these attributes may be ignored"...
Agreed:-) Moreover, such a clarification would require to specify what
the application domain shall specify.
> Issue 11:
> The note to be added at 14.4 could be clearer IMHO, by specifying when a
> variable is passed as a reference or as a value. To me, if the indirect
> reference option is used, it is the value contained in the variable that is
> passed to the program. But a program may rather need to get the objectRef
> of the variable itself in order to use it for In and Out. In that case, the
> indirect reference may be ignored.
I think that the difference between "by value" and "by reference" is
about
what happens when the called program modifies the variable's value.
But this note (as far as I understand it) address what happens before
the program is called,
i.e. during the evaluation of the paramerters.
IMHO, the ":IndirectRef <objRef>" tag could be viewed as the C language
instruction "* <pointer>".
And that's what it does for all other elementary actions, i.e.
retrieving the value of the referenced variable
before passing it to the parameter of the elementary action.
Best regards,
Guillaume
-- Guillaume AUDEON - CRIL INGENIERIE 5 square du Chene Germain - 35517 CESSON SEVIGNE (France) +33 2 99 38 43 43 - mailto:guillaume.audeon@cril-ing.fr