Posts by Dr. Seltsam

Bei mir kommen auch schon seit einiger Zeit keine Benachrichtigungen mehr an. Hinterlegt ist eine gültige gmx-Adresse. Auch im Spam-Ordner habe ich nichts gefunden.

SurfaceCleanerZ wrote:

Hi,

Andere scheinen mit den Allwinner ganz zu frieden zu sein.

Frag Dr. Seltsam mal dazu!

MfG Stefan

zu Allwinner kann ich nichts sagen, aber zu Amlogic

Mit dem softhdodroid-Plugin kann man auf dem Odroid N2 bzw. N2+ sowie etlichen Chinaboxen mit S905X3-amlogic-Chipsatz einen vdr laufen lassen. Das läuft bereits erstaunlich stabil. Ein Betrieb zusammen mit kodi ist möglich, dazu gibt es im wesentlichen zwei Ansätze: Ein angepasstes CoreElec-image von Zabrimus, in dem auch vdr läuft. Oder ein CoreElec mit integrierter Ubuntu-chroot-Umgebung für vdr.

Mein N2+ ist mit angeschlossener USB-SDD im Prinzip ein vollwertiger vdr. Einschalten per FB und acpi-wakeup funktioniert. Die Bildqualität ist super.

Nachteil: Es läuft nur ein von amlogic gepatchter 4.9-Kernel, und vdr sowie kodi müssen als root laufen. Es wird an einer Integration in den mainline-Kernel gearbeitet, und wenn das irgendwann mal fertig werden sollte, ist das Plugin hinfällig. Wahrscheinlich kann man dann softhddevice-drm benutzen. Das läuft bisher mit etlichen Allwinner-Boxen, wobei ich selbst da keine Erfahrungen habe.

jojo61 : magst Du das noch einchecken:

es entfernt lediglich die falsche Begrenzung auf speed 6. Der Rest ist Formatierungskorrektur.

Alle Geschwindigkeiten funktionieren, sowohl FF/REW als Zeitlupe vor und zurück.

Bei der Zeitlupe gibt es noch das Problem, das nach dem Wechsel vom Standbild zur Zeitlupe vorwärts das Bild erstmal ein Stück schnell vorwärtsläuft, ehe die langsame Zeitlupe beginnt. Das untersuche ich noch.

Und bei h264 funktioniert die Bildaktualisierung beim Rückwärtslauf nicht. Letzteres könnte vielleicht daran liegen, dass in PesParse einiger h264-spezifischer Code fehlt, der an der Stelle in softhddevice vorhanden ist.

jojo61 Kannst Du Dich erinnern, warum Du in VideoSetTrickspeed den speed-Wert auf 6 begrenzt hast?

Das macht m.E. keinen Sinn.

die device.h von vdr beschreibt

So wie es ist, kann die Zeitlupenfunktion also nur vorwärts in Stufe 2 und 3 richtig funktionieren.

Ich habe es jetzt mal mit einer mpeg2-Aufnahme (SD RTL) getestet. Dort klappt das Spulen vorwärts und rückwärts einwandfrei. Man sieht die einzelnen Frames und es läuft flüssig. Das Problem scheint nur bei h264 zu existieren. Wobei ich bisher nur 720p getestet habe. Muss mal suchen, ob es frei empfangbare 1080i Sender im Kabel gibt.

Ja, das ist auf alle Fälle noch eine Baustelle. Ich zitiere mich aus #373:

Quote

Das Springen geht verzögerungsfrei, nur das Spulen ist nicht ganz flüssig. Es werden anscheinend nicht alle Frames angezeigt, und alle paar Sekunden bleibt das Bild bei einem Frame stehen. Beim Rückwärtsspulen aktualisiert sich das Bild gar nicht, aber das war schon immer ein Problem auch bei den anderen softhd*-Plugins und mag auch vom Sender und der Aufnahme abhängen

Ich habe noch nicht ganz verstanden, wie das Spulen überhaupt umgesetzt wird. Der Amlogic Treiber scheint nicht selbst verschiedene Abspielgeschwindigkeiten per ioctl zu unterstützen, sondern nur einen allgemeinen Trickmode.

tja, da habe ich keine Idee. Vielleicht kann jojo61 nach seinem Urlaub mal schauen, ob andere Programme wie kodi für den S905Y besonderen Code verwenden.

Amlogic ist leider mehr oder weniger undokumentiert.

Tja, da bin ich auch überfragt. Empfangsprobleme kannst Du ausschließen? Was ist Deine iptv-Quelle? Sind die Einträge der channels.conf korrekt?

Ein DVB device hast Du ja nicht

Diese timeout-Kernelmeldungen vom Decoder habe ich jedenfalls nicht.

Dieter schrieb in VDR auf 40€ TV-Box - Tanix TX3 und ähnlichen Amlogic basierten Boxen

Quote

Den S912 sollte man meiden, ebenso die anderen Varianten with S905X4, X2, X, W und L.

Den S905Y erwähnt er nicht, aber vielleicht weiss er mehr

Bei mir bringt

journalctl |grep 'AmlCodec: amstream version'
die Ausgabe

Jun 23 10:15:27 CoreELEC vdr[4050]: AmlCodec: amstream version : 2.0

Gibt es neben dmesg ein syslog? dmesg enthält keine Meldungen von vdr bzw. seinen Plugins.

Im Code von softhdodroid gibt es einen Check der Version:

Die Frage wäre, welche Version da erkannt und geloggt wurde. Wenn der S905Y wie ein normaler S905 behandelt werden muss, aber wegen einer falschen Erkennung (vielleicht ist die Zuordnung im Plugin auch nicht korrekt) als S805 behandelt wird, könnte das die Probleme vielleicht erklären.

Im Makefile ist CONFIG := -DDEBUG  standardmäßig aktiv, so dass die Debug-Ausgabe geloggt werden müsste.

zabrimus hat ja in seinem Thread geschrieben, dass er den Patch zur optionalen Verwendung integriert hat.

heiko322 wrote:

Ich habe auch mal mit dem Parameter /sys/class/tsync/slowsync_enable herumgespielt. Beim Live-TV ist zwar ein Unterschied; aber dieser ist für mich subjektiv minimal. Was ich jedoch festgestellt habe ist, dass das Spulen und Springen in Aufnahmen mit auf "1" gesetzten Wert deutlich flüssiger funktioniert. Ohne den Wert ist die Navigation durch die Aufnahme durch die Verzögerung bis zum Bild stark erschwert.

Das erstaunt mich, denn ich habe diesbezüglich keinen Unterschied beim Spulen und Springen bemerkt. Das Springen geht verzögerungsfrei, nur das Spulen ist nicht ganz flüssig. Es werden anscheinend nicht alle Frames angezeigt, und alle paar Sekunden bleibt das Bild bei einem Frame stehen. Beim Rückwärtsspulen aktualisiert sich das Bild gar nicht, aber das war schon immer ein Problem auch bei den anderen softhd*-Plugins und mag auch vom Sender und der Aufnahme abhängen.

Der Vorteil des slowsync_enable beim Umschalten bei Live-TV kommt erst richtig zur Geltung, wenn auch die von mir in #367 beschriebene Änderung reinkompiliert wird. Die wiederum macht das Umschalten ohne slowsync_enable aber schlechter.

Ich habe jetzt mal einen Patch erstellt, der das Umschaltverhalten per OSD in den Plugin-Einstellungen konfigurierbar macht und einige Fixes enthält.

• Die Einstellung "Fast channel switch" setzt /sys/class/tsync/slowsync_enable auf 1. Klingt paradox, hat aber nunmal diese Auswirkung. Diese Einstellung habe ich als Standard gesetzt (softhdodroid.FastSwitch = 1). Solange die Einstellung aktiviert ist (und nur dann), ist die oben in #367 beschriebene Änderung für die Audiosychronisation aktiv. Nach dem Umschalten bleibt das Bild kurz stehen, bis Bild+Ton zusammenpassen.
• Die Einstellung "Black during channel switch" bleibt Standard (softhdodroid.BlackPicture = 1), kann aber deaktiviert werden. Dann bleibt das Bild beim Umschalten auf dem letzten frame stehen. Gefühlt geht das Umschalten so noch etwas fixer, aber das ist subjektiv und wird individuell sicher anders empfunden.
• Beim Beenden von vdr (auch beim detachen) wird das Bild schwarz (sys/class/video/blackout_policy = 1) und /sys/class/tsync/slowsync_enable wird wieder auf 0 gesetzt. Damit sind die Treiber-default-Einstellungen wieder hergestellt und es sollte unter kodi keine Probleme geben.
• Beim Umschalten (PLaymode 0) sollten eigentlich die buffer gecleart werden. Das funktionierte in SetPlayMode 0 aber bisher nicht, weil die Bedingung "if (MyVideoStream->ClearClose)" nie erfüllt war (ClearClose ist gar nicht mehr implementiert). Den direkten Aufruf von Clear() halte ich für unglücklich, da es eine vdr-interne Funktion ist, die für den Trickmode vorgesehen ist und immer das Stoppen auf dem letzten frame vorsieht. Deshalb habe ich nur Teile des gleichen Codes in SetPlayMode 0 ergänzt. Allerdings bin ich mir nicht sicher, ob das bezüglich Video überhaupt irgend etwas bewirkt: ClearBuffers soll CodecVideoFlushBuffers auslösen - diese Funktion ist in video.c aber leer. Zumindest die AudioBuffer sollten nun aber gecleart werden.
• Den Sinn der Funktion amlReset() habe ich noch nicht ganz verstanden. Sie wird im Prinzip nur von Clear() und zur Fehlerbehandlung in SendCodecData() aufgerufen. Das Stoppen und Neustarten des Decoders findet aber auch ohne amlReset bereits beim Playmode 0 statt. Nach meinen Experimenten würde es reichen, beim Beenden einer Wiedergabe FirstVPTS = AV_NOPTS_VALUE; und isFirstVideoPacket = true; zu setzen. Einstweilen habe ich es mal so gelassen und lediglich die Behandlung der blackout_policy vereinfacht. Es reicht, sie hier auf 0 zu setzen. Der Wert 1 für ein Schwarzbild beim Umschalten wird über SetPlayMode 0 gesetzt bzw. als Standardwert beim Beenden zurückgesetzt. Das muss nicht jedesmal erfolgen, wenn man in einer Aufnahme springt.

Kannst Du selbst kompilieren oder verwendest Du das image von Zabrimus ? Vielleicht kann er ja meinen Patch mal einbauen, damit mehr Leute das Testen können.

Es kann sein, dass hier die reinen Messwerte und das subjektive Empfinden nicht übereinstimmen.

Ich habe mal zwei Videos hochgeladen.

mit dem o..g. Codeblock:

meine Modifikation ohne den Codeblock

Letzteres finde ich angenehmer. Der Ton kommt sehr früh, und das Umschaltverhalten wirkt m.E. angenehmer. Was meinen die anderen?

In beiden Fällen habe ich übrigens das Schwarzbild beim Umschalten deaktiviert. Der Umschaltvorgang geht jetzt so schnell, dass das Schwarzbild eigentlich nur stört. Vielleicht können wir das als Option im Menü einstellbar machen, ebenso wie slowsync. Wieso das Aktivieren des slowsync nun allerdings das Umschalten schneller macht, bleibt etwas kurios...

jojo61 wrote:

Du kannst mal /sys/class/tsync/slowsync_enable auf 1 setzen. Dann hast du wieder sofort Bild und dann wartet das Video auf den Ton.

Das Umschaltverhalten wird damit nochmal etwas sauberer, wenn man in audio.c den Block

entfernt. Das Audio kommt dann sehr früh, während das neue Bild sofort steht und nach einem kurzen Moment synchron weiterläuft. Andernfalls kommt es zu dem Effekt, dass das neue Bild nach dem Umschalten zunächst noch einen kleinen Moment läuft, ehe es stoppt und wieder weiterläuft.

Mein Vorschlag wäre, /sys/class/tsync/slowsync_enable und diese Änderung als neuen Standard einzubauen.

Ich vermute, dass die Hintergrundaktivität (EPG aktualisieren, neue Kanäle suchen und einfügen) das Problem ist. Da spricht vdr ständig das device an und der USB-Port wird beschäftigt. Ich würde in den Einstellungen zumindest erstmal die Suche nach neuen Kanälen oder gar Transpondern deaktivieren.

Machen das die anderen softhd*-Plugins genauso? Und dass es da fixer geht, liegt dann vermutlich an der stärkeren 'Motorisierung'?

Wird denn ein eigener buffer im Plugin benötigt, oder haben bei amlogic Treiber/Hardware evtl. einen eigenen?

Wäre toll, wenn Du da noch eine wie auch immer geartete Optimierung erreichen könntest.

ja, das wirkt zumindest schneller. Ob es im Ergebnis tatsächlich ein Unterschied wäre, wenn das Bild noch solange schwarz bleiben würde, bis das Video zum Ton passt und weiterläuft, möchte ich aber noch nicht beschwören.

Ich habe gestern und heute -nach der Änderung- ein paar Umschaltvorgänge geloggt. Das Tunen und Locken ist jedenfalls kein Zeitfresser. Vom Set Playmode 0 bis zur Meldung "pesdemux: pes start code id 0xbd" in PesParse() vergehen jeweils kaum 400 ms. Danach sind die Ergebnisse sehr unterschiedlich. Bis zur Meldung " first vpts" aus ProcessBuffer() vergehen weitere 400 bis 1400 ms.

Beispiel (mit Deiner o.g.Änderung!)

Die zweite Spalte gibt jeweils die Millisekunden an, die seit der in der darüber stehenden Zeile vergangen sind.

Man müsste wahrscheinlich noch viel mehr debug-Meldungen einbauen, um das genauer analysieren zu können.

Hast Du die vdr.services irgendwie ergänzt, damit der Dienst erst ausgeführt wird, nachdem das externe Laufwerk gemounted wurde?

Und in der chroot-Umgebung: wo mountest Du? in der runvdr? Brauchst Du noch einen sleep, ehe vdr ausgeführt wird?

Ich kriege hier ständig Abbruchfehler, weil vdr die video-Partition nicht findet, weil sie (noch) nicht gemountet ist

aber im StandardOutput (=Log?) sind die printf-Meldungen ja bei Ubuntu auch nicht zu finden.

Aus der Rubrik "was ich schon immer mal fragen wollte.."

Um Meldungen auszugeben, bietet vdr ja für sich und seine Plugins drei Methoden an, um ins Standard-Log (in der Regel /var/log/syslog) zu schreiben:

Darüber hinaus gibt es sowohl im vdr-Code als auch in vielen Plugins aber auch noch jede Menge Debug-Ausgaben, die mit printf realisiert wurden.

"Früher" (ja, das kann schon 10 Jahre und länger her sein...) hat man vdr auf der Konsole gestartet und sah dann dort die printf-Ausgaben. Das geht schon seit geraumter Zeit nicht mehr. Woran liegt das eigentlich? Ist es eine Änderung in vdr, oder haben die Linux-Distris etwas geändert? Gibt es einen Weg, sich auch die printf-Ausgaben in Echtzeit anzeigen zu lassen, während vdr läuft?