Subject: [AVT] MPEG-4 Flexmux: towards an enhancement of the spec & a simplific ation of the RTP payload

From: CURET Dominique FTRD/DMI/REN <[email-masked]>
Date: Fri, 26 Oct 2001 23:39:44 +0200

Dear all,

The concern of this message is something like: "what might be an extension
of the FlexMux specification, to have a better definition of the RTP payload
for MPEG-4 FlexMux streams"
We will look successively at the preceding and future drafts of "RTP payload
for MPEG-4 FlexMux streams" (A), then at the relation between the "FlexMux
signalling payload" and the FlexMux specification itself (B), then at the
MPEG-4 requirements (C), and finally at the needed characteristics of a
FlexMux specification extension (D). 
A conclusion is also be presented in (E).
At the end of this message, a draft proposal to extend the FlexMux
specification is detailled in (F). 
your comments are more than welcome

A) drafts of "RTP payload for MPEG-4 FlexMux streams": 
A first version of the "RTP payload for MPEG-4 FlexMux streams" has been
presented  to IETF, during the March meeting held in Minneapolis. A second
version of the "RTP payload for MPEG-4 FlexMux streams" will be presented in
Salt Lake City.
The second version will try to take into account the questions raised by the
first presentation, while being as simple as possible, i.e. close to the
payloads already defined for MPEG-1 and MPEG-2 TS, for example. 

The first version of the "RTP payload for MPEG-4 FlexMux streams" had two
parts: the SDP signalling part and the payload part. The payload part was,
itself, divided into two payloads:
- the "FlexMux packet payload" to carry the FlexMux packets themselves,  
- and the "FlexMux signalling payload" to carry the associated signalling, 

B) relation between the "FlexMux signalling payload" and the FlexMux
specification. 
As in March, the FlexMux stream syntax was not supporting a dynamic
configuration mechanism, the "FlexMux signalling payload" was proposed to
support the dynamic configuration of the FlexMux stream. According to some
questions asked during the Minneapolis presentation, that "FlexMux
signalling payload" could lead to confusion, as it was re-defining the set
of FlexMux descriptors already defined within MPEG-4. The dependance between
the MPEG-4 FlexMux specification and its payload was then very strong. Any
modification of an existing descriptor, or any addition of a new descriptor
had to be reflected in a new definition of the RTP payload. The list of
FlexMux descriptors is precisely defined to be updated and completed by new
descriptors. A new descriptor definition is only assigning a new value to a
descriptor tag.

C)MPEG-4 requirements:
If we have a look at the MPEG-4 multiplexing requirement document: Two
sentences can be found about the "Multiplexing of Audio, Visual and Other
Information":
 1= a requirement sentence: "The MPEG-4 standard shall support the dynamic
multiplexing of scalable objects, compositing information, as well as other
data. The multiplexing, and particularly the demultiplexing, should be easy
and cost-effective to implement."
 2= a specification sentence: "The multiplex must support at least a number
of 1024 elementary bitstreams in the same multiplex bitstream. The multiplex
shall supply means to support a dynamically changing number of object
streams."

D)FlexMux specification extension:
D-1)characteristics of such an extension: As for any extension to an
existing  Standard, an in-band "FlexMux signalling" mechanism must be
obtained in a backward compatible way with the preceeding FlexMux syntax.
Such a mechanism has to be optional, in order not to penalize applications
that don't require a dynamic signalling. 

D-2) a draft proposal: A draft proposal (m7292,"FlexMux inband signalling")
was presented in Sydney. It was not discussed because of a lack of time. It
was supposed to be discussed in Washington, which is now postponed to
Pattaya (first week of December). That draft proposal is describing an
optional and backward compatible extension. 
remark: Within a FlexMux stream, the signalling of the addition of new
streams and removal of finished streams, can be done by the means of two
tables: the Muxcode table and the FlexMux Channel (FMC) table. It was
accepted in Sydney that the dynamic in-band FlexMux signalling should
involve these two tables. 

E) Conclusion: 
E-1) extending the FlexMux syntax to support a dynamic signalling mechanism
would allow the FlexMux specification to comply with its "dynamic"
requirements, and would simplify the "RTP payload for FlexMux", getting rid
of the "FlexMux signalling payload".
E-2) the draft proposal (m7292,"FlexMux inband signalling") is a candidate
solution

your comments are more than welcome
best regards

dominique

F)Annex to this message: an extract 
from the m7292 contribution ,"FlexMux inband signalling")
**start*****************************************************
2	a possible solution
As far as FlexMux streams are concerned, the means to support an inband
signalling mechanism can be easily assigned to the '238' Flexmux packet.
Usually this '238' Flexmux packet carries an FCR and a fmxRate, but it can
also carry neither FCR nor fmxRate.
This '238' Flexmux packet has a length field that can be used, in a backward
compatible way to carry any information. The idea is then to carry the
FlexMux signalling descriptors in the '238' FlexMux packet.

3	FlexMux packet specification
Syntax:

class FlexMuxPacket (MuxCodeTableEntry mct[], 
			FlexMuxTimingDescriptor FM,
			FlexMuxIDDescriptor mde) {
	unsigned int(8) index;
	if (mde == NULL | mde.Muxtype == 0) { 
		bit(8) length;
	} else if (mde.Muxtype == 1) { 
		length = 0;
		bit(1) nextByte;
		bit(7) length;
		while(nextByte) {
			bit(1) nextByte;
			bit(7) sizeByte;
			length = length<<7 | sizeByte;
		}
   } 
   if (index<238) {
		SL_Packet sPayload;
	} else if (index == 238) {
		bit(FM.FCR_Length) fmxClockReference;
		bit(FM.fmxRateLength) fmxRate;
			for (i=0; i<(length-FM.FCR_Length-FM.fmxRateLength);
i++) {
				FlexMux_descriptor()
			}
		} else if (index == 239) {
		bit(8) stuffing[length];
	} else {
		bit(4) version;
		const bit(4) reserved=0b1111;
		multiple_SL_Packet mPayload(mct[index-240]);
	}
}

Semantics:
"FlexMux descriptor"-one of the FlexMux desciptors.
**end*******************************************************

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www1.ietf.org/mailman/listinfo/avt