From the discussion in Dallas I think we may also need to define what an “application” is…
Marie-Jose Montpetit, Ph.D. mari...@mit.edu @SocialTVMIT > On Jun 4, 2015, at 9:37 AM, Michael Welzl <mich...@ifi.uio.no> wrote: > > Well... it's a typical engineering trade-off decision to make... > > >> On 04 Jun 2015, at 07:45, Marie-Jose Montpetit <mari...@mit.edu> wrote: >> >> In my presentation in Dallas I had suggested adding RTP (and even HTTP) >> because as both Mirja and Christian mention some 'applications' are >> requesting functionalities that are got given elsewhere. >> >> Marie-José Montpetit >> ma...@mjmontpetit.com >> mari...@mit.edu >> >> On Jun 3, 2015, at 20:44, Christian Huitema <huit...@microsoft.com> wrote: >> >>>> Actually I think I don't agree here. Yes, it's tied closer to the >>>> application but I >>>> think for taps this is a (good) example where the interface is at a much >>>> higher >>>> level and therefore might have a value to discuss it. However... (see >>>> below) >>> >>> I don't quite agree either. >>> >>> RTP is an extreme example of the split between "generic transport library" >>> and "application specific transport implementation." There are quite a few >>> RTP functions that are seldom found in other transports, but are worth >>> considering: >>> >>> 1) The use of timestamps. This is quite fundamental for "real time" >>> applications that need to synchronize the rendering of different media >>> streams. >>> >>> 2) The tolerance for losses. This requires alignment of transmission units >>> to "natural" media boundaries such as audio or video frames, or compression >>> units within video frames. >>> >>> 3) The practice of FEC, including variable rate FEC. This is quite common >>> in video transmission. A given frame will be transmitted as N data packets >>> plus P redundancy packets, where N and P depend on size and importance of >>> the frame, e.g. anchor frame versus delta. >>> >>> -- Christian Huitema >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
