AMD Hardware Video Encoding (h.264/h.265) [Archiv]

Gast

2017-05-08, 12:23:12

Hi

Ich bin auf der Suche nach einem Videoencoder mit AMF support. Mit Polaris und dem AMF kann man ja seit Dezember eigentlich in Hardeware h.265 encodierte Videos erstellen. Leider finde ich kein funktionierendes Tool mit dem ich das auch nutzen kann.

OBS hat ein Plugin, dass allerdings wohl auf h.264 beschränkt ist und vor allem hab ich bisher nicht herausgefunden wie ich mit OBS einfach ein Quellvideo recode und abspeichere.

A's Video Converter (https://forum.doom9.org/showthread.php?t=174132) kann eigentlich auch h.265 mit AMF auf Polaris aber leider wirft mir das Tool einfach einen Fehler (Failed!) aus, wenn ich versuche in Video neu zu encoden. Er scheint das Videoformat welches ReLive erstellt nicht zu mögen, denn auch mit dem Softwareencoder kommt es zu einer Fehlermeldung.

Leider bietet Handbrake noch keine Unterstützung für AMF. Es wird aber wohl daran gearbeitet. Denn Xaymar, der Ersteller des OBS AMF Plugins, hat sich da jetzt wohl vor gut 3 Wochen eingeklinkt. (https://github.com/HandBrake/HandBrake/issues/697)

Vielleicht hat ja noch jemand von euch einen Tipp für mich? Oder vielleicht kann mir jemand erklären, wie ich mit OBS einfach ein Video recoden kann.

Danke!

Gast

2017-05-08, 13:32:42

ich hab auch noch vceenc (
http://rigaya34589.blog135.fc2.com/blog-entry-901.html) getestet. das war gar nicht so einfach, denn es gibt nur setups in koreanisch(?). leider errort das auch mit:

storage->SetProperty(PeakBitrate) failed Error:AMF_OUT_OF_RANGE
storage->SetProperty(VBVBufferSize) failed Error:AMF_OUT_OF_RANGE

ach noch als ergänzung das log von a's:

StartConvert
StopConvert: EncCount=0
StartConvert
StopConvert: EncCount=0
StartConvert
RunTranscode0
RunTranscode
SendTranscodeParam00
TS00_RecvParam
SendTranscodeControl(00): QueryConst
TS00_RecvTranscodeControl: QueryConst
[TranscodeSettings]
[Input]
File: *.mp4
Index=0
Delay=0
[HardwareInfo]
VendorID: 1002
DeviceID: 67DF
Desc: Radeon (TM) RX 480 Graphics
Luid: 084258285
HwType: 4
[VideoEncoderConfig]
Encoder: AMD VCE H.265 Encoder
Format: H.265
SupFlag: 603042DFB
SubSupFlag: C0B
LowLatencyMode: 0
EncodeNumThreads: 0
RateControl: PeakVBR
Pre-Analysis: 0
VBAQ: 0
TragetBitrate: 5000000
MaxBitrate: 6500000
MinimumQP: 0
MaximumQP: 33003300330000
QP: FFFFFFFFFFFF0000
Quality: -1
QualityVsSpeed: 1
GOPLength: 0
NumOfBframes: 0
B-frames Delta QP: -11
MaxRefFrames: -1
Reference B-frames: True
Ref B-frames Delta QP: -11
FrameFormat: 0
InLoopDeblockFilter: True
MotionEstimation: True/True
PAR: 0:0
DAR: 0:0
CABAC: False
Profile: 1
Level: -1
DeinterlaceMode: 0
MiscSetting: 0
[AudioEncoderConfig]
Format: 7
Channel: 0
SampleRate: 0
Bitrate: 128000
OpusRateCnt:0
[HardwarePreprocessorConfig]
QualityVsSpeed: 0
Size: 1920x1080
HQDownScaling: False
AvgTimePerFrame: -2
FrameInterpolation: 0
[DecodeConfig]
0
VideoDecoderName:
VideoDecoderClsid: 00000000-0000-0000-0000-000000000000
VideoDecoderDllPath:
GPUDecode: False
AMDDecoderGPUMode: 1
AmdDecoderDeinterlace: False
AudioDecoderName:
AudioDecoderClsid: 00000000-0000-0000-0000-000000000000
AudioDecoderDllPath:
SplitterName:
SplitterClsid: 00000000-0000-0000-0000-000000000000
SplitterDllPath:
[MuxerConfig]
Mode: MP4
UseTimecode:False
SupportOver4GB:False

CreateDecodeSink Ok
CreateEncode failed
RecvTranscodeConstResult(00): Failed
SendTranscodeControl(00): QueryStop
TS00_RecvTranscodeControl: QueryStop
StopTranscode
TS00_FormClosing, EncCR=0
0/-1/-1/-1/0/0
TS00_Closed
CompleteConvert
StartConvert
StopConvert: EncCount=0
Closing
ClosedAsVideoConv

Ich nutze win10 creators und Relive 17.5.1.

in asien scheint es allgemein mehr tools für amd zu geben.

Gast

2017-05-08, 15:36:20

Ich habe A's Video Converter zum laufen gebracht. Sau geiles Tool.

dazu muss man direkt im Tool die zip für lavfilters einbinden: http://bluesky23.yukishigure.com/en/avc/howto/lavFilters.html

man kann damit seine videos auch schneiden, convertieren, resizen, filter anlegen und zusammenführen.

Screemer

2017-11-18, 14:22:35

Narolf

2017-11-18, 16:17:07

so nun nach ewigkeiten wurde der patch für amf encoding im ffmpeg eingepflegt.

https://github.com/HandBrake/HandBrake/issues/697
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/219757.html

alle tools die auf ffmpeg setzen (handbrake, etc.) können nun via ffmpeg amds h264 und hevc/h265 hardware encoder verwenden.
Hab mal ein bisschen gelesen, weil mich das Thema interessiert.

Der Patch ist wohl noch nicht ganz fertig, wird aber bestimmt nicht mehr lange dauern.

Handbrake nutzt leider nicht ffmpeg, sondern libav, allerdings scheint es Bemühungen zu geben, auf ffmpeg umzusatteln. Diese Bemühungen werden allerdings frühestens mit Version 1.2 fruchten (momentan aktuell ist 1.0.7). Ich schätze mal, dass es wenigstens noch ein Jahr dauern wird, bis Handbrake dieses Feature bekommt, lasse mich aber gerne eines Besseren belehren.

Screemer

2017-11-18, 16:31:39

es werden in handbrake grad switches eingebaut um ffmpeg nutzen zu können. man kann es sich also durchaus schon mit ffmpeg support kompilieren. hoffe da gibts dann zeitnah auch binary releases.: https://github.com/HandBrake/HandBrake/pull/981
https://github.com/HandBrake/HandBrake/pull/983

der patch für ffmpeg ist auf jeden fall was amf fast fertig. heute kam wieder ein kleines update von amd: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220091.html

bin gespannt, wann es in die release version aufgenommen werden wird oder der patch zumindest in binary releaes von usern auftaucht.

Narolf

2017-11-18, 17:07:35

der patch für ffmpeg ist auf jeden fall was amf fast fertig. heute kam wieder ein kleines update von amd: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220091.html
Jo, da gibt's noch ein bisschen hin und her, damit der Patch so ist, dass die ffmpeg-Entwickler ihr OK geben. Ich denke auch nicht, dass es noch allzu lange braucht.

es werden in handbrake grad switches eingebaut um ffmpeg nutzen zu können. man kann es sich also durchaus schon mit ffmpeg support kompilieren. hoffe da gibts dann zeitnah auch binary releases.: https://github.com/HandBrake/HandBrake/pull/981
https://github.com/HandBrake/HandBrake/pull/983

[...]

bin gespannt, wann es in die release version aufgenommen werden wird oder der patch zumindest in binary releaes von usern auftaucht.
Basierend hierauf wird es offiziell wohl erst mit 1.2 soweit sein: https://github.com/HandBrake/HandBrake/issues/974#issuecomment-342199883

Wenn es aber als Überbrückung fertig gebackene Binaries mit ffmpeg (und damit AMD-Hardwaredecodierung) von Usern geben würde, wäre das schön, die würde ich wahrscheinlich auch selber nutzen.

Screemer

2017-11-18, 17:12:56

hier das ganze von ffmpeg mal in hübsch und nicht im 90s look: https://patchwork.ffmpeg.org/patch/6135/

gibt ja von handbrake immer wieder binary releases mit aktuellem patch stand. warum man ganz ehrlich bis 1.2 warten will um ffmpeg als alternative nutzbar zu machen ist mir ein rätsel. das dauert ja dann noch ewig. naja dann wird halt weiter staxrip genutzt.

da ich zur zeit auf eine nvida karte setze bin grad am herausfinden ob dieser patch mittlerweile in ffmpeg (https://patchwork.ffmpeg.org/patch/2526/) implementiert ist und wie man cuvid zum resizen und cropen nutzt. leider bin ich nicht so afin was das lesen von code angeht um herauszufinden welche parameter ich für crop und resize via ffmpeg nutzen muss. damit wäre crop und scale nämlich quasi kostenlos über den hardwaredecoder realisierbar. scale_npp kostet ja ganz gut performance.

€dit:

Decoder h264_cuvid [Nvidia CUVID H264 decoder]:
General capabilities: delay
Threading capabilities: none
Supported pixel formats: cuda nv12 p010le p016le
h264_cuvid AVOptions:
-deint <int> .D.V.... Set deinterlacing mode (from 0 to 2) (default weave)
weave .D.V.... Weave deinterlacing (do nothing)
bob .D.V.... Bob deinterlacing
adaptive .D.V.... Adaptive deinterlacing
-gpu <string> .D.V.... GPU to be used for decoding
-surfaces <int> .D.V.... Maximum surfaces to be used for decoding (from 0 to INT_MAX) (default 25)
-drop_second_field <boolean> .D.V.... Drop second field when deinterlacing (default false)
-crop <string> .D.V.... Crop (top)x(bottom)x(left)x(right)
-resize <string> .D.V.... Resize (width)x(height)

cool ist im aktuellen ffmpeg binary release drin.

deekey777

2017-11-18, 21:50:03

Vielleicht habe ich das Thema falsch verstanden, aber mit Stax und Hybrid gibt es zwei GUIs, die VCEEnc nutzen.

Screemer

2017-11-18, 22:27:08

VCEEnC ist ja nur eine Implementierung Fähigkeiten der Hardwareencoder von AMD. Wenn ich mich richtig zurück erinnere war es der erste Encoder, der vom neuen AMF Gebrauch machte. Leider wird er seit gut 10 Monaten nicht mehr weiter gepflegt und funktionierte bei Release auch eher schlecht als recht mit meiner damaligen 480.

Deshalb bin ich dann auf A's Video Converter gestoßen, der auch auf AMF für die Entwicklung seines Decoders genutzt hat und das Tool auch mit anderen coolen Features ausgestattet hatte. z.B. eine Art Shadowplay mit Nutzung von AMDs Hardwareencoder und zwar noch vor ReLive 16.12.

Im März war irgendwas mit VCEEnC nicht in Ordnung, wenn ich mich recht erinnere müsste es der hevc/265 support gewesen sein, der mich dann A's nutzen lies.

Das gute an der Umsetzung in FFmpeg ist, dass man nicht mehr auf weitere Encoder setzen muss und alles aus einer Hand bekommt. Außerdem können dann alle Tools die auf ffmpeg setzen AMDs UVD/VCE nutzen.

AMF ist der Nachfolger von AMDs Media SDK. Damit sind viele neue Funktionen hinzugekommen, die AMD-GPUs schon längere Zeit unterstützen. Leider ist die Adaption recht träge.

deekey777

2018-01-20, 23:16:29

Ist das Ding (ffmpeg&AMF) fertig? Es scheint akzeptiert worden zu sein, https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=4231#p12886

Aber wie kriege ich das Ding zum Laufen?

Screemer

2018-01-21, 02:02:01

das sieht doch gut aus für alle projekte die auf ffmpeg setzen.

Charlie Chaplin

2018-03-03, 16:03:17

Aber wie kriege ich das Ding zum Laufen?
Gibt es hierzu etwas neues?

Screemer

2018-03-04, 14:58:01

a's video converter (http://bluesky23.yukishigure.com/en/AsVideoConv.html) oder ffmpeg über die cmd. obs schon guis für ffmpeg gibt die das ganze nutzen keine ahnung. a's nutzt kein ffmpeg sondern wohl eigenen code. obs (https://www.xaymar.com/portfolio/plugin-amf-encoder-for-obs-studio/) kann auch über amf encoden. handbrake wohl noch nicht: https://github.com/HandBrake/HandBrake/issues/697. handbrake wechselt wohl mit einem kommenden release von libav zu ffmpeg (https://github.com/HandBrake/HandBrake/pull/1144) und da es davon unterstützt wird, soll es wohl auch gui elemente dafür geben.

wird zeit 3 jahre nach einführung von amf und vce. ich check auch nicht, warum es da von amd keine referenzimplementierung gibt. das ist ein feature, dass so oft nachgefragt wird und es gibt 0 präsenz dafür über google. ich hab mich da anfang 2017 halb tot gesucht. es gibt heute noch redaktionen, die behaupten amd könne kein h265 in hardware encoden und schreiben dann sowas in reviews:

AMD's Advanced Media Framework (AMF). However, we have been unable to find any software support for this toolset beyond AMD's own ReLive application.

einfach nur selten dämlich!

deekey777

2018-04-21, 16:50:19

FFMPEG 4.0 ist draußen und AMF offiziel drin: http://ffmpeg.org/index.html#pr4.0

Screemer

2018-04-21, 17:05:06

1,5 Jahre seit amf und ein jahr nach dem ich den thread aufgemacht hab :D

deekey777

2018-04-21, 22:42:22

1,5 Jahre seit amf und ein jahr nach dem ich den thread aufgemacht hab :D
... und weiterhin kein passendes GUI.

Narolf

2018-04-22, 09:27:45

... und weiterhin kein passendes GUI.
Ja, sehr ärgerlich. Wenn ich raten müsste, was der Grund ist, würde ich sagen, dass es eine Mischung aus "die Entwickler haben schlicht keine AMD-Hardware und deswegen kein großes Interesse an dem Feature" und "die Entwickler der Video-Software sind hauptsächlich an Software-Encoding interessiert und behandeln Hardware-Encoding daher nur stiefmütterlich". :usad:

Gorkon

2018-04-22, 22:25:15

Per Kommandozeile mal Quick and Dirty probiert ob es überhaupt funktioniert. Ja, tut es ;) Auflösung war FHD.

Ryzen 5 2400G @ 3,8GHz / iGPU @ Default (Treiber: 23.20.841.1024) / 16GB DDR4-2800 (14-16-16-34-50-1T)

.\ffmpeg.exe -i D:\The_Orville.mkv -c:v hevc_amf -quality quality D:\The_Orville_Test.mp4

frame=66173 fps=172 q=-0.0 Lsize= 789737kB time=00:45:59.92 bitrate=2344.1kbits/s speed=7.18xDeckt sich mit den Werten vom AMF-Encoder für OBS bzw. aus dem Raven Ridge Review von Golem. UHD müssten es dann ~50fps sein. Quali war sogar ganz gut mit HEVC. Beizeiten versuch ich mal nen Vergleich mit Screenshots zu machen...

Screemer

2018-04-23, 13:34:14

funktionieren tut das schon seit november letzten jahres. hatte 0 probleme mit den binary releases von version 3.4x+ und amf. allerdings sollte jetzt endlich mal bewegung bei den guis in die sache kommen.

deekey777

2018-04-23, 14:31:00

Braucht man was besonderes wie AviSynthdings oder ähnliches? Oder reicht die Exe und die passende Commandozeile aus? Nebenbei: Welche Befehle gibt es?
"-quality quality" reicht aus?

Gorkon

2018-04-23, 15:06:47

Ich habs gestern Abend wirklich nur Quick and Dirty ausprobiert...keinen Bock gehabt mich erst wieder in die halb grausame Doku von ffmpeg reinzulesen ;( Zumal GPU-Encoding ja sowieso von der Quali eher "mäh" ist.

War eher daran interessiert, ob der Kram auch mit Raven Ridge (VCN) und dem 17.40er Treiber überhaupt funktioniert oder man noch bis zum PR3-Treiber warten müsste.

Grüße

deekey777

2018-04-23, 18:40:40

Funktioniert auch mit meinem A10-9600P. :uup:

gmb

2018-04-24, 00:25:55

frame=66173 fps=172 q=-0.0 Lsize= 789737kB time=00:45:59.92 bitrate=2344.1kbits/s speed=7.18x[/CODE]Deckt sich mit den Werten vom AMF-Encoder für OBS bzw. aus dem Raven Ridge Review von Golem. UHD müssten es dann ~50fps sein. Quali war sogar ganz gut mit HEVC. Beizeiten versuch ich mal nen Vergleich mit Screenshots zu machen...

Ist die HEVC Qualität wenigstens besser als x264 medium?

Gorkon

2018-04-24, 18:52:04

Mir gings erstmal nur um die reine Funktionalität und Reproduzierbarkeit der angegebenen Geschwindigkeit seitens AMD > [x] Check...das passte.

Aber Qualität besser als Software-Encoding? Nicht wirklich, aber auch nicht so katastrophal wie früher mit allem < VCE 3.0. Mehr als "faster" würde ich aber realistisch nicht erwarten.

Wenn ich mal Zeit habe, versuch ich nen vernüftigen Vergleich zu machen. Aktuell kommt aber das RL dazwischen.

Grüße

deekey777

2018-06-18, 22:14:57

Handbrake Nightly kann VCE https://github.com/HandBrake/HandBrake/commits/master bzw. https://handbrake.fr/nightly.php

VCE wird zumindest angezeigt, ausprobiert habe ich das Build noch nicht.

dargo

2018-06-18, 22:21:53

Jo.

https://abload.de/img/vce69j34.jpg

Narolf

2018-06-19, 10:57:01

Sehr gut. Hab's mal mit zwei Testsamples ausprobiert.

Jellyfish (1080p, 100mbps, HEVC) (http://jell.yfish.us/)
4K UHD Fireworks Sample (http://4ksamples.com/4k-uhd-fireworks-sample/)

Einstellung war h.265 1080p mit gleichen fps wie die Quelle, Quality preset und crf 20. Als Grafikkarte kam eine RX460 zum Einsatz:
Jellyfish encodierte mit ~33 avg fps
Fireworks Trailer encodierte mit ~26 avg fps (hier noch Audio auf 96 kbit AAC gesetzt, im nach hinein hätte ich es einfach heraus lassen sollen ... >_>)

Hier die Resultate (Passwort 3dcenter): https://www86.zippyshare.com/v/yVYd71Jd/file.html

gmb

2018-06-19, 12:09:47

Das ist sehr langsam, läuft das überhaupt in Hardware?

dildo4u

2018-06-19, 12:18:34

deekey777

2018-06-19, 12:24:49

Wenn ich mich nicht irre, ist Polaris' VCE (3.4?) deutlich langsamer als seine Vorgänger, denn die Leistung wurde zugunsten von H.265-Encoding geopfert. Das gilt auch für H.264.

gmb

2018-06-19, 12:46:59

Mir erscheint das extrem schnell kommt es drauf an welche Files man Konvertiert?

https://www.techspot.com/review/1465-amd-ryzen-threadripper-1950x-1920x/page3.html

Ein Test mit Vega IGP wäre interessant.

26 fps sind sehr wenig, ich komme mit Quicksync und TU4 auf 100 fps, was ebenfalls recht langsam ist, liegt aber an der zu langsamen GPU. Mit TU7 sind das etwa 150 fps. Nvidia sollte hier auch auf etwa 150 fps kommen. Das ist halt konvertiert auf 1080p, mit Hardware Encoder keine große Sache. Es sollte erstmal geschaut werden, ob das wirklich von der Grafikkarte beschleunigt wird. Und wenn ja, vielleicht nur von der GPU. Polaris ist natürlich nicht mehr aktuell. Vega wäre hier interessanter.

dildo4u

2018-06-19, 12:53:36

Bei mir gibt es mit der 1070 keine Option der GPU Beschleunigung.

aufkrawall

2018-06-19, 13:14:16

Es sollte erstmal geschaut werden, ob das wirklich von der Grafikkarte beschleunigt wird.
Wo von denn sonst? Und ja, Win 10 Taskmanager sagt 100% GPU-Encoder Auslastung.

gmb

2018-06-19, 13:29:43

Wo von denn sonst? Und ja, Win 10 Taskmanager sagt 100% GPU-Encoder Auslastung.

Von der CPU oder der GPU ohne dedizierten Hardware Beschleuniger. Wenn das wirklich so langsam ist, ist das schwach für einen Hardware Encoder.

aufkrawall

2018-06-19, 13:32:04

Ich würde die Geschwindigkeit nicht ohne die Qualität beurteilen.
Btw. schafft Polaris natürlich 1440p 60fps HEVC via ReLive.

deekey777

2018-06-19, 13:43:55

Von der CPU oder der GPU ohne dedizierten Hardware Beschleuniger. Wenn das wirklich so langsam ist, ist das schwach für einen Hardware Encoder.
Und fühlst du dich jetzt besser?

Narolf

2018-06-19, 16:38:54

Das ist sehr langsam, läuft das überhaupt in Hardware?
Die GPU hilft definitiv mit, in dem Rechner ist ein Pentium G4560 drin, reines 1080p Software-Encoding mit h.265 wäre damit noch viel langsamer.

Ich habe jetzt nochmal das Jellyfish-Video getestet, laut Taskmanager ist die GPU-Encoding Auslastung zwischen 30% und 40%, die CPU Auslastung bei ~70%. Ich kann auch keine Unterschiede zwischen den drei Presets erkennen. Eventuell ist das Feature auch noch nicht besonders gut implementiert, ist ja gerade erst neu herein gekommen.

Savay

2018-06-19, 23:25:01

Narolf

2018-06-20, 07:12:54

Savay, falls es nicht zu viel Mühe ist, könntest du auch noch mal mit dem Fireworks Sample, das ich vorhin verlinkt habe, mit meinen geposteten Einstellungen gegentesten? Würde mich mal interessieren, in wie weit wir unterschiedliche Ergebnisse bekommen. Auch bildqualitätsmäßig, ich hab mein Resultat ja hochgeladen.

dargo

2018-06-20, 08:26:41

41 avg.fps hier mit RX Vega64 LCE undervoltet.

Edit:
Der R5 1600 @3,8Ghz liefert im Vergleich mit dem Medium Preset 14,8 avg.fps. Ich habe aber keine Ahnung inwieweit Medium Preset @CPU mit Quality Preset @GPU vergleichbar ist. Beim ersteren ist nämlich die Datei 85,7MB groß, beim zweiteren nur 43,9MB.

deekey777

2018-06-20, 08:55:25

Es hängt definitv ab was man kodiert...hab es grade mal mit einem meiner Files getestet:

1080p30 Fast Preset einmal nur mit
AMD VCE bzw. x265

H.265 VCE: ~156FPS @ VEGA64
X265: ~67FPS @ 2700X

Mit Super-HQ wird es etwas dramatischer:

Die Vega juckt das nicht...der 2700X knickt aber auf 38-40FPS ein.
Quali ist über x265 natürlich besser...die Files aber auch entsprechend größer.

IMO dürften Einstellungen wie Fast oder ähnliches zu vernachlässigen sein, wenn es um VCE geht. Der einzige Regler befindet sich unten, wo man zwischen Geschwindigkeit und Qualität wählen kann. CQ wirkt eher auf die Bitrate aus als auf die Qualität (je kleiner der Wert, umso höher die Bitrate). Es empfiehlt sich eher die AVG-Bitrate zu wählen bzw. zu bestimmen.

dargo

2018-06-20, 08:58:51

CQ wirkt eher auf die Bitrate aus als auf die Qualität (je kleiner der Wert, umso höher die Bitrate).
Du meinst QP? Hat hier übrigens überhaupt keine Auswirkung was ich bei QP @H265 VCE einstelle. Die Datei ist immer gleich groß.

deekey777

2018-06-20, 09:15:02

Du meinst QP? hat hier übrigens überhaupt keine Auswirkung was ich bei QP @H265 VCE einstelle. Die Datei ist immer gleich groß.
Ja, ich hatte den Regler nicht mehr im Kopf, es ist "Constant Quality". Zumindest bei QuickSync hatte der Regler Auswirkung (auch mit StaxRip, weil eben höhere Bitrate erzwungen), aber keine maßgebliche.

In Handbrake würde ich die Average Bitrate wählen, diese sollte aber mindestens 5000-6000 kBit/s für 1080p24&H.264 sein, um halbwegs ansehliche Ergebnisse zu haben. Wer aber wirklich seine Blu-rays rippen will und sie dann auch anschauen, für den gibt es weiterhin nur CPU-Encoding. Oder eben H.265 mit 5-6 MBit/s.

Vielleicht bin ich zu pessimistisch.

https://github.com/Xaymar/obs-studio_amf-encoder-plugin/wiki/Hardware-VCE3.4

Acceleration: Hardware
Profiles: High, Main, Baseline
Maximum Level: 5.2
B-Pictures Supported: No
Maximum Simultaneous Streams: 16

Wie das bei VCN 4.0 aussieht, weiß ich nicht.

dargo

2018-06-20, 09:30:03

Jo, bei AMD VCE funktioniert nur die avg. Bitrate, QP hat wie gesagt keine Auswirkung.

Narolf

2018-06-20, 11:55:27

LOL, ich bin mittlerweile so auf QP geeicht, dass ich gar nicht mehr daran gedacht habe, auf avg Bitrate umzustellen. :biggrin:

Auf 15 Mbps kriegt man dann auch das Colorbanding in dem Fireworks Sample zumindest ein Stück weit in den Griff. Ist aber auch ein gemeines Video was die Thematik angeht. Interessant, dass verschiedene Bitraten keinen Unterschied bei der Encodinggeschwindigkeit zu machen scheinen.

41 avg.fps hier mit RX Vega64 LCE undervoltet.

Edit:
Der R5 1600 @3,8Ghz liefert im Vergleich mit dem Medium Preset 14,8 avg.fps. Ich habe aber keine Ahnung inwieweit Medium Preset @CPU mit Quality Preset @GPU vergleichbar ist. Beim ersteren ist nämlich die Datei 85,7MB groß, beim zweiteren nur 43,9MB.
Gut, Vega ist zwar ~60% schneller als Polaris 11, aber auch nicht über 100 fps, was einige erwarteten. Eventuell ist das Fireworks Sample einfach generell ein sehr forderndes Video für jegliche Encoder.

Wenn jetzt noch jemand mit Polaris 10/20 seine Werte postet, hätten wir schon mal einen kleinen Überblick über die aktuell gängigen diskreten GPUs von AMD.

Für mich muss ich sagen, dass die Qualität mich jetzt nicht unbedingt vom Hocker haut, aber damit habe ich ehrlich gesagt auch gerechnet und man kann ja im zweifel auch einfach die Bitrate höher setzen. Aber zumindest in meinem Rechner ist es dennoch eine gute Option, wenn ich mal schnell was encoden möchte, für Archivierung dann eher nicht so. An h.265 Software-Encoding war ja vorher mit einem Pentium G4560 nicht zu denken.

dargo

2018-06-20, 12:38:12

Auf 15 Mbps kriegt man dann auch das Colorbanding in dem Fireworks Sample zumindest ein Stück weit in den Griff. Ist aber auch ein gemeines Video was die Thematik angeht.

Jo... ich hatte mal 10Mbps probiert, das Banding in den dunklen Szenen war recht übel. War aber auch mit Softwareencoding über die CPU @RF 20 genau so. Die Bitrate ist dafür viel zu niedrig.

Gut, Vega ist zwar ~60% schneller als Polaris 11, aber auch nicht über 100 fps, was einige erwarteten. Eventuell ist das Fireworks Sample einfach generell ein sehr forderndes Video für jegliche Encoder.

Polaris 10/20.

gmb

2018-06-20, 12:56:50

Ich würde die Geschwindigkeit nicht ohne die Qualität beurteilen.
Btw. schafft Polaris natürlich 1440p 60fps HEVC via ReLive.

Qualitativ kann man nicht so viel zu sagen, die samples sind sehr kurz, nicht vielseitig genug und auch sehr dunkel beim Fireworks Sample. Jedoch zeigt mein Quicksync Video in der gleichen Größe und vergleichbarem Modus (H265 CQP) eine deutliche bessere Detailerhaltung. Wie sieht denn die CPU Auslastung aus?

Und fühlst du dich jetzt besser?

Troll dich.

Die GPU hilft definitiv mit, in dem Rechner ist ein Pentium G4560 drin, reines 1080p Software-Encoding mit h.265 wäre damit noch viel langsamer.

Ich habe jetzt nochmal das Jellyfish-Video getestet, laut Taskmanager ist die GPU-Encoding Auslastung zwischen 30% und 40%, die CPU Auslastung bei ~70%. Ich kann auch keine Unterschiede zwischen den drei Presets erkennen. Eventuell ist das Feature auch noch nicht besonders gut implementiert, ist ja gerade erst neu herein gekommen.

Dann ist das anscheinend nicht in Hardware bzw. nur teilweise, somit kein Wunder. Eventuell läuft das decoding auf der CPU, könnte dann aber auch an Handbrake liegen.

aufkrawall

2018-06-20, 13:34:55

Meine CPU war afair nur auf einem Kern ausgelastet.

deekey777

2018-06-20, 13:58:32

...

Dann ist das anscheinend nicht in Hardware bzw. nur teilweise, somit kein Wunder. Eventuell läuft das decoding auf der CPU, könnte dann aber auch an Handbrake liegen.

Es gibt in diesem Handrake-Build kein Decoding auf GPU (außer Quicksync). Und wenn man GPU-Decoding auf älteren Versionen aktivieren wollte, gab es einen Hinweis, dass es nur bei schwachen CPUs etwas bringt.

Narolf

2018-06-20, 16:39:09

Falls hier jemand noch andere Video Samples durchtesten möchte, einfach Links posten. Die Quelldatei sollte halt wenigstens 1080p (besser 4k), >=40Mbps (bzw keine leicht erkennbaren Kompressionsartefakte haben) und nicht über 5 min lang sein.

Polaris 10/20.
Ich hatte mich auf meine eigenen Ergebnisse als Vergleich bezogen und ich hab eine RX460, also Polaris 11. Polaris 10 und 11 haben zwar offiziell die gleiche VCE-Version drin, aber ob die auch wirklich die selbe Leistung haben müsste ein Test zeigen.

dargo

2018-06-21, 18:24:28

Ich hatte mich auf meine eigenen Ergebnisse als Vergleich bezogen und ich hab eine RX460, also Polaris 11.
Ups, sorry... ich hatte aus mir unerklärlichen Gründen die 60% auf die Spieleleistung projeziert. :freak:

deekey777

2018-06-21, 19:04:48

https://github.com/HandBrake/HandBrake/issues/1408

CQ funktioniert derzeit nicht.

Savay

2018-06-21, 23:40:55

BeetleatWar1977

2018-06-22, 14:30:16

gmb

2018-06-23, 13:18:22

Ich komme mit dem FireWorks Sample @Fast1080p30 auf folgende Werte:
H265 VCE -> ~49FPS
x265 -> ~27FPS

Die Systemumgebung und Quelldatei spielt bezüglich des Decoding wohl definitiv eine Rolle.
Die CPU ist nämlich auch via VCE recht gut ausgelastet.

Mach das mal ohne Decomb in Handbrake, wie sieht es dann aus? Läuft VCEEnc eigentlich schneller als Handbrake?

Savay

2018-06-25, 18:59:56

Ohne Decomb sind es bei ansonsten gleichen Settings ~76FPS@VCE (und ~34@x265)
CPU Auslastung ist trotzdem bei durchgängig ~50%.

EDIT:
Meine eigene Testdatei von der letzten Seite kommt ohne Decomb übrigens auf ~220FPS@VCE und ~80FPS@x265

gmb

2018-06-25, 20:26:39

Das sieht schon sinnvoller aus. Hab ich's doch gewusst, dass 26 fps nicht stimmen können. Mit hardware decoding läuft Quicksync in Handbrake mit dem sample übrigens satte 35% schneller bei mir (i7-7700k) verglichen mit deaktiviertem HW decoding. Falls hardware decoding bei AMD nicht funktioniert, könnte eine volle hardware Beschleunigung auch auf 100 fps kommen. Allerdings ist auch mit Quicksync und hardware decoding die CPU Auslastung in Handbrake trotzdem sehr hoch bei diesem sample. Ich tippe mal drauf, dass Handbrake die Umwandlung auf 1080p nicht auf der VPP durchführen lässt. Die CPU Auslastung mit QSVEnc mit voller Hardware Beschleunigung und VPP ist nämlich sehr niedrig.

deekey777

2018-06-26, 12:29:20

Zumindest bei mir war VCEEnc nicht viel schneller, ist aber länger her.

Handbrake wird auch NVIDIA-Encoder unterstützen, vielleicht ist die Unterstützung schon drin (Nightly).

gmb

2018-07-01, 11:49:44

Also die Qualität ist richtig schlecht, zumindest bei dem hier verlinkten Fireworks Video, hier am Beispiel vom Frame 380.

AMD RX460= https://abload.de/img/amd_1ucs8f.png
Intel HD 630= https://abload.de/img/intel_1tbs2h.png

Videos sind gleich groß und beide VBR (QP funktioniert ja angeblich nicht).

Kann sein, dass AMD bei der Konvertierung von 4k auf 1080p viel Qualität verschenkt. Intel hat einen sehr guten und schnellen Hardware Scaler.

Achill

2018-07-01, 21:50:52

gmb

2018-07-01, 23:44:41

Die Bilder sind schon von einen unterschiedlichen Zeitpunkt. Und welches Intel-Video wurde verwendet?

Nein sind sie nicht, das ist vom Frame 380 jeweils. Das Intel Video ist von mir. Das Original findest du in Beitrag #28.

aufkrawall

2018-07-31, 23:17:30

Leicht OT, aber es gibt jetzt auch nvenc in Handbrake Nightly. Da sich die Presets nicht auf die fps auswirken, scheint die Option wohl noch nicht zu gehen.

Achill

2018-08-01, 00:17:37

Ich habe gerade auch mal getestet, der "Constant Quality" Regler hat definitiv Auswirkungen auf die Zielgröße, das Firework-Video wird mit:
- QP12 => ~1 GB
- QP18 => ~400 MB

.. groß. Mit einer Avg Bitrate von 15.000 kbits sind es gerade mal ~195 MB.

Hier gibt es noch Bilder von Pos. 380 - hab das Video bis ca. Frame 400 laufen lassen, dann gestoppt und zum Schluss zu Frame 380 gesprungen. Damit kann im Status vom Player die Avg. Bitrate sehen für die ersten 12s.

Avg. Bitrate: 15000
https://i.imgur.com/qfSWn5S.png

Constant Quality: 18QP
https://i.imgur.com/jgarfxG.png

Constant Quality: 12QP
https://i.imgur.com/72TFaBb.png

aufkrawall

2018-08-10, 19:04:04

Soll wohl auch abseits von Handbrake für Linux kommen:
https://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues/4#issuecomment-410260519

Für obs hat jemand btw. vaapi encoding implementiert:
https://gitlab.com/GloriousEggroll/arch-obs-studio-latest-ffmpeg-vaapi
https://obsproject.com/forum/threads/experimental-ffmpeg-vaapi-plugin.61529/page-2#post-348725

Rooter

2018-08-10, 20:53:08

Die Qualität ist beim GPU-Encoding also auch 2018 noch Kacke. :(
Warum schafft es niemand einen Encoder zu bauen der die GPU nutzt aber gscheite Qualität auf dem Niveau von x264 liefert? Oder ist das mit der API gar nicht machbar?

Also die Qualität ist richtig schlecht, zumindest bei dem hier verlinkten Fireworks Video, hier am Beispiel vom Frame 380.

AMD RX460= https://abload.de/img/amd_1ucs8f.png
Intel HD 630= https://abload.de/img/intel_1tbs2h.pngStimmt, AMD sieht unter aller Sau aus. :eek:

Kann sein, dass AMD bei der Konvertierung von 4k auf 1080p viel Qualität verschenkt. Intel hat einen sehr guten und schnellen Hardware Scaler.Das Ringing an den Gebäudekanten und die verschwundenen Details kommen sicher nicht vom Scaler.

MfG
Rooter

dargo

2018-08-10, 20:59:11

Die Qualität ist beim GPU-Encoding also auch 2018 noch Kacke. :(

Sehe ich nicht so. Bzw. diese Aussage ist mir zu pauschal gehalten. Die Qualität lässt nur bei mickrigen Bitraten zu wünschen übrig. Mit hohen Bitraten sieht es anders aus. Erst recht mit HEVC.

aufkrawall

2018-08-10, 21:28:02

Mit AV1 10/12 Bit Hardware-Encoder düfte endgültig kein Endanwender mehr die CPU dafür anfassen.

Narolf

2018-08-10, 22:01:18

Mit AV1 10/12 Bit Hardware-Encoder düfte endgültig kein Endanwender mehr die CPU dafür anfassen.
Jo, wenn man mal davon ausgeht, dass die Rechenpower-Anforderungen ähnlich stark steigen wie beim Schritt x264->x265, dann brauch man wohl schon eine HEDT-CPU um >=1080p 2h Videomaterial innerhalb einer Nacht fertig zu encoden. Solch einen Rechner haben die wenigsten zu Hause herum stehen. Da wird Hardwareencoding der einzige Weg sein, wenn man nicht ewig den Rechner mit Encoding-Jobs blockieren will.

deekey777

2018-09-08, 21:23:29

Handbrake 1.1.2 ist offiziell: https://github.com/HandBrake/HandBrake/blob/master/NEWS.markdown#handbrake-112

VCE und NVENC sind jetzt drin. (FFMPEG 4.0 halt)

aufkrawall

2018-09-08, 22:02:37

Hier gibts kein nvenc.

dildo4u

2018-09-08, 22:21:58

Version 1.2 soll es haben nicht 1.1.2.

1.2 ist erst 55% Komplett.

https://github.com/HandBrake/HandBrake/milestone/10

deekey777

2018-09-08, 22:42:10

Hier gibts kein nvenc.
Argh, die falschen Neuerungen zitiert.

aufkrawall

2018-09-09, 14:51:37

Hm, weird. Die Quality-Presets von nvenc für H.264 haben hier nur mit VBR anstatt CQ einen Effekt, für H.265 mit beidem.
Allerdings könnte bei H.264 durch die viel höheren fps auch das CPU-Limit mit reinspielen.

Wir sollten nochmal einen Thread für Vergleiche auf machen, dass jeder framegenaue Ergebnisse eines Referenzvideos posten kann.

aufkrawall

2018-09-26, 17:20:48

Für obs hat jemand btw. vaapi encoding implementiert:
https://gitlab.com/GloriousEggroll/arch-obs-studio-latest-ffmpeg-vaapi
https://obsproject.com/forum/threads/experimental-ffmpeg-vaapi-plugin.61529/page-2#post-348725
Ist jetzt upstream =) :
https://github.com/obsproject/obs-studio/commit/a64ae11bce8ed9a7c8f1deba3338f77595dba903

robbitop

2018-09-26, 21:17:05

Mit AV1 10/12 Bit Hardware-Encoder düfte endgültig kein Endanwender mehr die CPU dafür anfassen.
Der Codec sagt IMO recht wenig über die BQ/Bitrate aus.

NV brüstet sich bei Turing damit, dass NVEC nun einen riesen Sprung gemacht hat und HEVC in Punkto BQ/Bitrate mit x264 im fast Preset mithalten kann.
Mit einem Codec, der >10Jahre alt ist mit einem Gurkenpreset...

Softwareencoding ist wohl kaum zu schlagen (wenn es um BQ pro Bitrate geht), da sich die komplexen (und besonders BQ/Bitrate steigendernden Algorithmen) nur schwer/gar nicht in HW gießen lassen und/oder nur begrenzt paralellisierbar sind.
Bei HEVC Encoding nimmt die Skalierbarkeit mit CPU Cores auch ggü x264 ab, was ich so gelesen habe.

aufkrawall

2018-09-26, 21:30:20

x264 ist immer noch gut und fast kein Gurkenpreset. Dafür, dass mit HW HEVC/VP9-Encoding die Qualität nicht deutlich gegenüber HW H.264/VP8 angestiegen sei, hätte ich gerne einen Nachweis. Bleibt auch immer noch die höhere Bittiefe, und natürlich wird es AV1 HW-Encoder geben.

robbitop

2018-09-26, 22:05:22

X265 ist bei gleichem preset mittels cpu nochmal deutlich besser (wenn auch rechenintensiver). Ich wollte damit nur sagen, dass gpu Encoding bzgl bq/bandbreite immer den deutlich kürzeren ziehen wird. Dafür muss man dann aber Rechenzeit mitbringen.

Dass die Qualität hw encoding hevc vs hw encoding h264 gestiegen ist, habe ich nie bezweifelt. Aber im Vergleich zu Softwareencoding ist es halt immer noch eine andere Liga.

iuno

2018-09-27, 01:37:04

Benutzt OBS eigentlich kein ffmpeg? Damit geht schon laenger va-api encoding. Habe direkt mit ffmpeg auch schon vaapi h.264 (und zum Testen auch h.265) Desktopaufnahmen gemacht, direkt auf Twitch oder so streamen kann man damit halt nicht, geht bei meiner Leitung aber eh nicht.

Hat eigentlich jemand mal dieses 2-pass encoding ausprobiert dass AMD seit Polaris beworben hat?

dildo4u

2018-12-26, 11:14:37

Handbrake 1.2 Final ist raus mit AMD VCE.

https://handbrake.fr/downloads.php

https://farm8.staticflickr.com/7817/46469547261_336613a77c_b.jpg (https://flic.kr/p/2dNmzqH)handbark3e (https://flic.kr/p/2dNmzqH) by Gorgul (https://www.flickr.com/photos/56281102@N02/), auf Flickr

Screemer

2018-12-26, 11:42:49

dildo4u

2018-12-26, 12:04:29

Tests mit Handbrake 1.2 Final:

Fireworks Sample MPEG-4 ca 1.2GB 95 Megabits

http://4ksamples.com/4k-uhd-fireworks-sample/

Test mit CPU h.265(Ryzen 2600X@default) 7 Bilder pro Sekunde. 4k 30fps 15 Megabits 198mb

https://drive.google.com/open?id=1x9BZcCGFN78iIzhQH-ovYMZ8fN3lfrG2

Test mit NVenc h.265(GTX 1070) 45 Bilder pro Sekunde. 4k 30fps 15 Megabits 196mb

https://drive.google.com/open?id=1HeTiQzUASuXjC_2GCIhRZ2xgn55b6hso

Hab das Roku 4k30 Profil genommen und jeweils 15 Megabits fest eingestellt.

Narolf

2018-12-26, 15:29:53

Es halt also nur etwas über ein Jahr gedauert :ugly:
Hab ich doch gesagt! :uup:

Nee, aber mal ernsthaft, besser spät als nie, jetzt brauch ich dann auch nicht mehr die Nightlies installieren.

aufkrawall

2018-12-26, 15:34:54

Gibt allerdings immer noch kein AMF für Linux.

Rooter

2018-12-26, 16:10:35

Test mit CPU h.265(Ryzen 2600X@default) 7 Bilder pro Sekunde. 4k 30fps 15 Megabits 198mb

https://drive.google.com/open?id=1x9BZcCGFN78iIzhQH-ovYMZ8fN3lfrG2

Test mit NVenc h.265(GTX 1070) 45 Bilder pro Sekunde. 4k 30fps 15 Megabits 196mb

https://drive.google.com/open?id=1HeTiQzUASuXjC_2GCIhRZ2xgn55b6hso

Bildqualität mit GPU ist immer noch schlechter als mit CPU (obwohl es in 4k vermutlich kaum auffallen wird).
Oder gibt es da noch andere Profile, die langsamer sind aber es besser machen?

MfG
Rooter

gmb

2018-12-26, 17:28:33

Es halt also nur etwas über ein Jahr gedauert :ugly:

Fast 3 Jahre, AMDs Marketing hat schon Anfang 2016 (https://youtu.be/rI4fzMDDxYg) damit geworben, woraufhin ein Hype ausgebrochen war. Wie so vieles war das damals eine Luftblase.

samm

2018-12-26, 19:36:48

Macht eigentlich Sinn, dass Intel-MAs alte AMD-Marketing-Links aufbewahren, um sie in produkttechnisch bescheidenen Zeiten ausgraben zu können.

gmb

2018-12-26, 20:14:27

Für Leute wie dich macht das immer Sinn, sieht man doch an deiner Reaktion. Dein BIAS-o-Meter zeigt schön auf, wie sehr du auf unangenehme Fakten deines Lieblingsherstellers stehst.

Gebrechlichkeit

2018-12-26, 20:17:37

Bildqualität mit GPU ist immer noch schlechter als mit CPU (obwohl es in 4k vermutlich kaum auffallen wird).
Oder gibt es da noch andere Profile, die langsamer sind aber es besser machen?

MfG
Rooter

Erreicht man endlich, jahre nach dem x265 veroeffentlich wurde die BQ von x264? x265 encodes sahen immer ein weniger verwaschener aus als x264. Wer so erpicht ist, soviel wie moeglich zu sparen .. mit PSNR werden auch dateien im 1.4gb groesse moeglich. Jedoch muss man sich die frage stellen, wieso?

RF25 x265, psnr, medium und aus 50BD werden 1 bis 2gb in ca. 3h
oder mittels x264 quicksync best quality, rf 22 binnen 35min ca. 5gb?¿

REsummiert :

Diese "sicherheits kopien" erstellen thematik, stundenlanges encoieren .. dank threadripper nun 10x filme parallel ... bei den zig streaming seiten, warum, wieso. weshalb?

Die dvd golden era ist vorbei, der gb pro € ist so billig wie noch nie ... warum tut man sich das noch heute an? X264 duerfte auch im jahre 2018 die bessere
bild qualit bieten, x265 sah immer ein bisl verwaschen, unschaarf im vergleich.

lohnt sich net, spart euch das geld. diese hobby encodieren ist fuer den popo, aus meiner sicht. kauft euch eine console und ein paar spiele, da habt ihr mehr von :wink:

deekey777

2018-12-26, 21:31:26

Warum fallt ihr immer auf den Typen herein?

Screemer

2018-12-26, 21:35:51

Fast 3 Jahre, AMDs Marketing hat schon Anfang 2016 (https://youtu.be/rI4fzMDDxYg) damit geworben, woraufhin ein Hype ausgebrochen war. Wie so vieles war das damals eine Luftblase.
Du weißt genau wie ich es gemeint habe. Von Ankündigung von Handbrake bis zur 1.2 hat's knapp über 1 Jahr gedauert. Du bist und bleibst der größte Intel shill des forums.

aufkrawall

2018-12-26, 21:47:52

AMD kann ja nichts für die Release-Zyklen von Handbrake und ffmpeg. ffmpeg 4.0 kam im April und zu der Zeit hatte Handbrake zudem noch auf libav gesetzt.

gmb

2018-12-27, 03:15:51

Du weißt genau wie ich es gemeint habe. Von Ankündigung von Handbrake bis zur 1.2 hat's knapp über 1 Jahr gedauert. Du bist und bleibst der größte Intel shill des forums.

Noch viel schlimmer, AMD hat es vor 3 Jahren höchstpersönlich in einem Videobeispiel angekündigt! Das ist jetzt in Ordnung oder was :rolleyes: Schau dir die Kommentare in dem AMD Video an, die Leute wurden regelrecht verarscht, es wurden jahrelang falsche Hoffnungen geschürt. Das schmeckt dir jetzt natürlich nicht, wird lieber unter den Tisch gekehrt. Es ist wieder einmal bezeichnend für dich, dass du mit Kritik an AMD nicht umgehen kannst.

deekey777

2018-12-27, 08:58:53

Und wie es wirklich war:

Wie schon Intel vor Jahren hat AMD ohne Zustimmung des Handbrake-Entwicklers VCE-Unterstützung in Handbrake reingehackt und diese eigens modifizierte Version in dem Youtube-Video gezeigt. Der Handbrake-Entwickler hat damals eindeutig Stellung gezogen: "Nö."

Irgendwann wurde angekündigt, dass mit 1.2 der Wechsel auf FFMPEG vollzogen wird, im Herbst 2017 hat der gute Michail von AMD FFMPEG um VCE erweitert, die offizielle Implementierung verzögerte sich jedoch (wegen der Nutzervereinbarung), erst gegen Ende 2017 kam VCE offiziell zu FFMPEG. Folge: Mit der Veröffentlichung von Handbrake 1.1 kamen die ersten Entwicklerbuilds mit VCE-Unterstützung (weil schon FFMPEG). Und jetzt ist Handbrake 1.2 offiziell veröffentlicht worden.

Rooter

2018-12-27, 20:26:53

Erreicht man endlich, jahre nach dem x265 veroeffentlich wurde die BQ von x264? x265 encodes sahen immer ein weniger verwaschener aus als x264.Mit dem Unterschied h264 vs h265 habe ich mich noch nicht beschäftigt, mit h265 fange ich evt. auch erst an wenn mal ein Ryzen in meinem Rechner tickt und kein Intel 2500K mehr. :)

Ich rede vom Unterschied h265 CPU vs h265 GPU und da sehe ich ich bei GPU doch ordentliche Artefakte, vor allem im dunklen Himmel über den Häusern.
Die mögen wie gesagt bei 4K vielleicht gar nicht sichtbar sein, dennoch ist die gleich große Datei der CPU die bessere.

AMD kann ja nichts für die Release-Zyklen von Handbrake und ffmpeg. ffmpeg 4.0 kam im April und zu der Zeit hatte Handbrake zudem noch auf libav gesetzt.Was ist denn aktuell die encoding-lib der Wahl? ffmpeg?

MfG
Rooter

aufkrawall

2018-12-27, 21:08:15

Was ist denn aktuell die encoding-lib der Wahl? ffmpeg?

Eher ist so zu formulieren, dass ffmpeg diverse Enkoder usw. als Libs umfasst.

Rooter

2018-12-27, 21:38:20

Eher ist so zu formulieren, dass ffmpeg diverse Enkoder usw. als Libs umfasst.Ich meinte die Wahl zwischen ffmpeg und libav. ;)

MfG
Rooter

aufkrawall

2018-12-27, 22:48:30

Ich sehe keinen Grund, libav ffmpeg vorzuziehen.

Gebrechlichkeit

2019-06-30, 16:40:08

Tests mit Handbrake 1.2 Final:

Fireworks Sample MPEG-4 ca 1.2GB 95 Megabits

http://4ksamples.com/4k-uhd-fireworks-sample/

Test mit CPU h.265(Ryzen 2600X@default) 7 Bilder pro Sekunde. 4k 30fps 15 Megabits 198mb

Test mit NVenc h.265(GTX 1070) 45 Bilder pro Sekunde. 4k 30fps 15 Megabits 196mb

Hab das Roku 4k30 Profil genommen und jeweils 15 Megabits fest eingestellt.

4K Handbrake 1.2

Sorry fuer den Necro, hab aber grad mal den 4670K mit der Source durchgebencht, irgndwie stimmt was nicht mit dem 2600X. Ich habe im Durchschnitt um die 2fps (x265) bei thermal throttelter cpu at 3.5Ghz@100º, vier Kerne.

Haswell kann auf einmal 4K encodieren, mit ca. 25fps und selbst x264 schafft der 4 Kerne um die 6fps+

https://i.ibb.co/CVg6s33/cpu-thermal-cpu-only-x264-quicksync.png (https://ibb.co/CVg6s33) https://i.ibb.co/WvnQD71/cpu-thermal-cpu-only-x264.png (https://ibb.co/WvnQD71) https://i.ibb.co/swvrPNN/cpu-thermal-cpu-only-x265.png (https://ibb.co/swvrPNN) https://i.ibb.co/d0qQFzq/cpu-thermal.png (https://ibb.co/d0qQFzq)

2K Handbrake 1.2

Quicksync ca.26fps (hmm gleich schnell wie 4K?¿)
cpu x264 ca.20fps
cpu x265 ca.7fps

Vorteil 2K = cpu wird bloss 85º kühl

Handbrake 0.10.5 64bit

quicksync 2K, Best Quality. 85fps, Balanced 130fps, Best Speed 130fps

Handbrake 1.2

quicksync 2K, Best Quality. 25fps, Balanced 25fps, Best Speed 25fps

Screemer

2019-06-30, 17:56:35

Das eine ist CPU encoding und das andere läuft über die fixed funktion unit quicksync deiner GPU im haswells.

Gebrechlichkeit

2019-06-30, 19:41:16

Das eine ist CPU encoding und das andere läuft über die fixed funktion unit quicksync deiner GPU im haswells.

Isch weiss, hab ja extra die ver. runs gemacht. Ich frage mich wieso der 2600 bloss 7fps hinklatscht, lohnt sich irgendwie nicht. DDr4, bessere IPC und weitere features die der 2013 Haswell nicht hat... der Unterschiede muesste weitaus groesser ausfallen.

Evtl. liebr gleich den 3900X in Erwaegung ziehen und die kleineren Bureder vermeiden, die sind wohl eher fuer Gaming gedacht.

Screemer

2019-06-30, 20:32:13

fast 3x so schnell ist also nicht genug?

Narolf

2019-07-01, 11:35:11

Badesalz

2019-07-01, 11:43:19

Beim Kodieren steht weiterhin und immernoch, die Qualität im Vordergrund. Nicht die Zeit.

Weil... ein Video mag von einem 2h oder 6h kodiert werden, wird aber anschliessend von Tausenden/Millionen, kummuliert Millionen Stunden angeschaut. Was ist da also wirklich von Bedeutung? Na eben.

dargo

2019-07-01, 11:50:10

Wenn du das Video auf YT hochlädst ist die Qualität nebensächlich da YT diese eh zerstört.

Badesalz

2019-07-01, 11:53:13

Ja. Für YT ist das natürlich zweitrangig.

dildo4u

2019-07-01, 14:11:29

Isch weiss, hab ja extra die ver. runs gemacht. Ich frage mich wieso der 2600 bloss 7fps hinklatscht, lohnt sich irgendwie nicht. DDr4, bessere IPC und weitere features die der 2013 Haswell nicht hat... der Unterschiede muesste weitaus groesser ausfallen.

Evtl. liebr gleich den 3900X in Erwaegung ziehen und die kleineren Bureder vermeiden, die sind wohl eher fuer Gaming gedacht.
Nicht verwunderlich AVX2 ist immer noch Intel Land auch gegen den 3900X.
50% mehr Cores 14 % mehr Leistung.

https://live.staticflickr.com/65535/48169108112_8456d5e7c9_h.jpg (https://flic.kr/p/2goxgE1)ryzen_3000_content_creation-100798895-orig (https://flic.kr/p/2goxgE1) by Gorgul (https://www.flickr.com/photos/56281102@N02/), auf Flickr

Savay

2019-07-01, 14:53:27

50% mehr Cores 14 % mehr Leistung

Kann man IMHO von dem Wert alleine schlecht ableiten und ist auch etwas unlogisch, immerhin wurde die FPU doppelt so breit gemacht.

was man bedenken sollte:
x265 skaliert eh nicht so pralle über die Kerne.
Hängt zudem auch viel vom Profil ab.
1st pass ist auch idR rein ST.

dildo4u

2019-07-01, 14:58:48

16 Kerne scheinen ok zu skalieren die Threadripper rauchen den 2700X.

https://live.staticflickr.com/65535/48169423387_6fe00a328b_b.jpg (https://flic.kr/p/2goyTnM)hadnbarekf (https://flic.kr/p/2goyTnM) by Gorgul (https://www.flickr.com/photos/56281102@N02/), auf Flickr

https://www.tomshardware.com/reviews/amd-ryzen-threadripper-2-2990wx-2950x,5725-9.html

Gebrechlichkeit

2019-07-01, 16:14:51

Erstmal hast du nicht exakt das Selbe verglichen. (dildo4u hat avg Bitrate 15 MBit verwendet)

Aber nehmen wir mal an, dass das keinen großen Unterschied macht, dann haben wir immer noch 2,5 fps gegen 7 fps stehen. Das ist ein Performancesprung von 280% oder anders formuliert, ein 30 Minuten langes 30fps Video zu encodieren würde 6 Stunden mit deiner CPU und 2 Stunden und 8 Minuten plus ein paar Zerquetschte mit dem 2600X brauchen. Wie groß muss der Unterschied denn sein, bevor du ihn als groß genug ansiehst?

Ja so gesehen, habt ihr recht. der 4670 hat genau 1/3 der Kerne des 12ers, jener hat 280-300% mehr Power. Aber der schnellere Ram, die bessere IPC usw. muessten doch dem Ryzen mehr Vorteile geben. Rein "hypotethisch" koennte man sagen, haette der 4670 auch 12 Threads waeren beide gleichauf.

Evtl. liegt es auch am Encoder (Handbrake), via cmd ffmpg evtl. schneller? Habend ie ryzen nicht avx2? Ich habe via AV bessere "fps", mit den Standard Einstellungen.

AV Video Converter
quicksync default @82s / speed = 30fps+
microsoft x264 encoder @144s / speed = 20fps
microsoft x265 encoder @230s / speed = 10fps+

dildo4u

2019-07-01, 16:18:50

Ryzen haben AVX 2 aber es wird nicht so schnell wie bei Intel ausgeführt,dafür explodiert der Verbrauch dort nicht.Ein 9900k wird extrem hungrig wenn man AVX2 Code ausführt.

Der 3900X sollte halt leicht schneller als ein 9900k sein dafür aber nur so viel wie der 2700X brauchen.

https://live.staticflickr.com/65535/48170071806_6fa75557a0_b.jpg (https://flic.kr/p/2goCd8q)Power-1 (https://flic.kr/p/2goCd8q) by Gorgul (https://www.flickr.com/photos/56281102@N02/), auf Flickr

https://live.staticflickr.com/65535/48170069751_fce5dc71c4_b.jpg (https://flic.kr/p/2goCcvZ)HandBrake (https://flic.kr/p/2goCcvZ) by Gorgul (https://www.flickr.com/photos/56281102@N02/), auf Flickr

https://www.techspot.com/review/1730-intel-core-i9-9900k-core-i7-9700k/page3.html

Narolf

2019-07-01, 22:05:55

Ja so gesehen, habt ihr recht. der 4670 hat genau 1/3 der Kerne des 12ers, jener hat 280-300% mehr Power. Aber der schnellere Ram, die bessere IPC usw. muessten doch dem Ryzen mehr Vorteile geben. Rein "hypotethisch" koennte man sagen, haette der 4670 auch 12 Threads waeren beide gleichauf.

Evtl. liegt es auch am Encoder (Handbrake), via cmd ffmpg evtl. schneller? Habend ie ryzen nicht avx2? Ich habe via AV bessere "fps", mit den Standard Einstellungen.

AV Video Converter
quicksync default @82s / speed = 30fps+
microsoft x264 encoder @144s / speed = 20fps
microsoft x265 encoder @230s / speed = 10fps+
Wir vergleichen Core i5 4670 mit Ryzen 5 2600X. Der 2600X hat "nur" 6 Kerne, allerdings mit SMT, die extra Threads haben aber nicht die gleiche Performace wie ein echter Kern. Von 4/4 auf 6/12 ein Leistungssprung um 280% ist imo schon ziemlich sportlich, bin mir nicht so sicher ob ein etwaiger Haswell mit 6/12 die gleiche Leistung zeigen würde.

Und die Unterschiede zwischen Handbrake und AV können verschiedene Gründe haben. Eventuell sind die x265 Versionen nicht die selben, oder die Bildqualität zwischen dem "Roku"-Profil bei Handbrake und den "Standard"-Einstellungen bei AV ist nicht vergleichbar. Das "Roku"-Profil nutzt beispielsweise Encoder Preset: Slow. Wenn AV dagegen Encoder Preset: Fast hat kann das schon der Unterschied sein.

Achill

2019-07-02, 10:48:07

4K Handbrake 1.2

Sorry fuer den Necro, hab aber grad mal den 4670K mit der Source durchgebencht, irgndwie stimmt was nicht mit dem 2600X. Ich habe im Durchschnitt um die 2fps (x265) bei thermal throttelter cpu at 3.5Ghz@100º, vier Kerne.

Haswell kann auf einmal 4K encodieren, mit ca. 25fps und selbst x264 schafft der 4 Kerne um die 6fps+

https://i.ibb.co/CVg6s33/cpu-thermal-cpu-only-x264-quicksync.png (https://ibb.co/CVg6s33) https://i.ibb.co/WvnQD71/cpu-thermal-cpu-only-x264.png (https://ibb.co/WvnQD71) https://i.ibb.co/swvrPNN/cpu-thermal-cpu-only-x265.png (https://ibb.co/swvrPNN) https://i.ibb.co/d0qQFzq/cpu-thermal.png (https://ibb.co/d0qQFzq)

2K Handbrake 1.2

Quicksync ca.26fps (hmm gleich schnell wie 4K?¿)
cpu x264 ca.20fps
cpu x265 ca.7fps

Vorteil 2K = cpu wird bloss 85º kühl

Handbrake 0.10.5 64bit

quicksync 2K, Best Quality. 85fps, Balanced 130fps, Best Speed 130fps

Handbrake 1.2

quicksync 2K, Best Quality. 25fps, Balanced 25fps, Best Speed 25fps

Bitte schau dir doch mal deine eigenen Settings an:
- QuickSync lässt du mit "Balanced" und ohne konkretes Encoder-Profil und -Level laufen
- h264 lässt du in "fast", ohne konkretes Encoder-Profil und -Level und mit Extra-Optionen laufen
- h265 lässt du in "slow", im Main-Profil und abweichenden Extra-Optionen laufen

Damit sind doch deine eigenen Werte schon kaum miteinander zu vergleichen und ich meine damit nicht einmal das Encoding-Ergebnis sondern das man z.B. alles mit "slow" und ähnlich Profilen testet sowie bei HW-Encoding evtl. Quality wählt um sich dem Slow Setting anzunähern.

Ja so gesehen, habt ihr recht. der 4670 hat genau 1/3 der Kerne des 12ers, jener hat 280-300% mehr Power. Aber der schnellere Ram, die bessere IPC usw. muessten doch dem Ryzen mehr Vorteile geben. Rein "hypotethisch" koennte man sagen, haette der 4670 auch 12 Threads waeren beide gleichauf.
[..]

So leicht ist das nicht, der 4670 hat 4 Cores, der 2600X hat 6 Cores - der 4670 hat also 2/3 der Cores vom Ryzen und nicht 1/3. Der Ryzen kann nur mehr Threads gleichzeitig bearbeiten auf den 6 Cores, das bringt aber nur viel (wie auch bei Intel), wenn der Code eines Threads die CPU-Core nicht gut auslasten kann oder z.B. auf Daten warten muss, dann kann der zweite Thread auf dem gleich Core "übernehmen" und in der Zeit "arbeiten" - sehr vereinfacht ausgedrückt.

[..]
Evtl. liegt es auch am Encoder (Handbrake), via cmd ffmpg evtl. schneller? Habend ie ryzen nicht avx2? Ich habe via AV bessere "fps", mit den Standard Einstellungen.

AV Video Converter
quicksync default @82s / speed = 30fps+
microsoft x264 encoder @144s / speed = 20fps
microsoft x265 encoder @230s / speed = 10fps+

Kann man den HandBrake und AV Video Converter einfach so vergleichen, sind die Settings gleich oder wenigsten sehr ähnlich? Wie war die Video-Qualität und -Größe im Vergleich zu HandBrake?

Gebrechlichkeit

2019-07-02, 13:01:25

Das "Roku"-Profil nutzt beispielsweise Encoder Preset: Slow. Wenn AV dagegen Encoder Preset: Fast hat kann das schon der Unterschied sein.

Standard Einstellung bei allen drei "balanced". Mein x265 test lief mit Best Quality (von mir vorher eingestellt). Der Unterschied Best Quality vs Balanced liegen at best bei 5fps. x265 slow lohnt sich sowieso nicht, lieber medium dafuer 10/12bit?

@Achill

Das Roku 4K60 x265 ist so voreingestellt. X265 warum auch immer "slow", x264 "fast" und wenn auf quicksync umstellt "balanced". Und zur Bild Quali. kann ich nichts sagen, da die CPU mit 100º noch aus dem Fenster springt. Hab bloss ca.2min durchlaufen lassen und pi-mal-daumen das ganze notiert :wink:

aufkrawall

2019-07-02, 13:07:36

Ist hier alles OT.

Narolf

2019-07-02, 13:56:21

Standard Einstellung bei allen drei "balanced". Mein x265 test lief mit Best Quality (von mir vorher eingestellt). Der Unterschied Best Quality vs Balanced liegen at best bei 5fps. x265 slow lohnt sich sowieso nicht, lieber medium dafuer 10/12bit?

@Achill

Das Roku 4K60 x265 ist so voreingestellt. X265 warum auch immer "slow", x264 "fast" und wenn auf quicksync umstellt "balanced". Und zur Bild Quali. kann ich nichts sagen, da die CPU mit 100º noch aus dem Fenster springt. Hab bloss ca.2min durchlaufen lassen und pi-mal-daumen das ganze notiert :wink:
Keine Ahnung, welche x265 Presets qualitätsmäßig Sinn machen, ist hier ehrlich gesagt auch nicht Thema. Mir ging es nur darum, dass Leistungsvergleiche nur bei gleichen Einstellungen funktionieren. Ist wie bei Spielebenchmarks, wenn der eine mit 1080p@MaxQ testet und der andere mit 1080p@Low dann sind die Ergebnisse nicht wirklich zu vergleichen.

Ganz generell würde ich dir empfehlen einen Thread in einem passenderen Unterforum aufzumachen. Das ganze ist ein bisschen weit weg von "AMD Hardware Video Encoding".

dildo4u

2019-07-07, 22:49:43

Isch weiss, hab ja extra die ver. runs gemacht. Ich frage mich wieso der 2600 bloss 7fps hinklatscht, lohnt sich irgendwie nicht. DDr4, bessere IPC und weitere features die der 2013 Haswell nicht hat... der Unterschiede muesste weitaus groesser ausfallen.

Evtl. liebr gleich den 3900X in Erwaegung ziehen und die kleineren Bureder vermeiden, die sind wohl eher fuer Gaming gedacht.

AVX Performance scheint zumindest bei Handbrake gefixt.
3700X 65 Watt = 9900k.

https://www.hardwareluxx.de/index.php/artikel/hardware/prozessoren/50163-amds-ryzen-7-3700x-und-ryzen-9-3900x-im-test.html?start=8

https://www.guru3d.com/articles_pages/amd_ryzen_7_3700x_ryzen_9_3900x_review,17.html