[Ffmpeg-devel] Re: Re: Re: [theora-dev] Theora encoding in FFmpeg

Ralph Giles giles
Sun Dec 31 19:35:26 CET 2006

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 

> 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.

> Am I still correct in believing that vp3.c should be capable of
> decoding theora video (and header packets) written using libtheora?

Well, vp3 has slightly different packet headers (and no header packets) 
but so far it sounds like the code actually expects theora.

> Questions regarding the header packet..
> Should I be writing my own theora header instead of using
> theora_encode_header() from libtheora?


> 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.


More information about the ffmpeg-devel mailing list