{"id":332,"date":"2014-10-11T14:47:41","date_gmt":"2014-10-11T14:47:41","guid":{"rendered":"http:\/\/blogs.gentoo.org\/lu_zero\/?p=332"},"modified":"2014-10-18T08:42:10","modified_gmt":"2014-10-18T08:42:10","slug":"vdd14-discussions-hwaccel2","status":"publish","type":"post","link":"https:\/\/blogs.gentoo.org\/lu_zero\/2014\/10\/11\/vdd14-discussions-hwaccel2\/","title":{"rendered":"VDD14 Discussions: HWAccel2"},"content":{"rendered":"
\nI took part to the Videolan Dev Days 14<\/b> weeks ago, sadly I had been too busy so the posts about it will appear in scattered order and sort of delayed.\n<\/div>\n

Hardware acceleration<\/h2>\n

In multimedia, video is basically crunching numbers and get pixels or crunching pixels and getting numbers. Most of the operation are quite time consuming on a general purpose CPU and orders of magnitude faster if done using DSP or hardware designed for that purpose.<\/p>\n

Availability<\/h3>\n

Most of the commonly used system have video decoding and encoding capabilities either embedded in the GPU or in separated hardware. Leveraging it spares lots of cpu cycles<\/strong> and lots of battery<\/strong> if we are thinking about mobile.<\/p>\n

Capabilities<\/h3>\n

The usually specialized hardware has the issue of being inflexible<\/strong> and that does clash with the fact most codec evolve quite quickly with additional profiles<\/strong> to extend its capabilities, support different color spaces, use additional encoding strategies and such. Software<\/strong> decoders and encoders are still needed and need badly.<\/p>\n

Hardware acceleration support in Libav<\/h2>\n

HWAccel 1<\/h3>\n

The hardware acceleration support in Libav grew (like other eldritch-horror<\/strong> tentacular code we have lurking from our dark past) without much direction addressing short term problems and not really documenting how to use it.<\/p>\n

As result all the people that dared<\/strong> to use it had to guess, usually used internal symbols that they wouldn’t have to use and all in all had to spend lots of time and
\nhad enough grief when such internals changed.<\/p>\n

Usage<\/h4>\n

Every backend required a quite large deal of boilerplate code to initialize the backend-specific context and to render the hardware surface wrapped in the AVFrame.<\/p>\n

The Libav backend interface was quite vague in itself, requiring to override get_format<\/code> and get_buffer<\/code> in some ways.<\/p>\n

Overall to get the whole thing working the library user was supposed to do about 75% of the work. Not really nice considering people uses libraries to abstract<\/strong> complexity and avoid repetition<\/strong>…<\/p>\n

Backend support<\/h4>\n

As that support was written with just slice-based decoder in mind, it expects that all the backend would require the software decoder to parse the bitstream, prepare slices<\/strong> of the frame and feed the backend with them.<\/p>\n

Sadly new backends appeared and they take directly either bitstream or full frames, the approach had been just to take the slice, add back the bitstream markers the backend library expects and be done with that.<\/p>\n

Initial HWAccel 2 discussion<\/h3>\n

Last year since the number of backends I wanted to support were all bitstream-oriented and not fitting the mode at all I started thinking about it and the topic got discussed a bit during VDD 13<\/strong>. Some people that spent their dear time getting hwaccel1<\/strong> working with their software were quite wary of radical changes so a path of incremental improvements got more or less put down.<\/p>\n

HWAccel 1.2<\/h4>\n