• In DGAVCDec siehst du es eventuell nicht, weil die Vorschau dort wahrscheinlich nur die halbe Größe hat - dadurch siehst du dann immer nur das eine von beiden Halbbildern.

    Wie bereits allseits empfohlen, wäre eine der sichersten Methoden, sich ein Skript der Art { AVCSource("*.dga").SeparateFields().Bob() } anzuschauen -- Bild für Bild in VirtualDub langsam vorwärts gehend, auf Muster in den Bewegungen achtend (Bewegung/Stillstand, vor/zurück).

    Die von dir vorgeschlagene Methode (einfach mal dumm resizen) wäre vermutlich auch insofern relativ "sicher", als dass dabei wahrscheinlich sehr starke "Wellen-Kämme" zu sehen sein werden, wenn das Original doch interlaced war. Dann siehst du wenigstens ganz klar, warum das die falsche Methode ist, wenn sie unangebracht war.

  • Also interlaced ist - das habe ich jetzt doch nicht übersehen können.

    Allerdings gefällt mir die Lösung mit Bob nicht so dolle und die mit SeperateFields geht gar nicht.

    Gibts noch ne gute Alternative?

    -= kein Bild, kein Ton - Valoron =-

  • Die beiden sind doch bloß zum Testen! Und zwar nicht nur, ob unterschiedliche Halbbilder (combing) vorhanden sind, sondern auch in welcher Art und Weise -- also ob es vielleicht statt "üblichem Interlacing" (gleichmäßige Veränderung von Halbbild zu Halbbild) doch eher was anderes ist, wofür man etwas anderes braucht als einen Deinterlacer.

    Jetzt kommt es darauf an - welche Art von Halbbildfolge ist es genau?

    a) Normales Interlacing (gleichmäßiges Fortschreiten der Bewegung von Halbbild zu Halbbild): Da hilft meist TDeint() mit Standardwerten.

    b) Eigentlich gar kein Interlacing, sondern nur Fieldshift (Bewegung - Stillstand - Bewegung - Stillstand): "Einfach nur" Halbbilder neu mischen.

    c) Irgend was anderes? Dann lass mal sehen...

  • Allerdings gefällt mir die Lösung mit Bob nicht so dolle und die mit SeperateFields geht gar nicht.


    Das sind ja auch keine Vorschläge zur "Lösung" !

    Du hattest gefragt:

    Woran kann ich denn jetzt erkennen ob es interlaced ist oder nicht?


    - und LigH hat Dir gesagt, wie man das einfach & zuverlässig kontrolliert. Entweder Bob oder SeparateFields, und dann in der Einzelbildschaltung sehen, welches Muster auftaucht.

    Bewegung-Stop-Bewegung-Stop-... ... ist Progressiv. (oder Phase Shift.)

    Bewegung-Bewegung-Bewegung-Bewegung-... ... ist "Interlaced".

    Bewegung-Stop-Bewegung-Stop-Stop-Bewegung-Stop-Bewegung-Stop-Stop-... ... ist Pulldown (NTSC).
    ___

    Ah, wieder zu lange rumgetrödelt beim Tippen ...

  • Sorry ;)

    Habe wie gesagt von Interlace keinen blassen Schimmer.

    Was mir gerade zusätzlich noch Kopfschmerzen bereitet ist, dass VirtualDub des öfteren Artefakte in mein Bild haut.

    -= kein Bild, kein Ton - Valoron =-

  • Das muss auch nicht wirklich besorgniserregend sein: Die letzte Version von DGAVCDec (ohne *NV) hatte noch einen Decoder verwendet, der noch nicht mit allen AVC-Varianten des Interlacing zurechtkam. Ein aktuelles FFMPEGSource2 unterstützt AVC inzwischen komplett, ebenso DGDecNV (kostenpflichtig, und erfordert CUDA-Grafikkarte, also GeForce ab 8xxx).

  • Danke!

    Ich werde das heute abend mal ausprobieren.

    Mach das eigentlich den Kohl fett, wenn ich den Stream umcontainer?

    Grundsätzlich demuxe ich den 264 Stream immer und indiziere dann mit DGAVCIndex.

    -= kein Bild, kein Ton - Valoron =-

  • Zitat

    Mach das eigentlich den Kohl fett, wenn ich den Stream umcontainer?


    Je nach Streamdatenrate und -länge kann kann die Containerauswahl einiges ausmachen, vor allem wenn man auch Transportstreamcontainer betrachtet (.m2ts, .ts, .mts) Bei avi/mkv/mp4 /mov sind die Unterschiede i.d.R. +/- 4% (was je nach Größe des Stream natürlich auch ein paar MB sein können).

  • beunruhigen tut mich folgender Auszug aus der doc. von FFMPEGSOURCE 2

    Zitat

    Compatibility


    • AVI, MKV, MP4, FLV: Frame accurate
    • WMV: Frame accurate(?) but avformat seems to pick keyframes relatively far away
    • OGM: Frame accurate(?)
    • VOB, MPG: Seeking seems to be off by one or two frames now and then
    • M2TS, TS: Seeking seems to be off a few frames here and there
    • Image files: Most formats can be opened if seekmode=-1 is set, no animation support

    Da meine Source eine M2TS Datei ist, wäre es doch wissenswert, ob ich mich der Gefahr fehlender Frames entziehen kann, wenn ich das M2TS mal eben mit MKVMERGE in einen MKV Container verwandel?!?

    Und sehe ich das richtig, dass ich bei Verwendung von FFMPEGSOURCE2 kein Indexfile mehr erstellen muss?

    -= kein Bild, kein Ton - Valoron =-

  • Beim "Seeking" geht es um das Springen zu beliebigen Frames; beim Konvertieren aber liest man meist von Anfang an durchgängig - da dürfte das Risiko relativ gering sein (außer man hat Trim()-Kaskaden).

    Das Transmultiplexen in MKV ist aber auch keine schlechte Idee; dessen Overhead ist auch geringer (die Kopie dürfte schon durch den Kontainer kleiner werden).

    FFMS2 indexiert automatisch vor der ersten Nutzung einer Quelldatei. Siehe auch beigelegtes *.avsi-Skript mit zusätzlichen nützlichen Funktionen zur Automatisierung.

  • Dann bin ich ja beruhigt, aber wie wende ich das ganze denn jetzt am sinnvollsten an?

    Gehe ich da jetzt mehr oder weniger genauso vor wie mit DGAVCIndex?

    Also indizieren kann ich mir schenken, nur ffms2.dll im .avs Skript laden und dann
    die .mkv via FFVideoSource laden?

    -= kein Bild, kein Ton - Valoron =-

    3 Mal editiert, zuletzt von Hans Dampf (23. Juni 2010 um 11:50)

  • So, ich habe jetzt mal meinen h264 Stream in ein MKV gepackt und mittel FFVideoSource in VirtualDub analysiert.

    Bei FFMSINDEX sieht das Bewegunsmuster in Ordnung aus.

    Allerdings habe ich mal Yadif mit meinen nicht vorhandenen Kenntnissen angewendet und das Ergebnis flackerte.

    Ich habe jetzt die m2ts noch mal DGAVCIndex indiziert und dort ungefähr dieses Muster analysiert.

    Bewegung Bewegung Bewegung Bewegung Bewegung Bewegung Bewegung Stop

    Bei DGAVCIndex unter Vewendung von BOB sieht bei Prüfung durch Virtual Dub jeder zweite Frame matschig aus.

    Bei FFMSINDEX und DGAVCINDEX sieht es so aus, als wenn immer ein Frame zurückgesprungen würde.

    Das mit der dga Datei erstellte File sieht allerdings nach dem Enkodieren mit Yadif in Ordnung aus.

    -= kein Bild, kein Ton - Valoron =-

    2 Mal editiert, zuletzt von Hans Dampf (23. Juni 2010 um 19:11)

  • Werde ich heute abend machen.

    Die mit DGAVDEC erstellte Datei sieht übrigens doch matschig aus.

    Ich habe das M2TS File heute Nacht mal durch Selurs Hybrid gejagt.

    Das sah zumindest schon mal in der Vorschau ordentlich aus.

    Kann das Ergebnis leider erst heute abend ansehen.

    -= kein Bild, kein Ton - Valoron =-

  • Also ich habe jetzt auch noch mal BFF anstatt TFF ausprobiert, aber es sieht auch nicht anders aus.

    Das mit Hybrid erziehlte Ergebnis (via Yadif) sieht tadellos aus und ist auch absolut sync. ;)

    -= kein Bild, kein Ton - Valoron =-

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!