> suggest that ffmpeg is built  off of (and I suspect develops...?)
> libavcodec.

FFmpeg is the application, it's merely a quite simple wrapper around libavcodec and libavformat.

> libavcodec is also used by mplayer/mencoder. Given that ffmpeg has
> admitted having bitrate
> problems with mpeg-2, does that hold true for mencoder?

It's not exactly so. The bitrate control of ffmpeg is really not perfect, but in practise you'll never know (in my opinion). Unless you want to make a super-hq DVD with an average bitrate of 9 Mbps, which imho is silly anyway.

And yes.

> The mplayer docs
> (http://www.mplayerhq.hu/DOCS/HTML/en/codecs.html#ffmpeg)[] say that
> mplayer uses ffmpeg's libavcodec (which version?). How intertwined are
> these tools?

CVS, yes, very.

> I found a basic comparison between ffmpeg and mpeg2enc here:
> http://www.transcoding.org/cgi-bin/transcode?FFmpeg_Vs._Mpeg2enc[] that
> confirms ffmpeg's bitrate control problem (and a more brief description
> in the newsgroups:
> http://article.gmane.org/gmane.comp.video.ffmpeg.user/481).[]

Please keep in mind those postings (and the opinions even more) are mostly based on versions of libavcodec from years ago. FFmpeg is one of the fastest moving open source projects around. That's also why you should always use CVS.

> Both pages
> also suggest that transcode can use either ffmpeg/libavcodec or mpeg2enc
> when encoding. Yet, transcode lists neither as a dependency (from what
> I've seen)... Does it include its own libraries from these utilities? If
> so, which versions?

Transcode used to ship the ffmpeg libs until 0.6.12 and link to these statically. Then I decided in my endless wisdom that it was too much burden on the developers to include the latest CVS of ffmpeg each time and also I don't like static libraries, so transcode now dynamically links to libavcodec. AFAIK all docs are changed to reflect this change. Before that time, the dependency on ffmpeg already was there because transcode uses all kinds of utils from libavcodec, regardless.

You can make a transcode that doesn't use mpeg2enc, so in that perspective, mpeg2enc is not a dependency.

> So, if I'm reading this correctly, the truly 'base' utilities/libraries
> are ffmpeg and mpeg2enc, while transcode and mencoder are
> front-ends/re-branders of sorts. Is this accurate?

Almost. It's more correctly to compare libavcodec and mpeg2enc. BTW afaik mpeg2enc does not supply separate libraries, so you always must run the program (separate or started from a frontend).

> Second, evaluate the encoders. The first step here would be research -
> look for others' work to avoid rehashing known facts. I've done some
> googling and haven't found much quantitative information comparing the
> stream quality of streams encoded by mpeg2enc and libavcodec

Bottom line: both are good encoders, libavcodec has some options to make it work faster (imho a lot, but opinions vary on this subject) but also less precise (bitrate and max compression, not quality). In some very rare cases of a very picky decoder, mpeg2enc tends to give better results. Also mpeg2enc is way easier to use from the command line, because it only makes mpeg program streams with mpeg2 video.

> If comparisons haven't been made, then I should do some. Which are good
> video types to test? What content do I want? I like tecoltd.com's choice
> of fast motion, edges, and details. What types of video will show how
> encoders differ?

I don't think it's worth the effort to do extensive comparison. Try both, watch the completion time and then look for yourself if you see any difference. If no, use the fastest.

At least don't use bbmpeg (-y mpeg in transcode). It's really ugly.

Erik Slagter

> > libavcodec is also used by mplayer/mencoder. Given that ffmpeg has
> > admitted having bitrate=20
> > problems with mpeg-2, does that hold true for mencoder?
>
>It's not exactly so. The bitrate control of ffmpeg is really not perfect,
>but in practise you'll never know (in my opinion).

That's wrong. The ffmpeg bug can bite you even at rates of 3Mbps (like it has me); the issue is that it can exceed the _maximum_ bitrate which transcode sets to 9Mbps per default (DVD spec says the maximum is 9800 kbps). It's not an issue of how it looks, it's an issue of whether the video data is within spec or not.

Andrew Church

>That's what I say (a little bit further on). It may bite you when you
>want an average bit rate of 9 Mbps or so.

No no, you're misreading me. It bites you with an AVERAGE bitrate of 3 Mbps, if your MAXIMUM bitrate is set too high (like 9 Mbps—which is what transcode defaults to with —export-profile dvd, hence this is relevant to ordinary transcoding).

>BTW this also only counts for two-pass encoding (which I never do
>anyway).

This is true, but I on the other hand always use two-pass (for the reasons I give on the wiki), and I have in fact had to deal with this several times at ordinary bitrates, like 3-4 Mbps.

Andrew Church

> 3 Mbps, if your MAXIMUM bitrate is set too high (like 9 Mbps--which is
> what transcode defaults to with --export-profile dvd, hence this is
> relevant to ordinary transcoding).

I've got bitten with this too. I've used ffmpeg to re-encoded some dvb-recorded material to a smapper size. W/ ffmpeg I used option -b 1860 to set the bitrate… Everything looked fine on computer but viewing the resulting stuff using dvd player gave me jerky output on tv (cartoon scene where much rain caused lot's of changes in picture — I checked the .m2v video — a that part all frames were I-frames…). In latest re-encodings I've used -b 1860 -maxrate 6000. I haven't checked the output (and whether there has been potentially problematic content there), but I hope I have better luck now.

Tomi

>As an elder n00b, is there any point in doing this if it just lowers the
>actual max bitrate from 18 Mbps to 17 Mbps? Or does lowering it from 9000
>to 8000 get it under some threshhold that stops it from going wild?

The problem is that ffmpeg doesn't actually pay attention to the maximum bitrate during the second pass of 2-pass encoding; it relies only on what the results of the first pass tell it. Since the maximum _is_ applied during the first pass, the logfile will reflect that to an extent— but since the whole point of 2-pass encoding is to alter bitrates based on the logfile, the second pass can end up exceeding the maximum bitrate if it decides to use more bits for a scene than it did in the first pass. So we have to lower the max bitrate we give to ffmpeg in order to get ffmpeg to give us video within the DVD specs (9800 kbps).

Unfortunately, there's no way to tell exactly how much ffmpeg will exceed the maximum bitrate by; 6000 is merely a guess at a "safe" value. (For reference, my personal worst-case scenario is out-of-spec video at a maxrate of 7000 kbps. 6500 turned out fine for the same video.)

Andrew Church