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

Interessant ist ja auch, dass vorwärts-Spulen geht ... da werden doch auch einfach nur I-Frames geschickt. Das geht doch im softhdodroid sogar durch die gleiche Funktion, oder?

Vielen Dank!!! Werde ich vermutlich am Wochenende ausprobieren können, dann kommt Feedback!

Ich habe es gerade mit dem letzten Finetuning von heute morgen getestet. Bingo!

Ich werde jetzt mal schauen, ob ein amlReset an irgendeiner anderen Stelle vielleicht noch das verbleibende Problem bei der Zeitlupe (zu schnell laufendes Bild am Beginn und Ende) löst.

Top! Das ist wirklich einfach nur genial! Super und vielen Dank !

Moin

was ich immer mal fragen wollte: beim "SES UHD Demo Channel", bekommt ihr da auch mit Passthrough mit softhdodroid (hier hängt noch ein Denon AVR dazwischen) keinen Ton ?

Auf meinem anderen NUC8 VDR mit softhddrm am Sony TV direkt habe ich Ton auf diesem Sender.

Danke

so nach gut einem Monat softhdodroid im produktiven Einsatz wollte ich kurz meine Beobachtungen schildern. Es kann auch sein das hier und da was hausgemachtes dabei ist, aber vllt können andere ja ähnliches bestätigen:

- also das eine voll aufgerödeltes OSD (shady, logos, scraper) auf einem odroid n2+ langsamer ist als mit einer GT630 oder auf einem nuc8 kann ich nicht bestätigen, das läuft hier wirklich flüssig

- Was am OSD nicht so toll ist sind (bei 3840) die skalierten Flächen, also wenn in der Programm oder Aufnahmen Ansicht ein viertel des Bildschirms im Fenster angezeigt wird: bei öffnen des Menu ist das noch ok aber sobald sich das Programm im Fenster ändert passt da die Skalierung nicht. Zum Beispiel in der Aufnahmensicht ist es solang ok bis man entweder die Wiedergabe mit Stop beendet und er auf TV zurückspringt oder mit den Kanaltasten ein Programm weiter schaltet wenn man einfach nur im Menu war. Beim Programmmenu identisch und mit softhddrm kein Problem. Aufgefallen war mir da das die setup Option zur OSD Größe die es unter softhddrm noch gab hier nicht mehr da ist?

- das Spulen, vor wie zurück läuft super. (benutze ich allerdings selten)

- was leider nicht so gut läuft ist das Springen mit grün/gelb um jeweils eine Minute, da kann man zB mit softhddrm einfach den Finger drauf halten und kann dann zB 20 Minuten zurückgehen. Hier benötigt es wirklich sehr viele Einzelklicks um dasselbe zu erreichen.

- seeeehr selten, vllt einmal pro Woche bleibt die Wiederhabe einer Aufnahme plötzlich stehen, ich kann dann kurz zurücklaufen lassen und mit einem 10s Sprung drüber, aber die Wiedergabe selber stoppt immer wieder an der Stelle. Ich kann da gern mal eine Aufnahme behalten und einen Schnipsel rausschneiden bei dem das auftritt. - unter softhddrm laufen die selben Sequenzen sauber.

- jump'n'run über markad Schnittmarken: das kann ich gar nicht so richtig greifen, sehr selten läuft es sauber, meistens läuft aber der Ton weiter, das Bild geht 2-3s in einen schnellen Vorlauf mode bevor er dann doch über die Werbung springt und danach dann sofort sauber weiter läuft.

Alles in Allem Jammern auf sehr hohem Nivuea, nichts davon ist wirklich lebenswichtig an dem tollen Plugin.

Aber vllt hat ja schon mal jemand ähnlich Sachen beobachtet oder sogar lokal beheben können.

Vielen Dank jojo61 , das war nochmal ein sehr großer Schritt nach vorn für ein ohnehin schon sehr gutes Frontend!

Gruß Christian

Ich hätte dann auch noch was zum Testen:

--- vdr-plugin-softhdodroid-orig/softhddev.c    2023-03-08 23:15:27.000000000 +0100
+++ vdr-plugin-softhdodroid-Test090323/softhddev.c    2023-03-09 12:17:41.000000000 +0100
@@ -2401,33 +2401,15 @@
 //extern void amlClearVideo();
 int SetPlayMode(int play_mode)
 {
-    int i;
     Debug(3, "Set Playmode %d\n", play_mode);
     switch (play_mode) {
-        case 0:                        // audio/video from decoder
-            // tell video parser we get new stream
-            //amlClearVideo();
+        case 0:
             if (MyVideoStream->Decoder && !MyVideoStream->SkipStream) {
-                amlSetInt("/sys/class/video/blackout_policy", ConfigVideoBlackPicture);
-                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);
-                }
+                Clear();
+                MyVideoStream->ClearClose = 0;
                 if (MyVideoStream->CodecID != AV_CODEC_ID_NONE) {
-                    MyVideoStream->NewStream = 1;
-                    MyVideoStream->InvalidPesCounter = 0;
-                    // tell hw decoder we are closing stream
-                    VideoSetClosing(MyVideoStream->HwDecoder);
-                    VideoResetStart(MyVideoStream->HwDecoder);
-#ifdef DEBUG
-                    VideoSwitch = GetMsTicks();
-                    Debug(3, "video: new stream start\n");
-#endif
+                        MyVideoStream->NewStream = 1;
+                        MyVideoStream->InvalidPesCounter = 0;
                 }
             }
             if (MyAudioDecoder) {       // tell audio parser we have new stream
@@ -2437,23 +2419,17 @@
             }
             break;
         case 1:                        // audio/video from player
-            VideoDisplayWakeup();
-            Play();
-            break;
         case 2:                        // audio only from player, video from decoder
         case 3:                        // audio only from player, no video (black screen)
-            Debug(3, "softhddev: FIXME: audio only, silence video errors\n");
-            VideoDisplayWakeup();
-            Play();
-            break;
         case 4:                        // video only from player, audio from decoder
-            VideoDisplayWakeup();
-            Play();
+            amlSetInt("/sys/class/video/blackout_policy", ConfigVideoBlackPicture);
             break;
     }
     return 1;
+
 }
 
+
 /**
 **  Gets the current System Time Counter, which can be used to
 **  synchronize audio, video and subtitles.
@@ -2539,7 +2515,6 @@
     for (i = 0; MyVideoStream->ClearBuffers && i < 20; ++i) {
         usleep(1 * 1000);
     }
-    amlReset();
     Debug(3, "[softhddev]%s: %dms buffers %d\n", __FUNCTION__, i, VideoGetBuffers(MyVideoStream));
 }
 
diff -ur vdr-plugin-softhdodroid-orig/video.c vdr-plugin-softhdodroid-Test090323/video.c
--- vdr-plugin-softhdodroid-orig/video.c    2023-03-08 23:15:27.000000000 +0100
+++ vdr-plugin-softhdodroid-Test090323/video.c    2023-03-09 12:09:08.000000000 +0100
@@ -1138,7 +1138,9 @@
 
 extern void amlClearVBuf();
 /// Flush video buffers.
- void CodecVideoFlushBuffers(VideoDecoder *decoder) {};
+ void CodecVideoFlushBuffers(VideoDecoder *decoder) {
+        amlReset();
+};
 
 
 /// Setup and initialize codec module.

Der besseren Übersichtlichkeit halber: Die neue Funktion SetPlayMode sieht damit so aus:

int SetPlayMode(int play_mode)
{
    Debug(3, "Set Playmode %d\n", play_mode);
    switch (play_mode) {
        case 0:
            if (MyVideoStream->Decoder && !MyVideoStream->SkipStream) {
                Clear();
                MyVideoStream->ClearClose = 0;
                if (MyVideoStream->CodecID != AV_CODEC_ID_NONE) {
                        MyVideoStream->NewStream = 1;
                        MyVideoStream->InvalidPesCounter = 0;
                }
            }
            if (MyAudioDecoder) {       // tell audio parser we have new stream
                if (AudioCodecID != AV_CODEC_ID_NONE) {
                    NewAudioStream = 1;
                }
            }
            break;
        case 1:                        // audio/video from player
        case 2:                        // audio only from player, video from decoder
        case 3:                        // audio only from player, no video (black screen)
        case 4:                        // video only from player, audio from decoder
            amlSetInt("/sys/class/video/blackout_policy", ConfigVideoBlackPicture);
            break;
    }
    return 1;

Und Clear():

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);
    }
    Debug(3, "[softhddev]%s: %dms buffers %d\n", __FUNCTION__, i, VideoGetBuffers(MyVideoStream));
}

Der amlReset() aus Clear() wurde in CodecVideoFlushBuffers verlegt und wird durch ClearBuffers ausgelöst. Das erfolgt durch den zusätzlichen Clear() Aufruf in Playmode 0 nun auch bei jedem Kanalwechsel, was vorher nicht der Fall war. Damit das Schwarzbild beim Kanalwechsel funktioniert, wurde die blackoutpolicy 1 in die anderen Playmodes verlagert und wird somit unmittelbar vor dem neuen Stream aktiviert. Da die blackout policy ja ohnehin nicht den endenden Stream betrifft, sondern erst beim neuen Stream berücksichtigt wird, macht das auch mehr Sinn.

Ich habe den Eindruck, dass das Umschalten so etwas schneller geht. Zumindest bei aktiviertem FastSwitch bringt der Patch m.E. eine erkennbare Verbesserung.

Ich habe das gerade mal ausprobiert, und bei mir klappt das einwandfrei. Bei jedem Sprung zu einer anderen Schnittmarke mittels Tasten 7 bzw. 9 wird CodecVideoFlushBuffers und dadurch amlReset aufgerufen. Das Bild aktualisiert sich jedesmal. Auch beim Verschieben von Schnittmarken mittels der Tasten 4 bzw. 6 aktualisiert sich die Anzeige.

Für den Fall, dass Du meinen Patch manuell eingebaut hast. Bist Du sicher, dass Du auch amlReset() in der bisher leeren Funktion CodecVideoFlushBuffers ergänzt hast?

Wenn es dennoch bei Dir nicht geht (Aufnahme von welchem Sender?) , würde ich Dich bitten, testweise VideoDisplayWakeup() und Play() in SetPlayMode in den Playmodes 1 bis 4 wieder einzutragen. Reicht das immer noch nicht, trage testweise amlReset bitte wieder in Clear ein.

das stimmt leider was nicht, auch wenn die Bugs beseitigt sind hab ich mit der aktuellen Version eine CPU von 100% während der Wiedergabe.

Das muss an was anderem liegen. Bei mir läuft es einwandfrei (13% derzeit bei einer Aufnahme).

Die Umschaltzeiten sind der Knaller. Danke jojo61.

Sicher? Wiedergabe, nicht Aufnahme. kann ich hier reproduzieren: mit dem Stand von gestern ist gut.

Wiedergabe habe ich nicht getestet. Nur live und Aufnahme. Momentan kann ich aber nicht testen, dann sinkt mein WAF...

EDIT: Getestet. Du hast leider Recht. Wiedergabe ist bei 100% CPU-Last.

Bei mir das gleiche. Meine Vermutung ist, dass es an einigen z.T. drastisch reduzierten usleep-Werten im Patch Fix Video in Window with channelswitch von gestern liegt.