[FFmpeg-devel] HEVC decoder for Raspberry Pi

[John Cox]

Hi

>On Wed, Nov 14, 2018 at 11:35:50AM +0000, John Cox wrote:
>> Hi
>> 
>> >Hi
>> >
>> >On Tue, Nov 13, 2018 at 03:52:18PM +0000, John Cox wrote:
>> >> Hi
>> >> 
>> >> I have been developing a hevc decoder for Raspberry Pi for some time
>> >> now. As active development has now pretty much ceased and the code is
>> >> believed stable it seems a good time to try presenting it to the group.
>> >> 
>> >> You can find the current code on branch test/4.1.0/rpi_main in repo
>> >> https://github.com/jc-kynesim/rpi-ffmpeg.git. It is based off tag n4.1
>> >> so if you diff it against n4.1 you should get a patch.
>> >> 
>> >> This code has been in use by the Raspberry Pi version of Kodi for over
>> >> two years now.
>> >> 
>> >> If you think it would be a good idea to add this to the main ffmpeg
>> >> distribution then I am willing to put reasonable effort into beating it
>> >> into an appropriate shape.
>> >> 
>> >> If not then it contains a reasonable number of ARM asm functions and
>> >> other code that you might like to take/adapt for the current decoder.
>> >> 
>> >> You will find the config scripts I have been using and a few notes in
>> >> the pi-util directory if you wish to try building it for yourself.
>> >> 
>> >> Just in case it isn't obvious: this will only run on a Pi.  Slightly
>> >> less obviously you need a Pi2 or better as the Pi0 & Pi1 don't have neon
>> >> and are just too slow anyway.
>> >
>> >others may have other oppinions, but i think optimized code in FFmpeg
>> >for Pi would be a good idea.
>> >How to integrate this best though i do not know. And i cant know as
>> >i have just quickly scrolled over the changes not really looked in detail
>> 
>> Well if you want help with understanding what I've done feel free to
>> email me and I'll do my best to explain.
>> 
>> >But its certainly better to have hw optimizations in main git and
>> >not have a seperate repository that needs to be maintained seperatly
>> >for each platform ... and that the user has to find also ... and then
>> >3rd party apps could have even more issues here  if they wanted to use
>> >optimized libs ...
>> 
>> As I said I'm happy to put in reasonable amounts of work to make this
>> happen. If we do want to go ahead then may I suggest that the most
>> efficient way of proceeding would be that I take advice from one
>> experienced person who understands the current hevc code (Michael?) by
>> email until the work is mostly done and then return to the list for
>> final polish?
>
>well, there are multiple ways this could be integrated, and its not
>really my decission which way to go. Whats important is that before
>doing substantial work you ensure that theres noone around who has
>an issue with the choice before.
>
>Now one way it could be integrated would be as a seperate decoder
That is how I've currently built it and therefore probably the easiest
option.

>another is inside the hevc decoder
It started life there but became a very uneasy fit with too many ifdefs.
>a 3rd is, similar to the hwaccel stuff
>and a 4th would be that the decoder could be an external lib that
>is used through hwaccel similar to other hwaccel libs
Possibly - this is where I wanted advice as my attempts to understand
how that lot is meant to work simply ended in confusion or a feeling
that what I wanted to do was a very bad fit with the current framework -
some of the issue with that is in vps/sps/pps setup where I build
somewhat different tables to the common code that is used by most other
h/w decodes.

>you need to obtain the communities preferrance here not just my
>oppinion ...
>especially comments from people activly working on hwaccel stuff
>are needed here
I welcome their comments

>But there is surely code in this change which can be integrated
>and which would not change depending on the higher level integration
>design. An example would be the asm that you already mentioned
>You could split that out into patches and submit these
I'd prefer to get the whole thing in, but if someone else wants to
cherry-pick my changes then they are completely welcome.

>another thing that can be worked on may be to reduce code duplication.
Yup

Regards

JC