Subject: RTCP payload format for backward messages

From: "Shigeru Fukunaga" <[email-masked]>
Date: Thu, 21 Oct 1999 22:41:03 +0900

Dear AVT experts,

Japanese MPEG-4 experts are planning to propose a new RTP format for 
MPEG-4 Audio/Visual to Washington meeting. This proposal was discussed 
in the last MPEG meeting (October), and ISO send a liaison to IETF to 
recommend this new proposal. Now we are discussing this issue on the 
MPEG-4 over IP AdHoc Group's reflector. We will input the internet-draft 
soon until tomorrow dead line.

In this internet-draft, there is a new proposal of RTCP payload format, 
as well as RTP formats.

This RTCP payload will be used to transport the backward messages of 
NEWPRED from the decoder to the encoder. 
NEWPRED is an error resilience video tool selecting the reference pictures 
according to the network error conditions. 

The syntax of the backward messages of NEWPRED is defined in the Visual 
part of MPEG-4 version 2, and the streams of the back messages are 
generated in the video decoder corresponding to the forward Video Packets 
or VOPs. The contents of the messages are changed message by message.
Therefore the RTCP, we proposed, has a payload to deliver the backward 
message as below.

----
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |V=2|P|   BMT   |  　　　PT 　　　|           length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              SSRC                             |
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    |    MPEG-4 Backward Channel Message Payload (byte aligned)     |
    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               :             padding           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

version (V): 2 bits
Identifies the version of RTP, which is the same in RTCP packets
as in RTP data packets. 

padding (P): 1 bit
If the padding bit is set, this RTCP packet contains some
additional padding octets at the end which are not part of the
control information. The last octet of the padding is a count of
how many padding octets should be ignored. Padding may be needed
by some encryption algorithms with fixed block sizes. In a
compound RTCP packet, padding should only be required on the
last individual packet because the compound packet is encrypted
as a whole.

backward channel message type (BMT): 5 bits
 Identifies the type of the MPEG-4 backward channel messages.
 0:  forbidden
 1:  MPEG-4 Visual NEWPRED
 2-63: reserved
 In this internet-draft, only NEWPRED is assigned as the candidate
 of the BMT for the moment.  Some other MPEG-4 Audio/Visual applications using
 the backward channel messages may be assigned in the future. 

packet type (PT): 8 bits
 The value of the packet type (PT) identifier is the constant 
 for MPEG-4 backward channel messages. The assignment of an RTCP payload type for this new packet format is outside the scope of 
this document, and will not be specified here.

SSRC: 32 bits
 SSRC is the synchronization source identifier for the sender of 
 this packet. 

MPEG-4 Backward Channel Message Payload: variable
 The syntax and semantics of the MPEG-4 backward channel messages 
 are defined in the ISO/IEC 14496-2/3. All messages are
 byte aligned.  Normally one message is mapped onto one RTCP 
 packet, and several messages with same BMT could be continuously mapped onto one
 RTCP packet.  One message SHALL NOT be fragmented into different 
RTCP packets.
--

To tell the truth, we had wondered which format (RTP or RTCP) is 
appropriate for the backward messages of NEWPRED, and we decided to use 
RTCP at the Melbourne. If there is other good solution, would you please 
propose it, and discuss here and at Washington?

We understand that RTCP has a limit of sending timing, and the receiver 
has to send RTCP report to all terminals. However there is a exceptional 
procedure in the RFC2032 (RTP payload format for H.261). In the document, 
the control messages can be sent immediately after error detection only to 
one encoder (not all terminals).
Therefore we copy the description of RFC2032 to our proposal for the moment.

Comments are welcome.

Best Regards,
Shigeru Fukunaga
--
   Shigeru Fukunaga ([email-masked])
   Oki Electric Industry Co., LTD.
   Tel. +81 6 6949 5105; Fax. +81 6 6949 5108