Subject: RE: RTCP Retransmission

From: Franceschini Guido <[email-masked]>
Date: Tue, 11 Jan 2000 12:20:03 +0100

Dear Stephan, all,

seems that the MPEG-4 message did not propagate clearly :(

DMIF has specified what it was meant to specify, i.e. a reference
architecture (and interfaces) to embrace the essential features of diverse
control and transport protocol stacks, while covering diverse consumption
scenarios (local, remote interactive, multicast or broadcast). This way it
has been possible for the "core" part of MPEG-4 (Systems) to be specified in
a delivery independent manner. The target environment for MPEG-4
applications ranges from Internet to mobile to broadcast and local
consumption, with a variety of enabling technologies. QoS providing
environments are considered. MPEG-4 refrained from 'invading' someone else's
areas of 'jurisdiction', but is willing to co-operate to fill the holes. We
did that with ITU-T (for mobile terminals), and are doing the same with this
group.
So far we have complete specs for delivering MPEG-4 over mobile, MPEG-2 TS,
DAB or to save MPEG-4 on files. We have implementations for streaming MPEG-4
over TCP and UDP (with and without RSVP in the control plane), various
solutions for RTP, a couple (at least) of implementations for IP multicast,
others covering RTSP in the control plane. There is an implementation also
for HTTP download and I even know of an implementation for native ATM.
Almost all these implementations are built on top of the DMIF architecture
provided in the MPEG-4 reference software implementation.

The definition of RTCP-Rx is, IMHO, a quite interesting new feature per-se,
which is fully in the scope of IETF. Specific MPEG-4 media may take
advantage of it, or not. If yes, maybe details could be worked out together
(IETF and MPEG).
In MPEG-4 the Initial OD has to be delivered reliably. There is no
compromise possible wrt real time delivery.
In a broadcast MPEG-2 TS environment we achieve that by repeating that
information in one of the carouseled MPEG-2 TS tables.
In my IP multicast implementation I achieve reliability by fetching the IOD
through HTTP.
These are just examples. Anyway the IOD is not an elementary stream.
MPEG-4 OD and BIFS streams have similar requirements, but in some cases some
Access Unit may become useless if too late. We defined a BIFS Carousel
algorithm (expecially for the broadcast scenario) to enable random tune-in
within a running session and also cope with the non-0 possibility of AU
loss.

I know of people in MPEG-4 that are considering to use a backchannel to
request the retransmission of portions of a scene, in case the scene itself
is delivered unreliably. (As I understand it) the scene is in this case a
complex SNHC graph and the intent is to preserve the real time nature of the
media -thus avoid TCP like transmission- while maximising the possibility of
rendering as much as possible of the graph itself.
To my understanding, this people is defining a full syntax for requesting
retransmissions, and simply assumes that the delivery layer provides a
backchannel. Whether such backchannel, in the case of Internet best-effort,
can be mapped into RTCP or not, is a matter that could be further
investigated.

Best regards
Guido Franceschini

CSELT, Via Reiss Romoli 274 , I-10148 Torino - Italy
Tel + 39 011 228 6137
Fax + 39 011 228 6299
Email [email-masked]