[x265] [RFC] Add support for tile header generation

[Nicolas Morey-Chaisemartin]

On 10/28/2014 05:10 PM, Steve Borho wrote:
> On 10/28, Nicolas Morey-Chaisemartin wrote:
>> Hi,
>>
>> I don't know if this makes sense for the mainstream but we use x265 to
>> generate a bitstream with tiles.  This is a patch that simply add the
>> capabilities to generate tile compliant headers although there is
>> absolutely no support for encoding using tiles.
> Tiles are an interesting problem. On the one hand they would allow more
> CTUs to be available for encode at the same time; always a boon. But on
> the other hand a compliant Main or Main10 encode cannot use tiles and
> WPP at the same time.
>
> And unless you restrict the ME search areas to also be tile based
> (introducing even more tile boundary artifacts), you also limit the
> effectiveness of frame parallelism.
>
> For us, tiles are a losing proposition: less parallelism, less
> compression efficiency, less visual quality.
>

I get that. The big advantage for us is memory locality.
But the biggest selling point on tile is for the decoder. Now we manage to decode 4K60 using OpenHEVC on a big CPU.
But when you look at larger resolution (8K 60 or even 120) in 10 bits or more, it takes quite a lot power to handle that.
And if only WPP is used, without tiles or slice, the decoder often cannot get much parallelism.
In this case, tiles are pretty much a must for the moment.

Anyway I'm not talking about adding a full tile support to x265. Although it might be interesting some day.
But I have few patches here to make the bitstream generation (header, entry points, etc..) tile compliant.
It does not have much impact on the overall code but it would limit the impact of our accelerator support in x265.

I'd be glad if these patch could make it upstream so I won't have to rebase/backport everything for each release but as I said the impact isn't too bad so I won't mind too much if you feel that it shouldn't be integrated. ;)