[FFmpeg-devel] HEVC decoder for Raspberry Pi

[Michael Niedermayer]

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
another is inside the hevc decoder
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
you need to obtain the communities preferrance here not just my
oppinion ...
especially comments from people activly working on hwaccel stuff
are needed here

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

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

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20181115/a07e35dd/attachment.sig>