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

Michael Niedermayer michaelni
Sun Dec 31 19:37:10 CET 2006


Hi

On Sun, Dec 31, 2006 at 05:56:11PM +0000, Paul Richards wrote:
> On 31/12/06, Paul Richards <paul.richards at gmail.com> wrote:
> >On 30/12/06, Ralph Giles <giles at xiph.org> wrote:
> >> On Sat, Dec 30, 2006 at 05:53:27PM +0000, Paul Richards wrote:
> >>
> >> > [theora @ 0x3c9554]Invalid extradata!
> >> > [theora @ 0x3c9554]Unknown Theora config packet: 50
> >> > [theora @ 0x3c9554]4376 bits left in packet 32
> >>
> >> This is really for someone who knows ffmpeg to answer, but looking at
> >> the header unpacking code in libavcodec/vp3.c I don't seen any of the
> >> xiphlacing() stuff. The headers appear to be packed in the extradata
> >> using a 16 bit length, followed directly by the body data, followed
> >> by the length of the next packet, and so on.
> >>
> >> It's throwing the "Invalid extradata!" because it's not finding the
> >> theora magic starting at extradata[2] like it expects.
> >>
> >> Try inverting that code and see if it works better. I guess it's
> >> using different packing for the theora and vorbis headers.
> >>
> >
> >Hi, your analysis indeed makes sense.  I have rewritten my packing of
> >the ogg_packet structs into the extradata field.  I now have a 2 byte
> >size, then the data for the first packet, followed by 2 byte size,
> >then data for the 2nd packet, and so on.  I do this for the 3 packets
> >I believe need to be packed into the extra data (header, comment,
> >tables).
> >
> >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?
> >
> >The actual output returned by theora_encode_header() is:
> >5B D5 B2 01 00 00 00 00 20 E0 B2 01 10 00 18 B5
> >A9 49 4A 10 73 9C E6 31 8C 52 94 A4 21 08 31 8C
> >62 10 84 21 08 40 00 00 00 00
> >
> >I also note that this packet does not contain the string "theora" as
> >vp3.c expects to find (and skip over).
> >
> 
> 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.
> 
> Am I still correct in believing that vp3.c should be capable of
> decoding theora video (and header packets) written using libtheora?

yes, just try a theora file (also maybe dump what ends in extradata when
decoding a random theora file)


> 
> Questions regarding the header packet..
> 
> Should I be writing my own theora header instead of using
> theora_encode_header() from libtheora?
> 
> Or do I simply need to munge the output from theora_encode_header() in
> some way that I haven't yet figured out?

i dont know libtheora so i cant help here ...


> 
> Or should I be changing vp3.c to understand the headers written by
> theora_encode_header()?

no, unless there are some theora files which which vp3.c cant decode


> 
> And on a deeper level..
> 
> 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... 

no of course not, just think about this for a moment, should the avi muxer
contain code to repackage theora, vorbis, ... headers? then what about
matroska, nut, asf, mov, mp4, ... ? should every muxer contain (duplicated)
code to pack all the codec specific xiph headers into a single packet?

and then after you duplicated that code in every muxer, you will have to
add code to every corresponding demuxer to undo it otherwise you cannot
copy a stream between 2 containers witout reencoding ...

simply putting the (de)packaging code into the 2 or 3 xiph codecs is much
easier ...


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20061231/806429a0/attachment.pgp>



More information about the ffmpeg-devel mailing list