Beiträge von Dr. Seltsam

Ein weiteres Problem ist die unterschiedliche GOP-Länge. Ich zitiere mal jojo61:

Zitat

VDR sendet tatsählich nur I-Frames beim spulen. Dazu wird dann Trickspeed gesetzt um anzuzeigen wie oft das Frame wiederholt werden soll. Bei MPEG2 funktioniert das auch ganz nett. Aber bei H264 sind die I-Frames doch recht weit auseinander und da rennt dann das Bild sehr schnell. Grund hierfür ist das Trickspeed auf 1 sitzt wenn man kein Multi Speed aktiviert hat. Mit aktiven Multispeed sieht es besser aus weil da Trickspeed mit 6 anfängt (d.h. jedes I-Frame wird 120ms angezeigt) und damit ergibt sich eine sinnvolle Zeitlupe.

Eigentlich müsste Trickspeed an die Frequenz der I-Frames angepasst werden. D.h. bei Mpeg2 anders als bei h264 sein, wenn man die gleiche Zeitlupe oder Zeitraffer haben will

Was mir noch nicht klar ist: Schickt vdr bei einfacher Zeitlupe rückwärts jetzt 63 mal das gleiche i-frame, oder ist es Aufgabe des Ausgabedevices, ein einzelnes angeliefertes i-frame 63 mal zu wiederholen?

Das kommt ja noch aus der Zeit der FF Karten und wurde im dvbsddevice-Plugin so umgesetzt, dass speed (also hier die 63) ein Parameter für das av7110-soezifische ioctl ist, der die Anzahl der Wiederholungen festlegt. Demnach vermute ich, dass letzteres zutrifft.

Für DVB-C habe ich die WinTVdualHD auf die Antennensteckdose gesetzt und verwende für die Leitung zum VDR ein weiches durchgehendes USB-Verlängerungskabel. Den Tip von blau im letzten Absatz kann ich nur unterstreichen.

jojo61: Sehr schön, Danke. Ich war schon am grübeln, denn eigentlich funzt das zuverlässig. Immer wenn PlayMode 0 kommt (beim Umschalten oder beim Beenden einer Wiedergabe), wird auch amlReset aufgerufen, und da wird dann die blackout policy gesetzt.

Eine der drei compiler warnings habe ich übrigens gefixt. Die anderen (aml...) begreife ich nicht - das müsste dann ja an zahllosen anderen Stellen in video.c und softhddev.c auch angemeckert werden...

horchi: Auf Dein Einfrier-Problem dürfte der Patch keinen Einfluss haben. Hast Du denn überhaupt ein DVB-device lokal angeschlossen oder schaust Du über einen satip-Server? Wenn ein DVB device dranhängt, dann sollte sich da innerhalb der 4.9er-Kernelversionen eigentlich nichts geändert haben. Das setzt natürlich voraus, dass Du ein von Kernel 4.9 unterstütztes Gerät hast. Falls Du die DVB-Treiber nachträglich aktualisiert hast (Paket des Herstellers oder aus linuxtv media_build) würde ich da mal schauen.

Wenn Du im eingefrorenen Zustand noch per ssh auf das Log kommst, müsste man da mal reinschauen. Bei Ubuntu ist das ja auch /var/log/syslog und überlebt ein reboot.

Falls Du eingrenzen kannst, ab welcher Kernelversion der Fehler auftritt, könntest Du ein diff der Kernelsourcen machen. Ich habe keine Ahnung, wie umfangreich da überhaupt noch Änderungen stattfinden. Gibt es ein git für den Odroid-Kernel? Ich glaube nicht.

Hallo horchi,

die Frage ist aus meiner Sicht, was im Kernel zu dem Stehenbleiben des Bildes geführt hat. Ist es ein amlogic-Problem auf der Dekoderseite? Oder ein Problem mit den DVB-Treibern (lokales DVB-Gerät angeschlossen?). Das Plugin ist ja vermutlich unschuldig, wenn Du wiederum die aktuellste Version kompiliert hast.

War denn die Box noch per SSH ansprechbar oder komplett eingefroren?

Grundsätzlich hat der Kernel von Odroid zwar amlogic-spezifische Anpassungen für die Decoderfunktion, aber er ist nicht so gut gepflegt wie der von CoreELEC. Die haben Insiderinformationen und sind auch beim Kernel 4.9 noch fleißig am patchen. Mein Rat wäre deshalb, auf eine Installation von CoreELEC mit Ubuntu in einer chroot-Umgebung umzusteigen. Es zwingt Dich ja niemand, Kodi zu verwenden

PS: Vielleicht magst Du meinen Patch aus #901 mal testen? Dann haben wir auch eine Rückmeldung von einem Nicht-CE-Nutzer.

Hallo jojo61,

ich möchte hier einen Patch (gegen den aktuellen git-Stand) vorstellen, der primär das Umschaltverhalten betrifft. Im aktuellen Stand ist die Geschwindigkeit ohne FastSwitch ja deutlich verbessert, aber was dabei fürchterlich nervt ist, dass es regelmäßig immer mal wieder beim Umschalten den Effekt gibt, dass das Bild für einen Moment viel zu schnell läuft. (Es ist das gleiche Phänomen, dass -unabhängig vom FastSwitch- auftritt, wenn man aus dem Standbild die Zeitlupe vorwärts aufruft und wieder auf Play (Normalgeschwindigkeit) geht. Man kann das mit FastSwitch auchgut reproduzieren, wenn man auf einen Radiokanal geht, einen Moment wartet und noch bevor Ton kommt wieder auf einen TV-Sender wechselt).

Noch ungeklärt ist, warum das unter VDR*ELEC sehr viel häufiger beim Umschalten auftritt als in einer chroot-Umgebung. Mit aktiviertem FastSwitch hat man hingegen das Problem, dass das Bild zwar sehr schnell da ist und anläuft, dann aber stehen bleibt und auf A/V-Synchronität wartet, ehe es weiter läuft. Das nervt auf Dauer auch gewaltig. Also habe ich nach einem Weg gesucht, das zu verbessern.

Der anliegende Patch macht mehrere Sachen:

• In der audio.c wird in AudioEnque ein Bug beseitigt: Die Auskommentierung für skip = AudioSkip; betrifft m.E. nur das Umschalten ohne FastSwitch. Hingegen wird FirstVPTS an mehreren Stellen in video.c verwendet und sollte deshalb m.E. auch für aktivierten FastSwitch auf 0 gesetzt werden.
• Für das Schwarzschalten während des Kanalwechsels kehre ich zurück zur black policy, die jetzt aber ohne Zeitverzögerung sofort anspringt. Das jeweils richtige Setzen (schwarz oder letzter Frame) wird anhand des PlayModes ermittelt und in amlReset() berücksichtigt. Der amlogic-Parameter disable_video wird zum Umschalten nicht mehr benötigt. Gleichwohl muss er offenbar nach jedem Schließen des devices explizit erneut auf 0 gesetzt werden (macht Kodi auch so). Ich meine, dass die black policy einen Tick schneller funktioniert, wenn es darum geht, den neuen Stream wieder einzublenden. Ein weiterer Vorteil ist, dass -zumindest wenn die letzte Aktion keine Wiedergabe war- das Bild auch bei einem ungeordneten Beenden von vdr (Crash oder killall -9 vdr) schwarz wird. Der bisherige Ansatz in StopVideo hat hier nichts bewirkt, da der Code dann gar nicht mehr zur Ausführung kam.
• In der Funktion Trickspeed habe ich zur Klarstellung die speed-Werte je Funktion als Kommentar hinterlegt. (Eventuell kann das stattdessen auch in VideoSetTrickspeed in video.c.)
• Die beiden bools doPauseFlag und doResumeFlag sind m.E. ungenutzt, daher habe ich sie entfernt
• Einigen toten Code habe ich entfernt. AMSTREAM_IOC_CLEAR_VIDEO bewirkt nichts und wird von Kodi auch nicht verwandt. AMSTREAM_CLEAR_VBUF ist schon im 4.9er Kernel in einem Kommentar als nicht mehr vorhanden beschrieben.
• Der Clou ist, dass bei aktiviertem FastSwitch Videodaten in CodecVideoDecode verworfen werden, bis in AudioEnque AudioRunning true ist. Dadurch startet das Bild fertig synchronisiert. Lediglich einen kurzen Schreckmoment braucht es, bis dieses anläuft. Das dauert zwar einen Tick länger als vorher, wirkt aber professioneller und ist immer noch schneller als ohne FastSwitch. Ich habe es auch mit Ausführung von AudioVideoIsReady versucht, aber das Ergebnis war weniger befriedigend. Ebenso die Platzierung - in SendCodecData dauert das Umschalten dann länger. Deshalb habe ich auch den Code für "ohne FastSwitch" von SendCodecData mal in CodecVideoDecode verlegt. Die Logik sagt mir, dass es sinnvoll ist, das so früh wie möglich auszuführen.
• Damit auch die Bildaktualisierung bei StillPicture (Schneiden) funktioniert, musste ich eine neue Variable "inTrickModeStillPicture" einführen. (Beim Schneiden ist weder TrickMode aktiv noch läuft Audio.)
• Anders als in Deinem letzten commit eingebaut habe ich amlSetInt("/sys/module/amvdec_h264/parameters/dec_control", 4); auch für den Kernel 4.9 vorgesehen - analog Kodi.

Wie sagtest Du mal so schön - man kann leicht Opfer seiner eigenen Erwartungshaltung werden . Im Falle des FastSwitch-Umschaltverhaltens bin ich mir sicher, dass es eine Verbesserung bringt. Ohne FastSwitch meine ich, dass es einen Ticken schneller geworden ist. Aber das will ich nicht beschwören.

der crash hat m.E. nichts mit dem fehlenden Ton zu tun. Vielleicht versucht vdr beim ATTA auf Ressourcen zuzugreifen, die Kodi noch nicht freigegeben hat. Der zusätzliche amixer-Befehl könnte genau die Verzögerung bewirken, bis die Resourcen frei sind.

Crasht es auch, wenn Du statt des amixer-Befehls ein "sleep 1" einträgst?

und mit dem um den amixer-Aufruf ergänzten Script kommt es nicht mehr zu vdr-Neustarts, wenn man von Kodi (darin Film abgespielt) zu vdr zurückwechselt?

Zitat von Zabrimus

Ich sehe grade, das im Switch-Script schon ein

Code

echo 4 > /sys/module/amvdec_h264/parameters/dec_control

vorhanden ist

Moin Zabrimus,

kannst Du rekonstruieren, woher das kommt? Man findet diese Empfehlung oftmals im Netz, aber was sie konkret bewirkt, bleibt geheimnisvoll.

Ein commit in einem anderen Projekt verweist auf einen commit für BBC TV

Kodi setzt dies auch bei ng (4.9 Kernel) in der AMLCodec.cpp standardmäßig:

// DEC_CONTROL_FLAG_DISABLE_FAST_POC
CSysfsPath("/sys/module/amvdec_h264/parameters/dec_control", 4);

Ich habe keine Ahnung fast "fast poc" sein soll. Wenn das notwendig ist, sollte jojo61 es ins Plugin in VideoInit() aufnehmen.

vdr kann diese Codes nicht direkt verarbeiten, sondern erwartet lirc-Codes. Versuch mal das remote-Plugin. Oder einen Übersetzungs-daemon wie eventlircd.

Zitat von Zabrimus

Ich sehe grade, das im Switch-Script schon ein

Code

echo 4 > /sys/module/amvdec_h264/parameters/dec_control

vorhanden ist und die beiden anderen Änderung irgendwas mit debug zu tun haben. Ich fürchte, die Änderung wird nicht viele Auswirkungen haben, oder?

Die beiden anderen sind m.E. deinterlacer-Einstellungen und können durchaus etwas bewirken. Kodi setzt sie bei VC1.

Die Frage ist, ob das Plugin die Werte über die sysfs-Schnittstelle setzen kann. Per command line waren die Parameter im Kernel 4.9 vorhanden, mit dem cat-Befehl aber nichtmal abfragbar. Vielleicht ist das beim 5er Kernel (ne, no) anders.

Bei einer Änderung des switch-Scriptes sollte man testen, ob das dann beim 4.9er Kernel an der Stelle nicht mit Fehler abbricht. Besser wäre es, im Script die Kernelversion zu ermitteln. Aber halt, das ist ja nur ein Provisorium zum Testen und gehört wenn es funktioniert ins Plugin.

Vergleich mal bitte die Ausgaben von

cat /sys/class/deinterlace/di0/debug
cat /sys/module/di/parameters/di_debug_flag

im 'gut' und 'schlecht'-Fall.

Ich habe Unterschiede mal so ermittelt:

mkdir /storage/Test-gut
mkdir /storage/Test-schlecht

Vorher (gutes Bild):

cp -R /sysy/class/* /storage/Test-gut

Nachher (schlechtes Bild):

cp -R /sysy/class/* /storage/Test-schlecht

Es kommen jeweils ein paar Fehlermeldungen, die kann man ignorieren

Dann:

diff -ur /storage/Test-gut/ /storage/Test-schlecht/ > /storage/Unterschied.diff

Die relevanten Unterschiede in der Hardwareinitialisierung sind meist in /sysy/class/video und sysy/class/tsync zu finden. Entweder sind das Parameter, die direkt per sysfs call gesetzt werden oder per ioctl. In letzterem Fall kommt man mit einer Begriffssuche in den Kernelsourcen evtl. weiter.

Zitat von Paulaner

• Die Streaming-Dienste in UHD/4K mit HDR gehen natürlich nur unter Android. Entweder mit den Android -Apps oder auch den KODI -Addons. Getestet habe ich dabei nur Prime-Video, da ich keine anderen Streamingdienste abonniert habe.

Erreichst Du unter Kodi bei Amazon Prime mehr als 480p? Mein Kenntnisstand ist, dass nicht nur die Hardware sondern auch die Software lizenziert sein muss.

wurde schon erwähnt

Beitrag

RE: [gelöst]HDMI Eingang als Kanal

So, Live und Aufnahmen über VDR mit dem alten HDPVR (https://www.hauppauge.de/site/products/data_hdpvr.html) über USB mit Component>HDMI Adpater mit 50 und 60 FPS inklusive Ton über SPDIF funktioniert. Das ist grundsätzlich schon mal ok.

Was nicht schön ist, wenn die Quelle am HDPVR ausgeschaltet wird oder einen andere Auflösung bekommt bricht der VDR ab bzw. man kann nicht mehr auf den Tunen tunen und muß erst VDR neu starten.

Was ist mit neuerer Hardware wie z.B. dem Hauppauge Colossus 2 (…

don-baba

23. März 2024

Linuxtreiber (soweit man das so nennen kann) kann auch HD nur in mpeg2. Die Integration in vdr wird mindestens ebenso aufwändig wie die laufenden Versuche mit zattoo.

Der Adapter sollte HDMI in YPbPr wandeln, damit ich das der HDPVR zuführen kann. Ein anderes Gerät mit YPbPr-Eingängen habe ich nicht. Schließe ich direkt einen Bluray-Player mit YPbPr-Ausgang an, kann ich aufzeichnen.

AC3-Aufnahme funktioniert. Und Ton hörte ich auch. Möglicherweise läuft das ac3-Signal dann unter einer PID, die eigentlich für mpeg-Ton gedacht ist. Geht aber.

Benutzt Du fertige Pakete oder kompilierst Du selbst? Falls letzteres, kann ich Dir meine überarbeiteten Sourcen von pvrinput zur Verfügung stellen.

Zitat von don-baba

Gibt es irgendwo eine Liste welche VPID und APID es gibt?

Wenn man z.B. einem PVR oder IPTV Kanal mitgeben will das er Dolby Digital sendet und das der VDR das dann auch erkennt.

In der Man Page steht nur falls ein Sender Dolby Digital anbietet dann steht dann erkennt VDR das. Aber bei IPTV und ggf. PVRinput Einträgen müsste man das noch händisch nachtragen...

Für pvrinput habe ich auch nur diese Information:

Zitat

This box sets the PIDs to 4352 for audio, 4113 for video and 4097 for the PCR.

And it's better to tell vdr the type of video (H.264 has a stream type of 27).

Daraus ergibt sich dann z.B.

HD PVR Component:1:COMPONENT:V:0:4113+4097=27:0;4352:0:0:1:1:9011:0

4352 ist dann wahrscheinlich die PID für normales mpeg-Audio? Hast Du eine gültige PID für Dolby Digital-Ton gefunden?

Bei den übrigen PVR-Karten (die selbst keinen TS liefern können) wird dieser mit fest kodierten PID-Werten im Plugin generiert:

static const short kVideoPid    = 301;
static const short kAudioPid    = 300;
static const short kTeletextPid = 305;
static const short kPCRPid      = 101;

Für die HDPVR wird hingegen der TS-Stream genommen, der von der Box kommt. Wenn darin irgendwas fehlt, was vdr für die Autoerkennung benötigt, kann das Plugin daran leider nichts ändern. Die Neugenerierung eines TS steht nicht auf der Agenda.

Ich bin mit der HDPVR und pvrinput noch nicht allzuviel weitergekommen. Da kein 1080/24p möglich ist, ist mein Interesse auch etwas abgeflaut. Zudem habe ich immer noch keinen funktionierenden HDMI->Component Adapter. Habe schon zwei gebrauchte gekauft. Der erste Verkäufer hat stattdessen ein SPDIF Coax auf Toslink-Adapter geschickt und ist uneinsichtig. Der zweite Adapter von einem anderen Verkäufer funktioniert nicht.

Du schriebst an anderer Stelle:

Zitat von don-baba

Was nicht schön ist, wenn die Quelle am HDPVR ausgeschaltet wird oder einen andere Auflösung bekommt bricht der VDR ab bzw. man kann nicht mehr auf den Tunen tunen und muß erst VDR neu starten.

Ich kann das leider mangels Adapter/Geräten nicht nachtesten. Was genau passiert denn? Was führt laut Log zum Abbruch? Ist es wirklich ein Abbruch, oder erkennt vdr (zumindest beim Ausschalten der Quelle) einen Streamabbruch und macht einen Notausstieg? Wie verhält sich cat /dev/video0 > test.mp4 bei einem Wechsel der Auflösung der Quelle? Gibt es dann keinen Abbruch? Wenn vdr dabei abbricht, ist mir die Ursache noch unklar.

Ich kann im Moment nur mit FBAS und fixen 720x576 testen.

Zitat von Dr. Seltsam

Das kannst Du im iptv-Plugin evtl. Umgehen, indem Du dort „Benutze Abschnittsfilter“ auf ja stellst. Dann deaktivierte Filter auf 1 und Filter 1 auf „PAT (0x00)“.

hilft das nicht gegen das ungewollte Entfernen der Audio-Pids in der channels.conf?

Meines Erachtens müsste das Zusammensortieren der Pakete in der richtigen Reihenfolge durch die Hardware bzw. im Kernel erfolgen. Bei dem von amlogic gepatchten Kernel 4.9 funktioniert das jedenfalls, ohne dass nach meiner Kenntnis softhdodroid eine Vorsortierung vornehmen muss. Vielleicht kann jojo61 dazu mehr sagen.

Zitat von Paulaner

Hier gab es dann allerdings ein Problem mit den Audio-PIDs, denn da wurden immer die eAC3-PIDs vom VDR gelöscht

Das kannst Du im iptv-Plugin evtl. Umgehen, indem Du dort „Benutze Abschnittsfilter“ auf ja stellst. Dann deaktivierte Filter auf 1 und Filter 1 auf „PAT (0x00)“.

Zitat

kann ich auch direkt über das vdr-plugin-iptv  die Streams anschauen.

Mir wird allmählich schwindelig. Ich denke, das geht NICHT direkt, sondern nur mit Transkodierung über ein Script in Verbindung mit vlc?