Support FAQ

What bit rate should I set up for the video?

The answer is, to a certain extent, subjective. MPEG compression is “lossy” – in other words, the decoded video does not look “exactly the same” as the original video. There is some loss of (hopefully not very important) information, as a trade-off for a higher compression ratio. Uncompressed standard definition video runs close to 300 Mb/s, while uncompressed high definition video runs close to 1.5 Gb/s. Using lossy compression, these bit rates can come down by a factor of 100 or more.

The encoder video bit rate represents a tradeoff between the video quality and the bandwidth required to transmit the video. In general, increasing the video bit rate increases the quality, but at some point the encoder gets to a region of diminishing returns, where increases in bit rate correspond to very small quality improvements.

The video quality is also a function of the complexity of the content. Simpler content, such as “head and shoulders” (for example, news) will require a lower bit rate than more complex content, such as sports and action movies. The final judge of whether it is “good enough” has to be a human being.

However, we can provide some guidelines. For Standard Definition video, the sweet spot is between 1 and 2 Mb/s. For High Definition video at 720p and 1080i, the sweet spot is between 6 and 8 Mb/s, and at 1080p it is between 10 and 16 Mb/s.

If you need to go to lower bit rates, there is another parameter that can be adjusted: reduce the horizontal resolution to ¾. On playback, all modern decoders will scale the signal back up to full screen. For SD, this means that the resolution will be 528x480 instead of 720x480; for HD, it means that it will be 1440x1080 (instead of 1920x1080) or 960x720 (instead of 1280x720). The image will be “softer”, but with less artifacts; the softness is typically preferable to the compression artifacts. Many broadcasters transmit SD at ¾ resolution.

For audio, what is the difference between AAC-LC and MPEG-1 Layer II? How do I choose one or the other?

AAC-LC and MPEG-1 Layer II are different types of audio encoding algorithms. In general, AAC-LC is somewhat better than MPEG-1 Layer II. “Better” means higher quality at the same bit rate, or lower bit rate for the same quality. However, most consumers will not be able to tell the difference between these two modes at bit rates 128 kb/s or higher.

The only scenario where AAC-LC is required is when streaming to some Apple devices, such as iPods and iPhones. Most IP set-top boxes and professional decoders will support both algorithms.

When transmitting over IP, how do I choose what protocol to use?

The short answer is that you should use a protocol that is compatible with your receiver and with your network. Here are a few guidelines:


  • For MPEG over IP transmission, the most common protocol is UDP. This is supported by all IP set-top boxes and professional decoders. Some software-based decoders, such as VLC, also support it. It is typically not supported on mobile devices and natively on browsers (unless a plugin is installed). 1. The UDP protocol is suitable for well engineered networks, because there is no mechanism to detect and recover from packet loss. UDP transmissions will not work reliably over the general Internet.

  • The standard for transmission of MPEG over IP is the RTP protocol, which runs on top of UDP. RTP is typically only supported on professional decoders; most IP set-top boxes will not support RTP. 1. As with UDP, the RTP protocol requires a well engineered network to avoid packet losses. The only useful advantage of RTP over UDP is its ability to re-order packets. Packet re-ordering may only be necessary if there are multiple paths being used in parallel between the encoder and the decoders. RTP transmissions will not work reliably over the general Internet.

  • The SMPTE 2022 FEC protocol is an adjunct to RTP to allow recovery of lost packets. The MPEG content is transmitted over RTP, and one or two additional redundant flows are transmitted as well. If a packet is lost, it may be recovered using these redundant flows. SMPTE 2022 is typically only supported by professional receivers. 1. RTP plus SMPTE 2022 FEC can be used on links with occasional packet losses (up to a few percent). Usage of this protocol will increase the overhead as additional packets are transmitted. The EN460 GUI will indicate the additional overhead. RTP transmissions with SMPTE 2022 FEC may work over the general Internet depending on location and connection characteristics.

  • If you want to deliver video over the Internet, you have two options, depending on what your target devices are and how many clients you want to support. 1. If you want to deliver video that plays on a web page to a small number (5 or less) of computers, you can use the Direct HTTP mode. The encoder generates a web page that includes the video; clients just point their browsers at the encoder’s streaming port IP address. This mode requires the VLC plugin and will not work for mobile devices. 2.If you want to deliver video to a large number of devices, you can use the HTTP Live Streaming mode. This mode is supported by all Apple devices (iPods, iPhones, iPads, etc) and some set-top boxes. In this mode, the video is actually delivered by a web server, which you can dimension to support however many clients you need. The encoder will upload the video to the web server and automatically create the control files.

What are NULL packets and why do I need them?

NULL packets are “fillers” added to the MPEG stream to make it constant bit rate, with very precise timing. They contain no information.

Most professional decoders require the presence of NULL packets in order to recover precise clocks. Software decoders and IP set-top boxes do not need NULL packets, but will work with streams that include them.

The IP outputs in the EN460 default to including NULL packets because this is the most compatible format. If you are transmitting to IP set-top boxes or software decoders, you can turn off NULL packets and save a bit of bandwidth. If you use the HLS or Direct HTTP modes, the NULL packets are automatically suppressed by the encoder, as none of the target devices for these protocols require them.

How do I play the video in my own web page?

Look at the source of the web page generated by the encoder and copy the block between these two tags:

Additionally, if you are using the Direct HTTP mode, find this line:

var hostval = 'http://' + window.location.host + ':XXXX/encoderY'

Where XXXX will be the port you configured in the encoder (e.g., 8000) and Y will be the encoder channel number (1 or 2), and replace window.location.host with the IP address of the desired encoder streaming port.

Isn’t HTML5 supposed to support video natively? Is the encoder compatible with that?

HTML5 indeed has the "VIDEO" tag, which supposedly allows compatible web browsers to natively play video on a web page. The problem, however, is that the standards community could not agree on exactly what format(s) the browsers were supposed to support. The result of this lack of agreement is that, even though all modern HTML5 browsers support the "VIDEO" tag, there is no single format that is supported by all browsers.

In most cases either a CDN or an origin server will be used to actually connect to the HTML 5 client. Since the formats required are either RTMP or Transport Stream and the EN460 encoders support both formats we do not see any problem in an application using HTML 5.

If I cannot use HTML5, how do I play the video in a web page?

The way to play the video on a web page is through the use of the VLC plugin. In Windows machines, by default only the Internet Explorer plugin is installed; you will need to explicitly select the “Mozilla Plugin” for all the other browsers (Firefox, Safari, Chrome).

Depending on the configuration, the encoder will generate a web page with the appropriate plugin calls embedded. Point the browser at the IP address of the streaming port of the encoder, and follow the web page links. The encoder will generate video on a web page under the following settings:

  • When the output is set to Direct HTTP. In the standalone ITV-EN460c model, the video is also available from the encoder’s control Ethernet port.
  • When the output is set to UDP or RTP, and the destination IP address is multicast. This stream will only be available from the web page served from the Ethernet port configured to transmit the stream.

How do I set up a Windows PC as a Web Server for HLS?

Here is the procedure:

  • 1. Download and install Apache for Windows (either the non-crypto or crypto version). Install for all users, using the default port 80.
  • 2. Download and install FileZilla Server for Windows. You can accept all the default selections. At the end of installation, a window will open to connect to the server administration interface. Just click OK on that (no password is needed).
  • 3. Create a directory where to serve the HLS files from. For simplicity, we suggest C:\HLS.
  • 4. In the FileZilla server administration window, select Edit -> Users, and create the following configuration:
    • a. Select the “General” page, and click on the “Add” button under “Users”. Create an user called “encoder”.
    • b. Check the “Password” box and enter some password for this user.
    • c. Select the “Shared Folders” page, click on the “Add” button under “Shared Folders”, and navigate to the “C:\HLS” directory you created for this purpose.
    • d. Check all the permission boxes under “Files” and “Directories”.
    • e. Click OK to close the Users window.
  • 5. Test the FTP server by attempting to upload a file to it from another computer. Use the “encoder” username and password defined above. If you get no response, add “FileZilla server.exe” to the list of allowed programs in the firewall (this program will be under “\Program Files\FileZilla” or “\Program Files (x86)\FileZilla” depending on your computer).
  • 6. From another computer, point a web browser at the server (just type http://server_ip). You should get a web page that says “It works!”. If you don’t, add “httpd.exe” to the list of allowed programs in the firewall (this will be under “\Program Files\Apache Software Foundation\Apache2.2\bin” or “\Program Files (x86)\Apache Software Foundation\Apache2.2\bin” depending on your computer).
  • 7. You now need to edit the Apache configuration file to point it at the same directory as the FTP server. Since this file is somewhat protected, it has to be done as the administrator (on Windows Vista or later). Proceed as follows:
    • a. Click on Start -> All Programs -> Accessories, right-click on Notepad, and select Run as Adminstrator.
    • b. On Notepad, select File -> Open, navigate to “\Program Files (x86)\Apache Software Foundation\Apache2.2\conf”, select “All Files (*.*)”, and select the file httpd.conf.
    • c. Look for a line that says:
      DocumentRoot "C:/Program Files (x86)/Apache Software Foundation/Apache2.2/htdocs"
    • d. Change it to
      DocumentRoot "C:/HLS"
    • e. Look for a line that says:
      Directory "C:/Program Files (x86)/Apache Software Foundation/Apache2.2/htdocs"
    • f. Change it to
      Directory "C:/HLS"
    • g. Save and close the file.
  • 8. Apache needs to be restarted to get the new configuration. On the system tray, locate the Apache monitor icon (when you place the mouse over it, the description will be “Running all Apache services”), click on it, select “Apache 2.2”, and select “Restart”.
  • 9. In the C:\HLS directory, create a file called index.html with the following contents:
    • Windows Server Test
    • HLS Test
    • Click here for the stream.

Now, configure the encoder to upload to the server you created (using the encoder username and password you defined above), and set the Base File Name to live. You can now use devices such as iPads to navigate to the page above, and when you click on the link, the video will open. IP set-top boxes can point directly to the “live.m3u” file.

How do I interface the EN460 with the Roku Player?

The Roku player supports the HTTP Live Streaming (HLS) protocol for live, real-time content. In order to make the output of the encoder available to a Roku player, configure the encoder as follows:

  • Audio Encoding must be configured for AAC-LC. Both mono and stereo modes work.
  • Encoder output must be configured for HTTP Live Streaming (in the Connections tab). If you want to support a small number of players, you can use the Local server in the encoder; if you want to support a large number of players, configure for an external (Remote) server.
  • You can adjust the segment size and the number of segments according to your latency requirements. Setting the number of segments to 4 will give you a more reliable delivery.

In order to actually receive the stream in the Roku, you will need to create a channel for it. ImmediaTV has provided a general-purpose private test channel (adapted from one of Roku's sample channels) that allows you to specify the URL for the HLS stream. In order to add this channel, log in to your Roku account and use code RQQ2W to add this private channel (or use this link: https://owner.roku.com/add/RQQ2W). ImmediaTV may, at times, make available content from a test encoder accessible through the Internet; if you want to try this with your Roku player, please contact us.

In local server mode, the access URLs for the content are:
http://xxx.xxx.xxx.xxx/HLS/encoder1.m3u8
http://xxx.xxx.xxx.xxx/HLS/encoder2.m3u8
where xxx.xxx.xxx.xxx is the IP Address of the MVN-EN460 Ethernet port. Also note that if you use a browser to go to the encoder IP address, there will be a link for the HLS page.

These instructions apply to both the openGear MVN-EN460 and the modular ITV-EN460c. The ITV-EN460c can serve HLS streams over its control port, as well as the streaming ports.

Company News
cobalt
09.12.2016
Cobalt Acquires ImmediaTV

Amsterdam, NL — Cobalt Digital today announced its acquisition of ImmediaTV, a Silicon Valley company

NABShow_Logo1
03.01.2016
NAB 2016

We will be at booth SU12713 (note new booth number).  Use Guest Pass Code LV9684

CCW new
11.01.2015
CCW 2015

We'll be at booth #859 next week in New York at the CCW/SATCON show. You

More News