x264 Streaming und Aufnahme

  • Ok, danke
    Wie sieht das jetzt aus wenn man nicht eine x264 Datei durch die Pipline von ffmpeg zum x264 von MeGui schickt, sondern eine avi mit UT Video, welche muss man da nehmen?

  • ffmpeg -i "input.mkv" -f yuv4mpegpipe - | x264-10bit - --demuxer y4m --qp 0 -o "output.264"

    Das hier ist ja eine YUV 4 MPEG Pipe, das war ja darauf ausgelegt das ich ein x264 Datei öffne.
    Was müsste ich machen wenn ich ein *avi mit UT Video öffne?
    Und hat das nichts mit dem was geöffnet zu tun, sondern wohin es weitergegeben wird?

    Einmal editiert, zuletzt von LigH (4. April 2017 um 14:12) aus folgendem Grund: QUOTE korrigiert

  • Bei ffmpeg folgt auf den Parameter "-i" der Name der zu öffnenden Datei (bei einer AVI mit Ut-Video als Inhalt also der Dateiname dieser AVI-Datei; dass da Ut-Video drin ist, kriegt ffmpeg schon alleine heraus); nach dem Parameter "-f" kommt das Ausgabeformat (wobei yuv4mpegpipe bedeutet: Unkomprimiertes YUV-Video mit einem "YUV4MPEG"-Header, in dem ein paar Eigenschaften des Videos drinstehen, wie Breite und Höhe). Als letzter Parameter für ffmpeg kommt der Name der Ausgabedatei, der hier "-" ist (das bedeutet: Standardausgabe-Handle, als Eingang der Pipe "|").

    Der Ausgang der Pipe wird dann mit x264-10bit verbunden, weil ffmpeg den x264 meist nicht mit 10 bit Präzision anbietet. Dem x264-10bit wird dann auch mitgeteilt, dass er aus der Pipe heraus (Eingabedateiname = "-") als Eingangsformat "YUV4MPEG" zu erwarten hat (--demuxer y4m).

    Der Name "YUV4MPEG" (genauer: YUV4MPEG2) dürfte ziemlich alt sein, es wurden damit wohl schon vor Jahrzehnten MPEG-1/2-Video-Encoder versorgt, die nur unkomprimiertes YUV-Video verarbeiten konnten, was aber ohne zusätzlichen Header keine Informationen darüber enthalten hätte, welche Art von YUV-Video drinsteckt (YUY2/UYVY oder YV12), ja noch nicht mal Breite und Höhe der Frames.

  • Code
    Video
    Frame rate                               : 50.000 FPS
    Bit depth                                : 8 bits


    Sind die Aufnahmen denn für Youtube gedacht? Dann würde ich eher mit 30 oder 60 fps capturen.
    Deine Aufnahmen sind 8 Bit. Bringt das denn viel, wenn du dann mit der 10bit Variante von x264 arbeitest?
    (Youtube wird sie dann ja wieder neu umrechnen)

    Ich hab jetzt aber gerade mal ffmpeg und Avisynth / MeGui verglichen, was die Geschwindigkeit angeht.
    ffmpeg: 195 fps
    MeGui: 90

    ffmpeg -i "input.mkv" -f yuv4mpegpipe - | x264-10bit - --demuxer y4m --qp 0 -o "output.264"


    Rein Interessehalber: verlierst du denn Performance, wenn du pipst?
    also reines ffmpeg gegenüber ffmpeg | x2648bit


    Bicubic tut es eigentlich recht gut. Manche empfehlen noch b= -0.5 und c=0.25 speziell fürs Downscalen. Weiß aber nicht, wie (ob?) man b und c bei ffmpeg einstellt.


    Also Parameter kann man setzen, ob sie auch was bewirken, bin ich überfragt.

    -vf scale=854x356:flags=bicubic+print_info:param0=-0.5:param1=0.25

    Dann gibt es noch den zscale Filter -> http://ffmpeg.org/ffmpeg-filters.html#zscale


    Gibt es eine Möglichkeit UT Video in ffmpeg zu sagen wie viele Threads er nutzen darf?

    Ja, kannst du durch den -threads (0=auto) Parameter tun, du musst aber beachten, wo in der Kommandozeile er steht.

    ffmpeg -threads 0 -i input.avi -threads 1 output.mp4

    Steht er vor dem -i Parameter, gilt er für die Inputdatei also den Decoder (also hier 0 für automatisch).
    Der zweite beschränkt die Anzahl der Encoderthreads auf 1 für die folgende Ausgabdatei.

  • Sind die Aufnahmen denn für Youtube gedacht? Dann würde ich eher mit 30 oder 60 fps capturen.


    Ja ist für Youtube.
    Youtube hat was doe Fps angeht zwei verschiedene Encoding Einstellungen.
    Einmal alles bis 30 Fps, das bekommt dann eine geringere Bitrate.
    Und dann noch von 41 - 60 Fps, hierbei wird dann das HFR Encoding freigeschaltet, was eine deutliche Steigerung der Bitrate zur Folge hat.

    Deine Aufnahmen sind 8 Bit. Bringt das denn viel, wenn du dann mit der 10bit Variante von x264 arbeitest?


    Das 10 Bit Encoding ist dann wieder wegen Youtube.
    Hier wird durch das Dithering von 10 Bit auf 8 Bit das Bending auf Youtube extrem reduziert.


    Rein Interessehalber: verlierst du denn Performance, wenn du pipst?
    also reines ffmpeg gegenüber ffmpeg | x2648bit


    Dadurch das der eigene Encoder von MeGui schneller ist, habe ich bei 8 Bit eine Performance Steigerung.
    Mit 10 Bit sieht es dann natürlich etwas anders aus.

  • Moin
    Ich bin es nochmal :D

    Ich hab jetzt noch mal etwas geschaut, und zwar geht es mir das ich schon beim neu codieren die Möglichkeit haben wollte die Video Frame genau zu schneiden.
    Hierfür hatte ich bei x264 die Parameter --Seek und --Frames gefunden.
    Das ist dann der Starframe und wie viele Frames encodiert werden soll, das wäre so auch kein Problem, nur etwa Mathe xD

    Was mir dann jetzt aber gerade aufgefallen ist, das er, wenn der Startframe nicht 0 ist, erstmal das Video durchläuft, was zwar mit 200+ Fps nicht langsam ist, aber bei einer Stapelverarbeitung bin 8+ Aufnahme doch zu erheblichen Problemen führen würde.

  • Klar, bei einem Strom von rohen Videoframes aus einer Pipe bleibt dem Zielprogramm keine andere Wahl, als die Frames zunächst zu lesen, die es überspringen soll. Das liefernde Programm schiebt sie ja in die Pipe hinein. Man müsste schon bereits bei ffmpeg den Bereich einschränken, damit es nur die Frames durch die Pipe schiebt, die x264 überhaupt encodieren soll (und x264 überspringt dann seinerseits keine, weil es ja schon die fertig geschnittene Auswahl erhält).

  • Ja irgendwie... hätte ich auch selber drauf kommen können xD
    Gibt es den auch bei ffmpeg eine Möglichkeit Frame genau zu schneiden (also ich meine jetzt, das ich nicht wie bei -ss einen Timestep angeben muss, sondern direkt den Frame) und würde es dann auch eine Möglichkeit geben zum Beispiel etwas weg zu schneiden?
    Also A -> B, C->D = eine Videodatei

  • Kommt drauf an.

    Wenn du zur Ausgabe sowieso komplett decodieren musst und anschließend von Grund auf neu encodierst, kannst du schneiden lassen, wo du willst. (Ob ffmpeg Abschnittslisten unterstützt, weiß ich aber nicht, ohne die Dokumentation zu lesen.)

    Versuchst du aber, das Material möglichst nicht neu zu codieren, sondern weitgehend unverändert zu kopieren (-codec:v copy), bist du an die GOP-Struktur gebunden (ansonsten bekommst du ab einem Schnitt, der nicht mit einem I-Frame beginnt, visuellen "Würfelhusten" beim Abspielen).

    Ich bin mir nicht sicher, wie genau man Positionen bei ffmpeg angeben kann. Möglicherweise nur auf die Sekunde. Oder vielleicht mit Millisekunden (aber evtl. nicht mit Framenummer). Das wissen andere aber besser...

  • Es geht darum eine Aufnahme von 8 Stunden in mehrere Videos zu teilen die dann zwischen 20 und 30 Minuten lang sind.
    Wo es dann von A->B | B->C und so weiter geht

    Einmal editiert, zuletzt von GelberDrache (6. April 2017 um 16:49)

  • Gibt es den auch bei ffmpeg eine Möglichkeit Frame genau zu schneiden (also ich meine jetzt, das ich nicht wie bei -ss einen Timestep angeben muss, sondern direkt den Frame) und würde es dann auch eine Möglichkeit geben zum Beispiel etwas weg zu schneiden?
    Also A -> B, C->D = eine Videodatei

    Es geht darum eine Aufnahme von 8 Stunden in mehrere Videos zu teilen die dann zwischen 20 und 30 Minuten lang sind.
    Wo es dann von A->B | B->C und so weiter geht


    Das sind unterschiedliche Wünsche.
    Fürs obere: https://superuser.com/questions/6818…eo-using-ffmpeg
    Fürs untere: entweder auch trim aber mit mehreren Ausageben. Oder halt einfach mehrfach ffmpeg benutzen, entweder wieder mit trim oder -ss/-to.

  • So da bin ich auch mal wieder.
    Läuft alles soweit schön und gut, aber eine kleine Sache ist da noch die mich stört.

    Ich nutze ein *.bat, mit dem Inhalt:

    Code
    @echo offset _ffmpeg_="C:\Users\Stefan\Desktop\ffmpeg-20170401-23ae3cc-win64-static\bin\ffmpeg.exe"set _input_=%1for /f "useback tokens=*" %%a in ('%_input_%') do set _input_=%%~a%_ffmpeg_% -ss 00:10:00 -i "%_input_%" -t 00:05:00 -f yuv4mpegpipe - | "C:\Users\Stefan\Desktop\Neuer Ordner (2)\tools\x264_10b\x264-10b_64.exe" - --demuxer y4m --preset veryfast --crf 18  --output "%_input_:~0,-4%_01.mkv"%_ffmpeg_% -ss 00:10:00 -i "%_input_%" -t 00:05:00 -acodec pcm_s16le -map 0:1 "%_input_:~0,-4%_01.wav"%_ffmpeg_% -ss 00:10:00 -i "%_input_%" -t 00:05:00 -acodec pcm_s16le -map 0:2 "%_input_:~0,-4%_02.wav"pause

    Schneiden und beim Video ist alles gut.
    Bei Audio kriege ich aber noch zwei komische Sachen.

    Die Audiodateien die ausgespuckt werden, sind in der länger und der Synchronität zum Video aber in Ordnung.
    Kann ich das einfach ignorieren oder muss da noch was geändert werden?

  • Möglicherweise fehlen in der MKV-Datei bestimmte Header zur umfassenden Beschreibung; wahrscheinlich arbeitet der MKV-Multiplexer nicht ganz korrekt, der die Dateien der Aufnahme ursprünglich erzeugt hatte. Sicherlich funktioniert trotzdem die Konvertierung, die du brauchst. Du kannst aber gern vergleichen, ob es ohne Warnungen durchläuft, wenn du die MKV-Datei gleich nach der Aufnahme nochmal durch mkvmerge neu multiplexen lässt. Aber ob das den doppelten Plattenplatz Wert ist?

  • Ja ist für Youtube.
    Youtube hat was doe Fps angeht zwei verschiedene Encoding Einstellungen.
    Einmal alles bis 30 Fps, das bekommt dann eine geringere Bitrate.
    Und dann noch von 41 - 60 Fps, hierbei wird dann das HFR Encoding freigeschaltet, was eine deutliche Steigerung der Bitrate zur Folge hat.


    Kann man denn nur x264 als 10bit Format bei Youtube hochladen? Oder gibts noch andere 10bit Formate, die Youtube nimmt.
    Kann mich erinnern, dass man früher auch keine x26410bit Videos hochladen konnte. Was geht denn inzwischen? (VP9 10bit Profile 2/3?)

    Zu den 60 fps: Du meinst jetzt, wie Youtube es umrechnet. Da hast du sicher Recht, aber das war nicht mein Gedanke.
    Youtube wird hauptsächlich auf Monitoren, Displays gesehen. Die laufen fast alle auf 60hz. Und auch TVs in Europa können 60hz.
    Du produzierst also Content, der dann hauptsächlich auf 60hz Geräten konsumiert werden soll. Daran würde ich mich automatisch anpassen.

    Andernfalls würden mir dann so Fragen einfallen: wenn ich eine flüssige Bewegung mit 50fps aufnehme und mit 60hz (ohne irgendwelche Filter) abspiele, wird sie dann noch 100% flüssig dargestellt?


    Dadurch das der eigene Encoder von MeGui schneller ist, habe ich bei 8 Bit eine Performance Steigerung.
    Mit 10 Bit sieht es dann natürlich etwas anders aus.


    Interessant. Weil es gibt eigentlich nur x264 als Encoder ... bei ffmpeg ist x264 nur eincompiliert ins ffmpeg Binary.


    Ich nutze ein *.bat, mit dem Inhalt:

    Das geht auch mit nur einem ffmpeg Aufruf, dann muss die Datei nur einmal dekodiert werden, anstatt 3x mal.

    zB.

    Code
    ffmpeg -ss 00:10:00 -t 00:05:00 -i input -acodec pcm_s16le -map 0:1 "audio1.wav" -acodec pcm_s16le -map 0:2 "audio2.wav" -f yuv4mpegpipe -map 0:v - | x264 - --demuxer y4m --preset veryfast --crf 18  --output "video.mkv"



    Die Audiodateien die ausgespuckt werden, sind in der länger und der Synchronität zum Video aber in Ordnung.
    Kann ich das einfach ignorieren oder muss da noch was geändert werden?


    Die Warnungen machen mir eigentlich keine Sorgen. Da ich ffmpeg gewohnt bin, ffmpeg spuckt sehr viele Warnungen aus.

    Wo ich mir aber nicht sicher bin:
    In den 8h Aufnahme wird es hin und wieder vorkommen, dass der Rechner nicht genug Ressourcen hat, um durchgängig 50 oder 60 fps aufzunehmen. (vielleicht hast du dann eine variable Framerate in der Aufnahme?)
    Ob das bei deiner Methode dann synchron bleiben wird, kann ich nicht sagen.

  • Kann man denn nur x264 als 10bit Format bei Youtube hochladen? Oder gibts noch andere 10bit Formate, die Youtube nimmt.


    Ob man noch andere Formate mit 10 Bit hochladen kann weiß ich jetzt nicht, aber ich weiß das VP9 geht, aber x265 nicht.
    Zudem VP9 oder x265 von der Geschwindigkeit viel zu langsam sind als das ich damit effektiv arbeiten könnte, zudem für mich die Dateigröße eher nebensächlich ist, 40 MB/s Uploud :D

    Andernfalls würden mir dann so Fragen einfallen: wenn ich eine flüssige Bewegung mit 50fps aufnehme und mit 60hz (ohne irgendwelche Filter) abspiele, wird sie dann noch 100% flüssig dargestellt?


    Das ist egal, es werden dann einfach zwischendurch der gleiche Frame 2 mal hintereinander angezeigt, das merkt man nicht wirklich.
    Klar 60 Fps ist flüssiger als 50 Fps, aber beim Video schauen ist der Unterschied nicht so groß.
    Früher wo es noch kein HFR Encoding gab, haben wir sogar nur mit 25 Fps aufgenommen, damit wir pro Pixel mehr Bitrate hatten, die niedrigere Fps haben wir dann damit ausgeglichen das wir bei der Videobearbeitung ein leichtes Motion Blur mit reingebracht haben, damit die Übergänge zwischen den Frames besser waren.

    Interessant. Weil es gibt eigentlich nur x264 als Encoder ... bei ffmpeg ist x264 nur eincompiliert ins ffmpeg Binary.


    Soweit ich weiß hat MeGui sich den x264 genommen und noch etwas angepasst. was zu der Steigerung der Geschwindigkeit geführt hat.
    Gerade für dich noch mal getestet, gleiche Aufnahme Unterschied von libx264 und MeGui, bei einem 5 Minuten Encode, 61 Fps zu 71 Fps, was etwas über 16 mehr Geschwindigkeit bedeuten.

    Wo ich mir aber nicht sicher bin:
    In den 8h Aufnahme wird es hin und wieder vorkommen, dass der Rechner nicht genug Ressourcen hat, um durchgängig 50 oder 60 fps aufzunehmen. (vielleicht hast du dann eine variable Framerate in der Aufnahme?)
    Ob das bei deiner Methode dann synchron bleiben wird, kann ich nicht sagen.


    Das sollte kein Problem sein, da das Aufnahmeprogramm mit CFR arbeitet, das heißt wenn ich im Spiel mal unter die Aufnahme Fps landen sollte, so wird ein Dummyframe geschrieben, das heißt die Anzahl der Frames pro Sekunde ist immer der gleiche Wert.
    Bei VFR hat man pro Sekunde immer einen schwankenden Wert, was für die Performance und die Flüssigkeit des Video nicht schlecht ist, aber für die Nachbearbeitung absolute Katastrophe ist.
    Aber was das angeht kann ich ja noch als Parameter bei x264 die Fps mit eintragen, dann sollte das ja sowieso "gelockt" sein.
    Wobei hier dann die frage ist ob es besser ist sowas bei ffmpeg einzutragen oder bei MeGui oder vielleicht sogar bei beiden?

    Hatte jetzt auch mal das mit dem neu Muxen der Videodatei probiert, die Fehlermeldung ist immer noch da.

    Code
    ffmpeg -ss 00:10:00 -t 00:05:00 -i input -acodec pcm_s16le -map 0:1 "audio1.wav" -acodec pcm_s16le -map 0:2 "audio2.wav" -f yuv4mpegpipe -map 0:v - | x264 - --demuxer y4m --preset veryfast --crf 18  --output "video.mkv"


    Das hat dann jetzt schon mal die zweite Fehlermeldung entfernt.

    3 Mal editiert, zuletzt von GelberDrache (7. April 2017 um 20:38)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!