OK, I agree and understand. But that way, is there a difference between the
time the contentAvailable and the streamPlaying events (both asynchronous)
are generated ? (I think that the stream can begin playing as soon as the
content is available, can't it ?)
>> The streamStopped event definition seems not clearer to me :
>> [...]
>> As the standard says "the last piece of *content* data", I would considered
>> that this event is generated as if there were a counterTrigger on the last
>> time code of the stream. Does this mean that the StreamStopped event should
>> be generated each time the stream loops, if its looping attribute specify
>> this, even if the stream continue playing ?
>> In this case (stream looping), shall a streamPlaying event be generated
>> immediately after the streamStopped event ?
>
>Interesting question. I am not sure myself. I would say that in case of
>looping the StreamStopped event is generated when the last piece of data of
>the stream has been presented to the user and the stream has finished the
>last loop.
>Then the stream stops.
OK, that seems logical to me.
If everybody agree with that, we could perhaps make a clarification in
37.1.2, Looping attibute, or rather in 37.1.3, counterEndPosition.
There, the next sentence :
"The stream will stop automatically when it hits this position. The
StreamStopped event is generated."
could be clarified like this :
"Depending on the looping exchanged attribute, the stream will either stop
or loop automatically when it hits this position. If the stream shall be
stopped, the StreamStopped event is generated."
>> But may a streamStopped event be generated if the stream is deactivated
>> before the last frame has been shown ?
>
>Yes, because the last piece of data has been presented and the stream
>stops.
>
>Maybe it helps if you regard the stream as a streamed file (which it actually
>is most of the time...) when the stream is "closed" the streaming ends.
OK, Andreas, I understand that the stream could be continuous and never has
an end, especially in ITV environment. I'm fully aware of this, of course.
But according to 37.1.3 mentioned above, it seems that the streamStopped
event could be related to the counterEndPosition attribute, that gives a
virtual end to an endless stream, right ?
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.
If it seems obvious for everybody, why not clarifying ? IMHO, the sentence
in 37.2 :
"it is generated as soon as the last piece of content data (video frame,
audio sample) has been presented to the user"
can be confusing because the last piece can be understood as the frame or
audio sample situated at the counterEndPosition in the stream.
The Deactivation behaviour could be modified at step 2.
"2. If the stream is playing :
- Stop playing all active StreamComponents
- Generate a StreamStopped event"
What do you think ?
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 ?
Perhaps, we should at least alert the author of possible unexpected result
if he use a preload action targeted to a stream object.
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