Development list for x264, a free library for encoding H264/AVC video streams.

aviad rozenhek | 5 Apr 2012 13:24

Re: x264 Development Newsletter: Vol. 28

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?

> 3. adaptive bitrate has become very important, and with it, synchronized
> GOPs across encodes in different bitrates.
> this is currently supported in x264 by using fixed sized GOPs. what are your
> thoughts regarding a more content-aware approach?

x264 supports this with adaptive GOP too; all encodes with the same
lookahead settings and the same source will give the same distribution
of frame types, no matter what the bitrate.

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?

> 4. what are you thoughts regarding the upcoming HEVC/H265 standard, and will
> there be an x265?

I don't know, are you offering to write one? =P

if wishes were horses ;-)

Jason
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel

--
Aviad Rozenhek

_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel

headers

Jason Garrett-Glaser | 5 Apr 2012 13:42

Re: x264 Development Newsletter: Vol. 28

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
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel

headers

Alex Giladi | 6 Apr 2012 16:24

Re: x264 Development Newsletter: Vol. 28

On Thu, Apr 5, 2012 at 7: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:
>>
...
>> > 3. adaptive bitrate has become very important, and with it, synchronized
>> > GOPs across encodes in different bitrates.
>> > this is currently supported in x264 by using fixed sized GOPs. what are
>> > your
>> > thoughts regarding a more content-aware approach?
>>
>> x264 supports this with adaptive GOP too; all encodes with the same
>> lookahead settings and the same source will give the same distribution
>> of frame types, no matter what the bitrate.
>
>
> 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 can "borrow" the frame types (either programmatically, or using
the stats file) and reuse either IDR's or all frame types.
You end up having essentially a 2-pass encode, with one "master", and
N-1 "slaves", and all N have same segmentation properties.
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel