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

    Siehe auch:


    vdr-plugin-softhddevice-drm: Video zoomen


    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)

    Edited once, 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 - MSI G41M P25 MS7592 Board - Intel P4 E8500 / 775 CPU - MSI GT710 PCI-e passiv - DVBSky S2 952 Dual SAT - 120GB Intenso SSD + Big HDD - 2x2GB DDR3 RAM - LG GH24NSD1 S-ATA DVD - SMK RC6 MCE 50GB FB. an STM32 USB-Arduino - EasyVDR 5 - Softhddevice mit Pulseaudio - Kodi 20.5 m. Confluence Skin
    Clients:Div. Raspberry PI

    Fernbedienungsempfänger: Siehe hier:RP 2040 Zero I.R. Empfänger kompl.

    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.7.3

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver
    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

    Quote from TomJoad

    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.

    Quote from kls

    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

    Quote from zillerbaer

    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.


    Quote from FireFly

    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

    Quote from 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

    Quote from zillerbaer

    Es wir von vdr geparsed

    Nicht bei Live-TV und nicht bei Wiedergabe.

    Quote from zillerbaer

    Das ist doppelte Arbeit.

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

    Quote from zillerbaer

    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.

    Quote from zillerbaer

    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

    Quote from 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!

    Quote from S:oren

    Und das ist genau falsch.

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

    Quote from S:oren

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

    Ich mache keine Stimmung, Ich spreche Probleme an.

    Quote from zillerbaer

    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.

    Quote from zillerbaer

    Ich mache keine Stimmung, Ich spreche Probleme an.

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

    S:oren

    Quote from kls

    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.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login