Transkodieren mit Nvidia Kepler Graka unter Linux mit ffmpeg... Es geht

  • Zitat

    Das einzige was noch besser wäre wär ein richtiges Ausgabeplugin das on the Fly transkodiert und mit dem man auch via HTTP Request umschalten kann ohne das er den Transkodier Prozess neu starten muss.


    Vielleicht liest ja hier einer von den Ausgabe Plugin Profis mit und baut das mal eben kurz ;) Ich beteilige mich dann auch mit einer hübschen Mediengalerie für den Browser.


    Naja, interessant ist das schon (wobei das schon viel Zeit brauchen wird), aber ich würde das eher nicht als Ausgabeplugin machen, sondern eher so eine Art Plugin, dass die Aufnahmen und die aktuellen Sender, als segmentierte TS oder MP4 transcodiert. (Also so eine Art vompserver plugin, nur http basiert und mit Transcoding und Segmentierung mit Clients entweder nativ oder Javascript).
    Das Problem sind hier eher die vielen Standards Samsung TV wollen noch die alten HAS oder HLS Standards, moderne Browser und Android TV (z.B. Sony) kann man über die MediaSourceExtensions von HTML5 bedienen oder nativ über MediaCodecs, aber das sind dann entweder MP4 oder TS Container. (Bei Segmentierung kann man leider ffmpeg nicht zum muxen nehmen, da es das nicht unterstützt). Zusätzlich gibt es noch ein großes Codec Wirrwar was die einzelnen Devices unterstützen.....


    Aber viel brennender Interessiert mich, habt ihr mal geschaut ob das parallel zu einem über VDPAU laufenden SoftHDDevice in vernüftiger Performance läuft???


    Marten

    vdr experimental, Femon, vdr live, acpi-wakeup, vompserver, undelete, epgsearch, vdr-burn, Raspberry Pi und Vompserver Windows Client (build from git)

  • Aber viel brennender Interessiert mich, habt ihr mal geschaut ob das parallel zu einem über VDPAU laufenden SoftHDDevice in vernüftiger Performance läuft???


    Ich hab da keinen Unterschied festgestellt.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Naja, interessant ist das schon (wobei das schon viel Zeit brauchen wird), aber ich würde das eher nicht als Ausgabeplugin machen, sondern eher so eine Art Plugin, dass die Aufnahmen und die aktuellen Sender, als segmentierte TS oder MP4 transcodiert. (Also so eine Art vompserver plugin, nur http basiert und mit Transcoding und Segmentierung mit Clients entweder nativ oder Javascript).
    Das Problem sind hier eher die vielen Standards Samsung TV wollen noch die alten HAS oder HLS Standards, moderne Browser und Android TV (z.B. Sony) kann man über die MediaSourceExtensions von HTML5 bedienen oder nativ über MediaCodecs, aber das sind dann entweder MP4 oder TS Container. (Bei Segmentierung kann man leider ffmpeg nicht zum muxen nehmen, da es das nicht unterstützt). Zusätzlich gibt es noch ein großes Codec Wirrwar was die einzelnen Devices unterstützen.....


    Ich hab da ja so eine Webapp Programmiert, mit der man über Streamdev auch TV oder Aufnahmen ansehen kann. Was mich dabei stört, ist das ich IOS nicht bedienen kann, da hier die angesprochene Segmentierung verlangt wird und die langsamen Umschaltzeiten. Das Codec Wirrwarr ist gar nicht so schlimm. Eigentlich benötigt man nur x264 und Webm. Damit bedient man schon mal alles außer IOS (IE mit Webm Plugin von Google, Edge hab ich (noch) nicht). Chrome nimmt übrigens auch MKV


    Ich wünsche mir so ein Plugin, damit VDR eine eigene Lösung für Mobiles Fernsehen anbieten kann. Das funktioniert mit meiner App sehr gut (ich nutze sie täglich z.B. zum Nachrichten schauen beim Zähneputzen), ist aber wie gesagt verbesserungswürdig. Jetzt mit NVENC kann man schon mal schwachbrüstigere Server dafür nutzen. TV Geräte interessieren mich hier weniger. Da kann man auch einen RPI oder ähnliches als Client anschließen oder meine App mit Chromecast nutzen (ist eher nur zum Aufnahmen schauen gut TV geht auch, man kann ja aber nicht umschalten).


    Vielleicht kann man ja auch Streamdev beibringen bei Nutzung von Externremux auf Befehl umzuschalten. Aktuell muss ich immer den Stream anhalten und einen neuen starten, was auch schon Probleme macht und ca. 30 Sekunden dauert.

    Grüße


    Hannemann

  • Du hast doch eine Karte die das unterstützt. Mach doch bitte mal einen Test :)


    Habe in den "11W-PC"-Bauvorschlag der c't die MSI aus 7/16 eingebaut. FFMPEG nach schon genannter Anleitung von NVIDIA gebaut.


    Die Ergebnisse:


    Allerdings gibt es Unterschiede, da nicht alle Optionen von nvenc(_h264) bei nvenc_hevc angenommen werden (?). Der Vergleich der Optionen sagt mir nichts

    HD-VDR 1&2 : Asrock N68C-S UCC, ASUS EN210 Silent, Boot IDE CF-Card, /srv auf SATA Samsung 3TB
    HD-VDR 1 : Sempron145, yavdr 0.4, TeVii S480 V2.1 DVBs2 Dual
    HD-VDR 2 : Sempron140, yavdr 0.5, DD Cine S2 V6.5 + DuoFlex S2
    Server (im Aufbau): Asrock B75M R2.0 mit i5-3470T sowie Zotac GT970 & DD Cine S2 V6.5 für Gastsysteme
    - Host: Manjaro-XFCE mit 4.4er Kernel mit qemu und virt-manager

  • Cool... Danke.
    Geht ja recht fix. Ich hätte erwartet, das es wesentlich länger dauert als nvenc_h264.
    Und wie ist die Qualität und Dateigröße im Verglich zu der h264 Datei?

    Grüße


    Hannemann

  • Und wie ist die Qualität und Dateigröße im Verglich zu der h264 Datei?


    Die Größe habe ich im Logauszug mit angegeben, z.B.

    Code
    video:86137kB


    Die hevc-Datei ist etwas kleiner, wobei die Optionen allerdings nur ähnlich sind. Daher sollte man die gleichen Optionen nehmen, wenn man die Qualität (subjektiv) vergleicht, zumal interlaced-Material meiner Meinung nach für hevc auch nicht so gut ist.
    Vllt. sollte man eher 1080p-Material für die Performancevergleiche (NASA oder NFL Highlights fallen mir ein) nehmen und dann bestimmte Bilder nach Kriterien (wie Bewegung, Farbtreue, Schärfe von Logos/Einblendungen usw.) herausnehmen.

    HD-VDR 1&2 : Asrock N68C-S UCC, ASUS EN210 Silent, Boot IDE CF-Card, /srv auf SATA Samsung 3TB
    HD-VDR 1 : Sempron145, yavdr 0.4, TeVii S480 V2.1 DVBs2 Dual
    HD-VDR 2 : Sempron140, yavdr 0.5, DD Cine S2 V6.5 + DuoFlex S2
    Server (im Aufbau): Asrock B75M R2.0 mit i5-3470T sowie Zotac GT970 & DD Cine S2 V6.5 für Gastsysteme
    - Host: Manjaro-XFCE mit 4.4er Kernel mit qemu und virt-manager

  • 720p ginge auch, sollte halt nicht interlaced sein.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Zitat

    Ich hab da keinen Unterschied festgestellt.


    Und softhddevice hat über vdpau h264 dargestellt. Lief beim transcodieren die dekodierung von h264 auch über vdpau?


    Zitat

    Ich hab da ja so eine Webapp Programmiert, mit der man über Streamdev auch TV oder Aufnahmen ansehen kann. Was mich dabei stört, ist das ich IOS nicht bedienen kann, da hier die angesprochene Segmentierung verlangt wird und die langsamen Umschaltzeiten. Das Codec Wirrwarr ist gar nicht so schlimm. Eigentlich benötigt man nur x264 und Webm. Damit bedient man schon mal alles außer IOS (IE mit Webm Plugin von Google, Edge hab ich (noch) nicht). Chrome nimmt übrigens auch MKV


    Ich wünsche mir so ein Plugin, damit VDR eine eigene Lösung für Mobiles Fernsehen anbieten kann. Das funktioniert mit meiner App sehr gut (ich nutze sie täglich z.B. zum Nachrichten schauen beim Zähneputzen), ist aber wie gesagt verbesserungswürdig. Jetzt mit NVENC kann man schon mal schwachbrüstigere Server dafür nutzen. TV Geräte interessieren mich hier weniger. Da kann man auch einen RPI oder ähnliches als Client anschließen oder meine App mit Chromecast nutzen (ist eher nur zum Aufnahmen schauen gut TV geht auch, man kann ja aber nicht umschalten).


    Vielleicht kann man ja auch Streamdev beibringen bei Nutzung von Externremux auf Befehl umzuschalten. Aktuell muss ich immer den Stream anhalten und einen neuen starten, was auch schon Probleme macht und ca. 30 Sekunden dauert.


    Naja, wir haben hier jetzt überall smarttvs, und ich habe mir viele Apps von Streamingdiensten angeschaut.
    Die verwenden alle HTML5 als Basis für die UI und je nach Device wird das video Tag über HTML5 MediaSourceExtensions (https://www.w3.org/TR/media-source/) gefüttert oder die Dekodierung wird nativ über z.B. Android durchgeführt.
    Ich schau mir schon seit einigen Wochen Ideen an um vomp durch etwas zu ersetzen, was für die meisten Plattformen über HTML5 läuft und daher die entsprechenden segmentierten Files braucht. (Also sowohl AndroidTV, SmartTV Android für mobiles TV, und Versorgung über Webbrowser am PC).
    Mein aktueller Stand ist das die meisten Browser nur Mp4 Container über MediaSourceExtensions verarbeiten können und meist nicht TS (das nur über die älteren HLS und HAS Standards und dann Mp3 mit h264 und AAC oder mp3 der kleinste gemeinsame Nenner ist.
    Aber mir ist noch nicht klar wie der Weg genau aussehen wird. Das Schreiben eines Plugins das so etwas macht ist weniger das Problem, ich habe genug an muxer, demuxern und ffmpeg für die raspberry pi und windows ports für vomp gearbeitet (inklusive experimentellen Streamings mit Transcoding für bluray, das aber von der SchreibPerformance der temporär Dateien auf bluray Seite schrecklich war.
    Vielmehr eine Architektur zu finden die möglichst viele Geräte ansprechen kann, also welche Container und Codecs bedient werden müssen. Außerdem habe ich nicht so richtig Lust auf die javascript Seite und ich brauche noch eine lib die sich um die http routen kümmert.
    Also ich schwanke noch ob ich damit anfangen soll....


    Marten

    vdr experimental, Femon, vdr live, acpi-wakeup, vompserver, undelete, epgsearch, vdr-burn, Raspberry Pi und Vompserver Windows Client (build from git)

  • 720p ginge auch, sollte halt nicht interlaced sein.

    Hmm, Baraka war mal bei AreaDVD eine Referenz. Unter https://www.youtube.com/watch?v=ZSfFHxyYJJA gibt es einen "Baraka Original Theatrical Trailer - HD Matchframe Re-Edit" in 720p. Länge 02:46 bei 43,6 MB.


    ffmpeg kann doch Fertige HLS TS Streams ausgeben? Das macht der Plexmediaserver sowie Emby doch mit ffmpeg am laufendem Band...

    Mir ist auch so, dass es geht. Meiner Meinung nach war
    http://www.heise.de/ct/ausgabe…nes-streamen-2312251.html
    auf Basis ffmpeg.

    HD-VDR 1&2 : Asrock N68C-S UCC, ASUS EN210 Silent, Boot IDE CF-Card, /srv auf SATA Samsung 3TB
    HD-VDR 1 : Sempron145, yavdr 0.4, TeVii S480 V2.1 DVBs2 Dual
    HD-VDR 2 : Sempron140, yavdr 0.5, DD Cine S2 V6.5 + DuoFlex S2
    Server (im Aufbau): Asrock B75M R2.0 mit i5-3470T sowie Zotac GT970 & DD Cine S2 V6.5 für Gastsysteme
    - Host: Manjaro-XFCE mit 4.4er Kernel mit qemu und virt-manager

  • Zitat

    Das halte ich für ein Gerücht.
    ffmpeg kann doch Fertige HLS TS Streams ausgeben? Das macht der Plexmediaserver sowie Emby doch mit ffmpeg am laufendem Band...


    Ich meine aber etwas anderes, nicht das ein fixer HLS TS Stream ausgegeben wird, sondern das durch Kontrolle des Clienten die Bitrate dynamisch geändert werden kann, die das Plugin zum encoden nutzt.
    Ob da der muxer noch eingesetzt werden kann glaube ich weniger, da er ja eine feste HLS Datei ausgibt, außerdem ist HLS auch schon Schnee von gestern, die neue Standards nutzen alle MediaSourceExtensions und das ist ein anderer Container, leider kein TS mehr (auch wenn es Teil der Spezifikation ist). Grundsätzlich meine auch nur das der muxer wahrscheinlich im Plugin implementiert werden muss (ich vermute plex und emby machen das ähnlich aber die scheinen nicht open source zu sein(jedenfalls habe ich keinen source gefunden) , da kann ich nicht reinschauen, was die machen).


    Marten

    vdr experimental, Femon, vdr live, acpi-wakeup, vompserver, undelete, epgsearch, vdr-burn, Raspberry Pi und Vompserver Windows Client (build from git)

  • Coole Sache! Die Qualität soll ja viel besser sein. Ist aber ganz schön was zu tun um das zu testen ;)

    Grüße


    Hannemann

  • Vielmehr eine Architektur zu finden die möglichst viele Geräte ansprechen kann, also welche Container und Codecs bedient werden müssen. Außerdem habe ich nicht so richtig Lust auf die javascript Seite und ich brauche noch eine lib die sich um die http routen kümmert.
    Also ich schwanke noch ob ich damit anfangen soll....


    Also wenn das mit den Segmentierten Dateien irgendwie hinzubekommen ist... den JavaScript Part übernehme ich gerne. Mein Player kann ja schon die Hälfte. Aktuell arbeite ich mit den Streams von Streamdev aber das kann man auch umbauen.
    Für den HTTP Teil könnte man cxxtools nehmen.

    Grüße


    Hannemann

  • Da werdet Ihr keine Leistungseinbußen spüren. NVENC nutzt spezielle dedizierte ASICs auf dem Grafikchip, der kann nichts anderes als h264 bzw HEVC zu codieren. Einzig der RAM wird wohl geshared.

    "nativ" auf dem Server mit NVIDIA GM204 [GeForce GTX 970] mit dem Baraka-Trailer bei 4500K -> ca. 80MB vs 43,6 MB beim Original (ohne HW-Skalierung nach 1080p).



    HD-VDR 1&2 : Asrock N68C-S UCC, ASUS EN210 Silent, Boot IDE CF-Card, /srv auf SATA Samsung 3TB
    HD-VDR 1 : Sempron145, yavdr 0.4, TeVii S480 V2.1 DVBs2 Dual
    HD-VDR 2 : Sempron140, yavdr 0.5, DD Cine S2 V6.5 + DuoFlex S2
    Server (im Aufbau): Asrock B75M R2.0 mit i5-3470T sowie Zotac GT970 & DD Cine S2 V6.5 für Gastsysteme
    - Host: Manjaro-XFCE mit 4.4er Kernel mit qemu und virt-manager

  • Zitat

    Also wenn das mit den Segmentierten Dateien irgendwie hinzubekommen ist... den JavaScript Part übernehme ich gerne. Mein Player kann ja schon die Hälfte. Aktuell arbeite ich mit den Streams von Streamdev aber das kann man auch umbauen.
    Für den HTTP Teil könnte man cxxtools nehmen.


    Ich habe mir gerade libavformat genauer angeschaut, scheint sich insbesondere 2015 viel getan zu haben (was vermutlich bedeutet das jessie nicht die richtigen libs hat).
    Scheint vieles da zu sein, alle wichtigen Container usw. auch als segmentierte Version.


    Die Frage ist, wie soll die API aussehen, die aktuellen Bitraten, Codecs und Container sowie Audiospur alle in die URL encoden für die Files?
    Dann noch eine JSON API die Informationen über die Aufnahme wie Länge und Audiospuren mitteilt (muss ja nicht alles transkodiert werden).
    Und das Ganze immer im Zusammenspiel mit dem Restfulapi plugin bauen.


    Frage ist cxxtools noch sinnvoll, die Webseite kann ich nicht aufrufen..., libpoco kann ich mir wenigstens anschauen...


    Ich schau mir das mal nächstes Wochenende noch genauer an... und dann entscheide ich ob ich einen Prototyp baue...., sieht aber einfacher aus als ich dachte..


    Marten

    vdr experimental, Femon, vdr live, acpi-wakeup, vompserver, undelete, epgsearch, vdr-burn, Raspberry Pi und Vompserver Windows Client (build from git)

  • MartenR


    Wie man die Parameter übergibt kann man ja relativ einfach anpassen. Ich habe jedenfalls gerade festgestellt, das Apache als Proxy zicken macht wenn man kodierte slashes im URL übergeben will (404). Vielleicht sind GET Parameter doch besser geeignet.


    Restfulapi kann bereits alles liefern was benötigt wird. Wenn man das als Quelle für die benötigten Infos hernimmt braucht man sich darum gar nicht zu kümmern und falls was fehlt bauen wir es ein.


    Meinst du Live TV lässt sich auch so umsetzen? Das zu segmentieren stell ich mir irgendwie schwierig vor.

    Grüße


    Hannemann

  • Das segmentieren macht komplett ffmpeg bzw libav. Die Segmente werden dann über einen Webserver ausgeliefert (Apache, ngix, libpoco)
    Segmentiert wäre dann wohl Hls (m3u8) oder MPEG dash. Moderne Browser oder auch Geräte (Chromecast, Smarttv) spielen auch MKV als stream ab.
    Mit libpoco sind das nicht mehr als ein paar Zeilen Code, Beispiel siehe plex Plugin.


    Chris

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!