PIXILAB Wiki

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
blocks:live-video [2020-03-05 13:37]
mattias [Local Video In] 		blocks:live-video [2025-07-17 09:33] (current)
fredrik [Local Video In]
Line 1: Line 1:
 ====== Using Live Video in Blocks ====== ====== Using Live Video in Blocks ======
- 
-Blocks 2.1 adds a a Live Video block type, which can be used along with compatible players to integrate live video. 
  
 To use live video: To use live video:
Line 7: Line 5:
   - Create a Live Video root block, or…   - Create a Live Video root block, or…
   - Add Live Video as a child block to a Composition or other suitable type.   - Add Live Video as a child block to a Composition or other suitable type.
-  - Chose the desired stream type. +  - Chose the desired stream type and other settings. 
-  - Specify the URL to the camera/streaming box.+  - Specify the URL to the camera/streaming box (does not apply to local video input).
  
 ===== Live Video Formats ===== ===== Live Video Formats =====
Line 14: Line 12:
 The following formats are supported: The following formats are supported:
  
 +  - RTSP stream. Compatible with most players. Supports audio. Low delay. Supported by most video cameras and streaming boxes.
 +  - RTMP stream. Compatible with most players. Supports audio. Supported by most streaming programs and many streaming devices.
 +  - Local Video In. Compatible with Pixilab player v4.0. Supports audio. Very low latency. Suitable for live camera feeds.
   - HLS stream: Compatible with most players. Supports audio. Delay is several seconds. Supported by some streaming boxes and services.   - HLS stream: Compatible with most players. Supports audio. Delay is several seconds. Supported by some streaming boxes and services.
   - MJPEG stream. Compatible with most players. No audio. Low delay. Supported by many video cameras.   - MJPEG stream. Compatible with most players. No audio. Low delay. Supported by many video cameras.
   - JPEG polling. Compatible with all players. No audio. Low delay. Supported by some video cameras.   - JPEG polling. Compatible with all players. No audio. Low delay. Supported by some video cameras.
-  - RTSP stream. Compatible with few players. Supports audio. Moderate delay. Supported by most video cameras and streaming boxes. 
-  - Local Video In. Compatible with Pixilab player v4.0. Supports audio. Very low latency. Suitable for live camera feeds. 
  
 As you can see, there are pros and cons with the various formats, and it is sometimes not straightforward to find the ideal combination for a given source device and player combination. As you can see, there are pros and cons with the various formats, and it is sometimes not straightforward to find the ideal combination for a given source device and player combination.
  
-==== HLS Stream ==== 
  
-HLS is generally a good format as far as players are concerned, with good quality and scalability, and audio support. In some applications, the rather long delay (often several seconds) associated with this format may be problematic. Finally, support for HLS is rather limited on cameras and streaming boxes.+==== RTSP Stream ====
  
-The [[https://www.aja.com/products/helo |AJA HELO]] is one hardware option for bringing HLS into a Blocks system.+This format is supported by most cameras and streaming boxes, and (since Blocks 4) by PIXILAB Player and most browsers. The Kiloview KV-E2 works well for converting HDMI inputs to RTSP.
  
-{{ :blocks:blocks:video:aja-helo-h264-streamer-recorder.jpg?nolink |}}+https://www.streamingvalley.nl/product/kiloview-e2-hdmi-h264-srt-video-encoder/
  
-It accepts SDI, HDMI and analog audio as inputs (with passthrough), and converts it to various streaming formats, with the option of simultaneous recording of the stream to a memory card. More on HLS streaming and the Helo device below.+A similar box from the same manufacturer accepts SDI instead of HDMI.
  
-==== MJPEG Stream ====+{{ :blocks:blocks:video:kiloview-e1-4.jpg?nolink |}}
  
-This format is also supported by many players, and is commonly supported by cameras as well. It typically has very low delay, but doesn't support audio. Some cameras may protect the MJPEG url with authentication, which then needs to be disabled for Blocks to access the stream.+To minimize latency, chose a small custom GOP size (for example 5 frames), or a single frame only (only I-frames). When choosing a smaller GOP structure, the bitrate may need to be increased to maintain video quality. However, keep in mind that a higher bitrate puts more load onto the Blocks server, as it re-packages and distributes the stream, as well as on the network for distributing it. This is especially true when using numerous players simultaneously. 
  
-==== JPEG Polling ====+==== RTMP Stream ====
  
-This format has many similarities with MJPEG in that it has low delay, good player compatibility and no audio. It incurs a higher overhead, in that each image is fetched separately. This may also occasionally result in dropped frames.+RTMP, while similar in some ways to RTSP, works with other types of devices and programs such as [[https://obsproject.com|OBS]] and [[https://www.vmix.com|vMix]], as well as some hardware devices, like the popular [[blocks:live-video:atem-mini|ATEM Mini Pro]] from Blackmagic.
  
-It is supported by some network cameras, such as the Unifi line of cameras (which do not support MJPEG). Like MJPEG, you may need to disable any authentication in the camera for Blocks to be able to read the URL.+One notable caveat with RTMP, that makes it different from the other streaming formats supported by Blocks is the way the connection is made between the RTMP source and Blocks. RTMP expects the external device to make the connection to Blocks, and "push" the video to Blocks. This is the opposite of RTSP, where Blocks takes the initiative of connecting to the camera, essentially "pulling" the video stream from its source when it's requested by a Spot.
  
-{{ :blocks:blocks:video:unifi-video-g3-flex-camera.jpg?nolink |}}+This difference means that some streaming sources may have trouble connecting to Blocks unless Blocks is already expecting the stream, as Blocks won't "listen" for the stream until requested by a Spot. Some devices, such as the ATEM Mini Pro and the [[https://www.streamingvalley.nl/product/kiloview-e2-hdmi-h264-srt-video-encoder/|Kiloview]] streaming box, is OK with that and will just keep attempting to connect until it succeeds. Other sources, such as OBS, will just display an error message when trying to connect unless the Blocks is actively listening for that connection.
  
 +Thus, to use a streaming source that expects the server to listen before it will try to connect, do one of the following:
  
-==== RTSP Stream ====+  * Wait with starting the streaming source until you know there's at least one Spot requesting the video. 
 +  * Keep an extra "monitor Spot" displaying the live feed all the time.
  
-This format is supported by most cameras. Depending on the encoding, delay may be short to moderate (seconds). Player support, however, is very limited. As of this writing, only the Brightsign range of players support this format natively (verified with a Brightsign XD2 player with firmware version 6.2.147).+The second of these options essentially makes sure that Blocks is always actively listening for the stream, even if no other spot is yet showing it.
  
-{{ :blocks:blocks:video:brightsign-xd233.jpg?nolink |}}+Finally, due to the direction the stream is flowing in, you need to set up the stream URL at the streaming //source//, pointing it to the Blocks server using its address. Thus, if Blocks runs on 10.2.0.10, your would use a stream URL like this on the streaming source:
  
 +<code>
 +rtmp://10.2.0.10
 +</code> 
 +
 +In Blocks, you can typically leave this set to the default URL, which means that the Blocks server will listen for this stream on all its network interfaces (if it has more than one). The default URL is
 +
 +<code>rtmp://0.0.0.0</code>
 +
 +To use multiple RTMP streams at the same time, add a port number after the IP address, separated by a colon. The default port number used by RTMP is 1935.
  
 ==== Local Video In ==== ==== Local Video In ====
  
-From Blocks version 4 it is possible to use a local video source captured by a [[https://en.wikipedia.org/wiki/USB_video_device_class|UVC]] capture device connected to the USB port of the Pixilab Player. There are all sorts of capture devices available on the market that supports UVC.  Most webcameras would probably work but it is a good idea to try before buy. +Blocks 4 and later supports local video, captured by a [[https://en.wikipedia.org/wiki/USB_video_device_class|UVC]] adapter connected to a USB port of a PIXILAB Player (version 4 or later). THis method results in very low latency – at most a few frames. Not all adapters will work, however, so either go with one of the recommended devices listed below, or test the adapter well in advance. You can only use //one// such local adapter/camera, and the video fed through this adapter can only be shown on the player to which is connected.
-Blocks do not support multiple local devices. +
  
-Prerequisits: +Web browser have restrictions for accessing a local video camera/source, and require specific settings to allow this without user intervention. PIXILAB Player is pre-configured to allow this when used with the //pixi.guide// domain name and the Chrome browser. These settings are found in the browser policy settings. If you need to use another domain name or a raw IP address, follow [[blocks:porteus_kiosk#manage_pixilab_player_chrome_policies_from_the_blocks_server|this guide]].)
-Blocks 4.0 or newer +
-Pixilab Player 4.0 or newer running Chrome browser +
-Server using pixi.guide domain name. (This is the kiosk default setting as this is depending of some Chrome policies, the policies can be overrided by following this FIXME guide.)+
  
-We have tested the following devices sucessfully. +The following adapters hage been used successfully. 
  
-  * Inogeni 4K HDMI to USB 3.0 +  * Epiphan AV.io 4K HDMI to USB 3 
-  * Magwell USB Capture HDMI Gen 2+  * Magwell USB Capture HDMI 3 
 +  * Inogeni 4K HDMI to USB 3 
 + 
 +==== HLS Stream ==== 
 + 
 +HLS is generally a good format as far as players are concerned, with good quality, scalability and audio. In some applications, the rather long delay (often several to more than ten seconds) associated with this format may be problematic. Finally, support for HLS is  limited on cameras and streaming boxes. 
 + 
 +The [[https://www.aja.com/products/helo |AJA HELO]] is one hardware option for bringing HLS into a Blocks system. 
 + 
 +{{ :blocks:blocks:video:aja-helo-h264-streamer-recorder.jpg?nolink |}} 
 + 
 +It accepts SDI, HDMI and analog audio as inputs (with passthrough), and converts it to various streaming formats, with the option of simultaneous recording of the stream to a memory card. More on HLS streaming and the Helo device below. 
 + 
 +==== MJPEG Stream ==== 
 + 
 +This format is also supported by many players, and is commonly supported by cameras as well. It typically has very low delay, but doesn't support audio. Some cameras may protect the MJPEG url with authentication, which then needs to be disabled for Blocks to access the stream. 
 + 
 +==== JPEG Polling ==== 
 + 
 +This format has many similarities with MJPEG in that it has low delay, good player compatibility and no audio. It incurs a higher overhead, in that each image is fetched separately. This may also occasionally result in dropped frames. 
 + 
 +It is supported by some network cameras, such as the Unifi line of cameras (which do not support MJPEG). Like MJPEG, you may need to disable any authentication in the camera for Blocks to be able to read the URL. 
 + 
 +{{ :blocks:blocks:video:unifi-video-g3-flex-camera.jpg?nolink |}}
  
-Plain game capture devices will probably not work. 
-We have tested the following devices unsuccessfully.  
  
-  * Elgato CamLink 4K 
 ===== HLS Streaming Options ===== ===== HLS Streaming Options =====
  
Line 99: Line 124:
  
   * **HLS** news feed http://livepull1.secure.footprint.net/antena3mpp/bitrate_4.m3u8   * **HLS** news feed http://livepull1.secure.footprint.net/antena3mpp/bitrate_4.m3u8
-  * **HLS** on-demand stream http://184.72.239.149/vod/smil:BigBuckBunny.smil/playlist.m3u8+  * **HLS** on-demand stream http://qthttp.apple.com.edgesuite.net/1010qwoeiuryfg/sl.m3u8
   * **MJPEG** public webcam http://217.152.196.254/axis-cgi/mjpg/video.cgi?camera=1   * **MJPEG** public webcam http://217.152.196.254/axis-cgi/mjpg/video.cgi?camera=1
   * **Polling JPEG** public webcam http://62.108.201.7/record/current.jpg   * **Polling JPEG** public webcam http://62.108.201.7/record/current.jpg
 +
 +(Please note this is 3rd party links and may well come and go or even being removed permanently)
  
 Some public cameras using the "polling jpeg" method may have rate limits, meaning that if you poll them too frequently, your feed may stop working. Public cameras come and go, so some of the above streams may no longer be available by the time you read this. A quick google search should turn up plenty of others. Some public cameras using the "polling jpeg" method may have rate limits, meaning that if you poll them too frequently, your feed may stop working. Public cameras come and go, so some of the above streams may no longer be available by the time you read this. A quick google search should turn up plenty of others.