[xiph-rtp] draft-ietf-avt-rtp-vorbis confusion

[Luca Barbato]

Rémi Denis-Courmont wrote:
> 	Hello,
> 
> I am painfully aware that the RTP Vorbis I-D review period is well over. 
> However, I am confused with some apparent inconsistencies and editorial 
> problems within the document.
> 
> In section 3.1.1, it seems implied that the number of headers can only be 2 
> (identity + setup) or 3 (identity + comments + setup), and that the 
> corresponding field on the wire can only accept values 1 or 2.

3.1.1.  Packed Configuration

    A Vorbis Packed Configuration is indicated with the Vorbis Data Type
    field set to 1.  Of the three headers defined in the Vorbis I
    specification [10], the Identification and the Setup MUST be packed
    as they are, while the comment header MAY be replaced with a dummy
    one.

> However there is no explicit statement to that end.

The legacy vorbis comment payload that I'm afraid is causing this 
inconsistency should be gone indeed, thank you for spotting it at last.

> The implication that this field is 
> encoded using variable-length-encoding is counter-intuitive to me, as the 
> value will always fit in less than 2 bits, and a fortiori 7 bits.

Basically I picked a relatively widespread way to pack vorbis and theora 
  headers together that happens to store the different sizes of the 
headers using vlc values. The generic 2byte length that appears 
redundant had been put to enforce an hard limit to the size of 
configuration accepted for streaming (we found samples in the wild that 
stored fullsize album pictures within the comment fields)

> On page 10, the schematic has F=1 and PKTS=0, which contradicts the text 
> below. At the same schematic on page 10, has VDT=0 (raw data), while it 
> should presumably be 1 (packed configuration).

You are right, the text is right, the image is wrong.

> I hope this can be sorted out in AUTH48 or something.
> 
> A possibly more serious problem concerns the 2-bytes length which is prepended 
> to "packets". The text seems to imply that, in the case of a fragmented 
> packet, the field is found once at the beginning of the first fragment, and 
> encodes the whole (defragmented) packet length.

Could you point me/us the exact line?

> However, the schematics in 
> section 5.1 include one length field at the beginning of each fragment. I 
> hope this could be clarified...

The schematics are right in this case =)

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero