N-41010-g3956b12 (from today ->
http://johnvansickle.com/ffmpeg/):
frame= 3018 fps= 24 q=0.0 Lsize=N/A time=00:01:01.70 bitrate=N/A
video:283kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=293.263s
bench: maxrss=629456kB
Yeah - when openhevc sends their patches upstream, we will pick them - for the time being, you need to package your own ffmpeg and change FFMPEG-VERSION accordingly.
Yes, but benchmark like this can measure decoding performance. I don't know how much power is needed to display/scale decoded frames. But when saying about decoding OpenHEVC is 2x faster... unfortunately.
When trying to play with ffplay, OpenHEVC plays it smoothly, regular ffmpeg doesn't (on my i7). I suspect it's because decoding (not scaling/displaying) performance, because it can't even decode with >= 50 fps.
Quote:N-41010-g3956b12 (from today -> http://johnvansickle.com/ffmpeg/):
frame= 3018 fps= 24 q=0.0 Lsize=N/A time=00:01:01.70 bitrate=N/A
video:283kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=293.263s
bench: maxrss=629456kB
So, 24 fps vs 11 fps ? Indeed 2x faster.
Quote:Yeah - when openhevc sends their patches upstream, we will pick them - for the time being, you need to package your own ffmpeg and change FFMPEG-VERSION accordingly.
Yes I can, but most likely it will cause another problems.
Here is the result with openhevc ffmpeg:
frame= 3018 fps= 38 q=0.0 Lsize=N/A time=00:01:01.70 bitrate=N/A
video:283kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=211.774s
bench: maxrss=647112kB
The one above was with standard ffmpeg from git.
You were right the openhevc implementation is about 1.6 times faster on my system.
So ffmpeg git: 24 fps
openhevc ffmpeg: 38 fps
So - the ffmpeg benchmark values are approximately double then it would be when rendering and scaling.
Btw. the code difference between them and ffmpeg upstream is: 106500 lines!
I don't know if they have any plans to merge their changes into upstream ffmpeg. Actualy, they develope their own hevc decoding library and ffmpeg is not main focus (as far as I undestood it correctly):
https://github.com/OpenHEVC/openHEVC
But they forked ffmpeg to make their work available for regular users. As you can see, their results are quite impressive. Today it's probably the best hevc decoder, even better than most closed and commercial codecs.
(2014-09-28, 13:41)fritsch Wrote: [ -> ]Btw. the code difference between them and ffmpeg upstream is: 106500 lines!
So I can assume I will not able to merge their patches with xbmc's ffmpeg. It will be to hard for me to correctly embed their ffmpeg in xbmc (if it's even possible).
From other hand, I can understand your policy, you are using standard ffmpeg and you don't want to jump to some other forked version, since it can cause many problems etc. But, regarding to hevc, current solution in Kodi is not very good.
Why you trying to jump the barrel, get the ffmpeg updated by doing your work with ffmpeg master and working and then it will eventually all be in kodi, not work directly in project which doesn't really have interest in maintaining custom patches and are working to avoid them.
Also you sound slightly impatient and dont remember tan not long ago a ffmeg version update in kodi was a nightmare and now its almost been trivialized. Also considering how hevc is hardly mainstream and kodi already plays it should also help you put your work to work in correct place. no?
I don't really unedrestand what's your point, also I have no idea how to bump ffmpeg version in Kodi before compilation, is it described anywhere? As far as I know, Kodi devs removed possibility to configure with external ffmpeg.
And I'm not so sure if it's good idea though, because Kodi uses its own modified ffmpeg version, if I use another without Kodi patches, the result can be unpredictable (look at Debian problems - they use their own ffmpeg). I can try to merge openhevc ffmpeg with Kodi ffmpeg, but, since I don't know how does it work, I'm pretty sure I will fail with this.
At the end, I will lost any support from Kodi team, but of course it should be expected when changing sources.
It's quite easy. fork ffmpeg to github, make a prerelease. Change FFMPEG-VERSION within xbmc source tree -> done.
Don't worry, it is often hard to understand uNi's posts LOL.
I think he is suggesting that you become a ffmpeg developer, backport all of openhevc into ffmpeg, and eventually the code will make it's way into xbmc/kodi.
So sometime in about 3 years...
Sometimes the reluctance of XBMC to take patches that aren't put into core ffmpeg can be frustrating, but the dev team is not really in a position to cherry pick patches from openhevc, libav and a score of other specialised ffmpeg offshoots. Shame, because the best of all projects would be a wonder, but it's not really XBMC's mission, or within it's ability to do.
(2014-09-29, 09:31)nickr Wrote: [ -> ]I think he is suggesting that you become a ffmpeg developer, backport all of openhevc into ffmpeg, and eventually the code will make it's way into xbmc/kodi.
I don't think it's possible today
Not enough skills to do this so far... but in the future, who knows
But not near future.
I tried to pick the "relevant" bits yesterday. But they are 100.000 lines(!) of code different.
So probably hevc deoding support is written from scratch. With such big difference I suspect it will not possible to automatically merge Kodi patches into it, manual code review and fixes will be neccesary. Then test if all thing works, etc.
But I'm not familiar with git and I don't know anything about ffmpeg internals so I can only suspect as above, maybe I'm not right.
It rather seems they missed to rebase / merge with ffmpeg upstream for a whole long time. If they really want to make their fork usable for anything else besides HEVC. They will rebase at a point and then we see what patches they really need.
It is one of big disadvantages of using internal ffmpeg. We are unable to use external ffmpeg installed system wide. I know reasons why internal ffmpeg is forced to use, but there are also disadvantages of that.