Du bist nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: Amateurfilm-Forum. Falls dies dein erster Besuch auf dieser Seite ist, lies bitte die Hilfe durch. Dort wird dir die Bedienung dieser Seite näher erläutert. Darüber hinaus solltest du dich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutze das Registrierungsformular, um dich zu registrieren oder informiere dich ausführlich über den Registrierungsvorgang. Falls du dich bereits zu einem früheren Zeitpunkt registriert hast, kannst du dich hier anmelden.

PlunChilla Prod.

unregistriert

1

Dienstag, 12. Oktober 2010, 14:28

After FX Intro 20 sec=1,5GB

Guten Tag liebe Leute!

Ich arbeite seit kurzem mit Adobe After Effects CS3 und habe aus dem Anlass einfach mal ein Intro (bzw. wie nennt man das eigentlich, wenn da halt der Name der Produktionsfirma auftaucht?wie bei 20Century FOX, MGM Films mit dem Löwen, etc.) gemacht.

Es ist recht simpel:
Einzelne Teile der Firma (mein Nick) kommen auf Schienen zusammengefahren, dann wird geschwenkt auf eine Metalplatte, wo "presents" reingepresst wird.

Alle teile sind mehr oder weniger mit Photoshop gemacht worden.

Allerdings ist der Clip nur 20 sec. lang und wenn ich ihn rendere ist die entstehende .avi 1,56GB groß und das ist ja irgendwie nicht normal für diese Länge.

Technische Daten vom rendering:

Spoiler Spoiler

Auflösung: 1280x720
Tiefe: 16,7 Mil. Farben
Alpha: Integriert
RGB Farbe
30 Frames
Qualität: beste
Auflösung: voll
Audio is auf 44hz

Falls ihr noch was wissen wollt, sagt es mir.

Der gerenderte Film sieht klasse aus...HD halt, aber er muss (im VLC-Player) immer wieder buffern. Der Film lässt sich also garnicht flüssig abspielen.

Es hat bereits 1 Gast diesen Beitrag als hilfreich eingestuft.

HTS_HetH

unregistriert

2

Dienstag, 12. Oktober 2010, 14:37

AE rendert standardmäßig halt unkomprimierte AVIs aus, daher die massive Dateigröße, bei1280x720 @ 30 fps kommt da schon was zusammen. Du musst halt ein anderes Preset wählen, wenn du es komprimieren willst für´s Web zum Beispiel. Häufig genommen wird h.264 oder WMV.

PlunChilla Prod.

unregistriert

3

Dienstag, 12. Oktober 2010, 16:43

ja, aber ich habe nun auch andere Filme auf dem PC, die über ne stunde lang sind, HD und trotzdem nur 4 GB dick sind.

Liegt es vllt. auch an den 16,7 Mio. farben?

Wie soll ich die den rendern, um den clip kleiner zu kriegen.

Selbst bei HD hatte ich so an ne maximale dateigröße von 50 MB gedacht...sind wie gesagt nur 20 sekunden.

freezer

Filmemacher / Postpro / FH Vortragender

  • »freezer« ist männlich

Beiträge: 1 637

Dabei seit: 21. Juli 2005

Wohnort: Graz, Österreich

Hilfreich-Bewertungen: 201

  • Private Nachricht senden

4

Dienstag, 12. Oktober 2010, 18:06

Ich empfehle Dir dringend, Dich in die Grundlagen der Videotechnik einzulesen:

http://de.wikipedia.org/wiki/Videoformat
http://de.wikipedia.org/wiki/Videokompression

Damit wird vieles klarer und Du bist in der Lage, die verschiedenen Ausgabeoptionen von AE auch zu verstehen und sinnvoll einzustellen.
Diese Arbeit kann Dir leider hier niemand abnehmen.
Robert Niessner - Planung / Kamera / Licht / Postproduktion
8010 Graz - Austria
Blackmagic Cinema Camera Blog

5

Dienstag, 12. Oktober 2010, 20:02

Rechnen wir mal:

es wird der volle RGB-Farbraum benutzt, also 0-255 (1 byte) pro Farbkanal, macht bei Rot, Grün und Blau also 3 Byte Speicher pro Pixel,

Für einen Frame (1280x720 = 921600 Pixel) benötigt man also 2764800 Byte

Jetzt noch die Anzahl der Frames: 30fps*20 = 600

3.686.400 * 600 = 1.658.880.000 Bytes

Was laut Google 1.54495 GB entspricht.

Passt doch, oder? ;)

PlunChilla Prod.

unregistriert

6

Mittwoch, 13. Oktober 2010, 00:03

vielen Dank schonmal für die Antworten!

Der Wikipediaartikel über die Videokompression ist schonmal harter Tobak und dass ich das ganz verstanden hab, kann ich nicht behaupten.

Nun wollte ich also das Video in MPEG2 Blu-ray rendern, da MPEG2 ja platzsparend ist.
Aber wenn ich das Format darauf einstelle, sagt er mir:
Es konnte kein Writer geladen werden. Adobe Media Encoder wird nun beendet.

Was habe ich denn nun schon wieder falsch gemacht.
Das gleiche sagt er auch, wenn ich es in Microsoft DV PAL 48 khz rendern will.

freezer

Filmemacher / Postpro / FH Vortragender

  • »freezer« ist männlich

Beiträge: 1 637

Dabei seit: 21. Juli 2005

Wohnort: Graz, Österreich

Hilfreich-Bewertungen: 201

  • Private Nachricht senden

7

Mittwoch, 13. Oktober 2010, 10:38

Der Wikipediaartikel über die Videokompression ist schonmal harter Tobak und dass ich das ganz verstanden hab, kann ich nicht behaupten.


Kann ich verstehen. Man braucht ein paar Monate Erfahrung mit Videotechnik, bis man sich besser in der Materie auskennt.

Du kannst Dir Kompression mit Hilfe folgender Analogie vorstellen:

Du hast 2 Personen A und B an unterschiedlichen Orten. Beide haben eine Schachtel mit unterschiedlichst eingefärbten, quadratischen Legosteinen, vor sich liegen.
Person A legt nun sein Lego nebeneinander (256 x 256 Steine) auf einer Fläche so aus, dass ein rasterartiges Bild (zB eine Landschaft) ensteht (wie beim Sticken).
Er möchte nun per Telefon die Person B so anleiten, dass sie das gleiche Bild auslegen kann.
Dazu unterteilt A sein Bild in horizontale und vertikale Koordinaten (X/Y) und definiert jede Farbe (RGB) mit einer dreiteiligen Zahl. Der blaue Stein rechts oben hat also X=1/Y=1/RGB=000.000.255.
Damit B nun das Bild exakt nachbilden kann, muss A nun immer die Koordinaten und die dazugehörige Farbe über das Telefon ansagen. Das dauert natürlich sehr lange. Um die Zeit abzukürzen versucht A nun ein wenig die Durchsagen zu optimieren. Die ersten 20 Zeilen bestehen nur aus blauen Steinen (Himmel), daher gibt er durch: Von X=1/Y=1 bis X=256/Y=20 nimmst Du RGB=000.000.255.
Damit schrumpft die benötigte Information auf unter 1/5000-stel, trotzdem kann B genau nachvollziehen, wie er die Steine bei sich aufzulegen hat.
In den nächsten Zeilen wechseln sich unterschiedliche Farben ab, daher gibt A immer zuerst eine Farbe und dann alle dazugehörigen Koordinaten durch, dann die nächste Farbe mit Koordinaten usw. usf. Hier sinkt die Effizienz, aber er spart sich immerhin 1/3.

Das würde in der Bildkompression nun einer verlustfreien Kompression entsprechen - gleich wie auch zB das ZIP/RAR/PNG/HuffYUV/Lagarith Verfahren für Dateien abläuft. Die Kompressionsstärke ist natürlich beschränkt.

Möchte man stärker komprimieren, dann muss man tiefer in die Trickkiste greifen und auch leichte Bildinhaltänderungen in Kauf nehmen.
Umgelegt auf obige Analogie würde das bedeuten, dass A bspw. ähnliche Blautöne im Himmel als gleich definiert und so effizienter die Koordinaten durchgeben kann. Er könnte auch noch die Farbgenauigkeit reduzieren zB statt 000.000.255 für Blau sagt er 00.00.16 - was natürlich die Anzahl der möglichen Farben einschränkt.

Das wäre dann eine verlustbehaftete Kompression, das Bild, welches B zusammensetzt entspricht nicht mehr 100% dem von A, sondern es weicht ein wenig davon ab. Je effizienter A sein Bild zusammenfasst, desto stärker wird Bs Bild vom Original abweichen.

Bisher haben wir dabei immer nur 1 Bild betrachtet.
Was wäre, wenn A und B nun beschließen, eine ganze Serie von Bildern hintereinander zu machen und dabei die Bildinhalte von Bild zu Bild leicht zu verschieben - quasi animieren. Nehmen wir an, es gibt eine runde gelbe Sonne. A müsste nun wieder die Daten für die Sonne B durchgeben, damit dieser sie exakt an der gleichen Stelle, Bild für Bild, positionieren kann. A erkennt bald das Optimierungspotenzial: Er muss B lediglich die sich im jeweiligen Bild geänderte Gesamtposition der Sonne angeben. D.h. er betrachtet die Sonne nicht mehr als einzelne Legosteine mit Koordinaten und Farbe, sondern als ein Objekt, mit einer Koordinate und Farbe. Somit muss B nur beim ersten Bild wissen, wie er die Sonne aufzubauen hat, bei dem nächsten Bild kann er sich die Struktur vom ersten Bild abschauen, lediglich die Platzierung im Bild ändert sich.

Das ist das Grundprinzip einer MPEG Kompression, stark vereinfacht natürlich.

Nun wollte ich also das Video in MPEG2 Blu-ray rendern, da MPEG2 ja platzsparend ist.
Aber wenn ich das Format darauf einstelle, sagt er mir:
Es konnte kein Writer geladen werden. Adobe Media Encoder wird nun beendet.

Du hast natürlich nicht den Fehler gegoogelt, oder? Sonst wärst Du darauf gestossen, dass es ein Update für CS3 gibt, dass Du installieren musst.
http://www.adobe.com/support/documentati…_3_1_ReadMe.pdf

Adobe Premiere Pro CS3 3.2 update
Adobe After Effects CS3 Professional 8.0.2 update
Robert Niessner - Planung / Kamera / Licht / Postproduktion
8010 Graz - Austria
Blackmagic Cinema Camera Blog

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »freezer« (3. November 2010, 12:23)


Es haben bereits 1 registrierter Benutzer und 4 Gäste diesen Beitrag als hilfreich eingestuft.

Benutzer, die diesen Beitrag hilfreich fanden:

Joshi93

PlunChilla Prod.

unregistriert

8

Donnerstag, 14. Oktober 2010, 13:49

Wow, vielen dank freezer für die Erklärung!
Nun versteh ichs wenigstens ein bisschen.

Gegoogelt hatte ich die Fehlermeldung, allerdings anscheinend nicht gründlich genug.(Blöde Ungründlichkeit! Schande über mein Haupt!)
Da wurde den Leuten immer geraten, das mit Premiere zu rendern und andere verquere Lösungen.
Das mit dem Update is wohl irgendwie nicht ganz glatt gelaufen. Mit MPEG funktioniert es nun immernoch nicht!
Auf jeden Fall hab ich die 1,56 GB datei nun auch mit meinem Cuttingprogramm rendern lassen und nachbearbeitet und siehe da:
Eine 30MB große mpeg-Datei mit klasse Bildqualität.

Vielen dank euch allen!
Werd da nochmal bei Adobe nachfragen wegen dem Update, aber vorerst hab ich ja eine Lösung.

9

Samstag, 16. Oktober 2010, 12:17

@freezer:

Wenn die "Bedanken"-Funktion, wird sie für deinen letzten Post benutzt. Selten so eine schöne Veranschaulichung gesehen :thumbsup:
Geht jetzt zwar ein bisschen mehr in die Materie rein, aber kannst du mir zufällig beantworten, wie genau die Koordinaten (zB bei png) abgespeichert werden?

Bei bmp/unkompromierten material kann man stur die Farbwerte nebeneinander aufschreiben, bei einem 3x3 px bild dann zB so (vorrausgesetzt, es wird von oben links nach unten rechts gearbeitet)

bmp:
000/000/255, 000/000/255, 000/000/255;
000/255/255, 255/000/255, 000/255/255;
255/000/255, 255/000/255, 255/000/255;

als png dann so?
000/000/255 = 1/1 , 1/2 , 1/3;
000/255/255 = 2/1 , 2/3;
255/000/255 = 2/2 , 3/1 , 3/2 , 3/3;

bei bmp wären es 27byte. (216 Bit)
als png bräuchte man 9byte für die farben, wie genau weren die koordinaten abgespeichert? in meinem beispiel würde 2Bit pro Zahl reichen, was 36 Bit für Koordinaten machen würde. (insg. 108 Bit);
Kann der Speicherplatz für die Koordinaten dynamisch gewählt werden oder ist der Datentyp (=Speicherbedarf) festgelegt?


@PlunChilla:
An den "16,7 Mio. Farben" sollte man gar nichts ändern, das ist der Farbraum, der mit 8Bit pro Farbkanal dargestellt werden kann (256^3), und selbst das ist im vergleich dazu, was unser Auge wahrnehmen kann, recht wenig. (nicht umsonst gibt es HDR-Imaging, mit 32 oder 24 statt 8 Bit).

JoshSanderson

unregistriert

10

Mittwoch, 3. November 2010, 12:13

Ich kann nur meine besten Empfehlungen für den QuickTime Container mit einem H264 Codec aussprechen.

Der Qualitätsverlust hält sich in äußerst annehmbaren Grenzen.

Solltest Du die Einbindung des Alphakanals (also die Transparenz) benötigen, schalte den Codec auf "Animation".

Ich würde zu solchen Zwecken von unkomprimierten AVI abraten, da es wirklich unnötig große Dateien erzeugt.

Thom 98

unregistriert

11

Mittwoch, 3. November 2010, 14:04

h.264 ist ein exzellenter Codec fürs finale Render, wenn man den Film dann online stellen will oder archivieren will. Während der Postproduktion sollte man fürs Zwischenrendern davon absehen und stets verlustfreie Codecs verwenden. Animation ist in Ordnung, Lagarith und Huffyuf sind ebenfalls gute Alternativen. Oder man nutzt eben Einzelbildersequenzen. TIFFs haben sich in meiner Erfahrung bisher am günstigsten herausgestellt und laufen mit Premiere Pro auch in FullHD flüssig in der Timeline.

PlunChilla Prod.

unregistriert

12

Dienstag, 16. November 2010, 17:32

ok, also das mit der größe ist nun nicht mehr so wahnsinnig das Problem, da ichs nun ja letztendlich flüssig als .mpeg abspeichern kann.

Allerdings habe ich nun das Problem,dass das Programm selbst teilweise ewig zum rendern braucht.

Da ich noch keine wirklich gute Cam hab (kommt hoffentlich zu weihnachten), spiele ich bei AE immoment nur mit effekten und erstelle ein paar animierte Intros (weiß immernoch nicht, wie das richtg heißt^^)

Also immoment habe ich was einfaches:


(Im 3D-Raum) Name: Keksfilm
Schrift vor weißer Wand, cam fährt durch schrift durch und filmt den schatten.
Dann wird etwas von der schrift abgebissen, was halt nur im schatten zu sehen ist.
Das mit dem abbeißen hab ich mit ner Maske gemacht.

Als ich das nun mal durchrendern wollte, ums mir zwischendurch mal anzusehen, hat er nach 6 Minuten erst 1,5 von 10 Sekunden durchgerendert.
Sowieso stockt er seit der maske und der Kamerafahrt extrem, sodass ich kaum noch daran arbeiten kann.

Auflösung ist 1280*720 bei 25 Frames pro Sekunde.

Wenn ich nun mit meiner alten Kamera filme drehe und darin mit Effekten wie blitzen, anderen videos (muzzle flashes,explosionen, etc.), Masken und allem möglichen Kram rumspiele, hat er damit keine großen Speicherprobleme.
Also müsste es ja an der Kamerafahrt, dem 3D-Raum oder beidem liegen.
Aber wie bekomme ich es denn hin, dass ich die trotzdem gut bearbeiten kann.

Mein Recher ist nun 2 Jahre alt, aber eigentlich noch ziemlich gut:
Intel Quad-Core mit 2,81 Ghz pro Kern.
4 Gb DDR2 Ram
ATI Radeon HD4830 mit 512 MB
Genug festplattenspeicher^^

JoshSanderson

unregistriert

13

Samstag, 27. November 2010, 22:03

@PlunChilla

Spontan würde ich sagen, das Problem liegt in der Schattenberechnung.
Wenn du lediglich Effekte auf bereits bestehendes Material legst, müssen dergleichen nicht berechnet werden.

Entweder die Glättung oder auch "weiche Schattenkanten" reduzieren, komplett weglassen oder mit langer Renderzeit leben. :)

An die müsste man sich ohnehin irgendwann einmal gewöhnen.

Ähnliche Themen

Social Bookmarks