Invoking mencoder

[ink]

I've merged the libvpx-r3 patches for mplayer/ffmpeg and the latest
git of libvpx, and everything seems to be working. How do I encode to
VP8 with mencoder? Here's what I get with my intuitive (naive)
attempt:


$ /usr/local/mplayer-webm/bin/mencoder -ovc lavc -oac lavc ./input.avi
-o output.webm -of lavf -lavfopts format=webm -lavcopts
acodec=vorbis:vcodec=libvpx

MEncoder SVN-r31189-4.4.3 (C) 2000-2010 MPlayer Team
success: format: 0 data: 0x0 - 0xd3d40a
AVI file format detected.
[aviheader] Video stream found, -vid 0
[aviheader] Audio stream found, -aid 1
VIDEO: [FMP4] 720x486 24bpp 29.970 fps 4059.9 kbps (495.6 kbyte/
s)
[V] filefmt:3 fourcc:0x34504D46 size:720x486 fps:29.970
ftime:=0.0334
==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000->176400)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
** MUXER_LAVF
*****************************************************************
REMEMBER: MEncoder's libavformat muxing is presently broken and can
generate
INCORRECT files in the presence of B-frames. Moreover, due to bugs
MPlayer
will play these INCORRECT files as if nothing were wrong!
*******************************************************************************
OK, exit.
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1
Opening video filter: [rotate]
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4)
==========================================================================
Movie-Aspect is 1.48:1 - prescaling to correct movie aspect.
videocodec: libavcodec (486x720 fourcc=7662696c [libv])
[libvpx @ 0xabbbd50]v0.9.0-37-gcbf12db
VIDEO CODEC ID: 0
AUDIO CODEC ID: 15005, TAG: 0
Writing header...
[webm @ 0xabb9ba0]Codec for stream 0 does not use global headers but
container format requires global headers
[webm @ 0xabb9ba0]Codec for stream 1 does not use global headers but
container format requires global headers
[webm @ 0xabb9ba0]WebM only supports VP8 video.
Floating point exception

[ink]

If anyone else stumbles on this thread, here is the response I
received via email:

"Without modifying ve_lavc.c you'll need to use -ffourcc VP80 to get
the proper codec selection."

It works like a charm.


-Craig

[rernst]

I got somewhere to this point to and get encodes. However, it is
unclear to me how to pass the proper options to the encoder. It
appears that vbitrate= is accepted and somehow influences the outcome.
However, other options can be passed in via vcodec=libvpx:o= but I do
not know whether this really makes any difference. The encoding speed
and fp/s is definitely not properly displayed (fp/s encoded is too
low, the encoder is actually encoding much faster).

I also saw that the fourcc has to be set manually.

However, all attempt to use the webm container have led to crashes for
me. If you have a working build, would you share it?

[James Zern]

On Wed, Jun 23, 2010 at 17:12, rernst <rern...@gmail.com> wrote:
> I got somewhere to this point to and get encodes. However, it is
> unclear to me how to pass the proper options to the encoder. It
> appears that vbitrate= is accepted and somehow influences the outcome.
> However, other options can be passed in via vcodec=libvpx:o= but I do
> not know whether this really makes any difference.
>

Yes via -lavcopts o= is correct. libvpxenc will log the encoder
parameters at loglevel debug under ffmpeg, but currently the callback
isn't registered under mencoder in this case so I don't believe
there's a way to produce this output without further patching.

> However, all attempt to use the webm container have led to crashes for
> me. If you have a working build, would you share it?
>

This may happen when attempting two pass as mencoder's use of lavf
differs from ffmpeg in that it will call write_trailers on the muxer
even if no data has been written (which is true in the first pass).
Using the default avi muxer in the first pass with /dev/null as the
file will avoid this.

[rernst]

Thought I'd mention that the latest svn build from a couple of minutes
ago looks very promising. A lot of the options are now being accepted
and webm is properly written. Promising. Looks better to me under
mencoder than under ffmpeg which up til yesterday kept blowing up at
me with qmin, qmax. Nice.

On Jun 23, 5:21 pm, James Zern <jz...@google.com> wrote: