Um schreiben oder kommentieren zu können, benötigst du ein Benutzerkonto.
Du hast schon ein Benutzerkonto? Melde dich hier hier an.
Jetzt anmeldenHier kannst du ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen
Kenne Sony Vegas nicht, aber es könnte an deiner Bitrate liegen.
Vielleicht solltest du den Frameserver und MeGUI verwenden?
FullHD bezeichnet nur die Auflösung, nicht die Qualität. 
Und ja, einfach mehr Bitrate rein und schon sieht es besser aus. Alternativ könntest du auch einen besseren Encoder als MainConcept benutzen.
FullHD bezeichnet nur die Auflösung, nicht die Qualität.
Ja, das weis ich 
Aber die Bitrate sind so von YT vorgeschrieben gewesen deshalb :D. Danke euch
Ja, das weis ich
Ich glaube YouTube gibt da nur Vorschläge an.. dud arfst Vidoes rein technisch gesehen ja auch lossless hochladen.
Macht nur fast keiner, wegen den Dateigrößen. 
Slices schonmal nich nehmen, statt 4 auf 1, 0 wäre besser, aber geht ja bei dem programm nich
Keine Max Bitrate definieren. Level auf High und dann maximalwert einstellen, da auch dieses Feld bei dem Programm nich deaktivierbar ist.
Schnittbitrate würde ich locker aufs 3-fache anheben.
Die Auflösung sollte mind. 2048x1152 wenn auf Youtube von dem Video noch was über bleiben soll.
Ein besserer Encoder wie x264 wäre anzuraten.
Slices schonmal nich nehmen, statt 4 auf 1, 0 wäre besser, aber geht ja bei dem programm nich
Das ist recht uninteressant und hat keine Relevanz auf die Qualität der Bilder. Das hat was mit Hardware Player zu tun. Daher sollte auch auf BluRays 4 Slices verwendet werden, um die Frames entsprechend zu zerlegen. Hat also eher was mit Speicherverarbeitung zu tun. Für die Qualität irrelevant. Trotzdem auf 1 stellen, weil das setzen von Slices kann die Encodier Dauer erhöhen und senken somit natürlich Effizienz.
Aber die Bitrate sind so von YT vorgeschrieben gewesen deshalb
Das sind recht fantastische Richtangaben. Die kann man getrost ignorieren. Man muss also nicht 30 oder 50mbit irgendwo reinballern, obwohl das Video optimal mit weit weniger bei gleicher Qualität auskommt. Das Überflüssig und Ineffizient. Weil du somit einen erheblichen höheren Zeitaufwand betreibst.
Fixe Bitraten zu nutzen entpuppt sich bei jedem Spiel und Video als reines Ratespiel. Es gibt keine heilige feste Bitrate die Top ist. Höstens wenn man wirklich soviel wie möglich rein pumpt. Aber das ist ja wie gesagt Ineffizient.
Daher sollte man zwecks Qualität entweder mit Quantizer Angaben encodieren oder mit durchgängiger gleichbleibender Qualität. Weil dann werden die Bitraten optimierter für jedes Video und die Qualität ist bestens.
Sprich z.B. für Tetris z.B. hast du dann bei 1080p später nur 3000kbit/s und für Battlefront 1 geht es dann in die 40mbit oder whatever.
Nur du selbst musst keine Bitraten mehr angeben.
Wenn man mit fixen Bitraten encodieren sollte, sollte man unbedingt 2pass Encoding verwenden. Weil das die Qualität steigert. Hast damit aber relativ höheren Zeitaufwand und die Frage ob die Qualität top genug ist steht auch im Raum, je nachdem wie hoch die Bitrate eingestellt war.
Daher würde ich dir einen Encoder empfehlen der dir dieses Bitraten Gerate abnimmt. x264 kann z.B. in CRF kodieren. Da gibst du nur noch ein Faktor an. Das ist dann ein konstanter qualitätsbasierender Encode.
Oder wenn du es finden solltest: konstante Quantisierung. Das würde auch schon besser sein.
Ich habe in FULL HD gerendert mit den YouTube angegebenen bit raten.
Aber das Video sieht nicht FULL HD aus. Habt ihr irgendwelche Ideen?
Hier auch mal das Video -> klick
Das Video ist auf YT auch nur in 720p verfügbar. Sprich die Non-Dash Versionen. Verwende, sofern du wirklich 1080p hochgeladen hast, die Bildverbesserung auf YT. Ändere aber nix dran, sondern speicher es einfach nur neu. Das Video wird dann von YT neu verarbeitet und sollte dann mit etwas Glück auch in 1080p verfügbar sein. Dann sollte es auch etwas besser aussehen.
Ich soll also jetzt konstante Bitraten benutzen?
Nein, konstant wäre total ineffizient. Variable Bitrate ist schon etwas besser, aber noch besser wären zwei Durchgänge.
Falls ja weis ich nur nicht genau wie viel.
Das hängt halt davon ab, wie empfindlich du in Sachen Bildqualität bist - und wie viel Zeit du für den Upload einplanen willst. Da musst du schon den für dich besten Kompromiss rausfinden. Das ist halt das Ratespiel in Sachen Bitrate.
Ich rendere auschließlich mit Sony Vegas was muss ich denn da einstellen damit das Automatisch angepasst wird?
Variable Bitrate, zwei Durchgänge anhaken, Maximum wirklich auf Maximum und Durchschnitt auf die Zahl, die du noch bereit bist, hochzuladen. 
Ich soll also jetzt konstante Bitraten benutzen?
Wenn du den max wert auf max machst, limitierst du den peak nich mehr.
Je mehr du den max wert an den schnittwert annäherst, desto mehr rückst du jedoch einer konstanten bitrate näher. Und genau das wollen wir ja eben nich.
Das ist recht uninteressant und hat keine Relevanz auf die Qualität der Bilder.
Doch hat es:
Each slice adds some bitrate (or equivalently reduces quality), for a variety of reasons: the slice header costs some bits, cabac contexts are reset, mvs and intra samples can't be predicted across the slice boundary.
In CBR mode, multiple slices encode simultaneously, thus increasing the maximum misprediction possible with VBV.
Tested at 720p with 45 slices (one per mb row) to maximize the total cost for easy measurement. Averaged over 4 movies at crf20 and crf30. Total cost: +30% bitrate at constant psnr.
I enabled the various components of slicing one at a time, and measured the portion of that cost they contribute:
* 6% deblocking between slices (you don't strictly have to turn this off just for standard compliance, but you do if you want to use slices for decoder multithreading)
The proportional cost of redundant headers should certainly depend on bitrate (since the header size is constant and everything else depends on bitrate). Deblocking should too (due to varing deblock strength).
But none of the proportions should depend strongly on the number of slices: some are triggered per slice while some are triggered per macroblock-that's-on-the-edge-of-a-slice, but as long as there's no more than 1 slice per row, the relative frequency of those two conditions is determined solely by the image width.
Und da sie völlig unnötig sind, ist jeder kleinste Verlust unnötig. Der Verlust wird einem je nach Bitrate nich vom Hocker hauen, aber es ist dennoch Verlust.
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!