Ivo Emanuel Gonçalves
2008-Mar-11 19:51 UTC
[ogg-dev] Regarding applications implementation of Skeleton's Content-Type
I noticed this first in vorbis-tools and later in ffmpeg2theora. The Skeleton bitstream contains a header called Content-Type. It lists the media types of all the data in Ogg. In vorbis-tools and ffmpeg2theora the output is normally Vorbis and Theora. The Skeleton implementation there reports those media types as video/x-theora and audio/x-vorbis. I would like to suggest that it would be better to use video/theora and audio/vorbis as those media types are in the middle of being registered through their respective RTP RFCs. Why urge this change instead of waiting? Because of interoperability as the Skeleton parsers will be expecting one media type for each of those codecs and not two (the x- and non x- versions). It would be pretty bad if there were two kinds of Ogg+Skeleton files out there. It's already bad that there are those with and without Skeleton as it is. The less confusion the better for everyone and, considering the media types are used internally, no one's going to complain. -Ivo
Silvia Pfeiffer
2008-Mar-11 20:33 UTC
[ogg-dev] Regarding applications implementation of Skeleton's Content-Type
I agree. Is it both in the code and in the documentation? I shall look at the documentation over easter. Cheers, Silvia. On Wed, Mar 12, 2008 at 1:51 PM, Ivo Emanuel Gon?alves <justivo@gmail.com> wrote:> I noticed this first in vorbis-tools and later in ffmpeg2theora. The > Skeleton bitstream contains a header called Content-Type. It lists > the media types of all the data in Ogg. > > In vorbis-tools and ffmpeg2theora the output is normally Vorbis and > Theora. The Skeleton implementation there reports those media types > as video/x-theora and audio/x-vorbis. > > I would like to suggest that it would be better to use video/theora > and audio/vorbis as those media types are in the middle of being > registered through their respective RTP RFCs. > > Why urge this change instead of waiting? Because of interoperability > as the Skeleton parsers will be expecting one media type for each of > those codecs and not two (the x- and non x- versions). It would be > pretty bad if there were two kinds of Ogg+Skeleton files out there. > It's already bad that there are those with and without Skeleton as it > is. > > The less confusion the better for everyone and, considering the media > types are used internally, no one's going to complain. > > -Ivo > _______________________________________________ > ogg-dev mailing list > ogg-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/ogg-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/ogg-dev/attachments/20080312/f13739ae/attachment.htm
Possibly Parallel Threads
- Regarding applications implementation of Skeleton's Content-Type
- Regarding applications implementation of Skeleton's Content-Type
- Regarding applications implementation of Skeleton's Content-Type
- Ogg index and Skeleton 4.0
- Merging Ogg streams whilst updating the Skeleton?