IPVTL utilizes both CPU and GPU decoding/encoding technique. The transcoding capacity is decided by both the CPU/GPU performance and the video profile you demand. For high density transcoding, we recommend private server with Intel processsor or NVIDIA Quadro/GRID/Tesla graphics card installed, as they have better parallel computing performance. Intel Core i5/i7/i9 processors with UHD 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 | Channels | Minimum CPU/GPU Requirement | |
| i7 8core (with UHD) / 8G RAM | |||
Note: # of channels above are evaluated with PURE video transcoding. Video resizing, overlay and other video processings will eat more cpu and gpu resources.
Remember to have a look at CPU load indicator at the bottom of IPVTL main window
or web console during transcoding. It tells current CPU usage per core so you
will get the idea whether the system performance is sufficient for streaming right now.
Requirements in system / GPU memory can be calculated by 100MB per channel.
HEVC/H.265/AV1 encoding involves much more calculation than H.264/AVC does. Generally, HEVC/H.265 encoding eats 50-100% more computing resources than H.264. And AV1 encoding is even a lot slower than HEVC. For these cases, it is recommended to replace CPU encoding with GPU, like NVIDIA Quadro/Tesla card with Maxwell/Pascal GPUs, or Intel Core 8th gen processor or above (Coffee lake) with UHD Graphics. 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 IPVTL channel video encoding to H.264 (qsv) / HEVC (qsv) to enable QSV transcoding then.
Intel QSV decoding can be also enabled in advanced video settings -> 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 against Linux.
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 H.264 (nvenc) or HEVC (nvenc) 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 picture copy between system memory and video memory.
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 GTX/RTX and Quadro under
K2000/M2000/P2000/T2000 GPU has a limit of 3/5 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 or Adobe media server.
See How to setup IPVTL with Nginx.
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 Param, and enter "-f gdigrab -framerate 5" in Source Parameters box.
Use the web console.
IPVTL web console is fully featured as Windows
UI since version 6.1.4.4. You can open it at
http://<ipvtl_host_ip>: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 addresses through ACL rules 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 1.2.3.4
IPVTL runs as daemon on Linux from version 5.9.3.0. 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 is still problem, 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 full channel log file, please enable Debug Log in IPVTL Global Settings and restart 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:
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 Param -> Target Parameters box. If you want to select some particular subtitle stream to output, please guide Source Stream Selection sector. 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 Param and in Target Parameters box, enter "-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://224.0.0.1:1234?localaddr=192.168.0.1 means
to use network interface with IP 192.168.0.1 for udp multicast.
You need to enable Mux Bitrate. 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.
For audio-only streaming, we suggest extra parameter "-re" in IPVTL advanced format settings -> Custom Param -> Source Param box. That usually makes audio output smoother.
To create MPTS output, you need to set up several channels. Please follow instructions here.
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.
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 parameter "-tune zerolatency" in Custom Target Parameters box.