<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: ABDUL RAHMAN</title>
    <description>The latest articles on DEV Community by ABDUL RAHMAN (@devlobb).</description>
    <link>https://dev.to/devlobb</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F784464%2F5a99ce6d-6368-48ec-94cc-3d40937c55d0.jpeg</url>
      <title>DEV Community: ABDUL RAHMAN</title>
      <link>https://dev.to/devlobb</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/devlobb"/>
    <language>en</language>
    <item>
      <title>How I Built a Stable 24/7 YouTube Livestream on a VPS Using FFmpeg (No SaaS Required)</title>
      <dc:creator>ABDUL RAHMAN</dc:creator>
      <pubDate>Sun, 28 Dec 2025 19:38:56 +0000</pubDate>
      <link>https://dev.to/devlobb/how-i-built-a-stable-247-youtube-livestream-on-a-vps-using-ffmpeg-no-saas-required-1bid</link>
      <guid>https://dev.to/devlobb/how-i-built-a-stable-247-youtube-livestream-on-a-vps-using-ffmpeg-no-saas-required-1bid</guid>
      <description>&lt;p&gt;Most live-streaming tools make 24/7 YouTube streaming sound easy — until you read the pricing page.&lt;/p&gt;

&lt;p&gt;Recently, I wanted to run a continuous 24/7 livestream to YouTube. The challenge?&lt;br&gt;
Most SaaS streaming platforms either:&lt;/p&gt;

&lt;p&gt;• charge monthly fees&lt;br&gt;
• limit long-running streams&lt;br&gt;
• or only allow full features on paid plans&lt;/p&gt;

&lt;p&gt;Since I already operate my own VPS, I decided to engineer a fully self-hosted solution using FFmpeg — stable enough to run indefinitely.&lt;/p&gt;



&lt;p&gt;&lt;strong&gt;Challenge&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;The stream worked at first, but YouTube repeatedly showed:&lt;/p&gt;

&lt;p&gt;• “Not receiving enough video”&lt;br&gt;
• “No data”&lt;br&gt;
• Buffering warnings&lt;/p&gt;

&lt;p&gt;Which meant the stream wasn’t stable, and viewers experienced freezes.&lt;/p&gt;

&lt;p&gt;It looked like a network problem — but it wasn’t.&lt;/p&gt;



&lt;p&gt;&lt;strong&gt;Root Cause&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;On the VPS, FFmpeg was using ~98–100% CPU constantly.&lt;/p&gt;

&lt;p&gt;At 100% CPU:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;encoding slows&lt;/li&gt;
&lt;li&gt;timestamps drift&lt;/li&gt;
&lt;li&gt;bitrate becomes unstable&lt;/li&gt;
&lt;li&gt;sometimes YouTube receives 0 kbps&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;So the problem was simple:&lt;/p&gt;

&lt;p&gt;The stream was CPU-bound, not bandwidth-bound.&lt;/p&gt;



&lt;p&gt;&lt;strong&gt;Technical Fix&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;The goal was to keep CPU safely below ~60%.&lt;/p&gt;

&lt;p&gt;I tuned FFmpeg as follows:&lt;/p&gt;

&lt;p&gt;Use a faster preset&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;-preset superfast
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;Apply predictable bitrate control&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;-b:v 2000k
-maxrate 2000k
-bufsize 4000k
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;Keyframe interval for 30fps&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;-g 60
-keyint_min 60
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;Scale when needed&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;-vf scale=1280:-2
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;






&lt;p&gt;Final Working Command (Simplified)&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;ffmpeg -re -stream_loop -1 -i video.mp4 \
-vf scale=1280:-2 \
-c:v libx264 -preset superfast -profile:v high \
-b:v 2000k -maxrate 2000k -bufsize 4000k \
-g 60 -keyint_min 60 -r 30 -pix_fmt yuv420p \
-c:a aac -b:a 128k -ar 44100 \
-f flv rtmp://a.rtmp.youtube.com/live2/STREAM_KEY

&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;CPU dropped to ~50–60%, and the stream stabilized to Excellent Health.&lt;/p&gt;




&lt;p&gt;&lt;strong&gt;Key Takeaways&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;• CPU load directly affects live-streaming stability&lt;br&gt;
• Stable bitrate &amp;gt; chasing maximum resolution&lt;br&gt;
• VPS-based streaming requires margin and monitoring&lt;br&gt;
• FFmpeg tuning matters in production&lt;/p&gt;




&lt;p&gt;&lt;strong&gt;Why I Built This&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;I wanted a reliable 24/7 stream without SaaS cost limitations, and since I already maintain servers, building it myself made sense — and it turned into a great engineering exercise across streaming, DevOps, and system reliability.&lt;/p&gt;

</description>
      <category>opensource</category>
      <category>devops</category>
      <category>performance</category>
      <category>tutorial</category>
    </item>
    <item>
      <title>Content Security Policy with PHP</title>
      <dc:creator>ABDUL RAHMAN</dc:creator>
      <pubDate>Wed, 23 Feb 2022 13:30:16 +0000</pubDate>
      <link>https://dev.to/devlobb/content-security-policy-with-php-5d07</link>
      <guid>https://dev.to/devlobb/content-security-policy-with-php-5d07</guid>
      <description>&lt;p&gt;Use X-Frame-Options and Content-Security-Policy with PHP&lt;/p&gt;

&lt;p&gt;Most of today's browsers can help protect your site from malicious attacks if you tell them so. A method that is almost universally supported is to set the X-Frame options. If this option is set, the browser does not allow other sites to display your own site in an iframe. This protects against clickjacking attacks and should be used on all sensitive pages such as the login page.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;// Adds X-Frame-Options to HTTP header so that page can only be shown in an iframe of the same site.
header('X-Frame-Options: SAMEORIGIN'); // FF 3.6.9+ Chrome 4.1+ IE 8+ Safari 4+ Opera 10.5+

&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;Users who work with a current browser automatically benefit when a website sends a Content Security Policy (CSP) in the header. With a CSP, you can define where JavaScript code is accepted from, which pages are allowed to display your page in an iframe, and many other things. If a browser supports CSP, this can be effective protection against cross-site scripting. &lt;a href="https://developers.google.com/web/fundamentals/security/csp" rel="noopener noreferrer"&gt;more…&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;The implementation in PHP is very simple, but problems can arise with inline JavaScript. You get the greatest protection if you avoid all JavaScript in the HTML files and instead store them in separate *.js files. In case this is not possible (existing source code), there is an option to allow inline-script.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;// Adds the Content-Security-Policy to the HTTP header.
// JavaScript will be restricted to the same domain as the page itself.
header("Content-Security-Policy: default-src 'self'; script-src 'self';"); // FF 23+ Chrome 25+ Safari 7+ Opera 19+
header("X-Content-Security-Policy: default-src 'self'; script-src 'self';"); // IE 10+

&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



</description>
      <category>php</category>
      <category>javascript</category>
      <category>security</category>
      <category>programming</category>
    </item>
  </channel>
</rss>
