[Torsten73]

Hi,
es scheint sich zu manifestieren, dass meine Bildproblem bei 1080p und aktivem Deinterlacerprofil den Raspi schlichtweg überfordern. Auch mit Overclocking auf 1Ghz.
Ich habe dazu mehrere Quellen gefunden die Ähnliches berichten:
http://www.reddit.com/r/raspberry_pi/comments/2f8ztu/raspbmc_stuttering_1080p_high_bitrate/

Scheinbar hat 10bit auch was damit zu tun, das schafft der Raspi nicht:
http://kodi.wiki/view/Hi10P

Dann schafft er auch kein DTS zu dekodieren. Dumm nur dass nicht alle TV´s das selber beherrschen, meiner kann es auf jeden Fall nicht.

Defakto habe ich im Live TV mit Bitraten über 10Mbit (z.B. Servus TV) ein Bildstottern, sobald ein Deinterlacerprofil genutzt wird.

Zuletzt bleibt mir nur noch der Test mit einem eigenem USB Empfänger, nicht das da der Netzwerkdurchsatz schlapp macht:

Code: [Select]

Had this problem myself while using the internal libnfs stuff to read files off my nfs share. I switched to a kernel based nfs mount (actually mounting it with the mount command) and didn't have any further issues. What a shocker that native nfs is faster than a userspace libnfs. Ich denke das hat aber mit streamdev nichts zu tun. Wohl aber dass der Fehler immer bei ansteigender Bitrate auftritt und sich beruhigt und wieder synct, wenn wenig sich ändert. Ergo wohl eher der Datendurchsatz beim Lan bzw der USB Hub wo alles angebunden ist.
http://raspberrypi.stackexchange.com/questions/1262/what-is-the-highest-performing-hardware-configuration

Heißt der Raspi kann kaum Bitraten >10 Mbit schaffen. Damit reicht es zwar für 720p aus aber bei FullHD sind manche Sender bei 15-20Mbit und das konstant. Das kann also der Raspi nie und nimmer schaffen.

Schade drum. Weil das bedeutet, dass noch nicht mal als Streamingserver genug Bandbreite da ist.

Ich verstehe nur immer noch nicht, warum das Stottern nicht bei 1080p auftritt.

[Torsten73]

Ein paar Tage später und mittlerweile ist die DVB-S2 USB Box BVBSky S960 in Betrieb, mit noch mehr Bild Problemen als Streamdev Client.

Offenbar bricht nun die Bandbreite über den USB Chip nun vollständig zusammen. Servus TV in FullHD geht so gut wie gar nicht mehr, selbst normale SD Sender mit aktivem Interlacer machen Klötzchen. Der Sat Empfang kann ausgeschlossen werden, Pegel und BER sind gut und funktionieren am normalen VDR auch problemlos. Am besten funktionieren weiterhin 720p Sender, klar da muß nichts deinterlaced werden und die Bitrate ist <10Mbit.

Einzig das Wiedergeben von den 1080p Signalen einer Streamdev Aufzeichnung funktioniert einwandfrei. Sobald aber noch mehr über den USB
Chip drüber muß kann die Bitrate nicht mehr aufrecht erhalten werden.
Das ist zumindest mein Resume.

Letzter Versuch einer vollwertigen Live Wiedergabe aller Formate ist noch einmal das XBMC. Denn möglicherweise kann das raspihddevice einfach nicht vernünftig puffern.

Ich habe aber auch im Netz nur wenig gefunden dazu. Es wird mehr oder weniger totgeschweigt, oder ich habe alleine diese Probleme, wobei ich von der technischen Seite eigentlich genug Belege für meine Vermutung gefunden habe. Das der USB Chip / Treiber gelinde gesagt Schrott ist sind sich alle einig, lediglich was das für Auswirkungen hat schreibt keiner.

Insofern, sehr viel mehr als reiner Streaming Server ohne lokalem Speicher oder vollständiger Verzicht auf 1080p ist kaum zu realisieren. Insofern kann ich verstehen, dass MarMic das ganze aufgegeben hat 

Im Grunde frag ich mich, ob nicht ein kleiner Intel Nuc zwar etwas mehr kostet, aber softhddevice hat es doch etwas einfacher mit der Intel Grafikkarte. Da gibt es zumindest keine massiven USB/Netzwerk Probleme.

[Marcus]

Mein RPI läuft gut, habe keine Probleme. Nutze aber auch DVB-C über streamdev. Da sind wohl die Bitraten nicht so hoch.

[Torsten73]

Zeichnet Du auch lokal am raspi auf? Das geht auch mit streamdev nur bei SD Sendern bei mir. KikaHd hat ab und zu auchbaussetzer in den Aufzeichnungen, xfs ist weniger problematisch als ext4, was logisch ist.

[Marcus]

Nein, Aufnahmen nur auf dem Server.

[Marcus]

Mach mal ein "ifconfig" und poste das Ergebnis hier.

[Torsten73]

? Wobei helfen die Netzwerkeinstellungen weiter? Das verstehe ich nicht, wie das mit den Engpässen zusammenhängen kann.
Aktuell kann ich am System nichts machen, bin jetzt im Urlaub (wo der eigentlich mit sollte, ich mir aber erspart habe)
Das dauert also bis Mitte nächste Woche.

[clausmuus]

Hi,

es gibt nen Update des rpihddevice Plugins. Damit sollten dei dts Probleme behoben sein, und eventuell auch einige andere, das der Fehler wohl den RPI ein unnötig hoch belastet hatte. Ich hab das neue Plugin aber noch nicht getestet.

Claus

[Torsten73]

Gut dann spiele ich mal mein Backup zurück und teste. Danke für den Hinweis. Trotzdem wird die Konstellation HDD/DVB-S2/ für den Raspi vermutlich weiterhin an der miesen Performance des USB Flaschenhalses scheitern. Aber ich lasse mich gerne eines besseren belehren 

Meiner Logik nach liegt das auch darin begründet, dass bei DVB-S2 über USB Receiver der komplette Transponder übertragen wird, während bei streamdev nur der einzelne Sender durchs USB Nadelöhr muß. Das macht sich dann bereits selbst bei ÖR 720P bemerkbar. Kommt dann noch eine Aufzeichnung mit ins Spiel geht da gar nichts mehr.

Der nächste praktische Einsatz ist erst im April wieder, bis dahin hat mein Wohnwagen Winterpause 

[Marcus]

Das wird ja mit dieser Meldung im Log angekündigt:

Code: [Select]

dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
Jetzt gibt es ja (bei einigen/vielen/allen?) DVB-Sticks einen Hardware PID Filter. Bei meinem NOVA-T-Stick gibts laut LinuxTV eine Option für dvb-usb, diesen auch zu benutzen.

Code: [Select]

force_pid_filter_usage
Ich hab das nie probiert und weiß auch nicht, ob die Treiber / der VDR das können, aber wenn das funktioniert sollte doch der Traffic über den USB-Bus reduziert werden?

Grüße
Marcus

EDIT:

Hier gibt es etwas Informationen bezüglich HW-PID-Filter:

While a system with a single usb2 stick will not be taxed at all by
software PID filtering, there might be a slight performance
enhancement in a system with 7 or 8 usb2 sticks using hardware PID
filters rather than software.

On the other hand, a device with hardware PID filters can be used on a
USB1.1 port, which would normally not provide enough bandwidth for
full transport using software filtering.

So yes, there is a gain in using hardware PID filters, but 90% of the
users would never notice the difference.

EDIT2:

So, habe jetzt mal den HW-PID-Filter bei mir aktiviert. Dazu habe ich

Code: [Select]

options dvb-usb force_pid_filter_usage=1in die /etc/modprobe.d/custom.conf eingetragen. Nach einem reboot steht folgendes im Log:

Code: [Select]

Jan  1 01:00:12 (none) user.info kernel: [   13.611650] dvb-usb: found a 'Hauppauge Nova-T Stick' in cold state, will try to load a firmware
Jan  1 01:00:12 (none) user.info kernel: [   13.664503] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw'
Jan  1 01:00:14 (none) user.info kernel: [   15.151374] dvb-usb: found a 'Hauppauge Nova-T Stick' in warm state.
Jan  1 01:00:14 (none) user.info kernel: [   15.153416] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
Jan  1 01:00:14 (none) user.info kernel: [   15.153447] dvb-usb: pid filter enabled by module option.
Jan  1 01:00:15 (none) user.info kernel: [   16.238538] dvb-usb: schedule remote query interval to 50 msecs.
Jan  1 01:00:15 (none) user.info kernel: [   16.238569] dvb-usb: Hauppauge Nova-T Stick successfully initialized and connected.
Der Interessante Teil ist

Code: [Select]

Jan  1 01:00:14 (none) user.info kernel: [   15.153447] dvb-usb: pid filter enabled by module option.Bei mir, mit DVB-T Stick, hat das keinerlei Effekt. Aber du könntest mal testen ob es damit bei dir etwas besser wird.

Grüße
Marcus

[Torsten73]

Hi Marcus,
na das ist mal eine interessante Option. War mir bisher gänzlich unbekannt. Ergibt aber alles Sinn. Auch wenn wir am Raspi kein USB 1.1 haben, so dürfte doch genau hier damit meine Logik passen. Bei DVB-T ist Transponder Bitrate außerdem viel geringer.
http://de.wikipedia.org/wiki/DVB-T
Demnach haben wir ca. 13-22Mbit je nach Bundesland die sich normalerweise 4 Sender teilen.
http://www.digital-eliteboard.com/272216-ard-neue-hd-sender-kommen-im-dezember-2.html
Bei Sat ist es schon einiges an rechnen und je nach Sendergruppe stark schwankend. Für uns relevant ist aber lediglich dass hier netto Bitraten von 40-80Mbit gefahren werden. Der Overkill sind die Abend Live Shows die mit fast konstanten 17-20Mbit je Sender laufen (kann man wunderbar mit dem Signalmonitor sich am vdr ansehen, die ÖRs in 720P kommen selten über 10 Mbit)
Da macht dann die Begrenzung auf einen einzelnen PID dann das gleiche Ergebniss wie Streamdev.

Soweit die Theorie... Jetzt bin ich gespannt was die Praxis daraus macht...

[Marcus]

Es kommt halt darauf an ob dein Stick einen HW-PID-Filter hat, oder nicht. Ich drück die Daumen!

[Torsten73]

so der Zustand vorher:

Code: [Select]

MLD> dmesg | grep dvb
#[   16.459453]         v4l-dvb-saa716x: dfd91ae70d2d6350c04162f8ac32074be14947e1 saa716x_ff: Align block data on 32 bytes for firmware 0.5.0 and up
[   16.537719]  v4l-dvb-saa716x: dfd91ae70d2d6350c04162f8ac32074be14947e1 saa716x_ff: Align block data on 32 bytes for firmware 0.5.0 and up
[   16.628257] usb 1-1.5: dvb_usb_v2: found a 'DVBSky S960/S860' in warm state
[   16.642914] usb 1-1.5: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
[   16.646867] dvbsky_usb MAC address=00:18:42:54:96:0c
[   16.646913] usb 1-1.5: dvb_usb_v2: MAC address: 00:18:42:54:96:0c
[   17.113763] dvbsky_m88ds3103_load_firmware: Waiting for firmware upload (dvb-fe-ds3103.fw)...
[   17.131024] dvbsky_m88ds3103_load_firmware: Waiting for firmware upload(2)...
[   18.428949] Registered IR keymap rc-dvbsky
[   18.430355] usb 1-1.5: dvb_usb_v2: schedule remote query interval to 300 msecs
[   18.430384] usb 1-1.5: dvb_usb_v2: 'DVBSky S960/S860' successfully initialized and connected
[   18.430624] usbcore: registered new interface driver dvb_usb_dvbsky

Dann mit force_pid_filter_usage:

Code: [Select]

MLD> dmesg | grep dvb
[   17.699446]  v4l-dvb-saa716x: d7e98fc592305a600909003da2b7cc4338242511 saa716x_ff: Do not return on command ready timeout
[   17.769671]  v4l-dvb-saa716x: d7e98fc592305a600909003da2b7cc4338242511 saa716x_ff: Do not return on command ready timeout
[   18.059663] usb 1-1.5: dvb_usb_v2: found a 'DVBSky S960/S860' in warm state
[   18.060524] usb 1-1.5: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
[   18.062018] usb 1-1.5: dvb_usb_v2: MAC address: 00:18:42:54:96:0c
[   18.167651] usb 1-1.5: dvbsky_s960_attach fail.
[   18.170887] usbcore: registered new interface driver dvb_usb_dvbsky
Das funktioniert also hier bei dem S960 leider nicht. Ich werde mal den technischen Support kontaktieren, ob es hier eine Möglichkeit gibt. Wohlmöglich aber nur mit dvbsky Treiber dann.

Edit: Stop ich glaube hier muß ich erst was anderes reparieren. der zeitgleich durchgeführte dvb upgrade erlaubt mir auch ohne die Option keinen Empfang mit gleichem Fehler! Außerdem muß ich hier nicht dvb_usb sondern vermutlich dvb_usb_v2 nehmen?

Edit2: Dank der tollen Backup Funktion in MLD habe ich das Update von heute Rückgängig gemacht und nochmal mit funktionierendem dvb Modul probiert. Mit dem Ergebniss, dass die Option nichts bewirkt. auch nicht in dmesg. Ich habe nun dvbsky angeschrieben, ob die überhaupt irgendetwas ähnliches haben.

[meierchen]

Hallo,
ich klink mich hier mal ein.
Habe seid 2 Wochen jetzt eine Rasbperry Pi B+ und wollte diesen als Ersatz meines Tv-Servers laufen lassen aufgrund des geringeren Stromverbrauches weil das Fernsehprogramm meinen Atom basierten Server nicht auslastet.
Das System läuft bei mir jetzt seid ungefähr 4 Jahren. Durch die Erfahrung durch verschiedene VDR Versionen und Streamdev Lösungen bin ich letztendlich beim Tvheadend hängen geblieben da diese am stabilsten für den Stream am laufen ist. Als Frontend zuerst mit AppleTV2 mit XBMC(jailbreak) und seid 2 Jahren auch ein Raspberry PI B mit dem auch dann HD bei mir eingezogen ist in Form von HD+/Sky HD. Das läuft mit meinem aktuellen System astrein. Jetzt bin ich dabei am neuen Raspberry mit seperater TV Karte TT S2-4600 das System ans laufen zu bringen. Durch die default einstellungen des Serverimages von MLD zuerst den Streamdev getestet der anhand von sehr vielen Fehler in Form von Artefakten aufgefallen ist. Dann den tvheadend drauf gemacht und konfiguriert. Normal SD läuft ohne Probleme. Gestern Abend während des Länderspiels Das Erste HD(720p) geschaut lief noch gerade so allerdings ab und zu leichte Ruckler und Bildartefakte gesehen. Bitrate in dem Moment wohl zu hoch. Dann noch Sky HD(1080i) gestestet war praktisch unansehbar. Der Ton war dann schnell versetzt und mehr Artefakte als unter Das Erste.
Getestet jeweils mit meinem bestehenden Raspberry PI Model B Frontend mit Openelec installiert da habe ich mit meinem Atom Server nie Probleme mit gehabt! Also die Raspberry kann damit umgehen.
Ich habe auf dem neuen Raspberry PI noch keine Lizenz erworben für die Video wiedergabe sollte aber auch nicht erforderlich sein wenn man reinen Streaming Server nutzt ohne Anzeige auf einem Fernseher oder?
Die TV Karte ist ohne aktiven Hub angeschlossen sollte doch reichen weil externe Stromversorgung dran ist?
Der HW-PID schalter hat bei mir auch nix bewirkt bzw wird wohl ignoriert weil nicht unterstützt.
Die Auslastung unter Das Erste HD ist bei mir bei etwa 60% ohne übertakten das hab ich noch nicht probiert.
Bei irgentnem Sky HD Sender bei 100% okay das würde die Artefakte erklären


Update: Mal die Auslastungen(Top) getestet bei SD HD720p HD1080i
RPi          | Ohne OC | Mit OC High(950)
SD          | 50%        | 45%
HD720p  | 70%        | 60%
HD1080i | 100%      | 96%
Mein alter Atom:
SD 11%
HD720p 12%
HD 1080i 20%

Durch das übertakten sehe ich mittlerweile was in 1080i

[Torsten73]

Ohne die mpeg Lizenz kann man weder bei Streamdev noch mit DVB Empfänger einen SD Sender oder Aufzeichnung sehen. Außer und das weiß ich bei Openelec nicht, es wird soft dekodiert. Aber über die GPU benötigt immer den Lizenzschlüssel. Das Raspihddevice decodiert in der Grafikkarte und deshalb sollte hier eine geringere Last sein.
Das hilft aber nichts, wenn der USB Chip überlastet ist. So viel IO gibt der nicht durch. Daran kann man auch mit übertakten nichts ändern.