Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Do Mär 28, 2024 13:57

Foren-Übersicht » Programmierung » Allgemein
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 16 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
BeitragVerfasst: Do Jul 21, 2016 23:03 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Servus miteinander!

Ich möchte gerne meine Animationen in Echtzeit so gut wie möglich aufnehmen, ohne viel zu komprimieren und ohne viel Preformanceverlust.

Weiß jemand vielleicht, ob man irgendiwie den Output der Grafikkarte splitten kann, also so, dass man genau das was man sieht eben auch aufnehmen kann, ohne den Rechner, auf dem gerendert wird, damit zu behelligen?
Falls ja, was brauch ich dazu?

Und falls nein, was gibt es für Möglichkeiten? Bin momentan an OpenGL gebunden.
Würde halt am Liebsten in 4K und 60 Hz aufnehmen.
Und selbst ne richtig flotte SSD schafft das unkomprimiert nicht.
Und diverse Lets Player machen ja sowas auch, also dachte ich mir, dass es gehen müsste.
Oder komprimieren die den Stream?
Komprimieren is ja bei der Menge auch nicht gerade performancefreundlich, oder?

Grüße,
Vinz

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Jul 22, 2016 07:30 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 14, 2013 21:17
Beiträge: 587
Programmiersprache: C++
Also ohne jegliche Kompression macht das glaube ich niemand. Da es mittlerweile Spezialchips gibt, die H.264-Encoding in Hardware erledigen, ist das auch nicht unbedingt nötig. Jede moderne GPU (auch die integrierten) haben einen solchen Chip mit an Bord. Du brauchst nur eine Software, die ihn auch nutzt. Ich glaube Fraps kann das nicht. Wenn du nicht den selben Rechner aufnehmen lassen willst, der auch das Bild berechnet, kannst du dir auch eine von diesen HDMI-capture-Boxen holen. Zum Beispiel elgato Game Capture.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Jul 22, 2016 10:07 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 2067
Programmiersprache: C++
Was für ein OS nutzt du denn?
Bei Windows gibt es Videosinks welchen du Einzelbilder gibst und dann z.B. MP4 herauskommt. Und das funktioniert mit OpenGL.

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Jul 22, 2016 17:00 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
glAwesome hat geschrieben:
Also ohne jegliche Kompression macht das glaube ich niemand. Da es mittlerweile Spezialchips gibt, die H.264-Encoding in Hardware erledigen, ist das auch nicht unbedingt nötig. Jede moderne GPU (auch die integrierten) haben einen solchen Chip mit an Bord. Du brauchst nur eine Software, die ihn auch nutzt. Ich glaube Fraps kann das nicht. Wenn du nicht den selben Rechner aufnehmen lassen willst, der auch das Bild berechnet, kannst du dir auch eine von diesen HDMI-capture-Boxen holen. Zum Beispiel elgato Game Capture.


Dieses Elegato ist eigentlich so was, was ich suche, aber es geht nur bis 1080p.
Weißt Du, ob man da die Daten auch RAW abspeichern kann, oder ob man nur komprimierten Output bekommt.
Hätte da gerne volle Kontrolle, was ich z.B. bei Aufnahmeprogrammen misse, ist die Möglichkeit, nur aufzunehmen, wenn ein neues Frame berechnet wurde, sieht nämlich unschön aus, wenn die Framerate mal einbricht und das mitaufgenommen wird.

Wie kann man den H.264-Encoding-Chip ansprechen?

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Zuletzt geändert von Vinz am Fr Jul 22, 2016 17:06, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Jul 22, 2016 17:04 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
i0n0s hat geschrieben:
Was für ein OS nutzt du denn?
Bei Windows gibt es Videosinks welchen du Einzelbilder gibst und dann z.B. MP4 herauskommt. Und das funktioniert mit OpenGL.

Ist dieses Videosinks denn performant?
Eigentlich hole ich momentan über OpenGl via PBO die Frames, das geht an sich sehr schnell.

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Jul 22, 2016 17:44 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 2067
Programmiersprache: C++
Für mich war es performant genug. Bei mir war die Bremse an anderer Stelle und es war schnell genug das ich mich nicht darum gekümmert habe.
Das musst du selber testen. Und ja, PBOs waren bei mir das Mittel.

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Jul 22, 2016 21:35 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 14, 2013 21:17
Beiträge: 587
Programmiersprache: C++
Vinz hat geschrieben:
Weißt Du, ob man da die Daten auch RAW abspeichern kann, oder ob man nur komprimierten Output bekommt.
Ich besitze so ein Gerät nicht, aber RAW-Output kann ich mir schwer vorstellen. Bei 4k und 60 fps wären das ja 1,5 GB/s. Welcher Datenträger ist so schnell? Abgesehen davon wäre selbst eine Terabyte-Festplatte nach gut zehn Minuten voll.

Vinz hat geschrieben:
Hätte da gerne volle Kontrolle, was ich z.B. bei Aufnahmeprogrammen misse, ist die Möglichkeit, nur aufzunehmen, wenn ein neues Frame berechnet wurde, sieht nämlich unschön aus, wenn die Framerate mal einbricht und das mitaufgenommen wird.
Wenn die Framerate einbricht, sieht es in jedem Fall doof aus. Auch wenn die Videodatei so geschrieben wird, als wenn jeder Frame 16,67 ms gedauert hätte, denn dann hättest du Geschwindigkeitssprünge in der Wiedergabe. Einziger Ausweg wäre meiner Meinung nach, auf timebased Movement zu verzichten und die Zeit stattdessen jeden Frame um einen konstanten Wert zu erhöhen. Dann müsstest du jedes gerenderte Bild aufzeichnen (z.B. als verlustfreies PNG) und daraus im Nachhinein ein Video machen. Habe ich dich richtig verstanden, dass es dein eigenes Programm ist, das du aufzeichnen willst? Also mit deinem Quellcode?

Vinz hat geschrieben:
Wie kann man den H.264-Encoding-Chip ansprechen?
Da gibt es verschiedene APIs. Auf Windows kenne ich mich nicht aus. Unter Linux gibt es VA-API, VDPAU und OpenMAX, jedoch wird keine dieser APIs von allen Grafiktreibern ordentlich unterstützt. Du müsstest dich also entweder an eine bestimmte Hardware binden oder Unterstützung für mehrere APIs implementieren - also genau das machen, was man durch die Nutzung einer Standard-API vermeiden will. https://xkcd.com/927/
Die Hardware-Encoder sind auch nicht alle gleich gut. In c't wurden die mal getestet, wobei einzig der von Intel brauchbare Qualität lieferte.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Jul 23, 2016 00:01 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
glAwesome hat geschrieben:
Vinz hat geschrieben:
Weißt Du, ob man da die Daten auch RAW abspeichern kann, oder ob man nur komprimierten Output bekommt.
Ich besitze so ein Gerät nicht, aber RAW-Output kann ich mir schwer vorstellen. Bei 4k und 60 fps wären das ja 1,5 GB/s. Welcher Datenträger ist so schnell? Abgesehen davon wäre selbst eine Terabyte-Festplatte nach gut zehn Minuten voll.

Vinz hat geschrieben:
Hätte da gerne volle Kontrolle, was ich z.B. bei Aufnahmeprogrammen misse, ist die Möglichkeit, nur aufzunehmen, wenn ein neues Frame berechnet wurde, sieht nämlich unschön aus, wenn die Framerate mal einbricht und das mitaufgenommen wird.
Wenn die Framerate einbricht, sieht es in jedem Fall doof aus. Auch wenn die Videodatei so geschrieben wird, als wenn jeder Frame 16,67 ms gedauert hätte, denn dann hättest du Geschwindigkeitssprünge in der Wiedergabe. Einziger Ausweg wäre meiner Meinung nach, auf timebased Movement zu verzichten und die Zeit stattdessen jeden Frame um einen konstanten Wert zu erhöhen. Dann müsstest du jedes gerenderte Bild aufzeichnen (z.B. als verlustfreies PNG) und daraus im Nachhinein ein Video machen. Habe ich dich richtig verstanden, dass es dein eigenes Programm ist, das du aufzeichnen willst? Also mit deinem Quellcode?

Vinz hat geschrieben:
Wie kann man den H.264-Encoding-Chip ansprechen?
Da gibt es verschiedene APIs. Auf Windows kenne ich mich nicht aus. Unter Linux gibt es VA-API, VDPAU und OpenMAX, jedoch wird keine dieser APIs von allen Grafiktreibern ordentlich unterstützt. Du müsstest dich also entweder an eine bestimmte Hardware binden oder Unterstützung für mehrere APIs implementieren - also genau das machen, was man durch die Nutzung einer Standard-API vermeiden will. https://xkcd.com/927/
Die Hardware-Encoder sind auch nicht alle gleich gut. In c't wurden die mal getestet, wobei einzig der von Intel brauchbare Qualität lieferte.


Ja, das stimmt, 60 Hz 4K packt keine SSD.
Wenn ich auf 48 Hz gehe und vorher auf YUV schreibe würde es gehen und ich hätte effektiv keine Kompression, weil die ganzen Videoformate auf den Videoplattformen eh YUV haben.
Ja, es ist meine eigene Anwendung und da könnte ich die Bewegungen natürlich komplett Frameweise berechnen, aber dann müsste ich die Soundaufnahme auch selber schreiben, ist aber eig kein Problem...
Das mit dem Encoding ist glaub ich n Problem, das wirklich gut zu machen, weil man ja für gutes Encoding eig. viel Zeit braucht, oder?
Oder ist es möglich, relativ schnell ein Encoding auf eine relativ hohe Qualität hinzubekommen?

Weiß jemand zufällig, wie man sich dieses Encoding, speziell jetzt das Encoding auf der GPU vorstellen kann?
Wäre natürlich schon optimal, wenn die Grafikkarte irgendwas mit den Frames macht, und dann überhaupt erst viel weniger Daten von der GPU geholt werden müssen.
Intelprozessor habe ich, aber wenn das Zeug auf ner AMD oder NVIDIA gerendert wird und ich dann das ganze doch über den Prozessor laufen lassen muss, ist es ja auch nicht optimal, gibts da von AMD und NVIDIA auch ne API?
Selber schreiben in OpenGL z.B. ist wohl eher etwas zu aufwändig...

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Jul 23, 2016 00:02 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
ffmpeg fällt mir da ein, was man auch aus dem Quelltext benutzen kann, aber das meins Wissens komplett auf der CPU.

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Jul 23, 2016 01:47 
Offline
DGL Member

Registriert: Mi Sep 15, 2010 18:22
Beiträge: 59
Wohnort: Sachsen Meißen
Programmiersprache: Pascal, C(++), Java
Bei 4K/60 würde ich mit apitrace arbeiten. Du hast dabei kaum Performance Einbrüche, weil nur die OpenGL-Aufrufe aufgezeichnet werden.

apitrace trace deineAnwendung // Erzeugt eine .trace Datei deiner Animation
apitrace dump-images deineAnwendung.trace // Speichert alle Frames als PNG
apitrace dump-images --calls=10-50 deineAnwendung.trace // Speichert Frame 10 bis 50 als PNG

Aus der Bildersequenz erstellst du deine Videodatei und fügst den separat aufgenommenen Sound hinzu.

_________________
bluesky


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Jul 23, 2016 09:41 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++
Zumindest NVIDIA hat für geanu den Anwendungsfall ShadowPlay. Benutze ich u.a. um Videos von meinen Vulkan-Anwendungen zu machen, und es kostet trotz schwer CPU und normaler HD kaum Leistung. Hab bisher zwar nur max. 2560x1440@60fps aufgenommen, aber 4K ist auch möglich.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Jul 23, 2016 10:12 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 14, 2013 21:17
Beiträge: 587
Programmiersprache: C++
bluesky hat geschrieben:
Bei 4K/60 würde ich mit apitrace arbeiten.
Auch eine gute Idee. Du kannst dir sogar den Umweg über PNG-Dateien ersparen und den Output von apitrace direkt an ffmpeg weiterleiten:
Code:
  1. glretrace --core -b -s - aufnahme.trace | ffmpeg -r 60 -f image2pipe -c:v ppm -i pipe: -c:v libx264 -preset medium video.mp4

Wenn die Videoqualität bei dir oberste Priorität hat, führt übrigens kein Weg an Software-Encoding vorbei. x264 ist hier weiterhin ungeschlagen und insbesondere allen Hardware-Encodern überlegen.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Jul 23, 2016 11:28 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Dieses Api-Trace ist ja mal ein ganz anderer Ansatz.
Speichert das dann alles was auf der GPU ist in diese trace file, also auch Texturen, etc.?
Oder wie kann ich mir das vorstellen?

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Jul 23, 2016 12:21 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 14, 2013 21:17
Beiträge: 587
Programmiersprache: C++
Apitrace zeichnet ganz einfach alle gl*-Aufrufe auf, die dein Programm macht. Inklusive aller Parameter. D.h., wenn du glTexImage2D aufrufst, landen auch die Texturdaten im trace-File. Das Trace-File kannst du hinterher auf jedem Rechner, der die nötigen OpenGL-Features unterstützt, wieder abspielen. Dabei kannst du den Kontext in den Debug-Modus stellen um Fehler zu entdecken, Performance analysieren, Treiber vergleichen oder was auch immer. Oder du leitest halt die Ausgabe an ffmpeg weiter.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Jul 23, 2016 14:41 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Den Sound synchron zu bekommen stelle ich mir schwierig vor. Wenn die Framerate des Zielobjektes über die Aufnahme hinweg schwankt, wird Apitrace das nicht abbilden; Apitrace rendert so schnell es kann.

viele Grüße,
Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 16 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Foren-Übersicht » Programmierung » Allgemein


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 31 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.049s | 17 Queries | GZIP : On ]