Abspielen der letzten 25 Sekunden der Aufnahme: VDR reagiert nicht auf Eingaben, Bild verlangsamt

  • Hallo,


    Wenn ich eine Aufnahme, die mit vdr-transcode bearbeitet wurde, mit dem VDR abspiele, treten in den letzten 25 Sekunden folgende Probleme auf:

    1. VDR reagiert nicht auf Eingaben
    2. Das Video ist sehr stark verlangsamt, Ton ist unterbrochen und nur in kurzen Abschnitten zu hören
    3. Im syslog: audio/alsa: avail underrun error? 'Datenübergabe unterbrochen (broken pipe)'


    Wirklich störend empfinde ich: 1. VDR reagiert nicht auf Eingaben

    Für die anderen Punkte gibt es einen einfachen Workaround: Einfach 30 Sekunden mehr aufnehmen ...


    Der Fehler tritt bei Konvertierung nach mpeg2 und nach h264 auf. Die anderen habe ich nicht getestet.

    Mir ist ein kleiner Unterschied in der Länge von index aufgefallen. In meinem Beispiel:

    Original index.vdr: 59000 Bytes

    Konvertiert index: 58976 Bytes (bei mpeg2 und bei h264)


    vdr --genindex gibt folgendes aus (ich habe eine Debug Option im VDR aktiviert):

    I/P/P/P/P/P/P/P/P/P/P/P/I

    Delta = 3600 FPS = 25,00 FPPU = 1 NF = 12 TRO = 0

    bzw.

    ASI/AP/AB/AB/AB/AP/AP/AB/AB/AB/AP/AB/AP/AB/AP/AB/AP/AB/AP/AB/AB/AB/AP/AB/AP/AB/AP/AB/AP/AB/AP/AB/AP/AB/AB/AB/AP/AB/AP/AB/AP/AB/AB/AB/AP/AB/AB/AB/AP/AB/ASI

    Delta = 3600 FPS = 25,00 FPPU = 1 NF = 50 TRO = 0


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Das Problem tritt auch bei nicht transkodierten Aufnahmen nach dem Schnitt auf.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github


  • vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Das habe ich auch schon manchmal beobachtet (auch bei ungeschnittenen Aufnahmen) . Da ich aber meist nicht bis ganz zum Ende kucke (Abspann etc.) stört mich das nicht besonders.


    In cDvbPlayer::Action() wird unter "// Handle hitting begin/end of recording:" einiges unternommen, um die letzten Datenpakete an das Ausgabedevice zu schicken. Vielleicht liegt da ja was im Argen.

  • Dass der VDR am Ende der Wiedergabe nicht auf Eingaben reagiert habe ich auch schon öfters beobachtet, allerdings immer nur bei Aufnahmen, die direkt vorher geschnitten wurden, als würde er warten, "dass da noch was kommt" wie beim Anhalten des Live-TV. Gefühlt tritt das erst seit VDR 2.4.x auf.

    Bei "älteren" Aufnahmen (geschnitten vor etlichen Minuten? oder Stunden ?) wartet er am Ende ca. 10 Sec bis er wieder auf Live-TV schaltet, ist in dieser Zeit aber bedienbar.

  • Bei mir hat es definitiv nix mit dem Abstand zum Schneiden zu tun, das hab' ich auch mit Aufnahmen, die ich vor Jahren geschnitten hab (mit vdr selbst, es liegt also nicht an adr-transcode).

    Ich kann mich jetzt nicht erinnern ob der VDR sich mit lange genug warten wieder erholt (entweder ich bin schnell genug mit dem 'back/exit' drücken, oder ich starte VDR neu...). Wenn, ist's im Bereich von mind. 'ner halben Stunde (so lange habe ich schon mal gewartet, IIRC).

    Ja, kann gut sein dass das mit 2.4 begonnen hat. Ich hatte damals aber gleichzeitig auf ein anderes Mainboard gewechselt, und vermutet es hat damit zu tun...


    Nachtrag: Ich bin mir ziemlich sicher dass das Problem hier ausschliesslich bei SD-Aufnahmen auftritt.

    VDR2: ASRock J4105-ITX, DVBSky S952, openSUSE Tumbleweed, VDR 2.4.7

    softhddevice/vaapidevice, DFAtmo, xmltv2vdr, tvscraper, tvguideng, VDRAdmin-AM (alles git, aber alt)

    The post was edited 1 time, last by Der_Pit ().

  • Bei mir ist das def. nicht auf SD beschränkt.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Abhilfe könnte das hier sein: Beim mir mit EasyVDR Version 5.0pre Alpha

    Ob das auch so bei yaVDR funktioniert , müsste mal einer ausprobieren..

    Bei einer geschnittenen Aufnahme am Ende der Aufnahme eine Schnittmarke setzen und in den OSD Einstellungen unter

    System & Einstellungen / Einstellungen / Wiedergabe

    Pause an der letzten Schnittmarke auf ja stellen.

    Damit bleibt die Wiedergabe der Aufnahme am Ende stehen und der VDR bleibt Bedienbar..


    Siehe Einstellungen im Bild des Anhangs

    Gruß Helmut

    Images

    Test_VDR: Lintec Senior Gehäuse - MSI G41M P25 MS7592 Board - Intel P4 E8500 / 775 CPU - MSI GT710 PCI-e HDMI LP passiv - DVBSky S2 952 Dual SAT - 120GB W.D. Green SSD + Big HDD - 2x2GB DDR3 RAM - LG GH24NSD1 S-ATA DVD - SMK RC6 MCE 50GB FB. an STM32 USB-Stick - EasyVDR 5 pre Alpha - Softhddevice Frontend mit Pulseaudio - Kodi 19.4 m. Confluence Skin
    Clients: Hauppauge Media MVP Scart - VIP 1903Box - VIP 1910Box - EasyStream 0.6-18 fuer Windows - Raspberry PI B+ mit OpenElec 5.08 Kodi Helix 14.2 und Tsop31238 Lirc mit Conrad Promo8 FB on Code VCR 0104 - Raspi3 m.OpenElec 6.03 und Kodi 15.2 Isengard

    The post was edited 2 times, last by Emma53 ().

  • Ich denke, das ist bei den alten Full-Featured-Karten mal besser gelaufen. Bei den aktuellen Ausgabeplugins hängt es davon ab, wie DeviceGetSTC() implementiert ist und ob es da noch eine weitere Ausgabeverzögerung gibt.

    vdr-2.6.1

    softhddevice,, dbus2vdr, dvd, epgsearch, femon, graphtftng, hbbtv, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.10 ,AsRock J4105, CIne CT-V7 DVB-C

  • Ich denke, das ist bei den alten Full-Featured-Karten mal besser gelaufen. Bei den aktuellen Ausgabeplugins hängt es davon ab, wie DeviceGetSTC() implementiert ist und ob es da noch eine weitere Ausgabeverzögerung gibt.

    Ja, früher war alles besser!:] Herrlich, auf der alten Röhre mit VGA2SCART.


    VDR krankt mir zu sehr an der alten FF! Leider ist unsere alte Community nicht in der Lage VDR zu modernisieren. Ist halt so bei alten Weissen.

  • Das habe ich auch schon manchmal beobachtet (auch bei ungeschnittenen Aufnahmen) . Da ich aber meist nicht bis ganz zum Ende kucke (Abspann etc.) stört mich das nicht besonders.


    In cDvbPlayer::Action() wird unter "// Handle hitting begin/end of recording:" einiges unternommen, um die letzten Datenpakete an das Ausgabedevice zu schicken. Vielleicht liegt da ja was im Argen.

    Ist das jetzt nur ein Hinweis, oder schaust Du Dir das nochmal an?


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • VDR krankt mir zu sehr an der alten FF! Leider ist unsere alte Community nicht in der Lage VDR zu modernisieren.

    Habe in dem ganzen Thread nicht gelesen, dass irgendwer hier sich ueber dieses Problem mit der alten FF beschwert haette. Eigentlich steht fast nie dabei, welches Ausgabeplugin verwendet wird, vermutlich ueberwiegend Soft-Devices. Und dort hat das Ausgabeplugin doch alle Freiheiten, den Bitstrom komplett vom vdr entgegen zu nehmen, ggf. zu parsen und die Wiedergabe korrekt zu beenden. Ein guter Platz fuer moderne Ideen.


    Bei mir tritt es mit der TT S2-6400 Full-Featured-Karte bei HD-Aufnahmen auf, SD habe ich nicht getestet.

    Das ist in der Tat ein Problem, (auch?) auf der S2-6400. Dort ist es jedenfalls nicht trivial, fuer Bitraten von z.T. unterhalb 1 MBit/s bis ueber 15 MBit/s sinnvolle Buffergrößen und Transferchunks einzustellen. Zumal der Audio/Video-Versatz im Transportstream total verschieden ist und im Treiber nicht sinnvoll behandelt werden kann (OK, hat noch niemand versucht, Freiwillige vor).


    Das größte Problem ist vermutlich, dass entweder am Ende Audio-Daten fehlen (Schnitt) oder zu spaet im Transportstream stehen (Remux), so dass sie am Ende in einem halbvollen Buffer liegen und nicht weitergeleitet werden. Der Dekoder wartet auf Audio-Daten fuer die A/V-Synchronisation, der VDR wartet auf die Ausgabe der letzten Bilder. Oder der Video-Dekoder wartet wegen Vorwärtsreferenzen auf Bilder, die nicht mehr kommen und kommt dadurch mit der Audiosynchronisation durcheinander, schwer zu debuggen auf einer FF-Karte.


    Ja, das war 'frueher' einfacher, als es nur MPEG2 mit einfacher GOP-Struktur und niedrigeren Bitraten fuer DVB gab. Mit den FF-Karten an sich (oder mit Anpassungen des Core-VDR dafuer) hat das meiner Ansicht nach nichts zu tun (Ich waere natuerlich trotzdem froh, wenn jemand einen einfachen Fix findet.).


    Gruss,

    S:oren

  • Und dort hat das Ausgabeplugin doch alle Freiheiten, den Bitstrom komplett vom vdr entgegen zu nehmen, ggf. zu parsen und die Wiedergabe korrekt zu beenden

    Es wir von vdr geparsed und vom Ausgabeplugin noch einmal. Das ist doppelte Arbeit. Einmal Parsen und das Ergebnis weiterleiten ist die bessere Variante.


    Der Bitstream wird von vdr in Blöcke geschnitten die unlogisch sind. Ich vermute Beschränkungen die von den FF Karten kommen. Es wird bei Video teilweise mitten im Bild geschnitten. Das muss dann im Plugin wieder zusammen gefummelt werden. Das sieht im Audiostream nicht anders aus. Bei so viel Gefummel sind Fehler nicht zu vermeiden.


    Gruss

    zille

  • Es wir von vdr geparsed

    Nicht bei Live-TV und nicht bei Wiedergabe.

    Das ist doppelte Arbeit.

    Somit nicht. Und hat exakt nichts mit dem hier im Thread beschriebenen Problem zu tun.

    Der Bitstream wird von vdr in Blöcke geschnitten die unlogisch sind.

    Der DVB-Bitstrom ist zunaechst mal ein "unendlicher" Strom von Bits (TS-Paketen). Und wird so vom vdr behandelt.

    Ich vermute Beschränkungen die von den FF Karten kommen

    Und das ist genau falsch. Bei den FF-Karten parst die Hardware alles selbst, was fuer die Dekodierung noetig ist. Der VDR hat einfach nichts damit zu tun. Der VDR parst nur beim Aufnehmen, um spaeter in der Aufnahme verzoegerungsfrei springen zu koennen. Nicht mehr, nicht weniger. Das Prinzip einer FF-Karte ist gerade, den Bitstrom vom Demod zu nehmen und direkt in den Dekoder zu schicken (ggf. mit Umweg ueber die Festplatte, aber das ist dem Dekoder egal).


    Wenn Dir der VDR-Parser so gut gefaellt, dann binde ihn doch in Dein Ausgabeplugin ein. Ergibt mehr Sinn, als den Core-VDR z.B. bei Live-TV irgendwas parsen zu lassen, was spaeter vom Ausgabeplugin gar nicht benoetigt wird. Das VDR-Design ist hier doch klar: eine minimale Schnittstelle zwischen Core und Ausgabeplugins. Wenn fuer die Ausgabe irgendwas geparst werden muss, dann im Plugin. Der Core macht da nichts, weil es sowieso nicht fuer alle Ausgabeplugins identisch sein kann.


    Ja, ein Ausgabe- und Dekoder-Plugin ist nicht trivial. Besonders aergerlich, wenn die eigentliche Dekoder-Hardwaere auch (fast) so viel selbst koennte wie die FF-Karten, aber die ach-so-tollen stateless v4l2-m4m-Treiber die Funktionalitaet nicht weitergeben. Aber das doch kein Grund, hier Stimmung gegen den Core-VDR und FF-Karten zu machen, auf Basis von aus der Luft gegriffenen Vermutungen. Zumal das nichts mit dem Problem aus dem Thread zu tun hat.


    Gruss,

    S:oren

  • Der VDR parst nur beim Aufnehmen,

    VDR schickt aus dem Bitstream Packete an PlayVideo/PlayAudio. Ohne den Bitstream zu Parsen geht das gar nicht!

    Und das ist genau falsch.

    Mag sein, warum vdr die Packete so falsch weitergibt weiss ich nicht.

    Aber das doch kein Grund, hier Stimmung gegen den Core-VDR und FF-Karten zu machen,

    Ich mache keine Stimmung, Ich spreche Probleme an.

  • VDR schickt aus dem Bitstream Packete an PlayVideo/PlayAudio. Ohne den Bitstream zu Parsen geht das gar nicht!

    Du moechtest ueber steinalte PES-Aufnahmen diskutieren? Wirklich?
    Relevant ist heute doch eher PlayTsVideo/PlayTsAudio. Und da geht es eben um TS-Pakete als die relevante Granularitaet des Bitstroms.

    Ich mache keine Stimmung, Ich spreche Probleme an.

    Selbstgemachte Probleme? Andere Leute suchen Loesungen. Kein weiterer Kommentar.

    S:oren

  • Was genau macht VDR denn falsch, und wie wäre es richtig?

    Die von PlayVideo geschickten Packete beinhalten manchmal nur Teile eines Bildes. Der restlichen Daten werden mit neuem Header nachgeliefert. Ich hab festgestellt das ein neues reales Packet mit PTS Daten kommt. softhddevice-drm wartet immer auf das nächste Packet, schaut ob PTS vorhanden ist und bearbeitet dann erst das vorhergehende Packet. Momentan sitze ich an einem Problem mit PlayAudio. Da scheint es auch so zu sein. Hab es aber noch nicht komplett durch gespielt. Könnte das Problem hier im Thread an den fehlenden PTS Daten liegen? Wie wird das synchronisiert?


    Für den Anfang fände ich es schick, wenn geschickte Packete, wie im Header File beschrieben, wirklich ein komplettes Packet beinhalten würden.