aus 1080i (HDTV Aufnahme) verlustlos 1080p machen

    Hi, jedesmal wenn ich eine Aufnahme von einen Sender der 1080i ausstrahlt neu encoden will, lande ich bei der gleichen Frage.
    Mir ist so, also hätte ich mal gelesen, dass man verlustlos aus einer 1080i Austrahlung (mit 50 Halbbildern pro Sekunde) eine Variante mit 25 Vollbildern erstellen kann. (wenn das Ausgangsmaterial auch schon Progressiv war...)
    Daher meine kurze Frage: War das so und wenn ja, wie bekomme ich diese 50i zu 25p konvertierung in avisyth hin?

    Danke

    Edit: ich frage gleich mal mit: Angenommen ich habe tatsächlich mal eine Aufnahme, die auch in 50i Aufgenommen wurde (z.B. Sportübertragung) und ich möchte in x264 das Interlacing behalten, wie muss ich da das Avisynth-Script einstellen? Weil einfach den "interlaced" Parameter in den x264 Aufruf zu knallen, dürfte wohl nicht reichen? (also Quelle 1080i, mit DGavc indiziert und in avisynth eingebunden). Oder sollte man beim re-encoden von "echten" 1080i immer einen Deinterlacer verwenden, weil z.B. die integrierten aufgrund der theoretisch größeren verfügbaren Berechnungszeit die besseren Ergebnisse liefern als ein im TV integrierter?
    Oder sollte ich dafür lieber einen extra Thread aufmachen? Hat ja eigentlich nichts direkt mit meinen Thema zu tun, denn jetzt habe ich ja einen Kinofilm vorliegen.

    Einmal editiert, zuletzt von qupfer (23. März 2012 um 23:59)

    Doch, es ist tatsächlich so einfach. Wenn in dem 1080"i" tatsächlich 1080p Bildinhalt drinsteckt, dann muss man genau "gar nichts" machen. Genauso wenn es sich um "echtes" 1080i (z.B. Sport) handelt, und es interlaced von x264 kodiert werden soll: "gar nichts" machen, und bei x264 den --tff Schalter aktivieren.

    Das einzige was man NICHT machen sollte, ist 1080i mit DGAVCDec zu öffnen. Verwendet ein stark veraltetes libav, kann mit vielen interlaced-Streams nicht richtig umgehen.
    => Entweder DGDecodeNV, oder ffms2 (dafür sollte man das TS aber besser erst in MKV muxen).

    Danke dafür, ffms2 ist aber nicht die, die in megui schon enthalten ist, oder? Weil die hat mit dem Stream arge Probleme. Erstelle ich aus megui heraus eine ffmsIndex-Datei und öffne die (z.B. in virtualdub) dann ist das Video nicht zumutbar. Das ist ein extremes Geruckel und die Bewegunsabläufe sind grob so: Vorwärts-->Doppelbild/Überlagerung-->Rückwärts-->... Man kann das zwar "korrigieren" mithilfe von YADI und BFF aber irgendwas anderes scheint da dennoch nicht hinzuhauen.
    Lade ich es trotz Warnung durch "DGAVC" dann ist das Bild zwar schlecht und lauter klötzchen, aber die Bewegung haut hin. Mit DGIndexNV ist alles in Ordnung, nur hat der "eigentliche" Konverter-PC ne ATI Karte ;)

    Und nur um Irrtümer auszuschließen: Der --tff Schalter bezog sich nur auf echtes 1080i? Und mein pseudo 1080i behandel ich wie eine Progressiv-Aufnahme? Das ist ja einfach *freu*

    Einmal editiert, zuletzt von qupfer (24. März 2012 um 09:22)

    Zitat

    Das ist ein extremes Geruckel und die Bewegunsabläufe sind grob so: Vorwärts-->Doppelbild/Überlagerung-->Rückwärts-->...


    dann stimmt vermutlich die FieldOrder nicht, d.h. AssumeTFF() oder AssumeBFF() einfügen, dann sollte es auch nicht so ruckeln

    leider ist das mit AssumeTFF bzw. AssumeBFF genauso. :(
    Werde heute abend mal ein 30s Schnipsel hochladen *g Eventuell kann mir dann jemand sagen, warum ich das mit FFVideoSource nicht hinbekomme (habs jetzt auch mit einer frisch geladen Version versucht)

    ffms2 hat zumindest im Moment große Probleme mit H.264 interlaced ("insanity detected", oder dieses Hin- und Herspringen). Das Problem ist bekannt und an einem Fix wird gearbeitet.
    Derzeit also DGDecodeNV oder über DirectShow.

    DirectShow ist zum Anfang Sch..ße aber dann geht es.
    Und DGDecodeNV.....wahrscheinlich nicht schlecht......aber ATI-Grafikkarte. Ich verstehe bis heute nicht warum das für Nvidea entwickelt worden ist. Qualitätsmäßig ist ATI der Nvidea überlegen.

    Zu den wichtigsten Details mit FFmpegSource2 zählt, im Falle von Problemen zuerst "threads=1" zu versuchen; Multithreading ist noch eines derhöchsten Risikofaktoren, speziell bei leicht fehlerhaften oder noch nicht umfassend unterstützten Videoquellen.

    Haben die das immer noch nicht im Griff? ... Warum eigentlich, über DirectShow klappt's doch auch mit ff**/libav. (Ich mach' das meiste über DGDecodeNV (soweit möglich), deswegen krieg' ich die Probleme nicht so richtig mit ...)

    Multithreading abschalten kann helfen, ja. Auch einen anderen Demuxer probieren, ffms2 hat doch einen Parameter um den Demuxer explizit auszuwählen.


    Zitat von Propaganda

    DGDecodeNV..... Ich verstehe bis heute nicht warum das für Nvidea entwickelt worden ist. Qualitätsmäßig ist ATI der Nvidea überlegen.


    Na, na, na. Wir wollen hier jetzt kein Fanboy-Genöle lostreten, warum die eine Marke göttlich und die andere der letzte Dreck ist. Was immer die Vertreter der einen Fraktion behaupten - die Vertreter der anderen Fraktion behaupten so ziemlich das gleiche, nur andersrum. Recht hat der, der am lautesten schreit ... :rolleyes:

    Fakt ist: Donald Graft hat berichtet, dass Nvidia ausgesprochen entgegenkommend war, und sehr ausführliche und zielführende Hilfestellung gegeben hat, wie man das zu programmierende Interface denn am besten programmiert.
    Bei ATI war es angeblich genau das Gegenteil - die haben ihn völlig im Regen stehen lassen, auf ein paar verfügbare Whitepapers verwiesen und (sinngemäß) gemeint: "Wenn Dir das nicht reicht, dann biste halt zu doof."

    Bei der Konstellation hätte ich auch gewußt, auf welche der beiden Alternativen ich mich als Programmierer konzentriere ...

    Zitat von Didée

    Na, na, na. Wir wollen hier jetzt kein Fanboy-Genöle lostreten, warum die eine Marke göttlich und die andere der letzte Dreck ist. Was immer die Vertreter der einen Fraktion behaupten - die Vertreter der anderen Fraktion behaupten so ziemlich das gleiche, nur andersrum. Recht hat der, der am lautesten schreit ... :rolleyes:

    Fakt ist: Donald Graft hat berichtet, dass Nvidia ausgesprochen entgegenkommend war, und sehr ausführliche und zielführende Hilfestellung gegeben hat, wie man das zu programmierende Interface denn am besten programmiert.
    Bei ATI war es angeblich genau das Gegenteil - die haben ihn völlig im Regen stehen lassen, auf ein paar verfügbare Whitepapers verwiesen und (sinngemäß) gemeint: "Wenn Dir das nicht reicht, dann biste halt zu doof."

    Bei der Konstellation hätte ich auch gewußt, auf welche der beiden Alternativen ich mich als Programmierer konzentriere ...


    Okay Okay sowas wollte ich jetzt nicht auslösen und Du gibst auch Informationen von Dir,von denen ich nichts wußte. Bin sogar erstaunt das AMD sich da so quer stellt.
    Außerdem(muß ich ehrlich gestehen),bin ich von der älteren Technik ausgegangen. Wo ich für mich immer den Eindruck hatte,das ATI da eine bessere Videoqualität ablieferte als Nvidea. Wie das eigentlich heute aussieht,mit den GT-Modellen von Nvidea und der HD-Serie von AMD habe ich keine Ahnung. Weil ich bin kein Spieler und habe seit eh und je ne ATI verbaut mit der ich auch sehr zufrieden bin.
    Es ist nur Schade das ich ebend DGDecodeNV nicht nutzen kann. Und FFmpegSource2 habe ich bis heute nicht einmal sauber zum laufen bekommen. Naja....

    Zitat von Propaganda

    Und FFmpegSource2 habe ich bis heute nicht einmal sauber zum laufen bekommen. Naja....

    Und eben das wundert mich doch. Immerhin sind daran ja einige recht fähige Programmierer beschäftigt, die immer wieder mal Schnipsel reinkriegen, mit denen angeblich was nicht klappt, und dann ziemlich schnell entweder eine Empfehlung haben, welche Parameter man hätte einstellen müssen (threads=1 oder splitter...) oder welche Hilfestellung verwenden (Haali installieren oder Kontainer nach MKV konvertieren). Und wenn wirklich mal das Video schuld war, dann war es entweder wirklich allzu defekt, oder der Fehler konnte behoben werden.

    Mein Problem mit FFindex dürfte doch folgendes sein:

    Zitat

    Interlaced H.264 is decoded in an odd way; each field gets its own full-height frame and the fieldrate is reported as the framerate, and furthermore one of the fields (odd or even) may "jump around". To get the correct behavior, you can try setting fpsnum and fpsden so that the framerate is halved (may or may not work). This issue is caused by libavcodec.

    Nun habe ich "versucht" mittels fpsnum und fpsden eine feste Framerate einzustellen, aber auch ohne Erfolg :(

    Edit: ich habe mal ein Schnipsel zurecht geschnitten und hochgeladen

    Darin Enthalten ist
    ein *.ts File welches eine ~20s Szene enthält
    das gleiche als MKV
    und die auf meinen PC erstelle .ffindex Datei

    Interessant wär jetzt ob es bei euch läuft oder wie ihr und noch besser wie ich es auch zum laufen bekomme^^
    (meine fps-Versuche sind da nicht mehr enthalten)

    Einmal editiert, zuletzt von qupfer (25. März 2012 um 22:22)

    Wie "verarbeitest" du den Ton, damit der am Ende noch synchron ist?
    Sorry für meine Anfängerfragen, aber ich möchte nicht, dass mir dann beim Anschauen auf einmal auffällt....irgendwas stimmt da nicht. Wieso knallt die Tür bevor sie zugeschlagen ist. Bisher erstellte DGindex mir ja immer schön eine Delay-Angabe im Dateinamen, der dann beim konvertieren nach AAC korrigiert wurden ist (hoffe ich doch *g).
    Denn sonst scheint es mit DirectShowSource+YV12 Konvertierung problemlos zu funktionieren.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden