GfD - unsaubere Schnittübergänge nach Authoring

  • Hi,
    mal eine kurze Nachfrage (speziell eigentlich an borax und eventuell liquid217):
    Mir ist des öfteren aufgefallen, das GfD an den Schnittstellen (entfernte Werbung aus TV-Aufnahmen) ab und zu mal Probleme hat, soll heißen die Wiedergabe ist nach dem Authoring nicht mehr flüssig, sondern springt deutlich. Hat das sonst noch jemand bemerkt?


    Bevor jetzt alle auf mich einschlagen:ani_lol:,
    1. feststellbar bei DVD-Struktur in Software-Playern und Stand-alone Playern
    2. das passiert natürlich nur bei Schnitten, die nicht auf I-Frames liegen
    3. in den bearbeiteten m2v/mpa-files ist es nicht feststellbar


    Alternativ habe ich das Ganze nochmal mit DVDAuthorGUI laufen lassen (dieselben m2v/mpa-files), da sind die Übergänge einwandfrei.


    Bearbeitungsablauf:
    PjX: demultiplexen der Aufnahme liefert m2v/mpa-file
    CM: Schneiden (Framegenau, also beliebiger IBBpBBpBBpBB) liefert neue m2v/mp2-files, als Beispiel CutOut bei IB und CutIn bei IBBpBBpBBpB


    Authoring:
    Fall A mit GfD:
    Intro + Menu (mit Audio-Loop und 2 Titel) + Files und Chapter aus CM-txt.file
    --> Intro ok, Menu ok, Chapter ok, aber an den Schnittstellen "Bildruckler"
    Fall B mit DVDAuthorGUI:
    Menu (mit 2 Titel) + Files und Chapter aus CM-txt.file
    --> Menu ok, Chapter ok, Schnittstellen ok
    Gleiches Ergebnis wenn man Intro, Menu und Chapter wegläßt.


    Da ich mit GfD hervoragend zurechtkomme (ich vermisse eigentlich nur noch den Button fürs Kaffeekochen:D), aber selber noch nicht feststellen konnte woran es liegt, mal die Frage an alle: Irgendeine Idee?????


    Grüße aus dem Ruhrgebiet
    Christian



    PjX: v0.90.4.00, Java 1.6.0
    CM: v1.69a, CuttyEnc 1.2.0.2
    GfD: 1.04
    DVDAuthorGUI: 1.014


    System: XP Pro SP2, Asus A8N-SLI Premium, AMD X2 4800+ rev.E6 (939), OCZ 400/2048 PC3200 2GB Dual Channel, Asus EN7800GTX, Hitachi SATA-II HDD (3x250GB)

  • Könnte daran liegen, dass nach dem Entfernen der Werbung der Timecode des MPEG-Videomaterials nicht mehr fortlaufend ist. Das darf auf DVDs nicht sein. Einem Authoringtool sollte man immer optimales Material vorsetzen.


    Schau doch mal, ob es besser funktioniert, wenn du den Timecode regenerieren läßt (für elementares Video = m2v mit ReStream). Cuttermaran (falls du den mit "CM" meinst) tut das wohl nicht?

  • 1. Hatte ich noch nie
    2. Ich schneide mit M2S (wobei ich nicht weiß, ob das einen Unterschied macht)
    3. Falls es sich um 'sauberes' Material handelt, zuerst mal versuchen die DVD mit MuxMan als authoring engine zu erstellen.
    4. Falls das auch nicht geht, kannst Du mal den dvdauthor Pfad in GfD auf denjenigen von DVDAuthorGUI 'verbiegen' und dann testen. Einige Optionen darfst Du dann aber nicht verwenden: Kurzes Log file, Special colors bei Untertiteln, 16:9 Menüs.
    4a. Es gäbe noch die mingw Version der dvdauthor suite. Auf den ersten Test hin ist die verwendete mplex version da besser, und vmtl. ist mplex für die Ruckler verantwortlich (ich würde ja komplett auf die mingw Version umsteigen, allerdings gibt es leider noch ein 'Speicherloch' bei png2yuv). Siehe: http://forum.gleitz.info/showpost.php?p=352309&postcount=52


    EDIT: LigH
    Du bist ja vmtl. MOD hier... Kommst Du an die email Adresse von ssbssa ran? Wäre schön, wenn man das png2yuv Problem noch lösen könnte, aber ssbssa ist wohl schon länger nicht mehr hier im Board und er hat (leider) angegeben, keine Mails über das Board zu akzeptieren.

  • Hui, das ging aber fix mit der Antwort;)


    Danke erst mal für die schnelle Reaktion, bisher ist mir das bei GfD auch nicht aufgefallen, das lag aber eher daran, das ich zu 98% meine eigenen Aufnahmen bearbeitet hatte (da gibt's halt keine Werbung drin).


    borax
    zu 1. Als ich jetzt in den Folgen einer alten TV-Serie die Werbung entfernt hatte, sind mir die unsauberen "Bildübergänge" an den Schnittstellen aufgefallen. Die treten in dem Fall auf, wenn vorher mit CM framegenau (Cut-In und Cut-Out auf beliebigem I-/B-/p-Frame) geschnitten wird, bei Schnitten (Cut-In auf I-Frame, Cut-Out auf letztem p-Frame vor folgendem I-Frame) gibt es keine Probleme, aber das kommt ja sehr selten vor.


    Worüber ich mich gewundert hatte, war das mit der anderen GUI die Übergänge glatt laufen, egal an welchen Frames geschnitten wurde. Beide GUI's arbeiten ja überwiegend mit den gleichen Tools (dvdauthor, mplex, etc.), das Ergebnis ist aber bei identischem Quellmaterial unterschiedlich.


    zu 2. M2S von Martin schneidet beim Cut-In auf I-Frames, beim Cut-Out entweder auf I- oder P-Frames, aber nicht auf B-Frames, CM dagegen beliebig.
    EDIT: M2S ab Version 0.9 schneidet auch framegenau.


    zu 3. und 4. probier ich nachher mal aus.


    EDIT: zu 3. Der Wechsel auf MuxMan als authering engine führt zu einem flüssigen Übergang, kein Übergang oder unsauber "Bildübergang" an den Schnittstellen mehr zu erkennen, ich habe dabei das identische Quellmaterial - m2v/mp2-file - verwendet wie vorher (Schnitte also an B-Frames).
    --> Qualitativ einwandfrei!!!!!!
    Mit dvdauthor als engine werden die Schnitte an den B-Frames anscheinend anders verarbeitet, bzw. das Problem liegt augenscheinlich an der veränderten GOP-Struktur (kürzere Länge) der Schnittstellen.


    LigH
    ja, daran hatte ich zuerst auch schon gedacht und die timestamps (restream v0.9.0) zurückgesetzt, aber auch da war das Ergebnis identisch --> GfD: Ruckler an Schnittstellen, DVDAuthorGUI flüssiger Übergang. Der Unterschied ergibt sich erst beim/nach dem Authoring.
    Und stimmt,:D mit CM ist Cuttermaran gemeint.

  • borax
    Ups, Asche auf mein Haupt
    Stimmt, ist in den 0.9.er Versionen von M2S möglich (ich sollte mal meine alte 0.87 auf den neuesten Stand bringen). Ich korrigier das gleich in der anderen Antwort.


    Wie schon geschrieben, danke nochmal für den schnellen Hinweis & die Hilfestellung, das war übrigends das erste Mal das ich beim bearbeiten von Streams mit deinem Programm ein Problem feststellen konnte (seit der 0.7 Version bin und bleibe ich überzeugter Benutzer, sowohl in Bedienung/Bearbeitungszeit, als auch im Ergebnis, übertrifft es viele kommerzielle Programme).
    Anm: Ich werde nämlich häufig belächelt, weil ich im privaten Bereich (beruflich, naja da fällt mir nur folgendes Zitat zu ein: "Friß Vogel oder stirb";)) überwiegend "vernünftige" Software verwende, mit dem Hauptaugenmerk auf Funktionalität, Stabilität und Qualität.


    LigH

    Zitat

    Meine zweite Vermutung wäre ansonsten wohl "non-seamless cell" gewesen...


    Ich hatte mir mit IFO/PGC schon die Titlestruktur, respektive die Chapter und Cuts angeschaut, aber nichts ungewöhnliches gefunden, soll heißen ich konnte auch keine unnötigen Layer-Breaks entdecken. Ich denke mal, das du das damit meintest.

  • Zitat

    ... Tests mit den verschiedenen dvdauthor bzw. mplex Versionen durchführen könntest.


    Ich denke das sollte kein Problem darstellen, einen kurzen (am Wochenende steht der Sport an erster Stelle) Test habe ich vorhin mal durchlaufen lassen, siehe readme im rar-Archiv, ich schau es mir aber auch selber nochmal genauer an.
    Mit der mingw-version befasse ich mich nächste Woche nochmal.


    Schönes Wochenende
    Christian

  • Hi,
    ich hab mir die Ergebnisse (also unterschiedliche tool-Versionen) noch mal genauer angeschaut. Die Unterschiede hänge ich als txt-file mit an.


    Eine einfache Änderung in den VOB's geht anscheinend, ist aber nicht unbedingt praktikabel, weil zusätzlich zu den Parameter-Werten auch die kompletten MPEG Frames manuell geändert werden müssten (das ist ziemlich aufwendig :zunge:).


    Wenn ich mit meiner Vermutung (Wertberechnung oder Wertübergabe) richtig liege, könntest du u.U. die Änderung im Quellcode direkt vornehmen, denn die Funktion selber läuft ja fehlerfrei.

  • Könnte sein, auf jeden Fall geht der Thread in dieselbe Richtung, ich schau mir mal die Änderungen an, die du im ursprünglichen Source gemacht hast, vielleicht finde ich ja was. Allerdings sind meine Kenntnisse über die mpeg- und VOB-Strukturen nur interessehalber angelesen.
    Vielleicht kann bigotti5 ja was dazu sagen, falls er noch aktiv ist.


    Auf der anderen Seite, mit MuxMan funktioniert es doch einwandfrei, und wenn es bekannt ist, dann müssen bei der Verwendung von dvdauthor die Schnitte entsprechend gesetzt werden, das kann doch jeder bei der Verwendung vorher berücksichtigen!
    :D-IRONIE-IRONIE- Softwareprodukte wie XP oder Vista haben auch ihre "kleinen" Macken, nur gibt es da selten alternative Wege, eher ein "Das ist halt so!" -IRONIE-IRONIE-:D.

  • bigotti5 würde uns helfen, braucht aber (natürlich) ein Beispiel. Also eine 'möglichst kurze' vob/ifo die einmal mit 'meiner' dvdauthor Version erstellt wurde (mit dem Fehler) und einmal mit der 'Standard' Version (z.B. aus dvdauthorgui). Könntest Du da was zusammenstellen?
    Bzgl. MuxMan: Wie schon gesagt, verwende ich persönlich dvdauthor eigentlich gar nicht mehr. Es gibt aber hin und wieder mal 'unDVD' Auflösungen (z.B. 480x576 oder 544x576), und da streikt MuxMan. Isb. bei DVB-T soll es häufig solche Streams geben. Daher wäre ich schon daran interessiert, das Problem zu lösen.

  • Klar, das geht natürlich.
    Ich hatte ja auch schon für die Test's einen kurzen Schnitt verwendet (ca. 2min = ca. 55MB), wenn ich alles zusammenpacke, dürften das ungefähr incl. der tmp-files ca. 300MB werden.
    Das wären dann die Konstellationen:
    GfD mit dvdauthor, version 0.6.14-GfD-1
    DVDAuthorGUI mit dvdauthor, version 0.6.14. (sourceforge.net)
    GfD mit dvdauthor, version 0.6.14. (sourceforge.net)
    Soll ich dir das ganze auf eine DVD brennen und schicken, oder über z.B. rapidshare hochladen?
    Zu den "unDVD" Auflösungen kann ich wenig sagen, damit hatte ich bisher noch nichts zu tun.

  • Nun ja, damit sowohl bigotti5 als auch ich an die Files ran kommen, wäre eine Download-Möglichkeit schon vorzuziehen. Aber müssen es wirklich 2min sein? Probier doch erst mal, ob man den Fehler nicht auch schon mit ~10 sek 'provozieren' kann. Dann wären es vmtl. weniger als 10 MB pro Konstellation...
    Auf alle Fälle schon mal DANKE für Deine Mithilfe!

  • Da ist was Wahres dran.
    Ich hab es auf ungefähr 4 sec. gekürzt, den Übergang sieht man noch deutlich (aber nicht kurz 'n Schluck Kaffee nehmen, dann ist es schon zu Ende:lol:)
    Alle drei Variationen sind in einem rar-file, und können unter der folgenden URL abgerufen werden:


    http://rapidshare.de/files/39710137/GfD-short_cut.rar.html
    File-Grösse: ca. 12,5MB


    Kurze Frage noch:
    Hast du deine Änderungen (vobu_s_ptm, vobu_e_ptm?) im Source eigentlich dokumentiert oder nur alle kenntlich gemacht?

  • Danke schon mal!


    Änderungen sind 'nur kenntlich gemacht'...

    Du kannst nach folgenden Strings suchen (in dvdvob.c):

    Code
    1. if((vi->sectpts[1]-vi->sectpts[0])<36000) {
    2. // Vobunit MUST be at least 0.4 sec=36000 pts ticks
    3. // fprintf(stderr,"Warning: Vobunit to short: %d\n",(vi->sectpts[1]-vi->sectpts[0]));
    4. write4(buf+0x39,vi->sectpts[0]); // vobu_s_ptm
    5. write4(buf+0x3d,(vi->sectpts[0]+36000)); // vobu_e_ptm
    6. } else {
    7. write4(buf+0x39,vi->sectpts[0]); // vobu_s_ptm
    8. write4(buf+0x3d,vi->sectpts[1]); // vobu_e_ptm
    9. }
  • Zum Ruckelproblem:

    Beim framegenauen Schneiden von MPEGs entstehen oft sehr kurze GOPs. So auch hier.
    Die GOPs 6,7 und 12 sind nur 3 Frames lang (120ms).
    Eigentlich sollte jetzt das Authoringprogramm diese kurzen GOPs mit den davor oder dahinder liegenden GOPs zu einer gültigen VOBU (>=400ms und <=1000ms) zusammenfassen. Tut DVDAuthor nicht. Jede GOP wird eine eigene VOBU.
    Die Modifikation von Borax führt jetzt leider dazu, dass bei den kurzen VOBUs hier das dritte Frame für 320ms angezeigt wird und damit Ruckeln erzeugt.
    Außerdem werden die PTMs der folgenden VOBUs und die Cell Elapsed Time bzw Cell Playback Time nicht angepasst.


    VOBU 6
    2 sec 8 fr (Cell time)
    Start PTM 225419
    End PTM 261419 (= 36000 Ticks = 10 Frames)
    in der VOBU sind aber nur drei Frames enthalten (BBI)

    VOBU 7
    2 sec 11 fr (hier müsste jetzt aber 2.18 stehen)
    Start PTM 236219 (Start der VOBU vor dem Ende der vohergehenden)
    End PTM 272219 (= 36000 Ticks = 10 Frames)
    in der VOBU sind nur drei Frames enthalten (IBP)

    Das Authoringprogramm sollte GOP6,7 und 8 zu einer VOBU muxen.

  • Vielen Dank für die Analyse! Ich fürchte aber, dass ich mit meinen bescheidenden C-Kenntnissen keine saubere Lösung hinkriege. Daher muss das entweder jemand anders machen (sauber - sprich dafür sorgen, dass dvdauthor GOP6,7 und 8 zu einer VOBU muxt) oder ich mach meine Modifikation einfach 'abschaltbar'. Die Modifikation wird dann nur noch für single frame Menüs verwendet.


    Leider melden sich die mingw Leute nicht mehr. Ich könnte also nur eine neue Cygwin Lösung compilieren.

  • Ich hab mir mal den Source angeschaut, korrigier mich ruhig falls ich falsch liege, soweit ich das erkennen kann, handelt es sich ja um die iterative Abarbeitung des Streams und die Konvertierung in eine VOB-Struktur.
    Die Änderungen hattest du ja wegen einem spezifischen Problem mit einem SA-Player gemacht, und dvdauthor hält sich ja bezüglich der VOBU-Beschränkungen nicht unbedingt an die Spezifikationen, siehe der andere Thread.


    Anscheinend ist auch gar nicht vorgesehen das zu kurze GOP's separat behandelt werden (bzw. beim Durchlaufen/Abarbeiten der for-Schleife wird ja jeweils nur ein pointer auf vi gesetzt, und in den Strukturen "vob" und "vobuinfo" von -da-internal.h- finde ich keine var/struct Definitionen, um ggf. auf Grund einer zu kurzen Länge den aktuellen Speicherinhalt zu übergeben und zwischenzuspeichern).
    Die write*-functions selber schreiben ja nur den aktuellen Speicherinhalt und die aktuell übergebenen Werte zurück.


    Theorethisch müsste nach Feststellung der ersten kurzen GOP, diese und folgende als Struktur temporär im Speicher gehalten werden, um sie mittels Übergabe an eine separate void-function mit der vorhergehenden, oder der(den) nachfolgenden GOP(s), in eine VOBU zusammenzufassen, wobei hier dann eine case-Auswahl benötigt wird.
    Das dürfte allerdings nicht mal eben Q&D zu lösen sein, und geht glaube ich auch über meine Möglichkeiten hinaus:(


    Als Möglichkeit würde ich aber deine Lösung auf jeden Fall 'drin' lassen, bei paicolman hat sie ja funktioniert, und ansonsten bleibe ich dabei, das kann man bei den Schnitten ja schon berücksichtigen.