Hallo,
ich suche ein Schnittprogramm, mit dem man Dv-Avis zu DV-Avis ohne Neuberechnung/Rendern schneiden kann. Das Programm soll also nur Teile aus verschiedenen Videoclips zusammenkopieren, die Video- und Audiodaten also nicht verändern. Außerdem sollte dabei eine Nachvertonung möglich sein. Welche Programme können das? Können das solche Programme wie zb. Pinnacle Studio, Ulead oder Premiere?
Vieln Dank im Voraus
Masc
soviel mir bekannt ist, wird bei allen Programmen nur bei Effekten (incl. Übergangseffeten) der betroffenen Bereich neu gerendert, ansonsten praktisch nur kopiert. Allerdings wirkt eine Nachvertonung oder auch Pegelveränderung auch wie ein Effekt, wird also auch - spätestens bei der Ausgabe - gerendert.
Ich mache das mit dem alten Pinnacle Liquid 5.62 . Mußte mal gesagt werden, weil alle Welt nur immer nur Pinnacle Studio, Ulead oder Premiere nennt/kennt ;-)
thos-berlin hat geschrieben:Allerdings wirkt eine Nachvertonung oder auch Pegelveränderung auch wie ein Effekt, wird also auch - spätestens bei der Ausgabe - gerendert.
Berechtigter Einwand, da ich selbst jetzt auch wieder unsicher bin, ob das Bild neu berechnet wird, wenn nur der Ton geändert wird.
Bei dem Verhalten, das mein Ulead an den Tag legt, ist dem eher nicht so, will sagen, es findet kein Rendervorgang in dem Sinne statt, daß das Bild neu berechnet wird, sondern eben nur der Ton (auspacken, "verändern", neu einpacken).
Wenn es also um die Qualität des Bildes geht, dürfte sich da nix ändern. Und auch die Tonqualität bleibt davon recht unbeeindruckt, da es sich bei Ton in DV um unkomprimiertes PCM handelt, so daß bei der Bearbeitung keine Information durch Kompression verloren geht.
Sollte das so nicht sein, bitte berichtigen
Gruß
Stefan
Das Problem sitzt meist 50 cm vor dem Monitor
Was man sich selbst erarbeitet hat, bleibt besser im Gedächtnis als das, was man sich nur passiv angeeignet hat.
Also mein Magix-VDL habe ich auch im Verdacht, überall dort, wo nur der Ton geändert wurde, alles neu zu rendern. Persönlich umschiffe ich das Problem, indem ich zunächst den Schnitt nebst Überblendungen durchführe ( letztere Abschnitte werden natürlich neuberechnet), und dann als DV-Avi abspeichere; anschließend erfolgt die Bearbeitung der Tonspur(en), deren Resultat wiederum als Wave-Datei exportiert wird. In einem weiteren Schritt tausche ich dann mittels Vdub oder Avi-Mux GUI den Orginalton gegen den bearbeiteten.
thos-berlin hat geschrieben:Allerdings wirkt eine Nachvertonung oder auch Pegelveränderung auch wie ein Effekt, wird also auch - spätestens bei der Ausgabe - gerendert.
Das stimmt zwar, aber das Bild bleibt davon völlig unberührt. Audio-Rendern dauert nur ein paar Sekunden, das bekommt man gar nicht mit, wenn man nicht speziell darauf achtet.
Man kann es leicht ausprobieren: ein Video in die Timeline legen, am Bild selbst nichts verändern, aber den Ton kräftig manipulieren. Beim Export (als DV) wird ein z.B. 15 min langes Video in etwa 3 min auf der Festplatte liegen - mit völlig unangestastem Bild.
Zumindest bei mir ist das so. Ich spreche von APPro.
Gruss Wiro
Fast alle Schnittprogramme können DV Avi 1:1 neu abspeichern (Auch Pinnacle Studio). Wie oben schon gesagt werde lediglich Blenden neu berechnet. Ton spielt zumindest bei DV Avi Typ 2 keine Rolle.
... also, ich möchte hier keine neue Diskussion vom Zaum brechen aber ich habe in Bezug auf den "native" Schnitt eine Recherche bei den Herstellerfirmen für mein Buch hinter mir, die folgendes Ergebnis hat, sich aber zunächst einmal auf MPEG bezog und nicht auf DV.
Nach den Angaben der Hersteller heist "nativer" Schnitt nichts anderes, als dass kein FREMDER Codec zur erneuten Herstellung eines Exportstromes benutzt wird.
Bei allen Programmen (ausser Thomson EDIUS 4.5) wird im "native" Codec der Exportstrom ausgerechnet ... schon aus Timing-Gründen ist dies nicht anders möglich, weil auch beim Schnitt zwischen den GoPs (mehrere GoP´s werden herausgenommen), ein durchgängiges Timing erzeugt werden muss.
Thomson hält (mit) die Patentrechte für Transcodierverfahren nach dem so genannten MOLE Verfahren und übergibt u.A. Listeninhalte der Macrobröcke in den neu gepackten Exportstrom.
Dies ist "echtes" Transcoding und ermöglicht beispielsweise auch die Schnitte unterschiedlicher GoP Strukturen.
Selbstverständlich werden auch hier Übergänge und Bearbeitungen über einen "internen" Codec durchgeführt und im native-Codec dann wieder encodiert.
Man hat also IMMER eine Folgegeneration beim Ausspielen, aus dem Rechner, bei Bearbeitung über einen fremden Codec dann eben zwei Generationen.
Bis auf EDIUS 4.5 , bei dem durch das beschriebene Verfahren lediglich ein neuer Multiplex auf PS-Ebene stattfindet trifft es also nicht zu, dass der Ausgangsstrom unverändert dem Eingangsmaterial entspricht.
Da MPEG ein Schätzungsverfahren ist, kann es also durchaus vorkommen, dass, abhängig vom benutzen Encoder der Software, die Schätzungen anders ausfallen, als im ersten Encoding (der Kamera).
Da es sich bei DV ebenfalls um ein DCT basiertes System handelt, gehe ich von der analogen Gültigkeit aus.
Also: "native" heist nichts anderes, als dass ein identischer Codec benutzt wird, nicht aber, dass das Material nicht neu encodiert wird.
Hallo,
mein Verständnis von einem nativen Schnitt ist etwas anders. Nativer Schnitt bedeutet für mich, daß mit dem gleichen Codec EDITIERT wird, in dem auch das Quellfootage vorliegt. Will heißen:
Quelle = DV, Projekteinstellung ebenfalls DV = nativ.
Quelle = MPEG2, Projekteinstellung = DV = nicht nativ.
Quelle MPEG2, Projekteinstellung = MPEG2 = nativ (wie es z.B. beim MPEGPro-Plugin der Fall ist).
Meinem Verständnis nach hat das mit dem Export nichts zu tun. Ich kann sehr wohl nativ in DV editieren, final aber als WMV (MPEG4) oder MPEG2 (DVD) ausgeben. Dennoch bleibt die Bearbeitung nativ.
Wie auch immer - im vorliegenden Fall kann ein nativer DV-Stream ohne jede Neuberechnung exportiert werden, da es sich um einen intraframecodierten Stream handelt. Darum dreht sich ja die Eingangsfrage.
Gruss Wiro
Bei DV Schnitt ist es unerheblich wo ich schneide, da alles aus Vollbilder besteht. Daher wird auch nicht neu kodiert.
bei mpg wird sicher auch innerhalb einer GOP geschnitten was eine neue kodierung erforderlich macht. Denn noch gibt es einen Nativen Transfer für mpg auf den PC, aber nach dem Schnitt und erneuter Ausgabe ist es halt nicht mehr nativ.
... unser Verständnis deckt sich in Bezug auf die "native" Verwendung durchaus und ich muß zugeben, auch auf diese Frage erst durch solche "Allgemeinbezeichnungen" wie "native" oder "smart-Rendering", die eigentlich völlig nichts sagend sind, aufmerksam geworden zu sein. Ich habe mich daraufhin mit den Herstellern unterhalten und eigentlich die Bestätigung bekommen, die ich schon vermutet habe. (Apple hat mich sogar auf eine kleine Zeichnung in ihrer Broschüre hingewiesen, wo sie ganz eindeutig sagen, dass jedes Ein-und wieder Ausspielen aus dem System, selbst ohne Schnitt eine Generation bedeutet.. Betonung liegt auf AusSPIELN, also Exportieren)-(keine Filekopie). Auch beinhaltet der Codec ja unterschiedliche Pakete, die immer "ausgepackt" werden und anschließend mit einem gemeinsamen, in sich fortlaufenden Timing wieder paketiert werden. Nur so ist ein Strom, egal ob PES oder TS überhaupt lesbar.
Nun bezieht sich dies zunächst mal auf MPEG --- und nachfolgend AVC natürlich, aber DV ist im Grunde genommen nicht so unterschiedlich ... ausser dass es eben I-Frame only ist und ein paar andere Tools zur Anwendung kommen.
Und dein Verständnis widerspricht dem nicht, bis auf den Umstand, dass beim Export auf jeden Fall (und immer) Encodiert wird, ob nun im native Codec, in dem Du selbstverständlich auch schneiden kannst, (in DV oder dem Derivat DVCPro sogar ohne Intermediate) oder ob Du in einen beliebigen andern Codec überführst.
Und Du hast auch recht, wenn Du sagst, dass dann die Bearbeitung "native" bleibt ... aber eben ein neues Encoding und ein neuer Multiplex.
Und daher, um auf die Eingangsfrage zurück zu kommen, kann es durchaus sein, dass das Bild anders aussieht, als das, was eingespielt worden ist. (Technisch gesehen muss es sogar etwas Anderes sei) .. aber ich gebe den Praktikern natürlich völlig recht, dass das unerheblich sein kann, wenn man es nicht sieht.
Mir ging es für mein Buch nur wirklich darum zu klären, was nun Wahrheit und was Werbung ist. Und die Firmen sagen alle, nirgendwo behauptet zu haben, dass die Files unverändert bleiben. Sie reden gern von "lossless", überlassen aber die Interpretationen diese Terminologien gern den Konsumenten, wohl wissend, dass der nur das darunter versteht, was er verstehen möchte.
Ich habe noch aus alten MPEG-Zeiten ein "Stress-Tape", das die Uni-Braunschweig mal für Rohde & Schwarz entwickelt hat.
Damit lässt sich jede neue Generation identifizieren ... Das wird dann der nächste Test und die praktische Beweisführung werden ... aber das dauert noch ein paar Tage.
.... bei DV will ich mich nun nicht verbürgen, obwohl ich nicht den riesen Unterschied sehe (wie beschrieben).
Aber "native" ist es hinterher immernoch ... denn "nativ" heist nichts anderes als : "in keinem andern Codec".
Wenn Du also MPEG2 einspielst und MPEG2 wieder ausspielst ist das nach der definition der Softwarehersteller "NATIVE"
... nur hat es nichts mehr mit den ursprünglichen Encoding Algorithmen zu tun.
Und warum sollte das bei DV (I-Frame only) anders sein ... wie kriegst Du sonst ein kontinuierliches Timing (ohne Jitter) hin ??
O.K.
Also sagen wir mal das Nativ bedeutet das der gleiche Codec verwendet wurde.
Beim Dv Codec ist es aber doch so, das durch die I Frame only, keine erneute Kodierung beim reinen Schnitt des Bildes durchgeführt werden muß.
Bei mpg wird ja die GOP gleich mit übertragen , also liegt die GOP schon fest. Machst Du einen Schnitt muß die Software an dieser Stelle ein neues I Frame berechnen und alle nachfolgenden P und B Frames.
Das verändert die Qualität, denn das neu I Frame ist ja aus P und B Frames entstanden. Bei einmaligem Schnitt im HDV habe ich selbst keine Verluste gesehen. Aber ich glaube schon das nach mehrmaligen Schnitt der Bildfehler zunimmt.
Hallo Udo ...
Es gibt eigentlich 2 Probleme:
Das erste Problem ist, dass ein Schnitt ja von irgendwo bis irgendwo geht. Dass also die Übergänge über einen Intermediate gerendert werden ist klar. Nur ist ja nicht sicher, dass am Ende der Blende auch das letzte P Frame steht und es dann an ein (nennen wir es mal) Original I-Frame anschliessen kann. Was bedeutet das ? Die darauf folgende GOP muss also auch aufgelöst werden, um nahtlos an das letzte bearbeitete Frame anschliessen zu können und weil alle GoPs immer die gleiche Länge haben ... geht das so weiter.
Der Rechner legt aber lediglich den Schnitt und das Zwischengerenderte ab und führt die Batches beim Export aus. Daher kannst Du auch ohne grosse Wartezeit weiterarbeiten.
Bei DV, das stimmt, stellt sich dieses Problem nicht ... gleichwohl müssen alle Timing information in die Struktur um den Payload herum.
Da es sich bei den Bildern ja lediglich um Rechenanweisungen, also Tabellen von Koeffizienten für die Makroblockkoordinaten, DCT-Typ für jeden Makroblock, Schrittweite der Quantisierung, Gewichtungsmatrix usw.usw handelt, die lediglich dem Decoder die Anweisung geben, was er zu machen hat, kann es sein, dass sie bei DV ohne Veränderung zu mappen sind ... aber wie gesagt, da würde ich nicht bei jedem hersteller die Hand für ins Feuer legen, weil das Encodieren einfacher ist als ein aufwendiges Mappen ...
Nur, Du hast völlig recht, das stellt sich in I-frame only erheblich leichter dar. Daher würde ich das hier bezüglich DV mal offen lassen.
Es gibt nur eben ein weiteres Problem, dass man auch nicht ganz vergessen darf. Solche Transcodierverfahren sind alle Patent-geschützt und deshalb greift so mancher Softwarehersteller eben lieber zum Ecoder als die Lizenzkosten zu zahlen. Zumal man ja wirklich bei den ersten Durchläufen auch keinen Unterschied sieht. Nur das sollte die Anwender nicht davon abhalten zu wissen, wie ihre Software funktioniert ... und vor allem auch so Bezeichnungen wie "lossless" oder eben "native", aber auch Begriffe wie "transparent" einmal wirklich einzuordnen, die gern zum Verkauf benutzt werden und wo die Firmen gern in Kauf nehmen, dass sie wohlwollend interpretiert werden.
Aber wie ich schon gesagt habe, manche interessiert auch nur, das das Bild anschliessend gut aussieht ... das ist auch völlig in Ordnung. Aber falsch kann es nicht sei, zu wissen, wie es entsteht ...
Die Frage ist ein bisschen akademisch, da man DV, wenn man es schneiden will, nun einmal umkopieren muss. Findet eine Neuberechnung statt oder wird nur mit neuem TC-Register kopiert? Ich wüßte nicht, warum auch nur ein einziges Pixel in Position, Chroma und Luma verändert werden sollte. Zudem hat wohl jeder die Beobachtung gemacht, dass eine Sicherung des kompletten Films nur mit harten Schnitten nicht länger dauert als eine Kopie, wohingegen Rendern mehr Zeit benötigt.
Na und? Im Fernsehen wird ja auch alles wiederholt ...
... also die Zeit würde ich da nicht als Faktor nehmen...
Es gibt vielmehr ganz pragmatische Gründe dafür.
Denn die Handhabung des DV Codecs richtet sich nach dem Blue-Book. Das aber läßt (ganz bewußt) die Ausführungsbestimmungen offen, wie- und welcher der DCT Modi benutzt wird. Die ist ganz absichtlich so gemacht worden, um den unterschiedlichen Firmen die Möglichkeit zu geben, eigene Algorithmen zu implementieren, die dem Decoder signalisieren, welcher DCT Mode in use ist. Das Umschalten zwischen unterschiedlichen DCT Modi gibt aber dem Decoder eine harte Zeit und führt unweigerlich zu Artefaktbildung.
Weil ein Schnittprogramm aber nun mal aus der Natur der Sache heraus bei Schnitten und bei Bearbeitung einen eigenen (immer proprietären) DCT Algorithmus einfügen muss, der aber mit großer Wahrscheinlichkeit nichts mit dem (proprietären) Algorithmus der Kamera nichts zu tun hat, wird sich kein Softwarehersteller auf solche Experimente einlassen, weil an den Übergängen (bei der Umschaltung der Modi) Artefakte entstehen (nicht müssen, aber können). Das fällt zunächst einmal als Fehlfunktion auf den Softwarehersteller zurück ... Warum sollte er das Risiko eingehen ? Er muss ohnehin einen Encoder implementieren, warum sollte er also ein aufwendiges Mapping machen, noch dazu, wenn seine eingefügten Teile sich aufgrund der eigenen Algorithmen vom Originalmaterial unterscheiden .... dann doch lieber ein einheitliches Encoding ... und wie gesagt, bei DV läuft das ohnehin in Echtzeit beim Ausspielen ab.
Und, wie gesagt, jeder Hersteller m u s s seine eigenen Algorithmen einbringen, gerade weil Blue-Book sie bewusst nicht spezifiziert, um die Alleinstellungsmerkmale der Hersteller gewährleisten zu können.
Du siehst, es gibt da ganz gute und auch pragmatische Gründe... und nicht wirklich akademisch ...
Was heißt das denn jetzt im Endeffekt? Wenn man DV wieder als "DV-AVI" ausgibt, findet keine Neuberechnung, sondern nur ein Schnitt statt?
Auch mit dem Movie-Maker bzw. der Importfunktion in Vista?
Ich weiß z.B. von einem extra Programm (wie hieß das?), dass Mpeg2-Videos ohne Neuberechnung befreit von z.B. Vorläufen, Nachläufen und Werbung speichert. Das merkt man auch an der Geschwindigkeit.
Beim MovieMaker bin ich nicht ganz sicher, auch/gerade wenn es schnell geht.
Ich wollte nur ein paar importierte Schnippsel auf das wesentliche Kürzen.
Also z.B. 15:40m auf 1m. Spart Speicherplatz.
Beim Erstimport in MM trennt der noch in Clips. Das gesicherte DV danach nicht. Da muss man die Szenenerkennung aktivieren.
Bezüglich anderer Formate habe ich irgendwann mal in Forschung-Aktuell oder evtl. der Computersendung die zur gleichen Zeit Samstags läuft gehört bestimmte bzw. ein bestimmtes Schnittprogramm würden generell (bei Ausgabe im gleichen Codec) nur an Stellen Neuberechnen wo Effekte, Überblendungen usw. liegen.
Sehr nützlich z.B. bei AVCHD. Das Format ist ja zugleich auch Endformat, z.B. für BlueRay-Discs.
Es wäre zugleich Verlustfreie Weiterverarbeitung, aber würde auch sehr viel Zeit sparen. Zwei immer wieder von den Bemänglern hochgehaltene Nachteile die sich in Vorteile wandeln.
Am besten ist es doch, wenn die Kamera gleich in den Format aufnimmt in dem man es auch nach dem Schnitt ansieht. Natürlich darf nur an manipulierten Stellen neuberechnet werden.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.