[xiph-rtp] vorbis-rtp update

[Luca Barbato]

David Barrett wrote:

> 
> 
> In this draft it sounds like you're saying that inline codebook delivery
> is not only the baseline, but the one and only method discussed in the
> document (though there are hooks for others, including HTTP and reliable
> inline with ACKs, to be documented elsewhere).  Personally I agree with
> this approach, but I thought the general consensus was that both
> unreliable inline *and* HTTP would be documented here, and that in fact
> *HTTP* was the baseline (ie, "implementations SHOULD use HTTP if
> possible").

HTTP is one of the many way to deliver codebooks offband, has nothing to
do with RTP and I don't like it so much.
My favorite delivery method would be through SDP but doesn't cover all
the situations. HTTP must not be a mandated method in the vorbis-rtp
since there are applications that won't support http at all, a companion
vorbis-rtp-http could integrate it if there is the need, same goes for
the vorbis-rtsp.

> Incidentally, I'd suggest avoiding the term "baseline" as I don't know
> if that has a universally precise meaning.  Rather, I'd recommend
> sticking with SHOULD, CAN, MUST, etc.

point taken, the whole draft will require a proofread to avoid
ambiguities (see the reply to the latest question)

> 
> 
>>    {FIXME keep the codebook ident field or use a shorter
>>    tag field?}
> 
> 
> I'm not passionate either way (rather, I see advantages to both ways),
> but I guess I'd vote keeping the "codebook ident" field.


> 
> However, I'd recommend adding a blurb somewhere to the effect of
> "implementations SHOULD handle gracefully (but MUST endure without
> critical failure) the the unlikely event of a CRC32 collision where two
> different codebooks have the same Codebook Ident."

I'd like better explicit mappings because of that,

> 
> 
>> 4.1.  Initial SDP Header Setup
>>
>>    The initial configuration MUST be reported in the configuration
>>    parameter.  All the configuration headers known in advance SHOULD be
>>    reported in the same way. {FIXME better wording, if the tag id will
>>    be used instead of the Codebook hash here should go the mappings in
>>    the for of list order -> tag id number.  Define the metadata/
>>    configuration data in a non ambiguous way.  Define the format used.}
> 
> 
> What precisely is "the initial configuration"?  I'd suggest we define
> these terms more explicitly.  For the meantime, I'm assuming this:
> 
> - "The Setup" the payload of the setup packet
> - "The Codebook" the payload of the codebook packet
> - "The Metadata" the payload of the metadata packet
> - "The Configuration" a triplet of (setup, codebook)
> 
> So here, when you say the initial configuration "must be reported in the
> configuration parameter", what precisely do you mean?  Specifically:
> 
> By "initial" do you mean "the configuration of the first audio packet"?
> 
> By "configuration" do you mean "setup" or "setup+metadata"?

I should mark the SDP/mime parameters, "configuration" is a SDP
parameter, I guess I should use a more compact non ambiguous name

> 
> And furthermore, why make this a MUST requirement, or indeed a
> requirement at all?  Basically, I don't get the intent of this section.
>  Granted, I see that *something* must be defined in SDP in order for
> clients and servers to negotiate capabilties.  But given that everything
> can be changed on the fly, the SDP is only advisory -- the server is not
> bound to be limited by what was defined in the SDP.  (It obviously
> SHOULD stick within the client has agreed to accept, but it needn't.)

Would be better use SHOULD, since it could be changed on the fly at the
session start even if is unlikely?

> 
> The treatment and use of emtpy metadata packets is confusing to me.  I
> believe a more intuitive and semantically-correct approach is to make
> metadata headers optional, and say:
> 
> - Servers SHOULD define metadata in the SDP
> - Servers SHOULD NOT send metadata packets if metadata has not changed
> - Servers CAN send an empty metadata packet to clear the metadata
> 
> Thus when setting up a connection, you'd typically define the metadata
> in the SDP, and then NOT send it again inline because it hasn't changed
> from its last definition (in the SDP).

Good clarification =)


> 
> 
>> 4.2.2.1.  Codebook CRC32 Generation
> 
> 
> I just realized I've been totally mistaken about the meaning of the
> 'Codebook Ident' -- I've been thinking it refers to the combination of
> (setup+codebook), but in fact it refers *exclusively* to a single
> codebook.  Hm...
> 

If the Ident is kept would be interesting think about make it an hash of
the full 3 headers set and not just codebook.

> 
> Given my above confusion about 'Codebook Ident', can you clarify for me
> the relationship between codebooks and setups?  It seems that the setup
> can and should be specified in the SDP, and the setup can change with
> inline transmission.  However, can I re-use the same codebook with
> multiple setups?  In practice does anyone do this?  If not, I'd advise
> we change 'Codebook Ident' to 'Configuration Ident', and then define a
> 'Configuration' as "A setup and its matching codebook".  And given this
> definition, a 'Configuration Ident' would need its CRC32 calculated with
> the union of both configuration and setup payloads.


Talking about ambiguity...

Quick and dirty table

Other containers			| Ogg
Metadata (needed for decoding properly)	| Configuration,codebook,...
Info/Comment (just for the end user)	| Metadata


> 
> Basically, I'm confused about the relationship setups, codebooks,
> Codebook Idents, and configurations.  Can you straighten me out here?
> 

The problem about confusion is from the fact in ogg you may have
different places in which you put metadata and a way to separate it,
other containers just divide it between metadata, comments and data.
The xiph codecs have variable codebooks/profile/tables/ while the other
codecs have them fixed and in the metadata you just have a reference to
the right profile.

> 
> 
> Thanks Luca for your great work!
> 

Thank you for supporting me, I hope to have something a little more
complete for Friday

lu

-- 

Luca Barbato

Gentoo/linux Developer		Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero