I'm working on a homebrew streaming project; basically I live outside my native country and I'm building my own HEVC streaming system for sending my live TV over to where I live. Kind of like Slingbox but better quality for the bandwidth I have available.
ffmpeg is my tool of choice and I've made a Windows x64 build of 3.0 with GPU support for hevc_qsv, nvenc_hevc and libx265 so I can compare them.
The PC that is going to be doing the encoding is a homebuilt Skylake 6770K + NVIDIA GTX 980 running Windows 10 Pro.
A few points as I trial the Intel implementation of HEVC:
1. The Intel Graphics Driver with the latest MSS didn't install on my system. It claimed my PC didn't match the minimum spec, which seems odd given it's Skylake 6770K with Intel Graphics 530. I had to go to the Intel drivers download site to get the latest 6th gen driver and after installing that things started working properly. Previously ffmpeg would hang during an hevc_qsv encode.
2. It's difficult to perform any kind of serious evaluation of hevc_qsv with the 1000 frame limit with the trial. At 50fps that's 20s which simply isn't enough to get a handle on the kind of data sizes this encoder uses.
3. When I use ffmpeg to transcode an h.264 file to hevc there seems to be a problem when I play this back in that the audio starts almost straight away but the video doesn't start until 10-15s later. It's not out of sync but just very delayed. I don't get this problem with either libx265 or nvenc_hevc.
Here is my ffmpeg command:
ffmpeg -i input.mp4 -r 50.00 -vcodec hevc_qsv -preset fast -vb 2000k -bufsize 4000k -vf yadif=1 -acodec aac -ab 96k -y output.mp4
Here is a workaround though:
ffmpeg -i input.mp4 -r50.00 -vcodec hevc_qsv -preset fast -vb 2000k -bufsize 4000k -vf yadif=1 -acodec aac -ab96k -f mpegts temp.ts
ffmpeg -i temp.ts -vcodec copy -acodec aac output.mp4
Now, when I play output.mp4 both video and audio start together and almost straightaway. What arguments do I need to pass into ffmpeg to make it work with one command though?
4. I am aware of the pricing of a license for MSS Pro. For a homebrew project this is obviously way out of my budget, and I wondered if you had any options for people who want to use this plugin in a single-stream closed/private environment? If hevc_qsv turns out to be the best of the three encoders I'm testing then I would be willing to pay something but since I'm neither running a streaming business or developing an application I intend to sell then none of the licenses/featuresets offered on your website are of any use to me.
Thanks for your time.
Very glad to hear that you've gotten so much working through ffmpeg. Since you're running in Windows on Skylake you should be able to specify the plugin ID for the HW accelerated implementation too. Just use "-load_plugins 6fadc791a0c2eb479ab6dcd5ea9da347" as specified in this post: https://software.intel.com/en-us/forums/intel-media-sdk/topic/593838. (This version comes with the Skylake driver, and isn't one of the plugins included with Media Server Studio professional edition.)
Thanks for your feedback on the trial.
1: Windows MSS supports 4th and 5th generation (Haswell and Broadwell), not Skylake yet. However, as you found you can use the client drivers to "preview" Skylake capabilities.
2: The limitation to 1000 frames is intended to give you some sense of quality + performance. But, feedback like this is always important for product planning.
3: Media SDK accelerates the video elementary stream processing only. It seems like what is happening is that timestamps are getting out of sync, but re-encoding may put them back in a regular pattern. The FFmpeg implementation is out of our scope. Not sure that this can be solved from the command line, but the ffmpeg documentation covers some timestamp filters. A better place for this observation may be the ffmpeg mailing list. Alternately, since it is open source, you may be able to go into the libavcodec code and fix it yourself. From Media SDK's perspective timestamps are usually passed through the pipeline unchanged.
4: We generally try to keep this forum on technical topics, not pricing. However, if you like we can find a business representative to follow up with you directly.
Thanks for the comments, Jeff.
I have a better understanding of how everything fits together now. It would seem that in order to use the HEVC hardware encoder I do not actually need MSS.
It seems my earlier tests with what I thought was the HEVC QSV HW plugin via ffmpeg were in actual fact using the software HEVC QSV SW plugin. I realised this after observing the total lack of GPU use! What was confusing was that the code claimed it was initialising the MFX session using the hardware implementation but clearly at some point it was falling back to the software plugin.
Anyway, what I have seen so far with the HEVC QSV HW plugin using the sample SDK code is that the quality at lower (2000k and below) bitrates is really not very good at all at this stage when compared to both the HEVC QSV SW plugin, and also the NVIDIA hardware plugin.
Are there plans to improve it?
On the other hand, the HEVC QSV SW plugin produces excellent quality. Even slightly better than libx265 at the lowest bitrates, in my testing, at least at the settings I can run libx265 in realtime at anyway (ultrafast). If I run libx265 at medium or better then it's comparable to HEVC QSV SW but too CPU intensive for reliable realtime.
Getting ffmpeg to work reliably with the HEVC QSV HW plugin proved too difficult, I guess ffmpeg has some work to do in bringing it up to date with for the Skylake plugin.
Nvidia GPU was surprisingly good - I'd previously written it off as too low quality but that was with ffmpeg 2.8.5. Once I rebuilt it with 3.0 the quality was much better and is currently looking like my preferred encoder as its blindingly fast and not far behind both the HEVC QSV SW plugin and libx265 in quality.
I'll certainly keep an eye out for any improvements in the HEVC QSV HW plugin though, both in terms of its basic quality and its integration with ffmpeg.
Thanks for this great feedback. Intel's codecs are always improving. Please stay tuned This forum is an ideal place to find out about codec capabilities -- and new documentation to make the best use of those capabilities.