Encoding-Talk

Zitat von De-M-oN

Bislang ging nie mehr als 4:2:0 auch bei [lexicon]webp[/lexicon] nicht, was insbesondere bei [lexicon]webp[/lexicon] enorm schade ist
Wenn bei [lexicon]VP9[/lexicon] nun wirklich mehr gehen sollte, wäre das eine überraschende Neuerung

Wurde aber auch erst in den letzten FFmpeg Updates geändert bzw. ergänzt das [lexicon]VP9[/lexicon] zwecks Farbraum mehr unterstützt.

[lexicon]VP9[/lexicon] ist relativ schon fast identisch wie [lexicon]x264[/lexicon]. [lexicon]CRF[/lexicon] Encoding ist bei beiden möglich.

Aber halt nur fast. Es gibt schon Unterschiede, aber an sich würde nix dagegensprechen auch [lexicon]VP9[/lexicon] als [lexicon]Encoder[/lexicon] für YT zu nutzen. Das einzige was mir spontan erst mal einfallen würde ist das [lexicon]VP9[/lexicon] kein 10Bit Support und kein [lexicon]Lossless[/lexicon] Support besitzt. Obwohl ja der [lexicon]Container[/lexicon] [lexicon]webm[/lexicon] mit dem [lexicon]Codec[/lexicon] [lexicon]webp[/lexicon] [lexicon]Lossless[/lexicon] können würde. Nur [lexicon]VP9[/lexicon] unterstützt das nicht. Und [lexicon]VP9[/lexicon] kommt ausschließlich in [lexicon]webm[/lexicon] Containern. Das heißt das einige NLEs da wieder nix können, da sie das Format gar nicht decodieren können.

Und was noch gegen [lexicon]VP9[/lexicon] derzeit noch spricht ist das es zur Zeit ledeglich nur in bestimmten Anwendungen als [lexicon]Encoder[/lexicon] genutzt werden kann. Halt wie hier mit FFmpeg.

Eine VfW Variante von [lexicon]VP9[/lexicon] gibt es nämlich nicht. Also für die Masse an Usern die eh Schnittsoftware wie Vegas, Premiere und Co. verwenden, müssten dann alle einen [lexicon]Frameserver[/lexicon] nutzen, um ihre Videos mittels externen [lexicon]Encoder[/lexicon] wie über FFmpeg mit [lexicon]VP9[/lexicon] [lexicon]encodieren[/lexicon] zu können.

Daher ist [lexicon]x264[/lexicon] immer noch die mitunter beste Möglichkeit mehr mit seinen Videos zu machen. Vor allem da der Support für diesen [lexicon]Codec[/lexicon] recht verbreitet auch ist. Wird ja auch für BluRays eingesetzt. Also von daher, schon relevanter

[lexicon]VP9[/lexicon] ist zwars auch interessant, aber halt für den benutzerfreundlichen Gebrauch noch nicht so weit verbreitet.

Zitat von Sagaras

Wurde aber auch erst in den letzten FFmpeg Updates geändert bzw. ergänzt das [lexicon]VP9[/lexicon] zwecks Farbraum mehr unterstützt.

Ah also tatsächlich neu. Danke Google

Jetzt nur noch für [lexicon]webp[/lexicon] ergänzen und wir haben die JPG Ablöse schlechthin

Kein Thumbnail würde mehr die 2MB Grenze sprengen

zählt audiobearbeitung auch hier dazu? wenn ja, dann:

Zitat von TimBourbon

also ich hab das gefühl, der [lexicon]afterburner[/lexicon] hat die linke spur dezent....vermasselt...

[IMG: http://puu.sh/mXaGE/fc8f3330d8.png]

edit: wie könnte ich das reparieren?

Zitat von TimBourbon

zählt audiobearbeitung auch hier dazu? wenn ja, dann:

Die Seite ist verloren. Trenn die beiden Kanäle, lösch die linke Seite raus und ersetze sie durch die rechte Seite.

das hab ich mir schon gedacht - wie kann ich die trennen? hab da nix gefunden

edit: sprachs und findet es...

Zitat von GrandFiredust

Hm... ich dachte immer das [lexicon]VP9[/lexicon] eher der Gegenspieler zu [lexicon]H.265[/lexicon] ist

Naja, auch. Ist relativ langsam beim Encoding. Qualitativ ist es mit H265 ebenbürtig. [lexicon]VP9[/lexicon] nutzt ledeglich mehr [lexicon]Bitrate[/lexicon] gegenüber H265.

Problem ist und bleibt aber der Nutzungsfaktor der Codecs. H265 unterstützt YT nicht und Schnittprogramme erst recht nicht.
[lexicon]VP9[/lexicon] unterstützten Schnittprogramme so gut wie gar nicht.

Für H265 werden den meisten der [lexicon]Decoder[/lexicon] auf ihrem Rechner fehlen und bei [lexicon]VP9[/lexicon] wird oftmals Libav verwendet, bzw. von Google selbst der [lexicon]Decoder[/lexicon] bereitgestellt und in [lexicon]VLC[/lexicon] verfügbar sein. Es gibt für beide keine VfW [lexicon]Encoder[/lexicon] und auch sonst ist es sehr spärlich mit den Codecs effektiv zu arbeiten.

Dagegen ist für h264 der [lexicon]x264[/lexicon] [lexicon]Encoder[/lexicon] weiter verbreitet und auch Massentauglicher.

[lexicon]VP9[/lexicon] ist gegenüber H265 auch schon etwas weiter verbreitet.

So kann man z.B. bei [lexicon]xMediaRecode[/lexicon] [lexicon]VP9[/lexicon] als auch [lexicon]x264[/lexicon] voll Funktionsfähig nutzen.
[lexicon]VP9[/lexicon] kann ja z.B. auch [lexicon]Lossless[/lexicon] [lexicon]encodieren[/lexicon]. Nur ist der Support bei vielen [lexicon]VP9[/lexicon] Encodern die es derzeit gibt auch nicht grad vorhanden.

Also für Aufnahmen ist [lexicon]VP9[/lexicon] und H265 nicht zu verwenden, weil es einfach keine VfW Unterstützung gibt. Als [lexicon]Encoder[/lexicon] sind sie Spärlich zu erreichen, da die Schnittsoftware einen [lexicon]Frameserver[/lexicon] benötigt um einen externen [lexicon]Encoder[/lexicon] zu erreichen. Die [lexicon]Frameserver[/lexicon] Datein müssen dann via [lexicon]AVISynth[/lexicon] decodiert und als RAW Material an den [lexicon]Encoder[/lexicon] weitergeleitet werden. Der [lexicon]Encoder[/lexicon] ist dann meist auf CMD Basis oder kann halt von einigen Speziellen Programmen wie [lexicon]xMediaRecode[/lexicon] erreicht werden.

Die Effektivität anhand von Speed und Nutzen dadurch ist einfach noch zu untragbar um einen relativen guten Nutzen daraus zu ziehen. Zudem hat [lexicon]VP9[/lexicon] keinen 10Bit [lexicon]Encoder[/lexicon] und so kann das [lexicon]Banding[/lexicon] verstärkt auf YT wieder auftreten.

@Sagaras
Auch [lexicon]VP9[/lexicon] beherrscht 10Bit Kodierung. Seit wann genau weiß ich allerdings nicht.

Hier zwei zwei [lexicon]MediaInfo[/lexicon] von unabhängig voneinander kodierte Videos ([lexicon]Lossless[/lexicon], 10bit, YUV444) mit dem selben Quellmaterial.
Video 1:

General
Complete name                  : F:\Let's Play\Encode\TBoIA-Test-10bit.mkv
Format                         : Matroska
Format version                 : Version 2
File size                      : 38.1 MiB
Duration                       : 2s 0ms
Overall bit rate               : 160 Mbps
Writing application            : x264 r2638 7599210
Writing library                : Haali Matroska Writer b0


Video
ID                             : 1
Format                         : AVC
Format/Info                    : Advanced Video Codec
Format profile                 : High 4:4:4 Predictive@L5
Format settings, CABAC         : Yes
Format settings, ReFrames      : 5 frames
Codec ID                       : V_MPEG4/ISO/AVC
Duration                       : 2s 0ms
Bit rate                       : 156 Mbps
Width                          : 2 048 pixels
Height                         : 1 152 pixels
Display aspect ratio           : 16:9
Frame rate mode                : Constant
Frame rate                     : 60.000 fps
Color space                    : YUV
Chroma subsampling             : 4:4:4
Bit depth                      : 10 bits
Scan type                      : Progressive
Bits/(Pixel*Frame)             : 1.105
Stream size                    : 37.3 MiB (98%)
Writing library                : x264 core 148 r2638 7599210
Encoding settings              : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x1:0x111 / me=umh / subme=8 / psy=0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=18 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=0
Language                       : English
Default                        : Yes
Forced                         : No
Color range                    : Limited
Color primaries                : BT.709
Transfer characteristics       : BT.709
Matrix coefficients            : BT.709

Video 2 ([lexicon]VP9[/lexicon]):

General
Complete name                  : F:\Let's Play\Encode\TBoIA-Test-10bit.webm
Format                         : WebM
Format version                 : Version 4 / Version 2
File size                      : 65.6 MiB
Duration                       : 2s 0ms
Overall bit rate               : 275 Mbps
Encoded date                   : UTC 2016-02-06 06:49:17
Writing application            : mkvmerge v8.8.0 ('Wind at my back') 64bit
Writing library                : libebml v1.3.3 + libmatroska v1.4.4


Video
ID                             : 1
Format                         : VP9
Codec ID                       : V_VP9
Duration                       : 2s 0ms
Bit rate                       : 264 Mbps
Width                          : 2 048 pixels
Height                         : 1 152 pixels
Display aspect ratio           : 16:9
Frame rate mode                : Constant
Frame rate                     : 60.000 fps
Bits/(Pixel*Frame)             : 1.867
Stream size                    : 63.0 MiB (96%)
Language                       : English
Default                        : Yes
Forced                         : No

Da die [lexicon]MediaInfo[/lexicon] des [lexicon]VP9[/lexicon] Encodes recht wenig aussagt, hier nochmal die Ausgabe von ffprobe:

Input #0, matroska,webm, from 'F:\Let's Play\Encode\TBoIA-Test-10bit.webm':
  Metadata:
    encoder         : libebml v1.3.3 + libmatroska v1.4.4
    creation_time   : 2016-02-06 06:49:17
  Duration: 00:00:02.00, start: 0.000000, bitrate: 275263 kb/s
    Stream #0:0(eng): Video: vp9 (Profile 3), yuv444p10le(tv), 2048x1152, lossless, SAR 1:1 DAR 16:9, 60 fps, 60 tbr, 1k tbn, 1k tbc (default)

Das [lexicon]VP9[/lexicon] Video musste nochmal neu gemuxt werden, da mir sonst immer nur ein 59,94FPS Video ausgegeben wurde, trotz 60FPS Angabe beim Encode.

Zum Schluss die Absicherung, dass das dekodierte Videomaterial identisch ist via ffmpeg -loglevel error -i "[input]" -map 0:v -f md5 -.

Ergebnis ist identisch, wenn ich also keinen Fehler gemacht habe, dürfte es sich hierbei um zwei vollkommen gleichwertige 10Bit Encodes handeln.
Nutzen würde ich [lexicon]VP9[/lexicon] trotzdem nicht, aus den von dir schon genannten Gründen.

ok... dann wird das über den Farbraum angegeben. Dann wäre FFmpeg bis jetzt der einzige der das kann.

Gegenfrage: Kann FFmpeg mit [lexicon]VP9[/lexicon] [lexicon]Lossless[/lexicon]? Weil bei [lexicon]xMediaRecode[/lexicon] und laut den Internetinfos sollte dies möglich sein.
Aber FFmpeg meint dazu folgendes:

Codecs:
 D..... = Decoding supported
 .E.... = Encoding supported
 ..V... = Video codec
 ..A... = Audio codec
 ..S... = Subtitle codec
 ...I.. = Intra frame-only codec
 ....L. = Lossy compression
 .....S = Lossless compression
 -------
DEV.L. vp9                  Google VP9 (decoders: vp9 libvpx-vp9 ) (encoders: libvpx-vp9 )

Und [lexicon]xMediaRecode[/lexicon] hat halt folgendes: Bild

Auch FFmpeg kann [lexicon]Lossless[/lexicon] [lexicon]VP9[/lexicon] kodieren, man füge dafür zu libvpx-[lexicon]vp9[/lexicon] den -lossless 1 Parameter hinzu, die Angabe in der Übersicht dazu ist daher wohl falsch. Die 8Bit [lexicon]Lossless[/lexicon] Encodes auf der vorherigen Seite kamen auch von FFmpeg.
Für mehr als 8Bit ist aktuell vpxenc vonnöten, ist über FFmpeg bisher nicht möglich.

Nagut.
Trotzdem bleibt [lexicon]VP9[/lexicon] für die meisten recht unzugänglicher als [lexicon]x264[/lexicon], da es derzeit keine VfW Version davon gibt und es somit schon mal für die meisten Schnittprogramme unzugänglich bleibt. Und wenn man es als [lexicon]Codec[/lexicon] nutzen möchte bleibt einen ja quasi kaum was anderes möglich als halt FFmpeg oder [lexicon]xMediaRecode[/lexicon] bzw. andere Freeware Programme, die eventuell nicht so richtig arbeiten im Zusammenhang mit [lexicon]AVISynth[/lexicon].
z.B. ist [lexicon]xMediaRecode[/lexicon] mit einem [lexicon]AVISynth[/lexicon] Skript abgestürzt, wärend FFmpeg das gleiche Skript hervorragend verarbeiten konnte in [lexicon]VP9[/lexicon].

Also wie gesagt ist das sehr spärlicher als [lexicon]x264[/lexicon] zu nutzen.

Muss aber jeder für sich halt wissen. Es ist halt ne Option die ja da ist.

Ein [lexicon]CLI[/lexicon] [lexicon]Encoder[/lexicon] wäre halt schön, dann könnte es in [lexicon]MeGUI[/lexicon] integriert werden

edit: Oh und das es dazu kein VfW gibt ist nachvollziehbar, irgendwann sind auch mal die Grenzen von VfW völlig überschritten und ich denke mal das es auch kein x265vfw geben wird.

Zitat von De-M-oN

irgendwann sind auch mal die Grenzen von VfW völlig überschritten und ich denke mal das es auch kein x265vfw geben wird.

Die VfW Schnittstelle ist ja ledeglich dafür da die RAW Frames im Farbraum xyz an einen [lexicon]Encoder[/lexicon] zu schicken. VfW Codecs sind jedoch Windows Interne Codecs. Und [lexicon]x264[/lexicon], [lexicon]x265[/lexicon], [lexicon]VP9[/lexicon] und viele weitere sind ja nicht nur Windows Spezifisch. Die Entwickler orientieren sich da schon auch an andere [lexicon]OS[/lexicon]. z.B. muss das ja auch mit [lexicon]Linux[/lexicon] und Mac laufen, als auch Handys etc. pp. Konsolen bla bla...

Von daher ist ein VfW etwas zu direkt für Windows. Könnte man gewiss auch machen, die Möglichkeit ist ja da. Nur macht das kein Entwickler großartig.

Nur die Tatsache das VfW ausschließlich in ein [lexicon]AVI[/lexicon] File zurückführen muss, wird oder kann ja bei [lexicon]x264vfw[/lexicon] umgangen werden. Also es ist schon möglich. Nur der Sinn sich nur auf VfW zu konzentrieren ist relativ banal, da CMD [lexicon]Encoder[/lexicon] zumal schneller fertig sind und auch besser auf andere [lexicon]OS[/lexicon] umschreiben lassen können. Das ist der eigentliche Hintergrund der Geschichte. Man empfindet es halt nicht für nötig einen VfW [lexicon]Encoder[/lexicon] zu bauen dafür.

Zitat von De-M-oN

Ein [lexicon]CLI[/lexicon] [lexicon]Encoder[/lexicon] wäre halt schön

Gibt es, allerdings sind die Binaries nicht direkt zum Download verfügbar, nur die Source. Oder ich suche an den falschen Stellen.
Daher entweder selber kompilieren oder eine fertige Version im Internet finden.

Falls jemand damit rum spielen möchte, Version 1.5.0 gibt es beispielsweise bei Doom9.
Die Parameter sind aber sehr dürftig dokumentiert, wenn überhaupt. Beinhaltet anscheinend auch teils schon VP10 Code.
Nehmt euch aber sehr viel Zeit, wenn ihr etwas davon ausprobieren solltet. Dauert bei mir irgendwie immer 10x bis 20x länger als mit [lexicon]x264[/lexicon].

Edit: Oh, wie ich in meinem letzten Post schon geschrieben habe, der [lexicon]Encoder[/lexicon] verhaut mir bei 60FPS Encodes immer die [lexicon]FPS[/lexicon] Angabe und schreibt dort immer 59,94 rein. Einmal neu [lexicon]muxen[/lexicon] und dabei die [lexicon]FPS[/lexicon] Angabe korrigieren reicht hierbei.

Zitat von Kayten

Edit: Oh, wie ich in meinem letzten Post schon geschrieben habe, der [lexicon]Encoder[/lexicon] verhaut mir bei 60FPS Encodes immer die [lexicon]FPS[/lexicon] Angabe und schreibt dort immer 59,94 rein. Einmal neu [lexicon]muxen[/lexicon] über und dabei die [lexicon]FPS[/lexicon] Angabe korrigieren reicht hierbei.

Man kann die [lexicon]FPS[/lexicon] doch bestimmt als Parameter angeben oder nicht?

Bei [lexicon]x264[/lexicon] ist es auch sinnvoll immer die [lexicon]FPS[/lexicon] mitzugeben, sonst erkennt der gerne mal Variable Framerate wenn kein [lexicon]Avisynth[/lexicon] Script genutzt.

Apropos [lexicon]avisynth[/lexicon], damit könntest es ja dann vorgeben auch.

Denn wenn 59,94 [lexicon]fps[/lexicon] angegeben sind könnt ich mir vorstellen das er es auch in 59,94 encodet hat.

Zitat von De-M-oN

Man kann die [lexicon]FPS[/lexicon] doch bestimmt als Parameter angeben oder nicht?

Ja, kann man auch. Muss man sogar, sonst bleibt er standardmäßig bei 30FPS, wenn rawvideo über FFmpeg eingespeist wird.
Gebe ich aber 60/1 oder 60000/1000 an, kommt hinterher 59,94 raus.
Vielleicht übersehe ich auch eine Option, aber beheben kann ich das nur, wenn ich neu muxe.
Ansonsten zählt das wohl als Bug dieses Builds.

Naja das neumuxen wird das nicht beheben. Ich gehe stark davon aus, das er dann auch in 59,94 codiert hat.

Vllt gibts ja irgendwie NTSC / PAL setting oder so.

Wenn vor dem [lexicon]Muxen[/lexicon] 59,94FPS und eine Dauer von 1,983 Sekunden drinsteht und hinterher 60FPS und 2 Sekunden, dann wird das sehr wohl etwas gebracht haben, wenn über [lexicon]MKVToolNix[/lexicon] die [lexicon]FPS[/lexicon] auf 60 gesetzt werden.
Sowohl vor, als auch nach der Korrektur ist das Video 1:1 identisch mit dem [lexicon]Lossless[/lexicon] [lexicon]x264[/lexicon] Encode, was ich in einem der vorherigen Posts gezeigt habe.
Eine reine [lexicon]FPS[/lexicon] Änderung bei gleicher Frameanzahl verändert die Frames selbst schließlich nicht.
Vielleicht hat der [lexicon]Encoder[/lexicon] auch einfach nur falsche Daten im [lexicon]WebM[/lexicon] Header hinterlassen, ich weiß es nicht.
Auf jeden Fall zeigte FFprobe nicht die 60FPS an, die ich vpxenc übergeben hatte.

@Kayten

Mit was haste denn die [lexicon]FPS[/lexicon] Ausgabe angegeben? Mit -r oder -[lexicon]fps[/lexicon] ? Weil -r würde es erzwingen.

Keins davon, da FFmpeg damit nichts mehr zu tun hat, der 10Bit Encode lief via Pipe über vpxenc. Der 8Bit Encode, der direkt über FFmpeg läuft, ist einwandfrei.
Die Parameter variierten bei mir immer etwas, da ich am ausprobieren war, aber grob sah es so aus:
vpxenc --fps=60/1 --i444 --input-bit-depth=10 --bit-depth=10 -w 2048 -h 1152 --best --passes=1 --profile=3 --frame-parallel=1 --lossless=1 -o "[output]" -