[FFmpeg-devel] libx264 (no-)mbtree parameter

Jason Garrett-Glaser darkshikari
Fri Dec 4 21:34:52 CET 2009


On Fri, Dec 4, 2009 at 9:37 AM, Erik Slagter <erik at slagter.name> wrote:
>> > - enabling b-pyramid disables mbtree automatically (and vv) (dodgy but
>> > quick)
>> > - an extra bit in one of the flags
>> > - "mis"-use one of the existing avcontext fields that aren't used by
>> > libx264, e.g. prediction_order_method (I really don't know the semantics
>> > of this field in other codecs, just a wild guess)
>> > - ignore the issue completely and wait for libx264 to implement
>> > b-pyramid-compatible mbtree semantics and guess that would obsolete
>> > no-mbtree.
>>
>> It's still useful in general, as the faster speed presets in x264 use
>> --no-mbtree. ?Make it a flag.
>
> Okay.
>
> BTW: I did some benchmarks this afternoon with the latest x264, highest
> quality settings suitable for "main" profile, and it appears mb_tree is
> actually faster than the old code, in this context (which obviously
> surprised me). The question is whether this remains relevant if it holds
> over the whole range of settings. Anyone experience? Also it seems to be
> more efficient (I am very carefully here ;-)) even though it doesn't
> implement b-pyramid.
>
> Maybe one of the x264 devels can comment on this?

What is "the old code"?

>> > i_slice_max_size; ? ?/* Max size per slice in bytes; includes estimated
>> This is probably the one that I've seen the most requests for.
>
> If I only knew what it does ;-) Would there by any chance be comparable
> functionality in other codecs so a field in avcodec can be reused?

I recall there's a similar field that is used for H.263, but I'm not
sure of its name.

Dark Shikari



More information about the ffmpeg-devel mailing list