Hallo Thomas,
meiner Meinung nach ist die jetzige GIT-version die Beste die du bisher veröffentlich hast. Konnte nur kurz Testen aber die Umschaltzeiten sind schnell, das Bild ist nahezu perfekt, der Ton stottert nicht mehr. Bin Begeistert 
Fehlt nur noch die GPU-Unterstützung für den skindesigner.. Aber alles der Reihe nach....
VG Uli
Ich hatte die Firmware erst kurz vorher upgedated, aber da hat sich doch einiges getan.
Nach Firmware Update und Neubauen des plugins geht nun auch HD.
Danke für den Hinweis.
reufer: http://c-reimer.de/temp/record.tar.bz2
Es ist wirklich nur ein ganz kleines Stück. Und nachdem ich es eingepackt hatte ist mir eingefallen, dass der Index noch von der längeren Aufnahme ist. (gekürzt mit dd)
Der müsste also neu erstellt werden.
reufer: http://c-reimer.de/temp/record.tar.bz2
Es ist wirklich nur ein ganz kleines Stück. Und nachdem ich es eingepackt hatte ist mir eingefallen, dass der Index noch von der längeren Aufnahme ist. (gekürzt mit dd)
Der müsste also neu erstellt werden.
Danke für die Aufnahme. Diese spielt bei mir aber wunderbar, und das Log zeigt keine Auffälligkeiten.
Ich vermute schwer, dein Stream ist zu Beginn noch nicht richtig entschlüsselt und bringt den Audio-Parser durcheinander. Ich gehe davon aus, dass du während dessen auch kein Bild siehst? Solche Daten werden vom VDR auch nicht aufgezeichnet, daher wird die Aufnahme den Fehler auch nicht zeigen.
Gruss
Thomas
Nein, Bild sehe ich auch keins
Nein, Bild sehe ich auch keins
Ok, dann wird es höchstwahrscheinlich ein Entschlüsselungsproblem sein. Die Videopakete gebe ich praktisch 1:1 an den Decoder weiter - ist also kein Bild zu sehen, ist der Stream korrupt.
Gruss
Thomas
Wie beseitigt man das am besten?
Konnte nur kurz Testen aber die Umschaltzeiten sind schnell, das Bild ist nahezu perfekt, der Ton stottert nicht mehr. Bin Begeistert
Wunderbar!
Da scheinbar auch sonst keine grossen Probleme aufgetreten sind, habe ich eine neue Version 0.0.11 erstellt:
2015-01-21: Version 0.0.11
--------------------------
- new:
- reworked audio decoder, increase buffering of audio samples
- reworked omxdevice and improved clock stretching for transfer mode
- added Hungarian translations (thanks to Füley István)
- updated Finnish translations and fixed tr() usage (thanks to Rolf Ahrenberg)
- use fast deinterlacer for HD streams
- added high level OSD with GPU support
- fixed:
- start H.264 video with valid frame only, requires firmware from 2015/01/18
or newer
Als nächstes steht die Fertigstellung der GPU-Unterstützung fürs OSD an. Dann sollte ich alles für die Beta beieinander haben...
Gruss
Thomas
Wie beseitigt man das am besten?
Das ist Sache des VDR, bzw. des entsprechenden Plugins - rpihddevice kann hier nichts weiter tun, als die korrupten Daten zu ignorieren.
Gruss
Thomas
Und planst du so ein Ignorieren einzubauen?
Thomas: In Deiner Liste was in 0.11 drin ist fehlt der ZDF Patch.
Oh, und wenn es nach mir ginge dann wuerde ich natuerlich vor allem gerne Deine Version des Patches von mir sehen womit der omxplayer im mplayer-plugin laufen kann.
Thomas: In Deiner Liste was in 0.11 drin ist fehlt der ZDF Patch.
Moin,
die Firmware wurde angepasst, somit entfällt der "ZDF-Patch".... Steht in einen der vielen rpi Threads, ich finde ihn gerade nicht.... 
Und planst du so ein Ignorieren einzubauen?
Ich werde versuchen, den Audio-Parser weniger anfällig auf korrupte Streams zu machen, ansonsten will ich die Daten möglichst nicht analysieren. Das Plugin soll aber natürlich robust genug sein und solche Fehler überleben ohne abzustürzen.
Oh, und wenn es nach mir ginge dann wuerde ich natuerlich vor allem gerne Deine Version des Patches von mir sehen womit der omxplayer im mplayer-plugin laufen kann.
Teste doch mal selber deinen Patch mit der aktuellen Version des Plugins - ich habe da einiges vereinfacht und fahre eigentlich die meisten Ressourcen runter, wenn kein Stream läuft. Könnte gut sein, dass deine Version vom mplayer-Plugin out of the box läuft...
Gruss
Thomas
tscha, der update zur 0.0.11 Version des Plugins war bisher ein totales desaster 
Habs erstmal mit meiner derzeitigen Firmware laufen lassen. 3.12.35+.
SD prima.
ZDF HD Kanaele: syslog beschwert sich in etwa mit "nehmen sie neue Firmware", tut aber prima (bild, ton, kein Zeitversatz zwischen beiden).
Andere HD Kanaele: Bild schwarz, Ton nach 10 Sekunden. Bild bleibt schwarz
Omxplayer schmiert ab, 0.0.11 ersetzt also nicht den patch um alle resourcen vom rpihddevice freizugeben wenn externer player angeschmissen wird.
Ok, muss ich also Firmware upgraden, obwohl die neue 0.0.11 Version ja anscheinend zeigt, dass man ZDF HD auch mit alter RPI Firmware und ohne 100 Hz fixup ja anscheinend prima laufen lassen kann (sehr merkwuerdig).
Also rpi-update angeschmissen, und dabei kam dann das hier raus:
Raspian update 3.18.3+ kaputt !?!
Was habt Ihr so als Firmware laufen ? Irgendjemand bei dem die 3.18.3+ vom Mittwoch dieser Woche erfolgreich laeuft ?
Andere HD Kanaele: Bild schwarz, Ton nach 10 Sekunden. Bild bleibt schwarz
An der Stelle wäre ein Ausschnitt aus dem Log natürlich enorm hilfreich...
Omxplayer schmiert ab, 0.0.11 ersetzt also nicht den patch um alle resourcen vom rpihddevice freizugeben wenn externer player angeschmissen wird.
Ich habe jetzt mal aus Jux den omxplayer aus der Shell angeworfen, während vdr + rpihddevice läuft, aber kein Stream aktiv ist. Das läuft soweit wunderbar und sollte daher auch aus einem Plugin funktionieren.
Ich kann sogar, während omxplayer läuft, eine Aufnahme vom VDR starten und höre von beidem den Ton, nur hängt sich dann nach ein paar Sekunden der Videodecoder auf, was man ihm aber kaum verübeln kann. 
Ok, muss ich also Firmware upgraden, obwohl die neue 0.0.11 Version ja anscheinend zeigt, dass man ZDF HD auch mit alter RPI Firmware und ohne 100 Hz fixup ja anscheinend prima laufen lassen kann (sehr merkwuerdig).
ZDF HD lief ja immer schon, wurde einfach nur unnötig deinterlaced und konnte früher auch schon mal den Advanced Deinterlacer aus dem Tritt bringen.
Gruss
Thomas
Ok, DeviceTree im neuen 3.18'er Kernel war schuld. Mit der entsprechenden Overlayconfig geht es jetzt im Prinzip. SD/HD sehen gut & synchron aus. Hatte vorher aber fast nie knacksen, muss also mal laenger hinhoeren um sicher zu sein dass die alle eliminiert sind ![:]](https://www.vdr-portal.de/images/smilies/pleased.gif "Freude"){kind=small}
Probleme:
a) mplayer/omxplayer
b) Ein paar Kanaele wie dieser hier. Kein Bild, nur Ton der dann auch noch immer unterbricht. Geht mit der alten version vom plugin auch mit der neuen RPI firmware. Muss also was mit der Art zu tun haben, wie das neue Plugin funktioniert denke ich.
AstroTV;BetaDigital:12480:VC34M2S0:S19.2E:27500:2559=2:2560=deu@3:0:0:661:133:33:0
Jan 23 12:35:38 rpi-eckert vdr: [30716] receiver on device 2 thread started (pid=29544, tid=30716, prio=high)
Jan 23 12:35:38 rpi-eckert vdr: [30717] TS buffer on device 2 thread started (pid=29544, tid=30717, prio=high)
Jan 23 12:35:39 rpi-eckert vdr: [29564] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz
Jan 23 12:35:39 rpi-eckert vdr: [30716] rpihddevice: set video codec to MPEG2
Jan 23 12:35:39 rpi-eckert vdr: [30716] rpihddevice: failed to start clock!
Jan 23 12:35:39 rpi-eckert vdr: [29560] rpihddevice: video stream started 720x576@50i
Jan 23 12:35:44 rpi-eckert vdr: [30716] ERROR: TS packet not accepted in Transfer Mode
Jan 23 12:35:44 rpi-eckert vdr: [29564] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz
Jan 23 12:35:44 rpi-eckert vdr: [30716] rpihddevice: failed to start clock!
Jan 23 12:35:50 rpi-eckert vdr: [30716] ERROR: TS packet not accepted in Transfer Mode
Jan 23 12:35:50 rpi-eckert vdr: [29564] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz
Jan 23 12:35:50 rpi-eckert vdr: [30716] rpihddevice: failed to start clock!
Ich habe jetzt mal aus Jux den omxplayer aus der Shell angeworfen, während vdr + rpihddevice läuft, aber kein Stream aktiv ist. Das läuft soweit wunderbar und sollte daher auch aus einem Plugin funktionieren.
Ich kann sogar, während omxplayer läuft, eine Aufnahme vom VDR starten und höre von beidem den Ton, nur hängt sich dann nach ein paar Sekunden der Videodecoder auf, was man ihm aber kaum verübeln kann.
Jo, zum testen obs geht hat bei mir auch immer funktioniert, einfach parallel zum VDR heaus was mit omxplayer abzuspielen. Der omxplayer schmiert immer nach < 1 minute ab, wenn ich etwas mit untertitel abspiele. Ich schick Dir mal ein Beispiel.
ZDF HD lief ja immer schon, wurde einfach nur unnötig deinterlaced und konnte früher auch schon mal den Advanced Deinterlacer aus dem Tritt bringen.
Nochmal:
Auf meinem RPI lief die alte RPI Firmware, die 100 Hz erkannt hat. Ich lasse das mit altem rpihddevice treiber laufen. Ton wird asynchron.
Gleicher RPI, gleiche Firmware, neue 0.0.11 version: rpihddevice meckert zwar "looks implausible,...", aber der ton ist astrein und wird nicht asynchron.
Und die 0.0.11 macht ja keinen fixup (interlace = false) wenn sie die "100 Hz" entdeckt. Bloss meckern.
Erklär das Verhalten doch mal ..
Für mich beeutet das, dass dein neuer code im 0.0.11 es irgendwie auch schafft dass die alte firmware, obwohl sie interlaced arbeitet den Ton nicht aus den tritt kommen zu lassen.
Ist ja nicht relevant weil man eh die neue Firmware einspielen will, aber faszinierend ist es schon.
Jo, zum testen obs geht hat bei mir auch immer funktioniert, einfach parallel zum VDR heaus was mit omxplayer abzuspielen. Der omxplayer schmiert immer nach < 1 minute ab, wenn ich etwas mit untertitel abspiele. Ich schick Dir mal ein Beispiel.
Ok, dass es an den Untertiteln liegt, ist natürlich eine wichtige Information. Hier blockiert tatsächlich die OSD-Implementation vom Plugin gewisse Ressourcen. Da ich aber sowieso noch einen Umbau des OSDs geplant habe (Fertigstellung der GPU-Unterstützung), kannst du dir die Mühe sparen. Ich versuche, das bei den bevorstehenden Änderungen im Hinterkopf zu behalten...
Gruss
Thomas
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
