[x265] x265 "Custom Implementation"

[chen]

Hello,
 
In your describe, seems similary my previous FPGA architecture, it is based on task pool.
the biggest problem isn't on the interface, the bottleneck is transfer bandwidth and dispose latency.
Of course, RDO context is another bottleneck.

Best regards,
Min
 
At 2014-03-25 01:04:57,"Nicolas Morey-Chaisemartin" <nmorey at kalray.eu> wrote:
>Hi everyone,
>
>My company (Kalray) is looking into writing a HEVC encoder based on x265 on its many core processor (MPPA-256).
>Because of our architecture (distributed, limited memory among other things), a direct port of x265 is not a viable solution.
>
>Our plan is to write a custom encoder core optimized for our platform and use it as an accelerator for x265 running on a x86 processor.
>This should look something like that
>
>/-------------------------\                 /---------------------\
>|  x86                    |                 | 1 or more MPPA-256  |
>|                         ||                     |
>|  x265 preAnalysis +     |<= PCI Link => | Kalray Encoder Core |
>|  Rate Control           ||                     |
>|                         ||                     |
>\-------------------------/                \---------------------/
>
>The idea for the encoder core is to implement a CTU encoder.
>This leaves us some flexibilty on how we want to dispatch the CTU accross the cores (Tiles, frame parallelism, etc.)
>
> From what I could gather after a quick glance at x265 code is that right now, x265 is using HM "as is" to do the actual encoding. Meaning except for a few exceptions, HM code is use directly to try out the different modes, estimate cost, generate bitstream, etc.
>
>Therefore, our idea was to use HM structures as a "stable" interface between x265 and our encoder core. From these structures we can extract all the required info (pixels, reference frames, QPs, etc.) and convert/transfer it to our core.
>
>What is your opinion on this approach?
>Is HM classes (at least structure wise) an interface stable enough to do this?
>
>We are still in the design phase about this so any idea is more than welcome.
>
>Regards
>-- 
>Nicolas Morey Chaisemartin
>Phone : +33 6 42 46 68 87
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20140325/c87136f8/attachment-0001.html>