如何通过RTMP向Azure Media Service Secondary INGEST URL推流？副URL推流失败求助

Are Secondary INGEST URLs Still Usable? #

Absolutely—Azure Media Service (AMS) Secondary ingest URLs are built as a core redundancy mechanism to keep your streaming workflows highly available. They’re enabled by default and should work just as reliably as Primary URLs under normal conditions. The handshake stall you’re encountering is almost certainly not because the URL itself is unavailable, but rather a fixable issue with configuration, network connectivity, or FFmpeg settings.

How to Push to Secondary URL via RTMP (Plus Troubleshooting for Your Handshake Problem) #

Let’s break down the correct setup and troubleshoot the stuck handshake:

1. First, Confirm Your Secondary URL Format

AMS RTMP ingest URLs follow one of these standard patterns:

• Unsecured: rtmp://<ams-ingest-endpoint>/<stream-name>
• Secured (token-based): rtmp://<ams-ingest-endpoint>/<stream-name>?token=<valid-ingest-token>

Double-check that your Secondary URL is complete—no typos, and if using token authentication, verify the token hasn’t expired and has proper ingest permissions.

2. Working FFmpeg RTMP Push Command

Use this tested baseline command (adjust bitrates and codecs to match your source):

ffmpeg -re -i "/path/to/your/video-source.mp4" -c:v libx264 -preset medium -b:v 2000k -c:a aac -b:a 128k -f flv "<your-secondary-ingest-url>"

• -re: Critical for pushing at the source’s native frame rate (prevents overwhelming the ingest endpoint)
• libx264 + aac: Mandatory codecs for AMS RTMP ingest
• -f flv: RTMP requires FLV encapsulation to work with AMS

3. Fix the Stuck Handshake

Your observation of FFmpeg sending 0x0C and 1536 bytes without response points to a failed handshake. Try these fixes:

• Test Network Connectivity: Verify your machine can reach the Secondary endpoint’s RTMP port (default 1935) with:

  telnet <secondary-ingest-endpoint> 1935
  # Or for modern systems
  nc -zv <secondary-ingest-endpoint> 1935
  

  If this fails, check firewall rules, network proxies, or AMS IP whitelisting settings (if enabled in your account).
• Update FFmpeg: Older FFmpeg versions (pre-4.x) have known bugs with RTMP handshake logic. Upgrade to the latest stable release (5.x or newer) and retry.
• Enable Verbose Logging: Add -v verbose to your FFmpeg command to get granular handshake details:

  ffmpeg -v verbose -re -i "/path/to/your/video-source.mp4" -c:v libx264 -c:a aac -f flv "<your-secondary-ingest-url>"
  

  Look for lines like RTMP handshake or Connection failed to pinpoint where the process stalls.
• Check AMS Ingest Settings: In the Azure Portal, confirm the Secondary ingest endpoint is enabled, and there are no active restrictions (like IP filters) blocking your push source.

If you still run into issues, check the AMS Portal’s Ingest Logs under your streaming endpoint—they’ll show detailed errors for failed ingest attempts.

内容的提问来源于stack exchange，提问作者Lin ChiMing