[Softhddevice] cant'render mixer: An invalid handle value was provided

Ich verwende, wenn möglich immer die Neuste Version, im Moment 1.7.33.

In 1.7.32 ist mit den Thread Prioritäten gespielt worden. Daran könnte es liegen.

Johns

Gute Frage, ich habe nur geraten, weil dies mit meiner Vermutung der Ursache des Problems zusammen passt.

http://projects.vdr-developer.org/git/vdr.git

Ich kenne mich nicht mit den VDR Internas aus, aber wenn im Abspielpfad die Priorität gesenkt wird,
könnte es die beschriebenen Probleme auslösen.

Wenn der Sectionhandler bremst, dann könnte dies hier sein:

cSectionHandler::cSectionHandler(cDevice *Device)
-:cThread("section handler")
+:cThread("section handler", true)
{

Oder einfach um zu sehen ob es überhaupt daran liegt:

cThread::~cThread()
@@ -248,12 +249,16 @@ void *cThread::StartThread(cThread *Thread)
{
Thread->childThreadId = ThreadId();
if (Thread->description) {
- dsyslog("%s thread started (pid=%d, tid=%d)", Thread->description, getpid(), Thread->childThreadId);
+ dsyslog("%s thread started (pid=%d, tid=%d, prio=%s)", Thread->description, getpid(), Thread->childThreadId, Thread->lowPriority ? "low" : "high");
#ifdef PR_SET_NAME
if (prctl(PR_SET_NAME, Thread->description, 0, 0, 0) < 0)
esyslog("%s thread naming failed (pid=%d, tid=%d)", Thread->description, getpid(), Thread->childThreadId);
#endif
}
+ if (Thread->lowPriority) {
+ Thread->SetPriority(19);
+ Thread->SetIOPriority(7);
+ }
Thread->Action();
if (Thread->description)
dsyslog("%s thread ended (pid=%d, tid=%d)", Thread->description, getpid(), Thread->childThreadId);

Herausnehmen.

Johns

Wenn es nur kurz vor Ende kommt, dann ist der Effekt auch erklärbar.
Ich habe mehrere eigene Videopuffer die "91+3 v-buf", wenn die leer sind,
verlangsame ich das Videobild (empty + dupping Meldungen). Ist aber
wieder alles gut gefüllt, merke ich das die Zeitstempel zuweit auseinander sind
und versuche diese wieder anzugleichen (dropping Meldungen). Und dann geht
es wieder von vorne los.

Bei mir, komme ich garnicht so nahe ans Ende heran, weil bei mir die Aufnahme
dort abbricht wo das Ende beim Start der Wiedergabe war.

Zu deinen anderen Fehler liegt es daran, daß die Videopuffer sehr schwanken "91+3 v-buf" und "72+1 v-buf".
Der bisherige Patch gleich nur +-1 aus, mußt die Werte nochmal um ein paar ms erhöhen.

Was sind denn deine normalen Schwankungen? 16 - -49 = 65ms ist kein Vielfaches von 20ms.

Johns

Da hast aber schon wieder bei "Live TV" Probleme.

Ich meinte den "greater_sync.diff" Patch.

Johns

Welches Problem? Den Crash oder wenn die Wiedergabe die Aufnahme einholt?

Ich würde den Patch mit den Flächen drin lassen.

Johns

Für den greater sync muß ich nochmal einen vernünftigen Patch erstellen.
Wenn es die Zeit erlaubt, mal 65 - -15 oder 66 - -15 testen.

Den Patch von [Softhddevice] cant'render mixer: An invalid handle value was provided würde ich auch erstmal drin lassen.

Johns

So die extra Fläche ist nun im GIT. Im Gegensatz zu meinen Patch verwende ich nur 1 Fläche und nicht 2.

Und hier der aktuelle Patch für größeren Syncbereich:

diff --git a/video.c b/video.c
index 981f5c8..fba9dd5 100644
--- a/video.c
+++ b/video.c
@@ -4600,7 +4600,7 @@ static void VaapiSyncDecoder(VaapiDecoder * decoder)
            goto out;
        }
        // both clocks are known
-       if (audio_clock + VideoAudioDelay <= video_clock + 15 * 90) {
+       if (audio_clock + VideoAudioDelay <= video_clock + 35 * 90) {
            goto out;
        }
        // out of sync: audio before video
@@ -4644,12 +4644,12 @@ static void VaapiSyncDecoder(VaapiDecoder * decoder)
            ++decoder->FramesDuped;
            decoder->SyncCounter = 1;
            goto out;
-       } else if (video_clock > audio_clock + VideoAudioDelay + 45 * 90) {
+       } else if (video_clock > audio_clock + VideoAudioDelay + 65 * 90) {
            err = VaapiMessage(3, "video: slow down video, duping frame\n");
            ++decoder->FramesDuped;
            decoder->SyncCounter = 1;
            goto out;
-       } else if (audio_clock + VideoAudioDelay > video_clock + 15 * 90
+       if (audio_clock + VideoAudioDelay <= video_clock + 35 * 90) {
            goto out;
        }
        // out of sync: audio before video
@@ -8052,12 +8052,12 @@ static void VdpauSyncDecoder(VdpauDecoder * decoder)
            ++decoder->FramesDuped;
            decoder->SyncCounter = 1;
            goto out;
-       } else if (video_clock > audio_clock + VideoAudioDelay + 45 * 90) {
+       } else if (video_clock > audio_clock + VideoAudioDelay + 65 * 90) {
            err = VdpauMessage(2, "video: slow down video, duping frame\n");
            ++decoder->FramesDuped;
            decoder->SyncCounter = 1;
            goto out;
-       } else if (audio_clock + VideoAudioDelay > video_clock + 15 * 90
+       } else if (audio_clock + VideoAudioDelay > video_clock + 35 * 90
            && filled > 1 + 2 * decoder->Interlaced) {
            err = VdpauMessage(2, "video: speed up video, droping frame\n");
            ++decoder->FramesDropped;

Zum Synchronisieren werden gelegentlich Wartepausen eingefügt, um die Darstellung eines Frames abzuwarten. Als Referenzwert wird eine Variable vom Typ 'struct timespec' (decoder->FrameTime) verwendet. Diese enthält ja zwei Werte, tv_sec und tv_nsec. Ist es möglich, daß es bei asynchronem Zugriff von Setzen und Lesen gelegentlich zum Verwenden von nicht zusammengehörenden Werten von tv_sec und tv_nsec kommt? Im Ergebnis wäre die Zeit sofort abgelaufen oder es würde 1sec gewartet werden.

Gruß
e9hack

Der Videodecoder und Videoanzeiger ist nur ein Thread.
Das was von außen zugreift ist über einen Mutex gelockt.
Normal ist dies OSD oder Änderung der Ausgabeposition oder ...
Die FrameTime ist nur ein Schätzeisen, die wird wenn ntpd oder
Ähnliches läuft verändert.

Die eigentliche Videosyncronisation passiert im VDPAU Videotreiber.

Ich habe:
undekodierte Videopuffer -> dekodierte Videoframe Puffer -> Treiber interne Videoframe Puffer.

Johns

Irgendwo gab es einen patch für die libavcodec, der zumindest den abort bei ff_unused_picture unterdrückte. Ist eventuell bei den neuesten ffmpeg-Versionen drin, sonst muss man selber übersetzen. Jedenfalls hab ich seitdem keinen Absturz in der Ecke mehr gehabt. (Im softhddevice-code von codec.c steht nicht ohne Grund "can crash with bad packets")

Also ich bekomme diesen hier: [h264_vdpau @ 0x7f89c041cfb0] Internal error, picture buffer overflow
Und "out of surfaces".
Brauche nur 1 HD Aufnahme von heute mit schnellseten Vorlauf rennen lassen.

Was komisch ist, eine alte Aufnahme hat kein Problem.

Edit: der Patch repariert es, nur gab es ohne dieser Funktion manchmal keine Aktuallisierung
bei schnellen Vorlauf oder Rücklauf.

Johns