[giaur]

Oh yes, opensource world is so complicated... I think we will never see that changes on upstream ffmpeg, the same as we'll never see xbmc's ffmpeg changes in upstream etc...

[Martijn]

the same as we'll never see xbmc's ffmpeg changes in upstream etc...

and that's where you are way wrong
a lot of our custom patches have been send upstream and accepted. only few remain

[fritsch]

And our policy is: We don't take anymore custom patches that are not sent upstream in the same moment.

We have approximately 14 patches left -> https://github.com/xbmc/FFmpeg/commits/release/2.3-xbmc

[giaur]

Out of interest: How did you build xbmc with openhevc's ffmpeg version?

I didn't to this, I only compared official xbmc, official ffplay and openhevc ffplay and I reported my results xbmc (kodi) and official ffplay are the same performance, openhevc is better.

and that's where you are way wrong Smile
a lot of our custom patches have been send upstream and accepted. only few remain

But official ffmpeg is still not suitable for kodi, right? And probably it will never be. All of us know about debian issues caused by external ffmpeg.

---

And our policy is: We don't take anymore custom patches that are not sent upstream in the same moment.

We have approximately 14 patches left -> https://github.com/xbmc/FFmpeg/commits/release/2.3-xbmc

Ok I don't know your policy details, I only reported my test results in hope to be useful somehow.

[Martijn]

that's the problem for debian, not us.

[giaur]

Indeed, but it shows that official ffmpeg is not the same than your fork even if your patches are accpeted by ffmpeg upstream, debian uses official ffmpeg. Personally I don't care because I can always compile official xbmc and everything works.

[wsnipex]

Indeed, but it shows that official ffmpeg is not the same than your fork even if your patches are accpeted by ffmpeg upstream, debian uses official ffmpeg. Personally I don't care because I can always compile official xbmc and everything works.

thats why we have the fork until we get all our patches upstream or change our code to not need them anymore.

[DJ_Izumi]

Well, even at stock a 3770K tackles 4K HEVC just fine. I had it at 4.3ghz but went back to stock trying to see if I could make it quieter.

[giaur]

I just noticed 4k hevc to be better than h264. From unkownown reasons one of my 4k dci movies (taken by OnePlus One phone) causes strange cpu load - first core at 100%, other cores almost none. And movie is not smootch. It's really weird, because any other movie taken with my phone is ok and all cpu cores are used as should.

But after I converted it to hevc, everthing is fine. Overall cpu load is about 30%, all cores. Really strange, I think h264 support in ffmpeg is also not as good as it seems.

[AndreNewman]

I just noticed 4k hevc to be better than h264. From unkownown reasons one of my 4k dci movies (taken by OnePlus One phone) causes strange cpu load - first core at 100%, other cores almost none. And movie is not smootch. It's really weird, because any other movie taken with my phone is ok and all cpu cores are used as should.

But after I converted it to hevc, everthing is fine. Overall cpu load is about 30%, all cores. Really strange, I think h264 support in ffmpeg is also not as good as it seems.

That sounds like a single sliced h264 encode, for example the HD-PVR is well known for generating single sliced h264 that is hard to decode. The way the video is encoded can have a massive effect on software decoders, I don't know if h265 is inherently better for multicore decoders but I suspect if it wasn't nothing would be able to play it!

Slicing is a technique used in h264 encodes where the picture is encoded in multiple strips "slices" this makes it easier for a multicore decoder to spread the decode load across cores, it's often less efficient than a single slice encode.

[fritsch]

Sorry in advance: lol

4k is a resolution ... nothing more. And as AndreN pointed out a lot more parameters play an important role.

[giaur]

Thanks for info, I didn't know that. So it seems my phone after software uptade started to generate files more efficient while encoding, but hard to multicore decoding?

I can't see this effect to be inherited after I reencode it to hevc using ffmpeg. However, I didn't try to reencode to h264 I hope it will help for h264. Because now I'm unable to play h264 from my phone on i7, it's not nice. Also, phone can play that files without any problems.

[fritsch]

Btw. Can you transcode that hevc file to a standard level 5.1@high file and q 21 h264 cfr? How does that look? Also disable HW decoding just for testing. There might be other issues with your specific HW accel.

Edit: please dont use other custom settings. Jeep constant framerate, etc. In e.g. handbrake you only need to select profile and quality.

[giaur]

I'm not sure how to transcode it that way using ffmpeg? Also there is no any hw acceleration in my case because my gpu doesn't support it for hevc and h264 4k.

I have only issue with single core decoding for some h264 4k dci from my oneplus. After transcoding it to hev1 with ffmpeg (I only put average bitrate 15Mbps and nothing more) it works pretty well.

[wsnipex]

use handbrake.