<p>I've worked through a similar project over the last 6 months, and performed more tests than I can keep track of now.  So this is a little fresh for me.  With your questions:</p>
<blockquote>
<p>4K camera -&gt; capture card -&gt; Linux PC (compression) -&gt; RTSP</p>
</blockquote>
<p>This will work well</p>
<blockquote>
<p>Are blackmagic ursa mini 4K and decklink card able to do the first 2
stages respectively?</p>
</blockquote>
<p>Yes</p>
<blockquote>
<p>Is ffmpeg + libx264 able to perform real-time compression at such a high bitrate?</p>
</blockquote>
<p>It's possible, but I'm going to say that whichever way you spin it, you're likely going to arrive at getting a hardware card.</p>
<blockquote>
<p>If not, any recommendation for hardware encoding card?</p>
</blockquote>
<p>nVidia Quadro cards are excellent.  Anything with a Maxwell GM204 chipset or higher.  Even a sub $1000 card will open up the world of possibilities, especially when it comes to hardware accelerated resizing, format conversion, and producing multiple outputs.</p>
<h3>A note about libx264</h3>
<p>I advise care getting advice from anyone who hasn't used it for the purposes you're trying.  The theoretical and unit tests don't always account for everything.</p>
<p>libx264 is an excellent encoder.  It's well known it produces superior quality encodes than say a hardware accelerated h264 encoder <strong>for the same bitrate</strong>.  It also has a whole heap of specific options that can maximise efficiency and produce a video with multiple 264 layers that is friendly to all types of clients.</p>
<p>The strength of libx264 isn't realtime encoding though.  Yes it has zerolatency tuning options, and crf modes to reduce cpu demand, but every small change can make a major impact on encoding time.  The difference between doing a 2560x1440 encode and a 3840x2160 encode is drastic.  The difference between a yuv420p and yuv444p is also drastic.</p>
<p>Also, importantly, many of the options that make the significant difference in libx264 are lookahead options, these unashamedly prfioritize the end product as opposed to the performance of getting to the end product.</p>
<p>No implementation of x264 that I know of, does threading very well.  You can have a rack server with 200GB ram, and 24 actual CPU cores, and max them out very quickly.</p>
<p>One of the <strong>&quot;gotcha&quot;</strong>'s of libx264 is that you can seemingly have it running so well that it looks like a video player - i.e. - you plug something into the SDI port, and it shows up on the network player.  Amazing.  You can have it running for days... Then all of a sudden when the input signal becomes very complex (i.e. low lighting, stage effects like haze, fast detailed motion, fades and transitions, etc.), all of a sudden the roof comes tumbling down reveal 35 issues that look like one.  You remove the issues one by one, and by the time you have it running a treat, you <em>may</em> decide that x264 isn't going to cut it.</p>
<p>Having said that - running at a higher bitrate, requires less compression, and does run noticeably better than at low bitrates.</p>
<p>Given the cost of hardware cards, the doors they open up, and putting that up against the scope of your project, I would highly recommend getting one, whether you use it or not.</p>
<p>At high bitrates - the benefits of libx264 are negated - in fact - h264_nvenc can do realtime 2pass encoding, with spacial and temporal motion filtering and lookahead.  Since you want less than 1s latency, you may not use these, but they are included in some low latency presets.</p>
<h2>Blackmagic</h2>
<p>The decklink SDK works well with linux.  It's simple to configure card options, change inputs, and using the tools provided you build your own capture tools if required.  Even a $199 Decklink 4K Mini Recorder PCIe card works well.</p>
<h2>Example pipeline</h2>
<p>Blackmagic -&gt; Encoder -&gt; RTSP</p>
<p>From that RTSP signal you could then run all of these at the same time:</p>
<ul>
<li>RTSP -&gt; Low bitrate preview / wifi stream</li>
<li>RTSP -&gt; Archive</li>
<li>RTSP -&gt; Create RTMP stream -&gt; Send to live streaming site</li>
<li>RTSP -&gt; Create a 1080p stream -&gt; RTSP</li>
<li>RTSP -&gt; Create an adaptive DASH stream with multiple resolutions</li>
</ul>

CC BY-SA 3.0
2017-05-11T08:56:57.707Z
Thanks a lot for the detailed answer! It seems I'll be getting a hardware encoder card based on your advices. On the other hand, I'm still not sure about the "Encoder -> RTSP" part. I suppose using ffmpeg and nvenc to encode first, feed the output into ffserver, and output as an RTSP stream is the way to go?
Chang
CC BY-SA 3.0
2017-05-11T11:16:21.223Z
`ffmpeg` is great.  It needs to be compiled manually with all the nvidia extensions, and also the decklink SDK
hmedia1
CC BY-SA 3.0
2017-05-11T00:56:08.613Z
2017-05-11T01:31:53.273Z
2020-06-17T09:53:03.607Z
hmedia1
<p>(Background: I'm relatively familiar with using ffmpeg and libx264 to produce videos on demand, but I'm quite new to live streaming)</p>

<p>I'm currently tasked with a project to compress a 4K camera's raw 12G-SDI or 6G or 3G feed and live-stream the compressed feed through RTSP over UDP. I also need to decide which equipments to purchase. The requirements are as follows: </p>

<ul>
<li><p>The compression target can be one of the following: 100Mbps, 200Mbps, 500Mbps, 800Mbps. The target will not be changed on the fly once set. </p></li>
<li><p>Codec must be h.264 or h.265. </p></li>
<li><p>The latency from camera to RTSP output needs to be &lt;1s. </p></li>
<li><p>No budget limit, although &lt; $25K would be better. </p></li>
</ul>

<p>Currently I'm thinking of the following setup: </p>

<p>4K camera -> capture card -> Linux PC (compression) -> RTSP</p>

<p>My questions are: </p>

<ul>
<li><p>Are blackmagic ursa mini 4K and decklink card able to do the first 2 stages respectively? </p></li>
<li><p>Is ffmpeg + libx264 able to perform real-time compression at such a high bitrate? If not, any recommendation for hardware encoding card? </p></li>
</ul>

<p>Thanks! </p>

<streaming><transcoding>
Questions on workflow: 12G-SDI to 500Mbps to RTSP stream
Chang
# Questions on workflow: 12G-SDI to 500Mbps to RTSP stream

(Asked by: username_0 on 2017-05-01)

(Background: I'm relatively familiar with using ffmpeg and libx264 to produce videos on demand, but I'm quite new to live streaming)

I'm currently tasked with a project to compress a 4K camera's raw 12G-SDI or 6G or 3G feed and live-stream the compressed feed through RTSP over UDP. I also need to decide which equipments to purchase. The requirements are as follows:

* The compression target can be one of the following: 100Mbps, 200Mbps, 500Mbps, 800Mbps. The target will not be changed on the fly once set.
* Codec must be h.264 or h.265.
* The latency from camera to RTSP output needs to be <1s.
* No budget limit, although < $25K would be better.

Currently I'm thinking of the following setup:

4K camera -> capture card -> Linux PC (compression) -> RTSP

My questions are:

* Are blackmagic ursa mini 4K and decklink card able to do the first 2 stages respectively?
* Is ffmpeg + libx264 able to perform real-time compression at such a high bitrate? If not, any recommendation for hardware encoding card?

Thanks!

**Tags:** streaming, transcoding


---

## 1 answers

### Answer by username_1 on 2017-05-11. Score: 4 | Accepted answer

I've worked through a similar project over the last 6 months, and performed more tests than I can keep track of now. So this is a little fresh for me. With your questions:

> 4K camera -> capture card -> Linux PC (compression) -> RTSP

This will work well

> Are blackmagic ursa mini 4K and decklink card able to do the first 2
> stages respectively?

Yes

> Is ffmpeg + libx264 able to perform real-time compression at such a high bitrate?

It's possible, but I'm going to say that whichever way you spin it, you're likely going to arrive at getting a hardware card.

> If not, any recommendation for hardware encoding card?

nVidia Quadro cards are excellent. Anything with a Maxwell GM204 chipset or higher. Even a sub $1000 card will open up the world of possibilities, especially when it comes to hardware accelerated resizing, format conversion, and producing multiple outputs.

### A note about libx264

I advise care getting advice from anyone who hasn't used it for the purposes you're trying. The theoretical and unit tests don't always account for everything.

libx264 is an excellent encoder. It's well known it produces superior quality encodes than say a hardware accelerated h264 encoder **for the same bitrate**. It also has a whole heap of specific options that can maximise efficiency and produce a video with multiple 264 layers that is friendly to all types of clients.

The strength of libx264 isn't realtime encoding though. Yes it has zerolatency tuning options, and crf modes to reduce cpu demand, but every small change can make a major impact on encoding time. The difference between doing a 2560x1440 encode and a 3840x2160 encode is drastic. The difference between a yuv420p and yuv444p is also drastic.

Also, importantly, many of the options that make the significant difference in libx264 are lookahead options, these unashamedly prfioritize the end product as opposed to the performance of getting to the end product.

No implementation of x264 that I know of, does threading very well. You can have a rack server with 200GB ram, and 24 actual CPU cores, and max them out very quickly.

One of the **"gotcha"**'s of libx264 is that you can seemingly have it running so well that it looks like a video player - i.e. - you plug something into the SDI port, and it shows up on the network player. Amazing. You can have it running for days... Then all of a sudden when the input signal becomes very complex (i.e. low lighting, stage effects like haze, fast detailed motion, fades and transitions, etc.), all of a sudden the roof comes tumbling down reveal 35 issues that look like one. You remove the issues one by one, and by the time you have it running a treat, you *may* decide that x264 isn't going to cut it.

Having said that - running at a higher bitrate, requires less compression, and does run noticeably better than at low bitrates.

Given the cost of hardware cards, the doors they open up, and putting that up against the scope of your project, I would highly recommend getting one, whether you use it or not.

At high bitrates - the benefits of libx264 are negated - in fact - h264\_nvenc can do realtime 2pass encoding, with spacial and temporal motion filtering and lookahead. Since you want less than 1s latency, you may not use these, but they are included in some low latency presets.

## Blackmagic

The decklink SDK works well with linux. It's simple to configure card options, change inputs, and using the tools provided you build your own capture tools if required. Even a $199 Decklink 4K Mini Recorder PCIe card works well.

## Example pipeline

Blackmagic -> Encoder -> RTSP

From that RTSP signal you could then run all of these at the same time:

* RTSP -> Low bitrate preview / wifi stream
* RTSP -> Archive
* RTSP -> Create RTMP stream -> Send to live streaming site
* RTSP -> Create a 1080p stream -> RTSP
* RTSP -> Create an adaptive DASH stream with multiple resolutions

> **Comments:**
> **username_0**: Thanks a lot for the detailed answer! It seems I'll be getting a hardware encoder card based on your advices. On the other hand, I'm still not sure about the "Encoder -> RTSP" part. I suppose using ffmpeg and nvenc to encode first, feed the output into ffserver, and output as an RTSP stream is the way to go?  
> **username_1**: `ffmpeg` is great.  It needs to be compiled manually with all the nvidia extensions, and also the decklink SDK  

---

