Subject: RE: [AVT] one question about the MPEG-4 generic RTP payload format(multiSL)

From: [email-masked]
Date: Thu, 31 Jan 2002 20:00:48 +0100

Guido,

you write:

"If (but only if !!! ) an alternative solution is found that fulfills the 
requirement"

**********

OH but I can think of several ways to fix the problem !
and they would be better than that half hearted attempt !

i.e. the hypothetical existence of an alternative solution does not change 
the conclusion:
because the point is that ANY solution is irrelevant.... to *this* draft.

specifically from an IETF point of view any solution
need not and should not be be inside a RTP payload format !!

(yes ! finaly I think like an IETF guy, amazing no ?)

why ?

1.

you *cannot* use this  "should not" for interoperable synchronisation "as 
is"
because a "should not" is not enough to create a normative behavior
at the SENDER side, which is the issue at stake here...

specifically the only thing that a "should not" allows you
is that if you design a solution that would work on top of it
 you may feel a bit better about not using random offsets,
hu ? .. ;-)

==> you still need to define a specification for it, because
outside of this specification you will not have interop !!

2.

also you cannot have more that a "should not" because
there are too many RTP implementations out there that
assume/create a random offset AND we want to
interoperate with them ...

==> unless for a specific application you *specify separately*  that only
server X can be used ... etc .... back to square one!

*******************

in conclusion:

since you *will* have to specify something on top of it to *really* make 
it work,

why complicate/twist the RTP payload format ?

hum?

********************

I propose instead that we make another draft that will define how
to synchronize an RTP source using this payload format
with another non-RTP source of MPEG content ...

THAT would be the proper IETF way to proceed ...

Regards,

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

Franceschini Guido <[email-masked]>
Sent by: [email-masked]
01/31/2002 18:53

        To:     Philippe Gentric/LIM/CE/PHILIPS@EMEA1
[email-masked]
        cc: 
        Subject:        RE: [AVT] one question about the MPEG-4 generic RTP payload 
format(multiSL)
        Classification: 

Philippe, all,
 
The "SHOULD NOT" was introduced for enabling synchronization of MPEG-4 
content delivered with RTP and MPEG-4 content delivered somehow 
differently.
 
I understand that this rule represents an ugly exception within RTP
I am less convinced that this rule represents as well a real security 
hole, since in MPEG-4 timestamps as well as sequence numbers are allowed 
to have any starting value.
 
If (but only if !!! ) an alternative solution is found that fulfills the 
requirement, then I would obviously not object to cancel that rule. But 
please show an alternative solution first!
 
Best regards
 
Guido Franceschini
TILAB - Multimedia Division
Via G.Reiss Romoli 274
I-10148 Torino, Italy
tel + 39 011 228 6137
fax + 39 011 228 6299
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, January 31, 2002 5:43 PM
To: [email-masked]
Subject: [AVT] one question about the MPEG-4 generic RTP payload format(multiSL)

hi all, 

There has been a lot of oral traffic and email traffic on other reflectors 
(and recently about the emmerging H26L work !) about the issue that the 
draft 
currently recommends that RTP time stamps SHOULD NOT 
have random offsets, which is contradictory to the SHOULD in the RTP spec 

Originally the "should not" was introduced because there was a concern 
that random offsets 
would make it difficult to synchronize one RTP source with another non-RTP 
(say downloaded .mp4 file) source. 

Recent discussions indicated that this issue could rather be delegated to 
an application 
integration stage (or to another "hat" specification such as the ones 
issued 
by other bodies, 3GPP, ISMA, whatever) 

 I want to ask on this reflector: 

**************** 
would anybody object if this "should not " is simply removed i.e. 
the "classical" RTP time stamp offset is always assumed ? 
***************** 

NB: Assuming that nobody objects I dont plan to add any explanatory 
comments 
in the draft itself (that non-RTP source sync is out of scope). 

Regards, 

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

---

From: Dave Singer <[email-masked]>
Date: Thu, 31 Jan 2002 15:49:25 -0800

I'm with Philippe

the packaging spec that allows both RTP and other delivery means 
should specify how the time-lines are aligned.  Only one solution is 
using the same bit-values;  the kind of RTP-NTP mapping that RTSP 
does is another.  Yet a third is simply knowing that the two pieces 
of content have a simultaneous start, and driving them from the same 
clock.  There are many.  Such a spec should also discuss how to 
manage buffers when the two sources are not synchronized (basically, 
you have to run at the speed of the slowest source and buffer the 
faster ones).  It's a bigger question than a mere "should not" in 
this spec.
-- 
David Singer
Apple Computer/QuickTime

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt