Posts by zillerbaer

    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.

    Es wechselt zwischen interlaced und progressiv ständig hin und her. Hier ein Log über eine halbe Stunde von Sat1.

    Das aktuelle Problem ist das nach langer Zeit (Stunden) ein leeres Frame zum Anzeigen auftaucht und zum Segfault führt. Noch weiss ich nicht ob das vom Deinterlacer oder Decoder kommt. Hat jemand eine Idee?

    Sonst hätte man ja analog speichern müssen.

    Doch, das war analog. Digital kam später. ;)

    Es wurde oben links angefangen ein Pixel nach dem anderen mit dem Elektronenstrahl zeilenweise zu schreiben. Dabei wurde jede zweite Zeile ausgelassen. Diese wurde im zweiten Duchgang dargestellt. Danach wurde wieder oben angefangen. Der Elektronenstrahl hat permanent ein Pixel geschrieben. Daraus ergab sich dann durch die Trägheit der Röhre ein Bild.

    Heute werden die Informationen verarbeitet und das Bild zu einem Zeitpunkt dargestellt.

    Jedes Frame enthält nur ein halbes Bild.


    Es kommen immer die beiden Halbbilder eines Vollbildes nacheinander, dann die beiden Halbbildes des nächsten Vollbildes.

    Nein, es wird immer ein Frame übertragen das in den geraden Zeilen ein Halbbild und in den ungeraden Zeilen ein Halbbild enthält.


    Edit: Diese Halbbilder werden deinterlaced im Abstand von 20ms dargestellt. Die gesendeten progressiven Frames werden im Abstand von 40ms dargestellt. Die Bildinformationsmenge ist die gleiche, nur anders auf Bilder und zeitlich verteilt.

    SHF , Danke für Deine Recherche! Progressive Frames sind ein Standart. Das aber interlaced und progressive Frames gemischt in einem Stream vorkommen ist neu. Keine Ahnung ob das von einen Standart gedeckt ist.

    Bei der Bildqualität sehe ich eher Vor- als Nachteile

    Weder noch. Werden progressive Frames übertragen wird jedes zweite Bild weggelassen. Bei interlaced ist in einem Frame die Information für 2 Bilder. Die übertragene Bildinformationsmenge ist also gleich.

    Nach einem Kernel Update werden auch bei Rockchip die progessiven Frames erkannt. Die bringen die Ausgabe durcheinander. Seit gestern Abend scheint SAT1 komplett progressive zu senden. Das läuft zwar stabil, aber jedes Bild muss verdoppelt werden. Wollen die damit SD weiter verschlechtern um das Marketing für Ihre HD Karten anzutreiben?

    Im markad Log ist mir genau bei den o.g. Sendern seit ein paar Tagen aufgefallen, dass alle paar Minuten progressive Frames zwischen den interlaced Frames gesendet werden.

    Progressive Frames habe ich bisher noch keine gefunden. Es sind aber unregelmäßig Frames mit utopischer Weite und Höhe im Stream.

    Code
    [ 9756.296353] hantro_set_fmt_cap:596: fmt - w: 720, h: 576
    [ 9757.194262] hantro_set_fmt_cap:596: fmt - w: 48, h: 48
    [ 9757.194301] hantro_set_fmt_out:536: fmt - w: 0, h: 0
    [ 9757.194306] hantro_set_fmt_cap:596: fmt - w: 96, h: 32
    [ 9757.194311] hantro_set_fmt_out:536: fmt - w: 0, h: 0
    [ 9765.632471] hantro_set_fmt_cap:596: fmt - w: 96, h: 32
    [ 9765.632477] hantro_set_fmt_out:536: fmt - w: 0, h: 0
    [ 9765.632715] hantro_set_fmt_cap:596: fmt - w: 48, h: 48
    [ 9765.632751] hantro_set_fmt_cap:596: fmt - w: 720, h: 576

    Es geht soweit, dass nur noch die alten Karten mit STV0299 ein fehlerfreies Signal liefern.

    Was machen die alten Karten anders als z.B DD Cine? kfb77 , was für einen Tuner benutzt Du?