|
|
|
|
|
|
|
Ok, wobei ich da eher schauen würde, warum MeGUI diesen seltsamen Fehler ausspuckt.
Vergleich doch mal Rohdaten-Video vs. Blender-Render-Video.
Was machst du denn nochmal in Blender genau? Also was Avisynth nicht kann bzw. zu umständlich ist.
|
|
|
|
|
|
|
|
|
|
|
Blender, weil ich mich mit dem Schneiden einfacher tuhe und einfach gern mit ein paar 3D Effekten im Intro spiele. Ist zwar noch verbesserungswürdig, aber wird.
Das mit MeGUI ist seltsam. Ab irgendeiner Stelle im Video encoded er einfach kein Video mehr. Kein Fehler. Er wird einfach schneller und die Datei wächst nur noch minimal.
Werd bei Gelegenheit mal schauen, ob ich was im Log finde.
Aber momentan bringts mir Geschwindigkeitsmäßig und vom Klickaufwand absolut keinen Mehrwert gegenüber FFMpeg.
|
|
|
|
|
|
|
|
|
|
|
Ähh, dank mir? Okay. Ich weiß von nichts (mehr) 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Das Level müsste er doch automatisch ermitteln, ich meine Settings auch mal verändert und lande bei 4.
Preset ist Medium
| |
| Code: |
program --crf 26.0 --deblock -1:-1 --keyint 375 --min-keyint 25 --bframes 10 --b-adapt 2 --scenecut 60 --ref 5 --merange 20 --me umh --psy-rd 1.0:0.15 --output "output" "input" |
|
|
|
|
|
|
|
|
|
|
|
|
Level 4 hab ich nur noch drin stehen, weils in der Doku kein 5 gibt 
Werds ändern.
Das mit dem AAC werd ich mir auf jeden Fall auch anschauen.
Hat funktioniert, also hab ichs so gelassen
@Maestro: Du hast gesagt: Demux das Handbrake Video und mux es mit My Mp4BoxGUI neu. Das hat dann funktioniert.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von NightBooster am 29.09.2015 17:58]
|
|
|
|
|
|
|
|
|
|
Ah. Jo, da gab es irgendwann mal ein update der mp4box dll blascheiße.
|
|
|
|
|
|
|
|
|
|
|
|
Ja, einfach die neuste Version MP4Box saugen und mit der im gewünschten Program ersetzen, wenn Handbrake das benutzt.
|
|
|
|
|
|
|
|
|
|
|
m(
Tut es eben nicht. Zumindest konnt ich absulut nix dazu finden. Dann wärs ja auch kein Problem.
Die Aussage war: Wenn man ein Handbrake Video (das Probleme macht) mit MyMp4BoxGui demuxt und wieder damit neu muxt, sind die Probleme weg.
Ich gebs auf. Muss wohl an mir liegen.
|
|
|
|
|
|
|
|
|
|
|
|
Handbrake kann das auch "irgendwie eingebaut" haben, und dann isses halt ständig ne alte Version. Ist halt ein Ball, das Tool.
|
|
|
|
|
|
|
|
|
|
|
Hab grad noch mal nachgeschaut. Nix Mp4Box in Handbreak.
Könnte an ner veralteten Version von libavcodec liegen. Aber alle dlls sind da irgendwie zusammengepackt in eine. Einzeln austauschen is nich.
| | Zitat von ]Maestro[
Ist halt ein Ball, das Tool.
| |
So schauts halt mal aus.
|
|
|
|
|
|
|
|
|
|
|
| |
| Code: |
video4=Speedup("ShooterGame-Win32-Shipping 2015-10-16 18-23-50-03_speedup.avi",2, "Audio_on"=true) |
|
Was ist daran falsch?
"Expected a , or )"
Wenn ich das "Audio_on"=true weglasse kommt ein invalid parameter error.
edit: Habs. Bin ein Idiot. 
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Murica am 16.10.2015 20:14]
|
|
|
|
|
|
|
|
|
Ich glaub langsam echt, dass ich entweder zu blöd bin ein Programm oder einen Codec zu finden, der vernünftig aufnimmt (und den ich weiter verarbeiten kann), zu finden...
Das sollte beim encoden nicht passieren, oder?
| |
| Code: |
Stream mapping:
Stream #0:0 -> #0:0 (lagarith (native) -> h264 (libx264))
Stream #0:1 -> #0:1 (pcm_s16le (native) -> aac (libvo_aacenc))
Press [q] to stop, [?] for help
Input stream #0:0 frame changed from size:960x540 fmt:rgb24 to size:960x540 fmt:bgr0
Input stream #0:0 frame changed from size:960x540 fmt:bgr0 to size:960x540 fmt:rgb24
Input stream #0:0 frame changed from size:960x540 fmt:rgb24 to size:960x540 fmt:bgr0
Input stream #0:0 frame changed from size:960x540 fmt:bgr0 to size:960x540 fmt:rgb24
Input stream #0:0 frame changed from size:960x540 fmt:rgb24 to size:960x540 fmt:bgr0
Input stream #0:0 frame changed from size:960x540 fmt:bgr0 to size:960x540 fmt:rgb24
Input stream #0:0 frame changed from size:960x540 fmt:rgb24 to size:960x540 fmt:bgr0
Input stream #0:0 frame changed from size:960x540 fmt:bgr0 to size:960x540 fmt:rgb24
Input stream #0:0 frame changed from size:960x540 fmt:rgb24 to size:960x540 fmt:bgr0
Input stream #0:0 frame changed from size:960x540 fmt:bgr0 to size:960x540 fmt:rgb24
Input stream #0:0 frame changed from size:960x540 fmt:rgb24 to size:960x540 fmt:bgr0
Input stream #0:0 frame changed from size:960x540 fmt:bgr0 to size:960x540 fmt:rgb24
Input stream #0:0 frame changed from size:960x540 fmt:rgb24 to size:960x540 fmt:bgr0
Input stream #0:0 frame changed from size:960x540 fmt:bgr0 to size:960x540 fmt:rgb24
frame=33406 fps= 11 q=31.0 size= 151921kB time=00:18:33.63 bitrate=1117.5kbits/s dup=666 drop=0 |
|
Scheint bei der Aufnahme immer dann zu passieren, wenn die Framerate beim Laden einbricht.
RGB24. Sollte so sein. RGB mit 8 Bit pro Channel.
BGR0? BGR Farbraum ohne Daten? Toll. Also leeres Bild.
Sorgt am Ende des Tages nach dem Verarbeiten dafür, dass mein Video async wird. 
|
|
|
|
|
|
|
|
|
|
|
|
Linux? Kannst ja noch magicyuv testen, den codec nutze ich.
|
|
|
|
|
|
|
|
|
|
|
Immernoch Windows. Die Aufnahme kommt aus Dxtory mit dem Lagarith Codec.
Bilde mir ein, ich hätte den magicyuv schon getestet und kann ihn mit Blender nicht laden.. aber ich werds wohl noch mal versuchen.
Vielleicht liegts ja wirklich am Codec und nicht am Programm. Ich hoffs einfach mal. Weil Softwaretechnisch gehen mir langsam die Möglichkeiten aus.
Input ist im übrigen als rgb24 definiert. Dass der überhaupt switchen kann ist mir n Rätsel..
| |
| Code: |
Metadata:
encoder : DxtoryCore ver2.0.0.133
ISRC : Video:Lagarith Lossless Codec Audio0:VoiceMeeter Output (VB-Audio VoiceMeeter VAIO)
Duration: 00:33:09.50, start: 0.000000, bitrate: 128879 kb/s
Stream #0:0: Video: lagarith (LAGS / 0x5347414C), rgb24, 960x540, 124265 kb/s, 30 fps, 30 tbr, 30 tbn, 30 tbc
Stream #0:1: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, 2 channels, s16, 1536 kb/s |
|
Vielleicht ist das aber auch einfach nur die Codierung für leere Frames.
|
|
|
|
|
|
|
|
|
|
|
|
Ach stimmt, der blender-kram.
|
|
|
|
|
|
|
|
|
|
|
Ich ärger mich gerade mal wieder mit encoden rum.
Die Raw ist 34:29 lang. Die encodete Videospur ist 34:31 lang. Die encodete Audiospur 34:28. Asynchron wie sonst was. Wie kommt sowas? encoded wurde mit constant quality und einem CRF von 30.
Edit: Die Raw-Aufnahme ist übrigens synchron. erst nachdem encoden geht alles vor die Hunde.
EditEdit: Also die Videospur ist nachdem encodeten 2 Sekunden länger als die Raw-Daten. Die Audiospur hingegen ist auf einmal 1 Sekunde kürzer.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Skeith am 15.11.2015 0:36]
|
|
|
|
|
|
|
|
|
Womit hast du aufgenommen? Welcher Codec? Eventuell variable Framerate.
Du kannst ja testweise mal nach was anderem encodieren und schauen ob sich was ändert.
tschy2m
|
|
|
|
|
|
|
|
|
|
|
Shadowplay.
Raws sind in MP4.
Hab jetzt nach ABR und nach Constant Quality encoded. Beides gleich.
Hab jetzt mal nur eine Raw genommen.
Raw 22:18
Video 22:18
Audio 22:17
Ton kommt gefühlt etwa ne sekunde zu spät.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Skeith am 15.11.2015 1:10]
|
|
|
|
|
|
|
|
|
|
Das lässt sich aber in der Nachbearbeitung eigentlich gut fixen, wenn die Verschiebung konstant ist.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hitmiccs
Das lässt sich aber in der Nachbearbeitung eigentlich gut fixen, wenn die Verschiebung konstant ist.
| |
Naja ich weiß ja nicht ob sie konstant ist. ich hab nur dieses eine Gespräch mal als Ankerpunkt genommen.
Gebe es auf. Kriege es nicht gefixt. hab jetzt versucht die erste Sekunde aus der Audiospur rauszuschneiden. Gespräch ist trotzdem asynchron.
Verstehe halt nicht wie sowas kommt, wo die Raw doch völlig in Ordnung ist.
Werde das morgen dann einfach so hochladen.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Skeith am 15.11.2015 1:17]
|
|
|
|
|
|
|
|
|
Kann an framedrops liegen, da shadowplay ja h264 macht. :/
Wenn du es mit vdub offenen kannst mal versuchen als avi zu speichern oder so.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Bregor am 15.11.2015 1:28]
|
|
|
|
|
|
|
|
|
Ich geb ab, ich bin mit meinem Latein am Ende
| | skeith: hmm wenn directshow jetzt geht kann ich vllt auch wieder über nacht encoden ohne das megui abstürzt. das wäre ja ein traum
skeith: ehm ja
skeith: jetzt ist das ding über 8 sekunden asynchron.
Maestro: wenn du dir die origina ldateien anguckst, sind die beim gucken asynchron?
skeith: nein
Maestro: okay..
Maestro: lass michj mal googlen
Maestro: weil das kann gar nicht sien was dir da pssiert.
Maestro: bzw, mach mal folgendes
skeith: Was ich halt nicht verstehe:
Maestro: http://pastebin.com/index/CSY1ZGgx
Maestro: encode mal nur das
Maestro: ohne bauchbinde, ohne anderne bullshit
Maestro: nur das video
Maestro: ach warte
Maestro: was vergessen
Maestro: http://pastebin.com/index/CSY1ZGgx
Maestro: da is richtig
skeith: ok da ist jetzt aber auch kein changefps und +++\ drin
Maestro: evtl ist dsa script noch nich ganz richti, mach das ausm kopf
Maestro: wen ner fehler wirft, sag an
skeith: Hast du das richtig geschickt? da ist die bauchbinde noch drin
Maestro: http://pastebin.com/j1kPQNfd
Maestro: ich bin offenbar unfäig
skeith: Video definition fehlte. hab ich ergänzt
Maestro: zeig mal script
skeith: Video=DirectShowSource("Desktop 11.14.2015 - 20.33.53.24.mp4").changefps(30) ++\
DirectShowSource("Desktop 11.14.2015 - 20.33.53.24_1.mp4").changefps(30)
video
ConvertToYV12(matrix="rec.709").sincresize(1280,720)
Maestro: ah kay
Maestro: wie gesagt, ausm kopf
skeith: np
skeith: so kleinigkeiten hab ich schon verstanden, die krieg ich alleine hin
Maestro: gut!
Maestro: jedenfalls, encode das mal, so wie eben dsa video
Maestro: und wenn das asynch ist.. ist der fehler woanders
skeith: läuft
Maestro: http://staticdelivery.nexusmods.com/mods/1151/images/475-1-1447484535.jpg
Maestro: hahaha
skeith: lol
skeith: 25 minuten
skeith: 1 Minute
Maestro: gogogogo
Maestro: GOOGGOGOGOGO
Maestro: RAHRHHRGLGLALGL!
skeith: audio und video sind jetzt zumindest schonmal gleich lang
skeith: nope
skeith: immer noch
Maestro: wie sind dene settings in megui?
Maestro: faster? slower?
skeith: Medium
Maestro: das wollt ich wissen
Maestro: kay
Maestro: hmm
Maestro: ALL MEIN WATT
Maestro: sind die erstne beiden fallout videos nicht asynch?
skeith: neu
Maestro: nein?
skeith: nein
Maestro: also ja?
Maestro: 
skeith: nein sie sind nicht asynch
Maestro: schon gut
Maestro: okay..
Maestro: sind dir bei den aufnahmen zu 1, 2 oder 3 frame einbrüche aufgefallen?
Maestro: wo du sagen würdest, video 1 und 2 hatte ich durchgehend 60fps
Maestro: bei drei dann runter auf 25 oderso?
skeith: naja ich hab generell zwischen 30-40 fps
skeith: nichts awas aufgefallen wäre
Maestro: key
Maestro: hmm
Maestro: one moment please, processing
skeith: ich encode gerade nochmal ohne die beiden Raws zu verbinden. also nur die erste.
skeith: Das Async ist ja schlimmer geworden statt besser.
skeith: statt 1 Sekunde zu spät kommt der Ton jetzt lange bevor das gespräch losgeht
Maestro: DAS GEHT DOCH GARNICH
Maestro: zum fick
Maestro: ZUM HIRNFICK!
skeith: is aber so mann
Maestro: ja aber es ist hohl mann
Maestro: das hab ich ja noch nie erlebt..
Maestro: wart kurz
| |
|
|
|
|
|
|
|
|
|
|
|
|
Bregor wir testen jetz was du vorgeschlagen hast, nur mit Handbrake statt virtualnapf
|
|
|
|
|
|
|
|
|
|
|
Direkt in h264 Aufnehmen ist halt irgendwie scheiße, weils da zu solchem Mist kommen kann. Da ist keiner dran Schuld oder unfähig, das ist halt technisch bedingt am Ende, da brauchen nur ein paar Frames nicht ordentlich rekonstruiert werden zu können, die werden dann aufgefüllt oder nicht beim reencode und schon haste den Salat. Aber VDUB "kann" das vlt reparieren, wenn er es öffnen kann und als .avi abspeichert. Aber das ist glaube ich auch nur eine direct-stream-copy, also wenn der irgendwie kaputt ist, geht es halt nicht.
Noch eine Idee: Das Video mit irgendwas aus dem Player abfilmen, da sollten ja stabile Frames herschen und wenn du sagst die Wiedergabe ist ok, müsste das funktionieren.
|
|
|
|
|
|
|
|
|
|
|
|
Ein Video mit variablen FPS aus einem Player abfilmen ist das gleiche, wie ein constant FPS h264 reencode in Handbrake. Nur das Handbrake das nicht in Echtzeit machen muss.
|
|
|
|
|
|
|
|
|
|
|
War variable Framerate nicht schon immer das Problem von Shadowplay? Ich dachte, Maestro hätte da inzwischen einen funktionieren Workflow gefunden: Erst mit Handbrake konstante Framerate erzeugen und dann weiterverarbeiten, falls du die Weiterverarbeitung überhaupt brauchst.
EDIT: Das hat mit h264 nur bedingt zu tun. Es erlaubt variable Framerate ohne Probleme. Viele Videoencoder und -editoren haben allerdings gar keine bis rudimentäre Unterstützung dafür.
Vielleicht wäre es auch eine Idee, dass nochmal durch den Hardware Encoder auf der Grafikkarte zu schieben. Der hat schließlich den Murks mit Shadowplay erzeugt. Ob der dann allerdings konstante Frameraten ausspuckt bzw. man das einstellen kann, weiß ich nicht.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Ratatoskr am 15.11.2015 12:00]
|
|
|
|
|
|
|
|
|
Es macht halt irgendwie mehr Probleme, als es hilft wie es scheint, darum mag ich sowas nicht. Hat mit dem ATI-Eigenen Aufnahmecodec auch nicht ordentlich funktioniert.
#dxtorymasterrace
|
|
|
|
|
|
|
|
|
|
|
Ich würde ja auch dxtory benutzen aber die raws sind so riesig. weiß nicht wo ich das alles lagern soll. ich überleg ja schon die gelagerten lps zu löschen damit wieder platz für große raws ist.
Ich versuche das jetzt noch zu Ende. Wenns dann nix wird nehm ich nochmal neu mit dxtory auf. nachdem ich 200gb auf der platte freigemacht habe.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Skeith am 15.11.2015 12:05]
|
|
|
|
|
|
|
|
|
|
Wie groß sind denn jetzt deine Aufnahmedateien?
|
|
|
|
|
|
|
|
| Thema: Let's Help Für LPIP ( Tutorials und andere Hilfen ) |
