A message for x264's devs

[skottish]

I just wanted to extend my appreciation and thanks to the x264 devs for a
remarkable piece of software, as well as the work going into FFmpeg's H264
decoder.

Generally I use x264 through FFmpeg to encode my artwork. These are always
raw PNG frames, and I've done it frequently enough that speed improvements
aren't always noticeable to me. I don't encode movies except for one that
I own just to test settings. And even there, I only encode a few particular
scenes that are tricky for encoders.

Recently I recorded a concert of a friend of mine. The camera used shoots full
DVD quality mpeg2 streams with stereo ac3 audio. She also happened to get
an I-Pod Classic for Christmas, and I wanted to surprise her with videos
of the songs she played in.

I ended up with three tracks that averaged about five minutes a piece. I
decided to use the 1.5Mbps settings from Robert Swain's I-Pod encoding guide
using r1061:

http://rob.opendot.cl/index.php/useful-stuff/ipod-video-guide/

I remembered from the last time that I encoded mpeg2 to H264 that it was a
rather time consuming process. What I saw next was unreal.

After starting the process I looked at the progress counter. It was going what
seemed to me to be way too fast. I thought that something was wrong with the
command line parameters. I ran through the first pass, then the second pass
with FAAC this time (then MP4Box for certainty), and sure enough I had a
very good quality Quicktime/I-Pod compatible stream. I was stunned by how much
quicker x264 is now than the last time I worked with mpeg2 video.

The other part of this is to offer my support for the work that's going into
the H264 decoder in FFmpeg. While I'm not a coder, I'm dorky enough to read
through their mailing list. FFmpeg's obviously not the easiest environment to
work in, particularly when it comes to licensing issues. But, it is important
that it's getting done, and I doubt there's more capable hands than you.
Please don't stop until everything's in place.

I'm sure complaints about x264 and FFmpeg outnumber thanks and constructive
criticism by the tens of thousands to one. I wrote this to let you know
that there are people out here that truly and gratefully acknowledge and
respect your work.

Thanks.

[Dark Shikari]

....Hey, if it's too fast for you, raise subq to 8 for even better quality ;). Note by the way that the guide there is rather old at this point--this page (http://rob.opendot.cl/index.php/useful-stuff/ffmpeg-x264-encoding-guide/) and this page (http://ffmpeg.x264.googlepages.com/mapping) may be more useful, though neither provides iPod-specific settings. You could also harass superdump on IRC to get him to update his iPod info page.

Back to the point, thanks for the appreciation--and expect more soon on the topic of iPod encoding. I've written a level/run calculator that's over 2x faster than the current code--it'll need lots of cleaning up before it's ready, but that should do for CAVLC encoding what this (http://git.videolan.org/?p=x264.git;a=commit;h=84a1ca6ce70fe7bad4922ddc5a72c2e9cd73703b) did for CABAC encoding.

[skottish]

It's funny, I thought that I scoured the pages with the presets. I'd much rather use those; it's far easier to type! Guess I missed it.

Thanks

[Guest]

this page (http://ffmpeg.x264.googlepages.com/mapping) may be more useful In the description of --aq-strength it says:

"Higher values take more bits away from complex areas and edges and move them towards simpler, flatter areas to maintain fine detail."

But wouldn't taking bits away from complex areas and edges tend to destroy fine detail, rather than maintain it?

[Dark Shikari]

In the description of --aq-strength it says:

"Higher values take more bits away from complex areas and edges and move them towards simpler, flatter areas to maintain fine detail."

But wouldn't taking bits away from complex areas and edges tend to destroy fine detail, rather than maintain it?The "fine detail" we're attempting to retain is in the simpler/flatter areas. To do so, we take bits from the less-fine detail.

[LoRd_MuldeR]

But wouldn't taking bits away from complex areas and edges tend to destroy fine detail, rather than maintain it?

Well, I think the problem is that "complex" areas tend to eat far too much bytes.

VAQ greatly helps to avoid blocking and banding in flat areas, like background or sky, and hence improves the overall quality at a given bitrate.

Too much of it would hurt overall quality, so one has to find a good trade-off. It seems to defaults were chosen wisely.

[Guest]

The way it is described in the linked document is highly confusing/misleading IMHO.

[Sagekilla]

It takes away bits from the -extremely- complex areas where your eye won't normally notice a difference. Then, it takes those bits and gives it to the (comparatively) flat areas that still have some fine detail which would otherwise be smeared. Take the background in touhou for example. Great example of where AQ turns the background a soupy mess into something much sharper (despite the relative softness of the background to begin with.)

[Guest]

Thanks for the explanations. Perhaps the linked document could be revised to say what you have said here.

[LoRd_MuldeR]

Live music video also benefits from VAQ nicely:

http://mplayer.somestuff.org/misc/CQP-vs-CRF.3.htm
http://mplayer.somestuff.org/misc/CQP-vs-CRF.4.htm

(Note that the CQP version doesn't have VAQ, while the CRF version has. Both files have the same total size).

[teddg]

Hey, if it's too fast for you, raise subq to 8 for even better quality ;). Note by the way that the guide there is rather old at this point--this page (http://rob.opendot.cl/index.php/useful-stuff/ffmpeg-x264-encoding-guide/) and this page (http://ffmpeg.x264.googlepages.com/mapping) may be more useful, though neither provides iPod-specific settings. You could also harass superdump on IRC to get him to update his iPod info page.

speaking of http://ffmpeg.x264.googlepages.com/mapping, who owns it? they need to update -nr, see here (http://forum.doom9.org/showthread.php?t=143851).

Back to the point, thanks for the appreciation....
Same from me. You guys rock! :)

[Dark Shikari]

speaking of http://ffmpeg.x264.googlepages.com/mapping, who owns it? they need to update -nr, Why? It looks accurate to me.

(That page is mine, albeit relaxed actually edits it, I just give him the info.)

[teddg]

Why? It looks accurate to me.

(That page is mine, albeit relaxed actually edits it, I just give him the info.)

Accurate?

*http://ffmpeg.x264.googlepages.com/mapping say's that x264's -nr equivalent in ffmpeg is "unknown"

*and here (http://forum.doom9.org/showpost.php?p=1229687&postcount=2) you say the two are the same, only that ffmpeg is slower.

perhaps the mapping page could explain this and note the identical syntax?

[Dark Shikari]

Accurate?

*http://ffmpeg.x264.googlepages.com/mapping say's that x264's -nr equivalent in ffmpeg is "unknown"

*and here (http://forum.doom9.org/showpost.php?p=1229687&postcount=2) you say the two are the same, only that ffmpeg is slower.

perhaps the mapping page could explain this and note the identical syntax?I don't maintain the ffmpeg mappings, that's relaxed and superdump's job :p

[skottish]

I decided to just throw some stuff at the I-Pod and see what happened. I tried your HQ preset D.S. with the following:
ffmpeg -ss 232 -t 323 -padtop 48 -padbottom 48 -deinterlace -i MOV001.mpg -ab 128k -acodec libfaac
-s 640x384 -vcodec libx264 -pass 2 -vpre hq -b 1.5M -bt 1.5M -aspect 4:3 -threads 0 video.mp4
Quicktime on the Windows machine that was going to do the transfer was crippled by this video. It didn't make it to the I-Pod. :)

[Dark Shikari]

I decided to just throw some stuff at the I-Pod and see what happened. I tried your HQ preset D.S. with the following:HQ preset is not iPod compatible.

[skottish]

HQ preset is not iPod compatible.

Yeah. It was so much fun.