[SoftHdDevice] und >= ffmpeg 1.1

johns · 17. Februar 2013

Für 1.1.2 gibts schon einen ebuild, damit sollte es einfach sein.
Dauert halt etwas und ob ich den Fehler sofort sehe, wird sich auch noch
zeigen.

Johns

johns · 18. Februar 2013

So langsam stinkt mir das Ganze.

Diff

diff --git a/video.c b/video.c
index 265adf6..21f182c 100644
--- a/video.c
+++ b/video.c
@@ -5965,6 +5965,8 @@ static VdpauDecoder *VdpauNewHwDecoder(VideoStream * stream)
     decoder->OutputWidth = VideoWindowWidth;
     decoder->OutputHeight = VideoWindowHeight;
 
+    decoder->PixFmt = PIX_FMT_NONE;
+
     decoder->Stream = stream;
     if (!VdpauDecoderN) {              // FIXME: hack sync on audio
        decoder->SyncOnAudio = 1;
@@ -6809,6 +6811,13 @@ static enum PixelFormat Vdpau_get_format(VdpauDecoder * decoder,
     VdpDecoderProfile profile;
     int max_refs;
 
+#if 1
+    // this begins to stink
+    if (decoder->PixFmt == *fmt) {
+       return *fmt;
+    }
+#endif
+
     Debug(3, "video: new stream format %dms\n", GetMsTicks() - VideoSwitch);
 
     if (!VideoHardwareDecoder || (video_ctx->codec_id == CODEC_ID_MPEG2VIDEO

Alles anzeigen

Ursache ist das get_format nun für jede Frame aufgerufen wird, was natürlich für die Performance richtig toll ist.
Ich ordne sowas unter Vollpfosten am Werk ein.
Änderung ist erstmal Quick&Dirty, muß noch auf Seiteneffekte usw. abgeleuchtet werden.
Ansonsten wird mit -DDEBUG noch das Log vollgemüllt.

Johns

johns · 18. Februar 2013

Habe noch eine bessere Version:

Nur diesen Patch verwenden:

Diff

diff --git a/codec.c b/codec.c
index 9b98677..e66ad79 100644
--- a/codec.c
+++ b/codec.c
@@ -131,11 +131,24 @@ static enum PixelFormat Codec_get_format(AVCodecContext * video_ctx,
 {
     VideoDecoder *decoder;
 
+    decoder = video_ctx->opaque;
+#if LIBAVCODEC_VERSION_INT == AV_VERSION_INT(54,86,100)
+    // this begins to stink, 1.1.2 calls get_format for each frame
+    if (decoder->GetFormatDone) {
+       if (decoder->GetFormatDone < 10) {
+           ++decoder->GetFormatDone;
+           Error
+               ("codec/video: ffmpeg/libav buggy: get_format called again\n");
+       }
+       return *fmt;                    // FIXME: this is hack
+    }
+#endif
+
+    // bug in ffmpeg 1.1.1, called with zero width or height
     if (!video_ctx->width || !video_ctx->height) {
-       Error("codec/video: ffmpeg/libav buggy\n");
+       Error("codec/video: ffmpeg/libav buggy: width or height zero\n");
     }
 
-    decoder = video_ctx->opaque;
     decoder->GetFormatDone = 1;
     return Video_get_format(decoder->HwDecoder, video_ctx, fmt);
 }

Alles anzeigen

Der vorherige Patch entfernen und nicht verwenden.
Johns

Copperhead · 20. Februar 2013

Nochmal eine Rückmeldung zu dem Patch. Alle Sender funktionieren.
Allerdings wird bei Prosieben HD beim Wechsel von Film zu Werbung und von der Werbung zum Film das Bild ins Stocken gebracht. Das hängt dann 5-10sec. Es fehlt aber auch immer ein Stück Ton.

Außerdem ist bei Nick Comedy HD das A/V Delay anders als bei den anderen Sendern. Mit dem neuen FFmpeg ist dieser Unterschied noch größer geworden.

johns · 21. Februar 2013

Dann werde ich den ins GIT übernehmen. Der Patch ist aber nur für exact die Version 1.1.2 aktiv, bei der
nächsten müssen wir mal schauen ob das Problem immer noch drin ist.

Habe jetzt keine Idee was beim Wechsel schief gehen kann, vielleicht haben die für Werbung andere Zeitstempel.
Ansonsten gibts es nur einen Tonwechsel und der funktioniert ohne Probleme. Du kann versuchen wenn du die
Audiospur wechselst bei dem Sender, ob sich die gleichen Symtome zeigen. (Edit: wobei mir gerade einfällt,
ich habe dies immer nur bei LiveTv getestet)

Bei Nick/CC solltest du mal ins Log gucken, was er anmeckert. Meiner Meinung nach werden die Videopuffer immer
leer sein. Dann mal die Audio Puffer Zeit hochdrehen.

Johns

Hitman47 · 21. Februar 2013

Für archlinux wurde eine neues ffmpeg-Paket (1.1.2-3) veröffentlicht, das den letzten Patch gegen das Gezappel bei HD-Sendern wohl wieder überflüssig macht.
https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/ffmpeg&id=44f18945ee24c84ce182341c12c6cdca139825bd

Bei einem ersten flüchtigen Test meinerseits scheint es auch zu klappen.

Zitat von johns

Habe jetzt keine Idee was beim Wechsel schief gehen kann, vielleicht haben die für Werbung andere Zeitstempel.
Ansonsten gibts es nur einen Tonwechsel und der funktioniert ohne Probleme. Du kann versuchen wenn du die
Audiospur wechselst bei dem Sender, ob sich die gleichen Symtome zeigen. (Edit: wobei mir gerade einfällt,
ich habe dies immer nur bei LiveTv getestet)

Bei Aufnahmen kommt es nach einem Tonspurwechsel tatsächlich zu asynchronem Bild/Ton. Live-TV geht problemlos.
Edit: Nach Umschalten der Tonspur, synchronisiert es nun nach ein paar Sekunden. Das geht scheinbar auch mit dem neuen ffmpeg-Release einher. Es könnte aber schneller gehen... Vorher synchronisierte es jedenfalls gar nicht.

So long.

Copperhead · 21. Februar 2013

Ich habe jetzt noch nicht großartig viel getestet. Aber ich habe mir mal die Logs angeschaut und die Videopuffer sind gefüllt:

Code

video: 13:35:06.948  -14  875   0/\ms  71+7 v-buf

A/V passt immernoch nicht. Ist aber komischerweise nur bei Nick/CC HD.

Copperhead · 21. Februar 2013

Standbilder funktionieren bei Sixx HD nicht. Es bleibt immer das Bild von der letzten Wiedergabe stehen.

Edit: Ich schaue jetzt seit ein paar Stunden Nick / CC HD. Ich bin mir mittlerweile ziemlich sicher, dass der Versatz wandert. Als ob der beim Umschalten richtig gestellt und dann nicht mehr beachtet wird. Nick /CC HD ändert das aber scheinbar. Ist nur eine Theorie, aber kann da was dran sein und wie kann ich das am besten beweisen?

Edit2: Mein System läuft übrigens mit 50Hz. Mit 60Hz wandert der Versatz bei mir immer. Das sieht man aber dann auch im Log. Bie Nick/CC HD mit 50Hz sieht man aber im Log gar nichts.

MegaV0lt · 24. Februar 2013

Mal OT (Habe S2-6400): Mir ist auch aufgefallen, dass auf Nick/CC HD der Ton um ca. 0,75 s versetzt ist. Bei allen anderen Aufnahmen ist es i.O. Vielleicht liegt es am Sender? Gibt es denn "Beweise", dass es auf anderer HW funktioniert?

johns · 24. Februar 2013

Die werden halt hier SD Bild auf HDTV hochblasen, damit werden die eine Verzögerung erzeugen.

Im syslog steht ja mein Versatz und bei HD ist der Deltawert 0, daß "0 /\". Damit kann ich keine
Berechnungsfehler haben. Also kann der A/V Versatz sich nicht verändern, entweder immer richtig
oder immer falsch.

Johns

Copperhead · 24. Februar 2013

So ein Murks. Ich schau morgen wieder Comedy Central. Ich probiere dann mal den SD-Kanal.

johns · 25. Februar 2013

Zitat von Hitman47

Für archlinux wurde eine neues ffmpeg-Paket (1.1.2-3) veröffentlicht, das den letzten Patch gegen das Gezappel bei HD-Sendern wohl wieder überflüssig macht.
https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/ffmpeg&id=44f18945ee24c84ce182341c12c6cdca139825bd

Bei einem ersten flüchtigen Test meinerseits scheint es auch zu klappen.

Bei Aufnahmen kommt es nach einem Tonspurwechsel tatsächlich zu asynchronem Bild/Ton. Live-TV geht problemlos.
Edit: Nach Umschalten der Tonspur, synchronisiert es nun nach ein paar Sekunden. Das geht scheinbar auch mit dem neuen ffmpeg-Release einher. Es könnte aber schneller gehen... Vorher synchronisierte es jedenfalls gar nicht.

Alles anzeigen

Inzwischen gibt es schon 1.1.3, mal gucken was darin wieder nicht geht.
Das TON umschalten bei Aufnahmen muß ich mir nochmal genau angucken.
Ich denke ist aber kein ffmpeg Problem.

Edit: also 1.1.3 funktioniert wieder, toll die haben nicht mal die Version verändert.
Die Funktion wird zwar bei H264 zweimal aufgerufen, aber dies dürfte kein so großes Problem sein.

Johns

grappi · 25. Februar 2013

Hi,

mit der aktuellen ffmpeg Version ist jetzt das Problem mit den Streifen im SD-Bild behoben.
Ich habe auch bei Nick/CC HD das Problem mit dem Tonversatz und außerdem bei 1080i-Sendern kleine Ruckler.

Das Logfile ist voll von:

Code

vdr: video: speed up video, droping frame
vdr: video:  4:42:11.118 -109  352   0/\ms  48+5 v-buf
vdr: video: decoder buffer empty, duping frame (327/5252) 47 v-buf
vdr: video:  4:42:11.158  -84  337   0/\ms  47+5 v-buf
vdr: video: speed up video, droping frame
vdr: video:  4:42:11.158 -102  319   0/\ms  47+5 v-buf
vdr: video: decoder buffer empty, duping frame (328/5254) 47 v-buf
vdr: video:  4:42:11.198  -79  335   0/\ms  47+5 v-buf
vdr: video: speed up video, droping frame
vdr: video:  4:42:11.198  -97  349   0/\ms  47+5 v-buf
vdr: video: speed up video, droping frame
vdr: video: decoder buffer empty, duping frame (329/5262) 45 v-buf
vdr: video:  4:42:11.358  -42  339   0/\ms  45+5 v-buf
vdr: video: speed up video, droping frame
vdr: video:  4:42:11.358  -58  323   0/\ms  45+5 v-buf
vdr: video: speed up video, droping frame
vdr: video/vdpau: missed frame (141/5276)
vdr: video: speed up video, droping frame
vdr: video:  4:42:12.858  -23  331   0/\ms  42+6 v-buf
vdr: video/vdpau: missed frame (142/5344)

Alles anzeigen

Mit der 1.1.-Version von ffmpeg treten die Probleme nicht auf.

grappi

johns · 25. Februar 2013

Kann ich nicht nachvollziehen.

Live TV von Anixe HD und Servus HD Östreich läuft ohne Besonderheiten.
Waren zwar ein paar "dekoder too slow" dazwischen, aber die sollten passieren können.

Johns

grappi · 25. Februar 2013

Komisch, weder mit der 1.1. noch 1.1.2. treten diese Meldungen im Log auf.
Sobald ich die 1.1.3. installiere kommen im Sekundentakt die besagten Meldungen.

Komme heute leider nicht meht zum Testen. Werde wohl Morgen noch einmal einen Blick darauf werfen.

grappi

grappi · 26. Februar 2013

Hi,

man sollte seine Links richtig setzen.
Ich hatte nicht die 1.1.3 installiert, sondern eine Git-Version vom 24.02.
Mit der 1.1.3. läuft, nach einem kurzen Test, auch hier jetzt alles einwandfrei!

DANKE

grappi

Copperhead · 28. Februar 2013

Nochmal wegen Comedy Central. Da das ja scheinbar speziell bei diesem Sender ist. Könnte man dann da als Workaround prüfen ob CC HD geschaut wird und dann einen noch zu bestimmendes Delay einstellen?

johns · 1. März 2013

Möglich ist alles, nichts ist unmöglich.

Geht aber nur über die Kanalnummer. Oder gibt es User Einträge im channel.conf?

Da aber von wanderten Delay gesprochen wurde, klappt dies auch nicht.

Man kann über die Fernbedienung den AudioDelay verändern.

Johns

mini73 · 1. März 2013

Moin!

Wenn, dann würde ich die Channel-ID nehmen, nicht die Kanalnummer, weil die ID sich nicht wirklich ändert, die Nummer aber bei Umsortierung schon.

Lars.

Copperhead · 1. März 2013

Zitat von johns

Da aber von wanderten Delay gesprochen wurde, klappt dies auch nicht.

Ich schau nochmal genauer. Vielleicht ist es mir von Szene zu Szene auch unterschiedlich stark aufgefallen. Wann wird eigentlich ein verstelltes Delay übernommen? Wenn ich die Einstellungen mit OK schließe oder erst wenn ich neu auf den Sender schalte?

[SoftHdDevice] und >= ffmpeg 1.1

Jetzt mitmachen!

Teilen