Beiträge von LigH

  • Diverse Fragen zu HEVC/H.265/X.265/AMD H.265 und HDR

    F: CRF ist eine Bitratensteuerung, die außer x264 (und x265) kaum ein anderer Encoder ebenso anbietet. Die meisten dürften feste Quantisierungsfaktoren oder Zielbitrate unterstützen. Ob ein Hardware-Encoder überhaupt eine vergleichbare Qualität erreichen kann, ist ziemlich fragwürdig, weil diese Chips das Video oft mit ziemlich geringer Komplexität berechnen, ähnlich den schnellsten Presets on x264 oder anderen Kompatibilitätseinschränkungen.


    G: Ob der Encoder überhaupt 10-bit-Tiefe unterstützt, würde ich bezweifeln, bis mit jemand die Passage in der technischen Dokumentation des Encoderchips zeigt...


    P.S.: Micha ist sehr beschäftigt, oft auch im Ausland. Für einen Umbau der Forenstruktur hätte er wohl kaum Zeit.

  • VHS - Digitalisieren - Ton Verzerrt und zweiter VHS-Recorder Defekt

    Du musst auch bedenken, dass zu dem Zeitpunkt, als das Tutorial erstellt wurde, VirtualDub2 so noch nicht existierte. Und das Tutorial wird aufgrund seiner extremen Größe auch möglichst nicht mehr wesentlich überarbeitet... aber vielleicht kann man Aktualisierungen als Antwort anfügen, wenn ich es wieder öffne. Mal schauen, ob Gubel was vorhat...

  • VHS - Digitalisieren - Ton Verzerrt und zweiter VHS-Recorder Defekt

    Na, im Grunde wäre YUV 4:2:2 schon richtig, und zwischen YUY2 (YUYV) und UYVY sollte wenig Unterschied bestehen, lediglich in der Reihenfolge der Komponenten (endianness). Ein Haken könnte die Ut-Codec-Bibliothek sein, je nach Aktualität des Ut-Codecs einerseits und des ffmpeg-Kerns von X-Media Recode andererseits könnte es da Unterschiede geben. Du kannst also auch gern mal andere verlustlose Videocodecs ausprobieren, die von XMR vielleicht auch unterstützt werden (z.B. Huffyuv oder FFV1, die müssten in der ffmpeg-Codecauswahl im neueren VirtualDub2 intern verfügbar sein).


    In Zukunft bitte daran denken, dass es für uns grundsätzlich immer nützlich ist, möglichst exakte Details über Videodateien zu wissen, bei denen etwas nicht wie erwartet funktioniert; dabei hilft die Analyse durch MediaInfo (eine einfache Ausgabe davon hat der MPC-HC in seinem Info-Dialog via Shift+F10), im Fall von AVI-Dateien genügt oft auch schon der Dialog "File Info" in VirtualDub bzw. VirtualDub2.


    Vielleicht kannst du nach dem Capturing anschließend auch gleich VirtualDub2 zum Encodieren verwenden, damit kann man auch z.B. mit dem integrierten x264 (Interlaced-Modus oder nach Deinterlacing) in MP4 oder MKV speichern, und für die Tonspur kann man die ffmpeg-Audio-Codecs AAC oder LAME-MP3 verwenden.

  • Kodier Programm Einstellungen

    Es könnte aber auch sein: In irgendeiner Super-Duper-Anleitung steht 5000 kbps. Das wird ohne nachzudenken übernommen. Und bei der Spieldauer von 4 Stunden und einem schnellen Preset (bedenke die 2 ReFrames, eigentlich nur 1 laut Parameterliste, außerdem ABR-Modus – etwa nur 1 Durchgang?) kommen dann zufällig 8,39 GB heraus. Dann würdest du von der umgekehrten Kausalität ausgehen, weil du spekulierst.

  • Was ist mit diesem h264-BluRay-File los?

    Ich würde auch vermuten, dass da u.U. das Ende des Vorspanns in seiner .mts-Datei abgeschnitten ist, und an der Stelle, an der er durch Playlists mit der eigentlichen Folge zusammengefügt wird, sich dann ein unvollständiges Frame befindet. Vielleicht kann man ja die Folgen ohne Vorspann konvertieren.

  • Was ist mit diesem h264-BluRay-File los?

    Der Kontainer heißt "Matroska", weil er wie die russische Puppe einen vielfältigen Inhalt haben kann. Nicht weil er von einem Russen entwickelt wurde.


    Selbstverständlich muss die Unterstützung eines Kontainers für ein bestimmtes Anwendungsprogramm programmiert werden. Und das ist bei der Komplexität des Matroska-Kontainers sicher nicht einfach. Aber dafür existieren ja schon u.a. die Bibliotheken "libEBML" und "libMatroska". Die könnte man u.U. benutzen, wenn deren Lizenz das zulässt. Das alles ist aber kein Anlass, der Matroska-Spezifikation die Schuld zu geben, wenn die Implementierung nicht korrekt ist, und erst recht nicht, wenn da eigener Code zum Einsatz kommt, der gar nicht vom Matroska-Team stammt.


    Gleiche Bitraten sind grundsätzlich keine Garantie für gleiche Qualität. Zum einen könnte ein anderer oder anders eingestellter Encoder zum Einsatz kommen; zum anderen verschlechtert sich die Qualität mit jeder Generation einer Recodierung weiter.


    Und ... Pro Jo – was redest du über ein "Aufnahmemedium", wenn Matt Kirby doch geschrieben hat, dass er eine Blu-ray-Disk ausgelesen hat?


    Für die Analyse der Videospur fehlen mir leider Mittel (Ablaufverfolgung der Decodierung im Streamparser und Videodecoder) und Zeit. Wenn es allerdings Sprünge in Timecodes und Frameabfolge gibt, dann handelt es sich sicherlich um einen technischen Fehler, aber ich könnte wohl kaum zuverlässig herausfinden, ob der erst beim Auslesen durch makeMKV entstanden ist oder bereits während der Produktion der Blu-ray.

  • Kodier Programm Einstellungen

    Ich empfehle, nicht einfach ohne eine Aussage des Threadstarters anzunehmen, dass das Ergebnis auf eine DVD soll. Erst wenn wir den Zweck kennen, können wir optimale Tipps für genau diesen Zweck geben. Ohne jede Einschränkung würde man sonst den CRF-Modus verwenden.


    Also warten wir auf mehr Details von tom1984 ...

  • Kodier Programm Einstellungen

    Ich fasse mal die relevante Aussage (bis vor die Stelle zu den "Profis") zusammen: Die maximale Anzahl Referenz-Frames ist eine Einstellungen in den Tiefen des x264-Encoders; ob XMR dir als Nutzer die Möglichkeit bietet, diesen Parameter festzulegen, kann ich im Moment nicht ausprobieren, ich weiß aber, dass es auch andere Konvertierprogramme gibt, die eine so exakte Steuerung ermöglichen.


    Laut Dokumentation der x264-Presets würde auch das Preset "faster" die Anzahl der Referenzen auf 2 beschränken, aber das würde auch die Qualität pro Bitrate einschränken. Selur hat mal ein Tool programmiert, mit dem man aus den "Kodierungseinstellungen" zurückrechnen kann, welches Preset die ähnlichste Ausgangsvorlage wäre.


    Gibt es für dich offensichtliche Gründe, dass du die Parameter exakt so wählen musst? Einige davon sehen mir eher aus wie "lieber schnell als gut".

  • LAV Filters – DirectShow-Source/Splitter+Decoder, Alternative zu ffdshow

    Wieder etwas spät... 8|


    19.3.2019: VP9-Fix


    16.3.2019:


    11.10.2018:


    5.10.2018: AV1 support

  • Media Player Classic - aktuelle Version

    Changelog 1.8.4 to 1.8.5:


    * Updated LAV Filters to v0.74 — und für einen VP9-Bugfix kann man auch gleich noch Version 0.74.1 hineinkopieren...


    + Option to specify command line parameters to use when downloading with youtube-dl (File > Save a Copy). Does not apply to streaming.

    + CoverArt improvements. Prefer image with same filename. Reduced chance of false positive matches.

    + Increased max Pan&Scan zoom factor to 5x.


    ! Fix: Crash in null renderer. Also support more mediatypes.

    ! Fix: Ellipsis character was trimmed off from beginning or end of subtitles.

    ! Fix: Ignore auto-zoom setting when remember window size is enabled.

    ! Fix: Remember correct playlist position on a non-primary screen from extended Desktop.

    ! Fix: Don't use YDL when an URL points to a file.