====== x264 ====== was ist das: * [[https://de.wikipedia.org/wiki/X264]] > ffmpeg -i Quelle.avi -c:v libx264 -crf 25 -b:v 0 -c:a aac -y Ziel.mp4 > ffmpeg -i Quelle.avi -c:v libx264 -crf 25 -b:v 0 -preset slower -tune film -g 300 -map 0:a:0 -c:a:0 libfdk_aac -afterburner 1 -movflags faststart -f mp4 -y Ziel.mp4 //Mit der Option ''-preset ultrafast'' werden sehr große Dateien bei hoher Transkodiergeschwindigkeit erzeugt und mit ''-preset placebo'' werden kleine Dateien bei sehr, sehr geringer Transkodiergeschwindigkeit erzeugt, Voreinstellung ist ''-preset medium''.// //Mit ''-tune psnr'' wird das verwischen des Bildes bei Bewegung verstärkt, um kleinere Dateien zu erzeugen und mit ''-tune ssim'' werden auch Bilder in der Bewegung scharf gezeichnet, das verbessert die Qualität von Standbildern.// Um Qualität zu erzielen möchte ich mindestens "%%--me umh%%" //(Suche nach Bewegungsvektor im Bild)// haben und das wird erst ab ''-preset slower'' aktiviert. ich konzentriere mich hauptsächlich auf diese beiden Presets: * ''-preset slower'' //für ausreichend kleine Dateien// * ''-preset veryfast'' //für ausreichend hohe Transkodiergeschwindigkeit// ===== Quellen ===== Home-Page: * **[[https://trac.ffmpeg.org/wiki/Encode/H.264|H.264]]** * [[http://www.videolan.org/x264.html|x264 - a free h264/avc encoder]] Ansehen kann man sich die Quellen online hier: * [[http://git.videolan.org/?p=x264.git;a=summary]] Saugen kann man sich die neuesten Quellen mit Hilfe von [[http://wiki.videolan.org/Git|Git]]: # git clone git://git.videolan.org/x264.git Oder man saugt sich einfach eine gepackte Version von hier: * [[ftp://ftp.videolan.org/pub/videolan/x264/snapshots/]] weitere Infos: * [[https://www.mplayerhq.hu/DOCS/HTML/de/menc-feat-x264.html]] * [[http://x264-video-codec.giga.de/]] * [[http://encodingwissen.de/x264/konfiguration]] * [[http://www.heise.de/newsticker/meldung/Kommerzielle-Lizenzen-fuer-H-264-Encoder-x264-1037582.html]] * [[http://www.hifi-forum.de/viewthread-312-17-8.html]] ===== Einstellungen ===== * [[http://mewiki.project357.com/wiki/X264_Settings]] Wichtig ist auch die Reihenfolge, in der die Optionen angegeben werden! laut Doku soll es so sein: x264 [CRF] [Preset] [tune] [Restliche Optionen] -o [Zielvideo] [Quellvideo] [Auflösung] das //x264//-Team verwendet aber diese Reihenfolge: x264 [CRF] [Preset] [tune] [Restliche Optionen] [Quellvideo] -o [Zielvideo] [Auflösung] bei mir gab es auf 64Bit-Systemen mit der oben genannten Reihenfolge Probleme: raw [error]: raw input requires a resolution. x264 [error]: could not open input file `-' Hierbei hatte ich die Daten im //RAW-YUV//-Format per PIPE an //x264// übergeben und dem zufolge als //[Quellvideo]// ein "**-**" eingesetzt. seitdem verwende ich diese Reihenfolge der Optionen: x264 [Quellvideo] --input-res [Auflösung] [CRF] [Preset] [tune] [Restliche Optionen] -o [Zielvideo] * [[http://encodingwissen.de/x264/referenz.html]] ==== rate-control mode ==== ''bitrate'', ''qp'' und ''crf'' schließen sich gegenseitig aus! - **bitrate** - [Multi-Pass-fähig] orientiert sich an die Bandbreite des Video-Datenstomes - **qp** - [Blu-Ray-kompatibel] orientiert sich an die Qualität - **crf** - [Blu-Ray-kompatibel] eine Kombination aus den obigen beiden, es erreicht die Qualität von ''qp'', bei kleinerer Dateigröße in dem es die Datenmenge für Bewegungen im Bild verringert, da der Mensch diese ohnehin nicht erkennen kann. Die eingesparte Bandbreite kann zur Verbesserung der gut zu erkennenden Bilder bzw. Bildteile verwendet werden, um wieder auf die gleiche Dateigröße zu kommen. ==== --preset ==== ultrafast superfast veryfast faster fast medium (default) slow slower veryslow placebo ==== --tune ==== film (psy tuning) grain (psy tuning) stillimage (psy tuning) psnr (psy tuning) ssim (psy tuning) fastdecode zerolatency Es können mehrere "Tuning's" Kommagetrennt angegeben werden, allerdings darf nur ein einziges Tuning mit "psy" dabei sein! ==== --no-fast-pskip ==== "no-fast-pskip" bringt einen sehr kleinen Qualitätsgewinn, auf Kosten eines dramatischen Rechenzeitanstieges. ==== --no-dct-decimate ==== "dct-decimate" verwirft Blöcke, die für unnötig gehalten werden. Das beschleunigt den Encoder, kann aber unter Umständen zu einem geringen Qualitätsverlust führen. ==== --nr ==== Mit dieser Option kann man das Bildrauschen unterdrücken. Mit **0** ist sie deaktiviert und zwischen **0-600** sollte der Wert für gängiges Filmmaterial sein. x264 empfiehlt Werte zwischen **100-1000** um verrauschtes Bildmaterial aufzuwerten. ===== x264 Blu-Ray-konform ===== * {{x264_demo_blu-ray.torrent|Torrent-Datei: x264 Demo Blu-ray}} * [[http://en.wikipedia.org/wiki/BD-ROM#Technical_specifications|BD-ROM: Technical_specifications]] High-definition video may be stored on Blu-ray ROM discs with up to 1920×1080 pixel resolution at up to 59.94 fields per second, corresponding to 29.97 frames per second interlaced or 24 frames per second progressive. Alternatively, progressive scan at 1280x720 pixel resolution can go up to 59.94 frames per second. * [[http://www.pro-linux.de/news/1/15597/x264-unterstuetzt-blu-ray.html|seit 2010-04-25 kann die freie x264-Bibliothek Blu-Ray-konforme Videos erzeugen]] Die neueste Version der Bibliothek x264 kann Blu-Ray-konforme Videos erzeugen. Einem Mastering von Blu-Ray-Disks ausschließlich mit freien Programmen steht damit nichts mehr im Wege. Von Hans-Joachim Baader x264 ist eine freie, unter der GPL veröffentlichte Bibliothek zum Kodieren von H.264/AVC-Videos. Das bei VideoLan angesiedelte Projekt stellt keine offiziellen Versionen, aber tägliche Schnappschüsse der Bibliothek bereit. Wie Jason Garrett-Glaser, einer der Entwickler von x264, jetzt mitteilte, kann die neueste Version von x264 Videoströme erzeugen, die zur Blu-Ray-Spezifikation konform sind. Damit können nun Blu-Ray-Disks vollständig mit freien Werkzeugen erstellt werden, so wie es mit DVDs schon seit Jahren möglich ist. Es ist nicht mehr nötig, für die Produktion kommerzielle Produkte einzusetzen, die teils über 100.000 US-Dollar kosten. Blu-Ray-konformes Audio wurde schon zuvor unterstützt, dabei wird AC3 eingesetzt. Der Blu-Ray-Master kann, wenn stark genug komprimiert wird, laut dem Entwickler auch auf DVDs oder Dual-Layer-DVDs gebrannt werden, womit alle Blu-Ray-Abspieler klarkommen sollten. Eigentlich setzt Blu-Ray zwingend DRM voraus, das in den freien Tools aber nicht verwirklicht ist. Allerdings erzwingt kein auf dem Markt befindlicher Abspieler DRM. Zur Demonstration der Fähigkeiten haben die Entwickler eine Blu-Ray-Disk mit vollständig freien Inhalten zusammengestellt. Auf dieser sind die Filme Big Buck Bunny und Elephant's Dream des Open-Movie-Projektes und ein Sound-Beispiel enthalten. Microsoft hat sechs Minuten verlustfreies HD-Video und Audio bereitgestellt, die unter einer freien Lizenz stehen und ebenfalls auf dem Image enthalten sind. Das 2 GB große Image, das das Dateisystem UDF 2.5 verwendet, kann über BitTorrent heruntergeladen werden. Eventuelle Patentprobleme sieht das Projekt für die meisten europäischen Länder (noch) nicht. Software ist nach Ansicht der Entwickler im Artikel 52 der Europäischen Patentübereinkunft von der Patentierbarkeit ausgeschlossen. Hardwarehersteller, die VLC mit patentierten Codecs in ihre Geräte integrieren, könnten allerdings zu Lizenzzahlungen verpflichtet sein. * [[http://x264dev.multimedia.cx/?p=328|Announcing the first free software Blu-ray encoder]] * [[http://forum.doom9.org/showthread.php?t=143716|CURRENT VERSION 0.33.06 (April 24th, 2010)]] ---- [[http://x264dev.multimedia.cx/?p=328#more-328|Do keep in mind that you have to export to raw H.264 (not MKV or MP4) or else the buffering information will be slightly incorrect.]] ---- ==== Blu-ray support: NAL-HRD, VFR ratecontrol, filler, pulldown ==== * [[http://git.videolan.org/?p=x264.git;a=commit;h=c6de86497cdd7b7f3cce7d8a95d723c7d0c9f505|Blu-ray support: NAL-HRD, VFR ratecontrol, filler, pulldown]] **2010-03-27** x264 can now generate Blu-ray-compliant streams for authoring Blu-ray Discs! Compliance tested using Sony BD-ROM Verifier 1.21. # x264 --crf 16 --preset veryslow --tune film --weightp 0 --bframes 3 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --b-pyramid strict --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 -o This command is much more complicated than usual due to the very complicated restrictions the Blu-ray spec has. Most options after "tune" are required by the spec. //--weightp 0// is not, but there are known bugged Blu-ray player chipsets (Mediatek, notably) that will decode video with //--weightp 1// or //2// incorrectly. **Furthermore, note the Blu-ray spec has very strict limitations on allowed resolution/fps combinations. Examples include 1080p @ 24000/1001fps (NTSC FILM) and 720p @ 60000/1001fps.** Detailed features introduced in this patch: Full NAL-HRD compliance, with both VBR (no filler) and CBR (filler) modes. Can be enabled with --nal-hrd vbr/cbr. libx264 now returns HRD timing information to the caller in the form of an x264_hrd_t. x264cli doesn't currently use it, but this information is critical for compliant TS muxing. Full VFR ratecontrol support: VBV, 1-pass ABR, and 2-pass modes. This means that, even without knowing the average framerate, x264 can achieve a correct bitrate in target bitrate modes. Note that this changes the statsfile format; first pass encodes make before this patch will have to be re-run. Pulldown support: libx264 allows the calling application to specify a pulldown mode for each frame. This is similar to the way that RFFs (Repeat Field Flags) work in MPEG-2. Note that libx264 does not modify timestamps: it assumes the calling application has set timestamps correctly for pulldown! x264cli contains an example implementation of caller-side pulldown code. Pic_struct support: necessary for pulldown and allows interlaced signalling. Also signal TFF vs BFF with delta_poc_bottom: should significantly improve interlaced compression. --tff and --bff should be preferred to the old --interlaced in order to tell x264 what field order to use. Huge thanks to Alex Giladi and Lamont Alston for their work on code that eventually became part of this patch. ===== Beispiel ===== * [[http://encodingwissen.de/x264/konfig.html]] Das folgende Kommando ist ein Standard-Beispiel dafür, wie man mit //mencoder// Videodaten an eine Pipe übergeben kann. In diesem Beispiel hat der Film das Bildformat von 1920x1080, das muss //x264// separat mitgeteilt werden: # mencoder Originalfilm.flv -really-quiet -mc 0 -noskip -ovc raw -lavcopts threads=1 -lavdopts threads=1 -demuxer lavf -vf scale,format=i420 -nosound -of rawvideo -o - | x264 - --input-res 1920x1080 --crf 16 -b 3 --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --b-pyramid --aud --colorprim bt709 --transfer bt709 --colormatrix bt709 --sar 1:1 -o Film.mkv Der //mplayer// kann seine Video-Daten im Format //YUV4MPEG// ausgeben, der //mencoder// kann nur das Format //YUV//. Das //YUV//-Format kann das Bildformat bzw. die Auflösung nicht mitliefern, das muss dann dem //x264// noch zusätzlich mit gegeben werden und das muss natürlich vorher wieder erst ermittelt werden, das braucht man beim //YUV4MPEG//-Format nicht. Allerdings kann der MPlayer seine Video-Daten nicht an eine Pipe übergeben, hier muss man sich eines FIFO bedienen. Leider hat sich das verwenden von FIFO aber als problematisch herausgestellt, da der //MPlayer//, wenn er im Hintergrund in den FIFO schreiben soll, in den "STOP"-Status wechselt und der //x264//, der die Daten dann aus dem FIFO wieder auslesen möchte, bekommt nix... alles steht! In einem Forum habe ich gelesen, das //"nohup"// bei diesem Problem helfen soll, das habe ich aber nicht mehr so ausführlich getestet. Hier das FIFO-Beispiel: # mkfifo fifo.y4m # nohup mplayer Film.mpg -really-quiet -benchmark -vo yuv4mpeg:file=fifo.y4m -ao null & # x264 --crf 23 --threads 1 --b-adapt 2 --direct auto --slow-firstpass --no-fast-pskip --me tesa --merange 24 --partitions all --rc-lookahead 60 --ref 5 --subme 10 --trellis 2 --nr 0 --weightp 0 --bframes 3 --nal-hrd vbr --vbv-maxrate 12000 --vbv-bufsize 12000 --level 3.0 --keyint 24 --b-pyramid strict --slices 1 --aud --colorprim bt709 --transfer bt709 --colormatrix bt709 --sar 1:1 -o Film_stumm.mkv fifo.y4m # mplayer Film.mpg -aid 128 -vo null -dumpaudio -dumpfile Film_audiospur # mkvmerge --default-language ger --aspect-ratio 1:4/3 -o NEUERFILM.mkv Film_stumm.mkv Film_audiospur # rm fifo.y4m Film_stumm.mkv Film_audiospur Da der MPlayer nur das Originalbild (unmanipuliert) ausgeben kann, verwende ich lieber MEncoder. Mit ihm ist es möglich, das Bild zu scalieren (vergrößern/verkleinern) oder zu crop-en (schwarzen Rand abschneiden), besonders das crop-en ist für mich interessant. Deshalb habe ich die auf den ersten Blick etwas aufwändigere Variante mit dem //YUV//-Format gewählt, denn die funktioniert wenigstens zuverlässig. //Hier ein entsprechendes Script, bei dem eine Tonspur unverändert übernommen wird und die Videodaten in den "x264"-Codec umgerechnet werden, ohne das Bildformat und die Auflösung zu verändern:// ''threads'' setze ich hier auf 1, da es hier nicht um Zeit sondern um Qualität geht und im Multi-Tread-Mode erreicht der //x264// leider noch nicht die volle Qualität. Hier ein Script von mir, das zwar noch nicht fertig ist aber sonst schon alles richtig macht: [[filme_transkodieren#mpeg4-beispiel_-_allgemein|film_transcodieren_in_MPEG4]] Aufgerufen wird es zum Beispiel so... Aufruf der Hilfe: # /home/bin/film_transcodieren_in_MPEG4.sh ins MPEG4-Format transcodieren: # /home/bin/film_transcodieren_in_MPEG4.sh Film.mpg ins AVC-Format transcodieren und das Bildformat unverändert lassen: # /home/bin/film_transcodieren_in_MPEG4.sh Film.mpg 0 0 0 0 0 0 AVC die schwarzen Balken rundherum abtrennen (das reale Bild hat nur das Format von 704x432): # /home/bin/film_transcodieren_in_MPEG4.sh Film.mpg 0 0 0 704:432:08:72 0 0 AVC die schwarzen Balken rundherum abtrennen und zusätzlich noch verkleinern (das reale Bild wird auf das Format von 540x324 verkleinert): # /home/bin/film_transcodieren_in_MPEG4.sh Film.mpg 0 0 540x324 704:432:08:72 0 0 AVC Das DVB-Format 720x576 in 16/9 wird hier unverändert übernommen, da 720x576 aber automatisch als 4/3 erkannt wird, geben wir 16/9 extra an: # /home/bin/film_transcodieren_in_MPEG4.sh Film.mpg 0 0 0 0 16/9 0 AVC