roki100 hat geschrieben: ↑Sa 02 Mai, 2020 14:06
Die Riesensammlung z.B. für bash, wäre all das, was auch Du als Unix-Werkzeuge bereits genannt hast...
die stehen dir ja auch in fast jeder anderen programmiersprache immer noch zur verfügung, wo es sinn macht.
ich hab zum beipiel die letzten paar wochen wieder damit zugebracht ein tool zu basteln, um die DASH/HLS aufbereitung von video files und befriedigenderes ein bisserl praktischer abzuwickeln und ein paar wichtige features (SRT-upstreams, VP9 und AV1 support, r128-loudness korrektur) einzubeziehen, die mir in diesem zusammenhang in den meisten bekannten lösungen fehlen.
letztlich ist das ganze in diesem fall aber tatsächlich nur ein ziemlich aufwendiger wrapper um das ffmpeg command line tool geblieben. das hat damit zu tun, dass einerseits jene libraries auf denen ffmpeg basiert, derart problematisch zu benutzen sind bzw. so unglaublich schlecht dokumentiert sind, dass es wirklich keinen spass macht, sich damit herumzuärgern, und anderseits gstreramer, dass zwar ohnehin den größten teil der ffmpeg funktionalität in deutlich schöner handhabbarer weise bereitstellt, genau in jenen punkten, die in meinem fall besonders wichtig waren (CMAF support und dash-sink), leider augenblicklich noch immer bekannte schwächen aufweist, wo ich sehr viel zeit darauf verwenden hätte müssen, komplizierten low-level code zu debuggen, bevor das tatsächlich brauchbar funktioniert hätte.
stellt sich also die frage, ob ich das nicht tatsächlich auch einfach mit bash-scripts od. python abwickeln hätte können, so wie du das empfiehlst?
in genau dieser weise hab ich das die letzten jahre über ohnehin ständig für denen eigenen hausgebrauch gemacht. zuerst mit ganz einfachen shell-scripts, die halt nur die einfachsten abläufe bzw. kommandoaufrufsequenzen quasi als batch job festgehalten und einfacher wiederholbar machen, und später dann mit immer weiter ausufernden python scripts, die das ganze bereits deutlich schöner und nachvollziehbarer zu lösen versuchten. aber auch diese scripts, von denen sich im laufe der zeit umengen angesammelt haben, waren irgendwann keine lösung mehr. obwohl sie natürlich den vorzug haben, dass man sie sehr schnell abändern und korrigieren kann, ist es ab einer gewissen größe einfach nicht mehr möglich, die enthaltenen anweisungen auf den ersten blick zu erfassen, nachzuvollziehen und ggf. zu korrigieren, statt dessen schleichen sich immer mehr probleme ein, die erst bei der ausführung als runtime-error in erscheinung treten.
so hab ich also eine ganze menge an zeit darauf verschwendet, einiges von den erfahrungen, die sich im laufe der zeit rund um diese aufgabe bei mir angesammelt haben, zu einem neuen werkzeug zu verdichten. das ist zwar momentan wirklich nur ein ganz primitiver wrapper um das ffmpeg CLI-tool [wobei ich insgeheim schon hoffe, dass ich irgendwann zeit finde, das ganze mit gstreamer noch ein bisserl sauberer umzusetzten, was natürlich intern schon jetzt vorgesehen ist], aber in der umsetztung benutzt es doch möglichkeiten, die mit shell-scripts od. auch python kaum befriedigend einzulösen wären.
die nötige konfiguration für die DASH/HLS ausgabe wird bspw. mittels
serde aus einer YAML od. Json konfigurationsdatei eingelesen und in eine streng typisierte interne repräsentation des setups übersetzt. das hat unter anderem den vorzug, dass man aus der definition der betreffenden datenstruktur im code auch gleich völlig automatisiert ein json-schema ableiten und exportieren kann, an hand dessen man im editor beim eintippen der konfigurationsangaben dann syntax-highliting, eingabevorschläge und dokumentation der eingabefeolder eingeblendet bekommt. man kann damit aber auch eine automatische validierung von konfigurationsanweisungen beim einsatz des tools auf serverless platformen wie
OpenFaaS umsetzen, oder webformulare für benutzerinterface automatisch daraus generieren usw.
letztendlich wird in der gegenwärtiger form daraus dann aber trotzdem nur ein ganz simpler ffmpeg-aufruf generiert, der allerdings in der praxis meist in einem normalen terminal-fenster keinen platz mehr findet und gespickt ist, mit lauter kleinen feinheiten und notwendigen zaubertricks, über die jeder von uns lange rätseln muss, wenn er derartiges selber hinzubekommen versucht (ganz konkret müssen ja die unzähligen konvertierungen in diesem fall alle mit "-map" anweisungen voneinader getrennt werden und jede transcoding- und filter-option mit expliziten stream-angaben versehen werden etc.).
wie gesagt, prinzipiell geht so etwas schon auch mit shell-scripts, aber ich hab im laufe der zeit irgendwann einfach gelernt, warum man es in der praxis doch besser mit anderer mitteln abwickelt, wenn etwas einigermaßen zufriedenstellendes dabei herauskommen soll.