אפשרות ה-HTTP proxy של FFmpeg קודמת לקלט שלה

העבר את http_proxy כאפשרות פרוטוקול קלט ושמור על ארגומנטים נפרדים של אפשרות וערך כאשר אפליקציית Java מפעילה את FFmpeg.

עבור קלט FFmpeg שמעובד על ידי פרוטוקול ה-HTTP שלו, הצב את אפשרות ה-proxy לפני אותו קלט:

ffmpeg -http_proxy http://proxy.example:8080 \
  -i 'https://media.example/input.mp4' \
  -c copy output.mp4

‎-http_proxy בוחר את המתווך עבור חיבור ה-HTTP של הקלט; נקודת קצה מתוך רשימת ה-proxy של HTTP היא מועמדת לנתיב מדיה ציבורי. ‎-i עדיין מציין את משאב המדיה. אפשרות copy נוגעת לזרמי הפלט ואינה מגדירה את נתיב הרשת.

גם ב-Java יש לשמור את האפשרות ואת ה-URL כארגומנטים נפרדים של התהליך:

var command = new ProcessBuilder(
    "ffmpeg",
    "-http_proxy", "http://proxy.example:8080",
    "-i", inputUrl,
    "-c", "copy", outputPath
);

מעטפת שחושפת ארגומנטים נוספים זקוקה לאותה הבחנה בין שני טוקנים. מחרוזת אחת שמכילה גם את ‎-http_proxy וגם את ערכו אינה צמד האפשרות והערך ש-FFmpeg מצפה לו.

מירכאות שמעטפת משתמשת בהן כדי לקבץ URL לא אמורות להפוך לתווים מילוליים ברשימת הארגומנטים של ProcessBuilder.

אפשרות ה-HTTP proxy אינה הגדרת SOCKS כללית, והיא גם אינה מגדירה קלט RTSP/UDP לא קשור. בדוק את פרוטוקול ה-FFmpeg שנבחר ואת יכולות הבנייה כאשר זרם משתמש בתעבורה אחרת.

מאמרים קשורים