XSplit uses the x264 encoder, so let’s start off by saying that parameters mentioned in the title, with the exception of the quality parameters, mean the same as the parameters in the x264 wiki here:
Since quality is different let’s start off discussing exactly this. In x264 terms the quality is known as the CRF factor or Constant Rate Factor. The encoder accepts any value form CRF=0 (lossless) to CRF = 51 (terrible quality).
When encoding a video stream you can generally apply different rate control schemes. XSplit uses quality based rate control wherein a particular quality of the encoded video is targeted, while still observing an upper bitrate constraint (the vbv-maxrate). There is a huge difference in bitrate required between the different qualities (and it is NOT linear). Most people would not even be able to see any difference between CRF=18 and CRF=0 expect for the fact that a CRF=0 recording leave a pretty huge footprint on the hard drive.
In XSplit terms we use a general quality setting for streaming between 0 and 10, wherein 10 is the highest. Quality 10 corresponds to CRF=25 which is generally a very good quality. Quality 0 in turn corresponds to CRF = 35 which could be acceptable in some cases (but not too pretty).
While it may up for discussion, it is never the less the convention of XSplit to use its own quality parameter and translate internally to CRF. We think people understand quality and they are used to something between 0 and 10 where the latter is the highest. But all this can easily be customized for those who want to go do down this road. So please see this entry about see this entry about customizing settings.
You will notice that for local recording then XSplit will just offer you to set a quality setting and will not have a particular vbv-maxrate or vbv-buffer defined. The idea here is that for a local recording we are often not concerned with bandwidth usage. So a recording which will target a particular quality will be created and depending on the selected quality recording sizes for the same input will vary in size (seems logical enough).
In complex scenes (frames) more bits are used to ensure a consistent visual quality and in less complex scenes less bits a used. The x264 encoder tries to interpret the importance of changes in frame and optimize visual quality depending on the settings (the CRF , aka Quality setting). The base line FPS for quality is 25 frames per second. The x264 will scale its quality based on the frame rate of the video, so a particular quality setting will give lower quality per frame for 60 FPS stream when compared to a 25 FPS. The reasoning here is simple – namely that a single frame at 25 FPS is more important than a single frame at 60 FPS when the overall target is to retain the same visual quality for both the 25 and the 60 FPS stream.
For local recording it can still be desirable to control the maximum bandwidth used, so the UI in XSplit still allows the user to set a vbv-maxrate and vbv-buffer. – we will get back to this shortly.
VBV-buffer and VBV-maxrate:
The two main date rate control mechanisms employed by the x264 encoder are
- Average bitrate mode
- Average quality mode
In the user interface of XSplit we only allow average quality mode as discussed above, since this is often a much more effective mechanism.
However, for both main rate control schemes another supplementary rate control is often used and for successful live streaming with XSplit it is even required - the VBV rate control.
With quality based encoding you are assured of a particular quality but not a particular bandwidth usage. For live streaming it is important not to exceed your own available upload bandwidth, but also important not to exceed the download speed of viewers.
Streaming with a constant bandwidth is an option used by some encoders, but this rate control mechanism (or lack thereof) wastes bandwidths and often put larger requirements on quality of connection for both publisher and viewers.
XSplit instead uses quality based encoding and sets a VBV-maxrate and VBV-buffer. This basically means that the x264 encoder in XSplit tries to maintain a constant quality of the stream and can use less bandwidth in less complex or less important scenes. The VBV-maxrate puts a ceiling to the bandwidth that encoder can use, but relative to the VBV-buffer.
If you set VBV-maxrate=2000 and VBV-buffer=4000 then it will mean that your VBV-buffer (decode buffer) will be filled at a max-rate of 2000 Kbps. Hence your video bitrate can still exceed the discrete value of 2000 Kbps BUT you will not exceed 4000 Kbit during a 2 second period. In other words the VBV-maxrate is not actually the peak bitrate - as in the highest bitrate that can exist in the stream, it's merely the max bitrate that can enter the buffer.
If you grasp this concept then you will also understand the flexibility that the vbv-buffer provides. It basically allows the encoder to look ahead on a series of frames and then choose to use a more bits to encode some frames in a sequence and less on others as long as the vbv-buffer is not exceeded.
But here is what you now need to understand – the vbv-buffer is really a decode side buffer so it depends on the decoder which is mostly flash player in our case. It’s possible to configure flash player with a buffer anywhere from 0 sec to hmm…anything I guess, but most streaming service providers hardcode the buffer settings to either 1 or 2 seconds, so this is why you usually see that XSplit streaming plugins will auto-adjust vbv-buffer to X or 2 * X Kilobits when the vbv-maxrate is set to X Kilobits per second (Kbps) . I hope this is all starting to make some sense ! So this would mean that if flash player buffer with your provider was set to something like 10 sec then you would be able to really beef up my vbv-buffer size and in turn get same quality at lower overall bandwidth or better quality at the same bandwidth – Well , you would esentialy allow more liberty for the encoder to spike the bitrate when needed. So you can expect that the XSplit team will have a dialog with our partners to see if we can actually get them to adjust their flash player buffer to match the VBV –buffer set in XSplit.
On this final note I wanted to get back to our local recording again. So here there is no default max rate (vbv-maxrate) set for a recording and also no vbv-buffer consequently. But if you want to put recorded video on your website and have visitor’s playback the videos with flash player across the internet then you might want to think twice. If you expect that end-viewers will have no more than 1000 Kbps download bandwidth and you want your video to start playback after say 4 seconds , then you will simply apply the appropriate vbv-constraints in addition to the quality you have assigned the local recording.
So in our case above we would use the following XSplit settings:
VBV Max Rate:1000 kbps
VBV Buffer:4000 kbps
Well we probably also should also compensate for audio, but in this case just subtract 1 x audio bitrate from your VBV Max Rate and 4 x audio bitrate form your VBV Buffer and then you are set.
Several built in presets are provided from "Ultrafast" to "Placebo". XSplit uses a custom preset called “XSplit Default”. In the future you can expect that the default will be set to "Veryfast".
But what does this all mean?
H.264 specifies a set of compression features that a decoder must be able to support/decode. Depending on the capabilities of decoders these are segregated into groups of profiles. High Profile, Medium Profile and Base Line Profile. For the moment we will only consider High Profile which is supported by Flash Player.
By using a particular preset the x264 encoder will make use of several advanced preset features to better compress the video bit stream. Anything slower than "Superfast" will result in a High Profile compatible bit stream unless other custom constraints are added – but never mind about that for the moment. All you need to know right now is that the slower preset you select, the more your stream will be compressed and the better quality you can produce with limited bandwidth, BUT it all requires substantial CPU power depending on both frame rate and resolution.
The default preset is either “XSplit Default” or Veryfast” which are more or less equivalent. If no other CPU intensive processes are running at the same time and you wish to broadcast/encode 30 FPS @ 1280 x 720 using the “Veryfast” preset then you should be good with an i5 Processor. If your CPU gets above 70% usage on any core then you will need to:
a) Use a lower resolution
b) Use a faster preset (like superfast)
c) Buy a good core i7 machine
So to make a long story short then the preset you choose will be equivalent to the amount the amount of compression you ask the encoder to perform. The Slower = more compression = more CPU usage.
To elaborate on what you should have learned above then let us just give the answer to the only question that can now be on your mind -:):
Question: If I do a local recording and set my quality to 8 and if I do NOT set any VBV-constraints will I then get a better quality video if I select a slower preset.
Answer: NO YOU WILL NOT. The quality will be absolutely the same, but your recorded video will be less compressed (larger file size) the faster your preset is.
BUT if you do have VBV-maxrate constraints that are restrictive enough then you will see a quality difference because the slower preset will do a better job keeping you under your given VBV-maxrate.