Vorgehensweise: Wie jetzt Material mit MBAFF kodieren?

    Hallo zusammen,


    ja ich weiß, dass Thema wurden an vielen Stellen bereits behandelt, aber ich blicke da nach wie vor nicht durch, im Gegenteil: Je mehr ich lese, desto verwirrter bin ich...


    Ich habe hier ein File, bei dem mir MediaInfo als Scantyp MBAFF ausgibt, BDInfo zeigt mir dabei 1080i an. Wie müsste ich das ganze jetzt kodieren, wenn ich das Format beibehalten will? Normal progressiv? Oder per --tff oder --bff?


    Und wie kann ich am besten herausbekommen, welches Field zuerst dargestellt wird? Erst mal kodieren und dann schauen kann es auch nicht sein. Ich denke mal dass es gut sein könnte, dass sich dies pro Track auf der BD ändern könnte...


    Das Problem dürfte einige Files bei mir betreffen, und bevor ich da schon wieder tagelang kodiere und merke dass da was falsch ist frage ich lieber noch mal nach...



    Besten dank für die Geduld...^^


    Lapje

    Nein, ich will das Material so belassen wie es ist...wenns mbaff ist halt progressiv, wenns interlaced ist, dann soll es interlaced bleiben...die Frage war jetzt auch auf reines 1080i-Material bezogen...

    Lieber nicht...ich hab bis jetzt noch keinen Deinterlacer gefunden, der wirklich saubere Arbeit leistet, irgendwelche Schwachstellen sind da immer...und selbst wenn man einen guten hat, dann dauert es teilweise recht lange...zumindest liefert mein TV dabei eine deutlich bessere Quali...

    Deinterlacing macht aber IMMER Sinn, wenn das vorliegende Material ursprünglich progressiv gedreht wurde und erst nachträglich über irgendwelche obskuren Methoden zu interlaced Video verwurstet wurde. Denn dann kann man häufig die ursprünglichen(!!!) Vollbilder wieder aus den Halbbildern zusammensetzen (und das Ergebnis ist dadurch besser(!), als es die vergleichsweise dummen Automatik-Deinterlacer von TV-Geräten hinkriegen, die üblicherweise nur mehr oder minder simple Interpolationsverfahren nutzen, um die Halbbilder zu Vollbildern hoch zu rechnen).


    Nicht deinterlacen sollte man einzig und allein dann nicht, wenn das Quellmaterial schon so versaut wurde, dass sich die ursprünglichen Vollbilder nicht mehr rekonstruieren lassen... ODER wenn das Quellmaterial interlaced gedreht wurde.

    Im Zweifelsfall: nur mit den eigenen Augen -> indem du z.B. das fragliche Video per AviSynth lädst, per SeparateFields die verschachtelten Halbbilder trennst, dir eine Szene mit 'nem gleichmäßigen Kameraschwenk o.ä. suchst und dann schaust, ob Halbbilder doppelt (= mit gleichem Bewegungszustand) vorhanden sind und ob es da einen Rhythmus in der Wiederholung gibt. Bei ECHTEM (schon interlaced aufgenommenem) Material gibt es nämlich bei Bewegung im Bild (also eben z.B. einem Kameraschwenk) NIE zwei Halbbilder mit identischem Bewegungszustand.

    So ein Vorgehen kenne ich noch in ähnlicher Form von mpg-Material...da habe ich das, wenn ich mich recht erinnere, immer in VDub geladen.

    Zitat

    loadplugin("C:\Programme\DGIndex 1.5.5\dgdecode.dll")
    MPEG2Source("xyz.d2v")
    bob()

    Da konnte ich dann immer ein Bild weitergehen....interlaced wirkte dabei deutlich weicher...


    Verstehe ich das richtig dass ich jetzt hier ein Stück testweise so encode und später anschaue? Oder gibt es eine Möglichkeit wie oben?

    Zitat von Lapje

    So ein Vorgehen kenne ich noch in ähnlicher Form von mpg-Material...da habe ich das, wenn ich mich recht erinnere, immer in VDub geladen.


    Das Quellformat ist dabei vollkommen egal. Das geht mit HD- und SD-Videos... mit MPEG2-, H.264-, VC1-, XviD/DivX- oder sonstigen Videokompressionsformaten... im MPG-, AVI-, MKV-, M2TS- oder anderem Container.



    Zitat von Lapje

    Da konnte ich dann immer ein Bild weitergehen....interlaced wirkte dabei deutlich weicher...


    Danach gibt's aber kein Interlacing mehr. Bob ist ein extrem simpler Deinterlacer -> er trennt einfach die Halbbilder, skaliert sie bikubisch auf doppelt Höhe (für korrekte Vollbild-Größe) und zeigt sie nacheinander an. Die Reihenfolge, welches Halbbilder zuerst angezeigt wird, hängt dann (wie immer) davon ab, ob der interlaced Videostream TFF oder BFF vorliegt. Im Grunde ist Bob() also so ziemlich das selbe wie:


    Code
    1. SeparateFields()
    2. BicubicResize(Breite, Höhe*2)



    Zitat von Lapje

    Verstehe ich das richtig dass ich jetzt hier ein Stück testweise so encode und später anschaue? Oder gibt es eine Möglichkeit wie oben?


    Wieso encoden? Wie oben schon geschrieben: AviSynth ist das Quellformat vollkommen egal... intern wird eh immer mit unkomprimiertem Video gearbeitet. Hauptsache ist nur, dass du ein AviSynth-Source-Plugin hast, welches das Quellvideo laden und decodieren kann -> z.B. L-SMASH. Dann erzeugst du ein Script - mit L-SMASH z.B.:


    Code
    1. LoadPlugin("C:\Pfad_zur\LSMASHSource.dll")
    2. LWlibavVideoSource("C:\Pfad_zur\Videodatei.Dateiendung")
    3. SeparateFields()


    ... lädst das dann in VirtualDub, suchst dir eine Stelle mit Kameraschwenk und blätterst dort Einzelbild für Einzelbild vorwärts. Encoden musst du dafür gar nichts.

    Nein, Du hast mich ein wenig missverstanden...


    wenn ich das avs so in VDub gelande habe, konnte ich mit dem Pfeiltasten immer ein Bild weitergehen und daran erkennen, ob es interlaced war oder prog. Bewegung nach jedem Tastendruck: Interlaced. Bewegung alles zwei Bilder: Progressiv. Bewegung mal so mal so: Anscheinend Normwandlung. Danach konnte ich dann entscheiden, wie ich das Material kodiere. Das meinte ich damit...


    Und anscheinend muss ich das jetzt auch mit VDub machen. Wobei ich immer dachte dass VDub HD-Material oder x264 und so nicht nimmt. Aber wenn das doch funzt dann ist das ja prima...

    Zitat von Lapje

    Nein, Du hast mich ein wenig missverstanden...


    wenn ich das avs so in VDub gelande habe, konnte ich mit dem Pfeiltasten immer ein Bild weitergehen und daran erkennen, ob es interlaced war oder prog. Bewegung nach jedem Tastendruck: Interlaced. Bewegung alles zwei Bilder: Progressiv. Bewegung mal so mal so: Anscheinend Normwandlung. Danach konnte ich dann entscheiden, wie ich das Material kodiere. Das meinte ich damit...


    Das ist doch im Prinzip schon das, was ich ich mit:

    Zitat

    Im Zweifelsfall: nur mit den eigenen Augen


    ... meinte ;) .


    Wobei es in der Praxis noch komplizierter werden kann! Zum Beispiel hast du dann bei phase-shifted interlaced Video auch nur alle zwei Bilder Bewegung, weil vom ursprünglich progressiven Ursprungsmaterial die Halbbilder um ein Frame versetzt gemischt wurden - sprich: alle geraden Bildzeilen vom ehemals progressiven Frame 1 sind mit allen ungeraden Bildzeilen aus Frame 2 verwoben -> alle geraden Bildzeilen vom Frame 2 sind mit allen ungeraden Bildzeilen aus Frame 3 verwoben -> alle geraden Bildzeilen vom Frame 3 sind mit allen ungeraden Bildzeilen aus Frame 4 verwoben -> usw.! Daher ist das Video (TROTZ Bewegung alle zwei Bilder) interlaced und hat das dafür typische Kamm-Muster. In dem Fall wäre TFM zum Deinterlacen sinnvoll, da es automatisch erkennt welche Halbbilder ursprünglich ein Vollbild bildeten, und die Halbbilder dementsprechend zusammenfügen kann.



    Zitat von Lapje

    Und anscheinend muss ich das jetzt auch mit VDub machen. Wobei ich immer dachte dass VDub HD-Material oder x264 und so nicht nimmt.


    Ich wundere mich immer, woher der Glaube kommt, dass HD-Videos so viel anders als SD-Videos sind. Nur die Auflösung (= Pixelanzahl je Frame) ist höher - das war es dann aber auch schon. Solange man keine Software einsetzt, die an irgendeiner Stelle die Auflösung künstlich begrenzt, gibt es keinen Unterschied bei der Bearbeitung. VirtualDub könnte dementsprechend auch ein 8K-Video öffnen - das interessiert es herzlich wenig.


    Außerdem: wenn man ein Video per AviSynth-Script in VirtualDub lädt, dann erledigt AviSynth die Decodierung und NICHT VirtualDub! VirtualDub bekommt dann nur das decodierte/unkomprimierte Ergebnis von AviSynth geliefert. VirtualDub kann also das Kompressionsformat des Videos vollkommen egal sein!

    Zitat von TomKeller


    Wobei es in der Praxis noch komplizierter werden kann! Zum Beispiel hast du dann bei phase-shifted interlaced Video auch nur alle zwei Bilder Bewegung, weil vom ursprünglich progressiven Ursprungsmaterial die Halbbilder um ein Frame versetzt gemischt wurden - sprich: alle geraden Bildzeilen vom ehemals progressiven Frame 1 sind mit allen ungeraden Bildzeilen aus Frame 2 verwoben -> alle geraden Bildzeilen vom Frame 2 sind mit allen ungeraden Bildzeilen aus Frame 3 verwoben -> alle geraden Bildzeilen vom Frame 3 sind mit allen ungeraden Bildzeilen aus Frame 4 verwoben -> usw.! Daher ist das Video (TROTZ Bewegung alle zwei Bilder) interlaced und hat das dafür typische Kamm-Muster. In dem Fall wäre TFM zum Deinterlacen sinnvoll, da es automatisch erkennt welche Halbbilder ursprünglich ein Vollbild bildeten, und die Halbbilder dementsprechend zusammenfügen kann.


    Gibt es eigentlich Menschen die über das Thema den Verstand verloren haben? ^^



    Zitat von TomKeller


    Ich wundere mich immer, woher der Glaube kommt, dass HD-Videos so viel anders als SD-Videos sind. Nur die Auflösung (= Pixelanzahl je Frame) ist höher - das war es dann aber auch schon. Solange man keine Software einsetzt, die an irgendeiner Stelle die Auflösung künstlich begrenzt, gibt es keinen Unterschied bei der Bearbeitung. VirtualDub könnte dementsprechend auch ein 8K-Video öffnen - das interessiert es herzlich wenig.


    Soweit ich weiß konnte VDub damals nichts mit dem Codec anfangen...aber das würde ja dem


    Zitat von TomKeller


    Außerdem: wenn man ein Video per AviSynth-Script in VirtualDub lädt, dann erledigt AviSynth die Decodierung und NICHT VirtualDub! VirtualDub bekommt dann nur das decodierte/unkomprimierte Ergebnis von AviSynth geliefert. VirtualDub kann also das Kompressionsformat des Videos vollkommen egal sein!


    widersprechen...und da hast Du sicherlich mehr Ahnung als ich...


    Wie dem auch sei, gut zu wissen dass das doch noch funzt...

    Zitat von Lapje

    Gibt es eigentlich Menschen die über das Thema den Verstand verloren haben? ^^


    Der Witz an der Sache ist: das Thema "Interlacing" ist im Bereich der Videobearbeitung bei weitem nicht das komplizierteste Gebiet ;) . Und es ist nicht mal wirklich schwierig, wenn man sich schlicht und einfach klar macht, dass Interlacing nichts anderes als das hier ist:



    ... nur mit Pixelzeilen statt Fingern :rolleyes: .



    Zitat von Lapje

    Soweit ich weiß konnte VDub damals nichts mit dem Codec anfangen...


    Das gilt nur, wenn du ein Video DIREKT IN VirtualDub öffnest... OHNE Mitwirken von AviSynth.


    Wenn du jedoch ein Video über AviSynth lädst, dann decodiert AviSynth das Video (über sein Source-Plugin) und leitet das decodierte/unkomprimierte Videobild an VitualDub weiter. VirtualDub weiß dann nicht mal, dass das ursprüngliche Video komprimiert ist, da VirtualDub ja nur das unkomprimierte Video geliefert bekommt.


    Das ist so, als ob du ein komprimiertes MPEG2-, H.264- o.ä. Video in ein unkomprimiertes AVI-Video umwandelst und das unkomprimierte AVI-Video dann in VirtualDub öffnest -> das klappt ja auch!!! Mit AviSynth passiert genau das gleiche... nur eben OHNE das Zwischenspeichern des unkomprimierten Videos als AVI-Datei.

    Zitat von TomKeller


    Der Witz an der Sache ist: das Thema "Interlacing" ist im Bereich der Videobearbeitung bei weitem nicht das komplizierteste Gebiet ;) . Und es ist nicht mal wirklich schwierig, wenn man sich schlicht und einfach klar macht, dass Interlacing nichts anderes als das hier ist:


    ... nur mit Pixelzeilen statt Fingern :rolleyes: .


    Das reine Interceing meine ich dabei ja nicht mal, aber diese ganzen "Mischformen", das Verweben, die Normwandlungen ect...