FFmpeg ve GStreamer: Nerede Hangisini Kullanmalı, Ne Zaman Birlikte Çalıştırmalı?

Özet

• FFmpeg: ffmpeg / ffprobe CLI ve libav* kütüphaneleri — format dönüşümü, transcode, filtreleme, hızlı prototipleme
• GStreamer: Element–pad–pipeline mimarisi — 7/24 canlı akış, düşük gecikme, donanım hızlandırma, uygulama içi entegrasyon
• İlişki: Aynı problemde çoğu zaman alternatif; aynı tesisatta sıkça tamamlayıcı (gst-libav ile doğrudan hibrit)
• Amaç: FFmpeg ve GStreamer’ı yarıştırmak değil; hangi problemde hangisinin, hangi durumda ikisinin birlikte doğru seçim olduğunu göstermek
• Broadcast: ST 2110 ana yol vendor SDK iken; FFmpeg/GStreamer gateway, OTT köprüsü, monitoring ve transcoder katmanında yaygındır
• Karar: Dosya/offline ve CLI → FFmpeg; sürekli canlı pipeline ve gömülü servis → GStreamer
• Operasyon modeli: FFmpeg → process odaklı iş akışları (CLI, worker fleet, supervisor restart); GStreamer → süreç içi pipeline orkestrasyonu (state machine, bus, dinamik pad’ler)

Not: Bu makale, Go ile edge video processing yazısındaki kısa FFmpeg vs GStreamer bölümünü genişletir. Broadcast codec’ler, SRT gateway, ST 2110 kampüs, NMOS kontrol düzlemi ve HLS proxy (Go) ile birlikte okunması önerilir.

1. Giriş: İkisi de “video programı” değil, çerçeve

Canlı yayın, güvenlik kamerası, VOD platformu veya IP yayın kampüsünde sürekli şu soru gelir: “Bunu FFmpeg ile mi, GStreamer ile mi yapacağız?”

İkisi de multimedya işleme çerçevesidir: ham veya sıkıştırılmış veriyi okur, codec’lerden geçirir, filtreler, başka bir formata veya ağ protokolüne yazar. İkisi de codec kütüphanesi değildir — H.264, AAC, AV1 gibi codec’leri (çoğunlukla harici kütüphaneler üzerinden) kullanır.

Fark, nasıl düşündürdükleri ve nerede güçlü olduklarıdır:

Bu yazıda “hangisi daha iyi?” yerine nerede FFmpeg, nerede GStreamer, nerede ikisi birlikte? sorusuna odaklanıyoruz.

1.1 Sürüm kapsamı

Örnekler ve API isimleri FFmpeg 7.x / 8.x ile GStreamer 1.x (1.24+ / 1.26+ tipik güncel sürümler; bazı LTS distro’larda FFmpeg 6.x ve GStreamer 1.20+ hâlâ görülebilir) için yazılmıştır. Özellikler build’e bağlıdır:

Kurulumda ffmpeg -version ve gst-launch-1.0 --version ile somut sürümü doğrulayın; gst-inspect-1.0 ile element varlığını kontrol edin.

2. Mimari: Filter graph vs pipeline

2.1 FFmpeg — libav ve filter graph

FFmpeg temel olarak şu kütüphaneler etrafında döner:

• libavutil — ortak yardımcılar, zaman, bellek, piksel formatları
• libavformat — container (MP4, TS, MKV), protokol (file, RTSP, UDP)
• libavcodec — encode/decode
• libavfilter — ölçekleme, deinterlace, overlay, renk dönüşümü
• libswscale / libswresample — piksel ve ses örnekleme dönüşümü
• libavdevice (isteğe bağlı) — V4L2, DirectShow gibi capture cihazları

ffmpeg komutu bu katmanları bir filter graph ve mux/demux zinciri olarak birleştirir. Veri genelde frame veya packet olarak elementler arasında akar. Dosya tabanlı girdilerde -re, okuma hızını kısarak gerçek zamanlı ingest’e yaklaştırır (diskten canlı akış simülasyonu için faydalıdır). Girdiyi “native realtime” yapmaz; RTSP veya UDP gibi gerçek canlı kaynaklarda -re genelde gereksizdir, hatta zararlı olabilir.

2.2 GStreamer — element, pad, caps

GStreamer’da her iş bir elementtir: rtspsrc, x264enc, hlssink2, filesink. Elementler pad ile bağlanır; pad’ler üzerinden geçen verinin tipi caps (capabilities) ile müzakere edilir: çözünürlük, pixel format, codec, örnekleme hızı.

Pipeline bir durum makinesi ile yönetilir: NULL → READY → PAUSED → PLAYING. Hata, EOS ve uyarılar bus üzerinden uygulamaya iletilir.

2.3 Ortak zemin

Her ikisi de şunları yapar:

• Demux / mux
• Encode / decode (çoğu codec paylaşımlı veya benzer backend)
• Ağ protokolleri ve paketleme (RTSP, UDP, SRT, HLS, DASH, RTMP — kuruluma bağlı)
• Donanım hızlandırma (NVENC, VAAPI, Quick Sync — plugin/build’e bağlı)

GStreamer içinde FFmpeg: gst-libav plugin paketi, FFmpeg’in decoder/encoder’larını GStreamer elementleri olarak sunar (avdec_h264, avenc_aac). Bu, “ya biri ya öteki” değil doğrudan hibrit anlamına gelir.

3. FFmpeg derinlemesine

3.1 CLI: hızlı araç, üretim standardı

Çoğu ekip FFmpeg’i önce komut satırı aracı olarak tanır:

1
2
3
4
5

# RTSP → H.264 MP4 (TCP taşıma; RTSP kopmasında genelde supervisor yeniden başlatma)
ffmpeg -rtsp_transport tcp -i rtsp://kamera:554/stream1 \
  -c:v libx264 -preset veryfast -crf 23 \
  -c:a aac -b:a 128k \
  -movflags +faststart output.mp4

1
2
3

# Canlı UDP multicast ingest → SRT çıkış (örnek gateway)
ffmpeg -i udp://239.1.1.1:5000?localaddr=192.168.10.5 \
  -c copy -f mpegts "srt://hedef:9000?mode=caller"

1
2

# Metadata ve akış yapısı
ffprobe -v quiet -print_format json -show_streams input.ts

Güçlü yanlar:

• Tek satırda uçtan uca iş
• Evrensel format desteği
• Script, CI, cron, operatör el kitabı için ideal
• Dokümantasyon ve Stack Overflow birikimi çok yüksek

Zayıf yanlar (canlı servis bağlamında):

• Her ffmpeg çağrısı ayrı process — yeniden başlatma, bellek, pipe I/O overhead
• Uygulama içi ince kontrol için C API veya exec gerekir; hata yönetimi process seviyesinde
• Çok uzun süreli pipeline’da dinamik topoloji değişimi (ekran ekle/çıkar) CLI ile zor

3.2 Kütüphane kullanımı

libavformat + libavcodec ile process overhead olmadan entegre edilir; OBS, VLC, birçok commercial transcoder ve cloud VOD worker bu yolu kullanır. Go tarafında genelde CGO ile libav veya exec.Command("ffmpeg", ...) tercih edilir — edge video processing makalesinde ikinci yol anlatılır.

3.3 Tipik FFmpeg senaryoları

4. GStreamer derinlemesine

4.1 Pipeline dili: gst-launch

CLI karşılığı gst-launch-1.0dır; syntax boru (!) ile element zinciri kurar:

1
2
3
4
5
6

# RTSP → decode → scale → x264 → MPEG-TS → UDP
gst-launch-1.0 -e rtspsrc location=rtsp://kamera:554/stream1 latency=100 ! \
  rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! \
  videoscale ! video/x-raw,width=1280,height=720 ! \
  x264enc tune=zerolatency bitrate=4000 ! h264parse ! \
  mpegtsmux ! udpsink host=239.1.1.2 port=5000 auto-multicast=true

-e (EOS’ta doğru kapanış) canlı sistemlerde dosya bütünlüğü için önemlidir.

4.2 Uygulama API’si

Gerçek ürünlerde pipeline kod içinde kurulur (C, Python gi, Rust gstreamer crate). Bus mesajlarıyla hata, state change ve EOS yönetilir; runtime’da element ekleme/çıkarma (decodebin, uridecodebin) mümkündür.

Güçlü yanlar:

• Sürekli akış için tasarlanmış buffer ve clock modeli
• Plugin ekosistemi: WebRTC, DeepStream, V4L2, ALSA, custom appsrc/appsink
• Donanım encoder’lara doğrudan element (nvh264enc, vaapih264enc)
• Tek process, düşük gecikme hedefi

Zayıf yanlar:

• Kurulum: distro paketleri, plugin seti, caps müzakere hataları
• Öğrenme: pad, caps, ghost pad, bin kavramları
• Dokümantasyon FFmpeg kadar “tek komut örneği” zengin değil; daha çok API ve plugin referansı

4.3 Tipik GStreamer senaryoları

5. Aynı iş, iki yol

Aşağıdaki örnekler kavramsal eşdeğerdir; üretimde bitrate, GOP, B-frame ve taşıma parametreleri proje gereksinimine göre ayarlanmalıdır.

5.1 Dosya → HLS (VOD)

FFmpeg:

1
2
3

ffmpeg -i kaynak.mov -c:v libx264 -preset medium -crf 22 -c:a aac -b:a 192k \
  -hls_time 6 -hls_playlist_type vod -hls_segment_filename 'seg_%03d.ts' \
  -f hls master.m3u8

GStreamer (video + ses dalları):

1
2
3
4
5

gst-launch-1.0 filesrc location=kaynak.mov ! decodebin name=d \
  d. ! queue ! videoconvert ! x264enc ! h264parse ! mux. \
  d. ! queue ! audioconvert ! audioresample ! voaacenc ! aacparse ! mux. \
  mpegtsmux name=mux ! hlssink2 playlist-location=master.m3u8 \
  location=seg_%05d.ts target-duration=6

Not: decodebin dinamik pad üretir; yukarıdaki d. ! sözdizimi video/ses pad’lerini ayrı dallara yönlendirir. hlssink2 gst-plugins-bad gerektirir; alternatif olarak splitmuxsink kullanılabilir. Örneklerde sık geçen voaacenc tutorial uyumluluğu içindir; birçok kurulumda kalite ve destek için fdkaacenc (GPL) veya avenc_aac (gst-libav) tercih edilir.

Canlı HLS (event stream): VOD’dan farklı olarak segment silme ve playlist güncelleme gerekir.

1
2
3
4

# FFmpeg — canlı event (örnek bayraklar)
ffmpeg -i rtsp://kaynak/stream -c copy -f hls -hls_time 4 \
  -hls_flags delete_segments+append_list+omit_endlist+program_date_time \
  -hls_segment_filename 'live_%03d.ts' index.m3u8

Not: -c copy yalnızca kaynak zaten H.264 + AAC (veya HLS segmenter’ınızın MPEG-TS içinde kabul ettiği başka bir codec çifti) ise geçerlidir. HEVC, MJPEG veya uyumsuz ses için transcode gerekir — örn. -c:v libx264 -preset veryfast -c:a aac -b:a 128k.

GStreamer tarafında splitmuxsink veya hlssink2 ile benzer model; uçtan uca proxy için HLS stream proxy (Go) yazısına bakın.

DASH (FFmpeg — kısa):

1
2

ffmpeg -i kaynak.mov -c:v libx264 -c:a aac \
  -f dash -seg_duration 6 -use_template 1 -use_timeline 1 manifest.mpd

DASH (GStreamer — dashsink, gst-plugins-bad):

dashsink segment ve MPD üretimini kendi içinde yapar; önüne mp4mux koymak yanlıştır. Video ve ses doğrudan dashsink pad’lerine bağlanır:

1
2
3
4

gst-launch-1.0 filesrc location=kaynak.mov ! decodebin name=d \
  d. ! queue ! videoconvert ! x264enc ! h264parse ! ds.video_0 \
  d. ! queue ! audioconvert ! audioresample ! voaacenc ! aacparse ! ds.audio_0 \
  dashsink name=ds mpd-location=manifest.mpd

Not: dashsink request pad şablonları genelde video_%u, audio_%u, subtitle_%u biçimindedir; bu yüzden örnekte video_0 ve audio_0 kullanıldı. Sürüm/paket farkları için gst-inspect-1.0 dashsink ile doğrulayın.

5.2 RTSP kamera → ham frame (analiz için)

Aşağıdaki RTSP örnekleri H.264 RTP varsayar (rtph264depay). HEVC için: rtph265depay ! h265parse ! avdec_h265 (veya donanım decode elementi). MPEG-2 için rtpmp2tdepay / uygun parser kullanın.

FFmpeg (stdout pipe — edge makalesindeki model):

1
2

ffmpeg -rtsp_transport tcp -i rtsp://kamera/stream \
  -f rawvideo -pix_fmt rgb24 -s 640x480 pipe:1

GStreamer:

1
2
3

gst-launch-1.0 rtspsrc location=rtsp://kamera/stream ! rtph264depay ! h264parse ! \
  avdec_h264 ! videoconvert ! video/x-raw,format=RGB,width=640,height=480 ! \
  fdsink fd=1

FFmpeg burada operasyonel basitlik kazanır; GStreamer aynı process içinde appsink ile frame almak isteyen uygulamalar için daha doğal olur.

5.3 Copy (re-mux) — CPU tasarrufu

Codec’e dokunmadan container veya protokol değiştirmek:

1
2
3
4
5
6
7
8

# FFmpeg
ffmpeg -i udp://239.1.1.1:5000 -c copy -f mpegts output.ts

# GStreamer (video + ses elementary — demux sonrası parser)
gst-launch-1.0 udpsrc uri=udp://239.1.1.1:5000 ! tsdemux name=d \
  d. ! queue ! h264parse ! mux. \
  d. ! queue ! aacparse ! mux. \
  mpegtsmux name=mux ! filesink location=output.ts

Not: tsdemux dinamik pad üretir. Örnek, TS içinde hem H.264 hem AAC elementary stream olduğunu varsayar; yalnızca video varsa ses dalını kaldırın. Üretimde parsebin veya programa özel pad bağlantısı da kullanılır. Gerçek pad adları akışa ve GStreamer sürümüne göre değişir (ör. d.video_0, d.audio_0); gst-launch-1.0 -v veya GST_DEBUG=2 ile doğrulayın.

FFmpeg tarafında -c copy bitstream’e dokunmadan paketleri aktarır. GStreamer örneği ise demux → mpegtsmux ile yeniden paketleme yapar. Her iki yaklaşım da transcode değil, ancak container metadata ve zamanlama (PSI, PCR, PAT/PMT) yeniden kodlama olmasa da değişebilir — byte-identical çıkış varsaymayın. Sıkı contribution zincirlerinde vendor-specific passthrough elementleri gerekebilir.

5.4 Ses pipeline (broadcast senkronu)

Video örnekleri kadar ses de mux, gecikme ve seviye açısından kritiktir. Tipik bileşenler:

Surround (5.1 kanal) → stereo downmix (FFmpeg):

1
2
3

ffmpeg -i surround_51.mov -map 0:v -c:v copy \
  -map 0:a -af "pan=stereo|FL=FL+0.707*FC+0.707*BL|FR=FR+0.707*FC+0.707*BR" \
  -c:a aac -b:a 192k out_stereo.mov

GStreamer (6 kanal → stereo → AAC):

GStreamer’da audiochannelmix diye standart bir element yoktur. Kanal sayısı düşürme audioconvert + caps ile yapılır:

1
2
3
4
5

gst-launch-1.0 filesrc location=surround_51.mov ! decodebin name=d \
  d. ! queue ! audioconvert ! audio/x-raw,channels=2 ! audioresample \
  ! voaacenc ! aacparse ! mux. \
  d. ! queue ! videoconvert ! x264enc ! h264parse ! mux. \
  mpegtsmux name=mux ! filesink location=out.ts

Not: Bu, basit kanal katlama içindir. Surround matrisi (5.1 → stereo ağırlıkları) için FFmpeg -af pan daha kontrollüdür; ileri seviye için LADSPA veya özel audiomixer/volume zincirleri gerekir.

Canlı RTSP’de ses kopması çoğu zaman yanlış pad bağlantısı veya caps müzakere hatasıdır; ffprobe ile ses stream index ve codec’ini doğrulayın.

6. Performans, gecikme ve süreklilik

6.1 Process vs in-process

Go ile edge video processing deneyiminde belirtildiği gibi, Go uygulamasından exec ffmpeg ile frame okumak pipe I/O ve process overhead getirir. Çoğu edge senaryosunda kabul edilebilir; saniyede yüzlerce tam çözünürlük frame ve sıkı CPU bütçesinde GStreamer veya doğrudan libav tercih edilir.

6.2 Donanım hızlandırma

• FFmpeg: -hwaccel, -c:v h264_nvenc, vaapi, qsv — komut satırında iyi belgelenmiş
• GStreamer: nvh264enc, vaapih264enc, platform plugin’leri — pipeline’a element olarak eklenir

Hangisinin daha hızlı olduğu sürücü, sürüm ve pipeline tasarımına bağlıdır; genel “GStreamer her zaman daha hızlı” doğru değildir. Aynı workload’da throughput/latency 2–10x oynayabilir; sabit “kazanan” ilan etmek yerine kendi girdinizle ölçün. Başlangıç referansları: GStreamer benchmarking tasarım notları, FFmpeg sürüm notları ve donanım encoder kıyasları.

6.2.1 Low-latency checklist

Düşük gecikme yalnızca “hızlı encoder” seçimi değildir; ingest, queue, GOP, mux ve player tamponu birlikte ayarlanır.

6.3 Güvenilirlik ve yeniden bağlanma

FFmpeg

GStreamer

Örnek rtspsrc (daha dayanıklı ingest):

1
2

gst-launch-1.0 rtspsrc location=rtsp://kamera/stream latency=200 \
  tcp-timeout=5000000 drop-on-latency=true ! rtph264depay ! ...

Üretimde reconnect mantığı genelde uygulama kodunda (bus callback) veya ayrı supervisor process ile yapılır; FFmpeg’deki tek satırlık -reconnect bayraklarına birebir CLI karşılığı yoktur — bu yüzden 6.3’te iki taraf farklı operasyon modelleri sunar, biri diğerinden “daha az özellikli” değildir.

• Encoder stall → her iki tarafta watchdog
• Bellek sızıntısı → uzun soak test; GStreamer tek process’te profil daha net

6.4 Ölçekleme (throughput)

Yüksek throughput VOD’da FFmpeg process ordusu yaygın; tek host’ta çok senkron çıkış için GStreamer tee + clock modeli daha doğal.

7. Broadcast ve IP yayın bağlamı

7.1 ST 2110 ve profesyonel IP

ST 2110 televizyon kampüsü mimarisinde ana medya yolu RTP multicast + PTP ve genelde vendor SDK (ör. NVIDIA Rivermax, özel SMPTE stack) ile kurulur. FFmpeg ve GStreamer ST 2110 yığınının yerine geçmez; şu rollerde öne çıkar:

• Gateway: IP yayın → OTT (HLS/DASH), SRT contribution
• Monitoring: Akış kaydı, thumbnail, waveform
• Lab / test: Akış üretimi, loop, format dönüşümü
• Küçük istasyon / ikinci hat: Tam özellikli IP ürünü olmayan ortamlarda yazılım transcoder

7.2 Taşıma protokolleri ve OTT paketleme

RTMP: Hâlâ geniş kullanımda (OBS hedef sunucuları, sosyal platform ingest). FFmpeg libavformat üzerinden RTMP yazar; eski librtmp bağımlılığı artık tipik değildir. GStreamer tarafında flvmux + rtmpsink (veya yeni rtmp2sink) ile push yapılır; TLS için rtmps URL ve uygun plugin gerekir.

DASH: HLS kadar detaylı anlatılmasa da OTT/VOD’da standarttır; FFmpeg -f dash ile MPD üretir; GStreamer’da dashsink (bad plugin) benzer işi pipeline içinde yapar.

CMAF / fMP4: 2026 OTT’de HLS ve DASH ile birlikte sık kullanılır; FFmpeg’de parçalı MP4 (-movflags frag_keyframe+empty_moov), GStreamer’da cmafsink (build’e bağlı) aynı fikre yakın.

RIST / NDI: Contribution tarafında SRT yanında RIST (UDP-friendly, açık) ve NDI (LAN, vendor ekosistem) görülür; ikisi de bu çerçevelerin çekirdeğinde değil, genelde vendor SDK veya özel plugin ile entegre edilir.

Örnek zincir:

1
2

Kamera (RTSP) → FFmpeg/GStreamer (transcode veya copy) → SRT → Cloud / playout
OBS (RTMP) → CDN ingest → transcode farm (FFmpeg) → HLS/DASH origin

Medya sunucu katmanı: FFmpeg/GStreamer transcode/encode yapar; MediaMTX, nginx-rtmp protokol terminasyonu ve yeniden yayın sağlar (transcode değil). Örnek:

1

GStreamer (encode) --RTSP publish--> MediaMTX --HLS--> CDN / player

Broadcast codec’ler bağlamında DNxHD, XDCAM, ProRes gibi formatlar genelde profesyonel ürün ve lisans gerektirir; FFmpeg/GStreamer yaygın endüstri codec’leri (H.264, HEVC, AV1) ve genel container’larda en güçlüdür. Burada “destek var” demek “patent/lisans yükümlülüğü yok” anlamına gelmez; H.264/HEVC dağıtımı ayrıca ürün ve ülke bağlamında değerlendirilmelidir.

7.3 Ne zaman vendor SDK?

Yüksek bitrate, kernel bypass, nanosaniye düzeyinde PTP uyumu ve SMPTE uyumluluk sertifikasyonu gerekiyorsa yazılım çerçevesi değil, broadcast SDK tercih edilir. FFmpeg/GStreamer bu dünyanın kenar ve türev katmanıdır.

7.4 AV1 (2026 pratik durumu)

AV1 artık yalnızca “gelecek codec” değil; OTT arşiv ve VOD üretimde FFmpeg ve GStreamer ile kullanılıyor; büyük ölçekli veya deneysel canlı ingest de var ancak H.264/HEVC yanında özellikle düşük gecikmeli contribution’da niş kalıyor. Temel yazılar: AV1 nedir?, uygulama AV1 converter, bulut AV1 ve AWS.

FFmpeg örnek (SVT-AV1, VOD):

1

ffmpeg -i kaynak.mov -c:v libsvtav1 -preset 6 -crf 30 -c:a copy out.mkv

GStreamer örnek (SVT-AV1):

1
2
3
4

gst-launch-1.0 filesrc location=kaynak.mov ! decodebin name=d \
  d. ! queue ! videoconvert ! svtav1enc ! av1parse ! mux. \
  d. ! queue ! audioconvert ! voaacenc ! aacparse ! mux. \
  matroskamux name=mux ! filesink location=out.mkv

Broadcast contribution’da AV1 henüz H.264/HEVC kadar evrensel değil; ancak OTT origin, arşiv ve bandwidth maliyeti düşürme için FFmpeg/GStreamer yığınlarında yerleşik seçenek. AV1 converter makalesindeki libsvtav1 parametreleri aynı mantıkla CLI ve pipeline’a taşınır.

7.5 Altyazı ve kapalı altyazı (kısa)

Broadcast ve OTT’de CEA-608/708 (ATSC/kapalı altyazı) ile WebVTT (HLS/DASH yan veri) sık istenir:

• FFmpeg: SubRip .srt / mov_text mux, subtitles filter ile burn-in; ayrı subtitle track için -map 0:s
• GStreamer: subtitleoverlay, closedcaption (region/build’e bağlı), WebVTT için hlsdemux yan manifest veya ayrı dosya

Tam iş akışı genelde playout/MAM katmanında; FFmpeg/GStreamer dönüştürme ve paketleme aşamasında altyazı track’ini korur veya gömer. CEA-608/708 her zaman normal subtitle stream olarak gelmez; MPEG-TS, H.264 SEI, MXF veya side-data biçimine göre map/bitstream filter/container desteği ayrıca test edilmelidir.

8. Go ve uygulama entegrasyonu

8.1 FFmpeg + Go

Yaygın pattern:

1
2
3
4
5
6
7
8

cmd := exec.CommandContext(ctx, "ffmpeg",
    "-rtsp_transport", "tcp",
    "-i", rtspURL,
    "-f", "rawvideo", "-pix_fmt", "rgb24",
    "pipe:1",
)
stdout, _ := cmd.StdoutPipe()
// frame okuma döngüsü

Artıları: hızlı geliştirme, FFmpeg güncellemesi bağımsız. Eksileri: process yönetimi, stderr log, graceful shutdown.

8.2 GStreamer + Go (ve Python)

• CGO / go-gst: Pipeline uygulama içinde; daha az process overhead
• Python (gi.repository.Gst): Prototip ve ML entegrasyonu için yaygın; bus ve state machine aynı model
• Ayrı GStreamer servisi + gRPC/SHM: Dil ayrımı, GPU node

Edge projelerinde çoğu ekip önce FFmpeg CLI ile doğrular, ihtiyaç netleşince GStreamer veya libav’e geçer — bu makaledeki edge processing kararı da bu çizgidedir.

9. Karar ağacı

Pratik özet:

9.1 Hızlı seçim reçetesi

10. Lisans, platform ve operasyon

10.1 Lisans (ticari ürün için kritik)

Broadcast ürününde “FFmpeg kullanıyoruz” demek yetmez: hangi build, hangi codec’ler, statik mi dinamik mi link sorulur. GStreamer’da da gst-plugins-ugly içindeki patentli/GPL bileşenler ayrı paketlenir.

Ses codec notu: Örneklerde taşınabilirlik için aac / voaacenc kullanıldı; broadcast loudness ve kalite için libfdk-aac (FFmpeg tarafında non-free build/lisans etkisi) veya GStreamer fdkaacenc / avenc_aac gerekebilir — lisansı §10.1 ile birlikte planlayın.

10.2 Platform: Linux, Windows, macOS

Cross-platform ekiplerde FFmpeg script ve ops tarafında evrensel; GStreamer 7/24 canlı servis için çoğu zaman Linux hedeflenir.

10.3 Container ve debug

• Docker: jrottenberg/ffmpeg gibi imajlar operasyonel transcode için yaygın; GStreamer imajları genelde gst-*-plugins-* dev paketleriyle özel Dockerfile ister.
• GStreamer debug: GST_DEBUG=3, gst-inspect-1.0 rtspsrc, gst-launch-1.0 -v — caps ve pad hatalarında ilk araçlar.
• Pipeline görselleştirme: GST_DEBUG_DUMP_DOT_DIR=./dots — çalışma anında .dot grafikleri (Graphviz ile görüntülenir); profil için gst-shark (kuruluysa) latency/throughput ölçümü.
• FFmpeg teşhis: ffprobe -show_streams, -loglevel debug.

10.4 Kurulum doğrulama komutları

Yazıdaki her örneği çalıştırmadan önce build’in gerçekten ilgili protokol, encoder ve GStreamer elementini içerdiğini kontrol edin:

1
2
3
4

ffmpeg -hide_banner -version
ffmpeg -hide_banner -protocols | grep -E 'srt|rtmp|rtsp|http'
ffmpeg -hide_banner -encoders | grep -E 'libx264|libsvtav1|nvenc|qsv|vaapi'
ffprobe -hide_banner -show_streams input.ts

1
2
3
4
5

gst-launch-1.0 --version
gst-inspect-1.0 rtspsrc
gst-inspect-1.0 hlssink2
gst-inspect-1.0 dashsink
gst-inspect-1.0 svtav1enc

Bu kontroller özellikle container image, CI runner ve embedded cihazlarda önemlidir; aynı komut laptop’ta çalışırken production imajında plugin eksik olabilir.

10.5 Kısa sorun giderme

11. Alternatif araçlar (kısa)

FFmpeg ve GStreamer dışında aynı alanda:

• libVLC — oynatma ve basit stream; embed player
• MediaMTX / nginx-rtmp — protokol sunucusu; yukarıdaki zincirde terminasyon katmanı
• OBS — dahili olarak FFmpeg/libav bileşenleri kullanır; ancak kendi uygulama yığınına (libobs, plugin modeli) sahiptir; ffmpeg CLI etrafında ince bir sarıcı değildir
• Go-native (gortsplib, pure go codec) — bağımlılık azaltma; format/codec kapsamı sınırlı

Edge processing makalesinde Go-native alternatifler tartışılır. Format genişliği ve operasyon araçları açısından OTT, CDN ve VOD/transcode tarafında FFmpeg hâlâ güçlü. Gömülü cihazlar, video analitik ve GPU odaklı canlı pipeline’larda ise GStreamer (ve tamamen GStreamer tabanlı NVIDIA DeepStream ekosistemi gibi yığınlar) en az onun kadar yaygındır — baskınlık alana göre değişir, evrensel bir “kazanan” yoktur.

12. Sonuç

FFmpeg ve GStreamer rakip ürünlerden çok farklı mimari tercihler sunar:

• FFmpeg = evrensel multimedya aracı ve kütüphanesi; hızlı, dokümante, her yerde
• GStreamer = modüler pipeline motoru; canlı, gömülü, dinamik graf

Çoğu kuruluşta ikisi de bulunur: FFmpeg arşiv ve operasyon scriptleri için, GStreamer (veya gst-libav hibriti) canlı ürünler için. Broadcast IT’de asıl ayrım ST 2110 çekirdeği vs yazılım gateway düzleminde geçer; bu çerçeveler ikinci planda değil, köprü ve operasyon katmanında kritiktir.

Doğru soru: “FFmpeg mi GStreamer mı?” değil, “Bu iş dosya mı akış mı, CLI yeter mi process şart mı, kampüs çekirdeği mi kenar mı?”

Kaynaklar

• FFmpeg Documentation
• GStreamer Documentation
• gst-libav
• İlgili yazılar: Go edge video, SRT + Go, HLS proxy (Go), Broadcast codec’ler, ST 2110 kampüs, NMOS, AV1, AV1 converter, AV1 ve AWS — klasör AV1andAWS, yayın URL’si /av1andaws/