Subject: [AVT] RE: Update (-09) of Timed Tex draft (WAS: RE: Comments on draft-ietf-avt-rtp-3gpp-timed-text-08.txt)

From: "Rey Jose" <[email-masked]>
Date: Mon, 17 Jan 2005 17:20:10 +0100

Magnus, 

-cut-

..B. If SIDX=Z is not stored, then store the sample 
> description. Go to beginning of step 4 (wait state).
> C. Else go to the beginning of step 4 (wait state).
> 
> --- END of Alg ---
> 
Yes, it is  more clear this way.  I have further improved it and included it in the new draft. Specially the last part was improved (items 4.b.i, 4.b.ii):

"Let X be the last SIDX received that updated the range of valid sample descriptions.  Let Y be a value within the allowed range for dynamic SIDX: [0,127], and different from X. Let Z be the SIDX of the last received sample description.  Then:

1.	Initialize all dynamic SIDX values as inactive.  For stored
contents, read the sample description index in the Sample to Chunk box ("stsc") for that sample.  For live streaming, the first value MAY be zero or any other value in the interval above.  Go to step 2.

2.	First in-band sample description with SIDX=Z is received and stored, Set X=Z. Go to step 3.

3.	Any SIDX within the interval [X+1 modulo(128), X+64 modulo(128)] is marked as inactive and any corresponding sample description is deleted. Any SIDX within the interval [X+65 modulo(128), X] is set active. Go to step 4 (wait state).

4.	Wait for next sample description.  Once the client is initialized, the interval of active SIDX values MUST change whenever a sample description with an SIDX value in the inactive set is received.  I.e., upon reception of a sample description with SIDX=Z do:

a.	If Z is in the (closed) interval [X+1 modulo(128), X+64 modulo(128)] then set X=Z, store the sample description and go to step 3.

b.	Else Z must be in the interval [X+65 modulo(128), X], thus:
i.	If SIDX=Z is not stored, then store the sample description. Go to beginning of step 4 (wait state).
ii.	Else go to the beginning of step 4 (wait state)."

-cut-

> --- End of proposal ---
> I would suggest that you go through the text and fix language errors. 
> There is most probably need for better word alignment and usage of 
> terms. However I do hope you get the idea of the problem and 
> my suggest 
> solution.

I think so... I have aligned the normative language and rephrased here and there. The normative language in last items a) and b) with  could be a problem maybe ? (not sure I understood your reasoning from preivous email):

"o	SIDX from the Sample to Chunk Box (stsc): the stsc Box is used to find samples and their corresponding sample descriptions.  These are referenced by the "sample description index", a (unsigned) 32-bit integer.  If possible, these indices may be directly mapped to the SIDX field.  However, there are several cases where this may not be possible:

a) The total number of indices used is greater than the number of indices available, i. e., for static ones more than 127 and for dynamic ones more than 64 or, 

b) The original SIDX value ranges do not fit in the allowed ranges for static (129-254) or dynamic (0-127) values.

Therefore, when assigning SIDX values to the sample descriptions, the following guidelines are provided:

o	Static sample descriptions can simply be assigned consecutive values within the range 129-254 (closed interval).  This range should be well enough for static sample descriptions.

o	As for dynamic sample descriptions:

a) Streams that use less than 64 dynamic sample descriptions SHOULD use consecutive values for SIDX anywhere in the range 0-127 (closed interval).  

b) For streams with more than 64 sample descriptions, the SIDX values MUST be assigned in usage order, and if any sample description shall be used after it has been set inactive, it will need to be re-sent and assigned a new SIDX value (according to the algorithm in Section 4.1.6.1). "

Please feed me back on the issue of the normative language above and I'll send out the draft right away.

Thanks,

---------------------------------------------
Jose Rey              mailto:[email-masked]
P R D C G - Panasonic R&D Center Germany GmbH
Phone/Fax: +49(0)6103766-134/166
--------------------------------------------- 

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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Jan 2005 08:47:41 +0100

Hi Jose,

I think the text proposal you have in the email looks great. The 
alignment was in regards to my proposed text, not anything in your 
draft. When I wrote the suggested text I didn't take the time to ensure 
that all of my text was using exactly the drafts terms.

So fire away with a new version

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Arthur de Castro Callado <[email-masked]>
Date: Wed, 19 Jan 2005 12:14:05 -0300 (BRT)

Hi,

Can RFC 3385 be considered enough of a reference for CRC32 
implementations, or is it desirable to have (create) another RFC defining 
and naming all versions of CRC32 that MAY or SHOULD NOT be used in future 
IETF standards?

Thanks,
Arthur Callado.

On Tue, 18 Jan 2005, Linus Walleij wrote:

> > I don't know if there is an RFC for CRC32 that you could simply 
> > reference (after checking that it conforms to your implementation of 
> > course).
> 
> Now I know that there is RFC 3385 which carries an example 
> implementation in Verilog, sort of awkward unless you're devising 
> hardware implementations.
> 
> I'd say that SHA-1 is better for any modern software implementation, but 
> it's partly a matter of taste and opinion IMHO.
> 
> 
> Linus Walleij

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Jan 2005 17:11:12 +0100

Hi Arthur,

I am not certain why you ask this question. When it comes to using a CRC 
for Vorbis, the problem is not really about all the possible choices, it 
is about documenting precisly which version one shall use. There is also 
advantages and disadvantages of using the same CRC as is used on the 
transport layer. The advantage is that the implementation may be 
available, however the disadvantage would be that any error that 
inflicted on the protected data is not detected with a second CRC if the 
first identical one fails to detecet. However this disadvantage does not 
appear to be an issue in the usage considered for the vorbis RTP payload 
format.

I haven't read RFC 3385 properly to see if it is guarranted to be a 
suitable reference. I do however get the impression that it is likely by 
pointing at the relevant sections. However it is also important to 
remeber to provide the definition for the data to perform the 
calculation over.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Phil Kerr <[email-masked]>
Date: Wed, 19 Jan 2005 23:17:36 +0000

Hi Arthur,

Thanks for this.  The example in RFC 3385 is based on Verilog, which is 
less than ideal for the Vorbis I-D.  There is a C example in RFC 3309 
which I will have a closer look at.  What I will do, if it is best to 
document in the I-D itself, is to cover the polynomial as well as a C 
implementation and draw from the two RFC's as a guide.

Regards

Phil

Arthur de Castro Callado wrote:

> implementations, or is it desirable to have (create) another RFC 
> defining and naming all versions of CRC32 that MAY or SHOULD NOT be 
> used in future IETF standards?
>
> Thanks,
> Arthur Callado.
>
>> > I don't know if there is an RFC for CRC32 that you could simply > 
>> I'd say that SHA-1 is better for any modern software implementation, 
>> but it's partly a matter of taste and opinion IMHO.
>>
>>
>> Linus Walleij
>
>