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