Auf einem anderen System habe ich jetzt API 192 getestet, scheint zu laufen.
Ich werde den Link ins README setzen.
softhdcuvid: bei aktuellem ffmpeg git bekomme ich Fehler:
Schaue ich mir an. Muss eh mal auf neueres ffmpeg aktualisieren.
Beiträge von jojo61
-
-
Hast du die libplacebo API 113 ? Neuere Versionen gehen derzeit nicht.
Ich dachte ich hätte mal einen Link ins README gesetzt, finde ihn aber nicht
Edit:
Doch noch gefunden
Codehttps://github.com/haasn/libplacebo/archive/72cd260ad7d5aa564ff5e68caf16ec2633f3460e.zip -
Hilft das?
Leider nicht. Das zeigt nur welche Planes es gibt. Er sollte das Plane 184 nehmen. Kannst du mal mit libplacebo compilieren ?
Es könnte sein das das Framelayout NV12 hier anders ist. Dann müsste ich nacharbeiten. Dann muss ich aber erstmal das Framelayout ermitteln.
VAAPI scheint hier nicht eindeutig zu sein. Ich gehe davon aus das hier ein NV12 YUV Frame vorliegt wobei UV direkt hinter dem Y Teil liegt.
Das könnte aber mit dem neueren FFMPEG oder dem VAAPI Decoder hier anders sein.
-
Wie kann ich das steuern?
Was mich auch wundert, der Bildschirm arbeitet immer mit 60Hz.
Was mir noch aufgefallen war, Du verweist auf "'requires'", die finde ich aber nirgendwo.Steueren kannst du das leider nicht. Ich versuche zuerst einen 10 Bit Framebuffer zubekommen und wenn das klappt dann nehme ich den. Ansonten falle ich zurück auf 8 Bit. Hier kannst du das aber wohl ändern.
Um 50 Hz zu erzwingen geben mal die Auflösung und den Refresh Paramter mit. Also -g 1920x1080 -r 50
Wenn das nicht geht stimmt etwas mit dem EDID nicht.
Wo verweise ich denn auf "required" ?
-
Könnte ein Problem mit der 10Bit Farbtiefe sein.
-
So ich habe nun einen amlReset in das Zurückspulen eingebaut und nun geht es. Ich hoffe das es keine Nebenwirkungen hat.
Feedback willkommen.
-
Was auch immer es ist, meiner Meinung nach ist es ein Fehler im Kernel und da kann ich nichts machen.
Und wenn es kein Fehler im Kernel ist und ich mache etwas falsch dann weiss ich leider nicht was das sein soll. Wenn also jemand da weiter kommt nehme ich gerne einen Patch entgegen.
-
Stimmt da geht es auch nicht. Ich habe mir die Streams nun nochmal genauer angesehen und es gibt einen Unterschied in der Codierung.
Im ZDF (da wo es geht ) kommt ein I-Frame mit den Nal Units 9, 7, 8, 8, 6, 5. Wobei die 5 sagt es ist ein IDR Frame also ein I-Frame.
Bei der ARD (wo es nicht geht) kommt das I-Frame als 9, 7, 8, 6, 1. Wobei die 1 sagt das es ein B-Frame ist. In diesen Streams sind keine Nal Units mit 5 vorhanden. Das lässt darauf schliessen das hier Reference B-Frames genutzt werden. Wenn ich das richtig verstanden habe kann man die auch als I-Frames ansehen. Nur scheint der Decoder damit aber stehen zu bleiben.
-
#define TRICKMODE_FFFB 0x02
Hab ich schon ausprobiert, keine Änderung. Da es ja im Prinzip geht (z.b. Bei ZDF) denke ich nicht das ich hier etwas falsch mache.
Es muss etwas im I-Frame sein was ihn stört.
Im Übrigen ist es nicht der Trickmode sondern der Freerun Mode der hier genutzt wird. Damit wird das Video/PCR Sync abgeschaltet und jedes Frame unabhängig vom PCR angezeigt. Bei ARD halt nur das erste
-
Was für ein Reset ist das, den vdr bei Drücken der grünen Taste durchführt?
Da kommt ein Clear vom vdr. Daraus mache ich dann ein amlReset. Sonst löscht er nicht die Queue im Kernel.
Mich würde eher mal interessieren was der Unterschied in den I-Frames zw. ARD und ZDF ist. Gibt es ein Tool das ein I-Frame zerlegen kann ?
-
Nach weiteren Stunden des analysierens bin ich zu dem Ergebniss gelangt das es nicht geht.
So wie ich das sehe werden bei ARD und anderen Sendern die Frames in einer anderen Reihenfolge codiert als z.b. beim ZDF. Das ist sicher im Rahmen der h264 Spec völlig ok, aber der Decoder des Odroid hat damit offensichtlich Probleme. Beim normalen vorwärts klappt das auch, nur wenn ich I-Frames schicke die aus einem ARD Stream stammen dann werden sie zwar angezeigt, aber der decoder bleibt dann stehen und alle weiteren I-Frames (mit kleinerem PCR) werden nicht mehr angezeigt. (bei Trickpeed). Deswegen geht da kein Rückwärtsspulen.
Beim Rückwärtspringen (Grüne Taste) wird vor jeden Sprung ein Reset vom VDR gemacht und da geht das dann einmal. Deswegen fällt das da nicht auf.
Was nun wirklich anders ist am ARD Stream habe ich nicht weiter analysiert. Evtl. fehlt da nur irgendein Flag im Stream was man nachpatchen könnte, aber das ist mir derzeit zu hoch. Evtl. gibt es hier bessere Spezialisten was im Stream zw. ARD und ZDF unterschiedlich ist.
Ich checke nun noch den fix für das Springen zwischen EDIT Marken ein.
-
Ich habe mir das nun angeschaut und bin verwirrt
Ja bei ARD habe ich das Problem auch. Im Unterschied zum ZDF schickt der VDR eine Sekunde nach dem start des Zurückspulen ein Clear. Damit geht der ganze Setup kaputt und deswegen funktioniert es nicht. ABER, warum schickt der VDR ein Clear ?? Ich denke es liegt an den PCR Values die ich in GetSTC zurückschicke. Leider kann ich da nicht die realen Values aus dem Kernel zurückschicken, weil der Odroid hier nur mit 32Bit arbeitet. Deswegen speichere ich den letzten PCR Value den ich in die Queue zum Kernel geschrieben habe und schicke den zurück. Das ergibt schonmal eine kleine Diskrepanz zum real angezeigten I-Frame. Aber warum der VDR sich daran stört und ein Clear schickt ist mir ein Rätsel. Zumal es ja beim ZDF auch so ist.Bei der Gelegenheit habe ich noch einen Fehler gefunden. Derzeit funktioniert das Springen zwischen Schnittmarken nicht sauber. Das habe ich aber schon gefunden und werde es mit korrigieren wenn ich eine Lösung für das Spulen gefunden habe.
Ich bin also noch am suchen. Geduld
-
Ich teste morgen mal mit der tagesschau. Muss nun weg.
-
Das ist wohl die Zeitlupe
Ich glaube da muss ich noch nacharbeiten weil da die Trickspeed Werte zu hoch sind. Wie sieht es denn bei dem "normalen" Rückwärts aus ? -
Dabei starten .mkv (per Softwaredekoder) mit AC-3 problemlos aber z.B. E-AC-3 crasht den vdr
Läuft der mpv denn wenn du das E-AC3 File auf der Konsole mit mpv startest ? Sowas wie: $mpv video.mkv
-
Ja mach ich.Komm aber erst morgen dazu.
-
Das ist die aktuelle Version. Ich denke schon das es vom Sender ahängig ist da jeder einen anderen I-Frame zyklus haben kann. Aber es sollte keinen unterschied machen da ich ja die PCR differenz berücksichtige. Hast du MultiSpeed aktiv ?
-
Hmm das ist seltsam. Bei mir geht das durchaus. Vor und Zurück. Wichtig ist das ihr Multi speed aktiv habt.
Im Prinzip ist es ganz einfach. Der VDR schickt I-Frames und sagt wie lange sie zu wiederholen sind. Daran habe ich auch nichts geändert. Ich habe nur die Wiederholzeit zusätzlich von der Differenz des PCR Values zwischen den I-Frames abhängig gemacht. An der Zeitlupe Rückwärts könnte man noch verbessern weil da der VDR sehr hohe wiederholzeiten (Trickspeed values) vorgibt.
Das ganze wird in CodecVideoDecode gemacht. Wenn ihr da etwas verbessern könnt nehme ich Feedback gerne an.
-
Nur das VDR-MPV-Plugin schafft leider keine saubere "Hardware" unterstützte DRM-Übergabe an das MPV unter Ubuntu. War aber schon immer so
Ja das detach schliesst das drm device und dropt den master. Bei meinen damaligen Tests hatte ich aber den Eindruck das das nicht reicht und erst nach dem beenden des vdr tatsächlich das drm device wieder frei ist. Evtl. sollte man mal wirklich den VDR beenden und/oder den mpv mit einem at Kommando starten damit er wirklich frei läuft. Hintergrund ist: wenn ich das drm device schliesse bin ich evtl. immer noch authentifiziert und das mag ja die Probleme machen und der softhddrm Threat wird beim detach ja nicht beendet (soweit ich weiss).
-
ich dachte auch das die Aufgabe vom vdr-mpv-plugin darin liegt den VDR zu stoppen und die die Videodatei mit den Einstellungen an den
MPV Mediaplayer zu Übergeben. Der MPV Mediaplayer sollte dann auch die Video- und Tonausgabe übernehmen.
Erst nach Beendigung vom vdr-mpv-plugin wird der VDR doch wieder gestartet.
Wenn das mpv Plugin den vdr beendet wo spielt denn dann das softhddrm Plugin hier ein Rolle ? Im Prinzip müsse auch ein detach ausreichen um das softhddrm zu beenden. Dann sollte das drm device frei sein.
