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

  • Das hört sich doch alles sehr gut an :tup:

    Grüße


    Hannemann

  • Leider kennt nvenc crf nicht.

    Schade, aber danke für die Info.


    Da steht aber immer "up to" vor den angeben, da wäre ich vorsichtig ;) .
    Und einen Einfluss wird der GPU-Takt auch haben.



    Mal am Rande. Alternativ gibt es ja noch Intel Quick Sync.
    -vcodec h264_qsv


    http://emby.media/community/index.php?/t…-30#entry314835

    Auch das klingt vielversprechend.
    Wie auch andere neue Features, die zwei neuen Deinterlacer zB....

    Gruss
    SHF


  • Quote

    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.


    Naja, ich stelle wir eher so etwas vor, dass man mit einem GET auf http://vdr/open/recordings?PARAMETER einen JSON mit einem Art Handle bekommt und dann mit http://vdr/recordings/HANDLE/init.mp4 das initialization segment für MediaSourceExtensions bekommt und mit http://vdr/recordings/HANDLE/SEGMENTNUMBER.mp4?PARAMETER, wobei das die aktuelle Bitrate (transcodiert wird nur wenn Kodierung anders oder Bitrate überschritten) und Auflösung ist. So kann man bei schlechter WLAN oder anderer Verbindung die Bitrate adaptiv anpassen.
    Die GET für die Segmente sollten dann gleich noch Informationen über die tatsächliche Formate im Header haben. Der Header sollte auch sagen wie lang das Transcoding gedauert hat. Analog dazu Live-TV. Zusätzlich sollte eine Art Loadbalancing zwischen nvenv quicksync durchgeführt werden.


    Das mit dem Handle erlaubt dann Decoder und Encoder schnell wieder zu verwenden, das kann Wert volle Zeit und CPU Last sparen, außerdem vereinfacht das die Verteilung der Sample auf die Segmente. Wenn man immer weis welcher Client in welcher Reihenfolge auf die Segmente zugreift, kann man ein bisschen Schlampen bei der Zuordnung der Audiopakete zu den Paketen. Ein größeres Problem ist nämlich das die Segmente immer an Keyframe-Grenzen beginnen und dann die Audiopakete entsprechend aufgeteilt werden müssen. Wenn die Aufzeichung noch läuft, kennt man diese Information nicht unbedingt bei der Erstellung der Segmentgrenzen.


    Quote

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


    Ja klar, das ist sogar einfacher, da die Daten in einer definierten Reihenfolge kommen. Wahlfreier Zugriff ist viel schwieriger....


    Quote

    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.


    Vorsicht, ich habe die Muxer gestern abend genau im git angeschaut (wobei ffmpeg da viel weiter als libav ist), ganz so einfach ist das nicht.
    Denn ffmpeg ist darauf ausgelegt, die ganze Datei einmal durch zu kodieren. (Nur bei live TV sollte das direkt funktionieren)
    Wenn man bei Aufnahmen wahlfreien Zugriff haben will, ohne dass die ganze Aufnahme einmal durch die Maschine läuft, muss das noch irgendwie durch das plugin gesteuert werden (am besten über die VDR index Datei).
    Das sollte also alles on the fly passieren und nicht statisch durch den Webserver ausgeliefert werden.
    Ich würde auch als erstes mp4 als Container verwenden, der Rest kann dann später dazu kommen.


    Marten

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

  • So wie du das beschreibst, mit Initialisierung, Handle/Session, Parameter per GET macht das ja Emby und Plex. Da lässt sich bestimmt etwas "abkupfern"
    Auch würde es sich anbieten solch ein "Plugin" als extra Dienst/Prozess zu entwickeln, das halte ich für besser wartbar.


    Jedoch habe ich das Gefühl das das Vorhaben hier im Umfang explodieren wird...
    Prinzipiell lässt sich das ja alles schon mit Plex/Emby bewerkstelligen. Emby kann auch schon mit den NVDEC/Quicksync Encodern.

  • Jedoch habe ich das Gefühl das das Vorhaben hier im Umfang explodieren wird...
    Prinzipiell lässt sich das ja alles schon mit Plex/Emby bewerkstelligen. Emby kann auch schon mit den NVDEC/Quicksync Encodern.


    Macht doch nichts, wenn das Projekt etwas größer wird. Um unser Hobby weiter voranzutreiben ist es IMO ein Schritt in die richtige Richtung. Auch kann es nicht schaden ein Open Source Plugin anzubieten, das mit transkodieren von Streams umgehen kann damit andere Projekte wie z. B. Kodi auch davon profitieren können. Es soll ja immer noch Leute geben, die sich Plex und Co nicht installieren wollen da Closed Source.


    Einen extra Dienst fände ich nicht so gut. Ich habe da bedenken wegen der Umschaltzeiten und was macht der Dienst während des umschaltens wenn keine Daten mehr geliefert werden. Naja... da kenn ich mich nicht aus. Wenn es funktioniert... aber irgendwie hört sich für mich Plugin "richtiger" an. Auch weil man direkten Zugriff hat und IMO alles einfacher Steuern könnte.


    Wahlfreier Zugriff ist viel schwieriger....


    Wenn Live TV noch einfacher ist, warum dann nicht für Aufnahmen ein Recording Device nutzen? Müsste das nicht ähnlich handlebar sein? Bei Streamdev kann man ja bereits einen Timestamp mitgeben. So habe ich in meinem Player das Spulen umgesetzt.

    Grüße


    Hannemann

  • HD Live TV via Vnsiserver zum Pi und HD Live TV via Externremux zum Handy geht.


    [edit]gleichzeitig natürlich[/edit]

    Grüße


    Hannemann

  • Quote

    Einen extra Dienst fände ich nicht so gut. Ich habe da bedenken wegen der Umschaltzeiten und was macht der Dienst während des umschaltens wenn keine Daten mehr geliefert werden. Naja... da kenn ich mich nicht aus. Wenn es funktioniert... aber irgendwie hört sich für mich Plugin "richtiger" an. Auch weil man direkten Zugriff hat und IMO alles einfacher Steuern könnte.


    Da stimme ich voll zu. Nur so gibt es Zugriff auf die Informationen des VDRs ohne große Verzögerung.
    Der VDR hat einige Informationen über die laufende Aufnahmen, die Keyframes und nur hier bekomme ich die Möglichkeit direkt das LiveTV abzugreifen, das erst durch ein anderes PlugIn laufen zu lassen kostet nur Performance. Sicher muss man besser aufpassen das es nicht abstürzt, aber das ist auch schon alles...
    Und natürlich werde ich massiv verschiedene Threads einsetzen, um den VDR nicht zu stören.


    Quote


    Wenn Live TV noch einfacher ist, warum dann nicht für Aufnahmen ein Recording Device nutzen? Müsste das nicht ähnlich handlebar sein? Bei Streamdev kann man ja bereits einen Timestamp mitgeben. So habe ich in meinem Player das Spulen umgesetzt.


    Stop, so meinte ich das nicht. LiveTV ist einfacher vom Segmentieren, vom Zugriff auf VDR Resourcen sind Aufnahmen natürlich einfacher. Aber egal, das kenne ich alles vom vompserver plugin, da habe ich schon einige Sachen verändert...


    Marten

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

  • Ich überlege gerade, ob ich mir eine GTX950 bestelle.
    ~160€ würden ja noch im Rahmen liegen. :)



    Bestellt, geliefert, eingebaut und enttäuscht...:(





    Die Karte krieselt bei dunklen Flächen. Das sieht aus, wie ein Schneesturm.


    Ich weiß nicht, ob es an der Karte, oder an irgendwelchen Settings liegt?

  • Hallo,


    wenn ich den Thread richtig verstanden habe, denkt ihr ja darüber nach, ein Plugin zu schreiben, welches Aufnahmen oder Live-TV transkodiert und für HTML5 Browser ohne Plugins bereitstellt.


    Ich dachte als ich diesen Thread gesehen habe eher daran, alle Aufnahmen on the fly zu transkodieren. Dabei könnte man gleichzeitig die Schnittmarken einbauen (ffmpeg mit mkv kann das)


    Gruß,
    Hendrik

  • Ich fänd eine Schnittstelle a la externremux von steamdev toll, damit man während der Aufnahme transkodieren kann.


    vdr-User-# 755 to_h264 chk_r vdr-transcode

  • Die Karte krieselt bei dunklen Flächen. Das sieht aus, wie ein Schneesturm.
    Ich weiß nicht, ob es an der Karte, oder an irgendwelchen Settings liegt?

    Im "FFMPEG WITH NVIDIA ACCELERATION ON UBUNTU LINUX: Installation and User Guide" von NVIDIA unter http://developer.download.nvid…tion-on-Ubuntu_UG_v01.pdf ist ein Kapitel "TRANSCODE QUALITY" vorhanden.

    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

  • Interessant bei dem Dokument ist Seite 13



    Der kann mehrere Größen/Bitraten auf einmal ausspucken...

  • Ich experimentiere gerade mit libwebsockets herum... Damit bau ich dann eine Fernbedienung für den Player. Einen String vom Handy an den Desktop schicken ist schon mal kein Problem :)

    Grüße


    Hannemann

  • Die Karte krieselt bei dunklen Flächen. Das sieht aus, wie ein Schneesturm.


    Das klingt nach HDMI Studio Levels die vermutlich das Anzeigegerät nicht verträgt.
    Sieh dir mal die Xorg.conf Option in der Section "Screen" an

    Code
    1. Option "ColorRange" "Full"
    2. # Option "ColorRange" "Limited"
    3. # Option "ColorSpace" "YCbCr444"


    Siehe hier:
    http://wiki.openelec.tv/index.…guring_a_Custom_xorg.conf


    lg,
    Joe

  • Entsprechende Testsequenz und ein oder mehrere Testbilder als Vergleich vorausgesetzt, kann ich mal gegen eine GTX 950 mit Ubuntu 14.04 prüfen.
    In dem "11W-PC" (Details weiter vorn im Thread) hatte ich diese GTX 950 von MSI eingebaut.

    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