Answers.Body: <p>You might have done by this time.
  Please share if done.</p>
  <pre><code>ffmpeg -i input -c copy -f fifo -fifo_format flv -map 0:v -map 0:a rtmp://url
  </code></pre>
  <p>Ref:
  <a href="http://underpop.online.fr/f/ffmpeg/help/fifo.htm.gz" rel="nofollow noreferrer">http://underpop.online.fr/f/ffmpeg/help/fifo.htm.gz</a></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-03-06T02:54:03.520Z
Answers.LastActivityDate: 2023-03-07T21:11:00.357Z
Answers.LastEditDate: 2023-03-07T21:11:00.357Z
Answers.UserDisplayName: gaamaa
Body: <p>I'm trying to achieve something pretty simple, but it's very hard to describe:</p>
  <p>There is a live video stream which uses <em>h264</em> for it's video, and <em>m4a</em> for it's audio. This stream is not mine, and I have absolutely no control on it: I can use it as-is.</p>
  <p>The required transfer bandwidth graph looks like this below:</p>
  <p><a href="https://i.sstatic.net/8MVJA.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/8MVJA.png" alt="enter image description here" /></a></p>
  <p>Huge impact when there is a <em>keyframe</em>, then relax period until next keyframe.</p>
  <p>My <em>MachineA</em> receives this stream, and I want to republish it to my other <em>MachineB</em> (only to 1 single place).</p>
  <p>Why? Because MachineA <em>can</em> receive the stream, however MachineB (due to geo-lock), can't.</p>
  <p>But, between MachineA and MachineB there is a VPN, so MachineA could (and actually can) forward (republish) the stream to MachineB.</p>
  <p>The only problem is, that there is a bandwidth limitation between MachineA and MachineB, which causes the stream to quite frequently pausing: (green line shows the bandwidth limitation):</p>
  <p><a href="https://i.sstatic.net/oCf8G.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/oCf8G.png" alt="enter image description here" /></a></p>
  <p>The solution I'm looking for is to utilize some clever <em>ffmpeg</em> approach:</p>
  <ol>
  <li>ffmpeg opens the stream on MachineA</li>
  <li>On MachineB I open the stream from MachineA, and <strong>buffers</strong> it for <em>X</em> seconds, before playing.</li>
  </ol>
  <p>So I basically want to solve this problem similar to old-school <em>disc-man</em>'s anti-shock protection:</p>
  <ol>
  <li>fill up the buffer</li>
  <li>play the buffer</li>
  </ol>
  <p>This was a FIFO approach, ie.: MachineA sends a frame to MachineB, which puts it into buffer. Once buffer is full, MachineB starts feeding it to decoder. This way it can smoothen the bandwidth, as long as the average bandwidth of the stream is less-than-equal to the max bandwidth of the VPN between machines.</p>
  <p>How could I manage this with <em>ffmpeg</em>? I.e.: ffmpeg on MachineA receives the stream and republish to ffmpeg on MachineB. ffmpeg on MachineB applies this FIFO approach, and then it displays the received stream.</p>
  
Tags: <ffmpeg><streaming>
Title: FFMPEG: FIFO buffer to smoothen bandwidth requirements?
UserDisplayName: Daniel
ThreadText: # FFMPEG: FIFO buffer to smoothen bandwidth requirements?
  
  (Asked by: username_0 on 2022-12-04)
  
  I'm trying to achieve something pretty simple, but it's very hard to describe:
  
  There is a live video stream which uses *h264* for it's video, and *m4a* for it's audio. This stream is not mine, and I have absolutely no control on it: I can use it as-is.
  
  The required transfer bandwidth graph looks like this below:
  
  [![enter image description here](https://i.sstatic.net/8MVJA.png)](https://i.sstatic.net/8MVJA.png)
  
  Huge impact when there is a *keyframe*, then relax period until next keyframe.
  
  My *MachineA* receives this stream, and I want to republish it to my other *MachineB* (only to 1 single place).
  
  Why? Because MachineA *can* receive the stream, however MachineB (due to geo-lock), can't.
  
  But, between MachineA and MachineB there is a VPN, so MachineA could (and actually can) forward (republish) the stream to MachineB.
  
  The only problem is, that there is a bandwidth limitation between MachineA and MachineB, which causes the stream to quite frequently pausing: (green line shows the bandwidth limitation):
  
  [![enter image description here](https://i.sstatic.net/oCf8G.png)](https://i.sstatic.net/oCf8G.png)
  
  The solution I'm looking for is to utilize some clever *ffmpeg* approach:
  
  1. ffmpeg opens the stream on MachineA
  2. On MachineB I open the stream from MachineA, and **buffers** it for *X* seconds, before playing.
  
  So I basically want to solve this problem similar to old-school *disc-man*'s anti-shock protection:
  
  1. fill up the buffer
  2. play the buffer
  
  This was a FIFO approach, ie.: MachineA sends a frame to MachineB, which puts it into buffer. Once buffer is full, MachineB starts feeding it to decoder. This way it can smoothen the bandwidth, as long as the average bandwidth of the stream is less-than-equal to the max bandwidth of the VPN between machines.
  
  How could I manage this with *ffmpeg*? I.e.: ffmpeg on MachineA receives the stream and republish to ffmpeg on MachineB. ffmpeg on MachineB applies this FIFO approach, and then it displays the received stream.
  
  **Tags:** ffmpeg, streaming
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2023-03-06. Score: 1
  
  You might have done by this time.
  Please share if done.
  
  ```
  ffmpeg -i input -c copy -f fifo -fifo_format flv -map 0:v -map 0:a rtmp://url
  
  ```
  
  Ref:
  <http://underpop.online.fr/f/ffmpeg/help/fifo.htm.gz>
  
  
  ---
  
  