[theora-dev] Theora encoding in FFmpeg
Paul Richards
paul.richards at gmail.com
Sun Dec 31 12:21:17 PST 2006
On 31/12/06, Ralph Giles <giles at xiph.org> wrote:
> On Sun, Dec 31, 2006 at 05:56:11PM +0000, Paul Richards wrote:
>
> > >Decoding in vp3.c still chokes however. The returned packets from
> > >theora_encode_comment() and theora_encode_tables() have the 0x81 and
> > >0x82 prefixes as vp3.c expects. The output from
> > >theora_encode_header() however does not start with 0x80 as vp3.c
> > >expects. Does anyone know why, or what I should put there instead?
>
> Something's getting mangled. The packet returned from
> theora_encode_header() has 0x80,"theora",0x03,0x02,0x00 as its initial
> bytes.
>
Interesting, I'll investigate this further. See if I can figure out
why this is getting mangled.
> > As a further note I do not see the frame dimensions (320 x 240, or
> > 0x0140 x 0x00f0) in this packet. Looking at theora_decode_header() in
> > vp3.c, it definitely expects these values to be plainly visible.
>
> The frame dimensions are stored >>4, so this should be 0x0014 0x000f.
> The crop size is stored in two 24 bit integers though, so you will see
> 0x000140 0x0000f0 imediately after that.
>
Ok, well I'll check for these once I fix the above mangling.
>
> > Why is all this special packing of the output from theora_encode_***()
> > into the extradata required? I naively assumed that any packing like
> > this would be the responsibility of the muxer... Is the packing I am
> > performing simply reimplementing what libogg would do?
>
> Well, the header packets are necessary to initialize the decoder. In
> Ogg these are stored the same way as normal packets, just at the start
> of a segment, and the demuxer is expected to take care of finding that
> start and feeding them to the decoder, regardless of where in the stream
> playback is to begin. This design isn't supported among all container
> formats. My impression from the ffmpeg devs is that they find a better
> abstraction to be "this blob should be passed to the codec at
> initialization" and it may or may not be stored as normal packets by the
> muxer, depending on the format being written.
>
> See http://www.mplayerhq.hu/DOCS/tech/oggless-xiph-codecs.txt for more
> on this.
>
Excellent thank you. :)
It sounds like libtheora's API is too dependant on libogg. Perhaps it
should provide a handy function that does this packing for non-ogg
containers... It would certainly help me out, and anyone who wants to
pack theora into non-ogg..
.. Presumably then the ogg muxer in ffmpeg needs to then detect this
special non-ogg compatibility packing, and then repack in the normal
ogg way... (although I will look at this later)
Thanks for the help. :D
--
Paul Richards
More information about the theora-dev
mailing list