RE: [MMUSIC] End of movie signalling

["Spiros Spirou" <[e-mail]>]

Hi Thomas,

Thanks for the suggestion. I had thought about that but I am trying to cover
cases where the server is not implementing RTCP as well (oh yes, these heathens
do exist). Anyway, the four reasons you are mentioning in Appendix A of
draft-ietf-mmusic-rtsp-announce-00.txt against the use of RTCP BYE as an
end-of-stream signaling mechanism are certainly valid in general.

I am oriented towards maintaining a presentation clock (npt) in the client for
detecting EOS locally in the case of RFC2326 servers. This has the added feature
of being able to display to the user the running play time, remaining time etc.
just like DVD players can. I could add support for
draft-ietf-mmusic-rtsp-announce-00.txt as it progresses in order to be forwards
compatible.

Spiros

-----Original Message-----
From: Thomas Zeng [mailto:[e-mail]]
Sent: Thursday, February 03, 2005 6:43 PM
To: Spiros Spirou; Joerg Ott
Cc: IETF mmusic WG list
Subject: RE: [MMUSIC] End of movie signalling


Hi  Spiros:

Your transport is RTP, right? Can you not use RTCP BYE to signal end-of-stream
until draft-ietf-mmusic-rfc2326bis-08.txt and
draft-ietf-mmusic-rtsp-announce-00.txt are ratified?

Cheers,
-thomas

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf
Of Spiros Spirou
Sent: Thursday, February 03, 2005 4:08 AM
To: Joerg Ott
Cc: IETF mmusic WG list
Subject: RE: [MMUSIC] End of movie signalling


Hi Joerg,

Thanks for the pointers. Reading between the lines, I would say that there is no
provisioned mechanism for signaling end-of-stream using RFC2326 means only.
Implementations wishing to be backwards compatible should probably revert to
costly tricks. Is this correct?

Spiros

-----Original Message-----
From: Joerg Ott [mailto:[e-mail]]
Sent: Thursday, February 03, 2005 10:23 AM
To: Spiros Spirou
Cc: IETF mmusic WG list; Joerg Ott
Subject: Re: [MMUSIC] End of movie signalling


Hi Spiros,

what you are looking for is being addressed in an addition to the
revised RTSP spec: draft-ietf-mmusic-rtsp-announce-00.txt defines
a generic announcement mechanism that, among other uses, the server
can use to signal end-of-stream to the client.

Please also take a look draft-ietf-mmusic-rfc2326bis-08.txt,
the updated RTSP spec that is supposed to override RFC 2326 in the
not too distant future.

Joerg

>
> Hi,
>
> In a VoD scenario, I am trying to find a STANDARD way to detect the end of a
> movie in the client in order to free the associated resources for control
> (RTSP), transport (RTP) and play-out.
>
> RFC 2326 states that when the server reaches the end of the movie it "...
> reverts from state Playing ... to state Ready ...". From there "... it MAY
> revert to Init and tear down the RTSP session if it has not received
> \"wellness\" information, such as RTCP reports or RTSP commands, from the
client
> for a defined interval, with a default of one minute." Both of these state
> changes happen without sending any notification to the client.
>
> Now, the client could detect the end of movie on its own by maintaining a
> presentation clock, set initially by the Range header in the PLAY reply.
> However, this would probably involve polling, which seems incorrect given the
> usual scarcity of resources in the client platform. A variant of this method
> would be to poll the server by sending PLAY requests without a Range header
and
> reading the current presentation time in the Range header of the reply. This
> adds waste of bandwidth to the waste of local resources.
>
> Any ideas?
>
> Spiros
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mmusic
>



_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic



_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic