Video Treiber für Odroid-N2+ (softhdodroid)

und was auch noch wichtig ist: Läuft das CoreElec addon-Treiberpaket "dvb drivers from the latest kernel (media_build)" mit dem gepatchten Kernel noch zusammen?

Quote from Dr. Seltsam

Läuft das CoreElec addon-Treiberpaket "dvb drivers from the latest kernel (media_build)" mit dem gepatchten Kernel noch zusammen?

Ich fürchte, man muss es ausprobieren. Eine endgültige Antwort kann ich dazu nicht geben.

Hallo,

ich möchte meinen etwas betagten LG TV mit display mode 1360x768p60hz unter CE auf dem N2 betreiben.

Ich bekomme kein Signal am Ausgang mit dem der TV was anfangen kann.

cat /sys/class/amhdmitx/amhdmitx0/disp_cap
480p60hz
576p50hz
720p60hz
1080i60hz*
720p50hz
1080i50hz
640x480p60hz
800x600p60hz
1024x768p60hz

bring diese Auflösungen zutage.

In der config.ini habe ich folgende Einträge versucht:

vmode=1360x768p60hz

reicht nicht, dann noch:

modeline='1360,768,84750,47880,60,1360,1432,1568,1776,768,771,776,798,0,1,1'

reicht auch nicht.

Muss man vieleicht in vmode was anderes Eintragen wenn man eine modline hat?

cat /sys/class/display/mode zeigt aber schon 1360x768p60hz

Die native ist 1368x768 läuft aber auch mit 1360x768.

Kodi unter CE bietet sie auch nicht an. Liest wahrscheinlich auch nur die disp_cap aus.

Laut diesem Wiki https://wiki.odroid.com/troubl…ing/supported_resolutions sollte der N2 es können.

Kann sein das der LG die Auflösung nicht im EDID liefert. Musste unter X11 auch schon modlines anlegen.

Modline kann man ja in der config.ini definieren. Die diversen Beschreibungen zur config.ini beziehen sich aber

leider nicht auf den CE Kernel und sehen ein wenig anders seitens der Variablen aus.

Leider wird in den Beschreibungen nicht die tatsächliche gebildete Kernel-Commandline aufgeführt.

War da nicht mal was mit "60 Hz böse, 50 Hz gut"?

Oder wars genau umgedreht?

Ich bin den 60hz nicht böse Im Kodi sehen die Urlaubbilder mit der nativen Auflösung des TV einfach besser aus.

Wenn der VDR läuft wird natürlich auf 720p50Hz umgeschaltet.

jojo61

ich habe jetzt meinen Odroid-N2 testweise mit dem VDR von Zabrimus erweitert.

Nach dem es nun soweit ganz gut als Streamingclient von meinem yaVDR-PC läuft ist mir jetzt erst aufgefallen, dass die Ausgabe immer in 1080p erfolgt.

Auch wenn ich z.B. auf den Astra-UHD1-Sender schalte. Da habe ich dann auch 1080p allerdings mit HDR, aber nicht wie erhofft 2160p mit HDR.

Ich hatte gedacht, dass hier die Bildausgabe automatisch von 1080p auf 2160p umgeschaltet wird, wie es bei CoreElec-KODI gemacht wird.

Muss ich da noch etwas einstellen, was ich übersehen habe?

Quote from jojo61

Nein das umschalten der Auflösung gibt es nicht. Du solltest einfach immer auf 2160p einstellen.

Schade, aber so weiß ich Bescheid und brauche nicht mehr suchen.

Muss ich mal schauen, wo beim Odroid-VDR die Bild-Auflösung eingestellt wird.

Bei yaVDR wird das ja über X11 gemacht, beim Odroid muss ich mal schauen!

Paulaner: Wenn Du unter KODI die Auflösung änderst auf 4K, kann VDR das auch. Ich muss leider immer noch zuerst einen kurzen KODI-Film laufen lassen, damit VDR in Ubuntu chroot unter CE nicht ruckelt.

Quote from beta

Wenn Du unter KODI die Auflösung änderst auf 4K, kann VDR das auch.

Aber das will ich eigentlich nicht ändern, da ich die Funktion von KODI die Bildauflösung unverändert zum TV zu schicken nicht schlecht finde.

Da habe ich ja die Auflösung auf 1080p gesetzt und wenn ich einen UHD-Sender schaue gibt KODI dann die Bildauflösung in 2160p aus.

Ich werde es aber auf jeden fall mal testen. Ob ich es dann so lasse? mal sehen, denn eigentlich soll mein TV die Scalierung erledigen.

Ich weiss nicht, wieso ich hier keine Benachrichtigung bekommen habe... ich habe fast das ganze Pfingstwochenende ebenfalls damit verbracht, den Fehler zu suchen und bin am Ende zum fast gleichen Ergebnis gekommen, das ich gerade stolz posten wollte

Ich habe diesen Teil

r = ioctl(cntl_handle, AMSTREAM_IOC_SET_FREERUN_MODE,0);

if (r < 0)
{
Debug(3,"AMSTREAM_FREERUN 0 failed");
return;
}

ans Ende von void InternalOpen gesetzt, direkt vor dem isOpen = true;

Es ist nicht notwendig, erst die 1 und dann die 0 zu setzen.

Wahrscheinlich würde es auch an einer früheren Stelle funktionieren, z.B. nach dem AMSTREAM_IOC_SYNCTHRESH. Ich habe mich für InternalOpen() statt VideoInit() entschieden, weil Du da auch die "kodi-Reparatur" mit dem SYNCTHRESH eingebaut hattest.

Was mir noch auffiel:

In SetPlaymode(0) ist eine Menge Code, der gar nichts bewirkt bzw. nie zur Ausführung kommt. Die Bedingung if (MyVideoStream->ClearClose)wird niemals true, das ist wohl noch ein unvollständiges Überbleibsel der alten softhddevice-Basis. Deshalb wird Clear() an der Stelle nie ausgeführt, was aber m.E. auch gut so ist, denn es ist eine vdr-Funktion, die nur beim Spulen/Trickmode aufgerufen werden soll. Auch

VideoSetClosing(MyVideoStream->HwDecoder);
VideoResetStart(MyVideoStream->HwDecoder)

bewirken nichts.

Ich habe das jetzt so laufen:

case 0:                        // audio/video from decoder
            // tell video parser we get new stream
            if (MyVideoStream->Decoder && !MyVideoStream->SkipStream) {
                amlSetInt("/sys/class/video/blackout_policy", 1);
                if (MyVideoStream->CodecID != AV_CODEC_ID_NONE) {
                    MyVideoStream->NewStream = 1;
                    MyVideoStream->InvalidPesCounter = 0;
#ifdef DEBUG
                    VideoSwitch = GetMsTicks();
                    Debug(3, "video: new stream start\n");
#endif
                }
            }
            if (MyAudioDecoder) {       // tell audio parser we have new stream
                if (AudioCodecID != AV_CODEC_ID_NONE) {
                    NewAudioStream = 1;
                }
            }
            break;

Damit wird die blackout_policy für ein Schwarzbild an der einzigen Stelle gesetzt, wo sie benötigt wird. Clear() sieht dann so aus:

void Clear(void)
{
    int i;
    VideoResetPacket(MyVideoStream);    // terminate work
    MyVideoStream->ClearBuffers = 1;
    if (!SkipAudio) {
        AudioFlushBuffers();
    }
    // wait for empty buffers
    for (i = 0; MyVideoStream->ClearBuffers && i < 20; ++i) {
        usleep(1 * 1000);
    }
    amlReset();
    Debug(3, "[softhddev]%s: %dms buffers %d\n", __FUNCTION__, i, VideoGetBuffers(MyVideoStream));
}

Den Code in amlreset habe ich nicht verstanden. Wozu wird der Wert bei jeder Ausführung erst abgefragt, dann auf 0 gesetzt und schließlich wieder auf den Ursprungswert gesetzt? Und was soll das einzelne Semikolon? Ich habe das jetzt so laufen:

void amlReset()
{
        Debug(3,"amlreset");
        if (!isOpen){
                return;
        }
        // set the system blackout_policy to leave the last frame showing
        amlSetInt("/sys/class/video/blackout_policy", 0);
        InternalClose(0);
        FirstVPTS = AV_NOPTS_VALUE;
        isFirstVideoPacket = true;
        InternalOpen(OdroidDecoders[0], videoFormat,FrameRate);
}

Leider ändert das kaum etwas (vermutlich sogar gar nichts) an der Umschaltdauer, die ich mit 2-4 Sekunden zu hoch finde. Die Hardware sollte eigentlich deutlich schneller als ein Raspi2 mit rpihddevice sein.

Quote from Dr. Seltsam

Damit wird die blackout_policy für ein Schwarzbild an der einzigen Stelle gesetzt, wo sie benötigt wird. Clear() sieht dann so aus:

Bewirkt diese auch ein schwarzen Bildschirm, wenn man auf einen Radiosender schaltet? Bisher bleibt das letzte Live-TV Bild stehen...

Quote from Dr. Seltsam

Leider ändert das kaum etwas (vermutlich sogar gar nichts) an der Umschaltdauer, die ich mit 2-4 Sekunden zu hoch finde. Die Hardware sollte eigentlich deutlich schneller als ein Raspi2 mit rpihddevice sein.

Das finde ich bisher auch schade, mein alter raspi3b+ kann deutlich schneller "zappen". Vielleicht kann man hier noch etwas optimieren?

Quote from Uwe

Bewirkt diese auch ein schwarzen Bildschirm, wenn man auf einen Radiosender schaltet? Bisher bleibt das letzte Live-TV Bild stehen...

Leider nein. Die blackout-policy bleibt offenbar ohne Wirkung, wenn gar keine video-Daten beim Decoder ankommen. Die Erkennung, ob ein Stream Audio-only ist, ist leider nicht ganz so einfach.

Das gewünschte Verhalten kannst Du aber mit dem Radio-Plugin von https://github.com/siricco/vdr-plugin-radio ganz leicht erreichen. Ich verwende dazu ein Schwarzbild. Die Datei noSignal16x9-completelyBlack.mpg (siehe Anlage, gezippt) liegt bei mir in /var/lib/vdr/plugins/radio/ und das Plugin starte ich ich über /etc/vdr/conf.d/plugins.conf mit diesen Einstellungen:

[radio]
--replay=/var/lib/vdr/plugins/radio/noSignal16x9-completelyBlack.mpg
--live=/var/lib/vdr/plugins/radio/noSignal16x9-completelyBlack.mpg

Quote from jojo61

Bzgl. den Umschaltzeiten gibt es sehr unterschiedliche Erfahrungen. Ich habe hier einen X96 Max+ mit einer USB DVB-C Karte und da schaltet er in unter einer Sekunde um. An meinem Odroid-N2 mit Satip dauet es ca. 2-3 Sekunden. Ich denke das Problem ist hier nicht das Ausgabeplugin.

Das ist interessant!

Ich habe am Odroid N2+ sowohl eine Hauppauge WinTV dualHD per USB (die auf meinem Nvidia-VDR blitzschnell umschaltet) als auch freie MagentaTV-Kanäle (iptv-Plugin).

Die DVB-C-Kanäle schalten gemächlich um, wobei SD deutlich fixer als HD geht. Die iptv-Kanäle, die auf meinem Nvidia-Rechner etwas langsamer als die DVB-C-Kanäle umschalten, schalten auf dem N2+ sogar etwas fixer um.

Was für ein device hast Du am X96 Max+ hängen? Wenn es Unterschiede zwischen dem S905X3 und S922X Chipsatz sind, könnte die Ursache vielleicht doch im Plugin zu suchen sein - da gibt es ja an einigen Stellen spezifischen Code für die jeweiligen Chipsätze. Was mich immer noch wundert ist, wie rasend schnell das neue Bild da war, als kodi das syncthresh-Verhalten versaut hatte. Es fehlte dann zwar die Video/Audio-Synchronisation, aber die dauert ja, wie Du selbst mal geschrieben hattest, nur um die 600ms. Dadurch dürften dann ja keine Umschaltzeiten von mehreren Sekunden entstehen.

Der X96 Max+ hat wahrscheinlich keine RTC und kann daher kein acpi-wakeup? Hast Du 2GB oder 4GB RAM?

Quote from jojo61

Bzgl. den Umschaltzeiten gibt es sehr unterschiedliche Erfahrungen. Ich habe hier einen X96 Max+ mit einer USB DVB-C Karte und da schaltet er in unter einer Sekunde um. An meinem Odroid-N2 mit Satip dauet es ca. 2-3 Sekunden. Ich denke das Problem ist hier nicht das Ausgabeplugin.

Ich habe eine Tanix TX3 mit Sundtek Dual Tuner (DVB-S2), die schaltet relativ flott um. Eine weitere TanixTX3 mit satip-Plugin an einer Fritzbox mit DVB-C (Vodafon) schaltet sehr langsam um... Das wäre meine Erfahrung....