vaapidevice: fast forward and rewind of all rtl transmitter does not work

Fourty2 · 17. Juni 2018

Also...

Schärfen geht bei mir auch nicht (stehendbleibendes Geisterbild). Hatte ich mal als Bug gemeldet...

Farbkalibrierung hat mein Spyder gemacht - kümmert sich der XServer per Argyll (o.s.ä.) drum. Kann ich also nichts zu sagen - ist alles aus hier.

Zum Abspielproblem:
Hab' mal 'ne Mutex verschoben - dann läuft meine Testaufnahme zuverlässig mit Ton an.

Audio-Fix

Diff

--- a/audio.c
+++ b/audio.c
@@ -779,12 +779,13 @@
            }
            if (err != frames) {
                if (err < 0) {
-                   pthread_mutex_unlock(&ReadAdvance_mutex);
                    if (err == -EAGAIN) {
+                       pthread_mutex_unlock(&ReadAdvance_mutex);
                        continue;
                    }
                    Error("audio/alsa: writei underrun error? '%s'", snd_strerror(err));
                    err = snd_pcm_recover(AlsaPCMHandle, err, 0);
+                   pthread_mutex_unlock(&ReadAdvance_mutex);
                    if (err >= 0) {
                        return 0;
                    }

Alles anzeigen

Oder hier nochmal komplett mit:
- Audio Mutex-Fix

- 33 Bit PTS Rollover Fix (26:30:00.000 -> 0:00:00.000 macht keine Bildfehler)

- Anderer Sync-Mittelwertbildung (die alte Methode tut's eigentlich auch... )

speedupdown.patch.gz

Wenn die Zeiten im Log stören:

+// err = VaapiMessage(1, "video: speed up video, droping frame(s)");

+ Info("video: speed up video, droping frame (/\\=%.2f ms, vClk %s - aClk %s)",diff*1000/(double)90000, Timestamp2String(video_clock), Timestamp2String(audio_clock));

durch

+ err = VaapiMessage(1, "video: speed up video, droping frame(s)");

+// Info("video: speed up video, droping frame (/\\=%.2f ms, vClk %s - aClk %s)",diff*1000/(double)90000, Timestamp2String(video_clock), Timestamp2String(audio_clock));

bei den Infos() ersetzen. Nur Debug-Output...

Stefan

Fourty2 · 17. Juni 2018

Na klar... ein Bug kommt niemals allein.

720p Sender + 720p Aufnahme = Stillstand, sonst läufts soweit...

(und ein paar alte VDR Aufnahmen (*.vdr), die das Problem auch vor vaapidevice hatten)

Stefan

Der_Pit · 17. Juni 2018

Zitat von mamomoz

Eine Bitte an Dich: Könntest Du Dein softhddevice mit dem eingebauten Patch hier bitte mal posten? Da ich auch die grab-Funktion brauche ist das bei mir genau derselbe Anwendungsfall, da wir beide ja auch dasselbe Board nutzen (j4105-itx).

DANKE

Gruß

moz

Hmm, nicht ganz sicher was genau Du brauchst/willst. Ich häng jetzt mal das src.rpm an, da ist originalquelle und patch drin. Im Zweifelsfall (ich verwende Tumbleweed - du vermutlich nicht, oder?) mit 'rpm2cpio rpmfile | cpio -idmv' auspacken und geeignet in deine Quellen einbauen. Mit der kompilierten lib wirst Du vermutlich wenig anfangen können.

Grummel, rpm will er nicht. Habs ausgepackt und als tar.gz wieder zusammengepackt....

softhd_sources_pit.tar.gz

447377 · 18. Juni 2018

Zitat von Fourty2

Zum Abspielproblem:
Hab' mal 'ne Mutex verschoben - dann läuft meine Testaufnahme zuverlässig mit Ton an.

Audio-Fix

Diff

--- a/audio.c
+++ b/audio.c
@@ -779,12 +779,13 @@
            }
            if (err != frames) {
                if (err < 0) {
-                   pthread_mutex_unlock(&ReadAdvance_mutex);
                    if (err == -EAGAIN) {
+                       pthread_mutex_unlock(&ReadAdvance_mutex);
                        continue;
                    }
                    Error("audio/alsa: writei underrun error? '%s'", snd_strerror(err));
                    err = snd_pcm_recover(AlsaPCMHandle, err, 0);
+                   pthread_mutex_unlock(&ReadAdvance_mutex);
                    if (err >= 0) {
                        return 0;
                    }

Alles anzeigen

Bei mir leider kein Unterschied. Der Ton geht nicht bzw. nur bei Aufnahmen mit anderer Auflösung als der aktuelle Live-Sender.

Stefan

Fourty2 · 23. Juni 2018

Habe mir das Verhalten nochmal angesehen:

Offenbar scheitert das Abspielen, sobald, etwa nach Umschalten, das

"VAAPI: video/vaapi: synced after <xx> frames"

vorbei ist. Startet man die Aufnahme per Back/Ok und erwischt die Sync-Phase des TV-Bilds darunter, wird abgespielt.

Teste mal dies:

Diff

--- a/vaapidev.c
+++ b/vaapidev.c
@@ -2198,10 +2198,10 @@
            // tell video parser we get new stream
            if (MyVideoStream->Decoder && !MyVideoStream->SkipStream) {
                // clear buffers on close configured always or replay only
-               if (MyVideoStream->ClearClose) {
+//             if (MyVideoStream->ClearClose) {
                    Clear();            // flush all buffers
                    MyVideoStream->ClearClose = 0;
-               }
+//             }
                if (MyVideoStream->CodecID != AV_CODEC_ID_NONE) {
                    MyVideoStream->NewStream = 1;
                    MyVideoStream->InvalidPesCounter = 0;

Alles anzeigen

Oder als Komplett-Patch anbei.

Stefan

447377 · 24. Juni 2018

Zitat von Fourty2

Habe mir das Verhalten nochmal angesehen:

Offenbar scheitert das Abspielen, sobald, etwa nach Umschalten, das

"VAAPI: video/vaapi: synced after <xx> frames"

vorbei ist. Startet man die Aufnahme per Back/Ok und erwischt die Sync-Phase des TV-Bilds darunter, wird abgespielt.

Teste mal dies:

Alles anzeigen

Du hast's geschafft. Vielen Dank! Es geht!

Und das, wo ich gestern einen Beitrag auf git einstellte.

https://github.com/pesintta/vd…in-vaapidevice/issues/121

Darf ich dort auf Deinen Beitrag #25 mit Deinem Patch hinweisen, um so Rofafor und Pesintta maximal zu unterstützen? Oder machst Du das selber?

Vielleicht können den Patch noch andere testen, vielleicht mit älterer Hardware - Haswell oder Skylake oder...

Nochmals danke

Stefan

447377 · 29. Juni 2018

Hallo Stefan,

auch hier vielen Dank für die Lösung und Deinen Beitrag im Git. Hoffentlich übernehmen Pesintta und Rofafor Deinen Patch so schnell wie möglich in den Master.

Für alle mit den gleichen Symptomen: Der Patch im Beitrag #25 ist die Lösung - zusammen mit dem Einschalten von "Sanftanlauf A/V Sync" in den Vaapidevice-Plugin-Einstellungen.

Stefan

Fourty2 · 29. Juni 2018

Leider behebt der Patch (noch) nicht alle Probleme, die seit der "Code-Bereinigung" aufgetreten sind.

Falls Du noch pre VDR-2.x Aufnahmen hast... besser nicht abspielen.

Startwert waren ca. 500 ms Diff...

Jun 29 23:49:48 roadrunner vdr: [5234] VAAPI: video: slow down video, duping frame (/\=1996,68 ms, vClk 10:37:17.827 - aClk 10:37:15.831)

Jun 29 23:51:26 roadrunner vdr: [5234] VAAPI: video: slow down video, duping frame (/\=2316,97 ms, vClk 10:38:56.387 - aClk 10:38:54.070)

Jun 29 23:55:01 roadrunner vdr: [5234] VAAPI: video: slow down video, duping frame (/\=2716,92 ms, vClk 10:42:31.507 - aClk 10:42:28.790)

Das RpiHDDevice spielt diese Aufnahme problemfrei und AV-synchron ab.

Auch auf z.B. EuroNews hab ich noch seltsame Klötzchen-Störungen.

Grüße,

Stefan

447377 · 1. Juli 2018

Das vorwärts Spulen von 576i-Aufnahmen scheint nicht zu gehen: Das Bild läuft wie im Schnellmodus vor, die Zeit bleibt stehen. Beim Druck auf Wiedergabe beginnt's wieder an der alten Stelle vor dem Spulen.

Mit etwas älteren Aufnahmen (aus der Ära vor vdr 2.4) geht's dagegen.

Stefan

Fourty2 · 1. Juli 2018

Hmm,

MPEG2 oder MPEG4?

Schnellvorlauf nutze ich selten, per 1/3 und grün/gelb funktioniert ja alles.

Das dürfte derselbe (vermutlich) fehlende Re-Init des Decoders sein - irgendwie ist da der Wurm drin...

Edit:

Habe mal ein MPEG4, VDR 2.4, 576i (vom Himmel) getestet... funktioniert.
Also vermutlich eher ein MPEG2 Problem.

Eventuell habe ich das aber schon gestern behoben (das A/V-Diff steigt und steigt...):

Diff

--- a/vaapidev.c
+++ b/vaapidev.c
@@ -2067,7 +2067,8 @@
        }
 #endif
        // SKIP PES header, begin of start code
-       VideoMpegEnqueue(stream, pts, dts, check - 2, l + 2);
+//     VideoMpegEnqueue(stream, pts, dts, check - 2, l + 2);
+       VideoEnqueue(stream, pts, dts, check - 2, l + 2);
        return size;
     }
     // this happens when vdr sends incomplete packets
@@ -2075,14 +2076,20 @@
        Debug3("video: not detected");
        return size;
     }
-    if (stream->CodecID == AV_CODEC_ID_MPEG2VIDEO) {
-       // SKIP PES header
-       VideoMpegEnqueue(stream, pts, dts, data + 9 + n, size - 9 - n);
-    } else {
-       // SKIP PES header
-       VideoEnqueue(stream, pts, dts, data + 9 + n, size - 9 - n);
+//    if (stream->CodecID == AV_CODEC_ID_MPEG2VIDEO) {
+//     // SKIP PES header
+//     VideoMpegEnqueue(stream, pts, dts, data + 9 + n, size - 9 - n);
+//    } else {
+//     // SKIP PES header
+//     VideoEnqueue(stream, pts, dts, data + 9 + n, size - 9 - n);
+//    }
+
+    // Skip PES Header
+    VideoEnqueue(stream, pts, dts, data + 9 + n, size - 9 - n);
+    if ((size < 65526) && (stream->CodecID == AV_CODEC_ID_MPEG2VIDEO))
+    {
+      VideoNextPacket(stream, AV_CODEC_ID_MPEG2VIDEO);
     }
-
     return size;
 }

Alles anzeigen

Stefan

447377 · 6. Juli 2018

Zitat von Fourty2

Eventuell habe ich das aber schon gestern behoben (das A/V-Diff steigt und steigt...):

Danke für Deine Mühen. Der weitere Patch zeigt leider keine Änderung.

Es handelt sich um mpeg2, eben nochmal einige Minuten aufgenommen (SD-Sender RTL2, 576i).

Vorspulen: Sprung von einer Minute und dann Suchlauf nach vorne, Zeitanzeige läuft mit. Klick auf Wiedergabe und die aktuelle Position wird gezeigt.

Zurückspule: Sprung von einer Minute nach zurück , dann Suchlauf nach zurück, Zeitanzeige läuft mit. Klick auf Wiedergabe und Sprung zurück auf die Position VOR dem Zurückspulen.

Mit einer anderen Aufnahme (mpeg2, 576i):

Spulen beginnt ab der aktuellen Position ohne diesen anfänglichen Sprung.
Zeit bleibt stehen.
Mit Klick auf die Wiedergabe wird die Position vor dem Spulen angesprungen.

Mit dem Stand von Rofafor, den er Anfang Juli zur Verfügung gestellt hat, geht das Spulen mit diesen Aufnahmen. Allerdings treten da die Probleme wie im Git geschrieben auf. Ton und Video sind asynchron, droped frames, Ton hängt beim Umschalten hinterher und beim Beenden stürzt die VDR-Software ab.

Stefan

447377 · 20. Juli 2018

Ich habe mich nun nochmal ans Testen gemacht. Mit sämtlichen alten softhddevice-Versionen geht das Spulen auch nicht. Ob das nun an Kaby Lake oder vaapi > 2 liegt - keine Ahnung.

Und bei Euch? Habt Ihr ältere Hardware? Geht bei Euch alles?

Stefan

Der_Pit · 22. Juli 2018

Hmm, gerade mal getestet, bei mir scheint das zu gehen. Ich kann 576i Aufnahmen im Schnellvorlauf ansehen, dann auf 'normal' play gehen, und er spielt da weiter, wo der Schnellauf gerade war - das war doch das Problem, oder?

Meins ist ein Gemini Lake (Celeron J4105), vaapi 2.1. Ich verwende allerdings noch das ältere softhddevice 0.7 in der git Version vom 3.2.2018 plus dem speedupdown patch (github.com/pesintta/vdr-plugin-vaapidevice/files/2088359/speedupdown.patch.gz). Könnte mir vorstellen dass es an dem liegt? Ohne den war die Darstellung teilweise sehr hakelig, auch bei Live-TV.

447377 · 22. Juli 2018

Zitat von Der_Pit

Hmm, gerade mal getestet, bei mir scheint das zu gehen. Ich kann 576i Aufnahmen im Schnellvorlauf ansehen, dann auf 'normal' play gehen, und er spielt da weiter, wo der Schnellauf gerade war - das war doch das Problem, oder?

Meins ist ein Gemini Lake (Celeron J4105), vaapi 2.1. Ich verwende allerdings noch das ältere softhddevice 0.7 in der git Version vom 3.2.2018 plus dem speedupdown patch (github.com/pesintta/vdr-plugin-vaapidevice/files/2088359/speedupdown.patch.gz). Könnte mir vorstellen dass es an dem liegt? Ohne den war die Darstellung teilweise sehr hakelig, auch bei Live-TV.

Danke für Deine Rückmeldung. Ich habe jetzt eben zwei Versionen vom 3.2.2018 getestet:

- c99afc2 aus dem vpp-support-Branch

- 9a98c62 aus dem Master-Branch

Bei beiden Versionen gehen duped und droped frames bei der Wiedergabe schnell nach oben und das Spulen von 576i Aufnahmen geht nicht (Schnellvorlauf in beide Richtungen wird zwar dargestellt, aber nach dem Drücken auf Play wird auf die Stelle davor - machmal auch auf eine andere - zurückgesprungen.

Vielleicht könntest Du bitte noch schreiben, welche 0.7er-Softhddevice-Version Du benützt - die Git-Bezeichnung.

Gruß

Stefan

P.s.: Deine Gemini Lake CPU sollte doch mit meiner Kaby Lake verwandt sein. Opensuse Tumbleweed bei Dir und Leap bei mir ist wohl der einzige Unterschied. Eine Firmware für die CPU hast Du nicht separat installiert?

447377 · 22. Juli 2018

So, nun nochmal getestet.

1. Version c99afc2

2. Den speedupdown.patch manuell eingepflegt (großer Zeilenversatz im 1000er Bereich)

Spulen von 576i bzw. Schnellvorlauf geht "in der Regel". Der Rücklauf funktioniert auch, aber die Zeit springt eine Minute zurück und zählt dann herunter. Beim Druck auf Wiedergabe springt die Zeitanzeige wieder eine Minute hoch und die Stelle, ab der die Wiedergabe erfolgt, ist richtig.

Ist das mit der Zeitanzeige (Sprung von einer Minute) beim Rückwärtsspulen bei Euch auch so?

ABER: Die krit. Testaufnahme geht hier genauso wenig wie mit vaapidevice. Bei vdpau alles kein Problem.

Stefan

Der_Pit · 23. Juli 2018

Hi Stefan,

Die Quellen zum Plugin hatte ich damals (IIRC) aus dem easyvdr repo genommen - leider sind da keine git infos mit drin, kann Dir also leider nicht sagen welches der beiden es ist :o

Ja, der patch muss angepasst werden für diese alte Version, aber er ist wirklich essentiell.

Ich werd mir das Spulen anhand Deiner Beschreibung nochmal genauer ansehen, melde mich dann nochmal.

wolfi.m · 23. Juli 2018

Hallo,

Zitat von Der_Pit

Die Quellen zum Plugin hatte ich damals (IIRC) aus dem easyvdr repo genommen - leider sind da keine git infos mit drin,

...mal ins changelog geschaut??

Code

vdr-plugin-softhddevice-vaapi (1:0.7~git20180203-0easyVDR0~trusty) trusty; urgency=high

  * new upstream snapshot
  * sources: https://github.com/rofafor/vdr-plugin-softhddevice
  * commit:c99afc2 - Switch to posix compaatible sched_yield

Gruss

Wolfgang

Der_Pit · 24. Juli 2018

Hi Wolfi,

Danke für die Info (und Deine Arbeit sowieso).

Ich habe hier nur das Tar-Archiv selbst, da ist dieses Changelog nicht drin(?) - die letzten Einträge dort waren von Johns, 2015 :o

Sollte ja auch gar kein Vorwurf sein (ich packe Tars i.a. auch mit --exclude-vcs)

mini73 · 24. Juli 2018

Im orig.tar ist das debian/changelog nie drin.

Lars.

447377 · 7. August 2018

Zitat von Der_Pit

Hi Stefan,

Die Quellen zum Plugin hatte ich damals (IIRC) aus dem easyvdr repo genommen - leider sind da keine git infos mit drin, kann Dir also leider nicht sagen welches der beiden es ist :o

Ja, der patch muss angepasst werden für diese alte Version, aber er ist wirklich essentiell.

Ich werd mir das Spulen anhand Deiner Beschreibung nochmal genauer ansehen, melde mich dann nochmal.

Alles anzeigen

Jetzt habe ich Tumbleweed - wie Du - installiert und alles belassen, keine weiteren bzw. neueren Intel-vaapi-Treiber oder libva kompiliert. Aber gleiches Verhalten beim Spulen - ausschließlich bei SD-Aufnahmen - siehe #36.

Aber jetzt kommt's:

Meinen nvidia-Wohnzimmer-VDR habe ich geupdated und nun vpp_support-softhddevice am laufen. Doch jetzt: Das gleiche Verhalten beim Spulen von SD-Aufnahmen...

- Manchmal geht's.

- Manchmal springt's an die Position vor dem Spulen zurück.

- Manchmal springt die Zeitanzeige 1 Minute vor/zurück und nach dem Spulen wieder eine Minute...

Irgendwas muss sich also getan haben beim Code von softhddevice zwischen 0.6 und 0.7, was sich dann auf vdpau und vaapi auswirkt.

Oder mache ich was falsch - weil das sonst niemand hier beschreibt?

Stefan

vaapidevice: fast forward and rewind of all rtl transmitter does not work

Jetzt mitmachen!

Teilen