[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] alignment of layers issue
Hi all,
I can present myself as a co-implementer of an RTP/RTCP suite.
I do use RTCP, base my lip-sync on RTCP and have no troubles with it.
However, when I generate RTCP reports my wallclock-RTPTS mapping is not exact, but suffers from the imprecision of the getTimeXXX functions.
Similarly, when I examine the RTCP reports I receive from other sources, I notice similar issues.
Such imprecision is a don't care for lip-sync.
But it becomes a must care for the layering stuff.
This is a key difference that, by the way, invalidates my current RTCP implementation (and I guess many others).
In my understanding, layered codecs need some exact correlation strategy. Timestamp can be used for that task only if they can be computed and matched exactly. Stretching the RTCP SR to cover this requirement sounds ineffective to me.
The alternative proposed so far, i.e. forcing all layers to share the same TSoffset, is preferable, although I don't like it that much. Indeed, I think that in theory (maybe just in theory) some or all layers could go through "recasting" devices, and such devices might be media agnostic and apply new TSoffsets, thus breaking the alignment constraint. Probably this could be ameliorated by explicit signaling.
For similar reasons (intermediate devices) I believe that any effort on the RTCP SR is prone to corner cases that would invalidate its effectiveness, in addition to clock precision problems on the peer themselves.
I haven't seen in this thread a discussion considering the carriage of an additional, explicit field to correlate the layers. This field could even contain a copy of the original TS itself, or any other "exact" information. Maybe this possibility was already explored and rejected. I can imagine that for the SVC case the requirement of backward compatibility with AVC prevents adding extra fields in the Payload Header of the base layer. Also, the desire of a common solution for the various layered codecs votes against Payload Header specificities. However, did you explored the less efficient but still available usage of RTP Header Extensions? Would this be a viable alternative? I have no experience/knowledge about RTP Header Extension and their management in intermediate devices, though.
BR
Guido
------------------------------------------------------------------
Telecom Italia
Guido FRANCESCHINI
Broadband Solutions and Multimedia Innovation
Via Guglielmo Reiss Romoli, 274 10148 Torino
office +39 011 2286137
mobile +39 335 7669748
> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Ver
> Steeg, Bill
> Sent: venerdì 21 novembre 2008 15.26
> To: Roni Even; Ross Finlayson; avt at ietf.org
> Subject: Re: [AVT] alignment of layers issue
>
> Ross/Roni
>
> I also believe that there are good reasons to implement the full RTP
> suite, particularly for video flows. However, we are "preaching to the
> choir" here. The readers of this list are a self selecting crowd. The
> folks who do not use RTP for video flows do not read this list, and
> probably do not attend the IETF.
>
> It would be interesting to ask other SDOs (like CableLabs or W3C) to
> comment on "the elephant in the room". It may even be more instructive
> to ask implementers who operate outside of standards groups their
> opinion on this matter. I am not sure how we solicit that data, though.
>
> I suspect that most applications programmers do not know that RTP
> exists, much less understand its merits. In many cases, it is these
> applications programmers that decide what encapsulation to use for their
> data flows.
>
> Bill VerSteeg
>
> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
> Roni Even
> Sent: Thursday, November 20, 2008 4:45 PM
> To: 'Ross Finlayson'; avt at ietf.org
> Subject: Re: [AVT] alignment of layers issue
>
> Ross,
> I want to believe that this is not the case. At least for video codec
> you need RTCP for other reasons as defined in RTCP feedback and the
> extensions in the ccm draft.
> Roni Even
>
> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
> Ross Finlayson
> Sent: Wednesday, November 19, 2008 1:56 AM
> To: avt at ietf.org
> Subject: Re: [AVT] alignment of layers issue
>
> At 2:53 PM -0600 11/18/08, Magnus Westerlund wrote:
> > > Anyway, let us assume for the time being, we can make this work
> > with a
> >> relatively complex implementation in the sender as well as in the
> receiver.
> >>
> >
> >This is not complex, it is standard RTCP that you anyway need to
> >implement
>
> It seems to me that there's "an elephant in the room" here. I can't
> help but feel that many (though not all) of the people who are opposing
> adopting the standard RTCP SR-based solution are really doing so because
> they don't want to implement RTCP. I.e., they want to get away with
> implementing only a restricted version of RTP that works just for one
> particular layered video codec (and perhaps also one particular audio
> codec for which they would also align timestamps), without RTCP at all.
>
> If this is really true, then it would be useful if people would come
> clean about this, so that we can address, or put to rest, whatever
> fears/concerns they may have about implementing RTCP.
>
> Ross.
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
>
>
> - - - - - Cisco
> - - - - -
> This e-mail and any attachments may contain information which is
> confidential,
> proprietary, privileged or otherwise protected by law. The information is
> solely
> intended for the named addressee (or a person responsible for delivering
> it to
> the addressee). If you are not the intended recipient of this message, you
> are
> not authorized to read, print, retain, copy or disseminate this message or
> any
> part of it. If you have received this e-mail in error, please notify the
> sender
> immediately by return e-mail and delete it from your computer.
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
Rispetta l'ambiente. Non stampare questa mail se non e' necessario.
www.avoicomunicare.it Ogni giorno, il tuo luogo di dialogo.
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt