[softhddevice] Ton läuft mehrere Sekunden hinterher (ffmpeg 2.2)

Copperhead · 28. März 2014

Hallo johns,

mit ffmpeg 2.2 funktioniert softhddevice nicht mehr richtig.
Der Ton hängt dem Bild mehrere Sekunden hinterher.

Code

Mar 28 14:38:59 vdr4arch vdr[3858]: audio/alsa: using device 'default'
Mar 28 14:38:59 vdr4arch vdr[3858]: audio/alsa: start delay 336ms
Mar 28 14:39:00 vdr4arch vdr[3858]: codec/video: ffmpeg/libav buggy: width or height zero
Mar 28 14:39:00 vdr4arch vdr[3858]: video: decoder buffer empty, duping frame (57/1) 2 v-buf
Mar 28 14:39:00 vdr4arch vdr[3858]: video/vdpau: missed frame (1/3)
Mar 28 14:39:00 vdr4arch vdr[3858]: video: decoder buffer empty, duping frame (58/3) 0 v-buf
Mar 28 14:39:00 vdr4arch vdr[3858]: video: --:--:--.---   +0    0   0/\ms   0+0 v-buf loaded
Mar 28 14:40:00 vdr4arch vdr[3858]: video: decoder buffer empty, duping frame (67/311) 7 v-buf
Mar 28 14:40:00 vdr4arch vdr[3858]: video: --:--:--.---+8888 1333   0/\ms   5+2 v-buf
Mar 28 14:41:00 vdr4arch vdr[3858]: video: --:--:--.---+8888 1366   0/\ms   9+2 v-buf

Außerdem wird die Liste der Deprecated Declarations immer länger.

Code

codec.c: In function 'Codec_get_buffer':
codec.c:204:2: warning: 'type' is deprecated (declared at /usr/include/libavutil/frame.h:318) [-Wdeprecated-declarations]
  frame->type = FF_BUFFER_TYPE_USER;
  ^
codec.c:215:2: warning: 'pkt' is deprecated (declared at /usr/include/libavcodec/avcodec.h:2889) [-Wdeprecated-declarations]
  if (video_ctx->pkt) {
  ^
codec.c:216:6: warning: 'pkt' is deprecated (declared at /usr/include/libavcodec/avcodec.h:2889) [-Wdeprecated-declarations]
      frame->pkt_pts = video_ctx->pkt->pts;
      ^
codec.c:231:2: warning: 'type' is deprecated (declared at /usr/include/libavutil/frame.h:318) [-Wdeprecated-declarations]
  frame->type = FF_BUFFER_TYPE_USER;
  ^
codec.c:240:2: warning: 'pkt' is deprecated (declared at /usr/include/libavcodec/avcodec.h:2889) [-Wdeprecated-declarations]
  if (video_ctx->pkt) {
  ^
codec.c:241:6: warning: 'pkt' is deprecated (declared at /usr/include/libavcodec/avcodec.h:2889) [-Wdeprecated-declarations]
      frame->pkt_pts = video_ctx->pkt->pts;
      ^
codec.c:248:5: warning: 'avcodec_default_get_buffer' is deprecated (declared at /usr/include/libavcodec/avcodec.h:3744) [-Wdeprecated-declarations]
     return avcodec_default_get_buffer(video_ctx, frame);
     ^
codec.c: In function 'Codec_release_buffer':
codec.c:300:5: warning: 'avcodec_default_release_buffer' is deprecated (declared at /usr/include/libavcodec/avcodec.h:3745) [-Wdeprecated-declarations]
     return avcodec_default_release_buffer(video_ctx, frame);
     ^
codec.c: In function 'CodecVideoOpen':
codec.c:475:2: warning: 'get_buffer' is deprecated (declared at /usr/include/libavcodec/avcodec.h:2079) [-Wdeprecated-declarations]
  decoder->VideoCtx->get_buffer = Codec_get_buffer;
  ^
codec.c:476:2: warning: 'release_buffer' is deprecated (declared at /usr/include/libavcodec/avcodec.h:2093) [-Wdeprecated-declarations]
  decoder->VideoCtx->release_buffer = Codec_release_buffer;
  ^
codec.c:477:2: warning: 'reget_buffer' is deprecated (declared at /usr/include/libavcodec/avcodec.h:2108) [-Wdeprecated-declarations]
  decoder->VideoCtx->reget_buffer = Codec_get_buffer;
  ^
codec.c:492:2: warning: 'get_buffer' is deprecated (declared at /usr/include/libavcodec/avcodec.h:2079) [-Wdeprecated-declarations]
  decoder->VideoCtx->get_buffer = Codec_get_buffer;
  ^
codec.c:493:2: warning: 'release_buffer' is deprecated (declared at /usr/include/libavcodec/avcodec.h:2093) [-Wdeprecated-declarations]
  decoder->VideoCtx->release_buffer = Codec_release_buffer;
  ^
codec.c:494:2: warning: 'reget_buffer' is deprecated (declared at /usr/include/libavcodec/avcodec.h:2108) [-Wdeprecated-declarations]
  decoder->VideoCtx->reget_buffer = Codec_get_buffer;
  ^
codec.c:506:5: warning: 'avcodec_alloc_frame' is deprecated (declared at /usr/include/libavcodec/avcodec.h:3422) [-Wdeprecated-declarations]
     if (!(decoder->Frame = avcodec_alloc_frame())) {
     ^
codec.c: In function 'CodecAudioOpen':
codec.c:782:2: warning: 'request_channels' is deprecated (declared at /usr/include/libavcodec/avcodec.h:1983) [-Wdeprecated-declarations]
  audio_decoder->AudioCtx->request_channels = 2;
  ^

Alles anzeigen

Ich habe schon versucht herauszufinden, durch was das alles ersetzt worden ist. Finden konnte ich das aber nicht.

Copperhead · 28. März 2014

Wie ich es befürchtet habe wurde ffmpeg 2.2 in die Stable Repositories aufgenommen.
https://www.archlinux.org/packages/extra/x86_64/ffmpeg/

Das heißt, sollte jetzt jemand vdr4arch nutzen und ein Update starten, geht gar nichts mehr.

iNOB · 28. März 2014

Die 2.2 hatte ich mir versuchsweise unter Debian Wheezy zusammencompiliert und konnte den gleichen Effekt feststellen.

fnu · 28. März 2014

Copperhead

Ich kenne ja auch die Nöte als Distributor und da liegt halt die Aufgabe drin, das zu managen. Lobenswert eine Distro die immer super aktuell ist, aber eben auch am Bleeding Edge agiert, was nicht immer nötig oder gar hilfreich ist. Arch hat sein Metronom, die VDR Welt eben ihr eigenes ...

Gibt es keine Möglichkeit das Du eigene Abhängigkeiten definierst?

Regards
fnu

Copperhead · 28. März 2014

Was genau meinst du damit?
Ich kann mein Paket an eine ffmpeg Version binden. Allerdings nicht an die viel interessantere API Version.
Das löst zwar das Problem der Inkompatibilität, produziert aber einige neue.

Wenn ich fest auf eine alte Version depende wird solange gar kein Update mehr ausgeführt. Pacman differenziert da leider nicht.
Es entsteht einfach eine Konfliktsituation, die nicht aufgelöst werden kann. (Installiertes Paket will Paket, dass auf dem Server nicht vorhanden ist)

Als nächste Möglichkeit könnte ich ffmpeg selber ausliefern.
Dummerweise hat das vdr4arch Repository bewusst die geringste Priorität. Ich müsste also die Priorität über die aller anderen Repos stellen.
Dann würde softhddevice funktionieren, aber sonst nichts mehr, was auf ffmpeg basiert.

Eigentlich sollte es auch noch funktionieren. die API Versionen von ffmpeg haben sich nicht geändert. Die x264 Version hat das aber.
softhddevice hat eine binäre Abhängigkeit zur libx264. Das haben andere Pakete in Arch Linux auch, dort hat aber einfaches Neukompilieren gereicht.

Kompilieren funktioniert ja auch. Da die Funktionen aber alle deprecated sind (und das schon seit einigen Versionen)achtet da niemand mehr drauf, ob es auch funktioniert.
Alle anderen Projekte nutzen diese Funktionen von vornherein nicht, oder haben schon entsprechend aktualisiert.

In gewisser Weise gebe ich mir auch selbst die Schuld. Ich hätte es früher merken müssen. Das neue ffmpeg ist die letzte Woche vom Staging Repo ins Testing Repo und heute schließlich ins Extra Repo gewandert.
Ich weiß schon seit Montag von der Version, weil mich ein Cronjob auf solche Dinge hinweist.

Sollte sich das hier als längerfristiges Problem herausstellen bleibt mir nichts anderes übrig, als ffmpeg statisch einzukompilieren.

Copperhead · 28. März 2014

Hmm. Wieder etwas gelernt. Arch Linux bietet auch ein ffmpeg-compat Paket an.
Das ist im Prinzip der neuste ffmpeg 0.10 Branch. Das wird ja auch noch gepflegt.

Damit funktioniert alles und das ist wohl auch abgehangen genug.
Mal sehen, wie lange ich damit gut fahre.

fnu · 28. März 2014

Zitat von Copperhead

Mal sehen, wie lange ich damit gut fahre.

Weiß Du, es muß nicht immer schön sein, es reicht wenn's verlässlich funktioniert ...

Eigentlich dachte ich nicht an fest Einkomplieren, mehr dran das Du evtl. ein passendes ffmpeg als eigene Abhängigkeit bei Dir reinpackst ... ?

Regards
fnu

Copperhead · 28. März 2014

Zitat von fnu

Eigentlich dachte ich nicht an fest Einkomplieren, mehr dran das Du evtl. ein passendes ffmpeg als eigebe Abhängigkeit bei Dir reinpackst ... ?

Ich dachte mehrere ffmpeg Version funktionieren nicht nebeneinander. Dann habe ich das ffmpeg-compat Paket gesehen.

Sollte es das einmal nicht mehr geben, werde ich, wie du schon sagst, ein eigenes ffmpeg-compat paketieren.

attuska · 28. März 2014

Na ja!

Auch die SD Sender rückeln wieder mit ffmpeg-2.2!

attuska · 31. März 2014

Aber das ist keine vernünftige Lösung mein Lieber Copperhead, das du mit einer älteren, oder selbst gebastelten ffmpeg-version den Softhddevice-plugin aufbaust!

Du mußt schon ffmpeg-2.2 benutzen!
Und ich auch,
Und noch Viele!

Wier müßten daher Johns bitten, den Plugin mit ffmpeg-2.2 kompatibel zu machen.

Und ich bitte jetzt ihn dafür.

(Entschuldigung für mein schlechtes Deutsch, mein Muttersprache ist Ungarish "magyar" )

Copperhead · 31. März 2014

Das ist eine temporäre Lösung.

Vielleicht sogar eine dauerhafte. Ich bin es Leid.
Anpassungen an neue ffmpeg Versionen werden immer erst nach dem Release selbiger durchgeführt.

Kommentare zu Git Ständen werden einfach ignoriert. Würde man sich am Git orientieren. Wie das die anderen Projekte auch machen. Gäbe es solche Probleme erst gar nicht.

Vielleicht bin ich da durch Arch Linux auch etwas überempfindlich. Neue ffmpeg Versionen werden nach spätestens 7 Tagen ausgeliefert. Meistens sogar deutlich schneller.

fnu · 31. März 2014

Zitat von Copperhead

Kommentare zu Git Ständen werden einfach ignoriert. Würde man sich am Git orientieren. Wie das die anderen Projekte auch machen. Gäbe es solche Probleme erst gar nicht.

Soll jeder der ein Plugin für VDR entwickelt ständig das ffmpeg GIT überwachen?

Gegenfrage, wieso orientiert sich Arch Linux nicht am Tempo der VDR Entwicklung oder dessen Benötigungen?

Arch ist nicht der Mittelpunkt, genauso wenig Debian, Ubuntu, gentoo etc. sondern eben VDR selbst ist das Thema. In Debian/Ubuntu haben wir auch genug Probleme gerade das ffmpeg Thema zu lösen, aber wir versuchen es wenigstens ...

attuska

Wenn Du möchtest das softhdhdevice mit ffmpeg 2.2 jetzt sofort läuft, lieferst Du am Besten Patches an johns der die Software in seiner wertvollen Freizeit entwickelt, oder hast eben Geduld. Wir haben hier auch einen weiteren Ungarn der sicher mit Übersetzung beim Verständnis helfen kann ...

Regards
fnu

mini73 · 31. März 2014

Zitat von Copperhead

Neue ffmpeg Versionen werden nach spätestens 7 Tagen ausgeliefert. Meistens sogar deutlich schneller.

Das Problem ist nicht der schnelle Release-Zyklus von Arch-Linux, sondern die Art und Weise, wie die Leute im ffmpeg-Team arbeiten. Warum funktioniert eine API in der Version 2.1, aber in 2.2 nicht mehr? Dann hätten sie sie gleich entfernen sollen oder ein ffmpeg 3.0 oder sonst was machen sollen. Aber inkompatible Änderungen innerhalb einer Major-Version taugen doch nichts. Ich sag nur "never break userspace".

Da kann man in seiner Freizeit doch gar nicht hinterher kommen.

Und ich sehe da überhaupt kein Problem darin, etwas auf eine alte Version zu pinnen, wenn die neue "nichts taugt" bzw. die Nutzer der Lib erst mal Zeit brauchen, um die Kompatibilität zu testen. git-Stände schon und gut, aber da parallel zu programmieren ist auch keine Lösung und teilweise eine Menge Arbeit, insbesondere, wenn sich zwischendurch die API ändert. Da hinterher zu programmieren bringt keinen Spaß, dafür gibt es ja die Releases.

Lars.

Copperhead · 31. März 2014

fnu: Ich habe ja gesagt, dass ich da wahrscheinlich etwas überempfindlich bin.

Ich habe eine funktionierende Lösung gefunden, mit der ich nichtmal ffmpeg selbst kompilieren muss. Was will man mehr...

fnu · 31. März 2014

Zitat von Copperhead

Ich habe eine funktionierende Lösung gefunden, mit der ich nichtmal ffmpeg selbst kompilieren muss. Was will man mehr...

Eben, das ist doch gut und kannst in Ruhe gucken wie es weiter geht ...

johns · 31. März 2014

ffmpeg 2.2 ist auch bei gentoo als unstable angekommen und geht auch bei mir nicht.
Werde demnächst mal gucken, woran es liegt. Ob zuwenig dekodiert wird oder nur die Zeitstempel fehlen oder falsch sind.

deprecated werde ich erst in der nächsten Version (0.7) beheben. Ich will vorher noch eine "0.6.1" veröffentlichen.

Johns

attuska · 31. März 2014

Nun habe ich jetzt ffmpeg-2.2 und den dazu passenden Softhddevice-plugin auf mein System temporarly installiert, vdr startet mit "-Psofthddevice -a none "und in meinem Syslog sehe ich folgendes:

Code

Mar 31 21:17:57 localhost vdr: [softhddev] 2 invalid PES video packet(s) 
Mar 31 21:17:57 localhost vdr: [24965] EPGSearch: timer conflict check started
Mar 31 21:17:57 localhost vdr: [24964] EPGSearch: search timer update started
Mar 31 21:17:57 localhost vdr: [24965] EPGSearch: timer conflict check finished
Mar 31 21:17:57 localhost vdr: [24964] EPGSearch: search timer update finished
Mar 31 21:17:58 localhost vdr: video/vdpau: missed frame (1/0) 
Mar 31 21:17:58 localhost vdr: video: decoder buffer empty, duping frame (1/8) 0 v-buf 
Mar 31 21:17:58 localhost vdr: video: --:--:--.--- +0 0 0/\ms 0+5 v-buf 
Mar 31 21:17:58 localhost vdr: [24939] retuning due to modification of channel 1
Mar 31 21:17:58 localhost vdr: [24939] switching to channel 1
Mar 31 21:17:58 localhost vdr: [24939] [softhddev]SetPlayMode: 0 
Mar 31 21:17:58 localhost vdr: [24939] [softhddev]SetVideoDisplayFormat: 0 
Mar 31 21:17:58 localhost vdr: [24939] [softhddev]GetSpuDecoder: 
Mar 31 21:17:58 localhost vdr: [24973] TS buffer on device 1 thread ended (pid=24939, tid=24973)
Mar 31 21:17:58 localhost vdr: [24971] buffer stats: 19928 (0%) used
Mar 31 21:17:58 localhost vdr: [24971] receiver on device 1 thread ended (pid=24939, tid=24971)
Mar 31 21:17:58 localhost vdr: [24975] receiver on device 1 thread started (pid=24939, tid=24975, prio=high)
Mar 31 21:17:58 localhost vdr: [24976] TS buffer on device 1 thread started (pid=24939, tid=24976, prio=high)
Mar 31 21:17:58 localhost vdr: [24939] [softhddev]SetPlayMode: 1 
Mar 31 21:17:58 localhost vdr: audio: can't set channels 0 sample-rate 0Hz 
Mar 31 21:17:58 localhost vdr: audio: 2 channels unsupported 
Mar 31 21:17:58 localhost vdr: video: decoder buffer empty, duping frame (38/14) 0 v-buf 
Mar 31 21:17:58 localhost vdr: video/vdpau: missed frame (2/0) 
Mar 31 21:17:59 localhost vdr: video: decoder buffer empty, duping frame (39/6) 0 v-buf 
Mar 31 21:17:59 localhost vdr: video: --:--:--.--- +0 0 0/\ms 0+5 v-buf 
Mar 31 21:18:44 localhost vdr: video: decoder buffer empty, duping frame (756/2276) 1 v-buf 
Mar 31 21:18:44 localhost vdr: video: --:--:--.--- +0 0 0/\ms 1+5 v-buf 
Mar 31 21:18:53 localhost vdr: [24977] logger 1 filter thread started (pid=24939, tid=24977, prio=high)
Mar 31 21:19:06 localhost vdr: [24939] Power button pressed
Mar 31 21:19:06 localhost vdr: [24939] confirm: Nyomj egy gombot a leállás megszakításához

Alles anzeigen

Der Sender rückelt trotzdem.
Jetz mache ich meine installierte Dinge rückgaengig.

Ichbenutze und pflege übrigens UHU Linux ubk Version, und mache die zu installierenden Packete für mich (und andere) selbst, und möchte den ffmpeg-2.0 Packet veröffentlichen.

attuska · 1. April 2014

Ich füge eine Datei bei.

Ich habe den Plugin mit -DDEBUG herstellt, so ist der Log schöner, und vielleicht auch nützlicher!

johns · 1. April 2014

Problem ist wie schon vermutet, daß die Zeitstempel nicht ankommen.

Aber ohne Zeitstempel sollte das Bild auch einwandfrei und ohne Ruckler sein.
Nach dem Umschalten sollte nach ein paar Sekunden das Bild ruhig laufen.

Eine Synchronisation ist ohne Zeitstempel nicht möglich.

Diff

iff --git a/codec.c b/codec.c
index be6ed29..845233e 100644
--- a/codec.c
+++ b/codec.c
@@ -225,8 +225,10 @@ static int Codec_get_buffer(AVCodecContext * video_ctx, AVFrame * frame)
        // reordered frames
        if (video_ctx->pkt) {
            frame->pkt_pts = video_ctx->pkt->pts;
        } else {
-           frame->pkt_pts = AV_NOPTS_VALUE;
+           // frame->pkt_pts = AV_NOPTS_VALUE;
        }
        return 0;
     }

Alles anzeigen

Ist ein Quickfix, Auswirkungen auf andere ffmpeg/libav Versionen muß erst getestet werden.

Johns

attuska · 1. April 2014

Danke Johns!

Ich habe zwar deinen Patch ein bißchen modifieren müssen, aber jetzt der Sofhddevice-plugin (0.6.1rc1) scheint wieder einwandfrei mit ffmpeg-2.2, und ffmpeg-1.4 zu funktionieren!

Diff

diff -Naur orig/codec.c mod/codec.c
--- orig/codec.c	2013-09-30 20:54:27.000000000 +0200
+++ mod/codec.c	2014-04-01 14:15:00.000000000 +0200
@@ -215,7 +215,7 @@
 	if (video_ctx->pkt) {
 		frame->pkt_pts = video_ctx->pkt->pts;
 	} else {
-		frame->pkt_pts = AV_NOPTS_VALUE;
+		//frame->pkt_pts = AV_NOPTS_VALUE;
 	}
 	return 0;
 	}
@@ -240,7 +240,7 @@
 	if (video_ctx->pkt) {
 		frame->pkt_pts = video_ctx->pkt->pts;
 	} else {
-		frame->pkt_pts = AV_NOPTS_VALUE;
+		//frame->pkt_pts = AV_NOPTS_VALUE;
 	}
 	return 0;
 	}

Alles anzeigen

[softhddevice] Ton läuft mehrere Sekunden hinterher (ffmpeg 2.2)

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema