Sony Vegas Pro lastet CPU nicht aus

[Tenchi Muyo]

Nochmal zu Sony Vegas:

habe eine Vorlage um ein AVCHD Video in ein Ipad Format (Main Concept AVC/ACC mp4) 1280x720 29,97 1pass @5.120kps
umzuwandeln.

Sony Vegas lastet dabei sehr wohl alle 12 Thread mit bis zu 100% aus.

Es kommt wirklich auf den verwendeten Codec an.

Werde das Ergebnis übrigens sehr genau mit TMPGEnc Vergleichen!

Edit:

Die benötigte Zeit fürs Rendern:

Sony Vegas Pro: 6:21 Minuten (194 MB)

TMPGEnc Video Mastering Works 5: 10:19 Minuten (190 MB)

Optisch sehe ich keine großen Unterschiede zwischen den Videos,
aber muss ich noch weiter prüfen.

Edit: mir ist noch was wichtiges eingefallen, TMPG habe ich mit very slow genutzt!
Das dürfte die Zeitdifferenz wohl erklären.

 

[maxwell-cs]

5 mbit ist (je nach content) schon relativ viel, die unterschiede zwischen einem guten und einem schlechten encoder werden natürlich mit steigender bitrate immer weniger sichtbar. in direkten (mehreren!) frame - zu - frame vergleichen sollte man aber dennoch einen unterschied sehen.

 

[Tenchi Muyo]

Ah, ok das habe ich nicht bedacht!

Gibt es irgendein Tool mit dem man so ein Vergleich anstellen kann?

Edit: das org. Material hat eine Datenrate von 26.744kps

Edit2:

ist es in TMPG egal welche Spur ich importiere, der Film wird gesplittet in Playlist 1 & Program 1.

 

[maxwell-cs]

ich mache das meist per hand mit einer der beiden folgenden methoden:

die technisch einfachere: datei mit media player classic öffnen, zu bestimmten frames springen (über play - go to - framenummer) und mit file - save image einen screenshot speichern. dabei natürlich ein verlustfreies format wählen.

das mit denselben frames für beide dateien machen und dann zwischen ansichten von gleichen frames hin - und herspringen, z.b. ganz einfach mit der windows-fotoanzeige.


die andere methode benutzt das folgende avisynth-script (benötigt avisynth 2.60 und ffms):

src = "samp"
extension = "mkv"
newWidth = 1920
interval = 125
source = FFVideoSource(src + "." + extension)
newheight = 2 * int(float(source.height * newWidth) / float(source.width * 2))
source
Spline64Resize(newWidth, newheight)
ConvertToRGB32()
SelectEvery(interval)
AssumeFPS(5)
ImageWriter(file = src + "\%03d_" + src + ".png", type = "png")

das skript skaliert das videomaterial auf eine gegebene breite ("newWidth") hoch und erstellt dann screenshots (alle "interval" viele frames ein screenshot).
die variable "src" gibt an, wie das video ohne endung heißt, "extension" die erweiterung.
außerdem muss in dem ordner ein unterordner mit dem namen $src (hier also "samp") vorliegen, in den dann die screenshots gespeichert werden.

hört sich vielleicht etwas kompliziert an, aber wenn man es öfters macht, ist es doch ganz angenehm, nur ein skript kopieren zu müssen und den namen einzutragen.

zum erstellen der screens dann einfach das skript mit nem directshow-mediaplayer starten und kurz warten.

 

[Tenchi Muyo]

selber gelöscht

 

[maxwell-cs]

jap - png ist verlustfrei.

 

[Tenchi Muyo]

Neuer Test mit 2.500Kbps


Die Unterschiede sind "relativ" gering.


Main Concept AVC/ACC mp4:

Ganz klar ist das Bild mehr geglättet, im VLC Player wirkt das Bild dadurch "gefälliger"


H264:

Das Bild ist körniger aber dadurch bleiben mehr Details erhalten.

Aufällig sind z.B. Schatten die Detailierter (pixelig) sind wobei MainConcept (flächiger wirkt).


Auf schwarzen Hintergrund fallen kleine Details besser auf.

Daher denke ich das der H264 Codec auf einem HDTV insgesamt besser aussehen wird.

 

[maxwell-cs]

welche einstellungen hast du in TMPGEnc benutzt?

ansonsten nochmal zum unterschied h264 / x264 (nicht schlimm, das unterscheiden die meisten nicht richtig)

H.264 ist ein standard zur videokodierung, genau wie z.b. mp3 ein standard zur audiokodierung ist.

x264 (in diesem fall von TMPGEnc angesteuert) und MainConcept sind implementierungen von H.264-encodern, erzeugen also H.264-konforme videostreams. nur dass eben die qualität dieses videostreams von der qualität eben dieser implementierungen und den einstellungen, mit denen sie gefüttert werden, abhängt.

der standard lässt dem encoder sehr (sehr sehr!) viele möglichkeiten, wie er ein video kodieren kann.
ein guter encoder zu sein, bedeutet unter diesen sehr vielen möglichkeiten meist eine gute zu finden.

und noch ein edit: zu welchem zweck benötigst du die encodes? nur um sie lokal zu speichern und dann später von einem (ht) pc aus wiederzugeben oder soll das ganz verteilt oder auf anderen geräten wiedergegeben werden, d.h. kompatibilität mit weit verbreiteten decodern ist pflicht?

 

[Tenchi Muyo]

Die Einstellungen wie oben:

Für iPad->X264 -> 1280x720 29,97 1pass @2.500kps CBR -> very slow


Was zum Vergleich der Screenshots besser geht:

die Bilder übereinanderlegen und dann wechseln.

Dann fallen doch mehr Details mit der H264 Codierung auf, auch wenn es sich hierbei nur um Nuancen handelt (Augenbrauen vom Baby - meine Tochter die eh kaum sichtbar sind).

Wenn ich das 2 Pass verfahren anwende - könnte ich damit die Qualität steigern?
Oder eher weniger weil die Bitrate ja dann variable sein muss von "kps" bis "kps" ?


Eine andere Frage ist, ob 1280x720p überhaupt fürs IPad korrekt wäre?

Die max. Auflösung ist 1024x768
irgendwo im Netz stand das mein bei 1920x1280 eine Auflösung von 1024x576 nutzen muss !?

 

[maxwell-cs]

CBR = constant bitrate ist nicht besonders effizient. ist das ein muss? ansonsten versuche es mal mit 2-pass-vbr und preset slower statt veryslow.

der vorteil von vbr: unterschiedliche teile eines videos benötigen unterschiedlich viel bitrate für eine ungefähr gleiche qualität. klar: eine detaillierte naturaufnahme einer wiese z.b. beinhaltet ungleich mehr information als eine weiße fläche. auch lässt sich natürlich ein video, in dem sich kaum etwas bewegt, leichter komprimieren.

vbr nutzt das und spart da bitrate, wo sie nicht so sehr benötigt wird, und spendiert sie an stellen, wo sie sinnvoller qualitätssteigernd verwendet werden kann.

zur auflösung: ja, du solltest auf die auflösung des wiedergabegerätes runtergehen.
die höhe errechnet sich dann durch das konstante seitenverhältnis und anschließendes runden auf ein vielfaches von 2 oder 4.
neue breite / neue höhe = alte breite / alte höhe
also:
neue höhe = alte höhe * (neue breite / alte breite)

beispiel: 1920 x 1080
neue breite: 1024
neue höhe: 1080 * (1024 / 1920) = 576.

 

[Tenchi Muyo]

Danke für den Tip!

very slow ist schon ok - dh. er holt das max. an Bildqualität raus - oder?

Aber dann würde VBR nur Sinn machen wenn ich die Bitrate leicht nach oben erhöhe,
damit er das auch nutzen kann!

Wenn ich 2.500 Kpbs als max. einstelle wird das Bild ja nicht besser sein als mit 2.500Kbps CBR.

Wobei das max. soll angeblich ja bei 2,5Mbps liegen.

Mit anderen Kauf-Apps kann man aber wiederum "alles" bis hin zu MKV's abspielen (ohne vorher was umzuwandeln.

Ich möchte allerdings schon die Videos verkleinern wegen des Platzes und auch der Akkuleistung.

Zumindest kenne ich es noch vom iPod so, ein nicht umgewandeltes Video machte den Akku so schnell leer das man bei zuschauen konnte.
Denke das dürfte bei iPad nicht viel anders sein.

Edit:

dann ist es aber komisch das Sony Vegas generell 1280x720 als Default Wert vorgibt.
Tmpg - nutz fürs Ipad nur 320x240 - eine Auflösung von 1024*576 läßt sich gar nicht mit dem vorgegeben Profil eingeben. Nur wenn man die MPEG Standards ausser kraft setzt kann man manuelle Einstellungen vornehmen.

Edit:

Wären so die Einstellungen ok?

 

[maxwell-cs]

very slow ist schon ok - dh. er holt das max. an Bildqualität raus - oder?

ja - die abstufungen von ultrafast über very fast, faster, fast, medium, slow, slower, very slow bis zu placebo verbessern die qualität bei gegebener bitrate auf kosten der laufzeit des encodings.

Wenn ich 2.500 Kpbs als max. einstelle wird das Bild ja nicht besser sein als mit 2.500Kbps CBR.

klar - vbr mit max 2500 kann nicht besser sein als cbr mit 2500.
aber: vbr mit durchschnittlich 2500 kbps wird besser aussehen als cbr mit 2500 kbps - bei gleicher dateigröße.
die angabe einer maximalen bitrate beim vbr-verfahren dient dazu, das wiedergabegerät nicht zu überlasten: es könnte ja z.b. sein, dass dein wiedergabegerät nur bis 5 mbit ruckelfrei wiedergeben kann, es aber eigentlich sinn machen würde, ein paar sekunden mit 10 mbit zu encoden. da greift dann die maximal erlaubte bitrate.

also: ziel-bitrate auf 2500 und max. bitrate auf z.b. 5000 oder 10000, was halt das ipad so aushält.

edit: joar, das sieht schon prinzipiell ganz gut aus. mit diesen einstellungen sollte es wirklich klar besser als MainConcept sein.

wenn du dich davon überzeugt hast, musst du noch die passende bitrate finden, die 2500 sind ja erstmal willkürlich gewählt.

prinzipiell müsstest du danach auch für jedes andere video neu testen, mit welcher bitrate es noch gut aussieht. das kann man tun (kostet aber unendlich zeit), oder man nimmt einfach immer denselben wert, oder man nutzt (wie z.b. ich selbst für meine encodes (: ) ein weiteres tolles feature von x264: der crf-modus.

prinzipiell ist der crf-modus ähnlich zum vbr-modus. die bitrate wird je nach komplexität der aktuellen szene verteilt. allerdings wird nicht eine bestimmte durchschnittliche bitrate, die am ende erreicht werden soll, angestrebt, sondern eine bestimmte qualität. d.h.: mit denselben einstellungen spendiert x264 im crf-modus material mit vielen details automatisch mehr bitrate als simplerem material.

da es (derzeit, aber wohl auch in der näheren zukunft) kein vom computer berechenbares maß dafür gibt, wie gut ein kodiertes video für den menschen aussieht, ist der crf-modus natürlich nur eine näherung, d.h. es kann immer noch vorkommen, dass manche videos sich in der qualität leicht unterscheiden. damit kann man aber gut leben.

daher benötigt der crf-modus auch nur einen pass und bekommt als parameter statt einer bitrate einen "qualitätswert", den crf-wert. je kleiner dieser wert ist, desto besser die qualität. meist sind werte zwischen 18 und 24 sinnvoll, bei zeichentrickmaterial auch höher.

 

[Tenchi Muyo]

Also das Ergebnis mit den Einstellungen kann sich eigentlich sehen lassen, die Datei hat nur 1/10 der größe der org. Datei.

Wobei man sagen muss das org. Material hat 1920x1080@50fps.

Was mir gerade so auffällt - wir driften vom Thema ab,
vielleicht sollte ich besser einen eigenen Thread erstellen ?

 

[maxwell-cs]

joar, bietet sich schon an.

 

[Tenchi Muyo]

Eine Frage noch:

Könnte ich nicht in Sony Vegas Pro das Projekt als unkomprimiertes AVI abspeichern und dann einfach mit Handbrake umwandeln (h264) ?

Wäre AVI uncompressed nicht sozusagen lossless?

Die Handbrake Konvertierung fürs Ipad sieht übrigens sehr gut aus.
XMedia Recode stürtz immer ab und der AVS4You Encoder nutzt scheinbar kein x264/H264 Codec der alle CPU Kerne auslastet.

 

[mvBarracuda]

Nimm doch einfach wie Demon vorgeschlagen hat ein Frameserverplugin. Dan sparst du dir den Umweg über ein sperriges, großes Zwischenformat, hast keinerlei Qualitätsverlust und kannst anschließend mit x264 und deinem Lieblingsfrontend (Handbrake, MeGUI, Avidemux, Whatever) enkodieren.

 

[maxwell-cs]

joar, der umweg über ein lossless-format lohnt sich nur, wenn das rendern des videos selbst in sony rechenintensiv ist und du einen 2-pass-encode machen willst, da dann ja sony vegas alles doppelt rendern müsste.
wenn das nicht der fall ist, solltest du, wie schon gesagt, den frameserver nutzen.

 

[Tenchi Muyo]

Meine Gedanke wäre:

In Sony Vegas ganz normal den Film bearbeiten so wie man ihn haben möchte,
wenn man fertig ist kann man ihn erstmal testweise mit Main Conzept rendern (es werden damit alle CPU Kerne mit 98% angesprochen und geht recht zügig auch minimal langsamer als X264).

Wenn der Film dann wirklich Final ist - wenn man mit dem Ergebnis zufrieden ist, könnte man das Projekt als uncompressed AVI Speichern (dauert leider sehr lange) und dieses wiederum danach mit Handbrake & X264 neu encoden - für die beste mögliche Qualität bei minimalen Platzverbauch.

Ein Nachteil ist aber die Größe:

Mein 5 Minuten AVCHD Clip war nur 5 Minuten lang ca. 1GB Groß. Die Umwandlung in uncompressed AVI dauerte unter 12 Minuten (3960X) - die Größe des AVI Files betrug 98GB !

Der Tip mit dem Frameserver ist gut - leider funktioniert das aber nur mit den 32 Bit Versionen von Sony Vegas.

Oder könnte man das Projekt in der 64Bit Version erstellen und - wenn final - in Sony Vegas 32-Bit Version öffnen und dort mit dem Frameserver/Megui rendern lassen?

Würde jetzt ungern die 32Bit Version von Vegas nutzen müssen (gerade weil man dafür 32GB RAM verbaut hat).

Zumal die 64Bit Version insgesamt stabiler laufen soll (lt.Vegas-Forum).

 

[maxwell-cs]

für vorläufige ansichten einen schnellen encoder verwenden, der nur auf geschwindigkeit und weniger auf effizienz achtet. ich kenn die einstellungsmöglichkeiten von MainConcept zwar nicht, aber schnellere voreinstellungen bietet der sicher. für ne vorschau braucht der sich ja nicht für ne besonders tolle effizienz anzustrengen.

 

[mvBarracuda]

Warum dann nicht einfach direkt den Weg über den Frameserver? Dann sparst du dir Zeit und Festplattenplatz. Frameservers aren't rocket science.

Einmal eingerichtet ist die Bedienung je nach Frameserver sehr einfach und man will die Arbeitsweise nicht mehr missen.