Subject: Re: [AVT] Working group last call: draft-ietf-avt-mpeg4-simple-04.txt

From: [email-masked]
Date: Wed, 10 Jul 2002 15:23:14 +0200

Alex,

Thanks for your comments. I like your example. If we follow your suggestion, we need an explicit statement for the "unwritten rule"; if we don't, then I agree that the first example needs correction. Let me check also what the feeling of ISMA is about
this issue. On the other hand, I think we should be careful with rules to conclude that a packet is lost. In my understanding,  the order of receiving packets may differ from the order in which the packets are sent, so any "lost" packet may arrive later.
I would assume the best approach is to wait for conclusion whether an Access Unit is lost until you need to decode the AU.

On your other two issues, I am happy to extend the examples in the appendix. I don't think it is the intend to repeat an AU; to explicitly state that is OK with me.

Best regards,

Jan

                      Alex MacAulay                                                                                                    
                      <[email-masked]             To:  Jan vanderMeer/EHV/BE/PHILIPS@EMEA3                                            
                      m>                           cc:  [email-masked]                                                                   
                                                   Subject:   Re: [AVT] Working group last call: draft-ietf-avt-mpeg4-simple-04.txt    
                      2002-07-09 07:17                                                                                                 
                      PM                           Classification:                                                                     

Hi Jan,

Thanks for the quick response!

Regarding:

> 16) I am not aware of any changes made  to the copyright statement.
> Could you please let me know what is missing ?

I suspect the original copyright text may have come from RFC 2026. You
can find it there at the end of page 32 and it continues on to the
beginning of page 33.

> 1) I don't think there is an unwritten rule that RTP time stamps of
> packets are required to monotically increase (I guess this is what
> you mean). In case of video with B-pictures, the pictures are indeed
> sent in decoding order, but the RTP time stamp
> indicates the presentation time. Consequently the RTP time stamp of
> a P picture that is displayed subsequent to a B-picture, but that
> is sent prior to that B-picture has a RTP time stamp that is later
> than the RTP time stamp of the B-picture.  Or do I
> make a mistake here ? Of course I agree that your proposal simplifies
> receivers, but it makes the second interleaving example in appendix A
> illegal.  We should be careful with such simplification, unless we
> would know that losing two consecutive RTP
> packets is very unlikely to happen in practice.

I agree with you that B-pictures cause the RTP time stamp to be
non-monotonic. However, the packets are still in decoding order, and
that is the unwritten rule that I wanted to express.

If we do not limit interleaving to respect this rule, then I would
assert that the first example must change. That is because when packet 2
with timestamp T[2] arrives, the example concludes that frame 1 has been
lost. This conclusion is not possible if we cannot be sure that the
first time stamps of packets are in decoding order.

Regarding the protection against the loss of two consecutive RTP
packets, what if I can convince you that we can still achieve that while
respecting decoding order of first AUs? Below is an alternative
configuration that uses continuous interleave, respects decoding order
of first AUs, and avoids the loss of two consecutive frames when two
consecutive packets are lost. (Unfortunately, it does have two
drawbacks: the first is that the first four packets in the stream are
not resilient to double-loss, the second is that the interleave delay is
larger for a given number of frames per packet).

   Packet   Time-stamp   Frame Numbers       AU-Index, AU-Index-delta
   0        T[0]                 0   6       0  5
   1        T[1]                 1   9       0  7
   2        T[2]             2   5  12       0  2  6
   3        T[3]             3   8  15       0  4  6
   4        T[4]             4  11  18       0  6  6
   5        T[7]             7  14  21       0  6  6
   6        T[10]           10  17  24       0  6  6
   7        T[13]           13  20  27       0  6  6
   8        T[16]           16  23           0  6
   9        T[19]           19  26           0  6
   10       T[22]           22               0
   11       T[25]           25               0

Meanwhile, I have two extra comments:

- Again regarding the appendix, I think it would be nice for the
appendix to give the value of the interleave delay for each example.
This would help to ensure that sender implementations will have the
correct calculation for this value.

- It would be good to explicitly allow or disallow the repetition of an
access unit in one or more packets (i.e. two identical access units with
the same calculated AU-Index value in one or more packets). I don't
remember reading that anywhere in the document. I don't have an opinion
about whether it should be allowed or not, but I think it would be
helpful to have an explicit statement on this topic.

Alex.

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