Well, I'm not so sure that your definition of ContentAvailable event follow
the standard spirit (see 8.2 : "available in an optimal state"). However,
the note in 8.2 agree that you may choose to give a different meaning in
your engine.
BTW, I think that this "StreamPlaying" event was put in the standard to
give something symetrical to the "StreamStopped" event. That way, we could
simply let the application domain or the engine implementors define when
these events occur. (I'm convinced that some engines could generate both
StreamPlaying and ContentAvailable at the same time but we could let this
as is).
>> In fact, I think that the standard clearly specify that the streamStopped
>> event shall be generated if the stream is stopped because it hits the
>> counterEndPosition. But it is not so clear on whether this event should be
>> generated if the stream stopped playing because it was deactivated.
>
>Good question. Previously I decided not to generate it, but I was
>"convinced" by my colleagues to do it anyway. This has the advantage
>that the application can always trigger upon a StreamStopped event, no
>matter if it stopped by itself or if it was explicitly deactivated.
I see that you also had this question at GMD fokus so let's clarify this as
I proposed in 37.2.Deactivation.2.
>> BTW, as I asked in my e-mail, don't you think that the Preparation behavior
>> of the Stream is pretty unusual, compared to the Group class, when stated
>> that all StreamComponents are activated during the preparation of the
>> stream. In fact, initiallyActive videos of the stream can be viewed (first
>> frame) before the stream is activated. Is this correct ?
>
>No, as I understand it, both the stream as well as the video component
>must be active. You have to set the speed to zero, when you only want
>to view the first frame on startup.
I would find this behavior logical and desirable and I even think that this
behavior was expected by the authors of the standard. However, I think that
the standard is not clear and would even specify what I said here. I
explain:
- The stream class inherits from the presentable class and is used to
synchronise components of the stream multiplex. It is neither a visible
object nor a group of visibles.
- The video class inherits from the visible class and doesn't redefine the
activation behavior.
Consequently, when I read the preparation of the stream, I see that
initialyActive components are activated. Following the activation behaviour
defined at 31.3, step 2, I would say that the video is displayed as soon as
the stream is prepared, even if not playing.
Is there something in the standard that define another behavior ?
BTW, I think that the deactivation of the stream object should also specify
that stream components are deactivated as well. I think that "Stop playing
all active StreamComponents" is definitely not sufficient to be clear and
explicit.
BR,
Emmanuel
__________________________________________________________________
Emmanuel BEUQUE mailto:ebeuque@pratique.fr
MediaServ tel: +33 (0) 2 99 64 35 64
Multimedia consultant & developer fax: +33 (0) 2 99 64 36 65