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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Feb 2004 11:11:31 +0100

Hi Amir,

This question belong to the AVT mailing list not MMUSIC. If you respond 
please exclude the MMUSIC list.

The reason for not allowing the usage of single NAL unit packets and 
STAP-As in Interleaved mode is that they do not contain Decoding Order 
Numbers. To avoid the inconsistencies with some NALU having DON and 
other not, this restriction is in place. You will have to use STAP-B in 
interleaved mode to send a single NALU. This is the overhead you will 
have to pay for using interleaving mode.

I hope that clarifies things.

Cheers

Magnus

Amir Wolf wrote:
> Hi All,
> I have one question about the above draft related to packetization-mode.
> The draft specifies that when packetization-mode is set to 2 
> 
> single NAL unit packets and STAP-As MUST NOT be present in the stream.
> 
> I really don't understand this limitation, It is possible for a server
> to use MTAP when having small frames, though aggregating several frames
> in one RTP packet to fill the MTU size.
> 
> On the other hand, when getting a large frame, The server may use STAP-A
> and not STAP-B to reduce overheads.
> 
> Am I missing something?
> 
> Thanks 
> 
> Amir wolf
> 
> Direct: +972-9-7699386
> 
> Mobile: +972-55-509035
> 
> Fax: +972 9 7699 373
> 
> EMBLAZE Systems,Ltd. www.emblaze.com
> 
> 22 Zarhin St. Raanana  43662, ISRAEL
> 
>  
> 

-- 

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: "Amir Wolf" <[email-masked]>
Date: Tue, 24 Feb 2004 12:03:34 +0200

Hi Stephan,
I am not suggesting any limitations,
on the contrary,
To my opinion the current specification is somehow limiting implementers of Non-Interleaved mode not to use MTAPs.
As the packetization-mode parameter in the SDP, having the value of 1 forbids using MTAPs which might be very useful also for Non-Interleaved mode.

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