Nachrattern am Wiedergabe-Ende

    Zitat von TomJoad

    Suche mal in recording.c nach "struct tIndexTs"


    Zitat von TomJoad

    Suche mal in recording.c nach "struct tIndexTs"


    Jo. Ich hatte schon mal gesucht, aber natürlich nicht mit dem neuen Strukturnamen.
    Das Problem liegt an der veralteten Doku im VDR-Wiki, die nur für 1.6 gilt und dem Fehlen einer vergleichbaren "Benutzerorientierten" für 1.7.


    Ausführlich:
    Sinn und Unsinn von "emergency exit"


    Hilft allerdings bei Nachrattern nicht wirklich weiter. Ich könnte mal das genindex-Modul umbauen um den TS zu dumpen.


    Bin ich da wirklch der einzige bei dem der Effekt auftritthat, oder der einzige den das stört?

    Möglicherweise hängt es vom eingesetzten Audiodevice ab?


    Afaik stellt VDR nicht sicher, daß das letzte Audioframe vollständig ist, oder?


    CU
    Oliver

    Zitat von UFO

    Möglicherweise hängt es vom eingesetzten Audiodevice ab?


    Afaik stellt VDR nicht sicher, daß das letzte Audioframe vollständig ist, oder?


    CU
    Oliver


    Audio geht über den HDMI der GT610 Grafik. Also nix besonders, oder?


    Ich habe den Eindruck, das 2 Frames im wechsel abgespielt werden.


    Warum kappt VDR nicht automatisch beim letzten Vollbild oder
    überschreibt mit schwarz/ruhe?
    Der weiss doch, wann das war. Steht ja in der index-Datei.
    Worin liegt der Vorteil das aufzuzeichnen?

    Zitat von zochi

    Audio geht über den HDMI der GT610 Grafik. Also nix besonders, oder?


    Das Audiodecoder ist in diesem Fall am anderen Ende des HDMI-Kabels. ;)


    Zitat


    Ich habe den Eindruck, das 2 Frames im wechsel abgespielt werden.


    Warum kappt VDR nicht automatisch beim letzten Vollbild oder
    überschreibt mit schwarz/ruhe?
    Der weiss doch, wann das war. Steht ja in der index-Datei.
    Worin liegt der Vorteil das aufzuzeichnen?


    VDR schneidet an Videoframegrenzen, nicht an Audioframegrenzen - afaik.


    CU
    Oliver

    Es sind jetzt 5...


    1. Die Aufzeichnung ist zu ende, ich sehe ein Standbild ehe wieder "live"
    2. Am Ende flimmert das Bild. Ich sehe dann 2 ineinander verzahnte(interlaced?) Bilder, die mit wohl 25Hz flimmern.
    3. wie 2, aber der Ton wieder auch in einer Schleife wiedergegeben, was dann "knattert" (als es ist kein "schaltknacken")
    4. wie 2 oder 3, aber terminiert nicht nach 3..15sec. sondern erst wenn ich eingreife.


    Neu:
    5. Die Wiedergabe bleibt ca. eine Sekunde vorm Ende stehen, so als ob wer "Pause" gedrückt hätte.
    So steht der Recorder vorsich hin ohne sich abzuschalten und zieht Strom.
    OSD geht, bei "OK" wird "0:00" Rest angezeigt, ich kann zurückspulen, z.B. mit Grün. Die Wiedergabe startet dann
    und hängt. Es kommt kein Menu wie bei den anderen Fällen.
    Drücke ich "Cursor runter" gehts einen Tick weiter und endet dann normal, ohne jede Störung mit dem richtigen Ton..
    Es handelt sich dabei um eine alte Aufnahme von 3.2011, wohl mit 1.7.28 oder 29 (etobi)
    Diese Aufnahme hat Schnittmarken.


    Unter Setup-Replay ist "Pause at last mark" aktiv. Also ein "Feature", aber:
    Eigentlich möchte ich, das der Recorder sich nach x-Minuten Benutzerinaktivität abschaltet.
    Noch eigentlicher hätte gerne nicht das zurückschalten auf "live" (am besten Schwarz)
    und natürlich das sich das Teil irgendwann ganz abschaltet. Letzeres implemtiere ich derzeit darauch, das ich
    einen der 3 nicht mehr funktionierenden IPTV vor der Wiedergabe wähle.
    Dann habe ich aber u.U. über 10 sec die Tonstörung. Vermutlich wartet VDR da auf einen Frame, der nicht kommt.


    Schalte ich das "Pause at last mark" aus habe ich wieder die Tonstörung in der letzten Sekunde.
    Geschätzt während der Frames die nach dem letzten kommen.
    Diese Tonstörung habe ich nicht, wenn ich "Pause at last mark" aktiviert habe und aus diesem Zustand
    die Wiedergabe laufen lasse. Dann wird ein sauberer Ton abgespielt.




    [/code]drwxr-xr-x 3 vdr vdr 39 Mar 9 2011 ../
    -rw-r--r-- 1 vdr vdr 569584645 Mar 9 2011 001.vdr
    -rw-r--r-- 1 vdr vdr 203656 Mar 9 2011 index.vdr
    -rw-r--r-- 1 vdr vdr 536 Mar 9 2011 info.vdr
    -rw-rw-rw- 1 vdr vdr 58 Mar 9 2011 marks.vdr
    -rw-r--r-- 1 vdr vdr 4 Jan 14 05:40 resume.vdr
    [/quote]


    Code
    3F_-_Moderation#3A/2011-03-09.22.45.50.99.rec# hd marks.vdr
00000000  30 3a 30 32 3a 31 33 2e  31 32 20 4c 6f 67 6f 20  |0:02:13.12 Logo |
00000010  73 74 61 72 74 0a 30 3a  31 36 3a 35 38 2e 30 31  |start.0:16:58.01|
00000020  20 6e 6f 61 64 20 6d 61  72 6b 20 6f 6e 20 6c 61  | noad mark on la|
00000030  73 74 20 49 46 72 61 6d  65 0a                    |st IFrame.|
0000003a


    Zitat von S:oren


    Ab 1.7.32 sollte der vdr beim Schnitt auch Audiopakete vervollstaendigen (siehe dieser Thread). Ob da am Ende der Wiedergabe irgendwas in irgendwelchen Buffern haengen bleibt, weiss ich aber nicht...


    Ok, dann hat sich dieses Problem ja erledigt. Hatte noch keine Zeit, mir die ganzen Änderungen genauer anzusehen.


    Bleibt die Frage, was ein Decoder veranstaltet, wenn er am Ende der Aufzeichnung "verhungert".


    CU
    Oliver

    Zitat von anbr

    Nein, ähnliches habe ich auch unter vdr-1.7.31 und der Ausgabe auf eine SD-FF Karte beobachtet...


    Das deutet dann darauf hin, das Unsinn aufgzeichnet worden ist. Denn ich habe ja VDPAU mit Gt610 zur Ausgabe.


    Ich schaumal was passiert wenn ich schneide.

    Hallo


    ich musste ebend mit femon zwischen Geräten umschalten, die u.U. keinen TS lieferten.
    Dabei sah ich einmal auch dieses "Nachrütteln" solange keine neuen Daten kamen.
    Also kein reines Aufnahme Problem.


    a) Ist das das Video Device
    b) Müsste VDR am Ende der Aufnahmen ein Schnipsel "schwarz" einkopieren, damit die Buffer leer gespült werden.
    c) oder dafür sorgen das das das Auszeichungsende auch das Frameende ist und nicht "mitten drin".

    Das "Nachrattern" am Wiedergabe-Ende kommt mit ziemlicher Sicherheit daher, daß in cDvbPlayer::Action() am Ende der Datei der letzte Frame so oft wiederholt an das Ausgabedevice geschickt wird, bis DeviceGetSTC() anzeigt, daß der letzte Frame auch wirklich dargestellt wurde. Das Problem vor dieser Änderung war, daß unter Umständen die letzten paar Sekunden (je nach Größe des Puffers im Ausgabedevice) nicht mehr abgespielt wurden, da das Device seinen Puffer wohl nicht "leerspielt". Da es nichts gebracht hat, einfach Pakete mit lauter 0x00 oder 0xFF zu schicken, bot sich als einzige Lösung eine Wiederholung des letzten Frames an, um den Device-Buffer "durchzuspülen".


    Für die Video-Wiedergabe könnte folgender Patch helfen:


    Damit werden vom letzten Frame nur noch die Video-Daten geschickt, was wohl auch reichen sollte, um das Device "durchzupusten".
    Für reine Audio-Wiedergabe (Radio-Programme) hilft das allerdings nichts.


    Es war mal angedacht, die Funktion cDevice::Flush() zu benutzen, aber die wird anscheinend inzwischen nirgendwo mehr verwendet. Und dvb[hs]ddevice haben nur eine leere Implementierung. Am schönsten wäre es wohl, wenn cDevice::Flush() in den Ausgabedevices mit Leben befüllt werden könnte, und diese Funktion in cDvbPlayer::Action() aufgerüfen würde, um dem Ausgabedevice zu sagen "spiel deinen Puffer bis zum Ende ab".


    Hat jemand eine Idee, wie man das für dvb[hs]ddevice implementieren könnte?


    Klaus

    Danke für die Erklärung.
    Das "Nachrattern" ist aber -manchmal- nicht nur ein Video-Problem, sondern vorallem ein Audio.
    Wenn die Aufnahme an einer lauten Stelle endet rattert es im Ton.


    Irgendwie erklärt sich damit mir nicht, warum das Schüttelbild länger stehen bleibt, wenn man
    (mit Absicht) einen Kanal ohne Daten, z.B. den 3sat IPTV, als letztes "Live" eingestellt hatte.

    Zitat von zochi

    Danke für die Erklärung.
    Das "Nachrattern" ist aber -manchmal- nicht nur ein Video-Problem, sondern vorallem ein Audio.
    Wenn die Aufnahme an einer lauten Stelle endet rattert es im Ton.


    So hatte ich das auch verstanden und kann es auch nachvollziehen. "Rattern" hatte ich auf den Ton bezogen.


    Zitat


    Irgendwie erklärt sich damit mir nicht, warum das Schüttelbild länger stehen bleibt, wenn man
    (mit Absicht) einen Kanal ohne Daten, z.B. den 3sat IPTV, als letztes "Live" eingestellt hatte.


    Dazu kann ich nichts sagen, sowas beobachte ich hier nicht. Kann aber daran liegen, daß ich eine TT-S2 6400 als Ausgabedevice benutze.


    Hast du den Patch schon probiert?
    Ändert sich dadurch was?


    Klaus

    Zitat von kls


    So hatte ich das auch verstanden und kann es auch nachvollziehen. "Rattern" hatte ich auf den Ton bezogen.


    Ich las nur immer "video".

    Zitat


    Dazu kann ich nichts sagen, sowas beobachte ich hier nicht. Kann aber daran liegen, daß ich eine TT-S2 6400 als Ausgabedevice benutze.


    Das sieht für mich so aus, als würde iregndwas 10sec auf Daten warten. Wenn "live" einen Stream liefert sind das nur wenige sekunden (2..3)

    Zitat


    Hast du den Patch schon probiert?


    Ich habe eben versucht zu übersetzen...


    also


    cd /usr/src/vdr/vdr-1.7.33
    make clean
    make
    und
    dann
    #make install-bin
    (Sonst würde ja wohl alle .conf überschrieben??


    Ich glaube irgendwas stimmt da mit dem src path nicht,
    denn mein vdr-file ist nur halb so gross wie das das ich aus yaVDR0.5 habe...
    Die symbole werden es wohl nicht sein...



    Code
    root@vdr4:/usr/src/vdr/vdr-1.7.33# ll /usr/bin/vdr /usr/bin/svdrpsend
-rwxr-xr-x 1 root root    1170 Aug  6  2011 /usr/bin/svdrpsend*
-rwxr-xr-x 1 root root 1470888 Dec 20 00:27 /usr/bin/vdr*


root@vdr4:/usr/src/vdr/vdr-1.7.33# ll ./vdr ./svdrpsend
-rwxr-xr-x 1  500 users    1170 Aug  6  2011 ./svdrpsend*
-rwxr-xr-x 1 root root  6605259 Jan 27 22:34 ./vdr*


Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden