using mencoder as an avi muxer

[Doom9]

I'm trying to get mencoder to mux mp3/ac3 tracks into an AVI. sample commandline:

mencoder -ovc copy -oac copy −audiofile <filename.mp3> -o <output.avi>
<avi-onlyvideo.avi>

the results: mencoder skips certain frames resulting in corrupt playback. When I leave out the audio, all is well. And as far as AC3 goes, while encoding is supported, mencoder just freezes when presented with AC3 audio input. Is that how it's supposed to be?

[unixfs]

adding -mc 0 -noskip to your command line is the solution to your skip
problems.

Ac3 in avi was (and still is) perfectly playable.
How does it freeze, exactly? Do you have any audio filter listed in ~/.mplayer/config ?

[akupenguin]

I can reproduce the freeze. If I compile mencoder.c without optimizations, it doesn't freeze and it looks like it's muxing, but still doesn't actually put any ac3 in the avi.

[unixfs]

and with -of mpeg or -of lavf -o file.avi ?

[unixfs]

I found the reason: demux_lavf.c (that "demuxes" ac3)
doesn't pass channels/bitrate/samplerate to mplayer/mencoder,
so for the time being you should append the following parameters to your command line :

-audio-demuxer 20 -rawaudio format=0x2000:bitrate=384000:channels=6:rate=48000

changing these last items as appropriate.

[Doom9]

@unixfs: while this no longer makes mencoder freeze, and while the output file gets somewhat bigger, size of video-only avi + ac3 file is much larger than my "muxed" output file, and while an ac3 decoding filter is loaded, there's no audio.

here is my commandline:

mencoder -ovc copy -oac copy -mc 0 -noskip -audiofile trailer-audio.mp3 -audio-demuxer 20 -rawaudio format=0x2000:bitrate=448000:channels=6:rate=48000 -o sometest.avi xvid.avi

[unixfs]

Originally posted by Doom9

mencoder -ovc copy -oac copy -mc 0 -noskip -audiofile trailer-audio.mp3 -audio-demuxer 20 -rawaudio format=0x2000:bitrate=448000:channels=6:rate=48000 -o sometest.avi xvid.avi [/B]

I'll explain better what is going on: mplayer has a native mp3/mp2/mp1
demuxer that automatically identifies the properties of these streams
and assigns bitrate, channels and samplerate accordingly;
in order to demux ac3 mplayer relies on libavformat, that in this
particular case does not assign those properties, so it has to be
replaced with -demuxer 20 (rawaudio).

Consequently, that command line is valid if the audiofile is ac3, but if (as the name implies) it is in mp3 format you either don't need
-audio-demuxer 20 -rawaudio format=0x2000:bitrate=448000:channels=6:rate=48000
or you should replace it with the correct parameters for audio,
in which case format=0x55.

I assumed that you were trying to mux ac3 audio, and forgot that
you also mentioned you attempted to mux mp3, that's why I only suggested to use format=0x2000, sorry.

[Doom9]

urgh... /me goes hiding in shame.. all my audio files have the same name just different output and I was first muxing mp3 (worked out with your first tip), then added the additional parameters and forgot to change the audio input extension. Now that I've done that it works as it should.

There's one thing (not quite related though) that I'm still wondering about: mencoder always writes messages about OpenDML.. so is it just creating OpenDML AVIs? And are those AVIs with or without a legacy index?

and the second one back on topic: you mentioned
so for the time being you should append the following parameters
Does that mean you already have a bug report filed or should I go ahead and file one?

[unixfs]

Originally posted by Doom9


There's one thing (not quite related though) that I'm still wondering about: mencoder always writes messages about OpenDML.. so is it just creating OpenDML AVIs? And are those AVIs with or without a legacy index?


yes, and with a compatibility index. Odml can be disabled with -noodml



and the second one back on topic: you mentioned

Does that mean you already have a bug report filed or should I go ahead and file one?

file one, please

[Doom9]

urgh.. they really don't like the spamcatcher email I use.. would you take the honors and file it?

[unixfs]

ok

[Doom9]

have you filed? I can't find anything in bugzilla

[unixfs]

I didn't because I realized why it doesn't work: mencoder uses libavcodec and libavformat without bindings for the code that
decodes ac3: liba52, so it's natural that ffmpeg doesn't assign
the properties to the audio stream.
Technically speaking it's not a bug. The only possible alternative
is to write a minimalistic ac3 demuxer in mplayer, that should be quite easy to write. I'll queue it to my TODO, so I can reuse the code in the mpeg muxer.

[Doom9]

hmm.. so if you know your way around mencoder.. I've been trying to find somebody to patch in xvid zones. There's a sample cli app that ships with the xvid source and looking at it, it seems rather easy, and I'd give it a shot myself but I don't really have the dev environment for this kind of thing.. any chance you could have a look at that, too? I wished mencoder was a VS project so I'd take care of it myself.. I've tried to encourage people in the mplayer irc channels but it seems outside of the windows world nobody really cares (or many times even knows) about xvid :/

[unixfs]

Actually I was there: my nickname in #mplayerdev is nicodvb.
As I explained, I don't care anymore enough about xvid, and I have a lot
of things stockpiled, so at the moment I can't work on xvid zones.

Yet, *IIRC* (and I have to admit that my memory sometimes
plays nasty jokes to me) around 1 year ago someone posted
(or maybe was willing to write?) a preliminary version of of zones for xvid, so if I'm not wrong a search on gmane is worth some research.

[unixfs]

I found out that extending libavformat to assign those parameters
is easy. The code is almost ready, I only need to verify a
couple of things; tomorrow I'll post a patch if it works.

[unixfs]

patch sent

[Doom9]

btw, can mencoder mux multiple audio streams (concurrently or one after another)?

[unixfs]

not concurrently no, consecutively only if the resulting audio
stream has everywhere the same codec and properties

[Doom9]

around 1 year ago someone posted
(or maybe was willing to write?) a preliminary version of of zones for xvid, so if I'm not wrong a search on gmane is worth some research.I don't find anything but an old patch for xvid 0.9 credits treatment (!= zones). can you tell me where in the source the xvid cli options are parsed and where the encoder is being configured? I don't even find xvid.h

[unixfs]

in libmpcodecs/ve_xvid4.c the array xvidencopts_conf contains
the possible cli options.
In your case you need to add one option of type CONF_TYPE_STRING, and
parse it in dispatch_settings().

[Doom9]

thanks for the info.. with a little help from the guys in #xvid and #mplayerdev I've now finished the patch :)

[unixfs]

thanks for the info.. with a little help from the guys in #xvid and #mplayerdev I've now finished the patch :)

good, but I don't see in the ML archive. Did you forget to post it ? :)

[Doom9]

No I didn't post it.. I gave it to gpoirier for testing because I don't have the environment to test and debug mencoder. Once testing it done and whichever bugs I may have introduced (it's not terribly complex, yet past experience has shown me that you never know) have been ironed out, it will be posted.

[Doom9]

In case you can't wait.. here's a prelim with manual.. not sure it works as it's never been tested (other than the commandline parsing which hopefully is fine now.. but the loop was never tested though I basically copied that from the lavc zone parsing)

[Doom9]

uhh.. was the patch actually committed?

mencoder -ovc copy -oac copy -mc 0 -noskip -audiofile trailer-audio.ac3 -o muxtest.avi x264.avi

=> mencoder freezes with 99% cpu usage

mencoder -ovc copy -oac copy -mc 0 -noskip -audiofile trailer-audio.mp3 -o muxtest.avi x264.avi

=> mencoder skips the video and only handles audio. It even tells me that it's skipping the video ("Ignoring video stream!" sent to stderr), but no reason is given.

[unixfs]

no, it was /dev/null-ed (I guess implicitly rejected)

[Doom9]

without any reason given? wouldn't that be reason to resubmit and resubmit until it's accepted? I mean.. pathes that get something working that it supposed to work.. if it doesn't break anything else I see no possibly reason not to apply it.

[unixfs]

no reason was given, but I trust Michael at 10000%, so if he dropped my patch
he must have had his good reasons.
Anyway, now that I re-read the part of mencoder.c that blocks muxing, I realize
that there's something very suspicious in there. I'll give it a look tonight.

[unixfs]

strange that it's skipping video, can you post or send me the log, please?

[Doom9]

I have attached stdout and stderr logs to this post

[Doom9]

here's an update on the situation: when encoding, appending -mc 0 -oac copy -audiofile "audio.mp3" seems to mux the audio. But using an ac3 file leads to the same freezing situation as when muxing ac3 into an existing AVI file.

[Doom9]

did you find anything?

[unixfs]

unfortunately I don't have a fix at the moment. sorry :(

[Doom9]

I noted another freeze: mencoder -ovc copy -o test.avi video.264 freezes mencoder. The same works if my video input is a raw mpeg-4 asp stream (.m4v) instead.

[unixfs]

until it's fixed you can workaround it adding -fps N -ofps N

[Doom9]

hmm.. so it can get the fps from a raw ASP stream but not AVC? things get weirder and weirder. I didn't even know that mencoder added an fps to its raw output, I thought only x264.exe did that (I used mencoder to create the m4v and x264.exe for the 264 file).

[unixfs]

mencoder can determine automatically the framerate of both streams (if certain conditions apply, more later) but in recent versions of mencoder something has changed, so you have to remove those two * 10000 in libmpdemux/mpeg_hdr.c to restore the correct detection.

About h264: the idiots that designed it made the framerate information in the VUI messages _optional_. I can't think of a more stupid thing to do in the context of a video bitstream definition!!

When these informations are not present you obviously have to specify the input framerate using -fps N

[unixfs]

ah, I forgot to say that it's not mencoder to output the raw fps, but the coder itself (rightfully).

[bond]

About h264: the idiots that designed it made the framerate information in the VUI messages _optional_. I can't think of a more stupid thing to do in the context of a video bitstream definition!!why is that stupid, if you have a vfr stream it doesnt make much sense to signal a framerate

[unixfs]

why is that stupid, if you have a vfr stream it doesnt make much sense to signal a framerate

it does: having the timing informations hardcoded in the bitstream is the only way
to mux the raw video stream in any container. How would you set the timestamps
otherwise? Obviously vfr means sequence-wise constant, e.g. a first sequence may be 25 fps, the second 125 and so on.
The same is possible with all other mpeg* video codecs.

[Haali]

I think h264 authors expected that the streams will be used in some container in real life, so the information that can be duplicated at container level is made optional in the bitstream. This helps to avoid confusion, what if the frame rate values are different in container and in bitstream? You can already see this happening with AR info, it depends on playback software which value is used.

Besides vfr is not always sequence-wise constant, e.g. dedup filters can remove arbitrary and upredictable number of duplicate frames.

[unixfs]

common sense and common experience dictate that informations at the higher level
(in this case container) override the equivalent informations in the lower levels
(A/R, timings and so on).

[unixfs]

Doom9: just committed the right fix in mplayer's cvs. Now you should be able to
skip -fps and -ofps parameters