Subject: Re: [MMUSIC] Aggregate Control URI

From: [email-masked]
Date: Tue, 15 Jul 2003 10:58:47 +0200

>> I'm not sure I understand still why MUTE is needed.  All it does is PAUSE
>> a single stream.  The MUTE complicates the RTSP server state machine
>> in exactly
>> the same way that a non-aggregate PAUSE down.
>>
>> It's the same thing called something different.
>
>Not exactly the same thing. You are correct that MUTE can be realized
>using one RTSP session per media and do all media synchronization at the
>client side. The MUTE/UNMUTE proposal is a separate extension draft and
>will  need further review. You might be correct that MUTE/UNMUTE are not
>in fact needed.

one difference/advantage is the need to specify a target media time with PLAY,
with MUTE/UNMUTE it could be optional:

for example if I was to SETUP 2 audio streams and MUTE one from the start,
I want to be able after some playback time to send MUTE on the one playing
and UNMUTE on the other one, simultaneously (queued RTSP commands)
, without specifying the target time:
i.e. for the server it means "now" or "asap", and it should make sure that the media
is sent in a way that there is "no gap".

=> it is "aggregate control" in the sense that the server must be aware of the NPT relationship
between these two streams

=> it is like when you aggregate PLAY audio and video
the server must send audio and video data that are at the same (NPT) media time.

(BTW this would also be a useful step for stream switching;-)

regards,

Philippe Gentric
Software Architect
Philips MP4Net
[email-masked]
http://www.platform4.philips.com

                                                                                                                                           
                                                       To:   Bill May <[email-masked]>                                                     
                                                       cc:   [email-masked]                                                               
                                                        (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS)                                         
                                                       Subject:    Re: [MMUSIC] Aggregate Control URI                                      
               Magnus Westerlund                                                                                                           
               <magnus.westerlund@ericsson.            Classification:                                                                     
               com>                                                                                                                        
                                                                                                                                           
               Sent by:                                                                                                                    
               [email-masked]                                                                                                       
                                                                                                                                           
               15/07/2003 09:52                                                                                                            

Hi Bill,

Bill May wrote:

> Thomas,
>
> I think that we can agree that this new specification would not be
> backward compatible with existing RTSP session.

To my knowledge the changes result in a subset of the functionality that
RFC 2326 specifies. This subset is working in this regard the same way
the original specification. In our discussion there where no
implementations that actually use the functionality of having individual
PLAY/PAUSE in a aggregated session. The reason of the change was
basically get the protocol to be interoperable. There where so many
strange things when you allow individual media control within an
aggregated session. By requiring all media control methods (PLAY and
PAUSE) to work on the aggregated the whole issue was resolved and
everything becomes consistent. So the interoperability issues of this
change seem minor and the client will get clear indications through
error codes that it attempts something not allowed by the server.

>
>
> To me, it does not seem like for good reason.  Not enough bang for the
> buck, but perhaps I am still missing something.
>
> As long as you are aware of this and have done so intentionally, that's
> cool.  But IMO, I would not not be making these changes (adding MUTE,
> requiring PLAY/PAUSE to be aggregate as opposed to stream based) in
> order to make wording or a state machine clearer.
>
> In fact, the MUTE complicates the state machine in the exact same way
> that a non-aggregate PAUSE does.

No it doesn't. As MUTE/UNMUTE only switch on and off the media delivery
and do not effect the timing of the state and in what state machine
state it is, it does not complicate things.

>
>
> More below:
>
> Thomas Zeng wrote:
>
>>> I can see a scenario where you might want to stop the video, but still
>>> maintain
>>> the audio.  In this case, you have 2 or more streams running, and the
>>> client
>>> wishes to stop 1 of them.  This is a perfectly legal scenario.
>>
>>
>>     [Thomas Zeng]  There are two ways to do what you want here: 1) issue
>> teardown on the audio track. 2) perform a MUTE on the audio track.
>
>
> Doesn't teardown now need to be aggregate ?  So that wouldn't work.

Teardown can be used both aggregated and non aggregated.

>
>
>
>>> Can you please expand on why it doesn't make sense to allow streams to
>>> be controlled separately ?  I've done most of my work on the player
>>> side
>>> with
>>> the idea that the streams could be seperate, so most likely I'm missing
>>> something.
>>
>>
>>     [Thomas Zeng]  If two streams belong to same RTSP session, and you
>> issue PLAY on one stream, what would be the state of the overall
>> session ?
>> what would be the NPT  (Normal Play Time) of the session? If I recall
>> correctly, if PLAY/PAUSE were allowed on each track in a
>> mutli-tracked RTSP
>> session, the RTSP state machine would break.
>
>
> I'm not sure that I understand why the state of the session is important.
> The server would be issueing the required streams.

Have you tried to implement a correct minimal implementation of the RFC
2326 defined RTSP server? If you had I don't think you would ask this
question. When I performed the implementation this resulted in a 50+
questions regarding how things should work that directly related to
expected behaviour and interoperability.

>
>
> The NPT of the session would be whatever the player decided it would be -
> it can derive this from the RTPInfo, and decide how it wants to deal
> with it.

I don't think it is this simple. In a session with two aggregated
session you will have actually three different playout clocks if you
allow individual PLAY/PAUSE.
- The aggregated session playout time
- Media 1 playout time
- media 2 playout time.

When you perform an individual PLAY on a pause media using the media URL
what should happened, what timers should be started? If you after that
performs an aggregated PLAY, does that replace the previous media
playout, or does it only start all not already running media? This is a
rat hole.

>
>
> Are you defining a specification on how to develop a server (which is
> what
> a state machine would imply) ?  Or a method of interoperability ?

This is a interoperability problem and a fix to a under specified part
of RTSP.

>
>
>>> Why ?  To me, aggregate (or control of the entire session) control and
>>> non-aggregate control (or control based on each stream) can be used
>>> at the same time, and should be allowed.
>>
>>
>>     [Thomas Zeng]  Yes, you are right here. The decision by the RTSP
>> task force was to let PLAY/PAUSE be aggregate, while SETUP/TEARDOWN and
>> MUTE/UNMUTE be non-aggregate (note MUTE/UNMUTE is defined as an
>> extension to
>> RTSP core spec).
>
>
> I'm not sure I understand still why MUTE is needed.  All it does is PAUSE
> a single stream.  The MUTE complicates the RTSP server state machine
> in exactly
> the same way that a non-aggregate PAUSE down.
>
> It's the same thing called something different.

Not exactly the same thing. You are correct that MUTE can be realized
using one RTSP session per media and do all media synchronization at the
client side. The MUTE/UNMUTE proposal is a separate extension draft and
will  need further review. You might be correct that MUTE/UNMUTE are not
in fact needed.

Best Regards

Magnus Westerlund

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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Jul 2003 17:45:43 +0200

Hi Philippe,

See below:

>and UNMUTE on the other one, simultaneously (queued RTSP commands)

It is not queued RTSP commands, it is pipelined commands.

>is sent in a way that there is "no gap".

Yes, not specifying a range for MUTE will make it happend directly. So 
by unmuting before muteing will ensure seamless switching.

>between these two streams

If the media streams that a client are muteing and unmuting is in the 
same session they are running using the same NPT timestamp.

>the server must send audio and video data that are at the same (NPT) media time.
Yes,

>(BTW this would also be a useful step for stream switching;-)

I don't know that. The SETUP overhead is considerable.

Best Regards

Magnus Westerlund