Yes, the Intel Media SDK supports a variety of algorithms for Rate Control. AVBR (Average Variable Bitrate) was added to API 1.3 (supported by Media SDK 2012). This is the mode that some applications refer to as 2 pass encoding. Please see the Media SDK Reference Manual for information on how to use this mode.
I would like to use Intel Haswell QSV for 2 pass video encoding. I do realize that it is not doable in one click scenario.
What I think about is to run software 1st pass which is fast enough (in my case using ffmpeg). This task results with .mbtree stats file which basically carries data of information density of input video (or in English info on how to distrubute bitrate most efficiently depending on scene complexity). Then I would like to run h264_qsv 2nd pass with .mbtree file as input of required data distribution to haswell encoder.
When I do as described above, it doesn't really matter if I mention -pass 2 parameter in command line (to inform that ffmpeg should use the stats file for bitrate selection). Output files have the same md5 sums (with and without -pass parameter).
Any idea if it is even possible for QSV?
I would like to you take a look at the two pictures below. They show bitrate distribution in a test video material.
1. x264, 2pass encoded, 4500kbps average bitrate
2. QSV ABR, 4500kbps
As you surely noticed, the QSV video output has pretty much constant bitrate. That means that encoder does not provide enough bitrate in most complex scenes and provides more than enough bitrate for simplier scenes (like low-motion). As a result a viewer could tell which video is lower quality, even though the two have pretty much the same average bitrate for entire file (435MB total for x264 file and 434MB for qsv).
That's because QSV only takes a number of consecutive frames (defined by look_ahead param) and it is not aware of the complexity of entire input material.
What I'd like to do it to provide this information about entire movie complexity to QSV encoder (we get this information by running 1st pass on video and it sits in .mbtree file, software way) so that it will be able to generate file with bitrate distribution very close to what I observe in x264 case. It is possible?
I understand more on your requirement now, I think there is a possibility for this requirement. Basically the current software has a FFmpeg wrapper which allows MSDK plugin to the FFmpeg framework, I will try some test to see if the 2 pass encoding can be done.
Give me sometime and I will get back to you soon.
Yes, my plan is:
1. Confirming the ffmpeg 2 passes command sequence, try to uses the 2 pass process to improve the bitrate.
2. Use Media SDK wrapper to the ffmpeg to see if it can do the same work.
I have completed #1 although I didn't see the bitrate get improved; but I think this is not important for now. I will the Media SDK wrapper and see if it can do 2-pass process.
I will give you update soon.
I am really interested in your outputs.
I tried to run a 2 pass encoding using FFMPEG 3.2, with both h264_qsv decoding and encoding.
It does not really look like to do the 2 passes as I have the same result as if I did 1 pass ..
Can you pleas share your cmd lines ?
Hi, for purpose of this post i have used ffmpeg build N-81508-g99882d0.
For starters, let's make it really clear. I don't mind you using the qsv decoder, but this has nothing to do with the topic. Let's focus on qsv encoder only.
You're right, 2 pass encoding with h264_qsv does not work. That's the whole thing. I imagine that Intel has not implemented this functionality. There's not a single program that's capable of real 2pass encoding with intel qsv. The closest to the truth is MediaCoder which clearly states that functionality has not been implemented yet (when setting qsv with 2pass encoding).
I made two examples to make it clear.
I used a sample test video file, then executed first pass on it, to collect information on video complexity (log files present after running 1st pass, to be used later):
ffmpeg -y -i testfile.mp4 -c:v libx264 -preset slow -pass 1 -passlogfile logs.log -f mp4 /dev/null ( <-- NUL for windows versions)
For usage examples, please refer to: https://trac.ffmpeg.org/wiki/Encode/H.264
Then I executed 2nd pass:
1. ffmpeg with software libx264, 2nd pass:
ffmpeg -i testfile.mp4 -c:v libx264 -preset slow -b:v 2500k -pass 2 -passlogfile logs.log -c:a copy testfile_ffmpeg_libx264_2pass_2500k_avg.mkv
As you can see, software 2 pass does work good.
2. ffmpeg with hardware h264_qsv, 2nd pass:
ffmpeg -i testfile.mp4 -c:v h264_qsv -preset slow -b:v 2500k -pass 2 -passlogfile logs.log -c:a copy testfile_ffmpeg_h264_qsv_2pass_2500k_avg.mkv
Looks like qsv does not take log data into consideration. That's what we would like to accomplish.