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

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

Siehe auch:

vdr-plugin-softhddevice-drm: Video zoomen

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.

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

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

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.

Zitat von TomJoad

Ich denke, das ist bei den alten Full-Featured-Karten mal besser gelaufen

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

Zitat von 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.

Zitat von 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?

Zitat von 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.

Zitat von 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

Zitat von 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

Zitat von zillerbaer

Es wir von vdr geparsed

Nicht bei Live-TV und nicht bei Wiedergabe.

Zitat von zillerbaer

Das ist doppelte Arbeit.

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

Zitat von 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.

Zitat von 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

Zitat von jsffm

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

Ein Hinweis ;-).

Zitat von 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!

Zitat von S:oren

Und das ist genau falsch.

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

Zitat von 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.

Zitat von zillerbaer

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

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

Zitat von 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.

Zitat von zillerbaer

Ich mache keine Stimmung, Ich spreche Probleme an.

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

S:oren

Zitat von 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.