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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
