[xiph-rtp] vorbis-rtp update

[Luca Barbato]

The fixes are coming nicely and hopefully it could be sent to ietf soon.

lu
--
Luca Barbato

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-ietf-avt-vorbis-rtp-00.txt.gz
Type: application/gzip
Size: 11557 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/xiph-rtp/attachments/20051011/4d098203/draft-ietf-avt-vorbis-rtp-00.txt-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-ietf-avt-vorbis-rtp-00.xml.gz
Type: application/gzip
Size: 10303 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/xiph-rtp/attachments/20051011/4d098203/draft-ietf-avt-vorbis-rtp-00.xml-0001.bin

[Ralph Giles]

Post by Luca Barbato
The fixes are coming nicely and hopefully it could be sent to ietf soon.

Thanks for all your work updating the draft! Unfortunately, I'm not
happy with it yet. Sorry for not responding recently. I didn't have
anything to add in September, and then got busy.

I think it's worth reproducing Aaron's table of the meaning of the C and
F flags in the payload header. Working out what's meant from the
definitions is confusing, so some additional text summarizing the
combination outside the example would help, and stating that RTP
payloads can be packed or fragmented but not both. Not sure if this
should go in section 2.2 or 3.

http://lists.xiph.org/pipermail/xiph-rtp/2005-February/000142.html

Also, the flags should be 0|0 instead of 0|1 in Figure 5 for a packed
payload.


I agree with David that the comment header packets should be allowed,
probably at arbitrary points in the stream. Please change the text to
permit this.

I guess you're trying to keep them out of the packet setup data block
that gets CRCd, but the packet is required by the spec, and not allowing
it destroys the transmissibility of Ogg Vorbis streams. It's true of
course that this packet can be abused, but as we've always said, the
only idea was to provide a saner alternative to ID3 tagging. Of course
a separate metadata stream (using vorbis metadata packets or something
more capable) is a better idea, but I think inline metadata transmission
can still be useful.


You haven't updated Phil's payload header aside from the CF flags, and
the decoder setup is still based on the CRC32 I decided against. This
needs to be changed as well. I guess we never really got consensus for
how big the setup mapping field should be, but I'd like you to update
the text to use my proposed scheme in the meantime:

http://lists.xiph.org/pipermail/xiph-rtp/2005-April/000194.html

Note that this also ups the number of vorbis packets field to 5 bits;
for theora we wanted to keep it at 4 with 2 reserved bits because of
the larger average packet size.

Can you explain again your reasoning for using the packed header
format for inline transmission? It always made more sense to me
to use the same packetization as for data and let the payload
header indicate the matching ident. Especially since the codebooks
will usually have to be fragmented.


Typo in section 4: "methodsMAY" Also the last sentence of paragraph 4
doesn't make sense.


In section 5 you give the MIME type as audio/vorbis, but in 5.1 it's
audio/VORBIS. Does the capitalization mean something, or is that an
error?


Anyway, that's my first review pass. Hopefully we can at least get an
updated draft for the 64th meeting.

-r

[Luca Barbato]

Post by Ralph Giles

Post by Luca Barbato
The fixes are coming nicely and hopefully it could be sent to ietf soon.

Thanks for all your work updating the draft! Unfortunately, I'm not
happy with it yet. Sorry for not responding recently. I didn't have
anything to add in September, and then got busy.
I think it's worth reproducing Aaron's table of the meaning of the C and
F flags in the payload header. Working out what's meant from the
definitions is confusing, so some additional text summarizing the
combination outside the example would help, and stating that RTP
payloads can be packed or fragmented but not both. Not sure if this
should go in section 2.2 or 3.

I based the graphics to the reference code, I already clarified the
issue in the very latest draft.

Post by Ralph Giles
I agree with David that the comment header packets should be allowed,
probably at arbitrary points in the stream. Please change the text to
permit this.

The problem is from one side logic: metadata belongs to the container
not the codec payload; on the other side it adds complexity that is
unneeded. To put it on another point of view.. well, we have enough bits
left to have it separate and completely optional so I could say why not.

I'm not convinced of their use or merit but I'd put them as completely
optional. I'll prepare something soon.

Post by Ralph Giles
You haven't updated Phil's payload header aside from the CF flags, and
the decoder setup is still based on the CRC32 I decided against. This
needs to be changed as well. I guess we never really got consensus for
how big the setup mapping field should be, but I'd like you to update
http://lists.xiph.org/pipermail/xiph-rtp/2005-April/000194.html
Note that this also ups the number of vorbis packets field to 5 bits;
for theora we wanted to keep it at 4 with 2 reserved bits because of
the larger average packet size.

That will take time and I'm not sure how well is accepted. I know that
there are early adopters, hopefully that change shouldn't be a problem
for them since we still are byte aligned.

Post by Ralph Giles
Can you explain again your reasoning for using the packed header
format for inline transmission? It always made more sense to me
to use the same packetization as for data and let the payload
header indicate the matching ident. Especially since the codebooks
will usually have to be fragmented.

Just to keep separated data and codec specific information at container
level. The Packed configuration is expected to be fragmented already

Post by Ralph Giles
Typo in section 4: "methodsMAY" Also the last sentence of paragraph 4
doesn't make sense.

I guess could be expressed better. Basically the intent is to recommend
inline SDP if the stream isn't chained.

Post by Ralph Giles
In section 5 you give the MIME type as audio/vorbis, but in 5.1 it's
audio/VORBIS. Does the capitalization mean something, or is that an
error?

I left that part as was, there is a note explaining that mime and sdp
are case insensitive in that regard.

Post by Ralph Giles
Anyway, that's my first review pass. Hopefully we can at least get an
updated draft for the 64th meeting.

I hope so too. (2 if we are really quick)

lu

[Luca Barbato]

WIP update, the 24bit Ident is there and the optional Comment packet
will follow soon.

I kept the 15 vorbis packet per rtp (given the current common mtu and
packet size it should be ok)


lu
--
Luca Barbato

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-ietf-avt-vorbis-rtp-00.txt.gz
Type: application/gzip
Size: 11082 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/xiph-rtp/attachments/20051014/4050d9f8/draft-ietf-avt-vorbis-rtp-00.txt-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-ietf-avt-vorbis-rtp-00.xml.gz
Type: application/gzip
Size: 9838 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/xiph-rtp/attachments/20051014/4050d9f8/draft-ietf-avt-vorbis-rtp-00.xml-0001.bin

[Luca Barbato]

As stated in the subject I added all the requested changes to the draft.

Summary:

- the Ident field is 24bit, it requires direct mapping. Changes
propagated over the rfc.

- the Comment packet is back, I made it clear that is completely optional

- All packet could be fragmented but just the data ones could be
aggregated.

That's all, if there is consensus I'll update the theora draft accordingly.

lu

[Luca Barbato]

I forgot to include the draft...

lu

Post by Luca Barbato
As stated in the subject I added all the requested changes to the draft.
- the Ident field is 24bit, it requires direct mapping. Changes
propagated over the rfc.
- the Comment packet is back, I made it clear that is completely optional
- All packet could be fragmented but just the data ones could be
aggregated.
That's all, if there is consensus I'll update the theora draft accordingly.
lu

--
Luca Barbato

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-ietf-avt-vorbis-rtp-00.txt.gz
Type: application/gzip
Size: 11285 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/xiph-rtp/attachments/20051016/2995bf8e/draft-ietf-avt-vorbis-rtp-00.txt-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-ietf-avt-vorbis-rtp-00.xml.gz
Type: application/gzip
Size: 10059 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/xiph-rtp/attachments/20051016/2995bf8e/draft-ietf-avt-vorbis-rtp-00.xml-0001.bin