Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 28th June 2009, 14:04   #1  |  Link
CAFxX
Stray Developer
 
CAFxX's Avatar
 
Join Date: Mar 2003
Location: Italy
Posts: 82
Adaptive max bframes patch

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:
Code:
+    /* 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 ).
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.
Attached Files
File Type: diff diff.diff (2.4 KB, 14 views)
__________________
CAFxXcrossway, a collection of my projects
CAFxX@strayorange, my blog
CAFxX is offline   Reply With Quote
Old 28th June 2009, 14:08   #2  |  Link
CAFxX
Stray Developer
 
CAFxX's Avatar
 
Join Date: Mar 2003
Location: Italy
Posts: 82
First tests:
Quote:
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
__________________
CAFxXcrossway, a collection of my projects
CAFxX@strayorange, my blog
CAFxX is offline   Reply With Quote
Old 28th June 2009, 14:16   #3  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
If you don't already do it, reset i_adapt_bframes to i_bframes when a scenecut is detected.
__________________
Manao is offline   Reply With Quote
Old 28th June 2009, 14:26   #4  |  Link
CAFxX
Stray Developer
 
CAFxX's Avatar
 
Join Date: Mar 2003
Location: Italy
Posts: 82
Been there, done that!
Quote:
Originally Posted by CAFxX View Post
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)
__________________
CAFxXcrossway, a collection of my projects
CAFxX@strayorange, my blog
CAFxX is offline   Reply With Quote
Old 28th June 2009, 14:49   #5  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
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.
__________________
Manao is offline   Reply With Quote
Old 28th June 2009, 15:57   #6  |  Link
CAFxX
Stray Developer
 
CAFxX's Avatar
 
Join Date: Mar 2003
Location: Italy
Posts: 82
I could eventually - for the sake of simplicity - drop completely the decrement and instead rely just on the previous b-frames span size.
__________________
CAFxXcrossway, a collection of my projects
CAFxX@strayorange, my blog
CAFxX is offline   Reply With Quote
Old 28th June 2009, 19:02   #7  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
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).
Dark Shikari is offline   Reply With Quote
Old 28th June 2009, 23:56   #8  |  Link
CAFxX
Stray Developer
 
CAFxX's Avatar
 
Join Date: Mar 2003
Location: Italy
Posts: 82
Quote:
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.

Quote:
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).

Quote:
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.

Quote:
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.
__________________
CAFxXcrossway, a collection of my projects
CAFxX@strayorange, my blog
CAFxX is offline   Reply With Quote
Old 29th June 2009, 01:54   #9  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
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.
Quote:
Originally Posted by CAFxX View Post
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).
Dark Shikari is offline   Reply With Quote
Old 29th June 2009, 06:01   #10  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,045
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?!
burfadel is offline   Reply With Quote
Old 29th June 2009, 07:40   #11  |  Link
CAFxX
Stray Developer
 
CAFxX's Avatar
 
Join Date: Mar 2003
Location: Italy
Posts: 82
I don't really get why you say that
Quote:
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)
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:
Code:
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
Code:
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.
__________________
CAFxXcrossway, a collection of my projects
CAFxX@strayorange, my blog
CAFxX is offline   Reply With Quote
Old 29th June 2009, 07:56   #12  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Quote:
Originally Posted by CAFxX View Post
...
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.
Dark Shikari is offline   Reply With Quote
Old 29th June 2009, 08:30   #13  |  Link
CAFxX
Stray Developer
 
CAFxX's Avatar
 
Join Date: Mar 2003
Location: Italy
Posts: 82
Quote:
Originally Posted by Dark Shikari View Post
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.

Quote:
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.

Quote:
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?)

Quote:
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.

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).
__________________
CAFxXcrossway, a collection of my projects
CAFxX@strayorange, my blog
CAFxX is offline   Reply With Quote
Old 29th June 2009, 10:06   #14  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,045
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.
burfadel is offline   Reply With Quote
Old 29th June 2009, 13:38   #15  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Quote:
Originally Posted by CAFxX View Post
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.
Quote:
Originally Posted by CAFxX View Post
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.
Dark Shikari is offline   Reply With Quote
Old 29th June 2009, 20:38   #16  |  Link
CAFxX
Stray Developer
 
CAFxX's Avatar
 
Join Date: Mar 2003
Location: Italy
Posts: 82
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.
__________________
CAFxXcrossway, a collection of my projects
CAFxX@strayorange, my blog
CAFxX is offline   Reply With Quote
Old 29th June 2009, 21:05   #17  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
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.
Dark Shikari is offline   Reply With Quote
Old 29th June 2009, 21:21   #18  |  Link
CAFxX
Stray Developer
 
CAFxX's Avatar
 
Join Date: Mar 2003
Location: Italy
Posts: 82
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.
Attached Files
File Type: diff heuristicbframe.diff (6.6 KB, 18 views)
__________________
CAFxXcrossway, a collection of my projects
CAFxX@strayorange, my blog
CAFxX is offline   Reply With Quote
Old 30th June 2009, 15:46   #19  |  Link
CAFxX
Stray Developer
 
CAFxX's Avatar
 
Join Date: Mar 2003
Location: Italy
Posts: 82
As a side note, how do I pipe a series of PNG images (BBB) to x264?
__________________
CAFxXcrossway, a collection of my projects
CAFxX@strayorange, my blog
CAFxX is offline   Reply With Quote
Old 30th June 2009, 15:55   #20  |  Link
J_Darnley
Registered User
 
J_Darnley's Avatar
 
Join Date: May 2006
Posts: 959
Avisynth, ffmpeg, mencoder.
__________________
x264 log explained || x264 deblocking how-to
preset -> tune -> user set options -> fast first pass -> profile -> level
Doom10 - Of course it's better, it's one more.
J_Darnley is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 09:05.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.