you wrote:
> As you said, there were only implementors of engines, not
> of authoring tool.
I hope I have not said that. There have been also authors, eg. myself
(with low-level MHEG programming), but also Rene who implemented
automatic converter from some propriatory multimedia format from a CDROM
app to MHEG, and Andreas Kraft, who has considerable experience with
automatic CGI-like MHEG object production. Probably all engine
implementors have developed apps.
> That's why I regret I could not come because I'm convinced that you
> could make something that is clear for an engine implementation but that
> makes MHEG not really usable for some applications.
I do not think that either (however, you would have had the chance to
try :-) I do not want to discuss the usefullness of MHEG in this forum,
most of the folks on this list should have a general idea about Pro and
Con of MHEG.
Nevertheless, clarification:
MHEG features are driven by STB environment restrictions during RUNTIME.
MHEG features are not driven by ease of authoring.
We have had many discussions during the MTF meeting about that target
environment. One of the main aspects is memory usage. Most STB boxes can
not afford to store some background images somewhere (except in the MPEG
Framebuffer) just in case that some application requires to hide and
expose some part of the image by a rectangle.
So, in addition, a good authored application takes the target domain
into account (including the interchange path such as DVB), not the other
way around. It might be required due to the "full system view" that
quite strange authoring is required, e.g. using many small rectangles
instead of one (since that might make the refresh simpler), or
intelignet usage of the stacking order, etc. Otherwise it will not
perform as the author expects (and the author looses the job).
> >One very important thing which I think you may underestimate sometimes
> >is the "ease of use of MHEG". Frankly speaking, there is NONE. Moreover,
> >there is no intention to have some.
>
> That's definitely a problem IMHO. I understand what you try to explain,
> Klaus, but I don't fully agree with you on this (see below).
I see that conflict.
> >...That is up to the authoring tool. It is like Visual
> >Basic and pentium assember.
>
> OK, I see what you mean but it's not completely true IMHO. Just let
> me take an example. The ListGroup class defines a "GetCellItem"
> elementary action. This action is not needed in low-level only
> description language. We could obtain the same information with a
> combination of "GetListItem", "GetFirstItem" and "GetTokenPosition".
> ...
> ... I'm sure we could find other examples like these in MHEG.
I am sure as well.
During development of MHEG we have had quite much of these discussions,
how to make the "language" simpler (i.e. how to make the parser
smaller). Most of the doubles are there due to actual implementation
calculation, i.e. how much processing would be needed as tradeoff to
parser smplification, and what is "very" simple to implement (for the
engine). I am pretty sure that we could now rediscuss and have some
different feelings (since there are now more implementations for the
runtime available) but the MHEG5 IS is the result of the findings in
these early days.
> On the contrary, there is sometimes a lack of low-level actions.
Again, that was the state of the art during MHEG5 development. You may
not want to believe in which detail the discussions have been.
>... Run on running Objects ...
> The action will be simply disregarded. But you are not allowed to preload
> an Ingredient that is already available. Could you tell me why ?
It is allowed. Since it is the provision of use of the action, it will
be ignored. Which is an intended behaviour.
> I regret there don't seem to be many application authors on the MUG list.
> If any, please give your opinion.
I think there are authors in the MUG.
At GMD FOKUS, we have produced applications using authoring tools (such
as MhegDitor :-) and Toolbook), using converters, using VI, using
macros, using CGI scripting. I know others who have done similar things.
The folks doing that (including myself) may not be enthusiastic about
the "rich" set of MHEG functions, but once understanding how it works
(and why), we have developed quite much apps which run on TV oriented
devices: EPG, Language Courses, Weather forecast, VideoOnDemand,
Database Information services, simple Games etc.
Its all possible, once understanding the application domain.
All the best,
Cheers,
- Klaus
-- GMD FOKUS German National Research Center for Information Technology Klaus Hofrichter Kaiserin-Augusta-Allee 31 D-10589 Berlin Germany mailto:hofrichter@fokus.gmd.de http://www.fokus.gmd.de/usr/hofrichter P: +49 30 3463 7211 Fx -8211 There is a reexamination, but no reparty