Mit streamdev-server. Ich schau mal, ob ich da am client und server irgendwelche logs einschalten kann. Und dann versuch ichs auch mal mit einer Aufnahme.
Die Aufnahme über deinen Player oder über die VDR-Wiedergabe?
Mit streamdev-server. Ich schau mal, ob ich da am client und server irgendwelche logs einschalten kann. Und dann versuch ichs auch mal mit einer Aufnahme.
Die Aufnahme über deinen Player oder über die VDR-Wiedergabe?
Die Aufnahme über deinen Player oder über die VDR-Wiedergabe?
Mit einem TS File sollte das keinen Unterschied machen.
Es scheint erstmal ein Problem auf dem Server zu sein, da steht einiges im Log. Mal sehen was das ist.
Wahrscheinlich nerve ich schon, aber hier ein log, das wohl den gleichen Fehler zeigt: https://pastebin.com/raw/JuVnCwpy
Den segfault gibt's nachdem ich mit Strg-C abbreche.
Hier ist das zugehörige Log vom Server: https://pastebin.com/raw/KJ2MBSC1
Wenn ich es richtig mitbekommen habe, beginnt das Problem auf dem Server, nämlich hier:
Mär 01 14:44:44 server01 vdr[22665]: [22669] SDT: channel 1 NID/TID (1/1101) not found, got 133/5
Mär 01 14:44:44 server01 vdr[22665]: [22668] frontend 0/0 is not receiving transponder 111837 for channel 1 (Das Erste) - retuning
Um 14:45:09 kommt dann mein Strg-C.
Das Material kommt von Streamdev-Server, auf "Das Erste (SD)" getunt. Solche Meldungen habe ich zwar mehrere im Log, allerdings scheint es logischerweise nur ein Problem zu geben, wenn gerade das frontend 0/0 betroffen ist, das den streamdev-client bedient. Möglichweise ist das der Auslöser, dass (zumindest zeitweise) kein vernünftiger Stream mehr am Client ankommt, aber den kann ich wohl auch zukünftig nicht durchgehend garantieren.
Deshalb denke ich, dass das am client abgefangen werden muss, damit der nicht gleich abschmiert. Ob man das in streamdev oder in softhddevice machen sollte, weiß ich nicht. Warum
[mpeg2video @ 0xa59828b0] v4l2_request_buffer_alloc: create buffers failed for type 2, Kein Hauptspeicher für den Puffer verfügbar (105)
den Speicher anmeckert, weiß ich nicht. Lt. /proc/meminfo sollten noch ca. 55MB vom CMA übrig sein... Aber das ist wohl ein Folgefehler.
Letztendlich wird das Log von
geflutet, bis ich abbreche.
Es wäre mir geholfen, wenn softhddevice das irgenwie abfangen kann, da ich bezweifle, dass man den Server dazu verdonnern kann, fehlerfrei zu streamen.
Ich kanns auch nochmal mit einer Aufnahme probieren, aber ich glaube der Auslöser des Problems ist der Fehler am Server.
Damit nicht genug, auch folgenden segfault hatte ich https://pastebin.com/raw/z5qNx9Ri - Der hat aber wohl nichts mit dem anderen Problem zu tun
Für mich ist es schwierig, das ganze zu reproduzieren, da es nur beim Kanalwechsel/Tunen auftaucht - und da halt irgendwann einfach.
Bin für jede Hilfe dankbar!
Andreas
Es wäre mir geholfen, wenn softhddevice das irgenwie abfangen kann, da ich bezweifle, dass man den Server dazu verdonnern kann, fehlerfrei zu streamen.
Den Server der nicht fehlerfrei streamed würde ich fristlos feuern! Da sollte angesetzt werden.
den Speicher anmeckert, weiß ich nicht. Lt. /proc/meminfo sollten noch ca. 55MB vom CMA übrig sein
Wenn ein Buffer mit 0 Byte angefordert wird ist der Fehler der gleiche.
Damit nicht genug, auch folgenden segfault hatte ich
Das ist KEIN segfault! Da wird Abgebrochen! Ein FB mit size 0 kann nicht angelegt werden.
Ich stimme Dir zu das der Decoder ein solches AVFrame nicht weitergeben sollte. Das passiert in der FFmpeg. Da müsste dafür ein Patch erstellt werden.
Aber vorher geht das Packet durch den Server, durch streamdev Server / Client , wieder vdr und softhddevice-drm, als letztes in der Kette bricht dann ab weil es nix damit anfangen kann. Mann könnte im Decoder ReveiveFrame abprüfen hat das Frame Höhe Breite FD hat. Das würde dann zu einem Programm Abbruch führen.
Das ist KEIN segfault! Da wird Abgebrochen! Ein FB mit size 0 kann nicht angelegt werden.
Stimmt. Mein Fehler.
Wer gefälschte TS Packete in Umlauf bringt wird mit Systemabsturz bestrafft!
Ich hab gefunden, wo in softhddevice ich es lösen/abfangen könnte. Ich probier das jetzt einfach mal...
Den Server kann ich momentan nicht beeinflussen. Da ist aktuellster VDR mit sundtek sticks und aktuellen Treibern drauf. Die haben bisher nie Probleme gemacht. Ich bleibe bei meiner Meinung, dass der Client nicht gleich in die Knie gehen darf, wenn der Server Fälscher spielt... Wo auch immer man das abfängt.
So, gefällt dir wahrscheinlich nicht, dass ich mehrere Baustellen gleichzeitig aufmache, aber folgendes passiert, wenn ich auf den Kanal "Inforadio" schalte:
CodecAudioOpen: CodecDownmix to AV_CH_LAYOUT_STEREO CodecDownmix 1
CodecAudioOpen: Codec MP2 (MPEG audio layer 2) found
AudioFilterInit: ch_layout stereo sample_fmt s16p sample_rate 48000 channels 2
AudioEnqueue: start? in Rb 264ms to skip 0ms
AudioFilter: Free the filter graph.
AlsaSetup: no channel map found for 1 channels, HwChannels 2 > set CodecDownmix
AudioFilter: AudioFilterInit failed!
PlayAudio: NewAudioStream
CodecAudioClose
CodecAudioClose
CodecAudioOpen: CodecDownmix to AV_CH_LAYOUT_STEREO CodecDownmix 1
CodecAudioOpen: Codec MP2 (MPEG audio layer 2) found
AudioFilterInit: ch_layout stereo sample_fmt s16p sample_rate 48000 channels 2
AudioEnqueue: start? in Rb 288ms to skip 0ms
AudioFilter: Free the filter graph.
AlsaSetup: no channel map found for 1 channels, HwChannels 2 > set CodecDownmix
AudioFilter: AudioFilterInit failed!
PlayAudio: NewAudioStream
CodecAudioClose
./vdr.sh: Zeile 28: 20500 Abgebrochen vdr -u root --vfat -c /etc/vdr -E /video0 -v /video0 --localedir=/usr/local/share/locale -Pstreamdev-client -P'softhddevice-drm -a hw:0,0' -P"skindesigner" --lirc
Alles anzeigen
Die Meldung oben wiederholt sich oft, dann verabschiedet sich VDR.
Gruß
Andreas
no channel map found for 1 channels, HwChannels 2
Das Problem ist das deine SoundKarte keine Mono Ausgabe kann. Schon erstaunlich das es noch Sender gibt die ein Mono Signal senden. Umso erstaunlicher ist es das es Soundkarten gibt die Mono nicht beherschen! Ich schau mir das an.
Danke. Die "Soundkarte" ist das hdmi meines H3...
Danke. Die "Soundkarte" ist das hdmi meines H3...
Hast Du die Patches von LE für HDMI integriert? Ich nutze das nicht weil ich einen USB Verstärker dafür habe.
Ja, das ist mein Kernel: https://github.com/rellla/linu…i/commits/vdr-5.10.4-test
Müssten alle notwendigen von damals drin sein. Habe in der letzten Zeit nicht mehr geschaut, ob sich was geändert hat.
Ich lasse gerade per Skript alle Kanäle anschalten, "K-TV" taucht mit einer Samplerate von 24000 auf, was ebenfalls zum Crash führt:
CodecAudioOpen: Codec MP2 (MPEG audio layer 2) found
AudioFilterInit: ch_layout stereo sample_fmt s16p sample_rate 48000 channels 2
AudioEnqueue: start? in Rb 600ms to skip 0ms
AudioEnqueue: start? in Rb 624ms to skip 0ms
AudioEnqueue: start? in Rb 648ms to skip 0ms
AudioEnqueue: start? in Rb 672ms to skip 0ms
AudioFilter: Free the filter graph.
AlsaSetup: SampleRate 24000 not supported
AudioFilter: AudioFilterInit failed!
PlayAudio: NewAudioStream
CodecAudioClose
./vdr.sh: Zeile 22: 23833 Abgebrochen vdr -u root --vfat -c /etc/vdr -E /video0 -v /video0 --localedir=/usr/local/share/locale -Pstreamdev-client -P'softhddevice-drm -a hw:0,0' --lirc
Alles anzeigen
... nicht dass ich K-TV unbedingt bräuchte
was ebenfalls zum Crash führt:
Es gibt keinen Crash! Vdr wird abgebrochen weil eine Samplerate verlangt wird die Deine Soundkarte nicht kann!
Im Ergebnis ist für mich Crash == Abbruch.
Crash ist ein unkontrolliertes beenden. Abbruch ist ein kontrolliertes Beenden einer Anwendung mit Freigabe aller Resourcen. Das ist ein grosser Unterschied!
Ich gebe dir schon recht. Das Problem ist aber doch nicht, ob ich jetzt ein Wort falsch benutzt habe, sondern dass der VDR danach nicht mehr läuft
Ich hab gefunden, wo in softhddevice ich es lösen/abfangen könnte. Ich probier das jetzt einfach mal...
Den Server kann ich momentan nicht beeinflussen. Da ist aktuellster VDR mit sundtek sticks und aktuellen Treibern drauf. Die haben bisher nie Probleme gemacht. Ich bleibe bei meiner Meinung, dass der Client nicht gleich in die Knie gehen darf, wenn der Server Fälscher spielt... Wo auch immer man das abfängt.
Ich weiß nicht, was streamdev genau macht, aber m.M. nach sollte es die Pakete vom Server-Stream unverändert an den Client durchreichen. Am Ende sitzt halt das Ausgabeplugin. Aber das muss mit den negativen Rückgabewerten von ffmpeg dann auch richtig umgehen, wenn es ffmpeg nutzt. Ein Fehler ist ja auch ein erlaubter Rückgabewert.
Mit diesen Änderungen hatte ich bisher keine "Ausfälle" mehr, was Stream/Video/Codec-Fehler betrifft. Vielleicht ist ja was dabei, was nützlich ist.
Gruß
Andreas
Nein, löst es nicht.
Soweit ich es durchblicke, liegt das eigentliche Problem darin, dass nur 0 oder EAGAIN als Rückgabe von avcodec_send_packet() behandelt werden. Wenn ffmpeg einen anderen Fehler liefert, gibt CodecVideoSendPacket() 0 zurück und läuft in https://github.com/zillevdr/vd…lob/drm/softhddev.c#L1108, was er wohl nicht sollte!?
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!