Beiträge von matmiller

    Würdest du uns nun bitte endlich mal einen ausführlichen Report deiner MKV-Datei zeigen, von der dein Fernseher behauptet, sie hätte 50 fps? Der Filmname ist das einzig uninteressante; sämtliche anderen technischen Details wären aber hilfreich, dass wir nicht auf Spekulationen angewiesen sind. :rolleyes:

    Ist das hier ausreichend?:

    Aktuelle Versionen von mkvmerge sollten mittlerweile auch (m2)ts-Dateien direkt in MKV konvertieren können, ohne dass man das Material vorher demultiplexen müsste. Das hätte den Vorteil, dass mkvmerge dann auch aus dem TransportStream-Kontainer noch Eigenschaften über den Videostream herauslesen kann, die aus dem rohen AVC-Videostrem nicht abzulesen sind.

    Ich hatte bis vor ein paar Tagen noch eine ältere Version von mkvmerge GUI und da hatte ich bei den meisten dateien Stotterer drin, wenn ich den original TS reingezogen und neu gemuxt habe. Wenn ich die einzelnen Streams reingezogen habe, hatte ich dieses Problem nicht. Hab mit der neuen Version noch keinen Test in dieser Richtung gemacht, aber werde ich auch mal machen.

    Also ich demuxe mit DGIndexNV (inkl. Videostream) und muxe dann alles mit mkvmergegui v7.1.0 ('Good Love') oder benutze Hybrid und lasse alle Streams auf "passthrogh". Klappt bisher beides problemlos.

    Das mit dem x264 Fake-Modus müsstest du mir nochmal genauer erklären oder ich schau einfach mal selbst nach.

    edit: also nach dem Artikel hab ich noch mehr Fragezeichen über dem Kopf.

    Das mit dem mediainfo -f hab ich auch nich nicht ganz kapiert. wenn ich das in der eingabeaufforderung eingebe, dann startet er mir mediainfo ganz normal.

    Es liegt übrigens definitiv am Samsung BluRay Player. Hab es mal auf eine externe Festplatte kopiert und spaßeshalber am Toshiba LCD TV im Schalfzimmer via USB abgespielt und da läuft es. Ich kann nur nicht ganz nachvollziehen, welches Problem der Samsung hat, da der BluRay Player neuer und fast genauso teuer war, wie der LCD im Schlafzimmer, also müsste man ja davon ausgehen, daß die Software mindestens genauso gut ist.

    Das verstehe ich nicht. Der MKV-Kontainer sollte die 25 fps melden, und auch der Videostream, wenn er mit x264 encodiert wurde...

    Das ist es ja! Ich habe nicht encodiert, sondern den original h264 stream aus der TS Datei mit den originalen AC3 Spuren in einen Matroska Container gesteckt! Wenn ich vorher mit x264 encodiere, hat mein Samsung null Probleme! Dann steht ja auch in der Mediainfo 25 fps progressive. Den Transport Stream spielt mein Samsung übrigens ab, auch wenn zwischendrin ziemliche Stotterer drin sind. Deshalb hatte ich ja die Idee das ganze in einen Matroska Container zu stecken, in der Hoffnung, daß er sich damit leichter tut. Aber wie gesagt, erhalte ich bei diesen Matroska Dateien den Fehler, daß 50 fps nicht unterstützt wird. Encodiere ich das ganze vorher mit x264 kein Problem. Aber das möchte ich ja eben vermeiden.

    Es geht auch nur um den Samsung BluRay Player. Am PC hab ich keine Probleme.

    Hab hier ein ähnliches Problem gefunden. Scheint wohl ein Problem mit der Abspielsoftware im Samsung zu sein. Gibt es keine Möglichkeit irgendwie eine progessive Quelle (die es ja eigentlich auch ist, steht nur was falsches drauf) vorzugaukeln?

    hallo allerseits.

    habe die tage mal getestet, HD "1080i" Aufnahmen (mit progressivem Inhalt) in MKV umzupacken. habe mittlerweile mehrere Methoden, wie ich das hinbekomme. Die Dateien sind synchron, haben laut Mediainfo 25 fps (interlaced) und lassen sich am PC problemlos abspielen (stotterfrei im Vergleich zum TS Format). Mein Problem liegt nun darin, daß ich diese Dateien nicht an meinem Samsung BluRay Player via Netzwerk abspielen kann, weil er die Dateien mit dem Fehler "Framerate 50 wird nicht unterstützt" abweist. Denke mal, daß es daran liegt, daß er die Datei als interlaced erkennt und mit 50 fps deinterlacen will. Gibt's da irgendeinen Trick, wie man die interlaced info aus dem Stream rausbekommt ohne mit x264 oder was auch immer neu zu encoden? Wollte sie nämlich eigentlich so lassen, weil die Bitrate i.d.R. zwischen 6000 und 8000 kbps liegt. Da macht das encodieren in meinen Augen wenig Sinn.

    Gruss matmiller

    weiss nicht, was du mit Doppel- oder Geisterbilern meinst, aber Stillstand-Bewegung ist schonmal richtig!

    du meinst, wenns progressiv ist wirds zwar als 1080i ausgestrahlt ist aber eigentlich 1080p also brauch ich im Endeffekt gar keinen deinterlacer drüber laufen lassen oder wie?!?

    hab ich natürlich gleich mal per script getestet! also kamm-effekte scheints schonmal keine zu geben!

    kann man trotzdem noch irgendwas drüber laufen lassen womit man das bild etwas schärfen kann? kenn mich mit diesen ganzen filtern nicht aus! ein link würde auch schon reichen! bin nicht lesefaul!!

    Letztlich kommt man nicht an den simplen Fakten vorbei: (Q)TGMC ist qualitativ so ziemlich das beste, was Avisynth im Bereich Deinterlacing zu bieten hat. Aber um dort hin zu kommen, muss eben auch ein vergleichsweise großer Aufwand betrieben werden. Und bei 1080-er Quellen tut der Aufwand eben weh.

    Bei der Entwicklung hab ich ausschließlich mit SD-Quellen gearbeitet. Die brauchen's auch am nötigsten - wenn SD sehr "einfach" deinterlaced wird, und dann auf einem HD-Display abgespielt wird (zwangsweise Hochskaliert), dann sieht man die Defizite mitunter durchaus deutlich. Deswegen macht solches HighQuality-Deinterlacing bei SD auch am meisten Sinn. Bei HD-Quellen fällt es leichter, sich mit einfacherem Deinterlacing zufrieden zu geben, weil die Defizite dort längst nicht so deutlich ins Auge fallen.

    Oder man nimmt einen einfachen Deinterlacer (es muss ja schnell sein!!), und fährt mit dann z.B. MVTools/MDegrainX hinterher. Dann ist's aber auch gleich wieder langsam. Weil man hiermit nämlich eine ganz ähnliche Filterkette gebaut hat wie sie TGMC intern sowieso benutzt. (Nur eben dass die nachgebaute weniger problemorientiert, und deswegen weniger optimal, aber trotzdem langsam ist ...)

    also 1. ja den qualitätsunterschied habe ich bei meiner Aufnahme gesehen! auch bei der vermeintlich schnellsten variante "TempGaussMC_beta2(1,1,1,EdiMode="NNEDI2",Smode=1,SVthin=0.0,Sbb=0,SLmode=1)"

    nutze übrigens staxrip mit eingebundenem DGIndexNV und crf 18 bei x264 mit Preset=Very Fast, Tune=Film und Device=DivX Plus

    2. Quellmaterial ist ein Spielfilm und von dem rest hab ich keine ahnung! mit mediainfo wird man das nicht rauskriegen oder? mediainfo sagt nur dass es interlaced ist (wusste ich aber vorher schon) ansonsten noch dies hier:

    Video
    ID : 767 (0x2FF)
    Menu ID : 107 (0x6B)
    Format : AVC
    Format/Info : Advanced Video Codec
    Format profile : High@L4.0
    Format settings, CABAC : Ja
    Format settings, ReFrames : 3 frames
    Codec ID : 27
    Duration : 2h 30min
    Bit rate : 6 312 Kbps
    Width : 1 920 Pixel
    Height : 1 080 Pixel
    Display aspect ratio : 16:9
    Frame rate : 25,000 FPS
    Standard : PAL
    Color space : YUV
    Chroma subsampling : 4:2:0
    Bit depth : 8 bits
    Scan type : Interlaced
    Scan order : oberes Feld zuerst
    Bits/(Pixel*Frame) : 0.122
    Stream size : 6,64 GiB (85%)
    colour_primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
    transfer_characteristics : BT.709-5, BT.1361
    matrix_coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

    ist übrigens bereits geschnitten mit DVR Studio HD 2, aber das sollte meines wissens nach irrelevant sein!

    3. muss es nicht das schnellste auf erden sein! würde auch 12 stunden encodingzeit akzeptieren, aber 3 tage ist dann doch ne spur zu happig!!

    4. SD nehme ich selten auf, aber werde es beim nächsten mal auch mit SD testen!

    5. Danke für alle Hinweise und Ratschläge!!

    6. FROHES NEUES!!!

    aha! wieder was gelernt! ich finde allerdings bei der yadif bob variante (mode=1,order=1) ist die bewegung nicht wirklich natürlich. man sieht schon einen grossen unterschied in der bewegung zum "normalen" yadif, aber sieht für mich irgendwie komisch aus!

    aber zurück zu tempgaussmc: habe mal meine tv-aufnahme mit tempgaussmc und zum vergleich mit yadif (als bob / s.o.) konvertiert und verglichen! tempgaussmc gestochen scharf yadif nicht so ganz (wenn man vorher das andere bild gesehen hat! dem gegenüber steht tempgaussmc 4 stunden für 7 minuten video! yadif (bob) 18 minuten für 7 minuten video!

    würde gerne tempgaussmc zum umwandeln nehmen, aber bei 2:15 film wären das ca. 77 Stunden also mehr als 3 tage!! habe schon die abgespeckte variante benutzt wie also kann man mit x264 noch ein bisschen mehr rauskitzeln?

    ach ja: GUTEN RUTSCH AN ALLE!!

    Es könnte schon schneller laufen. Es könnte aber auch langsamer laufen.

    "Man weiß es nicht ...."

    habe diesen parameter benutzt: (1,1,1,EdiMode="NNEDI2",Smode=1,SVthin=0.0,Sbb=0,SLmode=1) = ~1,4 fps

    vorher diesen: (mt = false, 2,2,3,0,0,0,"EEDI2",eedi2maxd=16,truemotion=true,sharpness=1.75,Sbb=2,SLrad=2,SVthin=0.75,Sovs=2) = 0,7 fps

    ist das wirklich schon das ende der fahnenstange bei nem i7 mit 3gb graka und cuda? yadif ist zwar schlechter bei genauem hinsehen, wobei ich so hohe bitraten nehme, dass das kaum auffällt, aber die geschwindigkeit würde ja dann in keiner relation stehen!

    mal ne andere frage: ist das deinterlacete material immer 50fps (bei 25fps source versteht sich) oder gibts auch ne einstellung, bei der die bitrate unverändert bleibt?

    also versuche mich schon seit ner halben stunde durch dieses forum und durch google durchzulesen und verstehe trotzdem noch nicht, was denn jetzt eigentlich wo geändert werden muss?!?

    muss man in der "TempGaussMC_beta2.avsi" bei "# Create spatially interpolated bob-clips" in der zeile "edi = (EdiMode=="nnedi2") ? clp.nnedi2(field=-2,qual=qual)" was ändern?

    versuche schon seit stunden TGMC mit Staxrip zum Laufen zu bringen, aber mehr als 1,4 fps sind nicht drin (Quelle MPEG-TS HD1080i DVB-S Aufnahme!) Kommt das hin oder muss ich nur ein paar dinge drehen und dann wird (wenigstens ein bisschen) schneller? Mit Yadif komme ich so auf ca. 18 fps!

    Falls du versuchen solltest, mit einem Staubsaugerrohr am Lüfter selbigen von Fusseln zu reinigen: Versuche, dabei den Ventilator zu blockieren. Wenn er mit hoher Geschwindigkeit dreht, kann das sein Lager beschädigen.

    ich habe einfach vorher den laptop ausgeschaltet und dann den lüfter / die lüftungsschlitze vom staub befreit. hatte aber bisher noch keine zeit zu testen obs was geholfen hat, aber so in ner stunde werd ichs testen und dann nochmal bescheid geben.

    Laptops sind grundsätzlich nicht für Hochleistungsarbeiten geeignet.

    Eine andere Möglichkeit wäre übrigens noch der MB-Tree-Modus von x264, der ziemlich viel Beziehungen zwischen Frames speichert.

    das hätte ich mir sowieso gedacht, aber da ich die halbe woche beruflich unterwegs bin und am wochenende kaum zeit hab was im fern zu gucken nehm ich mir dies und jenes auf und wandel es auch meist erst am laptop um. frag mich nicht warum ich das mache hab ich mir aus spass an der freude angewöhnt und dass ich abends im hotel einfach nur die datei anmache und weder zum anfang noch zwischen den werbeblöcken spulen muss! daher bleibt mir nur die möglichkeit am laptop zu arbeiten. helfen diese pads zum unterlegen mit zusätzlicher kühlung bei dieser problematik was?

    vielleicht ist auch der energiesparplan falsch eingestellt.
    wer weis vielleicht fuschen tuningtools jetzt auch da schon rum
    ich hoffe du verwendest sowas nicht.

    nein, tuning tools benutze ich keine und energiesparplan war so mit das erste was ich unter die lupe genommen habe. steht aber alles auf höchsleistung!

    hallo erstmal! hoffe das kann man hier reinschreiben, weil ich nicht genau weiss ob x264 der grund dafür ist!

    habe seit ca. 2 monaten folgendes problem:

    beim encodieren mit staxrip wird x264 beim encodieren stetig langsamer. als beispiel: eine aufnahme von ard oder zdf hd beginnt mit ca. 23 fps und dauert ungefähr 1 stunde. in dieser zeit sinkt die geschwindigkeit von 23 fps auf ca 15-16 fps. wie gesagt dieses phänomen tritt erst seit ca. 2 monaten auf (vorher blieb die geschwindigkeit fast konstant bei 23 fps) und das liegt nicht etwa daran, dass die bitrate sich verändert (minimal vielleicht aber vorher war das auch kein problem).

    jetzt hab ich natürlich null ahnung woran das liegen kann. dachte es könnte was mit dem arbeitsspeicher zu tun haben und habe schon an der auslagerungsdatei rumgewerkelt und arbeitsspeicher von 4gb auf 12gb aufgestockt, aber half bis jetzt alles nix! hat irgendjemand ne idee woran sowas liegen kann? habe einen intel core i7 mit 1,73GHz, 12GB Ram, Nividia GeForce GT 445M mit 3GB.

    dieses phänomen tritt übrigens nur auf meinem laptop auf! mein desktop funktioniert ganz normal ohne "geschwindigkeitsverlust"!

    bin leicht verzweifelt und hab keine ahnung wo ich als nächstes ansetzen soll! kann eine defragmentierung der festplatte bei sowas helfen? das habe ich noch nicht ausprobiert!

    also problem gelöst!! hatte doch noch irgendwo eine temp-ordner mit den raw-streams und hab die vermeintlich defekte videospur mit mkvmerge gemuxt und siehe da alles weg!! lag also doch an mp4box!

    danke an alle für die hilfe :daumen::daumen::daumen:

    mkvmerge sollte auch fertige MP4 lesen und konvertieren können.



    habe ich schon versucht! lesen und remuxen funktioniert, aber die stotterer sind immer noch da! heisst das, dass der konvertierte x264-stream kaputt ist oder dass er beim muxen von mp4box kaputt gegangen sein könnte?

    edit: hab mir spasseshalber mal den kmplayer runtergeladen und da sieht das ganze schon wieder ein wenig anders aus! die *.mp4 spielt er an der defekten stelle einfach nur langsamer ab (sieht aus wie halbe geschwindigkeit).

    wäre ne massnahme! schade, dass ich die .264 und .m4a rohdateien nicht mehr habe, sonst würde ich einfach nochmal neu zu matroska muxen, aber werde am wochenende mal in mp4 und mkv muxen und dann werde ich ja sehen. danke für den tipp! werde euch auf dem laufenden halten!

    habe jetzt mit weighted p-frames "disabled" encoded und das ergebnis ist genau das gleiche!daran lag es also nicht! das problem tritt immer bei einem bildwechsel (andere kameraeinstellung) auf und endet entweder beim nächsten bildwechsel oder falls so schnell kein bildwechsel kommt erst nach 5-6 sekunden. wer hat ne idee was das sein könnte und hilft mir vielleicht wirklich nur noch meinen pc komplett neu aufzusetzen und alles neu zu installieren, weil bis vor ein paar wochen hatte ich diese probleme wie gesagt noch nicht. mir fällt auch spontan kein programm ein, was ich zu diesem zeitpunkt installiert haben könnte, was evtl. diese probleme verursacht.

    [I]Also entweder x264 oder DivX Plus. Das sind jeweils unterschiedliche Encoder. Und DivX Plus (als EXE) bringt deutlich schlechtere Qualität. Vielleicht kann man aber x264 so in der Leistung reduzieren, dass zu DivX Plus kompatible Ergebnisse entstehen.



    mir ist das rekativ wurscht! es gab nur ab irgendeiner staxrip-version divx-plus als startup und daher dachte ich dass es etwas gutes wäre! meint ihr, wenn ich die einstellungen als standard lasse mit p-frames und x264 statt divxplus als encoder nehme dürfte mein problem auch gelöst sein?

    edit: also dixplus disablen und weighted p-frames "smart" hat das gleiche ergebnis gebracht. von der qualität an sich hab ich jetzt keinen grossen unterschied gesehen! werde am wochenende mal weighted p-frames "disablen" und wenn das auch nichts hilft vielleicht noch direct mode auf "auto" stellen, aber erst mal abwarten! werde euch auf jeden fall mitteilen, wenn das problem wirklich mal gelöst ist.

    wahrscheinlich "weighted P-frames".



    wusste erst mal nicht wo ich das einstellen soll, aber habe mal gegooglet und auch eine kurze erklärung von der VLC-Seite bekommen, dass besonders deim faden der bilder probleme auftreten könnten! das erklärt warum das problem immer nach bildwechseln vorkommt. klingt also alles mehr als plausibel!

    habe nur noch eine frage: soll das so aussehen [Blockierte Grafik: http://www.pictureupload.de/originals/pictures/111110025453_pframes.jpg] oder soll noch irgendwas davon aktiv bleiben?

    vielen dank schon mal für deine mühe!!