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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Feb 2004 13:37:25 +0100

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.

> 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.

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

---

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

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.
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.
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.

Amir

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Monday, February 23, 2004 12:12 PM
> To: Amir Wolf; mmusic (E-mail); IETF AVT WG
> Subject: Re: [MMUSIC] draft-ietf-avt-rtp-h264-03.doc question
> 
> 
> 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
> 
> 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: Randell Jesup <[email-masked]>
Date: 26 Feb 2004 20:02:26 -0500

Question about draft-ietf-avt-rtp-h264-04 and timestamp values:

The said draft states that avt-rtp-h264 uses a 90KHz timestamp clock.  The
RTP main spec (3550) says:

      If RTP packets are generated periodically, the nominal sampling
      instant as determined from the sampling clock is to be used, not a
      reading of the system clock.  As an example, for fixed-rate audio the
      timestamp clock would likely increment by one for each sampling
      period.

So, under what circumstances would one use a sampled (derived) timestamp,
and under what circumstances would one use an assumed timestamp?  For
example, for nominally 30FPS video, would one use a timestamp difference of
3000 every time?  What if the actual rate turned out to be not 30FPS, but
29.97fps, or 33fps, etc?  The receiver could compensate for clock/framerate
drift using RTCP SR/RR's or (very) roughly using jitter buffer queue depth,
but only after they had them.  What about inherently variable-frame-rate
encoders?  (Though normally will be using input devices that are
effectively or close to fixed-rate inputs, with the encoder skipping input
frames.)

Obviously the h.264 codec doesn't care itself.

It seems from the spec a receiver must be willing to handle either fixed
(or quantized) offset timestamps, as well as wall-clock-derived timestamps;
so the question is more one of which is preferred/recommended at the sender
side in which instance?  Is there _any_ instance where one would prefer
wall-clock-derived timestamps?  (Perhaps something that truly captured
frames on demand and the encoder ran (and captured/encoded frames) as fast
as it could.)

What about AV sync before RTCP packets are seen (assuming they're not lost
of blocked, etc)?  What if they're never seen - fall back into the rough
jitter-depth solution?  (Of course, in the no-RTCP case you may eventually
have problems due to the audio being all assumed timestamps.)

FYI, is there a list of changes between -03 and -04 somewhere?  I hate
doing textual compares in IETF docs....

Thanks.

-- 
Randell Jesup, Worldgate Communications, ex-Scala, 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)