Adaptive max bframes patch

[CAFxX]

I just put together a patch (it's more of an ugly hack but whatever) that makes --b-adapt 2 somewhat faster.
Basically what it does is to adapt the number of b-frames to look for based upon the length of the previous consecutive b-frames span. It is way easier just to read the patch to find out how it works; this is the relevant part:

+ /* adaptive max b-frames */
+ if( h->sh.i_type == SLICE_TYPE_P )
+ {
+ int i_gop_bframes = h->fdec->i_frame - h->fref0[0]->i_frame - 1;
+ const int i_bframes_overhead = 4;
+ if ( i_gop_bframes + i_bframes_overhead > h->frames.i_adapt_bframes )
+ h->frames.i_adapt_bframes = i_gop_bframes + i_bframes_overhead;
+ else
+ h->frames.i_adapt_bframes--;
+ h->frames.i_adapt_bframes = x264_clip3( h->frames.i_adapt_bframes, 0, h->param.i_bframe );
+ }

i_gop_bframes is the length of the previous span of consecutive b-frames and i_bframes_overhead is an arbitrary constant (possibly to be parametrized).
h->frames.i_adapt_bframes is initialized (and reset at every scencut) to h->param.i_bframe (i.e. the number of b-frames specified on the command line)
The same adaptive method can be easily added also to --b-adapt 0 and 1, but I guess that it wouldn't give the same speedup.
Right now I'm running a few tests and I will post further results briefly, but the first tests showed a speedup ranging from 5 to 30% (being heavily dependent of the content of the video) for -b 16 (I know that this is the best-case scenario as well as I know the tendancy of doom9ers to max out their settings :rolleyes:).
Just a few more warnings: I tested it only on a Ubuntu32 VM and I have not paid much attention to concurrency issues (there should be none, and I experienced no crashes or other misbehaviour - but I'll wait for a review from the x264 devs about this). I tried to be as clear as possible in the patch, but I guess that at least a few variable names and comments will have to be edited... I couldn't come out with better ones, though.
That's all. Feel free to comment and give (possibly) constructive advice.

[CAFxX]

First tests:
cafxx@cafxx-vm2:~/Devel/x264$ ./x264 -b 16 --b-pyramid --b-adapt 2 -r 4 --crf 26 -A all --direct auto -w -m 9 --psy-rd --mixed-refs -8 -t 2 --no-fast-pskip --no-dct-decimate --progress -o test.mkv paris_cif.yuv 352x288
x264 [info]: 352x288 @ 25.00 fps
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High, level 1.3
x264 [info]: slice I:5 Avg QP:28.01 size: 15611 PSNR Mean Y:35.71 U:39.02 V:39.28 Avg:36.58 Global:36.51
x264 [info]: slice P:502 Avg QP:30.33 size: 1391 PSNR Mean Y:33.70 U:38.34 V:38.57 Avg:34.79 Global:34.77
x264 [info]: slice B:558 Avg QP:32.05 size: 286 PSNR Mean Y:33.47 U:38.29 V:38.53 Avg:34.59 Global:34.57
x264 [info]: consecutive B-frames: 5.8% 61.3% 32.5% 0.4% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 6.9% 21.0% 72.2%
x264 [info]: mb P I16..4: 0.1% 0.2% 0.7% P16..4: 25.7% 5.9% 7.1% 1.2% 0.6% skip:58.5%
x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 8.7% 1.0% 1.4% direct: 1.3% skip:87.6% L0:18.7% L1:60.2% BI:21.1%
x264 [info]: 8x8 transform intra:22.4% inter:37.0%
x264 [info]: direct mvs spatial:92.8% temporal:7.2%
x264 [info]: coded y,uvDC,uvAC intra:83.6% 87.0% 67.9% inter:7.8% 5.0% 1.7%
x264 [info]: ref P L0 79.7% 9.5% 7.0% 3.9%
x264 [info]: ref B L0 92.3% 5.5% 2.2%
x264 [info]: ref B L1 97.3% 2.7%
x264 [info]: SSIM Mean Y:0.9574325
x264 [info]: PSNR Mean Y:33.590 U:38.317 V:38.556 Avg:34.691 Global:34.672 kb/s:175.76

encoded 1065 frames, 32.89 fps, 175.90 kb/s

cafxx@cafxx-vm2:~/Devel/x264$ ./x264-vanilla -b 16 --b-pyramid --b-adapt 2 -r 4 --crf 26 -A all --direct auto -w -m 9 --psy-rd --mixed-refs -8 -t 2 --no-fast-pskip --no-dct-decimate --progress -o test.mkv paris_cif.yuv 352x288
x264 [info]: 352x288 @ 25.00 fps
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High, level 1.3
x264 [info]: slice I:5 Avg QP:28.01 size: 15611 PSNR Mean Y:35.71 U:39.02 V:39.28 Avg:36.58 Global:36.51
x264 [info]: slice P:502 Avg QP:30.33 size: 1391 PSNR Mean Y:33.70 U:38.34 V:38.57 Avg:34.79 Global:34.77
x264 [info]: slice B:558 Avg QP:32.05 size: 286 PSNR Mean Y:33.47 U:38.29 V:38.53 Avg:34.59 Global:34.57
x264 [info]: consecutive B-frames: 5.8% 61.3% 32.5% 0.4% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 6.9% 21.0% 72.2%
x264 [info]: mb P I16..4: 0.1% 0.2% 0.7% P16..4: 25.7% 5.9% 7.1% 1.2% 0.6% skip:58.5%
x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 8.7% 1.0% 1.4% direct: 1.3% skip:87.6% L0:18.7% L1:60.2% BI:21.1%
x264 [info]: 8x8 transform intra:22.4% inter:37.0%
x264 [info]: direct mvs spatial:92.8% temporal:7.2%
x264 [info]: coded y,uvDC,uvAC intra:83.6% 87.0% 67.9% inter:7.8% 5.0% 1.7%
x264 [info]: ref P L0 79.7% 9.5% 7.0% 3.9%
x264 [info]: ref B L0 92.3% 5.5% 2.2%
x264 [info]: ref B L1 97.3% 2.7%
x264 [info]: SSIM Mean Y:0.9574325
x264 [info]: PSNR Mean Y:33.590 U:38.317 V:38.556 Avg:34.691 Global:34.672 kb/s:175.76

encoded 1065 frames, 24.40 fps, 175.90 kb/s

cafxx@cafxx-vm2:~/Devel/x264$ ./x264 -b 4 --b-pyramid --b-adapt 2 -r 4 --crf 26 -A all --direct auto -w -m 9 --psy-rd --mixed-refs -8 -t 2 --no-fast-pskip --no-dct-decimate --progress -o test.mkv paris_cif.yuv 352x288
x264 [info]: 352x288 @ 25.00 fps
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High, level 1.3
x264 [info]: slice I:5 Avg QP:28.01 size: 15611 PSNR Mean Y:35.71 U:39.02 V:39.28 Avg:36.58 Global:36.51
x264 [info]: slice P:502 Avg QP:30.34 size: 1391 PSNR Mean Y:33.70 U:38.34 V:38.58 Avg:34.79 Global:34.78
x264 [info]: slice B:558 Avg QP:32.05 size: 287 PSNR Mean Y:33.47 U:38.29 V:38.54 Avg:34.59 Global:34.57
x264 [info]: consecutive B-frames: 5.8% 60.9% 32.8% 0.4% 0.0%
x264 [info]: mb I I16..4: 6.9% 21.0% 72.2%
x264 [info]: mb P I16..4: 0.1% 0.2% 0.7% P16..4: 25.7% 5.9% 7.1% 1.2% 0.6% skip:58.5%
x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 8.7% 1.0% 1.4% direct: 1.3% skip:87.6% L0:18.8% L1:60.4% BI:20.8%
x264 [info]: 8x8 transform intra:22.0% inter:37.0%
x264 [info]: direct mvs spatial:94.3% temporal:5.7%
x264 [info]: coded y,uvDC,uvAC intra:83.5% 87.0% 67.7% inter:7.8% 5.0% 1.7%
x264 [info]: ref P L0 79.7% 9.5% 7.0% 3.9%
x264 [info]: ref B L0 92.1% 5.7% 2.3%
x264 [info]: ref B L1 97.0% 3.0%
x264 [info]: SSIM Mean Y:0.9574480
x264 [info]: PSNR Mean Y:33.591 U:38.318 V:38.563 Avg:34.692 Global:34.672 kb/s:175.88

encoded 1065 frames, 36.09 fps, 176.02 kb/s

cafxx@cafxx-vm2:~/Devel/x264$ ./x264-vanilla -b 4 --b-pyramid --b-adapt 2 -r 4 --crf 26 -A all --direct auto -w -m 9 --psy-rd --mixed-refs -8 -t 2 --no-fast-pskip --no-dct-decimate --progress -o test.mkv paris_cif.yuv 352x288
x264 [info]: 352x288 @ 25.00 fps
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High, level 1.3
x264 [info]: slice I:5 Avg QP:28.01 size: 15611 PSNR Mean Y:35.71 U:39.02 V:39.28 Avg:36.58 Global:36.51
x264 [info]: slice P:502 Avg QP:30.34 size: 1391 PSNR Mean Y:33.70 U:38.34 V:38.58 Avg:34.79 Global:34.78
x264 [info]: slice B:558 Avg QP:32.05 size: 287 PSNR Mean Y:33.47 U:38.29 V:38.54 Avg:34.59 Global:34.57
x264 [info]: consecutive B-frames: 5.8% 60.9% 32.8% 0.4% 0.0%
x264 [info]: mb I I16..4: 6.9% 21.0% 72.2%
x264 [info]: mb P I16..4: 0.1% 0.2% 0.7% P16..4: 25.7% 5.9% 7.1% 1.2% 0.6% skip:58.5%
x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 8.7% 1.0% 1.4% direct: 1.3% skip:87.6% L0:18.8% L1:60.4% BI:20.8%
x264 [info]: 8x8 transform intra:22.0% inter:37.0%
x264 [info]: direct mvs spatial:94.3% temporal:5.7%
x264 [info]: coded y,uvDC,uvAC intra:83.5% 87.0% 67.7% inter:7.8% 5.0% 1.7%
x264 [info]: ref P L0 79.7% 9.5% 7.0% 3.9%
x264 [info]: ref B L0 92.1% 5.7% 2.3%
x264 [info]: ref B L1 97.0% 3.0%
x264 [info]: SSIM Mean Y:0.9574480
x264 [info]: PSNR Mean Y:33.591 U:38.318 V:38.563 Avg:34.692 Global:34.672 kb/s:175.88

encoded 1065 frames, 32.63 fps, 176.02 kb/s

[Manao]

If you don't already do it, reset i_adapt_bframes to i_bframes when a scenecut is detected.

[CAFxX]

Been there, done that!
h->frames.i_adapt_bframes is initialized (and reset at every scencut) to h->param.i_bframe (i.e. the number of b-frames specified on the command line)

[Manao]

Then you ought to make adaptation instantaneous at the beginning of a scene, because the average scene length is quite small (a few seconds), so with -b 16, decreasing i_adapt_bframes by 1 at each P may costs a lot.

[CAFxX]

I could eventually - for the sake of simplicity - drop completely the decrement and instead rely just on the previous b-frames span size.

[Dark Shikari]

There is a specific type of danger with this type of patch. Let me describe a similar situation to explain.

Let's say you have a patch that speeds up --ref 16 by 50%. Everyone is very happy; clearly this is a great improvement. Then, someone goes and tests and finds that you can get the same speedup for the same quality cost simply by setting --ref 6 instead of 16, and that the patch is a complete waste of time.

The big possible problem with this I imagine is that the places it will do worst are the few places where tons of B-frames are actually useful--and the places it will do best is the places where they aren't useful, in other words, it will do nothing at all.

You need to test on some contrived input cases, e.g. linear fades created in Avisynth and placed after an ordinary sequence or similar (with no scenecut in between), in order to make sure your algorithm isn't going to react badly.

Finally, I don't like the idea of making b-adapt 2 too suboptimal because the idea of b-adapt 2 to begin with was to serve as a reference representing the best possible B-frame decision given a certain metric (slicetype_frame_cost).

[CAFxX]

Let's say you have a patch that speeds up --ref 16 by 50%. Everyone is very happy; clearly this is a great improvement. Then, someone goes and tests and finds that you can get the same speedup for the same quality cost simply by setting --ref 6 instead of 16, and that the patch is a complete waste of time.
In some of my tests the encoded clip ended up having maximum 2 consecutive b-frames. If I had known this fact beforehand I could have set -b 2 and I would have saved a ton of time (both writing the patch and at runtime), but this is -in general - hardly the case. At least, IMHO.

The big possible problem with this I imagine is that the places it will do worst are the few places where tons of B-frames are actually useful--and the places it will do best is the places where they aren't useful, in other words, it will do nothing at all.
The only scenario where this patch could actually possibly perform worse than the main tree is if a scene, after some GOPs where few b-frames are used, suddenly starts having tons of consecutive b-frames. I honestly don't know how common this scenario is. And, BTW, under these assumptions, the patch will swing from 4 to 16 bframes in at most 3 GOPs for a total of 4+8+12=24 frames, wasting one single p-frame (3 against 2).
Apart from this, the patch should behave exactly as a vanilla build. Only faster (YMMV).

You need to test on some contrived input cases, e.g. linear fades created in Avisynth and placed after an ordinary sequence or similar (with no scenecut in between), in order to make sure your algorithm isn't going to react badly.
This is why I posted it here in the first place. Bear in mind that this is the absolute first version of the algorithm; as such it is everything but tuned.

Finally, I don't like the idea of making b-adapt 2 too suboptimal because the idea of b-adapt 2 to begin with was to serve as a reference representing the best possible B-frame decision given a certain metric (slicetype_frame_cost).
Another good reason to parametrize this algorithm. Moreover, plugging in the same algorithm for --b-adapt 0 is absolutely trivial. For --b-adapt 1 it's only slightly harder IIRC.

[Dark Shikari]

What you need to do is test speed-vs-quality with B-frame numbers that actually get chosen. In other words, graph normal B-adapt 2 with bframes 1/2/3/4, and yours with 1/2/3/4, on an RD chart.The only scenario where this patch could actually possibly perform worse than the main tree is if a scene, after some GOPs where few b-frames are used, suddenly starts having tons of consecutive b-frames.I'm taking video with a cell-phone camera. I swing it around to look at something else; during this short period, scenecut will probably trigger and the phone will keep moving. B-adapt 2 will start terminating early at 0 or 1 B-frames. Then the phone stops moving and the scene might want 2-4 B-frames, but won't get it.

This applies to basically the majority of videos uploaded to the website of the company I currently work for (Facebook).

I don't think there's anything wrong with an attempt to speed up B-adapt 2 with heuristics, but I don't like patches which assume that scenes are uniform and adapt heavily to a scene (in particular, adapt in such a way that they cannot adapt back until the scenecut resets them).

[burfadel]

The above example just suggests a motion adaptive b-frame searh.

Well, regardless of it being motion adaptive or not, you could just set a min and max b-frame! Such that:
-b 4 (sets the minimum b-frames search
-bmax 12 (sets the maximum b-frame search

Therefore in this case, the minimum b-frame search will always be 4, so in the above situation you aren't suboptimal. If it were motion adaptive, since you already have the motion information you could use that information to detect where b-frames are useless, then having a b-frame search of 1 could be beneficial for the time of search. If b-frame search of 1 is successful (such that in the case of the motion 1 b-frame is used), then dynamically increase the search based on that.

Even if the above is complete nonsense because I don't really know what I'm talking about :) the min/max idea isn't?!

[CAFxX]

I don't really get why you say thatI don't like patches which assume that scenes are uniform and adapt heavily to a scene (in particular, adapt in such a way that they cannot adapt back until the scenecut resets them)
Suppose you passed -b 16 and i_bframes_overhead is set to 4 (the default). Suppose that x264 is fed a video that, if x264 wasn't patched, would yield the following:

I P P P P P P P P P P P P P P B B B B B B B B B B B B B B B B P B B B B B B B B B B B B B B B B P B B B B B B B B B B B B B B B B P
what my patch should do is this

frame_t w/o patch I P P P P P P P P P P P P P P P B B B B B B B B B B B B B B B B P B B B B B B B B B B B B B B B B P B B B B B B B B B B B B B B B B ...
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
prev_gop 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 8 12 16
frame_t w/patch I P P P P P P P P P P P P P P P B B B B P B B B B B B B B P B B B B B B B B B B B B P B B B B B B B B B B B B B B B B P B B B B B B ...
i_adapt_bframes 16 16 15 14 13 12 11 10 9 8 7 6 5 4 4 4 8 12 16 16
As you can see, you don't have to wait for a scenecut for the patch to adapt back.
Moreover, as far as the min/max approach is concerned, actually it is already that way: -b N controls the maximum and i_bframe_overhead controls the minimum (as you can see in the table above, i_bframe_overhead <= i_adapt_bframes <= param.i_bframe).

p.s. Rereading my previous posts I noticed that I may have mislead you by using the term GOP. What I was referring to was the spans of consecutive b-frames, not all the frames between to i-frames. Sorry about that.

[Dark Shikari]

...The term you're looking for is "minigop," one set of frames starting at a P-frame, containing X B-frames, and ending before the next P-frame.

So what you're really trying to say is that your patch allows the number of B-frames to increase by up to 4 between minigops, specifically that if the previous minigop had 4 B-frames, the search for the next one will look for up to 8. If the next one has 2 B-frames, we will decrease the threshold by one to 7 for the next minigop after that.

In other words, you predict that the current minigop will probably never need more than 4 B-frames more than the previous minigop.

This isn't a bad statement at all; however I see two problems with it.

1. B-adapt 2 assumes that the max B-frames throughout its path-searching is uniform. "Properly" implementing this heuristic would probably involve modifying the B-adapt 2 search function to take your heuristic into account when selecting paths.

2. The most common case of a sudden jump from few to an enormous number of B-frames is that of a fade; this patch might worsen coding in fades. This probably won't be too big a deal with real content, which rarely has perfectly linear fades, and will be partly mitigated by the upcoming weighted P-frame prediction patch, but is still potentially an issue.

[CAFxX]

The term you're looking for is "minigop," one set of frames starting at a P-frame, containing X B-frames, and ending before the next P-frame.
Yep, sorry for the misunderstanding.

So what you're really trying to say is that your patch allows the number of B-frames to increase by up to 4 between minigops, specifically that if the previous minigop had 4 B-frames, the search for the next one will look for up to 8. If the next one has 2 B-frames, we will decrease the threshold by one to 7 for the next minigop after that.

In other words, you predict that the current minigop will probably never need more than 4 B-frames more than the previous minigop.
Yes, that's the idea. Moreover the 4 B-frames overhead is kind of arbitrary. Ideally it should be exposed as a parameter.

This isn't a bad statement at all; however I see two problems with it.

1. B-adapt 2 assumes that the max B-frames throughout its path-searching is uniform. "Properly" implementing this heuristic would probably involve modifying the B-adapt 2 search function to take your heuristic into account when selecting paths.
I didn't notice this. I'll look into it (pointers, anyone?). In the meanwhile I could port the same algorithm to the other two --b-adapt levels (that, IIUC, shouldn't have the same problem, right?)

2. The most common case of a sudden jump from few to an enormous number of B-frames is that of a fade; this patch might worsen coding in fades. This probably won't be too big a deal with real content, which rarely has perfectly linear fades, and will be partly mitigated by the upcoming weighted P-frame prediction patch, but is still potentially an issue.
AFAICT there are a few scenarios where this method would simply improve the speed with no drawbacks, and a few scenarios where this speed improvement would waste a couple of P-frames (such as in my example a couple posts ago).
Moreover, IIRC, the 16 b-frames limit is arbitrary, right? Using this patch you could as well raise it and still be able to finish a two hour encode within a human lifespan. :p

As a side note, the same method (or slight variations thereof) could be also applied to a tons of other parameters (e.g. me_range).

[burfadel]

The whole fade issue can be negated by using a simple say, 3 frame buffer look-ahead. Fades involve an increase or decrease in luminance, so if such a change in luminance is detected within that small amount of frames then it can be dealt with! It would also be ok in this case for flickering caused by campfire scenes etc.

[Dark Shikari]

I didn't notice this. I'll look into it (pointers, anyone?). In the meanwhile I could port the same algorithm to the other two --b-adapt levels (that, IIUC, shouldn't have the same problem, right?)No. There is no reason for your algorithm to apply to anything other than b-adapt 2.As a side note, the same method (or slight variations thereof) could be also applied to a tons of other parameters (e.g. me_range).Probably not. The entire point of merange is to catch motion the motion search would not otherwise catch. If the motion field was smooth enough that you could get away with assuming you never need more than 4 or 8 merange more than the previous search needed, you wouldn't need a fancy motion search anyways.

[CAFxX]

DS, I just had an idea on how to improve the algorithm so that it doesn't, in any case, perform worse than the optimal solution.
The basic idea remains the same, but after calling x264_slicetype_path_search I check if num_bframes is equal to max_bframes and less than param.i_bframe. In this case I set max_bframes back to param.i_bframe (as if it was a scenecut) and call again immediately x264_slicetype_path_search (I know that in this way you'd end up doing the search twice for the same GOP). In this way the decision should be absolutely identical to the non-patched trellis decision. Could it work or am I missing something? Ideally x264_slicetype_path_search itself could be patched so that if it hits the limit it does the reset thing described above without having to do the same search twice - IIRC trellis allows this.

[Dark Shikari]

Here's the reason that won't work.

Let's say our max B-frames is 16 but our current threshold is 2. We run B-adapt trellis and it tells us we should use 2 B-frames.

So then we run it again with a threshold of 3. Now we run it and it tells us we should use 1 B-frame. What the heck?

This is because it's a trellis algorithm; it picks the optimal series of frametypes taking into account the effect the current decision has on future frametype decisions. So if you tell b-adapt 2 that "we can only use 2 B-frames max in any minigop", it will give you a different decision than if you say "we can only use 3 B-frames max in any minigop"... and it could even give you fewer B-frames with the latter than the former.

Now, in general, I think there are potentially good heuristics that are still "wrong" from a trellis sense, but IMO we should be careful to not lie to the trellis.

[CAFxX]

Here's an updated patch. I added the --b-heuristic <integer> option and made a few cosmetic changes. If someone could do some testing it would be greatly appreciated.

[CAFxX]

As a side note, how do I pipe a series of PNG images (BBB) to x264?

[J_Darnley]

Avisynth, ffmpeg, mencoder.

[nm]

As a side note, how do I pipe a series of PNG images (BBB) to x264?AviSynth (ImageSource), MPlayer or MEncoder (mf://*.png -mf fps=24), ffmpeg, ...

[CAFxX]

How am I supposed to tell mencoder to output the images on stdout so that I can pipe it to x264?

[LoRd_MuldeR]

How am I supposed to tell mencoder to output the images on stdout so that I can pipe it to x264?

MEncoder -of rawvideo -o - "c:\source.avi" | x264 --crf 22 --output "c:\out.mkv" --fps 25 --frames 1000 - 1280x720

[nm]

How am I supposed to tell mencoder to output the images on stdout so that I can pipe it to x264?
http://forum.doom9.org/showthread.php?t=144094

You can convert the image sequence to a yuv4mpeg file with mplayer -vo yuv4mpeg:file=out.y4m, which x264 can parse directly. This also works through a special FIFO file so that the intermediate video doesn't need to be written to disk. On Windows you'll need Cygwin or this (http://forum.doom9.org/showthread.php?p=1226337#post1226337).

Or you could link MEncoder against your custom libx264 version and use MEncoder's x264 interface: -of rawvideo -o out.264 -ovc x264 -x264encopts ...

[nm]

MEncoder -of rawvideo -o - "c:\source.avi" | x264 --crf 22 --output "c:\out.mkv" --fps 25 --frames 1000 - 1280x720
This bold part is probably also required (-nosound only if the input has an audio track):

mencoder -really-quiet -nosound -vf format=i420 -ovc raw -of rawvideo -o - mf://*.png | x264 --crf 22 --output out.mkv --fps 25 - 1280x720

[CAFxX]

cafxx@cafxx-vm2:~/Storage/BBB$ mplayer -nosound -vf format=i420 -ovc raw - "mf://*.png"
MPlayer 1.0rc2-4.3.3 (C) 2000-2007 MPlayer Team
CPU: Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz (Family: 6, Model: 23, Stepping: 7)
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.
Unknown option on the command line: -ovc
Error parsing option on the command line: -ovc

I can't find in the -vo option documentation an alternative to -ovc raw...

[LoRd_MuldeR]

Use MEncoder, not MPlayer ;)

[nm]

I can't find in the -vo option documentation an alternative to -ovc raw...
That's because there isn't one. Use -vo yuv4mpeg with MPlayer.

[CAFxX]

That's because there isn't one. Use -vo yuv4mpeg with MPlayer.

In this case, how do I specify to x264 that what's coming in from stdin is a yuv4mpeg?

[Dark Shikari]

In this case, how do I specify to x264 that what's coming in from stdin is a yuv4mpeg?You use a named pipe.

[thewebchat]

You don't. x264 only accepts YUV on stdin. You can make a named pipe or give up or something.

[roozhou]

MEncoder -of rawvideo -o - "c:\source.avi" | x264 --crf 22 --output "c:\out.mkv" --fps 25 --frames 1000 - 1280x720

Don't forget -really-quiet otherwise mencoder will produce garbage to stdout.

However, there are still printf code hiding in mencoder. They may sometimes give you a surprise.

[CAFxX]

I finally managed to do some testing. Results here (http://www.strayorange.com/blog/155-testing-x264-b-frames-heuristic).

Pretty graph FTW:
http://www.strayorange.com/blog/wp-content/uploads/2009/07/Immagine-512x335.png

[Dark Shikari]

I asked for B-frames 1, 2, and 3; above that I don't expect to be able to find any significant improvement among anything, so you won't be able to do a meaningful measurement.