Questions about FFMPEG x264 encoding

[HASH ULTRA]

Hi i'm using FFMpeg for windows build 13071 and have some questions about specifics for x264 encoding for Flash streaming. If anyone could shed some light on a few details that would be appreciated as relaible information and documentation is hard to find.

here is my 2-pass command line:

.\Utilities\ffmpeg -i %1 -y -an -threads auto -vcodec libx264 -s 480x360 -b 416k -bt 416k -maxrate 416k -minrate 416k
-bufsize 2M -qcomp 0.01 -ps 3000 -rc_eq "blurCplx^(1-qComp)" -flags +loop -cmp +chroma -deblockalpha 0 -deblockbeta 0
-refs 10 -bf 10 -b_strategy 1 -bidir_refine 1 -coder ac -me_method epzs -me_range 16 -subq 2 -partitions
+parti4x4+parti8x8+partp8x8+partb8x8 -flags2 +brdo+mixed_refs+wpred+dct8x8+bpyramid -g 240 -keyint_min 50 -qmin 10 -qmax 51
-trellis 2 -sc_threshold 35 -i_qfactor 0.71 -pass 1 -f mp4 nul.mp4

.\Utilities\ffmpeg -i %1 -y -an -threads auto -vcodec libx264 -s 480x360 -b 416k -bt 416k -maxrate 416k -minrate 416k
-bufsize 2M -qcomp 0.01 -ps 3000 -rc_eq "blurCplx^(1-qComp)" -flags +loop -cmp +chroma -deblockalpha 0 -deblockbeta 0
-refs 10 -bf 10 -b_strategy 1 -bidir_refine 1 -coder ac -me_method epzs -me_range 16 -subq 7 -partitions
+parti4x4+parti8x8+partp8x8+partb8x8 -flags2 +brdo+mixed_refs+wpred+dct8x8+bpyramid -g 240 -keyint_min 50 -qmin 10 -qmax 51
-trellis 2 -sc_threshold 35 -i_qfactor 0.71 -f mp4 -pass 2 %~n1.mp4

1. packet size (-ps) has any effect on the encoding? from my tests packet sizes of 1400 or 3000 bits or so reduce the maximum packet size but certainly don't limit packets to that limit. Is there any advantage to smaller packet sizes for stream reliability?

2. qcomp (-qcomp) specifiying values of 0.01 (to limit bitrate spikes) through to 0.6 don't have much of a predictable result on the quantizer.

3. i have specified high -refs and -bf because the material i am encoding is repetitive with many scene changes (VJ material). Is that sensible?

4. what is a good setting for -i_bfactor?

Generally how can i improve the encoding to acheive optimum results? Advice appreciated.

thanks

Hash

[Dark Shikari]

First of all, if you're using mp4, you're not streaming, you're doing progressive download.

Second, if you're doing progressive download, bitrate peaks really don't matter much at all. This means you should probably just make the stream VBR with no VBV restriction whatsoever.

Third, you don't need more than 1 ref/similar on the first pass; you can cut down on lots of settings.

Fourth, using me EPZS (DIA), the worst ME setting, is silly considering all the other slow settings. I'd definitely boost that to at least umh.

For an example of Flash progressive downloading encoded with x264, see my sample page (http://mirror05.x264.nl/Dark/Flash/index_lowbitrate.html).

[HASH ULTRA]

Ok so packet size is unimportant, and i can speed up the first pass by reducing complexity. What exactly is safe to remove that will not have a negative impact on the 2nd pass?

I should also remove quantizer restrictions to maximise quality, although this would lead to bigger bitrate spikes which, despite not technically being streaming, might be in the order of mbits/s and affect the continuity of a stream/download, no?

[Dark Shikari]

Ok so packet size is unimportant, and i can speed up the first pass by reducing complexity. What exactly is safe to remove that will not have a negative impact on the 2nd pass?
.\Utilities\ffmpeg -i %1 -y -an -threads auto -vcodec libx264 -s 480x360 -b 416k -bt 416k -maxrate 416k -minrate 416k
-bufsize 2M -qcomp 0.01 -ps 3000 -rc_eq "blurCplx^(1-qComp)" -flags +loop -cmp +chroma -deblockalpha 0 -deblockbeta 0
-refs 10 -bf 10 -b_strategy 1 -bidir_refine 1 -coder ac -me_method epzs -me_range 16 -subq 2 -partitions
+parti4x4+parti8x8+partp8x8+partb8x8 -flags2 +brdo+mixed_refs+wpred+dct8x8+bpyramid -g 240 -keyint_min 50 -qmin 10 -qmax 51
-trellis 2 -sc_threshold 35 -i_qfactor 0.71 -pass 1 -f mp4 nul.mp4Bolded appropriately, though I can't guarantee that's complete.
I should also remove quantizer restrictions to maximise quality, although this would lead to bigger bitrate spikes which, despite not technically being streaming, might be in the order of mbits/s and affect the continuity of a stream/download, no?Its really not a big issue; if your users' bandwidth is just barely enough to view your video you have a problem to begin with; the entire concept of progressive download relies on your users' connections being at least a decent bit faster than your average bitrate.

Bitrate spikes are absorbed by the fact that your users are downloading well ahead of what they're actually viewing.

[HASH ULTRA]

Thanks for that. However i do imagine that there would be a number of scenarios specific to streaming content that would require some concession to be made on the quality of encoding for a more uniform bitrate. If i did decide to make such concessions, what would be the best way to control the rate? i've already played around with -qcomp, and -ps seems to have an affect too. What are the best controls? Thanks

[Dark Shikari]

Thanks for that. However i do imagine that there would be a number of scenarios specific to streaming content that would require some concession to be made on the quality of encoding for a more uniform bitrate. If i did decide to make such concessions, what would be the best way to control the rate? i've already played around with -qcomp, and -ps seems to have an affect too. What are the best controls? ThanksHere's what I'd use for CBR in an ideal case:

1. VBV-maxrate == bitrate, with a reasonable buffer size.

2. 2pass mode, with the 2pass VBV patch from the mailing list (version 8).

If this isn't good enough, I'd set AQ mode to 1 and drop qcomp to 0, but I'd rather avoid doing that. Note AQ options *still* haven't been added to ffmpeg yet.

[HASH ULTRA]

I'm wondering if i'm barking up the wrong tree here and it would be better to use avisynth and the x264 codec and bypass ffmpeg altogether?

[Dark Shikari]

I'm wondering if i'm barking up the wrong tree here and it would be better to use avisynth and the x264 codec and bypass ffmpeg altogether?Yes, you should not be using Video for Windows when you don't have to.

Edit: GAH I SHOULD STOP POSTING AT MIDNIGHT, I read the thread topic as FFDShow!

[nm]

Well, FFmpeg is about as far from VFW as you can get in video tools ;)

@HASH ULTRA:
VBV parameters can be set through ffmpeg -bufsize <bits> and -maxrate <bits>. As Dark Shikari said, you'll just need to compile x264 with the 2-pass VBV patch and link ffmpeg against it. If building x264 and ffmpeg is the problem and you want to just use x264 binaries built by others, there are at least two options:
1. Use AviSynth + x264
2. Use ffmpeg or MPlayer/MEncoder for decoding/preprocessing and pipe their output to a separate x264 process.

The first option is probably easier on Windows.

[Dark Shikari]

Well, FFmpeg is about as far from VFW as you can get in video tools ;)Wow, I totally misread the thread topic. Maybe I should have gone to sleep earlier?

@HASH ULTRA:
VBV parameters can be set through ffmpeg -bufsize <bits> and -maxrate <bits>. As Dark Shikari said, you'll just need to compile x264 with the 2-pass VBV patch and link ffmpeg against it. If building x264 and ffmpeg is the problem and you want to just use x264 binaries built by others, there are at least two options:
1. Use AviSynth + x264
2. Use ffmpeg or MPlayer/MEncoder for decoding/preprocessing and pipe their output to a separate x264 process.

The first option is probably easier on Windows.This is correct.

[HASH ULTRA]

Thank you for the comprehensive advice. I'm not advanced enough yet to compile my own binaries on Windows but is there a binary source for a stable ffmpeg build linked with the 2-pass VBV patched x264 around? currently i am using a build with this configuration:

FFmpeg version SVN-r13071, Copyright (c) 2000-2008 Fabrice Bellard, et al.
configuration: --enable-memalign-hack --enable-postproc --enable-swscale --enable-gpl --enable-liba52 --enable-libfaac
--enable-libfaad --enable-libmp3lame --enable-libvorbis --enable-libtheora --enable-libxvid --enable-libx264 --disable-
ffserver --disable-ffplay --enable-avisynth --enable-pthreads --disable-vhook
libavutil version: 49.6.0
libavcodec version: 51.56.0
libavformat version: 52.13.0
libavdevice version: 52.0.0
built on May 6 2008 21:34:48, gcc: 4.2.3