Beiträge von johns

Dann wäre ein X11 Server für Android und graphtftng eine Möglichkeit.

Johns

Ich denke, die DVB Option hat keine Funktion mehr für SoftHdDevice.
Im Normalfall wirst du immer einen schwarzen Rand sehen. Es gibt ja keine 4:3 Sender mehr.
Und du musst die 16:9 ändern, da deine Auflösung keine echten 4:3 ist. 4:3 wären 720x540 oder 768x576.

Johns

Es ist schwierig sowas zutesten. Es sind mehrere Threads, der eine Thread schreibt die Tondaten.
Jetzt flushed du die vom zweiten Thread,

Sauber aber auch nicht viel besser, wäre ein "volatile" Flag und der AudioThread macht dies.

Die komplizierte Lösung wäre entweder Locks oder ein zweiter Ringbuffer für Befehle.

Zitat

Daran habe ich auch schon gedacht.
Edit: Soweit ich das überblicke, macht dein Code das bereits, und es hilft nicht.
Edit2: Dass es nicht hilft, liegt soweit ich mich erinnere an Alsa, man müsste vorher drain oder drop machen, da ist flush einfacher.
Theoretisch könnte man auch Nullen ins Audio füttern.

Das Problem sollten doch alle Alsaprogramme haben?
Mal geguckt wie mpv, xine, vlc dieses Problem löst?

Es passieren ja auch Underruns im normalen Betrieb und da kann man nicht einfach ein Flush machen.

Johns

Intressant wusste garnicht das ein grafdroid gab.

Gibt es den ein X11 Statusplugin?
Wenn ja, dann könnte man unter Android ein X11 Server laufen lassen und so die Statusanzeige auf das Tablet bekommen.

Johns

Das mit dem Flush habe ich falsch gelesen.

AudioUsedModule->FlushBuffers();

Diese F'unktion flushed wirklich nur die Kernelpuffer. Aber der Aufruf an dieser Stelle, kann problematisch sein.
AudioPause(); wird aus dem VDR Thread aufgerufen. Es arbeitet aber noch der Audiothread.
Beim Umschalten wird deshalb über den Ringpuffer mit dem Audiothread kommuniziert.

Zitat

Ist es überhaupt sinnvoll, den Alsapuffer „aufzuheben“ und ihn nach der Pause weiter zu spielen?
Zur Zeit spielt Alsa nach einer Pause weiter, bis der Alsapuffer (fast) leer ist. Insofern gibt es beim jetzigen Verhalten nichts aufzuheben.

Das ist falsch und ein Hack von mir. Wobei etwas ähnliches auch beim Video passiert. Das Video spielt auch noch die gepufferten Frames ab.

Ich stoppe nur das "Füttern" und nicht das abspielen.

Zitat

Die Frage ist, ob/wie man vor dem Schreibversuch wissen kann, dass der Underrun schon vorbei ist.
Gibt es da eine Alsa-Abfrage? Dann könnte man den Underrun abwarten und danach schreiben.
Was für einen Vorteil bringt das aber?

Dies scheint der eigentliche Fehler zusein.

audio/alsa: wrote -32/122354 frames

Entweder habe ich diesen Fall falsch abgefangen oder es lliegt an 'ALSA.
Ich danke man kann Underruns auch extra abfragen, aber der Recover in dem Write sollte auch einwandfrei funktionieren.
Der Recover sollte ein paar ms kosten und nicht den A/V total aus dem Takt bringen.

Johns

So nun die finale Version des Fixes für kein Softstart bei Sprüngen.

Bei Aufnahmen und bei VDR Geräte die einen eigenen Puffer haben (satip) sollte Bild und Ton sofort loslaufen.
Sollte der ungewöhnliche Fall auftreten, daß keine Zeitstempel kommen, dann löuft der Ton los bevor der VDR wegen Puffer voll stoppt.
Bei Radiosendern läuft nun der Ton los, sobald genug gepuffert ist.

Was mir noch gerade einfällt, was passiert beim Radio Plugin, das ein mpeg abspielt?

Johns

Streamdev includes a web interface and support http streams.

Point your browser to http://ip-or-name-of-your-vdr:3000, than you can select channel and format to play.
Inside the home there should be no problem, android and windows clients should be able to play without problems.

When you want to look from outside, than your internet connections limits the bandwidth.
See http://www.vdr-wiki.de/wiki/index.php/Externremux.sh to build a stream which fits into your bandwidth.

Johns

Zitat von jrie

Der Fehler tritt auf, wenn AlsaPlayRingbuffer() schreiben will, bevor er leer gelaufen ist.
Dann läuft Video und wird gedoppelt, obwohl Alsa nichts spielt, und die Ringbufferbelegung steigt immer mehr.
Bis Alsa los läuft, und die Ringbufferbelegung fällt und Video gedropt wird, bis er wieder synchron ist.

Dies behebt nur den Fehler und nicht die Ursache.

Beim Pausieren sollte nicht verlohren gehen. Mit dem Flush werden die Tonpuffer gelöscht und es erfolgt eine neu Synchronisation, wie bei Sprüngen.

AudioPaused

Wenn ich es richtig sehe, dann fülle ich nur den Kernelpuffer nicht mehr, was noch im Kernel ist wird abgespielt.
Da gehen auf jedenfall ca. 96ms verloren.
Es müsste nach einer Pause auf jedenfall "wait underrun error" im Log kommen.

Johns

Zitat von jrie

Ich habe ffmpeg 2.7.2 und immer 0/\ms.
Was ist mit "FIXME: not aligned for ffmpeg" in softhddev.c gemeint? Eben diese Schwankungen oder was anderes?

ffmpeg braucht für das Dekodieren "aligned" Puffer, mit extra Arbeitsbereich.
Dies ist hier nicht gegeben.

void CodecAudioDecode(AudioDecoder * audio_decoder, const AVPacket * avpkt)
{
    int16_t buf[(AVCODEC_MAX_AUDIO_FRAME_SIZE * 3) / 4 +
        FF_INPUT_BUFFER_PADDING_SIZE] __attribute__ ((aligned(16)));

Hier wird dann die Daten in buf umkopiert. Dieses kopieren kann man sparen, wenn der Aufrufer die Daten schon richtig übergibt.

Johns

Zitat von jrie

Empfiehlst du auf 2.9 umzusteigen?

Ja schon, aber der Punkt ist, dass es manchmal geht, und manchmal nicht, und ich versuche heraus zu bekommen, was den Unterschied macht.

Ich wollte über deinen Patch meckern und wollte wissen was der /\ (Delta) Wert ist.
Und da ist mir aufgefallen, daß mit der aktuellen ffmpeg Version keine Schwankung mehr war. Kann auch schon länger weg sein.
ffmpeg 2.9 wird noch ein paar Patche an SoftHdDevice brauchen, bevor es funktioniert.

Ich vermute es liegt an der Threadkommunikation. Mal kommt Start und Stop richtig an, mal nicht.

Zitat von TomJoad

Schneller Ton und schnelles Umschalten bei Radio erreicht man mit angehängtem Patch (fkt. prinzipiell auch ohne den softstart-diff)

Vielen Dank. Es fehlt noch die zweite Stelle, wenn ich es eingebaut habe, kommt es dann so ins GIT.

Johns

Anbei ein Überarbeiteter Patch.

Es wird der Ton nur gestartet wenn, nicht mehr genug Platz im Puffer ist.
Es dauert bis zu 8s bis auf Radiosendern ein Ton kommt.

Der Wert sollte groß genug sein, daß es bei Aufnahmen kein Start erfolgt.
Kann mal jemand mit Aufnahmen auf SSD und schnellen Rechner testen.

Einer eine Idee wie ich Radiosender im Plugin erkenne?

Johns

Ein paar Anmerkungen:

frame->pkt_pts

Schwankt, in VideoSetPts wird dies ausgeglichen. Steht im Syslog mit "0/\ms".
Es scheint mit ffmpeg 2.9 im Griff zu sein. Ansonsten war es iirc 240ms bei SDTV.

IIRC wird Pause und Sprünge verschieden behandelt.
Bei Pause wird nur der aktuelle Stream eingefrohren.
Ein paar Ruckler danach solten normal sein.
Da Ton und Bild nicht 100% gleich gestoppt wird.
Die Kommunikation erfolgt über 3 Threads, VDR, Bild, Tpn.

Ein Sprung, löscht die internen Puffer und entspricht einem Kanalwechsel.

Ich würde erstmal das Problem mit Sprünge und Kanalwechsel lösen.

Johns

Du kannst auch die "VA-API" Ausgabe testen, die lief bei mir mit Skylake inzwischen besser als die GLX.

Mein Branch hat nur Bob oder Nichts, alles andere geht nur im VPP-Branch.

In [Announce] VA-API/VPP Support for vdr-plugin-softhddevice waren am Ende ein paar Patche, die die Artefakte (Streifen) beseitigen. Ich vermute diese sind die Ursache für deine Hänger.

Damit sollte dann VPP gehen und keine Hänger mehr.

Johns

Sehr schön. Ursache gefunden.
Der Patch hat nur die Nebenwirkung, daß Radiosender nicht mehr gehen.

Richtige Lösung fehlt noch.

Johns

So pauschal kann man nicht sagen, daß ein grö0erer Wert für Streaming notwendig ist.
Es hängt davon ab wie das Streaming Plugin arbeitet.

Ich habe nochmal geprüft, ja es sollten Werte ab 1 gehen.

Lese mal den obigen Thread. Es kann sein, daß das satip Plugin größere Blöcke puffert.
Dadurch könnte das gleiche Problem wie bei Aufnahmen entstehen.

Johns

Moin,

Wir sprechen über:

softhddevice.AudioBufferTime = 266

?

Ich verwende dies für Cine S2.

softhddevice.AudioBufferTime = 0

Verwende ich für streamdev, 0 entspricht 336 ms. Es scheint durch das Buffern von streamdev, manchmal ein Paket später zukommen, was zu Aussetzer über streamdev führt. ich kann es aber noch auf 300ms reduzieren ohne Probleme, die 36ms sind extra Reserve.

Nun verstehe ich nicht, warum es bei dir umgekehrt ist, kannst mal den Thread/Post mit deinem Problem verlinken.

Ansonsten lies mal Soft-Start bei softhddevice.
was hier auch reinspielen kann.

Johns

Teste doch mal mit softhddevice ohne VA-API-VPP Patch, also aus meinem GIT.
Der VPP Branch hat scheinbar ein paar Fehler, die bei verschiedener Intel Hardware auftreten.
Sollte es funktionieren, kommen die Freezes von kaputten Aufrufen vom VPP Patch.

Johns

Nett, wollte schon selber basteln und habe die Docus zusammengesucht.

Der TV für den der Banana Pi vorgesehen ist, kann CES und dann brauche ich keine extra Fernbedienung.
Ist nur etwas schwierig daran zutesten.

Johns

Du hast da die freie Wahl.

Du kannst direkt SAT>IP mit Kodi und anderen Mediaplayern verwenden.
Du kannst zusätzlich auf dem VDR Server das SAT>IP Plugin installieren und dann kann der VDR als normaler VDR Server arbeiten.
Du kannst auch auf den VDR Clients das SAT>IP Plugin installieren und direkt damit gucken.

Das ist ja das schöne, sehr flexible und alles über eine Netzwerkleitung.

Johns

Wohnt ihr alle in Hutschachteln?

Wenn es kompakt sein soll, dann würde ich mir mal SAT-IP anstatt usb angucken.
Vorteil ist bis DVB-S3 kann man die Empfangshardware weiter verwenden

Edit: Also Beispiel: Digital Devices Octopus V2 NET

Als Client kannst dann fast alles verwenden.

Johns