Hallo,
ich versuche seit Monaten eine Videoschnittsoftware zu finden, die nur die mit Effekten versehenen Bereiche meiner AVCHD Dateien neu rendert. Sämtliche bekannten Softwareprodukte (z.B. Nero Vision, Corel X3, Sony Vegas Pro, ...) bekommen das nicht hin bzw. liefern fehlerhafte Artefakte an den Schnittstellen.
Wie ich bisher gelesen haben liegt das an den vielen, nicht einheitlichen Reihenfolgen der GOP-Struktur?
Was sind eure Erfahrungen? Ich habe es mit zwei verschiedenen Kameras (aktuelle: Sony Cx505) versucht und bei Beiden hat es nicht funktioniert.
Die einzigen die mir eine kompettente Antwort im Support gegeben haben waren die Leute von Sony Vegas Pro. Die meinten das Problem wäre bekannt und sie würden an einem Bugfix arbeiten. In der neuen Version haben Sie das Smart Rendering für AVCHD jedoch einfach entfernt.
Sony Vegas Pro 9 hat nie das Smartrendern von AVCHD offiziell unterstützt - dass es bis 9c ging, und auch nur mit dem Material einiger Camcorder, war nett - ist aber mit 9e offenbar weg. Aber grundsätzlich hat der Sony AVC Encoder eine gute Qualität - aber das Rendern dauert halt seine Zeit.
Vielleicht könnte dir der Powerdirector von Cyberlink helfen? Der ist da relativ gut.
Smartrendern ist nicht Nichtrendern. Es ist genau im Gegenteil ein besonders rigoroses Neuberechnen, um an Schnittstellen verloren gegangene Informationen aus früheren oder späteren Frames in die verbleibende Struktur zu integrieren (mehr oder weniger erfolgreich). Wäre Smartrendern gleichbedeutend mit Kopieren ohne Neuberechnung, käme es in der Tat zwangsläufig zu Fehlern an den Schnittstellen. Daraus folgt aber, dass vormals für harmlos gehaltene Schnitte, das bloße Trimmen und Zusammenfügen des Footage, einen Verlust von Originalinformation bedeutet, bei der man nur darauf vertrauen kann, dass sie durch die Güte des NLEs nicht sichtbar wird. Aber eine zweite Neuberechnung, auf der bereits datenverfälschten ersten aufbauend, wird nicht mehr smart sein können.
Glaube nicht, dass das so generell stimmt. Bei Womble z.B. geht das Smartrendern deutlich unter Originallaufzeit vor sich, nur bei den Schnittstellen merkt man, dass ev. zwei Gops neu berechnet werden, dort verweilt er etwas länger.
Bei PS und Liquid geht das Smartrendern in etwa 1:1 vor sich, hier muss wohl noch der vorher separarierte Ton eingemuxt werden.
Beide Geschwindigkeiten legen aber nahe, dass das Bild selbst nicht neu codiert wird, das würde wesentlich länger dauern.
>Vielleicht könnte dir der Powerdirector von Cyberlink helfen? Der ist da relativ gut.
Powerdirector schaltet das Smartrendern (SVRT) nicht frei, verrät aber nicht was ihm nicht an den Dateien passt...
>Smartrendern ist nicht Nichtrendern
Das ist mir bekannt, bei AVCHD müssen bis zu 8 Sekunden bei der Schnittkante neu berechnet werden und in den Stream integriert werden. Ändert aber nichts am Ergebnis, es funktioniert nicht vernünftig.
Das, was landläufig als "Smart rendern" bezeichnet wird, setzt zwingend eine GoP Struktur voraus. AVC hat keine Gop Struktur mehr. Die Bilder werden in Slices aufgeteilt. Ein Slice ist eine Sequenz von Makroblöcken und (kann) entspricht lediglich einem Bildbereich, der unabhängig von den anderen Bereichen des Bildes decodiert werden kann- oder wieder in Gruppen zusammengefasst- und so im Speicher abgelegt werden, dass sie auch als Langzeit Referenz dienen. Damit gibt es keine systematische Entscheidungsmöglichkeit mehr für "smart rendering".
Auch das, was als "smart MPEG" bezeichnet wurde, gibt es in AVC nicht mehr.
demnach wird es nie sowas wie "Smart Rendering" für AVCHD geben?
nach einem Artikel im Netz könnte man bei IDR Frames schneiden, das wäre für mich akzeptabel, hauptsache eine 2 Stundenaufnahme wird nicht komplett neu gerechnet nur weil man am Anfang einen Titel eingefügt hat.
Auszug:
"MPEG-4-AVC bietet weitaus mehr Kodierungsparameter als MPEG-2, da es effizientere Kompressionsalgorithmen bietet, aber auch Profile z.B. für mobile Geräte, sodass das Blu-ray-bzw. AVCHD-kompatible Kodieren eine Wissenschaft für sich ist. Hinzu kommen Veränderungen auf GOP-Ebene: Die von MPEG-1/-2 bekannten I-Frames haben in IDRFrames ihre Nachfolger gefunden, während die I- Frames jetzt auf Vorgänger-I-Frames verweisen können. Eine GOP erstreckt sich damit von einem IDR- Frame zum nächsten, nicht mehr von I-Frame zu I-Frame. Folglicherweise kann nur noch an IDR-Frames ohne Smart Rendering verlustlos geschnitten werden."
Hallo zusammen,
ich beschäftige mich seit 2 Jahren mit dem Problem Smart Rendering von AVCHD-Material des Canon HF100 Camcorders. Meiner Ansicht nach kann AVCHD-Material durchaus eine GOP-Struktur haben. Bei der HF100 ist die GOP-Länge z. B. 12. Dies kann man mit dem Elecard Stream Eye Tool leicht nachprüfen.
In Heft 25 der c't 2009 wurden Videoschnittprogramme getestet. Ein Testkriterium lautete "Smart Rendering AVCHD" und nur Cyberlink Power Director 8 Ultra bekam diesbezüglich eine gute Bewertung.
In diesem Test wurde Nero Vision nicht untersucht. Ich verwende das ältere Nero 8, das zumindest für HF100 Material Smart Encoding beherrscht, wenn man als Ausgabe DVD-AVCHD und nicht Ausgabe in Datei verwendet. Beim Rendern wird angezeigt, ob die aktuelle Stelle smart oder stupid gerendert wird.
Für mich ist das Kriterium für Smart Encoding eine Renderzeit die vergleichbar der Ausgabe durch TSMuxer ist, wenn ein paar Clips ohne Effekte und Übergänge verkettet werden. In jedem Fall sollte die Renderzeit nur ein Bruchteil der Echtzeit sein.
Viele Grüße,
Harald1234
Ein IDR wird im AVC lediglich am Szenenanfang geschrieben, danach nicht mehr. Das bedeutet, dass es durchaus ein paar hundert Frames keine IDRs mehr geben muss.
Den B-Frames kommt in AVC eine völlig neue Bedeutung zu, da sie für die Bild Rekonstruktion eine gewichtigere Rolle übernehmen. Da AVC eine Langzeitprädiktion erlaubt und dazu unterschiedliche Slices im RAM für durchaus lange Perioden ablegt, gibt es das, was man als SR bezeichnet nicht mehr.
Es ist beispielsweise möglich, ein Frame in zwei P-Slices und ein I.-Slice zu zerlegen. Das Bild besteht also aus völlig unterschiedlichen Teilen.
Um das komplette Frame vollständig dekodieren zu können, müssen sowohl das I-Slice als auch die beiden P-Slices dekodiert werden. Danach wird das "Original-Bild" rekonstruiert, indem die dekodierten Slice-Bereiche zusammengesetzt werden. Die beiden P-Slices brauchen dazu Referenzslices, z.B. vorherige I- oder P-Slices. Das I-Slice ist intrakodiert. Fehlt ein Slice, kann der Bildteil, der durch dieses Slice abgedeckt war, nur interpoliert werden, was deutlich sichtbar ist, zumal es über den Rest der Periode, bis zum nächsten IDR stattfinden muss.
Nun kann man ein B-Frame mit der entsprechenden Software in ein I-Frame bzw. ein IDR umwandeln. Dabei werden alle Slices Informationen verworfen, die normalerweise für eine korrekte Bildrekonstruktion erforderlich wären. Mit andern Worten, bei solchen "Tricks" darf man über längere Strecken mit verminderter Bildqualität rechnen.
Jeder kann nun auswählen, ob ihm ein "quick & dirty" oder ein gutes Bild lieber ist.
Wir haben das ein paar mal gemacht und schnell die Finger wieder davon gelassen.
Meiner Ansicht nach kann AVCHD-Material durchaus eine GOP-Struktur haben.
Ich denke, es ist keine Ansichtssache, ob AVC eine GoP Struktur hat, oder nicht.
Wo sollte eine GoP Struktur sein ???
Es gibt einfach keine, sich wiederholenden Strukturen innerhalb einer Szene mehr !!!
Und die Szenen sind ohnehin voneinander abweichend.
An der Funktionsweise des Codiersystems ändern auch Zeitschriften nichts ... obwohl man manchmal meinen könnte, sie erfinden das Rad neu, damit eine schnelle Blatt-Umlage generiert werden kann.
Der oben zitierte Artikel hat übrigens überhaupt noch nicht zur Kenntnis genommen, dass es Bild-Teilbereiche (Slices) überhaupt gibt, geschweige denn, welche Funktion sie haben, geschweige denn, wo und wielange sie abgelegt werden und wie sie aufeinander referenzieren.
Wer sich mit dem Kenntnisstand von MPEG2, AVC nähert, muss zunächst gewaltig umlernen.
Das betrifft übrigens auch die Analysemethoden.
vielen Dank für deine Erklärungen aufgrund dessen ich mir die H.264-Spezifikation angeschaut habe und dort ist wirklich keine Rede von GOPs. Mir war die Unterscheidung zwischen IDR und I Frames nicht klar, da die alte Version des Elecard Stream Eye dies nicht anzeigte. Die aktuelle Version von Elecard Stream Eye Studio Pro unterscheidet jetzt sehr wohl zwischen IDR und I Frames.
Für meine Canon HF100 Clips ergibt sich folgende Coded Video Sequence: IDR BB P BB P BB P BB I BB P BB P BB P BB ...
Dabei wiederholt sich die Abfolge I BB P BB P BB P BB. Soweit ich das feststellen konnte, kommt in einem Clip nur ein IDR Frame am Anfang vor.
Auf der anderen Seite gibt es Autoren, die von "GOP size" bei H.264 sprechen. Eine GOP erstreckt sich danach von einem IDR Frame bis zum letzten nicht IDR-Frame vor dem nächsten IDR Frame. Mit dieser Definition wäre ein HF100 Clip eine GOP.
Hallo Harald,
ich freue mich, dass es Leute gibt, die sich so intensiv mit dem Thema beschäftigen. Leider kann man das von den meisten Publikationen nicht behaupten. Daher wird eben oft auf längst überholten Begriffen herumgeritten, was dann wiederum zu ziemlichen Missverständnissen führt.
Für mich setzt das, was eine GoP beschriebt eine sich immer wiederholende Struktur voraus denn nur so ist es möglich, solche Tools, wie smart Rendering oder Smart MPEG aufzusetzen.
Wie Du sehr richtig erwähnt hast, halten einige eine Szene (Clip) von IDR zu (IDR-1) für eine GoP und berücksichtigen dabei nicht, dass jede Szene eine beliebige Länge haben kann und u.U. über hunderte von Frames geht. (oder eben nur über wenige Frames).
Daher ist das für mich keine GoP, nur weil jemand eine alte Bezeichnung benutzen will.
AVC hat übrigens Mechanismen, die I Frames dynamisch nach dem Speicherverhalten setzen und so bei langen Passagen Fehler vorbeugen kann. Mal ganz von der stärkeren Bedeutung der B-Slices abgesehen.
Viele "Nachbauten- wie z.B. X.264" unterscheiden sich darin und noch in etlichen andern "Feinheiten". Bei manchen Dingen kommt man eben um patentierte Verfahren nicht herum, kann sie aber nicht eben mal so re-engineeren..
Ebenso wird nirgend berücksichtigt, dass die Frames unterschiedliche Slice Inhalte haben können, was es im MPEG2 Verfahren mit seinen GoPs überhaupt nicht gab.
Nun ist es vermutlich wenig sinnvoll, in allgemeinen Publikationen auf solche Details einzugehen, aber es ist ebenso unsinnig, mit falschen und irreführenden Bezeichnungen zu hantieren und damit evtl. Erwartungen zu wecken, die längst der Vergangenheit angehören.
Oder aber, man erklärt die Zusammenhänge.
Mich verwundert eben nur, dass man nicht, wie im offiziellen Sprachgebrauch, gleich von Slices redet ... dann wäre klar geworden, das es etwas Anderes ist.
Beste Grüße.
ich beschäftige mich nur aus Hobby mit dem Thema H.264. Der Grund ist natürlich, dass ich als Hobbyfilmer irgendwie AVCHD sauber schneiden möchte. Bis jetzt habe ich noch nichts befriedigendes gefunden. Ich möchte aber die Hoffnung nicht aufgeben.
Momentan verwende ich die zu Fuß-Methode: beim Filmen Clips kurz halten (ca. 5 sec.), dann schlechte Clips löschen und den Rest mit TSMuxer zusammenfügen. Keine Blenden/Übergänge. Fertig ist der Film.
Gibt es eigentlich ein H.264-Analysetool um bei einem gegebenen Frame einen Macroblock rauszugreifen und sich alle Reference Frames anzeigen zu lassen und dann vielleicht noch eine Statistik über Reference Frame Abstände zu erstellen? Mich würde interessieren wie weit die Korrelationen bei Camcordern, die ja in Echtzeit encodieren müssen, reichen.
Vergangene Frames können i.A. wohl beliebig lange referenziert werden, wobei ich nicht weiss, ob das bei Camcordern in der Praxis wirklich gemacht wird. Zukünftige Frames können nicht beliebig referenziert werden, da sie noch nicht vorhanden/bekannt sind. Hier ist sicher eine Asymmetrie bei den B-Slices, oder?
Smart Encoding: Man müßte doch irgendwie die beim Schnitt verlorengehenden Referenzen, die in den abgeschnittenen Teilen stecken, "einsammeln" und an der Schnittkante einarbeiten können, so dass die Verweise im beschnittenen Material nicht ins Leere laufen. Ist wohl leichter gedacht als implementiert.
Eine Frage am Rande: Was ist den "Original" und was "Nachbau"?
Hallo zusammen,
inzwischen habe ich ein Analysetool gefunden und ein paar interessante Beobachtungen gemacht. Ich habe mit dem Elecard Buffer Analyser meine Canon HF100 AVCHD Clips im Format 1080i untersucht:
1) Die einzelnen Frames bleiben ca. 0,35 sec bis 0,50 sec im Decoded Picture Buffer. Danach werden sie wieder gelöscht.
2) Wird ein I Frame dekodiert sind bereits alle Frames, die vor dem Vorgänger I Frame liegen gelöscht.
3) Die Fenstergröße für Reference Frames ("sliding window memory control") ist lediglich der I Frame Abstand von 25 Frames.
4) Zum Dekodieren eines beliebigen Frames benötigt man nur Reference Frames, die maximal 0,50 sec und damit 25 Frames zurück liegen.
5) Es werden keine Long-term Reference Frames verwendet, da die Verweildauer von 0,5 sec nie überschritten wird.
Damit sollte Smart Rendering nicht zu schwer sein. Es muss lediglich eine Sequenz von ca. 25 Frames nach dem Schnittpunkt neu berechnet werden.
Zum Vergleich habe ich mir noch einen Clip einer Sony HDR SR10 angeschaut, mit ähnlichem Ergebnis.
Vielleicht werden ja bei AVCHD-Camcordern generell keine Long-term Reference Frames verwendet. Nicht alles was der H.264 Standard erlaubt, muss bei Canon, Sony und Panasonic implementiert sein.
Hallo Harald,
ich kann nicht genau nachvollziehen, was Du da genau gemessen hast, aber es sieht so aus, als ob der Bildspeicher ausgelesen worden ist, der aber wiederum keine Auskunft über den eigentlichen Bitstream gibt.
Wie ich schon angeführt habe ist eigentlich bedauerlich, dass die Begriffe aus den älteren Codingverfahren übernommen wurden, was jetzt zu falschen Definitionen und Missverständnissen führt. Eigentlich hätte man soetwas wie I, B und P Frames völlig vergessen müssen, weil wir es mit IDR und eigentlich auch nur noch einem weiteren Frametypus zu tun haben. Selbst IDR ist nicht das, was ursprünglich mal ein I-Frame war, weil wir jetzt auch eine Intra-Prädiktion im Bild haben, was ursprünglich nicht der Fall war. Es ist also, so gesehen gar kein I-Frame. Was den andern Bildtypus betrifft, so können sich darin Slices befinden, die frei wählbar sind. Prinzipiell unterscheidet man zwischen 5 Slicetypen, hier kommen aber nur 3 davon in Frage. Es sind Zusammenschlüsse von Makroblöcken, die im freien Zugriff im RAM befinden.
Das Verfahren ist der MPEG4 Idee entliehen, Objekte zu definieren und diese gesondert (in Layern) zu übertragen. Solche Layer ergeben sich in H.264 durch die "Hochtastung" darunter liegender Makroblöcke.
Solche Slices, deren Makroblöcke also separat in der Reihenfolge der Codierung frei wählbar und zuzuordnen sind, sind genau der Bestandteil eines Codings, das sich in solchen alten, bildorientierten Analyseverfahren, die immer nur eine Field/Frame kannten, nicht abbilden lassen und daher zu solchen Trugschlüssen führen.
Mein Tipp für Dich wäre, Dich einmal in das H.264 Verfahren und in die objektorientierten Übertragungsverfahren (Flexmux) von MPEG4 einzulesen.
Du wirst so, sehr viel schneller die Antwort auf solche anwendungsspezifischen Fragen finden als mit alten Testmethoden.
Ich bin völlig sicher, dass Du das rasch verinhaltlicht hast.
Es ist anfänglich etwas "trocken" aber macht nachher wirklich Spaß. Sicher kein Thema für "nur-Praktiker", aber der scheinst Du mir bei Weitem nicht zu sein.
Hallo lieber Wolfgang,
danke für dein schnelles Feedback. Nachfolgend versuche ich einige deiner Fragen zu beantworten.
ich kann nicht genau nachvollziehen, was Du da genau gemessen hast
Ich habe die Demoversion des Elecard Buffer Analyzer V2.1.21974 verwendet http://www.elecard.com/products/product ... -analyzer/
und mehrere Camcorder Clips untersucht. Das Ergebnis für einen Clip habe ich hier angefügt. Es zeigt den zeitlichen Verlauf der im Decoded Picture Buffer gespeicherten Reference Frames. Die Informationen beziehen sich auf Frames, nicht auf Slices oder Makroblöcke. Ich gehe davon aus, dass mit dem löschen eines Frames aus dem Buffer alle zugehörigen Slices und Macroblöcke gelöscht werden und für nachfolgende Frames zur Referenzierung nicht mehr zur Verfügung stehen. Gibt es dagegen Einwände?
Eigentlich hätte man soetwas wie I, B und P Frames völlig vergessen müssen, weil wir es mit IDR und eigentlich auch nur noch einem weiteren Frametypus zu tun haben. Selbst IDR ist nicht das, was ursprünglich mal ein I-Frame war, weil wir jetzt auch eine Intra-Prädiktion im Bild haben, was ursprünglich nicht der Fall war. Es ist also, so gesehen gar kein I-Frame.
Vergessen wir einfach ältere Standards und sprechen nur von H.264. Ein I Frame besteht nur aus Makroblöcken des Slice Types I usw.
Was den andern Bildtypus betrifft, so können sich darin Slices befinden, die frei wählbar sind.
Die Wählbarkeit bezieht sich wohl auf den Encodingvorgang beim Erstellen des Videos. Dagegen habe ich vorgegebene "fertige" Videos untersucht und hier ist der Auswahlprozess abgeschlossen. Meine Frage ist, was steckt da drin? Zugegeben das ist ein Einzelfall. Die Sachlage kann bei anderem Material ganz anders sein.
Solche Slices, deren Makroblöcke also separat in der Reihenfolge der Codierung frei wählbar und zuzuordnen sind, sind genau der Bestandteil eines Codings, das sich in solchen alten, bildorientierten Analyseverfahren, die immer nur eine Field/Frame kannten, nicht abbilden lassen und daher zu solchen Trugschlüssen führen.
Es mag ja sein, dass im allgemeinen über Long-term Reference Frames beim Encodieren auf jeden beliebigen Makroblock zurückgegriffen werden kann. Mir scheint jedoch, dass dies bei meinen Camcorder Clips nicht der Fall ist. Es wird nur ein recht kleines Fenster zurückliegender Frames benutzt. Das sollte Smart Rendering erleichtern. Kannst du definitiv ausschließen, dass dies bei den Canon HF100 Clips so sein kann?
Mein Tipp für Dich wäre, Dich einmal in das H.264 Verfahren und in die objektorientierten Übertragungsverfahren (Flexmux) von MPEG4 einzulesen.
Hast du da eine gute Referenz im Internet? Irgendwelche Papers? Fachbücher möchte ich mir nicht kaufen.
Bei Richardon: "H.264 and MPEG4 Video Compression" ist in Kapitel 6.4.2 das Reference Picture Management von H.264 gut beschrieben. Auf dieser Basis habe ich die Elecard Datei interpretiert. Dein Buch konnte ich noch nich lesen.
Es sind Zusammenschlüsse von Makroblöcken, die im freien Zugriff im RAM befinden.
D. h. alle jemals decodierten Makroblöcke eines Clips sind jederzeit im RAM verfügbar?
Solche Slices, deren Makroblöcke also separat in der Reihenfolge der Codierung frei wählbar und zuzuordnen sind
Ich weiss nicht genau, was du hier mit frei wählbar und zuordenbar meinst. Es gibt doch eine klare Hierarchie: Sequenz --> Frames --> Slices --> Makroblöcke --> Pixel.
Ein Makroblock gehört immer zu genau einem Slice und dieser zu genau einem Frame. So sieht man das auch mit dem H264Visa Analysetool.
Sicher kein Thema für "nur-Praktiker", aber der scheinst Du mir bei Weitem nicht zu sein.
Ich gebe zu, dass ich mich gerne auch mit theoretischen Dingen befasse.
Viele Grüße,
Harald
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
ich habe dasselbe Problem und bin auf der Suche nach einem einfachen Schnittprogramm für AVCHD. Ich habe verschiedene, freie Programme untersucht mit dem Fokus auf einfaches Schneiden und Trimmen ohne Übergänge oder Effekte. Bei meinen Tests mit Canon HF100 AVCHD-Material schnitten folgende Programme am besten ab:
-TSMuxer
-TSRemux
-TSSnipper 0.80
-VideoRedo TVSuite V4
Siehe auch die beigefügte Tabelle der Testergebnisse. Mir scheint, das Schneiden von AVCHD-Material mit TSSnipper und VideoRedo geht schon recht gut. Es treten bei diesen Programmen keine Blockartefakate, Ruckeln etc. mehr auf. Der Schnitt erfolgte an beliebigen Frames (I, IDR, B, P). Verbessert werden muss eher noch der Audioschnitt und die A/V-Synchronität. Teilweise hatten Video-und Audiospur nach dem Schneiden leicht unterschiedliche Längen.
Andere Programme (siehe Liste) sind aufgrund der miserablen Bildqualität oder wegen anderer gravierender Einschränkungen bei mir durchgefallen.
Vielleicht hilft das dem einen oder anderen als Anhaltspunkt.
Ich erhebe keinen Abspruch auf Allgemeingültigkeit.
Gruß,
Harald1234
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Hallo Leute,
ich finde es toll dass sich mittlerweile so viele Leute mit dem Thema befassen. Viele sind der Auffassung Smart Rendering ist für AVCHD nicht möglich.
Ich kann nur sagen:
Mit der neusten Version von Cyberlink Powerdirector funktioniert bei mir das Smart Rendering "einwandfrei" sowohl mit Daten von der alten JVC Kamera als auch mit der neuen Sony Kamera!
Konnte endlich meine erste Blu Ray fertigstellen...
Kannst du mal näher beschreiben, was du alles gemacht hast (Trimmen, Zerschneiden, Übergänge, Sonstige Effekte) und welches Format dein Videomaterial hatte.
Kannst du vielleicht einen kurzen original und unbehandelten JVC Testclip irgendwo zum runterladen bereitstellen. Mich würde die Frame-Struktur der Clips interessieren. Es ist sehr schwierig an Originalmaterial verschiedener Camcordermodelle ranzukommen. Ich vermute, dass bei Consumer Camcordern gar keine Long-term Reference Frames verwendet werden, was das Smart Rendering erleichtert.
Störende Blöcke gibt es nicht beim Smart Rendering mit Powerdirector, dafür hakt das Video für einen kurzen Moment wenn ich einen Schnitt gemacht habe. Beim aneinander reihen von Clips ist mir das bisher noch nicht aufgefallen...
Hakt das Video bei den letzten Bildern des gekürzten Takes - bleibt quasi stehen?
Wenn ja, dürfte das daran liegen, dass die Bildfolge des h.264-Stroms nicht der natürlichen Bildfolge enstspricht und somit Informationen für ein paar Bilder fehlen!
Um das zu vermeinden, müßte zumindest die letzte GoP neugeschrieben werden, was aber einige Sekunden Spieldauer bedeuten kann! Somit ist Smart-Rendering bei Footage mit insbesondere langen GoPs keine zufriedenstellende Alternative!
Der Thread ist 10 Jahre alt. Gibt es mittlerweile ein Schnittprogramm, das Smartrendering bei AVCHD Material beherrscht?
Mein Sat Receiver (Dreambox DM920 UHD) schreibt .ts Videodateien mit AVCHD H.264 Codec.
Ich mache fast ausschließlich harte Schnitte - aber halt framegenau - und bei den Tonspuren fade ich an einigen Stellen.
Gibt es dafür mittlerweile eine Smartrendering Lösung oder muss man auch im Jahr 2021 komplett neu rendern?
MikeyVanDikey hat geschrieben: ↑Mo 16 Aug, 2021 16:41
Mein Sat Receiver (Dreambox DM920 UHD) schreibt .ts Videodateien mit AVCHD H.264 Codec.
Ich mache fast ausschließlich harte Schnitte - aber halt framegenau - und bei den Tonspuren fade ich an einigen Stellen.
Gibt es dafür mittlerweile eine Smartrendering Lösung oder muss man auch im Jahr 2021 komplett neu rendern?
MikeyVanDikey hat geschrieben: ↑Mo 16 Aug, 2021 16:41
Der Thread ist 10 Jahre alt. Gibt es mittlerweile ein Schnittprogramm, das Smartrendering bei AVCHD Material beherrscht?
...
Gibt es dafür mittlerweile eine Smartrendering Lösung oder muss man auch im Jahr 2021 komplett neu rendern?
ich würde behaupten, dass ZUM GLÜCK nicht nur die nutzung von AVCHD immer mehr verschwindet, sondern auch diese art der herangehensweise an die video-verarbeitung, da es in der praxis kaum ernsthafte qualitative od. performancebezogene vorteile bietet, aber eine ganze menge an komplikationen und daraus resultierenden fehlerquellen.
heutige programme mögen zwar auf grund der erneuten encodierung ein meist völlig vernachlässigbares minimum an informationsverlusten verursachen, aber dafür werden dort unheimlich viele sachen deutlich sauberer und befriedigender gelöst (stichwort: farbverarbeitung, konsistenz der metadaten) als in diesen urzeiten des ganz primitiven digitalen video-schnitts.
Smartrendering macht unter Umständen bei dafür geeigneten Containern in Verbindung mit Intra-Frame-Only Codecs (DV, Prores, etc.) und ebenfalls passendem Audio-Format Sinn.
Sonst ist der dafür nötige Aufwand jedoch hoch und eine Umsetzung ist gemessen am Nutzen eher weniger sinnvoll.
SMART-Rendering bedeutet, dass bei der Video-Bearbeitung nur die stellen des Videos neu kodiert werden, die aufgrund von Schnitten oder Bearbeitungen neu kodiert werden müssen.
auch in den etwas komplizierteren heutigen videoformaten und deren containern werden bild und ton immer streng getrennt aufgenommen und abgespeichert. d.h. man kann grundsätzlich sehr wohl über einzelne passagen den videodatenstrom unverändert kopieren, aber die tonspur gleichzeitig verändern.
das lässt sich ohnehein sehr einfach mit ffmpeg komandozeilenaufrufen durchspielen, wo man sehr oft ein '-c:a copy' oder '-c:v copy' verwendet -- also die audio oder video spur unverändert kopiert --, und nur die jeweils andere spur in ein neues format konvertiert oder mit div. filtern bearbeitet. das ist zwar natürlich nur der allereinfachste fall, der das prinzip dahinter verdeutlicht, aber grundsätzlich lässt sich ein solches vorgehen natürlich auch auf wesentlich komplexeren szenarien übertragen.
trotzdem macht derartiges in der praxis meist nicht viel sinn, weil die entsprechenden verluste durch das wiederholte encodieren bei geeigneten codecs praktisch vernachlässigbar sind. vielmehr wird alles deutlich einfacher und weniger fehleranfälliger, wenn man sich dieses primitive jonglieren mit unveränderten originaldaten erspart bzw. sauber arbeitende zeitgemäße verarbeitungspipelines nutzt.
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.
