Beiträge von monarc99

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

    Wie sieht es aus, wenn ihr alles mit gcc 4.9 kompiliert?
    Die Pakete dürften mehr gegen gcc als clang getestet sein.

    Ohne jetzt die Fehlermeldungen zu sehen, hat ihr im Grunde das Problem, dass ihr eine halbe (übertrieben) Linux Distribution auf einem fremden System nach compiliert, ohne dass ihr eine Distribution habt.
    Und die meiste Arbeit einer Distribution ist dafür zu sorgen, dass alle Pakete zusammenpassen und gepatcht werden, damit alles compiliert. Und weil das sehr viel manuelle Handarbeit ist, teilt man sich diese normalerweise innerhalb einer Distri.

  • x265 unter MacOS X compilieren

    Zitat von Massaguana


    Nur wie muss ich die hq Zeile schreiben wenn ich eine andere Version haben will? Da ich dies nicht rausbekommen konnte habe ich mir die älteren Versionen selbst heruntergeladen und damit hq umgangen...

    Ich würde zu einem Tag springen. z.B.

    Code
    cd ${CMPL} hg clone https://bitbucket.org/multicoreware/x265[COLOR='#FF0000']cd x265hg update 1.4cd source[/COLOR]cmake -DCMAKE_INSTALL_PREFIX:PATH=${TARGET} -DENABLE_SHARED=NO .make -j 4 && make install

    die möglichen Tags siehst du, wenn du im x265 Hauptverzeichnis "hg tags" eingibst.

    z.B bei mir

  • x265 auf debian für Windows bauen

    Zitat von LigH

    Kann man solche Flags nicht mit ccmake bzw. cmake-gui (je nach Plattform) ändern? Dafür wurde doch das Shellskript zum Generieren des Projektes beigelegt.

    Einfach beim cmake Aufruf mit Parameter -D setzen.

    z.B.
    cmake -G "Unix Makefiles" -D HIGH_BIT_DEPTH:BOOL=ON ../../source


    may24 Aufruf würde dann z.B. so aussehen:

    Zitat


    cmake -DCMAKE_TOOLCHAIN_FILE=toolchain-x86_64-w64-mingw32.cmake -D ENABLE_SHARED:BOOL=OFF -D HIGH_BIT_DEPTH:BOOL=ON ../../source

  • x265 unter MacOS X compilieren

    Zitat von Massaguana

    Dann noch mal Zusammengefasst...

    Die erste Zeile code liefert:

    Code
    Last login: Thu Mar  5 13:57:49 on ttys002AKFs-MacPro:~ Massaguana$ /Applications/CMake.app/Contents/bin/cmake -G "Unix Makefiles" /Users/Massaguana/Downloads/multicoreware-x265-5e604833c5aa/source-- cmake version 3.2.0-rc2-- The C compiler identification is AppleClang 6.0.0.6000056-- The CXX compiler identification is AppleClang 6.0.0.6000056-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- works-- Detecting C compiler ABI info-- Detecting C compiler ABI info - done-- Detecting C compile features-- Detecting C compile features - done-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- works-- Detecting CXX compiler ABI info-- Detecting CXX compiler ABI info - done-- Detecting CXX compile features-- Detecting CXX compile features - done-- Detected x86 target processor-- Looking for include file inttypes.h-- Looking for include file inttypes.h - found-- Performing Test CC_HAS_NO_NARROWING-- Performing Test CC_HAS_NO_NARROWING - Success-- Performing Test CC_HAS_NO_ARRAY_BOUNDS-- Performing Test CC_HAS_NO_ARRAY_BOUNDS - Success-- Performing Test CC_HAS_FAST_MATH-- Performing Test CC_HAS_FAST_MATH - Success-- Performing Test CC_HAS_STACK_REALIGN-- Performing Test CC_HAS_STACK_REALIGN - Success-- Performing Test CC_HAS_FNO_EXCEPTIONS_FLAG-- Performing Test CC_HAS_FNO_EXCEPTIONS_FLAG - Success-- Found yasm: /Users/Massaguana/yasm (found version "1.3.0") -- Found Yasm 1.3.0 to build assembly primitives-- x265 version 1.4-- The ASM_YASM compiler identification is unknown-- Found assembler: /Users/Massaguana/yasm-- Looking for strtok_r-- Looking for strtok_r - found-- Looking for include file getopt.h-- Looking for include file getopt.h - found-- Configuring done-- Generating done-- Build files have been written to: /Users/MassaguanaAKFs-MacPro:~ Massaguana$

    Hier stimmt alles, x265 Version 1.4 z.B.

    Nicht ganz ... z.B. bei mir unter Linux findet er hg(Mercurial) im Pfad und kann die genau Version auslesen.

  • Leistungsstarker, aber preiswerter PC für Video und Spiele

    Die Intel Xeon sind bei Spielern beliebt, bieten relativ viel Leistung fürs Geld.
    Dafür verliert man sowas wie Intel Quick-Sync-Video, weil die keine interne GPU haben. Wer gerne mit sowas spielt, muss vorher schauen, was die jeweilige CPU alles so kann. (z.B. auch Hyperthreading)
    Gibt ja unzählige Varianten.

    Je billiger es sein soll, desto interessanter werden die AMD FX. Kommt halt sehr auf den Preis an, den man anpeilt.

    Wer gerne einen Rechner kauft und später zumindest versuchen möchte aufzurüsten, sollte Skylake im Auge behalten. Die neue Intel Generation ist für das 2te Halbjahr 2015 geplant und bringt wieder einen neuen Sockel mit sich. (also neues Motherboard und Co)
    Und vielleicht auch irgendwas an der H265 HW-Decoder Front, da bin ich aber jetzt nicht ganz informiert.

    An LigH Stelle würde ich genau aufschreiben, was mit dem PC genau geplant ist und dann geeignete Hardware in dem gewünschten Preissegment dafür suchen.

    Bestimmtes Spiel im Auge? -> Spielezeitschriften nach HW Anforderungen durchsuchen -> schon mal ein Hinweis, was die Hardware können muss.
    x265 Video Encoding -> ich vermute mal, soviel CPU Power wie möglich, also z.B. eine CPU ohne GPU, Preis nach oben unbegrenzt ^^
    mit QSV rumexperimentieren -> Intel CPU mit interner GPU

    usw...

  • Schlafzimmer-TV

    Man wird sehen, wie es kommt. Ich denke auch nicht, dass nur der Wechsel zwischen 32/64bit so ausschlagend ist.
    Ich betrachte es eher aus der praktischen Sichtweise, denn Handy Hardware wird noch schneller als PC Hardware ausgetauscht.

    Die AArch64 gibt es zwar noch nicht lange. Aber Apple verkauft im Grunde nur noch das (angeblich unerfolgreiche) IPhone5c als 32bit. Alle anderen Handys, die man bei ihnen kaufen kann, dürften 64-bit sein.
    Die 32bit ARM dürften bei Android Standard sein, weil erst Android 4.5 als 64-bit verfügbar sein wird. Wie schnell dann die Android Handys 64bit werden, wird sich zeigen. Da man bei Android auf den Preis achten muss, halten sich die 32bitter bei billigen Varianten vielleicht länger.

    Aus Sicht eines OpenSource Entwickler, der überlegt, ob er sich die jahrelange Mühe machen soll, einen komplexen Codec auf eine Architektur zu optimieren, stellt sich die Frage:
    Welche der ARM Prozessoren ist denn überhaupt schnell genug für hevc und gibt es diese Architektur noch lang genug, um den Arbeitsaufwand zu rechtfertigen. Bei den 32bit-x86 wurde die Frage wohl mit Nein beantwortet.

    Und für jemanden, der etwas für den Schlafzimmer-TV sucht, macht hevc vielleicht erst bei Auflösungen wie 720p/1080p Sinn. Also muss die Hardware schon etwas CPU Power bieten. Deshalb mein Hinweis, dass die 64bit-CPUs vielleicht geeignete Kandidaten wären.

  • x264 encoding mit Handbrake: CRF / Presets

    Zitat von fe_


    So komme ich zurecht, interessiert mich nur warum das zustande kommt.


    Da du etwas vom Bild wegschneidest (crop), skaliert jemand das Bild fürs Playback wieder auf 16/9 bzw. 4/3. Und dann ist es wohl verzerrt.

    Bei Openelec entweder XBMC oder der Fernseher. Bei meinem Fernseher muss ich einstellen, dass er das Bild vom HDMI Eingang unverändert anzeigt. Standardmäßig wird bei mir sonst alles auf 16/9 skaliert/verzerrt.
    Alternativ kann man auch versuchen, den Fernseher in XBMC zu kalibieren. Oder in den XBMC Einstellungen etwas zu finden.

    Die sicherste Methode ist nicht zu Croppen, wie es auch die Fernsehsender tun. Wenn die Datei auf einer Vielzahl an Geräten laufen soll, dann ist es sinnvoll die scharzen Balken einfach drin zu lassen.

  • x264 encoding mit Handbrake: CRF / Presets

    Zitat von fe_

    Der DN2820FYKH wuerde reichen und ist sehr guenstig. Hier finde ich aber nichts ob Ivy oder Sandy-Bridge.

    Basis ist Silvermont. Gehört zur Generation 7 (Ivy Bridge). Ob der den 24p Bug hat, kann ich leider nicht sagen.
    Tritt wohl nur auf, wenn der Fernseher auch mit 24p läuft - soweit ich das verstanden habe. Kann das also bei mir nicht testen.

    Aber wie ich mir schon gedacht habe, ist der NUC 2820 schon Geschichte. Ersetzen wird ihn wohl der 2830:
    http://www.computerbase.de/2014-04/intel-…830-quick-sync/

    Den es noch nicht zu kaufen gibt. Aber vielleicht lohnt es sich zu warten. Der kann Quick Sync also vielleicht ne bessere GPU?
    http://cpuboss.com/cpus/Intel-Cel…l-Celeron-N2820

  • x264 encoding mit Handbrake: CRF / Presets

    Raspberry Pi als Media Player würde ich auch nicht nehmen.

    Ich verwende momentan als Openelec Hardware einen Intel Nuc dn2820fykh.
    Für H.264 FullHD sollte der ausreichen. Zumindest spielt er bislang fast alles problemlos.

    100min / 35GB Bluray Stream ohne Probleme
    Nur bei einem crf 0 FullHD H.264 Stream kam er hin und wieder ins straucheln. Aber da habe ich eh nicht erwartet, dass er diese Datei packt.

    H.265 habe ich noch nicht getestet. Da müsste der Nuc dann per Software decodieren, da wirds eng werden. Sehe ich, wenn Openelec (stable) H.265 Support hat.
    Aber bei Raspberry Pi sehe ich bei H.265 schwarz.

    Immer ne gute Übersicht für Openelec Hardware: http://technikaffe.de/anleitung-23-d…ware_fuer_xbmc_

  • Ergebnisse mit x264 und CRF zu groß

    Zitat von Cubitus

    So langsam glaube ich, dass ich gefälschten CRF's aufsitze. Ich habe jetzt zwei identische Inhalte miteinander verglichen, die eine Folge von woanders mit 310MB, die andere per DVB-T mitgeschnitten.


    Vergleiche machen nur Sinn, wenn sie von der gleichen Quelle gemacht werden. Ist denn die 310MB Fassung auch vom gleichen DVB-T Mitschnitt?

    Wenn du z.B. ne Simpsons Folge einmal von DVD und einmal von einem TV Mitschnitt mit gleichen x264 Settings kodieren würdest, wäre die von der DVD optisch deutlich besser und vermutlich noch kleiner.
    Wie Ligh schon erklärt hat, muss man beim jedem Recodieren immer mehr Bitrate zugeben, um die Qualität des Film zu bewahren.

    TV-Mitschnitte sind meist schon ziemlich häufig recodiert worden und lassen sich nur sehr schwer nochmal komprimieren.

  • AMD vs. intel: Entweder Preis oder Leistung?

    Zitat von may24

    Wie schon gesagt, wenn erst mal 4k Material bearbeitet wird ...


    Ob dann ein Intel i7-4790 für x265 ausreicht, ist die andere Frage.

    Wie sieht es denn mit Hardware Support für HVEC aus (zumindest Decoder)? Vor Skylake (2015) wird sich da bei Intel wenig tun, zumal dann ja wieder ein neuer Sockel (1150) - also Motherboard+CPU+Speicher fällig wäre.

  • mencoder + FFV1

    Zitat von Selur


    Weiß jemand was genaueres? Ist das ein Bug oder mach ich was falsch beim Aufruf?

    Ne, nur das es bei mir auch nicht geht. Der Aufruf dürfte richtig sein.

    Zitat von Selur


    mit ffmpeg könnte man es auch machen:

    aber ich suche nicht ne Alternative, sondern einen Weg mencoder zu verwenden ;)

    ja, ffmpeg und mpv gehen bei mir. mencoder wird wohl nicht mehr so gut gewartet.

    Code
    ffmpeg -y -i ../Downloads/test.avi -an -sn -threads 4 -vsync 0 -r 25000/1000 -pix_fmt yuv420p -vcodec ffv1[B] -level 3 -slices 24 -slicecrc 1[/B] "ffv1Test.avi"
 mpv ~/Downloads/test.avi -o ffv1Test.avi -oautofps -ovc ffv1 -ovcopts threads=8,level=3,slices=24

    Schon das neuere ffv1.3 probiert? Aktiviert mal durch die level option. slices sollte man auch setzen.