Framegenauer Schnitt

[Djfe]

@wurzel
für sowas solltest du einen neuen Thread im Bereich "Muxen und Demuxen" öffnen
da ist dein Thema sicherlich besser aufgehoben, denn es hat fast nichts mit diesem Thread zu tun

inwiefern es einen nicht konstanten Versatz bei HD gibt, kann ich dir leider nicht sagen
aber ein vollständiger Recode mit Handbrake/Vidcoder wird nach meiner Erfahrung immer sauberer sein als ein Remuxen in einen anderen Container, weil Sat Aufnahmen nun mal nicht die beste Quelle sind

ich glaube auch nicht, dass ein framegenauer Schnitt bei deinem Problem helfen würde, da der Versatz ja bei dir über die ganze Aufnahme nicht konstant ist und nicht nur an den Schnittpunkten

hast du den Remux mit dem TS Remuxer im TSD gemacht?
eventuell kannst du dein Problem auf der folgenden Seite melden und Physic findet eine Lösung für dein Problem, sodass er es reparieren kann (je nach Format müsstest du den Fehler auch an den Entwickler von MKV Toolnix melden -> du hast ja nicht geschrieben um welchen Container und welches Tool es geht)
http://forum.doom9.org/showthread.php?t=168539
http://www.bunkus.org/videotools/mkvtoolnix/bugreports.html

[wurzel]

Ich denke der Beitrag ist schon hier richtig.

Das war mehr als Querverweis gemeint was ich beim Versuch HD zu verarbeiten feststellen durfte. Anscheinend ist einfach etwas schwieriger einfach HD zu schneiden aufgrund des Tonversatzes. Es wurde vorher schon angesprochen, dass speziell der Ton bei HD etwas wunderlich reagiert auf 'framegenauen Schnitt'.

Vielleicht etwas zu ausführlich dargestellt.

[Djfe]

naja ein anderer Codec halt

glaub AC3 hat sowas vergleichbares wie I-Frames -> also Referenzen zwischen einzelnen Audio-"Frames"
aber MPEG Audio hat das nicht

außerdem erschwert die Paketstruktur von TS das wohl noch zusätzlich -> es wird nach Paketen geschnitten:
man möchte nach Videopaket A schneiden, aber das Tonpaket für Videopaket A folgt in der Datei erst danach...

ich schätze der Grund warum ProjectX und Cuttermaran kein HD unterstützen ist vor allem die Lizenzlage...
->zusätzliche Kosten für den Codec in großer Höhe

Open-Source Projekte haben da keine so großen Probleme -> x264 ist für andere Open-Source Projekte ebenfalls kostenlos/frei verfügbar (GPT-Lizenz)
für kommerzielle Software hingegen kostet es Geld

hinzu kommt dann der Aufwand sich in den neuen Codec auch noch einzuarbeiten

[Derrick]

glaub AC3 hat sowas vergleichbares wie I-Frames -> also Referenzen zwischen einzelnen Audio-"Frames"
aber MPEG Audio hat das nicht

Sowohl bei AC3 als auch bei Mpeg1/Layer2 werden frames bestehend aus mehreren audiosamples übertragen. Um ganz genau zu schneiden, müsste man es erst dekomprimieren. Vergleichen mit einer GOP-struktur (mit I,P oder B frames) kann man es nicht.

außerdem erschwert die Paketstruktur von TS das wohl noch zusätzlich -> es wird nach Paketen geschnitten:
man möchte nach Videopaket A schneiden, aber das Tonpaket für Videopaket A folgt in der Datei erst danach...

Ist doch immer gemuxt hintereinander. Fürs korrekte timing gibt es zeitstempel

ich schätze der Grund warum ProjectX und Cuttermaran kein HD unterstützen..

,,ist zumindest für pj.x, dass der autor das projekt schon lange beendet hat

[testest]

..also mir reicht das schneiden an I-Frames nicht..

..hier wird die ganze Zeit von falschen Grundlagen ausgegangen - am Ende eines Schnittbereiches schneidet TS-Doc auch zw. I-Frames framegenau. Nur der Anfang sollte direkt auf einem I-Frame liegen.

Wenn das nicht wäre hätt ich auch Probleme. Aber so gehts genau genug und nix mehr da von der Werbung (bei manuellem Schnitt).

[paladin77]

..hier wird die ganze Zeit von falschen Grundlagen ausgegangen -

Hallo testest,

betrachtest du die Video-Qualität des Schnittproduktes und differenzierst du zwischen SD und HD Aufnahmen?
Meiner Erfahrung nach führen Schnitte zwischen I-Frames bei HD (H.264) Material zu Artefakten.
Diese treten dann auf, wenn man den Anfang eines Schnittbereiches nicht auf einen I-Frame setzen möchte.
Damit fehlen dem H.264 Dekoder Referenzinformationen was zu Bildstörungen führt.

Es mag ja sein, dass jemand hier von falschen Voraussetzungen ausgehen, aber ich denke ich tue das nicht und einige andere die mit Auge für das Ziel, sowie Sach- und Fachverstand diskutieren auch nicht. Der Ersteller dieses Threads und ich haben ein ganz klares Ziel definiert. Es ging nicht darum, ob die Schnitt-Fähigkeiten unter Einsatz von Kompromissen dem eigenen Empfinden nach ausreichen sondern darum,  ob das grundsätzlich tolle Produkt um die Funktion "Framegenauer Schnitt" erweitert werden kann und ob schon absehbar ist wann. Implizit erfordert das Vorhaben - mit dem Ziel einer fehlerfreien Videodarstellung ab dem Schnittpunkt - dass der Abschnitt zwischen zwei I-Frames reenkodiert wird. Dazu hatte Cypheros (Der Entwicker) bereits am Anfang des Threads Stellung genommen.

Ich nehme an, dass du derzeit auf einige Frames deiner Aufnahmen verzichtest um die Werbung Störungsfrei zu entfernen (Bitte stelle das Richtig, wenn die Annahme nicht stimmt). Wenn meine Annahme stimmt haben wir unterschiedliche Ziele. Ich möchte alle Anteile einer Aufnahme (mit Ausnahme von Überlappungen) im Endergebnis.

[gnarf]

Liebe Gemeinde,
meiner Meinung nach ist die Schnittgenauigkeit des TS-Doctor gerade mal wieder an einem Tiefpunkt angelangt. Ich bin mir nur nicht so sicher, ob es am TS-Doctor oder am LAV-Filter liegt.
Zuvor hatte ich nämlich den TS-Doctor v1.2.128 und LAV-Filter v62.0 installiert und das Resultat war schrecklich, egal ob ich am I-Frame geschnitten habe oder nicht. Der Schnittpunkt am bewegten Bild wird deutlich nach hinten verschoben. Vorige Woche, gleicher Sender und Sendung mit TS-Doctor 1.2.126 und LAV-Filter 61.2, da war die Genauigkeit deutlich besser.
Ich habe nun versuchsweise die alten Versionen nochmal drüber installiert, hat nur leider nicht viel gebracht. Deshalb werde ich jetzt das Rohmaterial aufheben und es, wenn hoffentlich bald wieder bessere Zeiten angebrochen sein werden, nochmal versuchen. Und wenn es dann tatsächlich soweit ist, werde ich nie wieder ein Update machen.   

Gruß,
gnarf

[Mam]

Hmm, ich versteh das Problem nicht 

Es gibt zwar seeeeehr selten Aufnahmen, da kann man ums Verrecken keinen ordentlichen Schnittpunkt setzen, bzw, das, was rauskommt, hat wenig mit dem Angeklickten zu tun, aber die Anzahl bewegt sich doch im unteren einstelligen Prozentbereich...

Ich habe mehr den Grafiktreiber in Verdacht, obwohl man Hardware Unterstützung überall ausschaltet, ich kann mich des Eindrucks nicht erwehren, dass der Treiber doch irgendwo reinferkelt.
Beim AMD Treiber ist es leicht nachzuweisen, da kann man "globale Videoverbessrungen" einrichten (also Kontrast, Farbe usw), und obwohl der Doc (bzw. die LAV Filter) am Treiber vorbei arbeiten sollten, sind sichtbare Unterschiede im Bild vorhanden.
Und irgendwie glaube ich auch, dass nicht "neuer Treiber" automatisch auch "besserer Treiber" ist...

[Tourniquet]

Als ich damals TS-Doctor gekauft habe, bin ich eigentlich davon ausgegangen, dass man mit dem Programm Frame genau schneiden kann. Tja dem war ja leider nicht so.

Ich habe viele verschiedene Einstellungen probiert, aber kam bisher nie zu einem akzeptablen Ergebnis. Daher ich nutze ich TS Doctor eigentlich nur noch bei Aufnahmen ohne Werbeunterbrechungen. Ist zwar etwas schade, aber mitten in einem aufgenommen Film, eine 'Störung' drinn zu haben, geht eben gar nicht.

Zwar wäre es wirklich super toll falls man Frame genaues schneiden bekommen würde, aber ich glaube nicht daran. Wenn es Frame genau sein muss, nutze ich Smart Cutter. Kostet zwar leider ein bisschen mehr, aber lohnen tut es sich auf jeden Fall 

[Djfe]

Ich glaub viele, die hier Probleme haben, haben auch bei "Berücksichtige I/P-Frames für den Schnitt" ein Häkchen gesetzt.

Ich hab dort keins gesetzt, weswegen der Doc auch immer dort schneidet, wo ich will, und nicht versetzt

jedoch muss man dann selbst nach Artefakten Ausschau halten/I-Frames bevorzugen/die Schnittvorschau benutzen, um Artefakte frühzeitig zu erkennen und den Schnittpunkt frameweise zu verschieben

dennoch wäre eine Lösung wie beim Smart Cutter sauberer und schöner anzusehen (kein harter Übergang)

[gnarf]

Ich glaub viele, die hier Probleme haben, haben auch bei "Berücksichtige I/P-Frames für den Schnitt" ein Häkchen gesetzt.

Ich hab dort keins gesetzt, weswegen der Doc auch immer dort schneidet, wo ich will, und nicht versetzt

Ich habe es probiert, das Resultat war leider mit den Versuchen von gestern identisch.
Auch habe ich mal mit Smart Cutter experimentiert, welches zwar perfekte Schnittergebnisse liefert, jedoch in den Bedienung stark gewöhnungsbedürftig ist. Die Bedienung von TS-Doctor mit der Schnittgenauigkeit von Smart Cutter wäre für mich beinahe das Nonplusultra.
Ich fürchte, ich muss wohl leider weiter auf bessere Zweiten warten.

Und irgendwie glaube ich auch, dass nicht "neuer Treiber" automatisch auch "besserer Treiber" ist...

Das glaube ich auch, man weiß es nur vorher nie so genau und ein Zurück ist eben oftmals leider nicht möglich.

Danke,
gnarf

[paladin77]

Zum Thema Hardwarebeschleinigung und Treiber. Ich bin mir ziemlich sicher, dass Hardwarebeschleunigung nur bei zwei Aufgben relevant ist.
1. Video-(Decodierung) zum Bearbeiten und für die Wiedergabe von h.264 bei sehr schwachen CPUs wie Atom-Klasse und Pentium 4 oder Handy CPUs. Wer eine ausreichend schnelle CPU hat kann darauf problemlos verzichten.
2. Video-Codierung.
Für die Schnittfunktionen von TS-Doctor spielt die Hardwarebeschleunigung (meiner Meinung nach) keine Rolle. Nur für eine nachfolgende Komprimierung wäre das relevant.
@cypheros: liege ich richtig?

Allerdings kann bei ungünstigen Schnittpositionen (abseits von I-Frames) weder ein Hardware-Encoder noch ein Software-Encoder wieder eine heile Frame-Abfolge zaubern. Eine Vernünftige Option die ggf. als Voreinstellung aktiviert sein kann oder auch nicht, wäre Frames ohne vorangehenden I-Frame automatisch zu verwerfen. Wenn der (Hardware-)Encoder so eine Einstellung aufweist, dann könnte man damit evtl. etwas sauberer Schnitte hinbekommen. Ob der Ton danach noch synchron ist, ist eine andere Frage.
Für den Hardware-Encoder der Grafikarte müsste man dann entsprechend die Treibereinstellungen durchforsten.

[Djfe]

Einen kompletten Film mit der Hardware encoden geht sowieso nicht mit einem PC (die Grafikkarte kann nur gewisse Lasten/Funktionen der CPU übernehmen und dadurch den Ablauf beschleunigen)

worum es Mam geht: ein Hardwaredecodierer ist zur Wiedergabe gedacht und kann dafür sorgen, dass die mit dem TSD festgelegten Schnittpunkte ungenau sind (nicht stimmen), weil es dem Hersteller des Decoders darauf nicht ankam, dass die Frameangaben zu 100% stimmen
dies ist aber beim Schnitt sehr wichtig, damit der TSD nachher tatsächlich auch den vom Nutzer gewählten Schnittpunkt nimmt und nicht den vom Hardwaredecodierer verfälschten

er wollte nur sagen, dass ihm die bisherige Schnittfunktion im Normalfall ausreicht und er denkt, dass die Probleme bei einigen durch eine standardmäßig in den LAV-Filtern (oder anderen Decodierern) aktivierte Hardwarebeschleunigung verursacht werden.

[testest]

Hardwarebeschleunigung funkt mit TS-Doc wegen dessen Spezialfiltern sowieso nur nicht-teilweise.
Auch Hardwarebeschleunigung-in-TS-Doc-benutzen-Gegner wie zB. Mam sollten dadurch "beruhigt" werden? Bei mir ist ohne/mit immer wieder getestet worden mit Null ! Unterschied bei der Schnittgenauigkeit (hauptsächlich Cyberlink, nebenbei, danke Onkel Cyph für Implementierung höherer Versionen ;-).

Schnittgenauigkeit in TS-Doc hängt, wie unzählige andere TS-Doc-Faktoren, immer wieder vom Empfang, Receiver, Land usw. ab. Also reichlich Spielraum für vielerlei Unabwägbarkeiten? Dann kommt noch der moralische Imperativ (deutsch) dazu: es MUSS 100% sein, sonst geht garnix, äh..?

Also ich mit DM8000 in Mitteldeutschland hab nur Bruchteile von sec Schnittbereichs-Anfang-Versatz zum nächsten I-Frame und der ist mir völlig egal da winzig. Der Schnittbereichs-Ende-Cut ist wie gesagt vollkommen Frame-genau. Allerdings, ich bin weiß, mein Enkel ist ziemlich dunkelhäutig. Auch das ist mir reichlich egal...

[Mam]

Ich finde es belustigend (oder beängstigend), was die Leute so meinen, aus meinen Worten lesen zu können 

a) "Hardwarebeschleunigung" ist weder "böse" noch "falsch" oder so. Das Problem dabei ist eben nur, dass die dekodierten Bilder nicht mehr im Speicher abgelegt werden, sondern nur direkt auf dem Bildschirm ausgegeben werden. Dadurch kann der Doc damit keine Vorschaubilder zeigen und die Bewegung im Schnittfenster wird total ungenau, bzw. zufällig.

b) natürlich kann man "ganze Filme" durch "Hardwarebeschleunigung" jagen, alles andere wäre ja traurig. Der Begriff sagt ja nichts anderes aus, als dass man die Rechenarbeit vom Prozessor auf ein irgendwie dafür geeignetes anderes Gerät auslagert. Wenn dieses andere Gerät zu schlapp dazu wäre, macht die Sache doch gar keinen Sinn.

c) Natürlich sollte man, wenn möglich, diese "Hardwarebeschleunigung" auch bei "schnellen CPUs" nehmen. Denn, wenn die weniger zu tun haben, könnten sie ja gleichzeitig was anderes erledigen... Es ist also schon etwas traurig, dass der Doc dieses Feature blockiert. Hier müsste eventuell mal mit den LAV Entwicklern geredet werden, vielleicht könnten sie sowas wie "Anwendungsprofile" vorsehen, so dass man Konfigurationen für verschiedene Programme hinterlegen kann (ist aber mehr die Kür) bzw. eine Anwendung wie der Doc beim LAV Filter eine Anforderung "bitte keine Hardwarebeschleunigung für mich aktivieren" senden kann.

d) das hat alles recht wenig bis überhaupt nichts mit "framegenauer Schnitt" zu tun. Egal, welcher Dekoder aktiv war, das Problem besteht weiterhin darin, dass um Klötzchen zu vermeiden, nur an I-Frames geschnitten werden kann (mir reicht diese "Ungenauigkeit" aber vollständig aus, die Sender, die ich aufnehme, senden genug I-Frames damit meine Schnittpunkte nah genug am "Wunschpunkt" landen. Wenn die Sender aber einfach so wild in der Gegend rumschneiden und ohne Schwarzblenden brutal auf Werbung schalten, dann kann es natürlich eng werden. Aber, das Problem liegt an den Sendern, nicht am Doc)