Subject: [AVT] RE: draft-ietf-avt-rtp-h264-03.doc question

From: "Amir Wolf" <[email-masked]>
Date: Mon, 23 Feb 2004 15:33:29 +0200

comments Inline

> -----Original Message-----
> From: Magnus Westerlund [ mailto:[email-masked]]
> Sent: Monday, February 23, 2004 2:37 PM
> To: Amir Wolf
> Cc: IETF AVT WG
> Subject: Re: draft-ietf-avt-rtp-h264-03.doc question
>
>
> Hi Amir,
>
> Comments inlie, I would also like to point out that the lastes H.264
> draft is version 04.
>
> Amir Wolf wrote:
> > Hi Magnus,
> > I understand, but I think it's wrong.
> > As any rtp packet contains the packetization method of the packet, I
> > think we should enable an option that supports all packetization
> > methods.
>
> The problem is not deciding how a NALU is packetized. The problem is
> that for making the interleaved mode work, all NALUs on the receiver
> side must have a DON. We authors has considered if we could
> solve it by
> some rule on how to determine the DON for NALUs lacking a
> DON. However
> we could not find a relatively simple rule that would work
> satisfactory
> without restricting which NALUs that could be sent around it. Thus we
> selected to use the explicit and guaranteed to work method of
> requiring
> all NALUs to be assigned a DON by the sender and having it
> transported
> in the packet types that support such transport. If you can
> write such a
> rule, we would welcome it.

Actually I can think of a very simple rule:

I think that MTAP's can also be used for Non-Interleaved mode - This is by sending NUL units of several pictures in decoding order

It will than require 2 more definitions of MTAP16-A, MTAP24-A, MTAP16-B and MTAP24-B.

Where MTAP's-A will not contain a DON.

The packetization-mode flag will than can have some more values with the distinction of Interleaved and non Interleaved mode, for example:

0- Single Nul unit

1- MTAP16-A and MTAP24-A and STAP-A and FU-A (and Single)

2- MTAP16-B and MTAP24-B and STAP-B and FU-B (and Single)

3-  (0-2)

The difference between MTAPs-A and STAP-A is very similar to the support of frame aggregation by rfc3016 which does not require additional signaling.

>
>
> > In addition, rfc 3016 enables aggregation of frames in one
> RTP packet
> > for MPEG4, I don't see why not making it possible for AVC without
> > special signaling.
>
> Aggregation is supported in both Non-Interleaved and
> Interleaved Mode.
> The single NALU mode does not support aggregation due its
> intention of
> being very simple. Also the single NALU mode is sufficient
> for certain
> use cases and applications. I understand that there is other
> use cases
> where aggregation is necessary. However due to the wide area of
> applications that the payload format is intended to support, we can't
> mandate that all functionality is implemented by all
> applications, while
> only a few needs certain application sets. The reason for
> making Single
> NALU mandatory is to ensure that at least on packetization mode is
> common for all applications that needs to negotiate. Those are the
> reasons why we have the Single NALU mode mandatory, Non-Interleave
> Recommended and Interleaved as optional.
>
> It is up to a certain application to decide what is
> appropriate for the
> application and in that context determine what modes that should or
> should not be implemented. If an application requires interleaving to
> work satisfactory, it is up to that application specification to make
> interleaving mandatory.
>
>
> > As 3GPP are going to adopt the above draft stating that
> Single NUL unit
> > mode will be mandatory, Non-Interleaved mode - Recommended and
> > Interleaved mode will be optional - We are loosing here one
> of the most
> > advantages of the AVC.
>
> If 3GPP in one of its applications needs aggregation, then make
> aggregation mandatory to implement. This is up to 3GPP to
> determine what
> there application requires. In fact I think that the 3GPP SA4 meeting
> will be discussing this very issue this week. If you look at the
> proposals over which packetization modes that will be required, some
> company proposes only single NALU mode, while others proposes
> either of
> the two others.
>
>
> Cheers
>
> Magnus Westerlund
>
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
>
>
> This communication is confidential and intended solely for
> the addressee(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you believe this message has
> been sent to you in error, please notify the sender by
> replying to this transmission and delete the message without
> disclosing it. Thank you.
>
> E-mail including attachments is susceptible to data
> corruption, interruption, unauthorized amendment, tampering
> and viruses, and we only send and receive e-mails on the
> basis that we are not liable for any such corruption,
> interception, amendment, tampering or viruses or any
> consequences thereof.
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Feb 2004 15:26:24 +0100

Hi Amir,

Sorry, for misunderstanding. I thought the problem was the overhead 
associated with using STAP-B, instead of using STAP-As. However as I 
understand your problem is that you like to use MTAPs also in 
Non-Interleaved mode.

We have discussed this setup among the authors. The reason why it is not 
included as I can find it is captured in this explanation by Miska:

"Regarding MTAPs with DON: The only scenario where MTAPs without DON can 
be used is when several pictures (access units) are encapsulated in 
their decoding order to an MTAP to drop the packet header overhead 
compared to STAP-based encapsulation. This requires either a very low 
bitrate or large MTU size, neither of which is very likely. All the use 
cases presented in the specification require the use of DON with MTAPs. 
Thus, I suggest allowing MTAPs only with DON."

What is your opinion about this?

Cheers

Magnus

-- 

Magnus Westerlund

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

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