Streams komprimieren auf TVHeadEnd Server

Hi,

hier mal ein Update von mir. Ich hab irgendwas kaputtgespielt und habe keine Ahnung was... VAAPI funktioniert nicht mehr, aber irgendwie hängt libav da mit drin.
Hier sind zwei verschiedene Fehler, je nachdem ob ich von Windows (oben) oder Linux (unten) drauf zugreife.

Sep 21 19:03:18 Udoo tvheadend[3944]: libav: Assertion pic->output_buffer == 0xffffffff failed at libavcodec/vaapi_encode.c:5Sep 21 19:03:18 Udoo tvheadend[3944]: libav: Assertion pic->output_buffer == 0xffffffff failed at libavcodec/vaapi_encode.c:569


Sep 21 19:05:43 Udoo tvheadend[4887]: libav: AVCodecContext: Failed to end picture encode issue: 18 (invalid parameter).
Sep 21 19:05:43 Udoo tvheadend[4887]: libav: AVCodecContext: Encode failed: -5.

VAINFO gibt:

error: XDG_RUNTIME_DIR not set in the environment.
error: can't connect to X server!
libva info: VA-API version 0.40.1
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/local/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_40
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.40 (libva )
vainfo: Driver version: Intel i965 driver for Intel(R) CherryView - 1.8.4.pre1 (1.8.3-135-g6f6a867)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Simple            : VAEntrypointEncSlice
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileH264MultiviewHigh      : VAEntrypointVLD
      VAProfileH264MultiviewHigh      : VAEntrypointEncSlice
      VAProfileH264StereoHigh         : VAEntrypointVLD
      VAProfileH264StereoHigh         : VAEntrypointEncSlice
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointEncPicture
      VAProfileVP8Version0_3          : VAEntrypointVLD
      VAProfileVP8Version0_3          : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointVLD

Das sieht für mich eigentlich ganz normal aus (außer das VA-API version: 0.40 (libva), da fehlt meiner Meinung nach eine Version dahinter...
Emby benutzt VAAPI ganz normal und wie gehabt.

Habe die libva und auch libav neu installiert und gebaut, aber keine Erfolge. Schade... vielleicht sieht jemand auf den ersten Blick was, ansonsten gebe ich es erstmal auf bis es stabilier ist.

Grüße

Auch ich muss eine negative Rückmeldung geben. Die Pakete, die ich eine Seite zuvor gepostet habe, haben nicht funktioniert. Es wird da anscheinend ein falscher Treiber (i915 statt i965) genommen und somit funktioniert auch das Hardware-Decoding nicht.
Also ich lasse das jetzt alles. Da ich eh eine starke CPU habe, soll diese die Aufgabe des transcodierens übernehmen. Mehr als zwei Streams gleichzeitig brauche ich eh nicht und somit muss halt die CPU herhalten. Für was habe ich den eine solche gekauft.
Sorry, dass ich da falsche Hoffnungen geweckt habe.

das Docker Image ist leider noch nicht fertig, das würde das Problem beheben

CvH: Hast du es eigentlich auf Ubuntu am Laufen? Welche Pakete / Treiber hast du genommen? Bin irgendwie sehr ratlos gerade...

Zitat von tojo2503

Hast du es eigentlich auf Ubuntu am Laufen?

Nein, ich brauch für meinen Heimbetrieb Stabilität (Frau ...) und kann mit der 4.3 noch nichts anfangen. Hab das nur zum Testen unter LE am laufen.

Zitat von CvH

Nein, ich brauch für meinen Heimbetrieb Stabilität (Frau ...) und kann mit der 4.3 noch nichts anfangen. Hab das nur zum Testen unter LE am laufen.

Moin,

noch ein Update: es läuft wieder und läuft auch mit 2 Streams parallel (Celeron N3160). Sieht echt gut und brauchbar aus bisher. Richtig coole Sache.

Der Fehler war, dass ich unter "Codec Profiles" Deinterlace aktiviert hatte. Das muss offensichtlich deaktiviert sein, damit ein Transcode per VAAPI funktioniert.
vainfo findet sich in meinem letzten Post, da habe ich nichts dran geändert. Deinterlace darf offensichtlich noch nicht aktiviert sein... selten dämlicher Fehler, der mich einiges an Zeit gekostet hat. Aber egal, es läuft. Sonstige Einstellungen sind in Post #183 beschrieben.

Beste Grüße!

Zitat von tojo2503

Der Fehler war, dass ich unter "Codec Profiles" Deinterlace aktiviert hatte.

oha, das wäre mir neu das es nicht geht - sieht wie Tvh Fehler aus (mal gucken ob ich das nachstellen kann)

Zitat von CvH

oha, das wäre mir neu das es nicht geht - sieht wie Tvh Fehler aus (mal gucken ob ich das nachstellen kann)

Den Tipp habe ich aus deinem Feature-Request von Jaroslav (Beitrag 33, das Log ist kurz davor irgendwo): https://tvheadend.org/issues/4443#note-33
Ist eigentlich in aktueller Zeit kein wirklich sinnvolles Feature, weil die allermeisten Clients selbst in der Lage sein sollten zu deinterlacen. Ist aber leider per default aktiviert und ich hatte es beim ersten Versuch wohl deaktiviert und dann irgendwann aktiviert...

Grüße

deinterlacing sollte bei Transcoding immer gemacht werden, weil sonst würde es das Interlace Bild als Vollbild encoden was einmal die Qualität massiv verschlechtert und gleichzeitig die Dateigröße in die Höhe treibt.
Deinterlace vom Quellmaterial ist kein Problem und sieht gut aus, Deinterlace von einem reencode/transcodetem Bild sieht einfach nur mistig aus gegenüber wenn es direkt gemacht werden würde

Zitat von CvH

oha, das wäre mir neu das es nicht geht - sieht wie Tvh Fehler aus (mal gucken ob ich das nachstellen kann)

Habs mit meinem Broadwell Core i3 mal kurz ausprobiert und es sieht so aus, als ob es nicht funktioniert wenn Deinterlace aktiviert ist, aber Hardware Acceleration deaktiviert und man einen Sender schaut, der nicht interlaced ist (z.B. ZDF HD). Sender die interlaced sind, funktionieren, und wenn man Hardware Acceleration einschaltet, funktionieren alle Sender, weil dann VAAPI wohl das Deinterlacen übernimmt.

Deinterlace über Vaapi funktioniert einwandfrei solange der Wert unter "Expert Settings" auf 0 bleibt. Setze ich einen höheren Wert als 2 (3-8) dann stürzt TvHeadend ab und ich erhalte die bereits bekannte Fehlermeldung:

[cbox]libav: Assertion pic->output_buffer == 0xffffffff failed at libavcodec/vaapi_encode.c:569....[/cbox]

Also lasse ich Expert Settings lieber auf Default-Einstellung.

Läuft dann tadellos, mit Ubuntu 17.04 auf einem einem Intel N3150.
Zwei Vaapi Streams mit verschiedenen Bitraten laufen zeitgleich einwandfrei, kein ruckeln und keine Unterbrechungen.
8000kbit/s für Zuhause und 800 kbit/s für unterwegs. Hab nur eine 1 MBit Upload-Leitung darum der niedrige Wert, die Bildqualität ist aber noch recht akzeptabel.

Die Auslastung über top zeigt für den Prozess tvheadend durchschnittlich 33 % an (2 Streams SD Sender)
Starte ich zusätzlich noch die Aufnahme steigt die Auslastung auf 50-55 % (2 Streams SD + Aufnahme)

Was mich stört ist das Bildformat über Vaapi. Die SD Sender werden nur im 4-3 Format angezeigt, gleiches gilt auch für die Aufnahmen. Kodi kann man zwar entsprechend einstellen, dass 4-3 Quellmaterial als 16-9 Bild angezeigt wird, ist aber nicht wirklich ne schöne Lösung. Ist dies bei euch auch so über Vaapi?

Zitat von Huberer

Es wird da anscheinend ein falscher Treiber (i915 statt i965) genommen und somit funktioniert auch das Hardware-Decoding nicht.

Aus dem Ubuntu Forum habe ich folgendes erfahren. Tvheadend ermittelt die Version möglicherweise anhand des Hashwertes.
In beiden Treiber (i915 und i965) liegt eine Datei mit der Versionsinfo vor, die trotz unterschiedlicher Bezeichnung, beide den gleichen Hashwert haben.
Der richtige Treiber wird dennoch verwendet. Ist also wohl nur ein kleiner Schönheitsfehler

Zitat von Zangetsu

Deinterlace über Vaapi funktioniert einwandfrei solange der Wert unter "Expert Settings" auf 0 bleibt. Setze ich einen höheren Wert als 2 (3-8) dann stürzt TvHeadend ab und ich erhalte die bereits bekannte Fehlermeldung:

[cbox]libav: Assertion pic->output_buffer == 0xffffffff failed at libavcodec/vaapi_encode.c:569....[/cbox]

Also lasse ich Expert Settings lieber auf Default-Einstellung.

Läuft dann tadellos, mit Ubuntu 17.04 auf einem einem Intel N3150.
Zwei Vaapi Streams mit verschiedenen Bitraten laufen zeitgleich einwandfrei, kein ruckeln und keine Unterbrechungen.
8000kbit/s für Zuhause und 800 kbit/s für unterwegs. Hab nur eine 1 MBit Upload-Leitung darum der niedrige Wert, die Bildqualität ist aber noch recht akzeptabel.

Hi,

kann ich so bestätigen. Hängt tatsächlich mit dem Zusammenhang Deinterlace<--> Qualität zusammen. Bis Einstellung 2 funktioniert es auch bei mir. Habe jetzt eine ähnliche Konfiguration am Laufen. Sowohl 720p als auch 1080i Sender funktionieren gut.

Zitat von Zangetsu

Was mich stört ist das Bildformat über Vaapi. Die SD Sender werden nur im 4-3 Format angezeigt, gleiches gilt auch für die Aufnahmen. Kodi kann man zwar entsprechend einstellen, dass 4-3 Quellmaterial als 16-9 Bild angezeigt wird, ist aber nicht wirklich ne schöne Lösung. Ist dies bei euch auch so über Vaapi?

Kann ich ebenfalls bestätigen. SD Sender werden in 4:3 ausgegeben. Wenn der Client Kodi ist, kann man aber problemlos einstellen, dass 4:3 Videos nichtlinear oder linear auf 16:9 skaliert werden sollen. Dann sieht das Ergebnis wie erwartet aus.

Insgesamt läufts jetzt echt super. Bin bei der Einstellung Deinterlace + Quality = 2 geblieben und damit sehr zufrieden.

Viele Grüße

Danke, dann kann ich das ja so erstmal laufen lassen.
Dachte schon das ich vielleicht was übersehen habe.

Vielleicht habe ich es falsch in Erinnerung, aber ich bin mir fast sicher das die Einstellung mit "Quality" mal funktionierte.
Da war ich aber noch in der Experimentierphase und habe willkürlich irgendwelche Pakete installiert, bis ich Vaapi am laufen hatte.
Mit TvHeadend 4.3-483 ging es noch. Leider habe ich die Version nicht mehr und weiß auch nicht, wie ich an eine ältere Version mit VAAPI rankommen kann. Weiss da jemand ne Lösung?

Grüße

So, ich möchte hier eine kleine Rückmeldung geben an jene die mit OMV/Debian unterwegs sind und noch die "älteren" Versionen von libva und Intel-Treiber drauf haben. Im Emby-Forum bin ich auf einen Beitrag von @sualfred gestoßen, der mich dann auf den richtigen Weg (glaublich) gebracht hat.
Wie schon ein paar Beiträge zuvor geschrieben, habe ich ein paar Packages von Ubuntu gefunden und auf mein OMV v3 mit 4.9 backboard-kernel installiert. Dabei habe ich anscheinend ein paar Libraries zerschossen und blieb somit mir nichts anderes mehr übrig als meinen Server (siehe Signatur) neu zu installieren. Ich habe gleich die Gelegenheit genutzt und auf OMV v4 "upgegradet". In der stable Debian-Repo sind noch immer veraltete libva-Pakete (0.39) und Intel-Treiber (v1.7.3) vorhanden. Auch in der experimentellen Repo wurden die dort "neueren" Packages komplett entfernt.
Ich bin dann auf folgende Lösung gestoßen:

1. mittels SSH auf den Server verbinden
2. mittels nano /etc/apt/sources.list die Datei für die Paketverwaltung bearbeiten
3. dort die unstable-Repo von Debian "SID" am Ende der Datei eintragen:

# Unstable repo main, contrib and non-free branches, no security updates here
deb http://http.us.debian.org/debian unstable main non-free contrib
deb-src http://http.us.debian.org/debian unstable main non-free contrib

4. mit Control+x den Editor beenden
5. mit apt-get update die Paketquellen neu einlesen
6. mittels

apt-get install i965-va-driver vainfo

werden die dort befindlichen Intel-Treiber, libva und "vainfo" installiert (mittels "J" die Installation bestätigen).

7. Achtung: Wenn dies getan ist, die sources.list wieder öffnen (nano /etc/apt/sources.list) und die zuvor eingefügten Zeilen der unstable Repo von Debian SID entfernen. Warum? weil sonst Pakete von der unstable Repo heruntergeladen und installiert werden (bei etwaigen Updates) und somit das System (Debian Stretch i.V.m. OMV v4) zerstören kann.

8. wieder ein apt-get update ausführen und zum Schluss
9. mittels reboot das System neu starten, damit nach dem Neustart die aktuellsten Treiber geladen werden

Verbindet man sich dann mittels "ssh" wieder mit dem Server und gibt in der Eingabeaufforderung vainfo ein, dann müsste es so aussehen:

root@HomeServer:/etc/apt# vainfo
error: XDG_RUNTIME_DIR not set in the environment.
error: can't connect to X server!
libva info: VA-API version 0.40.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/local/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_40
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.40 (libva )
vainfo: Driver version: Intel i965 driver for Intel(R) Haswell Desktop - 1.8.3
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Simple            :	VAEntrypointEncSlice
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileH264MultiviewHigh      :	VAEntrypointVLD
      VAProfileH264MultiviewHigh      :	VAEntrypointEncSlice
      VAProfileH264StereoHigh         :	VAEntrypointVLD
      VAProfileH264StereoHigh         :	VAEntrypointEncSlice
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc
      VAProfileJPEGBaseline           :	VAEntrypointVLD
root@HomeServer:/etc/apt#

Somit hat man sein System, was die Treiber anbelangt, auf den aktuellsten Stand gebracht.

Wichtig in diesem Zusammenhang: Sollte jemand das auch ausprobieren, so macht bitte vorher ein Backup eures Systems, falls etwas schief geht (ich habe es nicht gemacht und es hat trotzdem geklappt). Ob das ganze auch unter OMV v3 funktioniert kann ich nicht sagen, müsste aber gehen.

@CvH bzw. an alle anderen TVHeadend-Profis

Da beim originalen TVHeadend-Paket für Debian das Hardware-Transcoding mittels vaapi nicht dabei ist, wollte ich mir mein eigenen Paket kompilieren. Wie hier (eine Seite vor dieser) beschrieben.
Wenn ich den Befehl AUTOBUILD_CONFIGURE_EXTRA="–enable-vaapi" ./Autobuild.sh ausführe, erhalte ich folgende Fehlermeldung:

ERROR: libva-x11 not found

und die Kompilierung wird abgebrochen. Auf der Suche nach libva-x11 unter Debian Stretch finde ich nur den Hinweis, dass libva-x11-1 installiert und auf dem aktuellsten Stand ist.
Natürlich habe ich dann die "configure"-Datei von libva-x11 auf libva-x11-1 abgeändert und trotzdem wird die Kompilierung abgebrochen, dass auch "libva-x11-1" nicht gefunden wurde.

Suche ich nach dieser Datei, dann erhalte ich folgende Info:

root@HomeServer:~# find / -iname "libva-x11*"
/var/lib/dpkg/info/libva-x11-1:amd64.triggers
/var/lib/dpkg/info/libva-x11-1:amd64.symbols
/var/lib/dpkg/info/libva-x11-1:amd64.md5sums
/var/lib/dpkg/info/libva-x11-1:amd64.shlibs
/var/lib/dpkg/info/libva-x11-1:amd64.list
/usr/lib/x86_64-linux-gnu/libva-x11.so.1.4000.0
/usr/lib/x86_64-linux-gnu/libva-x11.so.1
/usr/share/doc/libva-x11-1
/home/huberer/intel/libva-1.8.3/pkgconfig/libva-x11.pc.in
/home/huberer/intel/libva-1.8.3/pkgconfig/libva-x11.pc
root@HomeServer:~#

Jetzt natürlich meine Frage, wie ich diese Fehlermeldung von fehlender "libva-x11" vermeiden kann bzw. wie ich TVHeadend trotzdem kompilieren kann.

Vielen Dank im Voraus

es sollte libva-dev sein was fehlt

Danke, genau das war es. Habe es nachinstalliert (musste es über die SID-Repo machen) und konnte es kompilieren.

Beim kompilieren von Tvheadend auf OSMC rpi 3 folgende fehler

Scanning dependencies of target encoder
make[4]: Leaving directory '/usr/src/tvheadend/build.linux/ffmpeg/x265_2.4/build/linux'
make[4]: Entering directory '/usr/src/tvheadend/build.linux/ffmpeg/x265_2.4/build/linux'
[ 1%] Building CXX object encoder/CMakeFiles/http://encoder.dir/analysis.cpp.o
*** Error in `/usr/bin/c++': double free or corruption (!prev): 0x01618348 ***
Aborted
encoder/CMakeFiles/http://encoder.dir/build.make:54: recipe for target 'encoder/CMakeFiles/http://encoder.dir/analysis.cpp.o' failed
make[4]: *** [encoder/CMakeFiles/http://encoder.dir/analysis.cpp.o] Error 134
make[4]: Leaving directory '/usr/src/tvheadend/build.linux/ffmpeg/x265_2.4/build/linux'
CMakeFiles/Makefile2:208: recipe for target 'encoder/CMakeFiles/http://encoder.dir/all' failed
make[3]: *** [encoder/CMakeFiles/http://encoder.dir/all] Error 2
make[3]: Leaving directory '/usr/src/tvheadend/build.linux/ffmpeg/x265_2.4/build/linux'
Makefile:117: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/usr/src/tvheadend/build.linux/ffmpeg/x265_2.4/build/linux'
Makefile.ffmpeg:263: recipe for target '/usr/src/tvheadend/build.linux/ffmpeg/x265_2.4/.tvh_build' failed
make[1]: *** [/usr/src/tvheadend/build.linux/ffmpeg/x265_2.4/.tvh_build] Error 2
make[1]: Leaving directory '/usr/src/tvheadend'
Makefile:832: recipe for target '/usr/src/tvheadend/build.linux/ffmpeg/build/ffmpeg/lib/libavcodec.a' failed
make: *** [/usr/src/tvheadend/build.linux/ffmpeg/build/ffmpeg/lib/libavcodec.a] Error 2
root@osmc:/usr/src/tvheadend#

Hat denn schon jemand Erfahrungen sammeln können? Wieviel gleichzeitige Transcoding Streams (von 1080p auf 720p) wären auf einem Intel Nuc möglich?

Ich würde sagen das kommt u.a. auf das Modell an. Gibt ja nicht nur ein Gerät welches Intel unter der Bezeichnung NUC verkauft.