thank you for your comments on the MTF proposals.
Emmanuel:
> First, let me give a suggestion about the format of the documents posted on
> MTF site.
I saved the document in the "Word95" format, so you should be able to read
it with the "old" version.
> I suggest to post documents in a more standard form : HTML is fine but if
> it is too difficult to generate properly, why not RTF or PDF files ?
Yes, this is a good idea. I will keep this in mind.
Emmanuel:
> 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.
I would have guessed that the change for the ContentAvailable event would
cause much confusion. Maybe I can clarify this a little bit.
The problem with this event occures in an carousell environment when external
content is not available at the same time the object prepares. Therefore, the
praparation behaviour as it is written now says that the content is retrieved
asynchronous. Otherwise, the preparation behaviour would block the whole
engine. The question is now, what happens if an object is activated and
the content is yet not available? Therefore, the asynchronous ContentAvailable
event is synchronised with the Activation behaviour, i.e. the behaviour
blocks if the content for the object is not available.
It is the authors responsibilty to activate an object with external content
only if the ContentAvailable event for this content has been raised.
This is very important in a broadcast environment.
I think that these things are not very clear by reading the standard.
You can already interpret the standard in this part at least two different
ways.
Guillaume:
> 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.
For some people it might be a technical change, for others it is a
clarification.
Emmanuel:
> MHEG-5 DIS only had an IsAvailable event that has been separated in 2
> different events IsAvailable and ContentAvailable. Today, it seems we want
> to join them again. Could someone explain me why it was decided to separate
> the events for IS... ?
I hope the explanation helps. The important message is, that you can not
always wait for the content to arrive, especially not in a broadcast
environment. An engine can do other things in the mean time.
Emmanuel:
> 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.
My opinion is that it was just overseen during the standardization. Of course,
the name implies only a preloading of the content, but the action also prepares
an object. For example, with the change in the display stack behaviour from
DIS to IS the necessarity of putting an object in the display stack was
forgotten.
Guillaume:
> Moreover, such a need could be satisfied by using
> Run and Stop elementary actions in an OnStartUp, without introducing
> such a change.
Yes and no. There is a problem in the standard with the Activation of objects
before the Scene is running. Another problem is that you would not always like
to Run a particular object. And, you have to Run all the objects because you
want to have them in the correct order in the Stack...
However, an object which has a visiual representation (like a Rectangle)
would most likely cause some flickering on the screen.
No, I think this is really a minor change.
Emmanuel:
> 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.
Oh, I think that the standard doesn't prevent an author from creating an
MHEG-5 application which breaks every engine, it just takes a Scene and two
Link objects.
The standard can not handle every situation. So, imho a lot of responsiblity
lies at the authors side.
When an author is aware of a problemematic situation and doesn't handle it
then it is an authoring error. The note should give a hint to authors that
this part might cause problems.
Emmanuel:
> Regarding Issue 8 (setData on streams) :
>
> 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.
Right, good point.
Emmanuel:
> 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.
Yes.
Emmanuel:
> 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.
Right, it is a note saying that we don't know.
Emmanuel:
> 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"...
I already addressed this issue some weeks ago on this mailing list and there
are many different opinions about the orientation of lines, characters etc.
We discussed this issue during the meeting and had also different opinions.
Maybe Guido, can you help me here clarifying were the problem is?
Guillaume:
> Agreed:-) Moreover, such a clarification would require to specify what
> the application domain shall specify.
Concerning the Text class an ADD has quite a lot to specify, anyway.
BTW, you are right, a chapter which clarifies the open points for an ADD
would be very helpful.
Does anybody volunteer? :-)
Guillaume:
> Issue 11:
> 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.
The question is whether only variables which are passed via the
":IndirectRef" mechanism can be used as "out" variables.
One (imho wrong) interpretation could be that if the parameter is an
ObjectRefVariable object the value of this variable is taken as an address
to the target variable...
Emmanuel:
> (ListGroup)
> For instance, there is no provision in MHEG about the possible values for
> the FirstItem attribute. The figures in the standard even suggest that it
> may take any value. However, it seems that some engines introduce some
> constraints about it.
Engine constraints are always a problem but this definitly something the
standard cannot deal with. This starts with memory constraints, speed,
size of an Integer etc...
I am afraid, this is an issue for an ADD, too...
Emmanuel:
> But MHEG don't say anything about the case FirstItem
> is 0 or even negative. We should also clarify what occurs when FirstItem is
> greater than the list size (when WrapAround is either False or True).
> How do you all have dealt with these cases ?
Andy?
> I expect many more clarifications from the MTF.
Of course, there is a lot of work to do. Help is always appreciated.
Best regards,
Andreas
-- o _ Andreas Kraft (\_|_) GMD FOKUS, kraft@fokus.gmd.de, +49 30 3463-7232 T> ] [ The sky is the limit