Jump to content

Intel Quick Sync Video Unterstützung


Recommended Posts

Quick Sync Video (QSV) ist eine Technologie, mit der sich Videos recht effizient in Hardware transkodieren lassen. Die Integration in FFmpeg hat in letzter Zeit große Fortschritte gemacht. Der DVBViewer Recording Service nutzt FFmpeg, um Streams für Web- und Mobile-Streaming aufzubereiten (Flash, WebM, HLS).

 

Um QSV mit dem DVBViewer Recording Service nutzen zu können, wird ein aktuelles FFmpeg Zeranoe Nightly Build empfohlen:

- win64

- win32

 

Die FFmpeg.exe muss in das DVBViewer-Programmverzeichnis entpackt werden.

 

Außerdem werden entsprechende Presets benötigt, die QSV über FFmpeg nutzbar machen (siehe iphoneprefs.ini und ffmpegprefs.ini im Anhang). Diese müssen in den config-Ordner im DVBViewer-Programmverzeichnis kopiert werden.

 

Anschließend steht QSV über die diversen Streaming-Schienen zur Verfügung (RS Web-Interface, iOS Web-Interface usw.):

qsv_streaming.jpg

 

Benötigt wird mindestens ein Core i Prozessor der 3. Generation (Ivy Bridge).

 

Für QSV gültige Encoder-Geschwindigkeiten (FFmpeg -preset) sind:

- veryfast (höchste Geschwindigkeit)

- faster

- fast

- medium (ausgewogenen Qualität und Geschwindigkeit)

- slow

- slower

- veryslow (beste Qualität)

 

Andere Encoder-Geschwindigkeiten führen zu einem Fehler in FFmpeg.

 

 

Anmerkungen zu den Presets:

Für sämtliche QSV Presets wird AAC Audio verwendet. h.264_qsv + libmp3lame führt unerklärlicherweise zu einem dumpfen Klang (unabhängig vom Container). AAC ist mittlerweile aber sowieso die bevorzugte Audio Technologie.

Deinterlacing und Scaling werden in Software über die entsprechenden Video Filter in FFmpeg (Yadif/libswscale) realisiert. Die VPP Eigenschaften der Quick Sync Hardware können aktuell dafür nicht genutzt werden.

ffmpegprefs.ini

iphoneprefs.ini

  • Like 1
Link to comment
  • 1 month later...

Hallo,

 

Habe versucht das nach dieser Anleitung umzusetzen, allerdings bekomme ich kein Bild, wenn ich ein transcoding profil mit quick sync wähle. Wo kann ich nachsehen an was es liegt, gibt es hier eine log Datei?

 

Hoffe es kann mir jemand weiterhelfen. Quicksync im allgemeinen läuft, habe es mit Handbrake getestet.

 

Danke schon mal für eure Hilfe :)

Link to comment

Gibt es vielleicht die Möglichkeit, die qsv profile als auch die entsprechende ffmpeg version in das nächste Release einzubauen?

 

Und falls ja, wäre es möglich ein transcoding profile einem Web Interface Benutzer zuzuordnen, somit brauchen die Clients keine Änderungen am aufruf der URL durchführen und bekommen den Stream automatisch mit dem Ihnen zugeordneten Transcoding profil geliefert.

 

Das wäre natürlich echt toll insbesondere für schwächere Clients, wie z.B. Kodi auf dem Fire TV Stick. So kann z.B. Das qualitativ hochwertige deinterlacing auf dem Server mit quick sync Unterstützung (also auch auf Stromsparenden Servern) ohne hohe CPU Last durchgeführt werden und der Kodi Client bekommt dann einen 1080p/720p Stream, welches selbst ein FireTV Stick einfeach dekodieren kann.

 

Wäre aber schon super Glücklich, wenn mich jemand bei der manuellen Umsetzung oben unterstützen könnte :)

Edited by Vlaves
Link to comment

Die ffmpeg Version die du mit RS 1.33 Setup heruntergeladen werden kann, unterstützt die Hardwarebeschleunigung via Quick Sync Video.

Aber die ffmpegprefs.ini und/oder iphoneprefs.ini musst du selber in das (DVBViewer Verzeichnis)\config\ kopieren.

 

Aber Quick Sync Video geht mit FFmpeg nicht mit allen Prozessoren, sondern nur mit neueren

Sandy Bridge und älter gehen nicht.

 

Wenn du die Ausgabe von FFmpeg sehen willst Transcodier einfach mal eine Aufnahme.

 

test.cmd

@echo off
"C:\Program Files (x86)\DVBViewer\ffmpeg.exe" -i "%~f1" -f mpegts -pat_period 0.2 -vcodec h264_qsv -bufsize 3200k -maxrate 1600k -look_ahead 0 -q 26 -g 50 -map 0:a:0 -map 0:v:0 -preset veryfast -tune film -vprofile main -level 30 -acodec aac -ab 96k -ar 44100 -ac 2 -async 1 -y "%~d1%~p1%~n1.mp4"
pause

 

erstellen und eine .ts Aufnahme drauf ziehen.

Link to comment

Erfüllt deine CPU die Hardware Anforderungen ?

Schätze mal, es liegt vielleicht daran ...?

Wenn Du z.b. noch eine Intel CPU mit Sandy Bridge nutzt ("2" Generation) wird es nicht funktionieren !

Erst ab Ivy Bridge ("3" Generation) funktioniert die Hardware Beschleunigung.

 

Siehe :

http://www.DVBViewer.tv/forum/topic/57581-streaming-mit-gpu-beschleunigung/?p=442293

Edited by feedzapper
Link to comment

Habe jetzt die Batch Datei getestet und es hat funktioniert, die mp4 wird erzeugt. Muss wohl an meiner ffmpegprefs.ini liegen, denn im Web Interface funktioniert es dann nicht. Habe als Profil das TS HD profil ausgewählt. Aber wie ich gesehen habe, unterscheiden sich auch die Aufrufe des ffmpeg Befehls in der inii und der Batch Datei.

 

Meine CPU ist der Celeron N3150, dieser unterstützt lauf Intel quick sync. Mit Handbrake funktioniert quicksync ja auch.

 

Kann mal jemand hier eine eventuell geänderte ini posten oder mir sagen, wo ich nachschauen kann was beim Aufruf durch den Rec.Service schief geht?

Link to comment

Ich habe ein paar Befehle entfernt, weil ich zu faul war, für die Variablen richtige Werte zu setzen.

 

Nur die Profile mit (QSV) sind die Hardware beschleunigten.

 

Und zu TS, mit welchem Client testest du? Das geht nicht im Webbrowser.

Geht die normale Variante? (ffmpegprefs.ini im Installationsverzeichnis\config (!!!) löschen dann wird das Original wieder generiert)

Link to comment

Ok, habe das ganze nun noch mal testen können. Die ffmpegprefs.ini gelöscht und den service neu gestartet. Im webinterface das profil TS 3600 gewählt un im Windows Mediaplayer abgespielt. Der Stream wurde ohne probleme widergegeben.
Danach die ffmpegprefs.ini vom post weiter oben genommen und im Ordner Installationspfad\Config ersetzt. Service negetsartet.
Diesmal das TS 3600 qsv Profil gewählt. ffmpeg.exe startet zwar, beendet sich aber nach einer sehr kurzen Zeit.
Gibt es irgendwo ein log vom ffmpeg process wenn es vom Recording Service aufgerufen wird?

Edited by Vlaves
Link to comment

Web Interface -> Configuration -> UPnP -> tick UPnP debug logging -> Save. After that the FFmpeg debug output (besides various other things) is written to the file svcdebug.log in the configuration folder.

 

Please note that this setting is reset automatically to "off" when the RS is stopped.

 

Oha, habe mich bei der Sprache vertan. Die Übersetzung:

 

Web Interface -> Konfiguration -> UPnP -> UPnP Debug Logging -> Speichern. Danach wird die FFmpeg Debug-Ausgabe (neben verschiedenen anderen Sachen) in die Datei svcdebug.log im Konfigurationsordner geschrieben.

 

Bitte beachten, dass die Einstellung beim Stoppen des RS automatisch auf "aus" zurückgesetzt wird.

Link to comment

Fang den Test mal mit unverschlüsselten nicht HD Sendern an. Und einer eher niedrigen Datenrate z.B. [Flash Low 800 kbit (QSV)] und dem Webbrowser als Client.

Link to comment

analyse von mir zum SVCDEBUG

 

fmmpeg stört sich an den : -threads auto in der command line

Normalerweise wird das ja mit einer Variable übergeben und ist dann wohl abhängig von den Kernen des Prozessors.

Aber es ist in der Regel ein numerischer Wert (1-4) und kein "auto"

 

-> -threads {threads} (So ist es jedenfalls bei mit in der command line voreingestellt)

 

Hast Du die Option von Hand gesetzt ? (-threads auto)

 

Dann solltest Du "-tune film" mal ganz rausnehmen für QSV. Bei meinen älteren ivy bridge (4 Generation) gabs da auch immer Fehlermeldungen - die gibts hier auch im Log bei Dir.

Link to comment

-threads {threads} am besten ganz raus nehmen. Aus der vom DVBViewer erstellten Version wurde das gestrichen. Da aktuelle 32 Bit FFmpeg Versionen damit Probleme haben wenn da ein Wert gesetzt wird.

 

Darum setzt RS 1.33 da wenn vorhanden nur noch auto. Weil das der einzige andere Wert ist der da keine Probleme gemacht hat.

Und das gezielte Setzen bei aktuellen FFmpeg Versionen keinen wirklich voreilt mehr gegenüber dem Standard in FFmpeg liefern.

Link to comment

und wenn es immer noch nicht funktionieren sollte :

 

-report in der commandline von ffmpeg.exe schreibt bei jedem Start die kompletten Console Ausgaben (verbose) von ffmpeg in ein LOG File. Dieses wird bei jedem Aufruf von ffmpeg.exe erneut angelegt und wird ins Verzeichnis von ffmpeg.exe geschrieben.

Im Format "ffmpeg-JAHR_MONAT_TAG-STUNDE_MINUTE_SEKUNDE.log"

sorry , nur so sieht man was erfolgreich verarbeitet wurde an den Optionen und Werten; und was zum Fehler führte.
Link to comment

Hier mal die Version von oben ohne -threads {threads}

attachicon.gifffmpegprefs.iniattachicon.gifiphoneprefs.ini

 

 

 

und wenn es immer noch nicht funktionieren sollte :

 

-report in der commandline von ffmpeg.exe schreibt bei jedem Start die kompletten Console Ausgaben (verbose) von ffmpeg in ein LOG File. Dieses wird bei jedem Aufruf von ffmpeg.exe erneut angelegt und wird ins Verzeichnis von ffmpeg.exe geschrieben.

Im Format "ffmpeg-JAHR_MONAT_TAG-STUNDE_MINUTE_SEKUNDE.log"

sorry , nur so sieht man was erfolgreich verarbeitet wurde an den Optionen und Werten; und was zum Fehler führte.

 

Vielen Dank für eure unterstützung. Habe nun die neuen ini Dateien genommen und die alten ersetzt. Hat leider nicht funktioniert :(

Also das gewünschte profile noch ein "-report" als argument hinzugefügt.

Eine frische "svcdebug.log" und die "ffmpeg-20160610-100339.log" habe ich hier angehängt. Ich hoffe dass ihr mit diesen Infos weiterhelfen könnt.

Danke im voraus für die Unterstützung hier :)

svcdebug.log

ffmpeg-20160610-100339.log

 

UPDATE: Habe nun den parameter "-maxrate", "scale={scalex}:{scaley}"" und "-tune film" entfernt um diese auf default zu lassen, jetzt schein es keine Fehler mehr bei den encoding parametern zu geben, wie in den oberen logs, jetzt steht da was wie "es sollte mindestens ein Outputfile angegeben sein", da hört leider mein Verständnins für ffmpeg auf :(

 

Hoffe, das hilf noch mehr für die Diagnose. Danke noch mal :)

svcdebug.log

ffmpeg-20160610-101555.log

Edited by Vlaves
Link to comment

Ich habe Grade keine Idee warum es mit Dateien bei dir klappt aber nicht beim streaming.

 

Nur um Sicher zu gehen du testest immer mit HD (H.264) Sendern. Hast du das auch bei den Aufnahmen gemacht?

Hast du mal SD (MPEG2) Sender Probiert?

 

Und wie lange benötigt das Transcorieren eines einstündigem Films? Wenn das nicht deutlich unter einer Stunde ist könnte auch dass das Problem sein.

Link to comment
  • 3 months later...

Bei mir lief es auch nicht... Hab dann die ffmpeg.exe vom Emby Server genommen, damit gehts ;)

Aber stelle kein Performancegewinn fest, CPU Auslastung ist mit und ohne (was mich sehr erstaunt) Quick Sync bei 25-35%.

Edited by Wired Life
Link to comment

Schade dass man hier bloß so kurze Zeit editieren kann...

Alsooo, hab noch mal länger getestet und man merkt doch einen Unterschied.

Wenn ich die Encoder-Geschwindigkeit auf slow, slower, very slow stelle geht die Auslastung ohne Quick Sync auf 70% und höher,

mit Quick Sync liegt sie immer, egal mit welcher Geschwindigkeit maximal bei 35%.

Meine CPU ist ein Intel G4500.

 

Wenn ihr möchtet kann ich ja die ffmpeg.exe von Emby mal hochladen oder ihr ladet euch Emby selbst und zieht sie euch aus

C:\Users\EUER BENUTZERNAME\AppData\Roaming\Emby-Server\ffmpeg\20160410

Link to comment
  • 2 months later...

Für alle die es vielleicht interessiert ...

 

QSV->QSV pipeline transcoding funktioniert nun seit der letzten ffmpeg-devel Version (jedenfalls bei mir) ;-)

vielleicht ganz interessant für die Leute, die mit der CPU nicht so gut motorisiert sind ?!

 

siehe :

https://github.com/FFmpeg/FFmpeg/commit/03cef34aa66662e2ab3681d290e7c5a6634f4058

 

Die (als Beispiel) aufgeführte ffmpeg commandline in der ffmpegprefs.ini sieht bei mir folgendermaßen aus:

[Flash High 1800 kbit Intel QSV HWACCEL]
Cmd=-analyzeduration 1500k {offset} {realtime} -hwaccel qsv -i "{infile}" -f flv -vcodec h264_qsv -bufsize 1500k -b:v 1500k -maxrate 1500k -look_ahead 0 {framerate} -map 0:0 -map 0:1 -preset 7 -profile:v high -level 41 -acodec libfdk_aac -ab 160k -ar 48000 -ac 2 -async 1 -y "{outfile}"
maxWidth=1280
maxHeight=720
MimeType=video/x-flv
Ext=.flv
Zu beachten ist, dass KEINE Filter zum Skalieren eingefügt werden dürfen (-vf), auch nicht das ändern der GOPs (-g).
Desweiteren :
wenn man 1920x1080i decodiert, bekommt man auch 1920x1080i raus.
Dito für interlace/progressive Inhalte in<->out
Was natürlich alles bei low Bitrates nicht so vorteilhaft ist.
Die maxWidth/maxHeight Werte finden hier keinerlei Verwendung
Edited by feedzapper
Link to comment
  • 2 weeks later...

Schade dass man hier bloß so kurze Zeit editieren kann...

Alsooo, hab noch mal länger getestet und man merkt doch einen Unterschied.

Wenn ich die Encoder-Geschwindigkeit auf slow, slower, very slow stelle geht die Auslastung ohne Quick Sync auf 70% und höher,

mit Quick Sync liegt sie immer, egal mit welcher Geschwindigkeit maximal bei 35%.

Meine CPU ist ein Intel G4500.

 

Wenn ihr möchtet kann ich ja die ffmpeg.exe von Emby mal hochladen oder ihr ladet euch Emby selbst und zieht sie euch aus

C:\Users\EUER BENUTZERNAME\AppData\Roaming\Emby-Server\ffmpeg\20160410

Danke für den tip mit der ffmpeg von Emby, betreibe beides auf dem Server.

Kannst du hier vielleicht auch noch deine ini-Dateien posten?

Danke :)

Link to comment
  • 1 month later...

 

QSV->QSV pipeline transcoding funktioniert nun seit der letzten ffmpeg-devel Version (jedenfalls bei mir) ;-)

 

Ohne VPP finde ich das noch recht sinnfrei. Allerdings gibt es in dieser Richtung bereits Bestrebungen, siehe hier. Im aktuellen 3.2.2 Release sehe ich das aber noch nicht. Allerdings ist auch mit SW-Dekodierung und SW-VPP die CPU-Last recht niedrig...

Link to comment
  • 1 month later...

So hab es ans Laufen bekommen:

 

[HEVC_QSV 720p]
Cmd=-analyzeduration 1500k {offset} {realtime}  -i "{infile}" -c:v hevc_qsv -load_plugin hevc_hw -f mpegts -pat_period 0.2 -vcodec hevc_qsv -load_plugin hevc_hw -q 28 -map 0:0 -map 0:1 -vf "yadif=0:-1:1, scale={scalex}:{scaley}" -preset veryslow -acodec aac -ab 64k -ar 44100 -ac 1 -async 1 -y "{outfile}"
maxWidth=1280
maxHeight=720
MimeType=video/mp4
Ext=.mp4

 

Qualität akzeptabel bei durchschnittlich unter 1000kbit, mein G4560 Pentium Kaby Lake liegt bei ca. 20% Last

M3U Playlist auf Handy kopiert, IPTV App, unterwegs mit 720p fernsehen...:bye:

Link to comment

Läuft bei mir auch prima auf dem Heimrechner b.z.w. auf der Gegenseite über OPENVPN.

Nur leider mit VLC only. Wird im WEBBROWSER (CHROME) leider nicht abgespielt (WEBM) Plugin Player ?

Keine Ahnung was Chrome für MP4 als Player benutzt ... ?

Den -q Faktor kann man ja schön anpassen, je nachdem welche Bandbreite zur Verfügung steht.

 

 

Edited by feedzapper
Link to comment

So, habe nun ein frisch aufgesetztes System mit DVBViewer RS 1.33.2.0 und soweit nun alle Sender eingerichtet. Würde jetzt gerne das Hardware transcoding einrichten.

Meine CPU ist ein Intel Celeron N3150 4x 1,6 GHz. Laut Intel unterstützt die CPU quick sync und ich würde nun gerne das Transcoding per quicksync nochmal versuchen einzurichten.

 

Könnte hier jemand bitte eine funktionierende ini Datei und eventuell auch die verwendete ffmpeg.exe posten.

 

Vielen Dank für eure Unterstützung im Voraus :)

 

Gruß

Vlaves

Link to comment

Ich aktualisiere ffmpeg bei mir öfter mal auf ein aktuelles Release, aktuell 3.2.2 von hier.

 

Hier mal meine aktuellen Presets für QSV:

[HLS HD (QSV)]
Cmd=-analyzeduration {analyzeduration} {offset} -i "{infile}" -f mpegts -vcodec h264_qsv -idr_interval 0 -force_key_frames "expr:gte(t,n_forced*{segdur})" -look_ahead 0 -q 24 {framerate} -map 0:a:0 -map 0:v:0 -vf "yadif=0:-1:1, scale={scalex}:{scaley}" -preset {vpreset} -tune film -vprofile high -level 41 -acodec aac -ab 128k -ar 44100 -ac 2 -async 1 -y "{outfile}"
maxWidth_IPhone=1280
maxHeight_IPhone=720
maxWidth_IPad=1280
maxHeight_IPad=720

[HLS Web (QSV)]
Cmd=-analyzeduration {analyzeduration} {offset} -i "{infile}" -f mpegts -vcodec h264_qsv -force_key_frames "expr:gte(t,n_forced*{segdur})" -bufsize 1400k -maxrate 600k -look_ahead 0 -q 28 {framerate} -map 0:a:0 -map 0:v:0 -vf "yadif=0:-1:1, scale={scalex}:{scaley}" -preset {vpreset} -tune film -vprofile high -level 41 -acodec aac -ab 48k -ar 44100 -ac 1 -async 1 -y "{outfile}"
maxWidth_IPhone=512
maxHeight_IPhone=288
maxWidth_IPad=512
maxHeight_IPad=288

Oft hat man aber andere Anforderungen an Qualität und Bitrate. Was bei obiger HD Variante nicht verwendet wird ist der -maxrate Parameter. Es wird lediglich ein konstanter Quantizer verwendet. Dadurch hat man eine gleichbleibende Qualität, aber je nach Komplexität der Szenen sehr variable Bitraten. Mit Edge als Client kommt es da gerne zu Abbrüchen. Spielt aber glaub mit der aktuell veröffentlichten Version vom RS noch keine Rolle, weil da Edge sowieso noch gar nicht funktioniert. Dennoch ist der maxrate Parameter empfehlenswert.

 

Es ist aber generell schwierig, sinnvolle Werte für Quantizer und maxrate zu finden. Ein kleiner Quantizer bedeutet eine hohe Datenrate. Ist die maxrate sehr niedrig gewählt, hat man quasi eine konstante Datenrate bei maxrate.

Link to comment

Danke für die schnelle Antwort :) Wie würde denn die ini aussehen um den TS Stream auf 720p mit rund 5MBit oder eben sehr guter Qualität zu bringen?

Ich möchte eigentlich die gute Auflösung behalten, am liebsten wäre mir ein 1080p stream der auf den Server deinterlaced wurde.

 

Vielen Dank für die Hilfe im voraus :) 

Edited by Tjod
Es ist koplett unnötig den gesamtn Beitrag über sinem eigenen zu Zitieren.
Link to comment

Eine Beschreibung zu generellen anpassen gibt es da:

http://www.DVBViewer.tv/forum/topic/57581-streaming-mit-gpu-beschleunigung/

 

Und die Auflösung sollte ja nicht so schwer zu finden sein (Width und Height) ;)

Aber generell hast die Wahl bessere Auflösung oder Qualität bei gleicher Datenrate oder höhere Datenrate. Und etwas kannst du noch mit höherer Prozessorlast raus holen. Also etwas höhere Qualität oder Auflösung bei gleicher Datenrate durch höhere Prozessor Auslastung.

 

Was für dich da am besten aussieht musst du selber ausprobieren. Und wenn die Datenrate fest ist würde ich mich nicht bei der Auflösung festlegen. Und mit der CPU Auslastung kannst du bei der GPU unterstützten Geschichte hier im Topic nichts machen, Das hängt also nur von der Grafikkarte und eventuell deren Treiber ab.

Link to comment
  • 3 weeks later...
Am 27.2.2017 um 17:23 schrieb feedzapper:

Läuft bei mir auch prima auf dem Heimrechner b.z.w. auf der Gegenseite über OPENVPN.

Nur leider mit VLC only. Wird im WEBBROWSER (CHROME) leider nicht abgespielt (WEBM) Plugin Player ?

Keine Ahnung was Chrome für MP4 als Player benutzt ... ?

Den -q Faktor kann man ja schön anpassen, je nachdem welche Bandbreite zur Verfügung steht.

 

 

 

Mit dem Hevc Codec wird das auch nicht im Browser laufen, der wird im Moment afaik von keinem Browser unterstützt.

Trotzdem war mir Hevc wichtig, da noch mal geringere Datenrate.

Mein Kaby Lake enkodiert den Sender bei 20% Last, mein Note 4 Handy dekodiert das hardwarebeschleunigt, also nur geringe Akku Belastung.

Playliste der Sender vorher aufs Handy, vom Playstore IPTV App und Mx Player. Schönes Bild, Amoled sei Dank. :dvbviewer:

Link to comment

Naja, da kann man mit Leben (VLC) only

Ich habe hier seit Januar VDSL100 mit 40 mb up

Die Gegenseite hat leider nur ADSL16000 

SD läuft alles nun über den RTSP Server prima mit der Gegenseite und DVBViewer als Client. (Datenraten so max. 7,5 m/bits bei SD)

HD - problematisch !  Die öffentlich Rechtlichen funktionieren leider nicht -> Bitrate zu hoch (ca.15M/bits 1280x720 mit progressive) 

HD-Plus teilweise (je nach Sender 1920x1080 interlace)

In diesem Zusammenhang habe ich festgestellt, dass es auch Probleme gibt, höhere Bitraten mit dem Recording Service und ffmpeg zu Streamen per Transcoding.

Sei es nun mit x264 oder x265 per QSV oder per Software Encoding

Insbesondere bei Auflösungen von 1920x1080

Habe es zunächst dem " nur" ADSL16000 auf der Gegenseite geschuldet.

Was aber wohl nur teilweise zutrifft.

Die Grenze liegt wohl so bei 5 Mbit/s alles darüber, wird problematisch beim transcoden mit ffmpeg. Es läuft nicht stabil über einen längeren Zeitraum.

Da ich zunächst den OPENVPN Tunnel in verdacht hatte, habe ich die Tests im eigenen LAN von Rechner zu Rechner noch einmal durchgeführt.

Mit dem selben Ergebnis.

Es gab immer wieder Freezes des Streams. Sei es im Browser mit Flowplayer,  oder mit dem VLC Player als Referenz.

Die CPU Belastung lag bei QSV hier bei unter 8% (Intel Skylake 6700)

Bei ffmpeg compiliere ich mir immer den aktuellen trunk, nun auch mit aktueller Skylake Unterstüztung -> GCC 6.3 und aktuellem cross Compiler MinGW 5.0.1

 

-> https://github.com/rdp/ffmpeg-windows-build-helpers

Edited by feedzapper
Link to comment

Kann ich so bestätigen. "-q 14" läuft noch, bei "-q 12" steigt er nach einer gewissen Zeit aus. Mir persönlich reicht "-q 28" für Handygucken, am 55" TV kann man ja dann auf 18 stellen, höher macht wohl kaum Sinn.

Link to comment

Q-factor ist auch immer leider so eine Sache. Da gibt es zeitweise der maßen peeks in der Datenrate nach oben beim encoden :-(

Glaube Bitrate orientiert zu encoden ist meistens immer der bessere weg ?!

Dort kann man die maximale Bitrate genau einstellen

Für deinen HEVC QSV Stream würde der ffmpeg Eintrag dann ungefähr so aussehen,  wobei man dann die Datenrate beliebig an seine Bedürfnisse anpassen kann :

 

[HEVC_QSV HD 5600k]
Cmd=-analyzeduration 1500k {offset} {realtime} -i "{infile}" -c:v hevc_qsv -load_plugin hevc_hw -f mpegts -pat_period 0.2  -bufsize 10900k -b:v 5440k -maxrate 5440k -g 50 -map 0:0 -map 0:1 -vf "yadif=0:-1:1, realtime, scale={scalex}:{scaley}" -preset 1 -tune film -acodec libfdk_aac -ab 160k -ar 48000 -ac 2 -async 1 -y "{outfile}"
maxWidth=1920
maxHeight=1080
MimeType=video/mp4
Ext=.mp4

 

 

 

Edited by feedzapper
Link to comment

Hab deine Einstellungen einmal ausprobiert, "-acodec libfdk_aac" wollte nicht,  "-acodec aac" ging....mein ffmpeg build scheint wohl ein anderes zu sein.

 

Bei diesen Bitraten ab 5000kbit habe ich sporadisch Aussetzer.

 

Die Bitrate per -maxrate zu beschneiden ist meiner Meinung nach so eine Sache. Peaks, die der Encoder ohne maxrate produziert,

sind ja nur ein Zeichen dafür, dass er für eine bestimmte Szene eine gewisse Datenrate braucht, um eine gewisse Qualität zu produzieren.

Wenn ich nun die Peaks glätte/abschneide, habe ich immer eine schwankende Bildqualität. Ruhiges Bild=gute Qualität, bewegtes Bild=weniger gute Qualität. Dieses Schwanken der Bildqualität empfinde ich als störend.

Bei 5000kbit merkt man das vielleicht nicht so sehr, ich bei 1000kbit aber schon. Also bleibe ich lieber bei einem constant rate factor, um diesem Schwanken aus dem Weg zu gehen. Wenn ich natürlich nur einen begrenzten DSL Upload habe, wird es kritisch, aber selbst da sollte ein -q 28 noch ein flüssiges 720p Bild mit HEVC liefern, das akzeptabel ist. Also hier noch mal mein Profil mit CRF:

 

[HEVC_QSV 720p CRF 28]
Cmd=-analyzeduration 1500k {offset} {realtime}  -i "{infile}" -c:v hevc_qsv -load_plugin hevc_hw -f mpegts -pat_period 0.2 -vcodec hevc_qsv -load_plugin hevc_hw -q 28 -map 0:0 -map 0:1 -vf "yadif=0:-1:1, scale={scalex}:{scaley}" -preset veryslow -acodec aac -ab 64k -ar 44100 -ac 1 -async 1 -y "{outfile}"
maxWidth=1280
maxHeight=720
MimeType=video/mp4
Ext=.mp4

 

Läuft bei mir bombenstabil. An dem "-q" Faktor soll dann jeder selbst rumspielen (14-28), bis die Leitung schlapp macht.  

 

Link to comment
  • 1 month later...

Aus dem ffmpeg-next (3.3) Changelog:

Intel QSV video scaling and deinterlacing filters

Könnte interessant werden. Entsprechende Builds und CLI habe ich mir noch nicht angeschaut...

Link to comment

Ich habe eine J3160 CPU die Intel Quick Sync unterstützt. Jedoch geht es nicht. Musd man da was extra installieren? Habe Win7 laufen.

Link to comment
×
×
  • Create New...