Beiträge von monarc99

  • FFmpeg unter Mac OS X kompilieren,... ?

    Ist denn das svn noch aktuell?
    FFmpeg ist schon länger auf git umgestiegen. -> git clone git://http://source.ffmpeg.org/ffmpeg.git ffmpeg

    Dein Problem dürfte sein, dass die kompilierten libs nicht mehr im lib Verzeichnis sind, sondern für jede Library ein eigenes Unterverzeichnis existiert. Ein einfaches -L reicht da nicht mehr.

    Du willst praktisch ein statisches x264 kompilieren?

    Gibts denn unter MacOS pkg-config? Und kompiliert gcc oder clang?
    Du könntest z.B. ffmpeg zum Schein unter /Users/selur/Desktop/builds/root installieren:

    Beim ffmpeg configure Befehl folgendes zusätzlich setzen: --prefix=/Users/selur/Desktop/builds/root
    und dann: make install

    dann sollte er ffmpeg unter /Users/selur/Desktop/builds/root installieren. Zum gefahrlosen Testen kann man das Installieren mit
    make -n install
    testen.

    Und dann beim x264 configure den pkg-config umbiegen. z.B.

    PKG_CONFIG_PATH=/Users/selur/Desktop/builds/root/lib/pkgconfig LDFLAGS="-static -lz -lbz2" ./configure --bit-depth=8 --prefix=/Users/selur/Desktop/builds --enable-static

    unter dem pkgconfig Pfad sollten die *.pc Dateien liegen. Hier bei mir unter Linux muss ich auch die LDFLAGS setzen, die oben zu sehen sind.
    Dann solltest du ein statisches x264 haben. ffmpeg natürlich nicht, das ist dynamisch.

    mfg

  • Windows fährt runter wegen x265 ?

    Dann mit CoreTemp http://alcpu.com/CoreTemp/ ... zeigt einfach nur die Temperatur an. (ohne Grafik)
    Auch die max Temp, die deine CPU verträgt.

    Und du solltest keine weiteren Notabschaltungen provozieren (also lange unbeaufsichtigt laufen lassen). Das heißt nicht ohne Grund so, deine Hardware kann auch trotz Abschaltung Defekte davon tragen.
    Wenn Verdacht auf Hitzeprobleme, dann ist eine Reinigung des PC immer sinnvoll, bevor man weitere Tests macht.

    mfg,
    monarc

  • Windows fährt runter wegen x265 ?

    Dürfte schon die Notabschaltung der CPU sein. Ist zumindest das naheliegenste.

    Lass dir mal die Temps anzeigen, während x265 läuft. (z.B. mit http://www.hwinfo.com/ die Temps als Graph über Zeit anzeigen lassen)
    Und schau nach, bei welcher Temp deine CPU abschalten würde. Um zu sehen, wie nahe du dran bist.

    Wann zuletzt Lüfter gereinigt?
    Kann sich die Abwärme stauen? Einige bauen sich den PC irgendwo ein, was bei normalen Betrieb kein Problem ist.
    Läuft der PC aber über mehrere Tage heiss, wird soviel Wärme erzeugt, dass der PC seine eigene Wärme wieder einzieht.

    mfg

  • YouTube: 1080p nur für Flash, nicht für HTML5?

    Zitat von LigH


    Trauen die sich nicht, weil man dann merken würde, dass VP8 es einfach nicht schafft (falls H.264 nicht vom Browser unterstützt wird)?

    Youtube hat mit dem letzten Update bei den Auflösungen höher 720p auf DASH umgestellt.
    Man kann diese Streams nach wie vor runterladen, allerdings sind Audio und Videostream getrennt gespeichert. Also unter einem itag findet man einen reinen Videostream, unter einen anderen itag den Audiostream.
    Der Flash Player wird beim Abspielen diese vermutlich kombinieren.

    Der webm Player wird das noch(?) nicht können, vermute ich mal. Ich weiss nur, dass bei Chrome z.B. an DASH Support für webm streams gearbeitet wird.

  • Erläuterungen zur den x264 Patches?

    Zitat von Selur


    [code]
    0027-New-experimental-AQ-mode-modification-of-Auto-varian.diff


    Bei den vielen AQs-Experimenten im Laufe der Zeit schwer zu sagen, welcher gemeint ist.
    Ich würde bei obigen Patch dies hier vermuten:

    Zitat


    I also experience this while encoding using x264 rev1376 under MeGUI. I notice the darker scenes (e.g: an aerospace fly through night sky with some white cloud) is really blocky. Other than that, the encoding was very good in quality for the given bitrate.

    In this case the problem is probably --aq-mode 2 with using MBTree (it is known to have problems in fades and probably dark areas). And that is why I trying different other modes (AQ3 and now AQ4) to fix this by tuning them specially for use with MBTree.

    http://doom10.org/index.php?topic=136.msg982#msg982

  • x264 bester Videocodec?

    Zitat von Selur


    Davon ausgegangen, dass VP9 und HEVC vergleichbare Qualität liefern sollten, würde die Decodinggeschwindigkeit interessant werden.

    Mal ein wenig gespielt und mir eine 52 sek VP9/Opus MKV Datei erstellt (sintel Trailer). Spielt auch brav - nach einer kleinen Änderung- in mpv (mplayer-fork) ab.

    Bei dem Kurztest (jeweils 2Pass, Bitrate 1000, bei x264 Preset Placebo) gefällt mir die VP9 Quali ganz gut, auch wenn man da noch wenig vergleichen kann.
    -> X264 Preset Placebo gegen zufällig in einem Mailinglisten Thread gefundene Einstellungen für VP9.

    Der Encoder ist sehr langsam. Hoffentlich noch nicht optimiert und single threaded.
    Auch kurz mit mpv die Decoder grob verglichen.

    Durch den 52sek-Videostream decodiert er sich auf meinem 4Kern-i5 bei:

    H264 in ca. 2.027s (ffmpeg Decoder, hoch optimiert und multi threaded)
    VP9 in ca. 12.605s (libvpx Decoder, vermutlich wenig optimiert und single threaded)

    wenn ich auch den H264 Decoder auf single threaded runterschalte, erhalte ich:

    H264 in ca. 9.302s (ffmpeg Decoder, single threaded)
    VP9 in ca. 12.458s (libvpx Decoder, vermutlich single threaded)

    Beide Streams bringen meinem i5 in keinster Weise ins Schwitzen beim Decodieren.

    mfg,
    monarc

  • Opus – flexibler Audio-Codec fürs Internet

    Ich war nur irritiert, weil die Optionen sich von opusenc nicht geändert haben.

    Code
    --vbr              Use variable bitrate encoding (default) --cvbr             Use constrained variable bitrate encoding --hard-cbr         Use hard constant bitrate encoding

    während bei opus_demo der neue unconstrained Modus in den Optionen erwähnt wird.

    Code
    -cbr                 : enable constant bitrate; default: variable bitrate
-cvbr                : enable constrained variable bitrate; default: unconstrained

    Scheinbar ist aber der alte ABR Modus (bisheriger Default-Modus) entfernt worden und der unconstrained Modus einfach Standard jetzt. (?)
    Und wird deswegen gar nicht erwähnt.

    mfg,
    monarc

  • Staxrip Template - immer wieder andere Bitrate nach Laden von Datei Quelle

    Sinnvolle Werte liegen so um 16-25 ... wobei die Mitte ein guter Startpunkt ist. Je kleiner der Wert, desto größer die Datei / umso höher die Qualität.

    Welcher Wert für dich geeignet ist, musst du selbst rausfinden. Da entscheidet der Geschmack ... der eine findet, ein CRF Wert von 16 ist gerade noch gut genug, anderen reicht ein Wert von 25 und freuen sich über die relativ kleinen Dateien.
    Am besten kodiert man einmal einen Testclip mit verschiedenen CRF Werten. Wenn du einmal deinen "persönlichen" CRF Wert gefunden hast, kannst du in der Regel diesen für alle weiteren Kodierungen nutzen.

    mfg,
    monarc

  • x264 bester Videocodec?

    Zitat von Selur

    Anfangs vermutlich HEVC, weil da mehr Leute dran arbeiten und unterschiedliche Firmen eigene En- und Decoder herausbringen werden, so dass zu hoffen ist, da man da bald einen von der Geschwindigkeit brauchbaren Encoder hat.


    Für welchen Verwendungszweck haben sie HEVC denn vorgesehen?

    TV Streams / Bluray (auch wohl 4k) werden - ähnlich wie damals beim Übergang MPEG2 -> MPEG4-ASP - vielleicht einen Codec überspringen und bei H.264 bleiben. Einige Ami Sender kodieren ja sogar HD Streams noch mit MPEG2.
    Große Video-on-Demand-Streamer (ala Netflix) kenne ich eher aus den USA, also nur dort von Bedeutung. Bei uns ist das ja eher klein.
    Youtube ist VP9-Welt ... wenn Google schon einen eigenen Codec macht, werden sie ihn auch irgendwann einsetzen und nicht unbedingt HEVC verwenden.


    Zitat von Selur


    Wenn dann VP9 optimiert genug ist, dass es von der Geschwindigkeit mit dem dann aktuellen Encodern einigermaßen mithalten kann (es eine offizielle mkvtoolnix Version gibt die VP9 unterstützt) werden sich wohl auch einige Leute mehr mit VP9 beschäftigen.
    -> momentan ist das noch alles sehr uninteressant für fast alle Anwender.


    Ob VP9 der große Wurf wird, hab ich so meine Zweifel. Aber man wird sehen.

    Mir gefällt aber, dass der Sourcecode verfügbar ist und so auf jeden System nutzbar ist.
    Auch ist Google flexibler. H.264 ist jetzt 10 Jahre alt und sollte der Nachfolger von HEVC wieder 10 Jahre brauchen, hat Google sehr viel Zeit.
    Optimierungen dauern lange, aber irgendwann holt man halt nur noch wenig raus. Google wird sicher nicht 10 Jahre VP9 optimieren, wenn man mit einem VP10/11/12 großere Fortschritte machen kann.
    Und bei HVEC vs. VP10 ... wer weiß, wie es dann aussehen wird.

    mfg
    monarc

  • x264 bester Videocodec?

    Zitat von Selur

    zu schweinsz: Wenn er da wie bei seinem H.264 Decoder, ohne Versionsverwaltung und im gewohntem Spaghetti-Code alleine an dem Teil schreibt, wäre es schon fast ärgerlich, wenn er mit vp9&co konkurrieren könnte. (da Updates, Fixes, Erweiterungen wohl, wie bei ihm gewohnt, auch bei kleinen Sachen sehr lange dauern würden)

    Lass ihn machen ... man wird sehen, was rauskommt.

    Wird interessant werden, welcher Codec/Codecfamilie das Rennen machen wird.

    mfg
    monarc

  • Je höher die Bitrate, umso langsamer das Abspielen?

    Zitat von HelmutS

    @ Selur
    50MBitReencode_fastdecode_nobframes_ref1.mp4 = VOLLTREFFER

    Super, freue mich. Jetzt wäre es lieb, wenn Du mir erklären könntest, wie ich das hier bei mir hinkriege unter Bezug auf gute Qualität bei einer Bitrate von etwa 22.000.


    Selur hat an den x264 Settings umgestellt, um deine CPU beim Dekodieren zu entlasten. Ne Auslastung von 52% deutet daraufhin, dass du z.B. eine CPU mit 2 Kernen hast, beim Abspielen aber nur 1 Kern Verwendung findet, also nur die halbe Kraft der CPU verwendet wird. Deshalb auch die Frage nach deiner Hardware.

    Probier mal einen anderen Player, wie der sich schlägt. -> http://mplayer2.srsfckn.biz/ (erste News ist ein Installer)


    Zitat von Selur

    Start->Ausführen->dxdiag
    da dann "Save All Infromation" (vermutlich 'Alle Daten speichern' oder so in nem deutschen Windows)
    und aus der Datei ist sind vermutlich nur interessant:


    Du kannst auch http://www.hwinfo.com/ verwenden. Damit kannst du dir auch die Auslastung der einzelnen Cores in einen Graphen anzeigen lassen. Dann siehst du, wie die Hardware beim Abspielen belastet wurde.

  • Spulen in mkv files,...

    Hm, ich hab mal den H264 Stream aus dem Original mittels ffmpeg geholt.

    Neu kodiert (deine Zeile oben verwendet, ohne avs demuxer, andere x264 Version (x264 core:125 r2200M 999b753 / Linux))
    und einfach beide H264 Streams - original und reencoded - mit mkvmerge aneinander gefügt.

    Spielt ohne Probleme und keine Probleme beim Spulen.

  • Spulen in mkv files,...

    Zitat von Selur


    Da sich daran nichts ändert, wenn ich den Video stream nach mp4 remuxe, liegt das Problem wohl nicht am Container, sondern an meinen x264 settings. :(

    Ich denke, ohne Ausprobieren wird das schwer. Wenn es überhaupt klappt, der original Stream wurde ja vermutlich mit einen anderen H264 Encoder erzeugt.

    Die Profile durchprobieren, von CRF auf CQ Modus wechseln. --force-cfr testen ... mehr fällt mir auf Anhieb nicht ein.

    mfg