Beiträge von Wally

    Salve,


    mir ist aufgefallen, dass HCEnc die avg.-Bitrate konstant nach unten korrigiert, wenn ich Adaptive Quantization aktiviere (meist nehme ich 1). Dies soll ja eigentlich Verblockungen vorbeugen, indem bei entsprechenden Szenen ne alternative, weniger 'agressive' Matrix genommen wird. Rein logisch gesehen wird in diesen Szenen eine höhere Bitrate gebraucht, da die Matrix Informationen genauer bewahrt und somit zwangsläufig schlechter komprimieren sollte/müsste.


    Nun finde ich diese Zeile(n) ständig im Log vor, wenn AQ aktiv ist:

    Code
    1. *** INFO, adjusting average bitrate: -0.01 %
    2. ...
    3. *** INFO, adjusting average bitrate: -4.99 %


    (insgesamt waren das in diesem Fall 81 Korrekturen nach unten, bis zu den -4,99%, alle vorgenommen im 2ten Durchlauf)
    Dieser extreme Wert ist mir tatsächlich untergekommen, was mein Video am Schluss 350mb kleiner machte als ich das eigentlich wollte (die avg. Bitrate sank um knappe 400kbps). Ansonsten hab ich mit aktivem AQ(=1) übliche Werte von -0,5 bis -1,5%, was sich ja noch im Rahmen hält.
    Dasselbe Video im 2ten Versuch ohne AQ und ansonsten identischen Einstellungen encodiert und es gab null Anpassung der Bitrate, die Zielgröße wurde mit minimaler Abweichung von +0,015% ziemlich genau getroffen.
    (zur Info: die beabsichtigte Avg.-Bitrate des erwähnten Videos liegt bei recht hohen ~7300kbps, sollte das in irgendeiner Weise relevant sein.)


    Nun die Frage, warum wird die Bitrate/Dateigröße nach unten korrigiert, wenn der theoretische Bedarf durch AQ doch eigentlich steigen müsste? Das widerspricht doch jeglicher Logik.
    Generell gebe ich die Avg.-Bitrate bzw. Größe doch auch vor, um den Platz auf der DVD möglichst auszureizen; eine Korrektur nach unten macht also weder aus platztechnischen, noch aus qualitativen Gründen (ungeachtet der evtl. sehr guten Komprimierbarkeit des Quellvideos) irgendeinen Sinn.


    Besonders bei einem so extremen Fall wie dem obigen, wo die ABR um 400kbps sinkt, kann ich mir nur schwer vorstellen, dass das Ergebnis (auf das Gesamtwerk bezogen) eine höhere Qualität hat. In manchen Szenen mag eventuellen Verblockungen vorgebeugt sein, wodurch diese aber nun mehr Bitrate brauchen dürften; alle anderen Szenen leiden darunter jedoch 'doppelt', da einmal die Bitrate durch die niedriger quantisierten Szenen entzogen wird und zum anderen durch die Korrektur allgemein Bitrate geklaut wird. Macht Sinn? Ne, oder? :D


    Sollte mir irgend jemand erklären können, warum es zu dieser Anpassung kommt, bzw. wie die zu begründen ist, wäre ich wirklich dankbar. :)


    Wally

    Soweit ich verstanden habe, willst du die DVD mit deinem Encodierten film vergleichen.
    aber nach dem encode von deinem film stimmt die FrameNummer nicht mehr mit dem der DVD.


    Hast du assumefps(25) vergessen?


    PS: drückt dich mal bisschen besser aus ;)



    zum späteren exakten ersetzen des videos hab ichs im avs entsprechend angepasst und mit dem originalen verglichen (overlayvorschau mit beiden videos geladen, nur als randinfo). als ichs synchron hatte wurd das ganze wie üblich an HCEnc weitergegeben und reencodet.


    beim neuerlichen vergleich des reencodeten materials mit dem original (vom neuen ne d2v erstellt) musste ich jedoch feststellen, dass das ganze nun gelegentlich asynchron ist. mal passts frame auf frame, mal ists um 1 frame asnyc, und ne kurze periode auch um 2. im gesamten, also zu beginn und auch am ende ists jedoch synchron.


    also das hab ich doch recht deutlich geschrieben, oder? ^^
    entsprechend nein, assumefps habe ich nicht vergessen; mpeg-stream und avs-script der anderen quelle hätten sonst unmöglich identisch sein können.


    also nochmal 'besser ausgedrückt' (auch wenn ich nicht verstehe, was bisher so undeutlich war):


    (die folgenden werte sind aus der luft gegriffen...)
    frame 0 bis 10000 sind script und das aus diesem reencodete m2v identisch (jedes frame gleich).
    10001 bis 11000: m2v liegt dem script um 1 frame zurück, es muss also eins 'verloren' gegangen sein.
    ab 11001: m2v und script liegen plötzlich wieder gleichauf; das verlorene frame ist also irgendwie wieder aufgetaucht (wenn auch in anderer 'gestalt').


    damit das passiert muss also ein frame (von mir nicht beabsichtigt) doppelt encodet und später einer (ebenfalls unbeabsichtigt) beim encoden ausgelassen worden sein, bzw. umgekehrt.


    so geht das über den gesamten film hinweg 3 oder 4 mal, einmal davon eben mit 2 frames versatz. am ende ist dieser versatz jedoch wieder vollkommen ausgeglichen.

    So etwas kann eventuell an Timingschwächen aus Multiplexing, Filterung und Wiedergabe liegen (Action-Szenen verzögern sich im Vergleich zu ruhigen Szenen durch Decodierung und Postprocessing; ein PC-Monitor hat doch nicht exakt die nötige Framerate), oder an leicht abweichenden Schnitten in der Synchronisation; mit Sicherheit kann man dazu kaum etwas sagen. Wenn es vorn und hinten synchron ist, ist aber zumindest die Lage der Tonspur korrekt.


    23,976 ist die Rundung. Der Wert 24000/1001 ist der exaktere.


    da hatte ich mich wohl etwas unklar ausgedrückt.
    gemeint war, dass ich die beiden videospuren per overlay im avisynth-script vergleichen habe, also überlagert um festzustellen, falls es nen unterschied gibt.


    das kuriose dabei war, dass der mpeg2-stream der dvd mit dem avisynth-script der mkv übereinstimmte, also von anfang bis ende frame auf frame absolut identisch war.
    erst nach dem encoden der avs und dem anschließenden vergleich des neuen mpeg2-streams (neue d2v) mit dem alten waren die unterschiede da.

    nach viel gelese hab ich nu endlich kapiert was du da machst... (die handlungsweise mit ITU bei 720px vs generisch war mir nicht richtig klar)


    aber hättest du auch nur ein einziges mal auf die ITU-rechenweise hingewiesen, anstatt immer nur zu sagen, dass deins ja richtig ist, wäre das auch klar gewesen. ;) (argumentation kann vieles klarstellen)
    was mich vor allem verwirrt hat war deine behauptung, dass bei 1280x720 die werte bei ITU und gen. gleich sind, was nicht stimmen kann. (der rest der rechnung ist korrekt, auch wenn ich dabei bleibe, dass sie zu umständlich und unklar ist).


    bei voller auflösung müsstest du laut deiner rechnung eine höhe von 589px nehmen, um das nach ITU korrekte seitenverhältnis zu wählen. würdest du einfach so 576 nehmen, wärst du beim generischem SV (nach welchem ich bisher immer gerechnet habe) und hättest ne andere AR. streng genommen (wenn ich richtig gedacht habe), müsstest du in dem fall beim encoden entweder je 8px balken li/re hinzufügen, oder die zielauflösung auf echte 704x576 anstatt 720x576 festlegen.


    ansonsten nochmal zu deiner rechnung. diese ist korrekt, wenn man nach ITU geht (was man wohl tun sollte), jedoch erwähnst du das nicht, was bei mir verwirrung gestiftet hat. desweiteren find ich sie so wie sie steht nicht gelungen, da die schritte zwar als rechnung ansich korrekt sind, jedoch die reihenfolge/art wenig nachvollziehbar wirkt.


    deine rechnung 1 und 2 kann man in eine simple zusammenfassen, die den sinn absolut korrekt wiedergibt (und diesmal wirklich korrekt ;) ):


    720*1024/704 -> zur erklärung: anamorphes material wird nach ITU von 704*576 auf 1024*576 gestreckt, du willst daher wissen, auf was 720*576 gestreckt wird. dieser simple dreisatz (das sind deine beiden rechnungen zusammengefasst und diesmal nur die höhe rausgekürzt, nicht auch die breite wie in meiner ersten rechnung) bringt dich auf 1047,27. das scheint die reelle breite zu sein, auf die video mit 720px breite nach ITU gestreckt wird. (damit hat der wert hand und fuß; deine zwischenergebnisse waren ansich ja richtig, jedoch reell nicht existent, ums mal so auszudrücken)


    die rechnung ist damit unabhängig vom quellmaterial und bezieht sich generell aufs ziel. somit muss diese nicht ständig ausgeführt werden, sondern man kann direkt das ergebnis, die 1047px als breite annehmen (die rundung geht vollkommen in ordnung, die differenz zum korrekten wert beträgt im extremfall 0,15, was sowieso gerundet werden würde).


    die einzige rechnung, die man also tätigen müsste, wäre:
    a) 1047 * Quellhöhe / Quellbreite, wenn das zielvideo eine auflösung von 720*576 haben soll, oder
    b) 1024 * Quellhöhe / Quellbreite, wenn das zielvideo eine auflösung von 704*576 haben soll.


    alternativ mein simpler dreisatz bei 720px und am schluss werden 8px balken li/re hinzugefügt, damit wär die rechnung auch wieder korrekt.



    hiermit also verzeihung für meinen etwas überflüssigen disput (ich war eben ziemlich auf die generische AR fixiert) und ich hoffe, die rechnung gefällt dir diesmal etwas besser. ;)


    wally


    und nochmal, 1024/444 = 2,306 != 2,35 = 1280/544


    öffne das video mal im original mit mpc oder so, maximiere das fenster und dann öffne dein neu berechnetes video. vergleich dann beim wechsel und ich bezweifle, dass du exakt dieselben seitenverhältnisse haben wirst.
    aber gut, offenbar willst du nicht lesen/verstehen, was ich schreibe, daher bleib bei deiner methode.

    Naja dann ist das für mich KEIN HD sondern "nur" Video im MKV Format.


    klar, ist 'nur' video im container, aber eben in hd-auflösung. nen in 1080p belassenes video, welchem lediglich die ränder entfernt wurden ist doch weiterhin hd... die schwarzen balken will ich ja nu nich wirklich sehen, bzw. die spendiert mir eh wieder jedes programm im originalzustand ;)


    Und warum klatsch Ihr dann nicht einfach die Ränder wieder dran und rechnet dann nach DVD? Oder versteh ich hier was Falsch.


    das könnt man theoretisch auch tun, jedoch möcht ich das ziel ja evtl. hinlänglich der macroblöcke optimieren. das mag vllt. die AR leicht verfälschen, jedoch benötige ich dafür die höhe in der zielauflösung.




    KM (Katjarella Meinung): Also Ihr ladet Euch also, ReEncodete MKV Filme runter und wandelt dann nochmal nach DVD? pfui


    wenn es legale und kostenfreie onlinevideorecorder gibt sehe ich nichts verwerfliches daran, hdtv-captures von bekannten zu beziehen, die eben in mkv speichern. zudem wurd für die dvd bereits bezahlt, der publisher hat den beitrag für seine billige produktion also erhalten.

    Und nach meiner rechnung kommt 720*444 raus,fällt dir was auf?
    Ja, mehr Bild und die AR stimmt trotzdem.....


    Mit bedingt meinte ich das die ergebnisse nur bei 1080 und 720 Quellhöhe gleich sind zu meinem weg!
    Viele Wege füren nach Rom, deiner auch,finde meinen aber "besser".


    tjoa, du hast damit grad bewiesen, dass du selbst opfer deiner undurchsichtigen methode wurdest ;)
    LigH hat es erwähnt, das PAL-verhältnis 11/16 darfst du ausschließlich verwenden, wenn du als zielbreite 704px nimmst und NICHT 720, denn 11*64=704... 11,25*64=720, damit wärs richtig.


    wenn ich deine formel nutze und die 11/16 drinne lasse und dann in schritt C 720px wähle, komme ich auch auf 445, respektive 'gerade' 444. doch damit hast du einmal ne zielbreite von 704 und einmal 720 genutzt, was dein fehler ist. ENTWEDER 704 + 11/16 ODER 720 + 11,25/16.
    probiers aus, setze in C 704px als zielbreite ein und du wirst auf mein ergebnis kommen.


    die AR kann bei dir nicht mehr stimmen... teile doch einfach mal 1024 durch 444, da kommt keine 2,35:1 mehr raus, sondern 2,30:1.


    und der weg ist IMMER gleich. les doch einfach mal richtig, was ich oben geschrieben habe... ich habe DEINE formel genommen und diese lediglich gekürzt. NICHTS habe ich gestrichen, geändert oder sonstwas, lediglich zusammengefasst. das sind keine verschiedenen wege und deiner ist nicht besser, sie sind schlichtweg identisch.


    katjarella
    HD(material) hast du im mkv-container doch üblicherweise gecropped. cinemascope z.b. füllt ja nicht die vollen 720/1080p, sondern eben sowas wie 1280x544 bzw. 1920x816.


    ääähm, es kann keinen unterschied geben... beide wege sind im endergebnis identisch (nicht durch zufall, sondern bedingt durch die formel)... wenn du 12489653646 durch 12489653646 teilst, kommt 1 raus. wie ich dir aufgezeigt habe, kürzen sich in deiner rechnung 2 werte komplett raus (nicht annähernd, sondern zu 100%, über bleibt ne glatte 1).


    zu deinem beispiel: 1280*544 entspricht ner AR von grob 2,35:1...


    1024 * 544 / 1280 = 435,2


    1024*435 entspricht ebenfalls ner AR von 2,35:1. und das ist doch das ziel, oder nicht? der erhalt des richtigen Seitenverhältnisses... bei PAL ist das immer ne prozentuale anpassung. bei ausgangsmaterial von 720p kannste die quellhöhe auch einfach mal 0,8 nehmen und hast den passenden wert (1280/1024...).


    bzl rechnung... das ist doch nicht spekuliert, ich hab deine einfach nur zusammengefasst und komm dann direkt auf meine (wesentlich einfachere)


    aber ums dir zu beweisen werd ich dir deine rechnung ma ganz pragmatisch aufzeigen:
    (ich nutze hier genau deine Formeln, nichts anderes!)


    # Qb=Quellbreite; Qh=Quellhöhe; P5=576(also PAL); Rk=Resize-schmal(11*64=704)/alternativ(11,25*64=720); Rl=Resize-breit(16*64=1024) #


    A = Qb * P5 / Qh
    B = Rk * A / Rl
    C = P5 * Rk / B


    B in C:
    C1 = ( P5 * Rk * Rl ) / ( Rk * A )


    A in C1:
    C2 = ( P5 * Rk * Rl * Qh ) / ( P5 * Rk * Qb )


    -> P5 und Rk kürzen sich raus ->
    C = Rl * Qh / Qb
    ausgeschrieben
    C = 1024 * Quellhöhe / Quellbreite, wie ich es schon geschrieben habe ;)


    zusammengefasst 100% identisch mit deiner komplexen gleichung, wobei die möglichkeit des fehlers mit 720px breite und dem 11:16 verhältnis (was zum falschen ergebnis führen würde) grundsätzlich ausgeschlossen wird. also einfacher, übersichtlicher und sicherer ;)


    edit:
    das gilt natürlich nur für PAL!
    wenn ich recht gespickt habe, wird das bild bei NTSC auf 864px gestreckt und nicht auf 1024. entsprechend muss bei NTSC das Rl eben mit 864 ersetzt werden; die höhe kürzt sich raus, spielt also nur beim setzen der ränder ne rolle.


    why so serious? ^^
    einen einzelnen beitrag kannste wirklich schreiben wie du willst, aber ich denke auch, nen tut, welches für viele augen bestimmt ist, sollte in 'sauberem' text verfasst sein, das erhöht die lesbarkeit enorm.


    was angesprochen wird sind nicht 'keine probleme' sondern meist eventualitäten, die auftreten können. wenn ein anfänger auf solch ein problem trifft, hilft dein tut nicht mehr weiter und das projekt ist entweder gescheitert oder es kommt evtl. mist raus.


    wenn du selbst einsiehst, dass es kompliziert verfasst ist, warum fasst du es nicht einfacher? dir werden doch nur hinweise gegeben, was verbesserungswürdig ist. nen tutorial/buch/wasauchimmer, das das vermitteln von kenntnissen zum hintergrund hat, kann in "v1" oder "v2" eigentlich kaum final sein, zu verbessern gibts immer was. also ransetzen und optimieren, normaler prozess!
    also, 'why so serious?' ;)


    Warum soll ich mich nicht mit der 'Materie' beschäftigt haben, nur weil ich wage, standardwerte in die rechnung einzusetzen? sowas nennt man probe... ich weiß was raus kommt und kann die rechnung somit überprüfen!
    nachdem ich LigH's post gelesen habe, in dem er darauf hinweist, dass das 11:16-verhältnis ausschließlich für 704px breite gilt, funktioniert das auch alles. wenn ich das aber erst 'im thread' lese und nicht schon im tut, hast du was falsch gemacht ;)
    zu 720*576 geht dein resize somit nicht! es passt nur mit 704, weil diese rechnung dank der 11 nur dafür ausgelegt ist. ersetze die 11 mit ner 11,25 und es passt dann mit 720px.
    dennoch bleibe ich dabei, dass die rechnung viel zu kompliziert ist. wenn du die 'formeln' für 1/2/3 mal erstellst, ineinander einsetzt und dann rauskürzt, kommst du auf meine erwähnten 1024 * Quellhöhe / Quellbreite.
    die zielbreite bleibt dabei irrelevant, da sie sich so oder so rauskürzt. auch wenn ich mich damit etwas weiter aus dem fenster lehnen mag, aber meine erinnerung sagt mir, dass jede handelsübliche dvd, die mir bisher durch die finger geglitten ist, 720px breite hatte und keine 704px. entsprechend handle ich der gewohnheit nach und bleibe bei der breite. wenn du nen guide für 'anfänger' schreibst (ich denke, dass jeder, der bereits mehr als 10h ins reencoden von dvds und in avisynth gesteckt hat schnell auch so auf den trichter kommt, wie sowas zu basteln ist), sollte das ding doch nicht zu überladen sein, entsprechend nicht 10 verschiedene varianten, die man eigentlich nicht braucht. soll nu nicht belehrend sein, sondern einfach nur nen hinweis, da es immerhin auch mir schon schwergefallen ist, der rechnung klar zu folgen (zu kompliziert, geht ja einfacher und sicherer zu berechnen und variablen die die rechnung und somit das gesamte produkt zerstören können).



    Benutze doch einfach mal genau mein TUT und dann staune über die Qualität!


    Mit HD2DVD beschäftige ich mich nicht erst seit gestern, dass da bessere quali rauskommt als bei dem ramsch den die publisher auf den markt werfen ist mir klar (das basiert allerdings auf dem prinzip an sich, nicht auf dem tut ;) ). für mich gehören zu 'qualität' aber auch untertitel, menü und die originale synchro... eben exakt das, was ich hätte bekommen sollen, als ich die scheibe im laden gekauft habe; macht den aufwand dann doch noch etwas größer.



    LigH
    Wäre nett wenn du die rechnung hier im thread auch nochmal bestätigst, keine lust die antworten aus dem anderen thread hier zu posten!
    Ich denke dir traut man mehr....


    Gruss Der Wille


    muss ja net, rechnung stimmt, sofern man auf die beschränkung für die 704px hinweist, bzw. andernfalls die 11 mit der 11,25 ersetzt ;)

    salve,


    bin mir nicht sicher, ob ich hier mit dem problem richtig aufgehoben bin, da ich den fehler nicht wirklich wirklich eingrenzen kann.


    vorhaben ist, mkv/h264(*.dga) per avisynth-script in mpeg2 umzuwandeln. dvd solls werden, da das original ne mehr als üble qualität hat, die ich nicht hinnehmen will.


    zum späteren exakten ersetzen des videos hab ichs im avs entsprechend angepasst und mit dem originalen verglichen (overlayvorschau mit beiden videos geladen, nur als randinfo). als ichs synchron hatte wurd das ganze wie üblich an HCEnc weitergegeben und reencodet.


    beim neuerlichen vergleich des reencodeten materials mit dem original (vom neuen ne d2v erstellt) musste ich jedoch feststellen, dass das ganze nun gelegentlich asynchron ist. mal passts frame auf frame, mal ists um 1 frame asnyc, und ne kurze periode auch um 2. im gesamten, also zu beginn und auch am ende ists jedoch synchron.


    kann mir jemand erklären, woran das liegen könnte? so schlimm wärs letztendlich nicht, da die 40 oder kurz ma 80ms zeitversatz kaum auffallen werden, aber wundern tuts mich dennoch, wenns vorm encoden doch synchron ist.


    erwähnen sollte ich evtl noch, dass die quell-mkv laut log ne framerate von 23.975986 fps hat, also keine glatten 23.976.


    sollten fehler im stream sein hätte doch eigentlich schon dgavc beim indizieren meckern müssen bzw. ich hätte es bei der vorschau des avs-scripts auch schon gesehen, oder nicht?


    ausmachen kann ich die punkte, an denen es async wird ebenso ziemlich schwer, da es sich um nen animationsfilm handelt, bei dem großteils nur jedes 2te bild ne änderung bereithält.


    über mögliche hilfe würd ich mich sehr freuen :)


    wally


    wie kann das sinn machen? sehr simpel gehalten hast du sie nicht, nein. und wer hat die dir bestätigt, haben diejenigen wirklich nachgerechnet?
    ich hab mir mal den spaß gemacht und ganz simpel die standard-16:9 auflösung von 1280x720 eingesetzt (wahlweise auch 1920x1080). rein theoretisch müsste bei "C" exakt und absolut glatt 576 rauskommen, wenn ich PAL/720 haben will. NICHTS anderes darf dabei rauskommen, wenn du das richtige seitenverhältnis haben willst.
    bei deinem vorhaben würd ich 589 rausbekommen, also grottenfalsch und bei ner maximalen höhe von 576px nichmal realisierbar. richtig gerechnet sollte ich auch haben, habs fein säuberlich schritt für schritt geexcelt.


    was du in schritt 1 machst ist also schon nicht sinnig, da dir diese breite 1. nichts bringt und sie 2. falsch ist - du hast schon 2 gegebene breiten, wo soll die 3te dann herkommen?


    anamorphes material wird auf 1024 pixel gestreckt (bei PAL). um die benötigte höhe zu finden reicht also nen simpler dreisatz.
    1024 * Quellhöhe(720) / Quellbreite(1280) = Zielhöhe(576)


    daher so und mit 1024px breite rechnen, beim resizen jedoch die 720px breite einsetzen. gilt natürlich nur für 16:9, aber anderes material gibts doch eh nicht mehr, besonders nich in HD.
    rechnest du so und vergleichst die videos direkt (wenn auf gleiche breite gestreckt, also vollbild), erhälst du (falls ohne rundungsfehler) exakt dasselbe bild, muss also stimmen.



    zum resizer selbst... bicubicresize solltest du aus dem ding streichen. hab ich einst auch genutzt, ist jedoch viel zu unscharf für den job (und schärfe dürfte weniger ne frage des geschmacks sein ;) ).
    beim direkten vergleich seh ich zwischen Lanczos und Spline36 keinen unterschied, bevorzuge jedoch letzteren nach empfehlungen aus diesem hause.

    hidiho,
    kurze frage hätte ich...
    hab ne dvd9 erstellt, die praktisch rappelvoll ist (PGCEdit sagt 99,51%, macht knappe 40mb rest). nun sind die cells unglücklicherweise nicht passend zum layerbreak und dank der größe bleibt mir auch keine wahl mehr zwischen verschiedenen cells.


    nun kommt erschwerend hinzu, dass das video multiangle ist, womit ich die cells nicht einfach mit vobblanker splitten kann, wie ichs eigentlich tun würde.


    daher nun die frage, wie ich das splitten anstellen kann, ohne irgendwas löschen zu müssen, das gesamte etwas kleiner zu reencoden oder aufs multiangle zu verzichten. mir fehlen da die ideen, wie und mit welchem programm ich das noch anstellen könnt.


    über rat wäre ich sehr sehr dankbar :)


    wally

    Deinterlacer? Welche MPEG2 Decoder werden verwendet? Welcher Videorenderer wird verwendet? Mal in den Grafikkarteneinstellungen bzgl. Videowiedergabe geguckt? Eventuell im Hintergrund ein ffdshow laufen, bei dem das Postprocessing entsprechend glättet? ....


    ffdshow eigentlich immer, ist ja das einzige, was von CCCP genutzt wird.
    hab nu aber grad mal in den einstellungen geschaut... für mpeg2 konnt ich dort das 'DVD decoding' aktivieren, was zusammen mit 'libmpeg2', anstatt 'disabled' wieder das gescheite bild liefert.


    postprocessing war alles aus, das hab ich sichergestellt. also bis eben hat wohl alles ffdshow erledigt, wobei das, soweit ich mich erinnern kann, die jahre zuvor nie anders eingestellt war.


    grafiktreiber hab ich vor kurzem nur von nvidia 169.21 auf den omega 169.21 gewechselt, da neuere probleme gemacht haben, wobei ich die ja nu auch schon seit nov. letztem jahr verwende.

    salve...


    ich bin grad etwas durcheinander, weil ich null plan hab, warum das passiert:


    film umgewandelt in mpeg2/dvd und beim testen verschiedener einstellungen schon seltsame probleme beim abspielen gehabt -> das bild wurde tierisch unscharf.


    ich nutze grundsätzlich und ausschließlich den MPC zum abspielen von videos jeglicher art; an codecs ist nur das CCCP installiert, sowie noch CoreAVC (wobei der meineswissens nur bei h264 greift, also eigentlich irrelevant).


    nun habe ich bei den tests festgestellt, dass es irgendwie am directshowfilter lag. und zwar habe ich zum abspielen entweder die encodete m2v direkt mit mpc abgespielt, oder übern simples avs-script per directshowsource.


    hab ich dagegen für den testschnipsel nochmal nen dvd2avi-projekt erstellt und dieses per mpeg2source geladen, war das bild genau so scharf, wie es im ursprünglichen script, das zum encoder gereicht wurde, gedacht war.


    nun dachte ich, das wäre nur dort der fall, musste aber eben feststellen, dass derselbe schärfeverlust wieder eintritt, wenn ich das fertige dvd-image (iso mit pgcedit/mkiso erstellt) mounte und abspiele. alternativ hab ich noch vlc getestet, da wars dasselbe...


    erst als ich wieder nen d2v-projekt aus der vob erstellt habe und dieses per avs lud, hab ich wieder das korrekte bild erhalten.


    in ffdshow hab ich keine filter oder so aktiviert, daher bin ich nu ziemlich ratlos, an was das liegen kann. ich bin mir auch nicht sicher, ob das problem schon die ganze zeit besteht oder erst seit kurzen, da ich normal ja nicht vorher/danach vergleiche, wodurch einem das erst wirklich ins auge sticht.


    hat jemand ne idee, was da ne mögliche ursache für ist? wäre sehr sehr dankbar für hilfe.


    wally

    hab nochma bissl rumprobiert und sollt das nächste mal vielleicht genauer testen, welch gravierende auswirkungen ne andere matrix hat ^^


    hatte die FOX genommen, da irgendwo gelesen, dass man eher sowas in der richtung nutzen sollte, um das starke quantisieren in den bereichen zu vermeiden.
    nuja, evtl. hab ich falsch gelesen oder so, zumindest wars mit der MPEG-matrix erheblich besser und die änderung von gradfun bleibt zumindest großteils erhalten.


    was mich nur erstaunt hat, war der wirklich herbe schärfeverlust nach dem encoden (nicht nur zum original HD, sondern zum bereits skalierten avs-script).
    kann ich zumindest nicht so ganz nachvollziehen, aber scheint wohl normal zu sein... zumindest hat CCE dasselbe ergebnis gebracht (wenn auch minimal schärfer).
    edit: doch nix mit schärfeverlust, nur die offenbar weniger gute idee, die mpv beim testen mit directshow wiederzugeben.

    Ihr müsst mit gradfun2db nur aufpassen, dass beim Encoden die Blöcke nicht zurückkommen. Déjà Vu?


    joa, exakt das ist passiert, teilweise siehts sogar noch ne ecke schlimmer aus als vorher.
    hab deinen thread ma durchgearbeitet... zwar nur die hälfte verstanden aber ma schaun, ob da bei den vorschlägen doch was passendes dabei ist, was ich umsetzen kann. ^^
    du hattest es da ja auch relativ viel von einstellungen, die ausschließlich das encoden von x264 betreffen (das -crf), jedoch möcht ich ja mpeg2 und hab entsprechendes nicht.


    nuja, zur not versuch ichs ma mit künstl. rauschen in den schwierigsten szenen und hoffe, ich krieg das ding dieses jahrtausend nochma fertig.

    Mit dem Wert musste testen, nutze gradfun2d i.d.R. nur in bestimmten Bereichen (trim), wenn Werte > 1.2 mit deiner Source Probleme machen, dann nimm niedrigere. ;)


    nuja, werd wohl doch noch probieren müssen. das avs-script an sich sah beim anschauen erstklassig aus, nachm encoden (HCEnc) wars jedoch nichmal mehr was für die tonne.
    hab schon die alternativen (internen) matrizen vom HC ausprobiert, da ich gelesen hab, dass die von gradfun erreichten effekte sonst meist wieder zunichte gemacht werden (was ich über den gesamten film ziemlich extrem beobachten konnte), aber selbst damit wollts nicht wirklich was werden.