Achtung: Die libarys von ffmpeg hießen schon immer libav. Dass sich dann der Fork von ffmpeg ebenfalls libav nannte war, wie einige ander Benennungen im Projekt sehr unglücklich.
Wenn gstreamer also von libav redet dann meinen sie die library vom ffmpeg. Das Backend hießt auch schon länger so als es den Fork unter dem Namen gibt. Heute ist es Wurst ob du dem gstreamer die orginal libavs aus dem ffmpeg oder die aus dem libavprojekt gibst ist dem reichlich Wurst. – Machen ja schließlich das gleiche. Er nutzt halt die, die da ist.
Zur Funktionalität von gstreamer:
So ein Video abspielen (oder konvertieren oder übers Netzwerk Streamen) ist ein relativ komplizierter Prozess, der aus vielen Einzelschritten besteht, die dir üblicherweise das Betriebssystem bereitstellt.
Hier mal ein dummes Beispiel:
https://upload.wikimedia.org/wikipedia/ ... peline.svg
Wenn du also einen Videoplayer baust musst zuerst die Datei aufmachen und entsprechend wissen wie das geht. (Du musst das nicht alle Dateisystemoperationen selber machen aber du musst wenigstens wissen wie sowohl unter Linux wie auch unter Windows, iOS... dazu anweist das für dich zu machen.)
Dann willst du da den Audio und den Videostream raus holen. => Du musst wissen wie man mkv, avi, mp4 etc. öffnet.
Dann willst du beides dekomprimieren. Auch das machen die Videoplayer nicht selbst: Wenn da AV1 komprimiert ist, nimmt er eventuell die libdav1d, wenn da AAC drin ist benutzt er die libfdk für h.264 eventuell direkt nvdec der Nvidia-Grafikkarte... Aber er muss dann wenigstens wissen, wie man libdav1d libfdk usw. nutzt.
Dann muss er das Audio wiedergeben. Dazu muss er aber wissen wie man pulseaudio und alsa und das Windows equivalent nutzt...
Du merkst: Das wird schnell unübersichtlich.
Apple machte da den ersten Ansatz der Vereinheitlichung mit QuickTime Windows zog nach Direct Media (Heute Windows Media SDK): Statt sich je nach bedarf mit diversen Einzelkomponenten auseinanderzusetzen sagte man einheitlich: Ich will XY decodieren. Kümmere dich mal darum den richtigen Codec zu nutzen. Leider war das insbesondere unter Windows in den 00ern eine ziemliche Totalkatastrophe. Windows selbst brachte kaum libraries mit und so nutzten die APIs es häufig fehlerhafte von Drittanbietern. VLC, mplayer und ffmpeg giengen dazu über alles möglichst selbst (und besser) zu machen. Schnell wurde klar dass es attraktiv ist, diese besser funktionierenden Funktionen auch für andere Programme zur Verfügung zu stellen um eine Alternative zur kaputten Windows API zu haben. (Die auch noch nur unter Windows verfügbar war) Später kamen KDE und GNOME ihre eigenen universellen Schnittstellen gstreamer und Phonon dazu. Vor allem mussten aber auch die Riesenprojekte einsehen, dass sie doch nicht alles selber neu erfinden können.
Und so lernte der VLC Player doch den ffmpeg zu nutzen, wenn er irgend etwas nicht aber der ffmpeg gut decodiern konnte. Und der ffmpeg den gstreamer und der gstreamer ffmpeg....
Und so nutzen die meisten Programme zwar eine universelle Schnittstelle bekommen aber über diesen Umweg die Funktionalität der anderen mit und so kannst du oft über 5 verschiedene Wege an der libfdk landen.– Viele Programme lassen dir die Wahl welchen du gehst bzw. ob du den überhaupt installieren willst. Zum decodieren von avis nutzt aber jede Schnittstelle wirklich ihre eigene Funktionalität.
Wenn du also fragst, ob das eine Alternative oder eine Ergänzung ist, lautet die Antwort sowohl als auch: Haben beide Schnittstellen die Funktionalität selbst implementiert ist es eine Alternative. Kann es nur eine ergänzen sie sich.