[x264-devel] x264 Development Newsletter: Vol. 28

[Jason Garrett-Glaser]

On Thu, Apr 5, 2012 at 4:24 AM, aviad rozenhek <aviadr1 at gmail.com> wrote:
> On Wed, Apr 4, 2012 at 20:30, Jason Garrett-Glaser <jason at x264.com> wrote:
>>
>> > its been a month since your last x264 development newsletter, the
>> > mailing
>> > list hardly contains information regarding future and current
>> > developments
>> > anymore ... :-(
>>
>> That's because discussion has pretty much always been on #x264dev IRC, not
>> here.
>>
>> > would you entertain a few questions to spark discussion?
>> >
>> > 1. is x264 likely to (significantly) improve in terms of bits/quality
>> > efficiency?
>>
>> If someone comes up with good enough new ideas!  But it's a lot harder
>> than it used to be and a lot of the improvements in the pipeline are
>> not so general-purpose (e.g. OpenCL lookahead).
>>
>>
>> > 2. is x264 likely to get (noticeably) faster for existing intel desktop
>> > processors like Bloomfield or Lynnfield?
>>
>> Unlikely, but I said that before Loren optimized trellis too.
>
>
> does the integration of the GPU into the CPU itself, like in AMD's APUs or
> Intel's HD3000 make it more feasible to offload parts of the encode to the
> GPU?

In theory.  For example, offloading main-encoder motion estimation
(NOT lookahead) to the GPU would require relatively fine-grained
synchronization (on the order of 10s of microseconds of latency,
basically).  While putting it on the same die is nearly required for
this sort of latency, it doesn't magically get you it either, and even
with AMD's Fusion, I imagine this would be quite a ways off.

> that's very interesting, I didn't know that.
> I guess it only works when encoding to the same resolution, though ...
> would it make sense to encode to one resolution [lets call it the master
> resolution] using adaptive GOP settings, and then encode all other
> bitrates/resolutions using the GOP boundaries of the master resolution?

You could do that.

Jason