IPVTL utilizes both CPU and GPU decoding/encoding technique. The transcoding capacity is basically decided by both the CPU/GPU performance and the video profile you demand. For high density transcoding, we recommend private server with Intel Xeon processsor or NVIDIA Quadro/GRID/Tesla graphics card installed, as they have better parallel computing performance. Intel Core i5/i7/i9 processors with HD Graphics are also recommended for lower density usage at low cost. Use calculator below to get rough idea of choosing hardware.
|H.264 Transcoding Hardware Spec Recommendation|
|Output Video Profile||# of Channels||Minimum CPU/GPU Requirement|
|Server||Xeon e5-2620v3 Dual|
Note: # of channels above are evaluated with pure video transcoding. If video transizing, overlay or other functions are enabled in the channel, more cpu / gpu resources could be involved.
Remember to have a look at CPU load indicator at the bottom of IPVTL Windows or web
UI during transcoding. It tells current CPU usage per core and you get the idea whether
the system performance is good for the processing jobs right now.
Requirements in system / GPU memory can be calculated by 100MB per channel.
HEVC/H.265/AV1 encoding requires much more calculation than H.264/AVC does. Generally, HEVC/H.265 encoding cosumes 50-100% more computing resources than H.264. And AV1 encoding process could be even slower. In these cases, it is recommended to utilize GPU assisted encoding, like NVIDIA Quadro/Tesla card with Maxwell/Pascal GPUs, or Intel 6th/7th (or above) generation Core processor (Skylake & Kaby Lake) with Quick Sync Video acceleration. For HEVC enabled NVIDIA video card specs, visit NVIDIA Video Encode and Decode GPU Support Matrix.
First of all make sure your processor is capable of Intel QSV here. Utilizing Intel QSV acceleration on Windows is recommended, as setup procedures are much easier than on Linux. On Windows, you just need to install Intel HD Graphics driver and make sure the driver has been updated to latest version. Outdated video driver could cause unexpected transcoding problems. If the driver is installed correctly, you can set channel's Video Encoding to Intel QuickSync H.264/HEVC to enable QSV accelerated transcoding.
If everything is ok, you can set IPVTL channel video encoding to Intel QuickSync H.264/HEVC to enable QSV transcoding then.
Intel QSV decoding can be also enabled in advanced video options -> Misc. -> GPU Decoding. This enables full GPU transcoding, avoiding unnecessary memory copy between CPU and GPU.
Intel QSV on Linux platform is not ready for production and we STRONGLY recommend NOT doing so. First it could involve manually installing intel vaapi driver and vainfo packages. If you are using latest distros like ubuntu 20 or above, it is lucky to have those packages in releases so you can just apt install them. Otherwise you may need to download and build from sources at your own risk.
After installation, run vainfo to make sure intel driver working correctly. If not, try environment values LIBVA_DRIVER_NAME like iHD or i965. And set LIBVA_DRIVERS_PATH if driver location cannot be found.
Even all packages are installed and configured properly, QSV functions are very likely to be limited. Setting up encoding options becomes so tricky that most of them can be unusable, especially on latest hardwares.
Consider Intel QSV on Windows or nvidia nvenc on Linux instead.
First of all make sure you have at least 1 NVIDIA video card capable of NVENC here. Then you need to install the latest NVIDIA video driver to enable NVENC acceleration. In IPVTL channel config, set video encoding to NVIDIA NVENC H.264 or NVIDIA NVENC HEVC to enable NVENC accelerated transcoding.
But be noted you only enable half GPU performance so far. CPU is still working on Video decoding and resizing at this moment. To enable full GPU transcoding, select NVDEC decoding H.264 or HEVC (as per your source signal) in advanced vide options -> Misc. -> GPU Decoding. This will put all video decoding, resizing and encoding process (with deinterlacing if required) into GPU, avoiding unnecessary RAM copy between CPU and GPU.
That's it. If you have multiple NVIDIA cards installed, remember to specify which card to be assigned in Misc settings as well.
Note: NVIDIA GeForce GPU and Quadro under
K2000/M2000/P2000 GPU has a limit of 3 encoding sessions max per system. It is a
hard limit by NVIDIA driver. Other Quadro models, Tesla or GRID don't have such limit.
To remove this limit, follow this link for 3rd party driver patch at your own risk.
If you want to monitor NVIDIA GPU load on Windows, GPU-Z tool is recommended. In Sensors tab, please note to watch Video Engine Load that reflects current NVDEC/NVENC working load. Not "GPU Load", which reflects 3D-modeling load instead. If you have more than 1 gpu cards, select and watch them separatedly to keep good balance in multiple transcoding channels. GPU load monitor is also available in Task Manager since Win 10.
On Linux, use nvidia-smi or nvtop in console instead.
IPVTL is designed for live media transcoding only. Although IPVTL can output mpeg ts over http format, it is NOT supposed to provide media stream distribution to large scale audience over the internet. You will need 3rd party media streaming server to do that, like Nginx, Wowza media server and Adobe media server, etc.
Absolutely not. IPVTL software license is bound to per server instance. If you want to run it on more than 1 server instances, please consider purchasing multiple licenses.
You can screencast using IPVTL on Windows. To do that, select "file" as channel source format and enter "desktop" as source name. Then go to advanced format settings -> Custom Options, and enter "-f gdigrab -framerate 5" in Source Options box.
Use the web UI.
IPVTL web UI is fully featured as Windows UI since version 184.108.40.206. You can open it at http://<any_ip_on_ipvtl_host>:8888 in the browser. Refer to Setup Section for details.
By default, IPVTL web UI binds all network interfaces on the localhost and login password is empty. We STRONGLY recommend setting up password in Global Settings IMMEDIATELY after installation, to secure web UI from malicious access. Remember your channel configuration details could be completely exposed to the internet with login password empty.
You can also secure web login from unknown IP address through an ACL config file set up in Global Settings. The ACL syntax supports both blacklist and whitelist, which is very like in nginx:
deny all allow 127.0.0.1/8or
allow all deny 220.127.116.11
IPVTL runs as daemon on Linux from version 18.104.22.168. It is possible to start IPVTL in remote ssh login without nohup now. To stop IPVTL running, simply pgrep ipvtl_ and kill IPVTL main process, or just pkill ipvtl_. Remember NOT to kill -9 (SIGKILL) as it is not a safe way.
On Windows, simply open Global Settings and enable Auto Start on System Boot option. Be noted IPVTL does NOT run as Windows service. It still requires user to login Windows before running.
On Linux, you may accomplish it using cron or rc.local scripts. For cron, enter $ sudo crontab -e under console and add line @reboot <IPVTL_with_full_path>. For rc.local, just edit /etc/rc.local and add IPVTL command with full path.
Several possible reasons:
If there are still problems, please send us feedback via email to support[at]ipvideotrans.com. In your feedback, please let us know your detailed transcoding settings and attach channel log files if possible. To get channel log files, please enable Debug Log in IPVTL Global Settings before starting the channel.
Check transcoding source validy and ensure IPVTL is receiving input stream with tools mentioned above. Make sure VLC is running exactly on IPVTL's output address and is receiving stream out from IPVTL. Open message log in VLC (Tools->Messages) and set log level to max to see full logs. If you are encoding video stream into H.263, remember VLC DOES NOT support H.263 RTP stream playing (only H.263+).
If still no video output, please enable Debug Log in IPVTL global settings and send channel log file back to us (support[at]ipvideotrans.com) to diagnose.
IPVTL log files are named in ipvt_###.log and are located in:
First please make sure the source video quality is fine using tools like vlc player. Remember there is always quality loss during transcoding. You CAN NEVER get better output quality than the source.
If you want to tune video quality for H.264 / HEVC / VPX / AV1 encodings, try changing Encoding Preset in Advanced Video Settings (see instructions). Setting video Quality in the main gui is NOT recommended and it should be kept as default.
For other video encodings like mpeg4 or mpeg2 video, setting video Quality and video Bitrate can both impact the output quality. Make sure the video bitrate is not set too low. If you don't understand about bitrate, just leave it default.
Following subtitles are supported by IPVTL:
1) dvb/dvd subtitle, dvb teletext, CC (EIA 608/708 closed caption) pass through in MPEG TS over UDP format
2) srt/webvtt subtitle pass through in HLS segments
Closed caption is passed through automatically during transcoding. Nothing required on user side.
To pass through dvb subtitle or dvb teletext in MPEG TS UDP output format, open channel format settings and enter "-c:s copy" in Custom Options -> Target Options box. If you want to select some particular subtitle stream to output, please guide Source Stream Selection settings. Make sure to select the proper subtitle pid you prefer.
If you are streaming to other kind of formats than UDP, say rtmp, you may want to hardcode dvb subtitle over video, rather than passing it through. This is possible via IPVTL advanced options. Open channel format settings -> Custom Options and in Target Options box, enter option "-filter_complex '[0:v][s:0]overlay[v]' -map [v]".
You can specify network interface to bind for receiving or sending udp stream. To do that, append option "localaddr=<IP_ADDR>" to the stream url. For example, udp://22.214.171.124:1234?localaddr=192.168.0.1 means to use network interface with IP 192.168.0.1 for udp multicast.
You need to enable CBR encoding mode. See how to enable CBR encoding.
That is true, unfortunately. It is not big problem if you are streaming to udp format. However, it would be annoying when streaming to other kind of formats, like rtmp.
To get over with it, we need to utilize another channel. In that channel, set output to MPEG TS over UDP format and specify a local address, like udp://127.0.0.1:1234. Then in the original channel, set input to udp://0.0.0.0:1234 and leave output encodings to Original to save CPU resources. That will do the trick.
It could be due to long key frame interval in output video. By default IPVTL produces video at 5 seconds key frame interval for better video quality. To shorten the prebuffer time you may try setting Key Frame Interval to a smaller value. See how to in Advanced Settings.
IPVTL evaluation does not run in VMware. Please try it on real machines instead. IPVTL licensed version does run on VMs, however.
First, if the result Frame Size and Frame Rate does not matter much, you can lower them to save bandwidth dramatically. For example, switch frame size from CIF to QCIF, or reduce frame rate from 30 to 15 fps.
Second, the Quality Level and Bandwidth settings both impact output video encoding bitrate. To control video encoding bitrate effectively, revert Quality Level to Original first. Then tune Bandwidth value to make video bitrate at your level. Remember: Low encoding bitrate always leads to low video quality.
If you've got a critical bandwidth limit, you can also try increasing video Key Frame Interval (to 120 or larger, through configuration file mentioned above) and switching Global Header from InBand to OutOfBand.
Yes it is because HEVC has very much more complexity in encoding algorithm than H.264. There is always trade-off between performance and speed. You may try HEVC on a much faster processor, or switch to GPU accelerated HEVC encoding instead.
IPVTL default H.264 encoding settings will indroduce about 50ms delay. If you have a strict demand of transcoding delay, please try advanced option "-tune zerolatency" in Custom Target Options.