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

From: "Amir Wolf" <[email-masked]>
Date: Mon, 23 Feb 2004 16:36:55 +0200

Well, 
Streaming AVC over GPRS networks requires a very low bitrate (about 30-40Kbps).
In order to get the maximum out of the network it is essential to aggregate pictures as the MTU still stands around the 1500 bytes.
Amir

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Monday, February 23, 2004 4:26 PM
> To: Amir Wolf
> Cc: IETF AVT WG
> Subject: Re: draft-ietf-avt-rtp-h264-03.doc question
> 
> 
> 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
> 
> 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.
> 
> 

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

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 23 Feb 2004 09:55:49 -0800

Hi Amir, and AVTers,

There is a procedural and a technical aspect in this thread, and I want to 
address both.  First, the technical side:

H.264 carries no timing information in-band.  In particular, it does not 
carry information about skipped pictures, the way older video standards did 
this using the TR (there are a number of very good reasons for this design 
decision, but discussing them here would take a little bit too far).  That 
is, if we were aggregating pictures in a form of an STAP (or the way 
RFC3016 is doing it) we would not know when to display them.  Hence we will 
need a modified version of MTAPs for any form of aggregation.

The overhead of an MTAP16 aggregation unit is 5 bytes, and could possibly 
reduced to 4 bytes if we were adding an MTAP16 without DON.  Either number 
sounds awfully close to the size of compressed headers on the 3GPP access 
link.  In the core network -- who cares?  Also, my gut feeling is that the 
header compression of the MTAP packet itself would likely be less efficient 
than the one of the single NALU packets as their content is less 
predictable, which could render aggregation even more questionable.

Now the procedural side:

Please let me summarize my understanding of this thread:
a) Amir suggests there is a valid application for multiple pictures in an 
MTAP without DON (IMHO questionable, see above)
b) that application, if valid, could be equally well served with MTAPs with 
DON, with minimal additional overhead,
d) There is an ongoing discussion in 3GPP on many aspects of the use of 
H.264, including the use of MTAPs with DON

Out of this I see two solutions:

1. 3GPP mandates or recommends the use MTAPs with DON for low bitrate 
applications, but possibly restricts the functionality of this powerful 
tool to whatever they deem useful.  Understand, any form of restriction is 
not my personal recommendation -- one would indeed loose a lot of carefully 
worked out functionality when doing so -- but if a group is feeling that a 
certain tool is too complex in terms of hard-, soft-, or brainware, then 
let them do it.  I believe Miska is at the meeting Magnus has mentioned, 
hence assistance can be provided to put such restrictions in appropriate 
language.
2. We add syntax to support exactly what Amir wants (new MTAP types), so to 
act pro-actively on the ongoing discussions in 3GPP.  the authors, among 
themselves, have already had this discussion and found it very tricky.

Needless to say, I would opt for the first option.

Stephan