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

[Luca Barbato]

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]

De: Luca Barbato <lu_zero at gentoo.org>

Post by Luca Barbato
the Identification and the Setup MUST be
packed as they are, while the comment
header MAY be replaced with a dummy
one.

Yeah - but what is a "dummy" comment header?
This is not defined in the I-D nor the Vorbis spec.

The vorbis spec defines the minimal header accepted. A sender could put
there a string like "Program - Version" or just "".

"an empty one" "a different one" "a smaller one" would sound better?

And how does this translate into the "number of headers" field,
that comes at the beginning of the packed configuration packet?
This does not seem to be specified anywhere.
Add to that, that the xiph-rtp Vorbis example code does not sout of date,
recipe for IOP failure.

gstreamer and lscube have fully interoperable independent implementations.

Post by Luca Barbato

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?

The first sections imply that each Vorbis packet is prepended with a 2 byte length.
That would "intuitively" mean that the 2-byte length is part of the fragmented data
(like the UDP length of a fragmented IPv4 packet).

I spent some time to disambiguate the use of packet/payload and any word
that may refer to the rtp payload or a group of samples encoded in a
vorbis frame and the people requesting that were happy in the end.

You however indicate that EACH fragment contains a length field at its beginning.
This is consistent with the fragmentation examples, but counter-intuitive and
contradicts my understanding of the previous sections.

This has been discussed before...

lu

[Luca Barbato]

De: Luca Barbato <lu_zero at gentoo.org>

Post by Luca Barbato

Yeah - but what is a "dummy"
comment header? This is not defined
in the I-D nor the Vorbis spec.

The vorbis spec defines the minimal
header accepted. A sender could put
there a string like "Program - Version"
or just "".
"an empty one" "a different one" "a
smaller one" would sound better?

A minimal valid Vorbis comments header or anything that makes it clear
that it MUST be a syntactically valid header.

...