Subject: [AVT] Comments welcome on the "draft-curet-avt-rtp-mpeg4-flexmux-03.txt"

From: "CURET Dominique FTRD/DMI/REN" <[email-masked]>
Date: Fri, 5 Jul 2002 11:00:37 +0200

Dear all,

According to the minutes of the 52nd meeting, we are glad to present a new drat for RTP payload format for FlexMux. We have modified the preceeding draft to answer the five major identified issues.
To allow you to have  a look at it before its installation on the IETF site, you can find it on our local CCETT FTP site using FTP:
 "ftp [email-masked]"  followed by  "ietf" as Login and  "!etF" as password. The draft in under the "avt" folder.

Catherine Roux is attending the next AVT meeting, and a presentation on the issues raised by your comments on this new draft will be presented.  

You will find hereafter the rational behind the modifications we made for identified issues:

yours sincerely

dominique

list of identified issues at the 52nd meting, and actions taken:

1.	Applicability statement: 
We added an applicability paragraph on the environment and on the restrictions of the target contents of that payload.

2.	TCP delay handling: 
When the transport of a FlexMultiplex stream of some of the Elementary streams uses TCP (with or without RTP), while the transport of another FlexMultiplex stream of other Elementary streams uses only RTP, the two transports will experience different delays. This can be handled at the Server side. The application can take into account the delay over TCP in order to send the contents over TCP sufficiently in advance. Synchronisation is done at the receiver side, by the means of the MPEG-4 timestamps, i.e. the common time clock reconstruction based on the FCR samples, and the use of the DTS/CTS. TCP delay handling to carry FlexMux streams is not much different than with the carriage of some individual SL or ES streams over RTP, and some others over TCP.

3.	The fmtp attribute:
 The FlexMux configuration can be static and dynamic. When it is static, and signalled generally by SDP, the mpeg-4-FlexMuxinfo attribute has been replaced by a new a=fmtp attribute. 

4.	The robust dynamic Flexmultiplexing:
When FlexMultiplexing is dynamic, as pointed out in Salt Lake City, the changes have to be transmitted without errors. This is handled now by the new FlexMux specification adopted by MPEG during the last Fairfax meeting: a version number and a current/next indicator are assigned to the FlexMux Channel table. This allows repetition of the FlexMux Channel table. "Null" packets point to the applicable version of the FlexMux channel table. "Null" packets can also be repeated. Repetition enables to recover from packet loss.

5.	The Synchronisation:
The synchronisation problem has been cleaned up. The starting point is that there is a strong relationship between the FCR samples and the embedded CTS & DTS of the FlexMultiplexed streams. 
In the MPEG-4 FlexMux specification, the following sentence is to be read: "The sequence of fmxClockReference time stamps in a FlexMux stream constitutes a clock reference stream, albeit with a different syntax as specified in clause 10. Elementary streams shall be associated to the time base established by this clock reference". This relationship is directly derived from the relationship existing between the OCR samples and the CTS and DTS related to the same object. FCR samples have the same semantics, at the FlexMux level, than the OCR samples at the Object level. 
Different sentences have been added in the RTP payload format draft: 
The FCRs, as well as the CTSs and the DTSs embedded within a FlexMux stream are samples of the same common clock. The relationship between the different CTSs and DTSs and the FCRs are defined according to the constraints of the MPEG-4 system decoder model).
......................................;
The RTP timestamp reflects the sampling instant of the FlexMux packet corresponding to the RTP packet. The sampling instant is given by the same clock that increments monotonically and linearly as the one which is used to validate the FCR field in the "238" specific FlexMux channel.

The transport of FlexMux packets has been improved: It has to be noted that all the FlexMux packets that are supposed to carry FCR samples (packet with index==238), shall carry an FCR sample. A packetisation rule has been added saying that a "238" Flexmux packet is always carried as the first FlexMux packet embedded with an RTP packet, i.e. in that case, the RTP Timestamp corresponds to the direct mapping of the FRC sample. The position and the length of the FCR sample within the "238" FlexMux packet can be introduced by out-of-band means (eg. as SDP parameters).
"end of the note on the rational behind the changes made to the payload format"

Dominique Curet
FT R&D  Rennes,   Laboratoire DMI/PIA
Tel :  (33) 2 99 12 40 05 
Fax : (33) 2 99 12 40 98 
E-mail : [email-masked]
Mail : FT R & D ,  DMI/PIA 
4, rue du clos Courtel BP 91226 
35512 Cesson-Sévigné Cedex, FRANCE