[x264-devel] Re: Test results of trellis,brdo,and mixed_refs

[Loren Merritt]

On Thu, 15 Dec 2005, Guillaume POIRIER wrote:
>
> I've read several times that adaptive bframes, weighted bframes and
> pyramid were pretty much always improving quality.

Adaptive B-frames are necessary if you want one setting to encode a whole
movie, or if you don't want to tweak settings for each source. But for any
given scene, there is some optimal B-frame setting, and x264's algorithm
doesn't necessarily find it.

And given that Tuukka forced 3 B-frames + pyramid, weighting doesn't do
much. Each B-frame is equidistant from its two main references, so their
weights are equal.

On Thu, 15 Dec 2005, Tuukka Toivonen wrote:
>
> Ok, I just threw them into this directory:
> http://www.ee.oulu.fi/~tuukkat/tmp/brdotests/
>
> Not pretty, hope they're useful.
> The file sum1-640-480-br.eps contains the average
> result plot over all 12 sequences.
>
> *-rd.eps: rate-distortion curve
> *-br.eps: relative bitrate
> *-qt.eps: quantization parameter vs. execution time
> test.sh: original testing script
>
> Looks like trellis and especially brdo unfortunately
> sometimes increase bit rate, even quite much, especially
> at low bit rates. Would be nice if this case could
> be detected & avoided.

What version of x264? svn-386 should somewhat improve brdo at low
bitrates, and nofast_pskip might do more. (This doesn't fix whatever bug
is causing brdo to increase bitrate, but it reduces the frequency at
which it occurs.)

What are the clips? I have some, but more testcases that break brdo would
help. (The fluctuations in trellis on test1 are also interesting.)

And in several of the graphs, the "x264best2mrbrdtr2" line goes below 90%,
and is not shown :)

On Thu, 15 Dec 2005, Jeff Clagg wrote:
>
> chroma_qp_offset=8?! I don't think this is likely to be used in any
> real encodes.

Agreed.

--Loren Merritt

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html