-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Quicksync HEVC bugs and problems #1558
Comments
I have just noticed that decoder_avc_qsv.cpp is setting
but decoder_hevc_qsv.cpp isn't. I'll now patch this and try to build from source on Arch Linux instead of using the package, and check if that changes anything.... |
I have now built OME from source including its ffmpeg. I added I also built your ffmpeg version including va-api. Now I would like to test if that is faster. However, for this, I would need to pass libavcodec the equivalent of the ffmpeg parameter I think that in general it might be a good idea for OME to always set Can you give me any pointers on how/where in the OME code I could pass such an initialization parameter? |
Recently we improved performance by enabling zero copy on xilinx and nvidia hardware accelerators. But we haven't done that for qsv yet. Because we thought no one was using it. |
Maybe I should not have put all of these subjects into one issue, but you definitely need to correct the codec name from "h265_qsv" to "hevc_qsv" for it to work at all. What a lot of people don't know: A $150 MiniPC with Intel N5095 has the same Quicksync encoder as expensive Intel Core CPUs. Such a Mini PC is able to transcode 8 FHD streams in parallel. For a non-commercial project we are running an array of 8 of those. This is fast and MUCH more power-efficient than any other transcoding solution there is. If you are interested, I might do a write-down on this some time in the future. And as you know qsv H.264 encoding has a MUCH higher quality than OpenH264. This has worked fine for H.264 sources for a while now, but I want to support HEVC, too. This is where the problem started... When it comes to the HECV qsv decoder, something must be wrong. It's not normal that decoding takes 10x the CPU load than encoding. This might also be a driver bug, or a bug in libmfx, or somewhere between. It might be related to some pixfmt issue, for example. I'll try to patch stuff to try use the va-api path for HEVC qsv decoding and see if that makes a difference. Not an easy task for someone who doesn't know much about the internals of libavcodec, but I'll try... As said, at this point this is a non-commercial project. However, I would be interested in acquiring an "enterprise license" in the sense that I would like to get my hands on the missing source files to support x264 to be more flexible. Should I go through the general ovenmedia contact address or do you have a more direct point of contact? |
And I am aware that qsv does have direct transcoding path, where both decoding and encoding is done in one step in the GPU and is blazingly fast using an internal pixmt. But of course that is completely incompatible with the flexible pipeline of OME, so that's a no-no sadly. |
I am not experienced enough with github, else I would create a pull request. So, again, this is the important bug that should be fixed: In decoder_hevc_qsv.cpp:
The codec is called "hevc_qsv", not "h265_qsv". So this line must be changed to:
After fixing this, HEVC decoding with Quicksync works. |
I would appreciate it if you could post a PR about this. |
irlkitcom: Thank you for doing this, I still have to learn how to do PRs... |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Hi,
I am trying to transcode on the origin a HEVC stream coming in via srt, and re-publish it, encoding it as HEVC and AVC.
In theory this works fine.
However, first of all there is this bug in decoder_hevc_qsv.cpp:
const AVCodec *_codec = ::avcodec_find_decoder_by_name("h265_qsv");
The codec is called "hevc_qsv", not "h265_qsv".
After fixing this, HEVC decoding and everything works.
However, there is one thing that is really strange: HEVC decoding is ten times slower than encoding. To decode the single incoming HEVC stream, four threads are each eating 40% CPU:
However, encoding only takes a single thread with 14% CPU, as you would expect with qsv:
1091914 root 20 0 2018M 751M 48848 S 14.7 2.4 0:08.19 Ench264Qsv
I looked at the code, but can not find any reason why this happens.
If I disable qsv for decode, but only enable to for encode, it looks like this:
So, as you can see, now HEVC decode is in software, and only uses 3 threads, but is just as slow as DechevcQsv with four threads.
It looks like no matter what, even when specifying the the correct codec name hevs_qsv, qsv decode is not used.
Please note: I am using the Archlinux ovenmediaengine 0.16.5-1 package, which is using their own ffmpeg build. But the build flags look identical to the ones you are using.
Sadly for the machines I have which have RHEL/Rocky running, I don't have an igpu. Have you patched ffmpeg anywhere so that a "h265_qsv" decoder exists and works properly, or is this untested?
And a related question: I have read that the qsv codecs inside va-api might be faster and better than when using qsv directly, as it may use Intel-provided non-free codec blobs (libmfx and libvpl) - but not sure if that is true. Have you considered supporting va-api? From what I understand all you would need to do is enable this in libva, similar to
-hwaccel vaapi -hwaccel_device /dev/dri/renderD128
in ffmpeg.Thank you very much for your great work!
The text was updated successfully, but these errors were encountered: