TrickSpeed - Verständnisfrage

  • Also bei softhddevice (mit vdpau) habe ich dieses Problem noch nie gehabt! Nun funktioniert softhdodroid auch ganz anders. Es erzeugt die video frames nicht selbst, das läuft alles direkt über den amlogic-Kernel. Das macht die A/V-Synchronisation mit alsa etwas schwieriger.

    Auch der ugly fix verändert bei softhdodroid nichts. Die Variante mit dem Clear hatte ich auch schon mal probiert, aber wie Du schon schreibst - es fehlen dann ein paar Sekunden.

    Das ganze Problem würde übrigens nicht entstehen, wenn man in Mute() den Aufruf von

    Code
    SkipAudio = 1;
    AudioFlushBuffers();

    auskommentiert. Die Wiedergabe läuft dann beim Wechsel von speed 2, 4 oder 8 zu Play sauber weiter. Aber die Zeitlupe würde dann nach ein paar Sekunden stehenbleiben, weil in PlayVideo keine Daten mehr vom vdr ankommen. Genau kriege ich das nicht mehr zusammen. Kam es zu einem Überlauf des Audio ringbuffers? Oder lag es daran, dass PlayAudio 0 returniert hat? Bei Beginn der Pausenfunktion wird in Freeze() StreamFreezed = 1 gesetzt und AudioPause aufgerufen. Beim Wechsel zur Zeitlupe aus der Pause heraus (Aufruf Trickspeed durch Drücken der Pfeiltaste rechts) ändert sich an StreamFreezed glaube ich noch nichts - erst der erneute Aufruf von Play() beim Beenden der Zeitlupe führt dazu, dass wieder Audiodaten in den ringbuffer geliefert werden. War denn nun vorher geleert oder sind noch Reste vorhanden, zu denen dann neue Daten mit nicht mehr kontinuierlicher PTS hinzukommen? Ich kriege es nicht mehr zusammen. Es kommt auf alle Fälle zu einer A/V-Abweichung von rund 4 Sekunden bei einer ringbuffer-Größe von 2s.

    Ich habe Tage damit verbracht, alles mögliche auszuprobieren, bin aber an der Stelle nicht wirklich weitergekommen. Wenn man Audio und Video buffer beide clearen würde und die Wiedergabe an der letzten beim Verlassen der Aufzeichnung aktuellen Stelle komplett neu beginnt, müsste es eigentlich gehen. Aber das überschreitet auch meine bescheidenen Fähigkeiten.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • vdr-plugin-xine spielt nach Pause-SlowForward-Play ein paar Sekunden Video ohne Ton, dann gibt es eine sehr kurze Bildstörung, und dann spielt Video mit Ton normal.

    vdr-plugin-xineliboutput spielt perfekt.

    In softhddevice mit cuvid wird Audio Clock per AudioSetClock() sowohl mit Clear als auch mit ugly fix ca. 3 Sekunden zu weit nach vorne gesetzt. Dadurch entstehen viele Video drops bei ugly bzw. der Sprung bei Clear.

    Wieso Audio Clock springt, ist mir noch nicht klar, aber das scheint die Ursache zu sein.

    softhddevice mit vdpau bzw. nvdec werde ich noch ausprobieren, danke für den Hinweis.

  • Also bei softhddevice (mit vdpau) habe ich dieses Problem noch nie gehabt!

    Interessant! Bei mir tritt das auch damit auf.

    Welche Version von softhddevice ist das denn, und könntest du mal deine setup.conf Einträge für softhddevice posten.

    Dann könnte ich vielleicht den Unterschied finden.

  • 2.3.7-GIT2105c48

    Code
    [softhddevice]
    -d :0 -g 1920x1080 -f
    -v vdpau
    -w alsa-driver-broken

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Ich habe deine setup.conf Parameter bei mir implantiert, aktuelles softhddevice git mit deinem Aufruf gestartet, aber immer noch das Problem.

    Dann muss es an etwas anderem liegen.

    Welches ffmpeg benutzt du? Was könnte noch anders sein,was ev. Einfluss hat?

  • Bei meinem Thema bin ich etwas weiter. Ich vervielfache jetzt bereits die ankommenden avpkt und schicke die clone so oft zum decoder, wie es TrickSpeed vorgibt.

    Ich probiere gerade aus, wieviel avpkt der decoder bei mpeg2/h264 i/p benötigt, um ein frame auszuwerfen. Wenn zuviel gesendet werden, korrigiert der decoder die Reihenfolge und das ist bei rückwärts schlecht. Wenn gesendete avpkt Anzahl und Zeitpunkt des flush passen, scheint es zu funktionieren. Ich muss es jetzt nur noch zusammenkriegen.

    Meine VDRs

    (SatIP Server) --- Kathrein Exip 418 ---

    (Server) --- HW: RPI5 --- SW: RPiOs, VDR 2.7.2 mit streamdev, satip/vtuner-ng, vdrmanager, live, epgsearch, markad ---

    (Client 1+2) --- HW: Radxa Rock 4 Plus - RK3399 --- SW: VDR*ELEC mit softhddevice-drm-gles ---

    (WIP) --- Tanix TX6, RPi5, RPi4, Odroid N2+, WetekPlay2 --- SW: VDR*ELEC mit softhddevice-drm-gles --

  • ... für multispeed muss ich wohl doch das frame verdoppeln und nicht avpkt ...

    Meine VDRs

    (SatIP Server) --- Kathrein Exip 418 ---

    (Server) --- HW: RPI5 --- SW: RPiOs, VDR 2.7.2 mit streamdev, satip/vtuner-ng, vdrmanager, live, epgsearch, markad ---

    (Client 1+2) --- HW: Radxa Rock 4 Plus - RK3399 --- SW: VDR*ELEC mit softhddevice-drm-gles ---

    (WIP) --- Tanix TX6, RPi5, RPi4, Odroid N2+, WetekPlay2 --- SW: VDR*ELEC mit softhddevice-drm-gles --

  • Ich habe deine setup.conf Parameter bei mir implantiert, aktuelles softhddevice git mit deinem Aufruf gestartet, aber immer noch das Problem.

    Dann muss es an etwas anderem liegen.

    Welches ffmpeg benutzt du? Was könnte noch anders sein,was ev. Einfluss hat?

    Basis ist Ubuntu 23.10. mit Kernel 6.5.0-44-generic.

    ffmepg hatte ich anscheinend mal aus den Sourcen kompiliert, aber das scheint durch upgrade auf eine höhere Ubuntu-Version seine Erledigung gefunden zu haben. Unter /usr/local/lib finde ich nichts von ffmpeg. Das müsste also das normale alsa der Ubuntu-Version 23.10 sein:

    Hast Du in den vdr-Einstellungen multispeed aktiviert? Das ist bei mir aktiv:

    Code
    MultiSpeedMode = 1

    Mein Test war mit der ersten Zeitlupenstufe vorwärts. Es kann sein, dass ohne Multispeed eine andere speed genommen wird. Allerdings gibt es bei mir auch in der zweiten und dritten Stufe keine Probleme bei der Rückkehr zu Normalgeschwindigkeit.

    nvidia-Treiber ist 470.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • MultiSpeedMode = 1 habe ich auch.

    ffmpeg ist bei mir 6.1.2.

    nvidia ist 550.120.

    Du hast AudioPassthrough, ich nicht. Wie kommt denn der Ton bei dir heraus? HDMI? Spdif? ...?

  • Bei meinem Thema

    Ist das OK, dass wir hier in deinem Fahrwasser plantschen? Sonst frage ich einen Moderator, das zu verschieben.

  • Kein Problem, so ein Trickspeed-Sammelbecken schadet nicht :)

    Meine VDRs

    (SatIP Server) --- Kathrein Exip 418 ---

    (Server) --- HW: RPI5 --- SW: RPiOs, VDR 2.7.2 mit streamdev, satip/vtuner-ng, vdrmanager, live, epgsearch, markad ---

    (Client 1+2) --- HW: Radxa Rock 4 Plus - RK3399 --- SW: VDR*ELEC mit softhddevice-drm-gles ---

    (WIP) --- Tanix TX6, RPi5, RPi4, Odroid N2+, WetekPlay2 --- SW: VDR*ELEC mit softhddevice-drm-gles --

  • Du hast AudioPassthrough, ich nicht. Wie kommt denn der Ton bei dir heraus? HDMI? Spdif? ...?

    Die Ausgabe erfolgt über den HDMI der Nvidia-Grafikkarte. Dazu ist in den Tonmischer-Einstellungen von pavucontrol das Gerät "GP108... Digital Stereo (HDMI)" ausgewählt und der Lautstärkeregler muss exakt auf 0 dB stehen. In der /etc/pulse/client.conf wurde zusätzlich der Eintrag autospawn = no ergänzt.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Ich kann leider kein AudioPassthrough testen.

    Magst du mal testen, was passiert, wenn du den Ton analog über Motherboard Audio ausgibst?

    Mein Verdacht ist, dass das Problem dann auch auftritt.

  • Magst du mal testen, was passiert, wenn du den Ton analog über Motherboard Audio ausgibst?

    Mein Verdacht ist, dass das Problem dann auch auftritt.

    Der Wechsel von Zeitlupe auf Play ist, was das Bild betrifft, sauber. Allerdings kommt der Ton nicht wieder. Bei Pause/Play ist das kein Problem, aber nach Pause/Speed/Play kriege ich erst wieder Ton, wenn ich ein Stück spule oder mit den gelb/grün-Tasten springe.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Der Wechsel von Zeitlupe auf Play ist, was das Bild betrifft, sauber. Allerdings kommt der Ton nicht wieder. Bei Pause/Play ist das kein Problem, aber nach Pause/Speed/Play kriege ich erst wieder Ton, wenn ich ein Stück spule oder mit den gelb/grün-Tasten springe.

    Das ist genau wie bei mir.

    Die Frage ist also, was das Problem betreffend, den Unterschied macht zwischen AudioPassthrough und analogem Ton .

    Und danke für den Test!

  • Ich bin noch am Kämpfen mit dem ffmpeg decoder. Alle Versuche, das sauber hinzukriegen, sind bislang gescheitert.

    Ich möchte ein avpkt senden, von mir aus auch mehrfach, wenns hilft oder einen flush schicken und dann auf das Frame warten. Das klappt teilweise auch.

    Bei 1080i, z.B. AnixeHD habe ich aber Probleme und habe mir mal die avpkt->data angesehen. Hier wäre mal so ein Beispielablauf, wenn ich keine avpkt doppelt schicke, sondern nur den decoder fülle und nach jedem send versuche, das frame zu bekommen. Kann mir jemand auf die Sprünge helfen, was es z.B. mit den ersten beiden Paketen auf sich hat, die nur 20ms auseinander sind? Den avpkt->pts und die ersten 10 bytes von avpkt->data gebe ich aus.

    Gehören .311 und .331 zusammen und ich brauche beide für ein frame? Bin in den Bitstream noch nicht eingestiegen...

    Jedenfalls ist es so, dass das erste avpkt wieder als frame kommt, die anderen 5 gehen unter, weil oben nach dem receive ein decoder flush stattfindet....

    Meine VDRs

    (SatIP Server) --- Kathrein Exip 418 ---

    (Server) --- HW: RPI5 --- SW: RPiOs, VDR 2.7.2 mit streamdev, satip/vtuner-ng, vdrmanager, live, epgsearch, markad ---

    (Client 1+2) --- HW: Radxa Rock 4 Plus - RK3399 --- SW: VDR*ELEC mit softhddevice-drm-gles ---

    (WIP) --- Tanix TX6, RPi5, RPi4, Odroid N2+, WetekPlay2 --- SW: VDR*ELEC mit softhddevice-drm-gles --

    Edited once, last by rell (October 22, 2024 at 11:03 AM).

  • Ich denke, ich habs jetzt hinbekommen, zumindest ohne multispeed.

    Für meine 3 Beispielstreams sieht es folgendermaßen aus:

    MPEG2 576i: send 1 avpkt, send flush packet, receive frame, flush buffers

    H264 720p: send 1 avpkt, send flush packet, receive frame, flush buffers

    H264 1080i: send 2 avpkts, send flush packet, receive frame, flush buffers

    Jetzt wäre nur noch die Frage, wie ich herausfinden kann, dass ich bei dem H264 1080i stream 2 Pakete senden muss.

    Momentan greife ich die coded_height ab und treffe die Entscheidung damit. Das funktioniert aber nur, wenn sicher ist, dass alle Streams dem oben beschriebenen Schema folgen!?

    Alternativ könnte ich mir avpkt->data abgreifen und solange frames senden, bis wieder eines mit

    Code
    0x00 0x00 0x01 0x09 0x10

    kommt?

    Meine VDRs

    (SatIP Server) --- Kathrein Exip 418 ---

    (Server) --- HW: RPI5 --- SW: RPiOs, VDR 2.7.2 mit streamdev, satip/vtuner-ng, vdrmanager, live, epgsearch, markad ---

    (Client 1+2) --- HW: Radxa Rock 4 Plus - RK3399 --- SW: VDR*ELEC mit softhddevice-drm-gles ---

    (WIP) --- Tanix TX6, RPi5, RPi4, Odroid N2+, WetekPlay2 --- SW: VDR*ELEC mit softhddevice-drm-gles --

  • Du wird ja i.A. vor TrickSpeed normales Decoding machen.

    Dann kannst du es dir aus "avFrame.flags & AV_FRAME_FLAG_INTERLACED" holen und merken für das spätere TrickSpeed.

    VDR

    Server: Ubuntu 24.04 headless VDR im LXC Container, Plugins: satip (Octopus NET SL SX8), live, epgsearch, epg2vdr, markad

    Clients: LibreELEC auf RasPi3 und RasPi 3+

  • Ich bin einen Schritt weiter.

    Mit

    Diff
    --- softhddevice.cpp.bak        2024-10-11 21:37:32.393254700 +0200
    +++ softhddevice.cpp    2024-10-23 23:52:12.945915544 +0200
    @@ -2796,6 +2796,7 @@ class cSoftHdDevice:public cDevice
     #endif
         virtual void Clear(void);
         virtual void Play(void);
    +    virtual bool HasIBPTrickSpeed(void) { return true; };
         virtual void Freeze(void);
         virtual void Mute(void);
         virtual void StillPicture(const uchar *, int);

    und

    Diff
    --- softhddev.c.A       2024-10-24 01:22:34.621020004 +0200
    +++ softhddev.c 2024-10-24 00:40:28.557671333 +0200
    @@ -3112,7 +3112,7 @@ void Freeze(void)
     void Mute(void)
     {
         SkipAudio = 1;
    -    AudioFlushBuffers();
    +    //AudioFlushBuffers();
         //AudioSetVolume(0);
     }

    sowie

    geht es.

    Aber noch nicht auf Nebenwirkungen getestet.

Participate now!

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