Hi,
Just to provide a reference to the multi-sink synchronization Jörg talked about below. This was defined for RTP in RFC 7272:
https://datatracker.ietf.org/doc/rfc7272/ and relies on signalled clock sources
https://datatracker.ietf.org/doc/rfc7273/
Cheers
Magnus
> Section 5.2.2: With audiovisual communication having a long history
> in the
> IETF, there is clearly an awareness of what it takes to do smooth
> playback
> and synchronized playback: playout buffers. These, of course, would add
> latency, so the point made here is well taken but it should be put
> into the
> context of A/V over packet networks.
>
>
> [Carlos] Not sure if you suggest adding here some text to clarify that
> this is in the context of packet networks. I've added something but I'm
> not sure if this addresses your point completely.
Ideally, this would reflect what A/V over packet networks has done since
RFC 1889/1890 (and even before that in research), playout buffers for
smooth playback and wallclock time sync (relative to a single sender)
for cross-media synchronization and possibly to a common reference clock
for multisource sync. There was work on multi-sink sync in research but
I am not sure this made it to the IETF.
In 5.2.1 you currently only cover lost packets but not delay variation
which might also occur, even in detnet-style networks (just miss your
TSN slot, for example). The latter would need minimal buffering which
may give your RAW design some room to maneuver.
Overall, the assumptions assume that the max latency bounds are so tight
to make rtx impossible. Isn't this a function of the current path RTT?
If this is very low, rtx might be permissble. Maybe phrasing this in
less absolute terms, e.g., "such an approach is not viable" -> "so an
approach may not be viable" would do the trick?
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
