Subject: RE: [AVT] RFC 3984 Packetization 0 question

From: "Rod Hill" <[email-masked]>
Date: Thu, 29 Nov 2007 15:17:10 -0000

RFC 3984 states that 

When the value of packetization-mode is equal
                        to 0 or packetization-mode is not present, the
                        single NAL mode, as defined in section 6.2 of
                        RFC 3984, MUST be used.

But how does 6.2 handle Single NALs > Max MTU size. Surely use of one of
the  FU schemes is the only reliable way to send such a NAL, or are we
supposed to rely on IP fragmentation/reconstitution to get the NAL
across a network?

        Best Regards

			Rod Hill
			Trinity Convergence

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 29 Nov 2007 16:30:17 +0100

> supposed to rely on IP fragmentation/reconstitution to get the NAL

The single NALU mode is intended for the simplistic case where you
actually can produce NALUs that fit into a single MTU. You have no
choice to rely on IP fragmentation if the NALU is bigger than the MTU.

cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 29 Nov 2007 17:33:19 +0200

Rod,
Using FUs make sense if you reach a limit like maximum number of slices.
Otherwise you should try to build your NAL units so that they are
smaller than the MTU size.
Roni Even

> -----Original Message-----
> From: Rod Hill [mailto:[email-masked]]
> Sent: Thursday, November 29, 2007 5:17 PM
> To: [email-masked]
> Subject: RE: [AVT] RFC 3984 Packetization 0 question
> 
> 
> 
> RFC 3984 states that
>

---

From: Thomas Stockhammer <[email-masked]>
Date: Thu, 29 Nov 2007 16:40:27 +0100

Roni,

FUs do have other use cases than the one you mention, for example if you
transmit pre-encoded content and you have to adapt the packet size.
In addition if you combine with Application-Layer FEC as for example the
case in 3GPP MBMS, FUs adapted to radio packet payload sizes can improve
performance significantly when compared to no adaptation or even when
compared to the use of adapted NAL unit sizes (i.e. slices).

Best regards

Thomas

>> > supposed to rely on IP fragmentation/reconstitution to get the NAL

=======================
Thomas Stockhammer, CEO
Nomor Research, Germany
http://www.nomor.de
phone: +49 89 97898002
cell: +49 172 5702667
SkypeMe@Id: stockhammer
=======================
Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht:
München, HRB 165856  Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Thomas
Stockhammer, Dr. Ingo Viering.

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 29 Nov 2007 17:44:57 +0200

Thomas,

You are right, my response was more for conversional services over local area networks

Roni

________________________________

From: Thomas Stockhammer [mailto:[email-masked]] 
Sent: Thursday, November 29, 2007 5:40 PM
To: Even, Roni; Rod Hill; [email-masked]
Subject: Re: [AVT] RFC 3984 Packetization 0 question

Roni,

FUs do have other use cases than the one you mention, for example if you transmit pre-encoded content and you have to adapt the packet size.
In addition if you combine with Application-Layer FEC as for example the case in 3GPP MBMS, FUs adapted to radio packet payload sizes can improve performance significantly when compared to no adaptation or even when compared to the use of adapted NAL unit sizes (i.e. slices).

Best regards

Thomas

Rod,

> From: Rod Hill [mailto:[email-masked]] <mailto:[email-masked]%5d> 

=======================
Thomas Stockhammer, CEO
Nomor Research, Germany
http://www.nomor.de
phone: +49 89 97898002
cell: +49 172 5702667
SkypeMe@Id: stockhammer
=======================
Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 - Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Thomas Stockhammer, Dr. Ingo Viering.

---

From: Randell Jesup <[email-masked]>
Date: Thu, 29 Nov 2007 12:28:37 -0500

>supposed to rely on IP fragmentation/reconstitution to get the NAL

Solutions:

a) Don't create NALs longer than MTU - set a maximum slice size or some
   such so that the encoder will avoid doing that (preferred).
b) Rely on fragmentation (generally risky and with downsides).
c) Don't use mode 0, use mode 1.  Warning: some people don't do mode 1.
   Even worse, some don't look at packetization-mode at all.  Fun.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Randell Jesup <[email-masked]>
Date: Thu, 29 Nov 2007 12:38:09 -0500

>compared to the use of adapted NAL unit sizes (i.e. slices).

Right - and not just for pre-encoded content.

Think of an RTP gateway (translater, what have you) at the border of a
large-MTU network (ethernet, even jumbo-frame ethernet) and a small-MTU
network (think radio transmission such as 3G).  You can either adapt the
original encoder down to the small-MTU size (and hurt your compression
ratios, and increase number of packets on the large-MTU network a lot), or
you could have the gateway take large NALs and fragment them.  Effectively,
to the gateway, the incoming large NALs look like pre-encoded content.
This does require some fancy footwork and the gateway is really acting
(mostly) like a B2BUA for the RTP traffic.  It could do the same thing in
reverse (aggregate into STAPs) in the other direction.

Even in straight 1500-byte MTU networks, mode 1 should let large NALs get
better compression, though how much I don't know.