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

[Paul Richards]

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