Beiträge von truthy

    Update: ups, sry nein mit l-mash-works crashed es leider auch. :wall:

    hier die crash+megui logs des 1st pass:
    fehlerhaftes modul avsynth.dll ffms2
    fehlerhaftes modul mvtools2.dll LSMASHSource
    immer noch avisynth.dll problem ... kann das vl mit den 2dlls zusammenhängen: http://fftw3.dll/libfftw3f-3.dll von 32-bit system-dlls [Vit-Mod]? die jetzigen sind alle von Avisynth extension für Hybrid bis auf diese 2 ...
    werde das ganze noch mit AVISource und Directshowsource probieren bzw. auf einem anderen pc ... aber komisch.

    Selur
    Danke. habs jetzt mit setmemorymax und den avisynth & plugin-dlls von hybrid probiert. ffmpeg/ffms2.dll mit QTGMC crashed immer noch bei dieser Quelle (DV, interlaced BFF). ohne QTGMC mit ffms2 nach x264 interlaced -bff funktionierts.

    may24
    Mit l-mash-works funktioniert es leider auch nicht. (auf diesem PC mit dieser Quelle)

    Bin gerade aum austesten, wie ich aus dem DV-Video nach x264 die beste Qualität rausholen kann. hab jetzt mal testweise interlaced mit 24Mbps (Orig 24,4Mbps) und ffms2 encodiert. das ergebnis is bei der wiedergabe auf einem smart-tv nicht sehr berauschend (unscharf und teilw. sieht man vert. linien). bei der wiedergabe über den standalone bluray-player dürfte das bild etwas besser aussehen (wahrscheinlich wegen besserem deinterlacer) - kann ich aber gerade nicht testen.

    Wie dem auch sei, ich werde doch mit QTGMC vorher deinterlacen ... glaube das ergebnis ist dann etwas schärfer und sieht besser aus mit TV-Mediaplayern. Der nächste Vergleich wird mit QTGMC Preset Fast und wieder 24Mbps sein - ich glaube aber, dass man bei dieser DV-Quelle/SD-Auflösung (720x576 anamorph, 16/9-->sar 16:11, 25fps, 1h 3m) mit einer Bitrate von 8-10Mbps oder weniger wahrscheinlich auch keinen Unterschied sieht ... würde man mit QTGMC Preset Slow bessere Bildqualität erreichen und was wäre eure Empfehlung bezüglich maximal sinnvoller video bitrate?

    Hallo,

    ich habe ein Problem beim beim encoden von DV nach x264 mit QTGMC-Deinterlacing und Avisynth 2.6 MT. Win7 x86 älterer DualCore CPU (Intel E6850) und 4 GB-Ram.
    avisynth version 2.6 alpha5 + geänderte avisynth.dll für QTGMC-MT von hier. Verwendete Plugins sind QTGMC 32-bit Plugins [Vit-Mod]. Mit den ungemoddeten Vit-Plugins gibts immer Zeilenfehler in der QTGMC-3.33.avsi.
    nach ca. der hälfte des 1st pass gibts crashed x264/avisynth.dll. Crash+Megui Log: Log
    laut der QTGMC-Anleitung sollte man ja für SD-Content den Speicher nicht beschränken müssen.

    AVS-Script

    woran könnte das liegen? muss ich den speicher beschränken oder andere einstellungen/plugin versionen verwenden. auf einem anderen/besseren PC mit 64 bit OS und anderer Quelle hat es bisher so funktioniert ... jemand eine idee?

    danke für die antworten/infos. zu #15: stimmt, sry der --level parameter beschränkt ja die b/ref-frames.
    werde beim nächsten mal mein selbst gebautes mit 100%igen BluRay-Vorgaben und eine leicht abgewandelte variante aus deinem beispiel versuchen. x264 --preset veryslow --tune grain --bitrate XXXX --level 4.1 --vbv-bufsize 24000 --vbv-maxrate 24000 --pass Y

    ... ich glaube heutzutage würde man das eher so erschlagen:
    x264 --preset veryslow --tune grain --bitrate XXXX --level 4.0 --vbv-bufsize 31250 --vbv-maxrate 25000 --pass Y
    Im Grunde alles rauswerfen, was man nicht begründen kann.


    wenn ich das richtig verstanden habe, meinst du, dass meine änderungen nur länger dauern und qualitativ nichts bringen. :grübeln: ... das könnte teilweise stimmen.

    Die Wiedergabe soll auf einem Standalone-BluRay-Player und mit den internen Mediaplayern von (Smart)TVs problemlos funktionieren. mit dem standard preset veryslow mit 8 b-frames und 16 ref-frames bei 1080p und diesen bitraten funktioniert das sicher nicht; das ist das absolute minimum, das geändert werden muss. das kann ich auf jeden fall begründen. ;)
    bisher habe ich bei 1080p maximal 4 b-frames und 5 ref-frames verwendet - jetzt verwende ich maximal 3 b-frames und 4 ref-frames. avc level lasse ich doch auf 4.1 weil bei megui mit level 4.0 immer so eine lästige, falsche warnung kommt, dass vbv maxrate 24k die level 4.0 main profile bitrate-grenze von 20k übersteigt, obwohl eh das 4.0 high profile ausgewählt ist und nicht main ... würde zwar level-conform sein mit 4.0 aber bei jedem encoding diese warnung nervt --> 4.1. vbv bufsize/maxrate bleibt bei 24k. die veryslow-standalone-cl, zumindest für meinen br-player, sieht dann so aus:
    x264 --preset veryslow --tune grain --bitrate XXX --level 4.1 --bframes 3 --ref 4 --vbv-bufsize 24000 --vbv-maxrate 24000 --pass Y

    Zu meinen Änderungen:
    alle diese parameter sind ja nur wegen besserer bluray/standalone kompatibilität drinnen - glaube nicht, dass die irgendwas sonderlich viel langsamer machen ...
    --keyint 24 --min-keyint 1 --open-gop --slices 4 --aud --nal-hrd vbr
    die quantizer min/max werte weiss ich nicht mehr genau warum ich die geändert habe ... lasse ich auch, außer ihr kennt einen grund warum 0/69 besser wäre?
    --qpmin 10 --qpmax 51
    Motion Vector Range auf 32 und Subpixel Refinement auf Full-RD ist wirklich übertrieben, die sollte ich doch auf 24 und 10 stellen.
    --merange 32 --subme 11 --> --merange 24 --subme 10
    RC-lookahead hatte ich bisher auf 40 - bei veryslow ist es 60 - wahrscheinlich auch übertrieben ... lasse ich aber.

    Ich habe gerade dieselbe Quelle mit dem geränderten veryslow und mit meinem preset ausgehend von veryslow encodiert - jeweils 2-pass.
    Win7 x64, megui 2500, avisynth x86+avs4x264mod, x264 v2431 64bit-mode, Intel Core i7 2600k HT 4 Cores, 8 Threads, 8 Gb Ram
    Zielgröße ~ 15892 MB (1/3 eines DL-BluRay Rohlings); DTS Audio 1352 MB --> Video Bitrate: ~16140 Kbps (Original 24 Mbps)

    Very Slow Preset
    1st pass: 31.69 fps, Dauer: 1h 35m, Log
    2nd pass: 5.22 fps, Dauer: 10h 37m, Log

    Mein Preset mit den 'alten' placebo-werten
    1st pass: 31.99 fps, Dauer: 1h 35m, Log
    2nd pass: 4.32 fps, Dauer: 11h 40m, Log

    Prinzipiell stört es mich nicht, wenn das encoden etwas länger dauert. Ich möchte halt qualitativ das maximal mögliche herausholen und genau die Dateigröße treffen, aber halt auch nicht mit unnötig langsamen einstellungen ohne sichtbaren qualitätsgewinn das ganze in die länge ziehen.

    Zu den Presets:
    Ganz erhlich gesagt verstehe ich nicht, warum ich überhaupt ein vordefiniertes preset wie veryslow verwenden soll, wenn eh so viele werte abweichen, nur damit die cl kürzer wird ... das ändert ja auch nichts an der encoding-geschwindigkeit. ohne --preset parameter habe ich alle meine abweichenden einstellungen ausgehend von medium in der cl und ob da jetzt 5 werte drinnen stehen oder 100 ist doch vollkommen egal. also sieht mein zukünftiges preset ausgehend von medium unter megui jetzt so aus (--bframes 3 wird mit medium augeblendet):

    Code
    program --level 4.1 --tune grain --pass Y --bitrate XXX --stats ".stats" --keyint 24/25/30 --min-keyint 1 --open-gop --b-adapt 2 --ref 4 --slices 4 --qpmin 10 --qpmax 51 --vbv-bufsize 24000 --vbv-maxrate 24000 --rc-lookahead 60 --merange 24 --me umh --direct auto --subme 10 --partitions all --trellis 2 --aud --nal-hrd vbr --output "output" "input"

    was euch wahrscheinlich besser gefallen würde wäre:
    --level 4.1 --bluray-compat --preset veryslow --tune grain --pass Y --bitrate XXX --open-gop --ref 4 --slices 4 --vbv-bufsize 24000 --vbv-maxrate 24000

    ich bleibe aber bei meinen jetzt vl etwas weniger placebo-artigen (merange/subme) einstellungen. man lernt nie aus, danke. btw das ruckeln bei einer 2. audiospur am br-player besteht weiterhin ... egal werde ich mich halt mit einer zufrieden geben müssen. hier noch ein bitraten/peaks vergleich vom original und meinem reencode:

    1.jpg

    danke für eure hilfe. ;D

    habe mein preset etwas angepasst. da ich aber auch bei very slow meine abweichenden werte (gop, quantizer, subme, ...) drinnen haben will, ist es trotzdem sehr lange. nachdem ich eigentlich immer schon ein selbst-erstelltes preset unter megui gespeichert habe bei dem ich dann eh nur mehr bitrate anpasse stört das nicht weiter. vbv bufsize/maxrate lasse ich beides auf 24k - bilde mir ein, wo gelesen zu haben, dass bufsize nicht größer sein soll als maxrate, aber wahrscheinlich wäre das auch egal. weightp/b-pyramid lasse ich auf standard und sar lasse ich auch weg. also sieht meine cl jetzt so aus:

    Code
    --level 4.0 --preset veryslow --tune grain --pass 2 --bitrate xxxxx --keyint 24/25/30 --min-keyint 1 --open-gop --bframes 3 --ref 4 --slices 4 --qpmin 10 --qpmax 51 --vbv-bufsize 24000 --vbv-maxrate 24000 --merange 32 --subme 11 --aud --nal-hrd vbr

    LigH, Selur
    naja, also der einzige grund warum ich die parameter einzeln angebe und nicht --bluray-compat verwende ist, da ansonsten immer die reference frames auf 3 gesetzt werden, obwohl ich 4 eingestellt habe. (wobei es egal ist, ob der output im mkv-container landet oder im elementary stream bleibt; änderungen an den vbv-werte funktionieren)

    megui-cl

    Code
    program --level 4.1 --bluray-compat --tune grain --crf 14.0 --keyint 24 --open-gop --b-adapt 2 [B]--ref 4[/B] --slices 4 --qpmin 10 --qpmax 51 --vbv-bufsize 30000 --vbv-maxrate 30000 --merange 32 --me umh --direct auto --subme 11 --partitions all --trellis 2 --sar 1:1 --output "output" "input"

    mediainfo test-mkv

    Code
    Format settings, [B]ReFrames: 3 frames[/B]Encoding settings: cabac=1 /[B] ref=4[/B] / deblock=1:-2:-2 / analyse=0x3:0x133 / me=umh / subme=11 / psy=1 / psy_rd=1.00:0.25 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=6,6 / fast_pskip=1 / chroma_qp_offset=-4 / threads=12 / lookahead_threads=1 / sliced_threads=0 / slices=4 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=1 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=1 / weightp=1 / keyint=24 / keyint_min=1 / scenecut=40 / intra_refresh=0 / rc_lookahead=24 / rc=crf / mbtree=1 / crf=14.0 / qcomp=0.80 / qpmin=10 / qpmax=51 / qpstep=4 / vbv_maxrate=30000 / vbv_bufsize=30000 / crf_max=0.0 / nal_hrd=vbr / filler=0 / ip_ratio=1.10 / aq=1:0.50

    mediainfo test-rawavc

    Code
    Format settings, [B]ReFrames: 3 frames[/B]Encoding settings: cabac=1 / [B]ref=4[/B] / deblock=1:-2:-2 / analyse=0x3:0x133 / me=umh / subme=11 / psy=1 / psy_rd=1.00:0.25 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=6,6 / fast_pskip=1 / chroma_qp_offset=-4 / threads=12 / lookahead_threads=1 / sliced_threads=0 / slices=4 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=1 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=1 / weightp=1 / keyint=24 / keyint_min=1 / scenecut=40 / intra_refresh=0 / rc_lookahead=24 / rc=crf / mbtree=1 / crf=14.0 / qcomp=0.80 / qpmin=10 / qpmax=51 / qpstep=4 / vbv_maxrate=30000 / vbv_bufsize=30000 / crf_max=0.0 / nal_hrd=vbr / filler=0 / ip_ratio=1.10 / aq=1:0.50


    es scheint so, als hab ich jetzt endlich herausgefunden, was das ruckeln am br-player verursacht:

    - beim alten encoding wars wirklich die zu hohe bitrate und/oder vbv zu hoch --> ruckeln
    - beim neuen encoding wird das video alleine und auch mit einer audiospur rucklefrei abgespielt

    sobald aber eine 2. audiospur dazukommt --> ruckeln. wobei es egal ist was für ein audioformat: dts,ac3,aac. anzumerken ist auch, dass die gesamte bitrate: video+audio1und2 bei 24,8 Mbps liegt - also kanns an der 25 Mpbs Grenze eigentlich auch nicht liegen. sehr interessant.
    :ratlos:

    Die Bitrate-Peaks sind jetzt bei 40,2 Mbps statt 48,8 vorher. ich glaube zwar, dass wenn die bitrate beim alten encoding 24 Mbps statt 25,7 gewesen wäre, hätte es mit den standard vbv-werten auch ev funktioniert. mit 30.000/30.000 bin ich aber eher auf der sichereren/kompatibleren seite.
    maxrate-30-30.jpg

    Jetz habe ich endlich, glaube ich, die für meinen br-player 'bestmöglichen/maximalen' einstellungen gefunden: prinzipiell gleich wie --bluray-compat, nur mit 4 reference frames, b-pyramid normal und vbv buffer/max 30.000/30.000, GOP ist zwar bei meiner hardware eigentlich egal, da aber das seeken schneller funktioniert lass ich das auch auf Fixed mit max 24/25/30 (je nach fps) und min 1. Maximale Video Bitrate 24 Mbps.

    megui-cl:

    Code
    program --level 4.1 --tune grain --pass 2 --bitrate 24000 --stats ".stats" --keyint 24 --min-keyint 1 --open-gop --b-adapt 2 --ref 4 --weightp 1 --slices 4 --qpmin 10 --qpmax 51 --vbv-bufsize 30000 --vbv-maxrate 30000 --merange 32 --me umh --direct auto --subme 11 --partitions all --trellis 2 --aud --nal-hrd vbr --sar 1:1 --output "output" "input"

    mediainfo der finalen version mit einer dts audiospur: link

    für verbesserungsvorschläge bin ich natürlich offen/dankbar. medium war standard - dauert so auch sehr lange - bei dieser datei und meiner doch sehr guten hardware 1st pass 1h, 2nd pass 7 h.

    Update: mhm, hab mich wohl zu früh gefreut, bei komplexen/schnellen Szenen ist das ganze trotz der neuen Einstellungen wieder nur eine Diashow ... weiss jetzt glaube ich auch warum: die Bitrate(Peaks) ist einfach zu hoch für meinen alten br-player, im Handbuch steht zwar dazu nichts aber beim Nachfolger ist die maximal unterstützte Video Bitrate im mkv-container bei x264-1080p mit 25 Mbps angegeben und DTS-HD hat im mkv-container auch noch nie funktioniert (vl nur direkt von der bluray/BDMV, unterstüzt wird es angeblich) weswegen ich immer nach dts downconverten muss ... naja wenigstens weiss ich jetzt das limit :D

    hier ein schöner vergleich mit bitrateviewer: links mein encoding mit peaks bei 48,8 Mbps, average 25,76 Mbps und rechts eine andere datei/quelle mit peaks bei 41,65 Mbps average 24,55 Mbps (die ohne ruckler problemlos wiedergegeben wird; zugegeben, die 2. datei hat nicht viel 'action/schnelle szenen')

    bitrate-comparison.jpg

    angesichts dieser tatsachen werde ich --vbv-bufsize --vbv-maxrate anpassen ... ich probiers mal mit 30/30 Mbps bei einer Bitrate von 24 Mbps statt 25,7. lt. dieser quelle muss angeblich auch -sar vorhanden sein und --keyint auf 1 Sekunde GOP beschränkt werden um theoretisch ganz kompatibel zu bleiben - also habe ich GOP auf fixed mit max 24 und min 1 gestellt.

    neue megui cl:

    Code
    program --level 4.1 --tune grain --pass 2 --bitrate 24000 --stats ".stats" --keyint 24 --min-keyint 1 --open-gop --b-adapt 2 --ref 4 --weightp 1 --slices 4 --qpmin 10 --qpmax 51 --vbv-bufsize 30000 --vbv-maxrate 30000 --merange 32 --me umh --direct auto --subme 11 --partitions all --trellis 2 --aud --nal-hrd vbr --sar 1:1 --output "output" "input"

    mein br-player kann keine dateien im *.ts container abspielen, BMDV-Discs erstelle ich nicht, wenn dann nur Daten-Discs mit UDF 2.5 und den einzelnen Datein bzw. erfolgt die Wiedergabe meist über USB (externe HD oder USB-Stick). ich verwende fast immer den mkv-container (sehr selten avi oder mp4, aber zb auch 1080i-mpeg2-interlaced von *.ts nach *.mkv geremuxt funktioniert)

    danke für eure antworten. megui ist die aktuelle version vom dev update server: v2500, x264 sollte auch aktuell sein v2431 (komisar) und zum muxen verwende ich mkvmerge/mkvtoolnix, auch aktuell v6.9.1 x64 mit '--clusters-in-meta-seek' weil sonst das seeken auf meinem älteren br-player nicht funktioniert. mein megui-x264 profil schaut so aus: bild bzw das xml-profil selbst: link - kA ob das veraltet ist. ruckeln wegen anderer (ton)spuren oder muxproblemen kann ich ausschließen, da es ja mit den anderen settings ruckelfrei funktioniert hat.

    open-gop, weightp und slices werde ich dann so lassen wie oben zwecks kompatibilität. interresant ist gerade bei dieser quelle noch, dass sogar das original-file sehr selten wenige, kurze ruckler und sehr kurze bildfehler am br-player verursacht, obwohl es nur 2 ref-frames hat ... wahrscheinlich deswegen, weil die variable bitrate kurzzeitig zu hoch ist (vbv buffer/maximum zu hoch oder nicht eingestellt ist). obwohl man doch meinen müsste, dass das original br-kompatibel encodiert wurde, vl ist auch mein br-player schon zu alt. mehr info lässt sich aus der quelle leider nicht herauslesen, aber egal hab jetzt meine einstellungen gefunden, danke. ;)

    Hallo,

    ich bin gerade dabei, die maximal unterstützten/möglichen bluray-kompatiblen x264 einstellungen für mich zu ermitteln. Grund war ein Encoding, dass zwar noch DXVA kompatibel ist, auf meinem BR-Player aber nicht ohne stottern nach ein paar minuten wiedergegeben werden kann. einer der gründe dafür könnte sein: ref-frames zu hoch, vbv unbeschränkt, b-pyramid auf normal und keine slices ... bei derselben auflösung mit geringeren bitraten und niedrigeren auflösungen haben diese einstellungen bisher immer ruckelfrei am brplayer funktioniert.

    Encoding settings:

    Code
    program --tune grain --pass 2 --bitrate 25730 --stats ".stats" --bframes 4 --b-adapt 2 --ref 5 --qpmin 10 --qpmax 51 --merange 32 --me umh --direct auto --subme 11 --partitions all --trellis 2 --output "output" "input"

    Mediainfo:

    Code
    GeneralUnique ID                                : 171885300564693696303470707452762119228 (0x814FE79CC32C9AFC96F607C08A5FDC3C)Complete name                            : E:\not-important.mkvFormat                                   : MatroskaFormat version                           : Version 4 / Version 2File size                                : 17.4 GiBDuration                                 : 1h 30mnOverall bit rate                         : 27.4 MbpsEncoded date                             : UTC 2014-05-23 03:23:07Writing application                      : mkvmerge v6.9.1 ('Blue Panther') 64bit built on Apr 18 2014 18:23:38Writing library                          : libebml v1.3.0 + libmatroska v1.4.1VideoID                                       : 1Format                                   : AVCFormat/Info                              : Advanced Video CodecFormat profile                           : High@L4.1Format settings, CABAC                   : YesFormat settings, ReFrames                : 5 framesCodec ID                                 : V_MPEG4/ISO/AVCDuration                                 : 1h 30mnNominal bit rate                         : 25.7 MbpsWidth                                    : 1 920 pixelsHeight                                   : 800 pixelsDisplay aspect ratio                     : 2.40:1Frame rate mode                          : ConstantFrame rate                               : 23.976 fpsColor space                              : YUVChroma subsampling                       : 4:2:0Bit depth                                : 8 bitsScan type                                : ProgressiveBits/(Pixel*Frame)                       : 0.699Title                                    : x264-1920x800@25.7MbpsWriting library                          : x264 core 142 r2431 ac76440Encoding settings                        : cabac=1 / ref=5 / deblock=1:-2:-2 / analyse=0x3:0x133 / me=umh / subme=11 / psy=1 / psy_rd=1.00:0.25 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=6,6 / fast_pskip=1 / chroma_qp_offset=-4 / threads=12 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=4 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=25730 / ratetol=1.0 / qcomp=0.80 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.10 / aq=1:0.50Language                                 : EnglishDefault                                  : YesForced                                   : NoAudio #1/#2/Chapters ...

    Hab mir die BR-Spezifikationen durchgelesen. Das croppen werde ich in Zukunft lassen; wenn ich unter den x264-settings unter megui als target-playback-device blu-ray auswähle, werden u.a. die b & ref-frames auf 3 gesetzt, open GOP eingeschaltet, die slices auf 4 gestellt und die VBV Buffer Werte beschränkt. dh. wenn ich die tabelle richtig verstanden habe: eigentlich kann man dann ja nur mehr die reference frames auf 4 erhöhen damits noch kompatibel bleibt, richtig? Nur muss ich dazu target-playback-device wieder auf default stellen und b-pyramid auf normal da ansonsten obwohl 4 ref-frames ausgewählt ist trotzdem nur 3 verwendet werden ...

    Code
    program --level 4.1 --tune grain --pass 2 --bitrate 25730 --stats ".stats" --open-gop --b-adapt 2 --ref 4 --weightp 1 --slices 4 --qpmin 10 --qpmax 51 --vbv-bufsize 30000 --vbv-maxrate 40000 --merange 32 --me umh --direct auto --subme 11 --partitions all --trellis 2 --aud --nal-hrd vbr --output "output" "input"

    Mit diesen Einstellungen funktioniert eine ruckelfreie Wiedergabe am BR-Player. Meine eigentliche Frage ist jetzt, ob man an diesen Einstellungen noch was 'verbessern' kann. b-pyramid ist auf normal, ref-frames auf 4, b frames auf 3. Würde es qualitativ etwas bringen wenn man
    - P-Frame Weighted Prediction auf Smart statt Blind stellt
    - Open GOP weglässt oder
    - die slices wieder auf 0 stellt.

    Und wie siehts dann mit der Kompatibilität aus?

    LigH
    danke werde ich probieren.

    Taurus
    Also crf kommt für mich nicht in frage, denn ja, ich bin noch so einer der wirklich auf DVD brennt. In diesem Fall je 1 Season auf 1 DVD-9 (8150 MB) - sind dann pro Episode nur 313-370 MB deswegen 2-pass. Ich habe zwar selber auch mehrere Terabyte-Festplatten ... eine mit 4, eine mit 2 usw. aber wenn die mal kaputt gehen verliere ich auf einen Schlag alles, deswegen sichere ich immer noch zusätzlich auf DVD. Davon abgesehen, mit mehreren Serien/Filmen die dann vl auch noch in HD sind, werden selbst Terabyte-Festplatten sehr schnell voll ;)

    Zur Qualität: normalerweise, wenn die DVD-Qualität besser wäre (vor allem schärfer) würde ich die Episodengröße mind. verdoppeln, aber habs gerade nochmal verglichen (side by side orignal + rip), selbst mit diesen niedrigen Einstellungen sehe ich fast keinen Unterschied, da das Original wirklich verschwommen/unscharf ist und zusätzlich nachschärfen will ich auch nicht. Mit yadif war das Ergebnis noch mehr verschwommen als das Original, mit QTGMC sehe ich wie gesagt fast keinen Unterschied.

    Danke für die Antworten. ColorMatrix kann ich sicher weglassen (dgindex.log BT.470-2) und Distributor() im Skript auch. Habs gerade nochmal mit 4 statt 8 Threads probiert - beim 2nd pass macht das keinen Unterschied, aber beim 1st pass ist die CPU nur 60 statt 98% ausgelastet - Zeit/fps mäßig macht das aber auch nicht viel Unterschied - ein paar fps weniger halt. Lossless wäre zwar auch eine Möglichkeit (hätte Sogar Platz auf meiner SSD) ist mir dann aber doch zu viel Aufwand für solch eine Quelle ... danke somit wäre alles geklärt.

    Es wäre fein wenn QTGMC irgendwann einmal unter megui in den Avisynth-Script-Creator aufgenommen werden würde ... für uns tippfaule Gui-Leute ;)

    Hallo, bin gerade dabei eine alte Serie ('87-'97), die ich mir als DVD-Box Set gekauft habe nach mkv(x264/ac3) zu encoden. Das Quellmaterial der originalen DVDs ist qualitativ nicht besonders gut wird aber im laufe der Seasons etwas besser. Megui's Interlacing Analyse schlägt meist partially interlaced oder interlaced mit yadif vor, bei manchen Episoden aber auch hybrid mostly interlaced mit TIVTC. Das TIVTC Deinterlacing funktioniert bei dieser Quelle leider nur unzureichend, da im Endergebis bei Bewegungen immer noch kleine horizontale Linien zu sehen sind. Yadif funktionierte einwandfrei, wesshalb ich es auch für die bisherigen Seasons verwendet habe. Wenn ich aber am Ende die DVD-Originalqualität(interlaced) mit der von mir x264-yadif(deinterlaced) vergleiche, muss ich feststellen, dass das ganze noch verschwommener (blur) geworden ist bzw. auch einige Details verloren gegangen sind (subjektiver Eindruck).

    Also hab ichs mit QTGMC versucht und finde das Ergebnis erheblich besser als mit yadif. Installation wie hier beschrieben hat funktioniert, Multithreading geht bei mir auch gut und stabil. Habe in meinem Fall vom Present Slow auf Fast gewechselt, da das bei meiner Quelle wirklich keinen visuellen Unterschied macht. Damit erreiche ich mit meinem avs-skript (avisynth 2.6 x86) unter megui beim 1st pass 55 fps und beim 2nd pass 22 fps, cpu-auslastung 94-98% (Core i7 2600K HT, 4 Cores 8 Threads). Da ich absichtlich nicht croppen oder resizen will, um die Original-Auflösung beibehalten zu können (720x576 DAR 4:3 mit dem anamorphen Seitenverhältnis) und auch die 25 fps beibehalten will sieht meine avs-Datei so aus:

    Avisynth-Script

    Code
    # Set DAR in encoder to 4 : 3. The following line is for automatic signallingglobal MeGUI_darx = 4global MeGUI_dary = 3LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgindex\DGDecode.dll")#SetMemoryMax(M)  # Optional line. See below for value MSetMTMode(3, 8)  # See below for value X, could try 5 instead of 3 for non-standard source-filter/avisynth combinationsDGDecode_mpeg2source("E:\VTS_01_1.d2v", info=3)SetMTMode(2)QTGMC( Preset="Fast", EdiThreads=1 ) # Choose preset based on overall speed/quality you want. See below for value YSelectEven()Distributor() # This line may or may not be necessary, try removing it and see if you get more speed#LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")#ColorMatrix(hints=true, interlaced=true, threads=0)#crop#resize#denoise

    x264-Encoding Settings

    Code
    cabac=1 / ref=5 / deblock=1:-2:-2 / analyse=0x3:0x133 / me=umh / subme=11 / psy=1 / psy_rd=1.00:0.25 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=6,6 / fast_pskip=1 / chroma_qp_offset=-4 / threads=12 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=4 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=1520 / ratetol=1.0 / qcomp=0.80 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.10 / aq=1:0.50


    Jetzt zu meinen Fragen:

    - Anhand von meiner CPU dürften die MT-Einstellungen von QTGMC passen, oder? (Max-Memory ist bei SD-Material ja nicht notwendig)
    - Egal wo oder wie ich ColorMatrix im Skript aktiviere, bekomme ich unterschiedliche fehlermeldungen, bzw. crashes in megui. brauche ich das unbedingt - merke von den Farben her keinen Unterschied?
    - Da ich immer 2-pass x264 encodiere (um aufs MB genau die Dateigrösse zu erreichen) - kann man da noch was optimieren, dass der 1st pass schneller geht? QTGMC muss auch beim analyse pass aktiv sein, richtig?
    - Was genau mach eigentlich Distributor() im Skript?

    ... man weiss nie was man bekommt. :lol:

    dürfte wahrscheinlich daran liegen. hab mit den thread einstellungen von ffdshow & x264 noch etwas herumexperimentiert (preview & encode) - bei zb nur 1 statt 8 kommt mir subjektiv vor, dass die ruckler etwas weniger werden, da sind sie aber noch immer - egal mit FFVideoSource hat eh alles funktioniert. hab noch ein anderes x264 video mit 20 threads gefunden (allerdings ohne diese slice enc-einstellungen) - directshowsource preview 8 threads ruckelfrei.

    .... (was in keinster Weise bedeuten muss, dass ein Reencode auch ruckeln würde,..)

    mhm naja mir ist es ja erst nach dem DirectShowSource reencode aufgefallen, dass es ruckelt - also in diesem fall bedeutet es das schon. der reencode und die vorschau mit FFVideoSource ist ruckelfrei. ich habe einen Quadcore i7 2600k mit Hyperthreading, der 64bit modus für x264 ist in megui eingeschalten und die threads stehen auf 8. aber an dem kanns ja gar nicht liegen wenn das nur mit diesem video reproduzierbar ist, dann müsste ja jeder directshowsource x264 reencode ruckeln, oder? ich probierst später nochmal ohne hyperthreading mit 4 threads, glaub aber nicht, dass das daran liegt.

    bin beim umwandeln von einem 720p video (x264/dts) auf ein kurioses problem gestossen. beim erzeugen des avs-skripts mit DirectShowSource gibt es bereits im vorschaufenster ruckler alle paar sekunden. wenn ich aber mit dem file indexer/ffms2 die datei indizieren lasse und danach die mit FFVideoSource erstellte avs-datei abspiele funktioniert das ganze flüssig/ruckelfrei. die quelldatei ruckelt auch in keinem einzigen player mit oder ohne ffdshow/dxva. andere x264/720p videodateien lassen sich auch ruckelfrei via DirectShowSource in megui abspielen/encodieren nur mit dieser einen gibts anscheinend probleme.

    alle verwendeten komponenten sind auf dem neuesten stand: megui x86 (svn 2117), ffdshow x86 (clsid svn rev 4382), ffdshow x64 (clsid svn rev 4382), avisynth x86 2.6.0.2 (Alpha 3). haali splitter, Win7DSFilterTweaker 5.1 & ffdshow sind richtig eingestellt. das video hat folgende encoding optionen:

    Code
    Writing library: x264 core 120 r2164 da19765
    Encoding settings: cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=18 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=4383 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00

    habt ihr vl eine ahnung woran das liegt - megui, avisynth, ffdshow, vfw, haali, win7 x64 oder kann es sein, dass vl diese 2 einstellungen die ruckler erzeugen chroma_qp_offset=-2 / threads=18?

    danke vielmals für eure hilfe. durch den ordnerpfad nicht verwirren lassen - habe alle meine multimedia-dateien dort gespeichert. hierbei handelt es sich um eine etwas ältere selbst gemachte umwandlung meines gekauften ST-dvd-box sets ;) jyp schau das immer noch, lediglich die untertitel sind aus dem netz.

    mit hybrid + den richtigen einstellungen lässt sich das ganze viel einfacher bewerkstelligen - auch zb kapitel beibehalten, nur 1. audiospur etc.

    danke.

    hallo,

    da ich des öfteren mkv-dateien wegen brplayer kompatibilität remuxen muss und das viele herumgeklicke in der mkvmerge-gui (joblist) gerade bei vielen dateien mit gleichen encoding-optionen (tracks/ids) doch etwas lästig ist, würde ich gerne ein batch file erstellen, dass diese aufgabe für alle mkv-dateien im ordner ausführt.

    also in- & output mkv (x264/ac3) dateiname + zusatz, header removal compression disabled, cl-option --clusters-in-meta-seek. was ich gerne automatisiert haben möchte wäre best. ids/tracks (zb nr 3 für untertitel) automatisch entfernen zu lassen.

    so würde die cl für zb die 1. datei im ordner mit diesen optionen aussehen:

    Code
    "C:\Program Files (x86)\MKVToolNix\mkvmerge.exe" -o "E:\\File (1).mkv"  "--language" "0:eng" "--default-track" "0:yes" "--forced-track" "0:no" "--display-dimensions" "0:644x496" "--compression" "0:none" "--language" "1:eng" "--default-track" "1:yes" "--forced-track" "1:no" "--compression" "1:none" "-a" "1" "-d" "0" "-S" "-T" "--no-global-tags" "E:\\File.mkv" "--track-order" "0:0,0:1" "--clusters-in-meta-seek"

    wie muss das für eine batch datei aussehen? hoffe ihr könnt mir helfen.