Posts by zillerbaer

    Im Stream sind die Packete in der Decodierreihenfolge. Das ist nicht zwangsläufig die Anzeigereihenfolge. Das sortieren macht nach dem decodieren der Decoder anhand des PTS. Das scheint bei AML noch zu fehlen. Der PTS steht im undecodierten Packet und wird vom Sender / Encoder festgelegt.

    Was für ein Kernel benutzt Du? Die Kernelmeldungen sehen bei mir so aus:

    Allgemein sind Allwinner und Rockchip vom mainline Kernel am Besten unterstützt. Ich habe hier ein Rockpro64 im Einsatz.


    Pros: RK3399 hat sehr Performance, RTC mit funktionierendem wakeup, PCIe für eine DD-Cine, Lüftersteuerung onboard, USB3, emmc, gpio, Power Button.


    Cons: Als ich den vdr aufgebaut habe war der Soundchip sehr schlecht unterstützt. Wenn der PCIe Bus werkelt funktioniert IR über gpio nicht mehr.


    Mehr sollten wir in einem anderen Thread diskutieren.

    Könnte das was mit den folgenden Commits zu tun haben? Rein aus deinem Gefühl?

    Das fühle ich nicht. :)


    Da geht was mit den Formaten durcheinander. Bwdiff ist ein SW Deinterlacer von FFmpeg. Der kann nur mit YUV420 umgehen. Daraus folgt: Wenn der SW Deinterlacer zum Einsatz kommen soll muss in SW Decodiert werden da der HW Decoder das falsche Format liefert. Ich würde CodecMode auf 2 setzen.

    Aber wenn man sich das Design anschaut, ist das ein PC Layout und kein kleines leichtes Entwicklerboard mehr.

    Das war das Rockpro64 vor Jahren schon. Mittlerweile ist das Standard! Bei Raspberry bin ich gespaltener Meinung. Auf der einen Seite hat das Unternehmen die ARM Boards sehr verbilligt. Auf der anderen Seite wird immer noch eine proprietäre Firmware auf der GPU gebootet unter deren Gnaden ein Linux-System auf den ARM Cores arbeiten darf.

    FLIRC nutzt wohl das X11 Keyboard. X11 gibt es aber nicht. Keine Ahnung ob das an eine Konsole gebunden werden kann. FLIRC kommuniziert nur mit vdr. Softhddevice-drm macht was vdr vorgibt.


    Auf einem ARM Board würde ich einen IR-Empfänger direkt an einen GPIO-Pin stöpseln und RC-Core über GPIO nutzen. Das ist einfach und preiswert.

    Die Simpsons und Galileo waren aber progressive.

    Es wechselt im Stream immer wieder hin und her. Ein Muster habe ich bisher nicht finden können. FFmpeg untersucht nur einige Frames am Anfang der Aufnahme und gibt diese Ergebnisse aus.

    Habt Ihr die auch, oder muss ich nach dem Feher in meiner SAT-Verteilung suchen gehen?

    Solche Fehler findet FFmpeg hier auch. Mit Mediaplayer und über vdr wird die Aufnahme aber abgespielt. Das muss ich noch genauer untersuchen. An der SAT Anlage brauchst du wohl erst mal nix machen.


    Meinen Fehler habe ich wohl gefunden. Seit gestern Abend keine Segfaults mehr. Es war dann wohl ein Threading Problem. Jetzt muss ich noch die zeitliche Reihenfolge der Bilder sicher stellen.

    Zeig mal den Code ;)

    Da steht jetzt:

    Code
        if (render->interlaced_frame != frame->interlaced_frame) {
            #include <time.h>
            time_t now;
            time(&now);
    
            fprintf(stderr, "VideoRenderFrame: interlaced_frame changed to %d , %s\n",
                frame->interlaced_frame, ctime(&now));
            render->interlaced_frame = frame->interlaced_frame;
        }

    Er bleibt aber nicht hängen,

    Ich denke das das nur mein Plugin macht. Weiss aber noch nicht warum.

    sondern dropt und dupt gelegentlich.

    Das muss ich auch noch klären. Ein progessive Frame kann sofort in die Queue. Ein interlaced muss erst durch den Deinterlacer. Das braucht seine Zeit. Da kann ein progessive Frame die interlaced Fames sozusagen überholen und in falscher zeitlicher Reihenfolge in der Queue ankommen.