Beiträge von z421

    Hab grade einen mit APU1D & Max S8 via minipcie -> pcie 1x adapter aufgebaut.
    Damit schafft man mit etwas Willen auch 8 decodierte streams.


    Stromverbrauch Peak gemessen 2A auf 12V sprich 24W.


    Mit 3 x Gbit via LACP bonding gibt's auch bei der Bandbreite kein Thema.

    PES streaming funktioniert mit dem streamdev patch noch nicht.


    Da schreibt der VDR im Log immer folgende Meldungen:

    Zitat

    May 3 14:22:59 tvserver vdr: [1217] ERROR: unknown picture type '4'
    May 3 14:22:59 tvserver vdr: [1217] ERROR: unknown picture type '5''
    May 3 14:22:59 tvserver vdr: [1217] ERROR: unknown picture type '6'
    May 3 14:22:59 tvserver vdr: [1217] ERROR: unknown picture type '7'


    Je "unknown picture type" Nummer sind's jeweils ca. 25 Log Einträge

    jsffm
    Danke für den Streamdev patch, der funktionierte auf Anhieb.
    Werde den in den nächsten Tagen noch etwas ausführlicher testen.


    Mein erster Versuch streamdev zu patchen hat nur hin und wieder zu einer Bildausgabe geführt, mir haben da wie es aussieht zwei notwendige Zeilen gefehlt.
    Deshalb hatte ich den Patch auch nicht gepostet.



    Mit freundlichen Grüßen,
    z421 :)

    vdr mit -D 0 starten. (Unter Debian in /etc/vdr/conf.d/00-vdr.conf)
    vdr-plugin-satip mit -d 2 (wobei 2 auch der Standardwert ist). (Unter Debian in /etc/vdr/conf.d/50-saitp.conf)
    Am besten dem satip auch noch "-s IP-vom-MINISATIP-Server|DVBS2-2" mitgeben.


    Die automatische SAT>IP-Server-Erkennung dauert meist etwas, das kann beim Einschalten bzw. NVRAM Wakup & Timern lästig sein.

    @Zille,


    warum ich explizit nach Kernel >4.4 gefragt habe ist, dass ich dort im Changelog einiges bezüglich KMS Treiber für RPI aufgeschnappt habe.


    Mein erster Gedanke bei mmal war folglich:
    Das wird wohl was mit den neuen Grafiktreibern zu tun haben.


    http://www.phoronix.com/scan.php?page=article&item=linux-44-features&num=1

    Zitat

    - There's a Raspberry Pi KMS driver that's finally landed after the extensive work done by Eric Anholt at Broadcom. Unfortunately for Linux 4.4, this Raspberry Pi kernel graphics driver is just for kernel mode-setting and doesn't yet handle 3D hardware acceleration or power management. Eric is still working on that acceleration code as well as the accompanying VC4 Gallium3D driver.


    http://www.phoronix.com/scan.php?page=article&item=linux-45-features&num=1

    Zitat

    - While the VC4 DRM driver was previously added as the Raspberry Pi kernel mode-setting driver, the kernels up to now haven't had the necessary bits for supporting 3D/OpenGL in conjunction with the new VC4 Gallium3D driver from Mesa. However, with Linux 4.5 those needed kernel bits are in place for having a fully open Raspberry Pi 3D driver stack.


    https://dri.freedesktop.org/wiki/VC4/

    reufer ,
    Danke für die vielen weiteren Details. :)


    Das mit rpihddevice & omxplayer hatte ich dann wohl falsch in Erinnerung. Jedoch ist das Problem der Audio-Ausgabe für den Endnutzer bei beiden das gleiche:
    Es ist keine Möglichkeit implementiert den Ton via Alsa auszugeben.

    ich will jetzt nicht stänkern, aber laut hier kann man per dtparam in der config.txt zumindest für den onboard Sound ALSA aktivieren (von mir ungetestet).


    Machst du aber. ;) - Keine Sorge, wir werden dir den Sinn von mmal unter softhddevice erläutern:


    Ja, man kann Ton am Raspberry über Alsa ausgeben, das ist richtig. Aber omxplayer & Ton über Alsa geht nicht (wirklich [1]).
    Omxplayer läuft über OpenMax, und OpenMax hat keinen Alsa Output. Das heißt, OpenMax gibt Bild und Ton direkt an den Grafiktreiber weiter, und der teilt dann Bild und Ton auf. Das ist aber nicht Alsa basierend. Somit kann man unter Verwendung von Omxplayer den Ton nur über a) HDMI oder b) dem On-Board-Analog Ausgang abspielen.
    Das führt wiederrum dazu, dass man HifiBerry, USB-Soundkarten usw. nicht mit hardwarebeschleunigter Video-Wiedergabe über OpenMax verwenden kann.


    Im Kodi z.B. kann man dazu mmal & alsa verwenden. Unter dem rpihddevice, welches zur Ausgabe von Bild & Ton auf den omxplayer zurückgreift, geht das aber nicht.


    Zu dem Thema gibt's einiges an Lesestoff, problematisch ist bei einer Ausgabe des Tons über Alsa & Bild über OpenMax, dass man A/V sync bekommt. Es gibt aber (habe ich in dunkler Erinnerung) irgenwo einen (Alpha)-Patch für OpenMax der das Feature Alsa Output in einer OpenMax implementation hinzufügt. Doch (leider) wurde der Patch nicht weiterverfolgt.


    https://github.com/huceke/omxplayer/issues/36
    [1]http://forum.kodi.tv/showthread.php?tid=174502

    Openhome.org
    Konfig, Kinsky: oss.linn.co.uk


    Lief auf einem Raspberry mit Raspbian Wheezy out-of-the-box.
    Ist eher was für App Bedienung. Auch Volumeio.org kann für Netzwekplayer interessant sein.

    Der Nachteil von SATIP ist, dass leider kein Austausch zwischen Server & Client von verfügbaren Kanälen gemacht wird.
    Das ist bei VTP schon ein sehr gutes Feature, "Kanal nicht verfügbar" gehört da nicht zum Programm, wenn ein Tuner am Server belegt ist.

    Vielen Dank für das Ostergeschenk,
    und deiner Arbeit in Sachen VDR. :)


    Leider ist HVEC/4k bei mir Hardwareseitig noch nicht wirklich brauchbar.
    Weiters habe ich auch einen kurzen Blick auf das VNSI-Plugin gemacht, das braucht wie's aussieht einen eigenen Parser, und wird somit aufwendiger.

    Ich hab's mit einem Quick'n'Dirty Patch vom streamdev-server getestet, und kann sagen:
    Der Parser funktioniert! Ich bekomme ein Bild mit mplayer als Stream im TS format.


    Bei PES füllt sich der Buffer mit dem schnell-schnell Patch nicht. Genauer habe ich mir das aber noch nicht angesehen.


    Getestet habe ich folgende Sender:

    Code
    1. PEARL TV 4K UHD;:12344:HC23M5O35P0S1:S19.2E:30000:2815=36:0;2816=deu@3:0:0:2010:1:1043:0
    2. Insight UHD;:12344:HC23M5O35P0S1:S19.2E:30000:255=36:0;256=deu@3:0:0:2000:1:1043:0


    Wenn der Analog I/O ein ähnliches Problem hat, dann ist das wohl auf den PCI Bus zurückzuführen.
    Wie bereits oben erwähnt, BIOS Einstellungen, Latency Timer, Slot-Position usw. versuchen.


    In deinem Fall hängt die Karte am selben IRQ wie der USB3 Bus, wenn USB Geräte in Verwendung sind auf dem IRQ könnte man auch versuchen die abzuändern.
    Bei manchen Mainboards führt aber all das auch nicht zur Lösung. Irgendwann hatte ich mal so ein Asus Brett mit Via Chipsatz. Da liefen die ICE1712 Karten garnicht ohne knacksen bzw. rauschen.


    Wenn du an der Hardware nichts verändern magst, und SPDIF I/O brauchst, ist USB wohl die bessere Lösung, wenn eine Asynchrone Datenübertragung möglich ist.
    Bei den meisten USB-Soundkarten ist das der Fall. Je nach dem wie Detailiert du das prüfen magst, sind Teardown-Fotos hilfreich. ;-)


    Die UA55 ist wie's aussieht rund um ein Analog Devices DSP gebaut:
    http://www.analog.com/media/en…524_BF525_BF526_BF527.pdf
    Ein paar Fotos vom Innenleben gibt's hier:
    http://lsair.html.xdomain.jp/a…and_quad-capture_usb.html


    Ich habe mir das DSP und die USB Datenübertragung aber nicht im Detail angesehen.

    Ich habe in letzter Zeit mit den Envy24 keine Probleme gehabt mit Latency Timer usw.. Als ich die ersten dieser Karten verwendet habe, das müsste so 2005 gewesen sein, da kann ich mich an solche Probleme & Themen (IRQ Sharing, BIOS Optionen, ...) noch erinnern.


    Wenn der Analoge I/O problemlos & ohne knacken läuft, dann glaube ich kaum, dass es ein PCI problem ist.
    Was dann noch Übrig bleibt, sind die SPDIF Output settings, unter "Hardware Settings".

    Upps, dachte das knacken ist am Input, hatte es falsch in Erinnerung.


    Übersteuert dir vielleicht der Digitale Mixer? Bzw, welche Quelle hast du im "Patchbay / Router" am SPDIF Ausgang geroutet?
    Der Digitale Mixer der ICE1712 Karten beginnt sehr deutlich zu knacksen/Rauschen wenn er übersteuert, der ist ziemlich sensibel.


    Das wäre eins der wenigen Sachen die mir hierzu Softwareseitig noch einfallen.