Beiträge von LessThanJake

    ...anamorph gestaucht (das ist richtig so - der HC kriegt genau das, was er soll; erst der Fernseher entzerrt das wieder).

    Zitat von Willensstark


    Hier nochmal die encoder settings:
    ...
    aspect ratio: 16:9
    ...

    Das finde ich jetzt ungewöhnlich. Er resized doch schon im AVISynth-Script so, dass das Ergebnis anamorph gestaucht ist. Heißt für mich der HC soll das was vom Script kommt im PAR 1:1 encoden und nicht nochmal 16:9.
    Zumindest mache ich das so.

    greets
    LTJ

    Du brauchst den Ton nicht verändern. Bei einem 3:2 Pulldown wird jedes 5. Halbbild doppelt angezeigt (23,976 / 29,970 = 4/5).
    Du hast zwar sozusagen mehr effektiv angezeigte Bilder pro Sekunde, aber der Film läuft vom Bildinhalt her nicht schneller ab.
    Du musst den Ton nur dann anpassen, wenn du eine PAL-DVD mit 25 fps erstellst.

    greets
    LTJ

    Willensstark
    Mach doch bitte dafür einen eigenen Thread auf.
    Das Thema Interlacing / Framerate hat mit Resizing-Problemen doch herzlich wenig zu tun. Vielleicht mag Rippraff das ja mal an passender Stelle abtrennen.

    So Lessthanjake, habe jetzt alles dank deiner hilfe verstanden....da du aber scheinbar echt was drauf hast ...

    Ich bin übrigens hier nur ein kleiner Mitleser, der mal was aufgeschnappt hat und anderen Neulingen vielleicht etwas weiterhelfen kann. Das was hier von mir gepostet wurde, steht mit Sicherheit schon zig mal irgendwo hier im Board. Die (aktiveren) Profis hier im Board sind eher Selur, Ligh, scharfis_brain, Dideé, Brother John ... um nur einige zu nennen ;).

    greets
    LTJ

    Die Rechnung oben ist mathematisch richtig. Das Thema Resizing an sich ist im Gesamtbild etwas komplexer und hier stößt man auf das Thema Analog-Digital-Wandlung und die daraus resultierenden Auflösungen für die Digitalwelt. Um weitere große Verwirrung zu vermeiden und groß nochmal die Theorie runterzukauen, betrachten wir mal einfach nur die Anwenderseite und das, was sinnvoll ist um eine vernünftige DVD zu erstellen.

    In den meisten Fällen sind in der Quelle schon schwarze Balken vorhanden. Rechnet man die ab, taucht dieses Problem nicht auf. Wenn du tatsächlich eine Quelle hast, bei der 1920x1080 eine volle Bildfläche ohne schwarze Balken ist, würde ich persönlich vertikal einfach soviel vom Bild wegcroppen bis man wieder auf genau 576 bzw. 480 landet das sind nur wenige Pixel und das merkt kein Mensch.
    Als Alternative kannst du eine DVD mit 704 Pixelspalten erstellen, dann "passt" die Rechnung wieder exakt.
    Oder du nimmst doch die volle 720er Breite und fügst kleine schwarze Balken links und rechts am Bild an. Für Röhren-TVs egal, die verschwinden im Overscanbereich, für Digital-TVs aber blöd, weil sie sichtbar bleiben.

    Wenn du dich mit der exakten Theorie befassen möchtest, lies doch mal den Abschnitt zu MPEG4-PAR / ITU-PAR vs. Generischem PAR von Brother John
    http://encodingwissen.de/spezial/itur-bt601.html
    und schau auch nochmal in den Link in Post #11 von Skiller.

    greets
    LTJ

    Habe nochmals gerechnet (mehrmals) und kam jedesmal auf 720*370 also mit border 54.......seltsam...aber eh besser....

    Dein DVD-Authoringprogramm wird eine Fehlermeldung präsentieren.

    370 + 2*54 macht?

    ----------

    Entweder:
    720 x 372 -> Borders 2*54 -> AR-Fehler ~0,3%
    oder
    720 x 368 -> Borders 2*56 -> AR-Fehler ~0,78%

    So, jetzt ist aber gut. ;)

    greets
    LTJ

    Das rechne ich jetzt nicht nochmal nach. Etwas Transferleistung musst du schon bringen. ;)

    Die Auflösung muß so gewählt werden, das die Borderpixelzahl oben und unten jeweils durch 2 teilbar ist. Wirst du aber auch selbst merken, denn falls das nicht der Fall ist, wird AVISynth ne Fehlermeldung ausspucken.

    greets
    LTJ

    Oh mann,,,,danke trotzdem, bin halt net mehr so gut in mathe..lol
    Ich hoffe ich habe es jetzt verstanden....nur nochmal zum überprüfen:

    1280*544 ist also original ohne Balken 720*368.19---also 720*368 , und die borgers betragen oben und unten 55.90--also 56 Richtig so???
    Und wie wird es dann geschrieben? addborders (0,56,0,56)...so?

    Bis hierhin ok. Evtl. Borders auf 54 statt 56 setzen weil Fehler kleiner, aber das ist jetzt nicht so tragisch.

    Zitat

    Bei LanczosResize wieder 720*576 oder die geänderte grösse eingeben??

    Dieser letzte Satz passt nicht. Du hast doch gerade die Berechnung für eine NTSC DVD gemacht, welches genau auf 720 x 480 passt. Das ist schon die Endauflösung. Wenn du das Ergebnis jetzt wieder auf 720x576 resized, hast du zwar ne PAL DVD, aber die Entzerrung passt doch nicht mehr. Schon wieder vergessen? PAL 16:9 --> PAR 16:11 / NTSC 16:9 --> PAR 40:33.

    Für dein oben berechnetes Ergebnis sieht das Script so aus:
    AVCSource("deinclip.dga")
    lanczosresize(720,368)
    Addborders(0,56,0,56)
    #Scriptende! Ab hier wird nix mehr resized!

    Wenn du ne PAL DVD haben willst, sollte das (wenn ich mich nicht verrechnet habe) folgendermaßen aussehen:
    AVCSource("deinclip.dga")
    lanczosresize(720,444)
    Addborders(0,66,0,66)
    #Scriptende! Ab hier wird nix mehr resized!

    greets
    LTJ

    1280x536 (Quelle)
    1145,27x480 (Dreisatz)
    945,67x480 (Video stauchen -> PAR-Tabelle -> NTSC -> 16:9 -> Faktor 40/33)

    Dieses ergebniss kommst....schreib mir mal die formel auf bitte....Danke

    VG

    Och Mensch - Bruchrechung und Dreisatz - Stoff der 5. Klasse oder so.
    Aber ok, ich wills nochmal erklären.

    Du hast ne Quellauflösung von 1280x536. Du weist, dass die vertikale Auflösung für NTSC 480 sein muss.

    Also

    (1280 / 536) * 480 x (536 / 536) * 480
    1146,27 x 480

    Jetzt wurde nur die effektive Bildfläche verkleinert, aber das Seitenverhältnis stimmt immer noch und das PAR ist auch immer noch 1:1. Bei einer DVD ist das PAR aber nicht 1:1 sondern - wie du ja nun im Encodingwissen gelesen hast - 40:33 für NTSC. Du willst die horizontale Auflösung aber nicht entzerren (ist sie ja im Grunde momentan schon), sondern stauchen, also muss sie um den Faktor 1 / (40/33) oder eben 33/40 verkleinert werden, also

    1146,27*(33/40) x 480 = 945,67 x 480

    Du hast zu diesem Zeitpunkt nun ein (virtuelles) anamorphes Video vorliegen, so wie es prinzipiell bei einer DVD auch der Fall ist, allerdings kann eine NTSC DVD der Norm nach nur 720x480 Pixel "fassen". 945,67 x 480 ist also zu groß. Deshalb wird die effektive Bildfläche nochmal soweit verkleinert, bis sie eben reinpasst und das geht wieder über nen Dreisatz.

    945,67 x 480 wird zu
    (945,67 / 945,67) * 720 x (480 / 945,67) * 720
    = 720 x 365,45

    720 x 365,45 ist jetzt die effektive Bildfläche ohne die schwarzen Balken. Wie wir aber wissen müssen aber 720 x 480 Pixel für eine NTSC DVD gefüllt werden. Die Differenz sind dann logischerweise die verbleibenden schwarzen Balken.

    Also
    480 - 365,45 = 114,55
    aufgeteilt für oben und unten ergibt das demnach 57,275.

    Subpixelgrößen kann die Funktion Addborders(...) aber nicht verarbeiten, sondern nur Werte, die durch 2 teilbar sind, daher wird gerundet. Entwerder auf 58 oder auf 56 und daher rühren die zusätzlichen minimalen, aber unvermeidbaren AR-Fehler.

    1 - (365,45 / (480 - 2*56)) = ~0,7%
    bzw.
    1 - ((480 - 2*58) / 365,45) = ~0,4%

    Beide Fehler sind minimal und wird man sicher nicht bemerken. Der Perfektionist nimmt dann eben den kleineren Fehler, also die 58 Pixel schwarze Balken oben und unten, heißt für die effektive Bildfläche bleibt in vertikaler Richtung noch 480 - 2 * 58 = 364 übrig

    => Endgültige Auflösung der effektiven Bildfläche:
    720 x 364

    Thats it. Wenn das klar ist, kannst du nun mal schauen ob FitCD, The Filmmaschine, MeGUI und andere Calculator und Tools das auch so machen. (Ja machen sie, aber du weist nun warum und wieso ;))

    ------------

    Wenn eine normale AC3-Tonspur (448kbit/s) vorliegt, würde ich Quellen mit einer Bildrate von 23,976 mit dem HCEncoder encoden und 3:2 Pulldown aktivieren, dann kann die Tonspur unverändert übernommen werden. Liegen eventuell höherwertige Tonspuren (DTS und besser im Sinne von mehr Bitrate und evtl. mehr Kanälen) vor würde ich die PAL-Variante nehmen und die Tonspur mit eac3to zu einer 448er AC3 passend zur 25er Bildrate konvertieren.

    greets
    LTJ

    Deinen Fragen nach zu urteilen hast du generell das Thema anamorphes Encoding und speziell anamorphes DVD-Encoding nicht verstanden.
    Brother John hat genau das hier
    http://encodingwissen.de/video/anamorph.html
    sehr ausführlich erklärt, allerdings in der Richtung DVD -> MPEG4.
    Wenn du das begriffen hast, musst du einfach nur rückwärts rechnen.

    Deine Quelle:
    Auflösung: 1280x536
    FPS: 23.976
    PAR: 1:1 (angenommen)
    AR: 16:9 (angenommen)

    Dein Ziel ist ne DVD.
    Jetzt kannst du schonmal überlegen ob es "sinniger" ist eine NTSC oder PAL DVD zu erstellen. Deine Quell-Bildrate ist 23.976. NTSC braucht 29.970, PAL hingegen 25.000 fps.
    Willst du eine PAL DVD erstellen, heißt das im Klartext, dass du einen Speedup für den Videostream und den Audiostream (verlustbehaftet) machen musst.
    Für NTSC kannst du die Tonspur 1:1 übernehmen, aber wirst ein Telecine-Verfahren (3:2-Pulldown) anwenden, oder zu 29.970 fps voll interlaced encoden müssen. Letzteres verschwendet Bitrate, ein 3:2-Pulldown erzeugt leichtes Rucklen bei Kameraschwenks.
    Jeder Weg hat also Vor- und Nachteile, die du erstmal für dich gegeneinander abwägen mußt.
    Deine Wahl wirkt sich dann automatisch darauf aus, wie deine Auflösung zu berechnen ist.

    Beispiel für NTSC (720x480):
    1280x536 (Quelle)
    1145,27x480 (Dreisatz)
    945,67x480 (Video stauchen -> PAR-Tabelle -> NTSC -> 16:9 -> Faktor 40/33)
    720x365,45 (reine Bildfläche)
    720x368(gerundet -> vertikaler AR-Fehler von ~0,7% (gestreckt))
    720x364(gerundet -> vertikaler AR-Fehler von ~0,4% (gestaucht))

    Borders:
    480-364 = 116 -> 58 oben und unten


    Reine Bildfläche resizen, dann Borders drankleben.
    => Script:
    DeineQuelle(...)
    resizefilter(720,364)
    Addborders(0,58,0,58)

    ----------

    Beispiel für PAL (720x576):
    1280x536 (Quelle)
    1375,52x576 (Dreisatz)
    945,67x576 (Video stauchen -> PAR-Tabelle -> PAL -> 16:9 -> Faktor 16/11)
    720x438,54,(reine Bildfläche)
    720x436(gerundet -> vertikaler AR-Fehler von ~0,6% (gestaucht))
    720x440(gerundet -> vertikaler AR-Fehler von ~0,33% (gestreckt))

    Borders:
    576-440 = 136 -> 68 oben und unten

    Reine Bildfläche resizen, dann Borders drankleben.
    => Script:
    DeineQuelle(...)
    resizefilter(720,576)
    Addborders(0,68,0,68)

    ----------

    Du kannst das Ganze auch für 704x480/576 durchrechnen, aber dann wird die effektive Bildfläche kleiner und die Balken werden größer.

    greets
    LTJ

    Nicht soviel auf einmal machen.
    Betrachte jede Quelle für sich und passe das Script entsprechend an.
    Wenn du eine progressive Quelle hast, ist es ne Ecke einfacher, wenn du ungleiche Halbbilder verarbeiten musst, ist eine automatische Erkennung meistens der schlechtere Weg, weil die auch nicht immer richtig liegt. Da ist so oder so mehr oder weniger manuelles Scripten von Nöten. Das altbekannte Exotisches Interlacing wird dir dabei helfen.

    Die globalen Variablen in deinem Script brauchst du auch nicht. Sei nicht so faul und rechne dir deine Zielauflösung selber aus. Das ist doch nur ein Dreisatz mit nem zusätzlichen horizontalen Skalierungsfaktor, bei DVDs und DVB Aufnahmen. Erstens verstehst du dann was die Automatik in MeGUI macht und zweitens kannst du überprüfen ob sie das überhaupt richtig macht. ;)

    Der nächste Punkt ist das Verpacken deiner Quelle.
    Warum benutzt du Directshowsource() statt AVCSource()?
    Diese Lösung ist uralt. Man hat früher DirectShowSorce verwendet, weil es für H264 noch kein geeignetes AVISynth-Plugin gab. Mit DGAVCIndex steht eine absolut solide Lösung zur Verfügung, die man sogar umsonst benutzen darf.

    greets
    LTJ


    Und warum haben dann manche Tools AVC-Rohdaten nicht korrekt behandeln können? ... :rolleyes:

    Soweit ich weiß, sind VUI Parameter nicht Pflicht. Sogesehen kann es auch vorkommen, dass "num_units_in_tick" und "time_scale" nicht vorhanden sind.
    Ist dann zu erkennen an "timing_info_present_flag=0"

    Code
    timing_info_present_flag equal to 1 specifies that num_units_in_tick, time_scale and fixed_frame_rate_flag are present 
    in the bitstream. timing_info_present_flag equal to 0 specifies that num_units_in_tick, time_scale and fixed_frame_rate_flag are not
    present in the bitstream.

    Spätestens, wenn variable Framerates ins Spiel kommen, dürften diese Parameter ohnehin sinnlos werden. Informationen zur Framerate müßten dann bei bspw. Transportstreams in jedem Paketheader enhalten sein, oder spätestens in einem vorangehenden Paket vor einem Frameratewechsel. Allerdings muss ich gestehen, dass ich, im Gegensatz zu diesem jungen Mann, selbst einen solchen Stream noch nie zu Gesicht bekommen habe.

    greets
    LTJ

    Zitat

    Da kann er doch direkt mit dem Interface des ScriptEnvironments arbeiten.

    Nein kann "er" nicht, weil sich die in Avisynth.h definierte API nicht mit dem GCC übersetzten läßt. Für den GCC wurde daher extra die Avisynth C - API entwickelt, die sich in avisynth_c.h wiederfindet. Um avisynth.h benutzen zu können muß ein MS-Compiler verwendet werden. Der GCC und der MS-Compiler produzieren unterschiedliche Symbole, so dass ein Aufruf von bspw.

    Code
    CreateScriptEnvironment(AVISYNTH_INTERFACE_VERSION)


    nicht notwendigerweise den gleichen Einsprungpunkt in der avisynth.dll hat, wie

    Code
    avs_create_script_environment(AVISYNTH_INTERFACE_VERSION)


    wenn überhaupt ein Einsprungpunkt existiert. Und dieser entspräche dann sicher nicht der gewünschten Funktion.

    Im Grunde ist das aber egal, ob man die normale, oder die C-API verwendet, die Funktionen sind identisch. Der einzige Unterschied besteht darin, dass ein Anwender ein mit der C-API verfasstes Plugin per LoadCPlugin einbinden muß.

    greets
    LTJ

    Dann müßte ich aber wieder an die API davon ran und die verstehe ich nicht, so ganz. Meine Ausgabe ist bisher bitidentisch mit der von avs2yuv mit -raw.
    Das kann aber irgendwie kein Programm lesen.
    YV12 kann man in BMP wahrscheinlich nicht unterbringen oder?
    Oder ich müßte zusätzlich noch zu RGB konvertieren, aber ich weiß nicht wie langsam das am Ende alles wird, schließlich sollen die Bilder beim scrubben live angezeigt werden.

    greets
    LTJ

    // EDIT
    RGB klappt.
    Welcher der AVISynth Resizefilter arbeitet denn am schnellsten, völlig unabhängig von der Bildqualität?