theora dev - Dec 2006 - Theora encoding in FFmpeg

(Cross posted to theora-dev@xiph.org and ffmpeg-devel@mplayerhq.hu)

I am working towards adding Theora encoding support to libavcodec in
FFmpeg.  I am doing this by simply calling libtheora from libavcodec.

I am at the point where I can execute:
"./ffmpeg -v 100 -i test.wmv -f avi -an -vcodec theora -b 1000000 -y
test.avi"
I get some whirring and an output file written.  My calls to libtheora
are succeeding, and I am copying the ogg_packet structures returned by
libtheora back to ffmpeg..  :)

When I attempt to decode my file with this command:
"./ffmpeg -v 100 -i test.avi -f avi -an -vcodec mjpeg -b 10000000 -y
test2.avi"

I get output like so:

...
Input #0, avi, from 'test.avi':
  Duration: 00:00:07.4, start: 0.000000, bitrate: 694 kb/s
  Stream #0.0, 1/15: Video: theora, yuv420p, 320x240, 1/15, 15.00 fps(r)
Output #0, avi, to 'test2.avi':
  Stream #0.0, 1/90000: Video: mjpeg, yuvj420p, 320x240, 1/15, q=2-31,
10000 kb/s, 15.00 fps(c)
Stream mapping:
  Stream #0.0 -> #0.0
[theora @ 0x3c9554]Invalid extradata!
[theora @ 0x3c9554]Unknown Theora config packet: 50
[theora @ 0x3c9554]4376 bits left in packet 32
Press [q] to stop encoding
1656240 dezicycles in init_frame, 1 runs, 0 skips
1537800 dezicycles in unpack_superblocks, 1 runs, 0 skips
...

FFmpeg exits cleanly but test2.avi has nonsense.  Clearly the VP3
decoder (which ffmpeg uses for theora decoding) does not understand my
stream.  I am not sure if the problem is just my extradata, or if my
entire stream is borked.

To describe my ogg_packet conversion..  I first copied the code used
in oggvorbis.c which calls to av_xiphlacing etc to concatenate the
header ogg_packet structs to the extradata field.  This gives the
error above.  Next I tried concatenating just the raw contents of the
ogg_packet structs, and not performing any *xiph*() things.  This
failed just as miserably:

...
[theora @ 0x3c9554]Unknown Theora config packet: 50
[theora @ 0x3c9554]188016 bits left in packet B2
Press [q] to stop encoding
1636920 dezicycles in init_frame, 1 runs, 0 skips
1518600 dezicycles in unpack_superblocks, 1 runs, 0 skips
...


Can anyone help me with this problem?  I am happy to post source code
(currently < 200 lines), or my entire svn diff.  I am not sure if this
would be welcome on these mailing lists.


-- 
Paul Richards

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.

 -r

On 31/12/06, Michael Niedermayer <michaelni@gmx.at>
wrote:
> On Sun, Dec 31, 2006 at 05:56:11PM +0000, Paul Richards wrote:
> > 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 ...
>
In that case shouldn't there be a function in libtheora to concatenate
all of the "extradata" packets together in a container-insensitive
way?


-- 
Paul Richards

Hi

On Mon, Jan 01, 2007 at 12:47:52PM +0100, Diego Biurrun
wrote:
> On Sun, Dec 31, 2006 at 09:17:52PM +0100, Michael Niedermayer wrote:
> > 
> > On Sun, Dec 31, 2006 at 08:09:54PM +0000, Paul Richards wrote:
> > > On 31/12/06, Michael Niedermayer <michaelni@gmx.at> wrote:
> > > >On Sun, Dec 31, 2006 at 05:56:11PM +0000, Paul Richards
wrote:
> > > >> 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 ...
> > > >
> > > 
> > > In that case shouldn't there be a function in libtheora to
concatenate
> > > all of the "extradata" packets together in a
container-insensitive
> > > way?
> > 
> > yes, and this container-insensitive way should be documented in the 
> > theora/vorbis/... spec
> > iam sure many people would be happy if this would happen ...
> 
> If you guys don't keep the xiph lists in the CC, they will never read
> this, though ...
oops i didnt realize that theora-dev@xiph.org was in the CC

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/theora-dev/attachments/20070101/5522c6ac/attachment.pgp

On 01/01/07, Rich Felker <dalias@aerifal.cx>
wrote:
> On Sun, Dec 31, 2006 at 08:09:54PM +0000, Paul Richards wrote:
> > On 31/12/06, Michael Niedermayer <michaelni@gmx.at> wrote:
> > >On Sun, Dec 31, 2006 at 05:56:11PM +0000, Paul Richards wrote:
> > >> 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 ...
> > >
> >
> > In that case shouldn't there be a function in libtheora to
concatenate
> > all of the "extradata" packets together in a
container-insensitive
> > way?
>
> yes, there certainly should be. unfortunately the xiph people, in
> their infinite wisdom, are outwardly hostile to container-insensitive
> things and want to make their codecs as painful as possible to use
> with non-ogg containers.
>
> btw, is there a reason you want to use theora so much? it's not a good
> codec at all..
>
I have two reasons.

1)  I want to show some support for a patent-free video codec.

2)  Theora was quite good in a few basic tests I ran here.  Compared
against ffmpeg's "mpeg4" codec at 400kbit CBR, theora was clearly
better.  Compared against ffmpeg's "h264" (libx264), there was no
clear winner (part of the problem was that I couldn't get h264 to
stick to CBR).



-- 
Paul Richards

On 01/01/07, Robert Swain <robert.swain@gmail.com>
wrote:
> Hey,
>
> Michael Niedermayer wrote:
> > also it is _very_ important to use postprocessing on the decoder side
for
> > mpeg4 asp (theora and h.264 have their own "postprocessing"
in loop filter
> > build in) mplayer -vf spp=X or -vf pp is something you could try
>
> Can the loop filter in theora be disabled? That's another option for
comparison
> I suppose.
>
> >> Compared against ffmpeg's "h264" (libx264), there
was no
> >> clear winner (part of the problem was that I couldn't get h264
to
> >
> > the default options for x264 encoding with ffmpeg are VERY bad, there
> > should be some recommanded command line parameters for ffmpeg-x264
> > somewhere i think (no i dont remember where ...)
>
> I made some notes here:
> http://rob.opendot.cl/index.php/useful-stuff/ffmpeg-x264-encoding-guide/
>
> It and the interface could probably do with a little updating to encompass
bime,
> mixed refs and anything else that was added.
>
Hi,
I did not mean to spark a debate about which codecs are better and
what set of options need to be applied to get there.  I just wanted to
defend my choice to hook up Theora by pointing out that it's roughly
up there with mpeg4 and h264 (both very popular).


-- 
Paul Richards