Quellcodes

  • Da ich selber nicht weiter daran arbeiten werde habe ich mich entschlossen die Quellen zu veröffentlichen.


    Ich hoffe es findet sich jemand der durchsteigt was ich da verzapft hatte und meine Arbeit fortführen möchte.


    Offen wäre da z.B.


    - Code aufräumen und vereinheitlichen
    - ColorMode und MultiChannelDecoding für beide (bisher Mosaik = ColorMode und PiP = MultiChannelDecoding)


    Na dann, ran an den Speck...


    Edit: Bitte zur weiteren Entwicklung die Sourcen aus dem CVS (PiP / Mosaic) nutzen!

    Files

    • pip_msc.tar.gz

      (304.63 kB, downloaded 732 times, last: )

    Ich bin nicht faul sondern im Energiesparmodus!

    Edited once, last by LazyT ().

  • Tausend Dank,
    was man hier so alles findet. Da hätte ich hier schon mal früher alles duchstöbern müssen. An dem Teil wollte ich schon immer mal dran rumfummeln.


    beste Grüße
    adenin

  • Na klar, mach ich.
    Erste Ergebinsse: ich hab es gerade compiliert und getestet und dabei hat sich Box mit "getCurrent - and nothing ready!" verabschiedet. Das ist aber ein Bug im enigma. Da wird, wenn man über das Webinterface die Transponderabfrage macht vorher nicht geprüft ob die PAT korrekt empfangen wurde (und ich hatte gerade keine Antenne dran).
    Ok, gefunden und beseitigt (meckere ich gleich mal in der Bugecke an).


    beste grüße
    adenin

  • Die Plugins sind jetzt im CVS.


    Ich habe noch ein wenig mit dem PiP rumgespielt und da mal Double-Buffering für den Framebuffer eingebaut (analog zu Tuxtxt).
    Dadurch scheint es bei mir etwas weniger zu ruckeln, das kann aber auch nur eine Illusion meinerseits sein ;)


    Eine weitere Optimierungsmöglichkeit wäre vielleicht, wenn man irgendwie einbauen könnte, dass nur die Zeilen/Spalten des Bildes dekodiert werden, die auch im PiP angezeigt werden.
    Wenn ich das richtig verstanden habe, dann wird bisher jeweils das ganze Bild dekodiert und dann werden die nicht benötigten Bildpunkte rausgefiltert.


    Oder gibt es irgendeine Möglichkeit, das von dem MPEG-Dekodierchip der Box machen zu lassen ?
    In der libmpeg2 sind ja Assembler-Optimierungen für verschieden Architekturen drin, evtl. gibt's da ja auch was für die Dreambox...


    dbluelle

  • Hmm, bei mir klappts nicht wirklich, hat jemand eine Idee?


    cu


    PS - OK, habs gesehen, wahrscheinlich liegts an der Freetype-version, die ich nutze...
    PPS - Hmm, aber was soll der STATE_SEQUENCE_MODIFIED-error?

  • Coronas ,


    lösche einfach ab Zeile 2378 diesen Code

    Code
    1. case STATE_SEQUENCE_MODIFIED:
    2. //Log2File("STATE_SEQUENCE_MODIFIED");
    3. break;

    In Version 0.4.1 der libmpeg2 gibt es kein STATE_SEQUENCE_MODIFIED mehr.


    beste Grüße
    adenin

  • Coronas ,


    lösche einfach ab Zeile 2378 diesen Code

    Code
    1. case STATE_SEQUENCE_MODIFIED:
    2. //Log2File("STATE_SEQUENCE_MODIFIED");
    3. break;

    In Version 0.4.1 der libmpeg2 gibt es kein STATE_SEQUENCE_MODIFIED mehr.


    beste Grüße
    adenin
    [EDIT]
    Ich sehe gerade das du eine eine ander Version von pip haben musst. Zeile 2378 gilt für die originale 0.7b von LacyT. Wird also bei dir ab Zeile 2425 sein.
    Den Fehler mit FTC_ImageDesc kann ich nicht nachvollziehen, da ich im Moment nicht die Source habe die Du benutzt. Sende sie doch mal per PN.


    [EDIT]
    Mist, Doppelpost. Ich habe aber eindeutig auf Ändern gedrückt.

  • Die Sache mit dem STATE_SEQUENCE_MODIFIED habe ich im CVS gefixt
    (obwohl ich nicht weiss, wieso das bei mir dann kompiliert hat ?( )


    Für Freetype 2.0.9 war auch noch ein Tippfehler drin :rolleyes:, das müsste jetzt auch funktionieren.


    dbluelle

  • OK, Danke!
    cu


    Nachtrag - zu früh gefreut...


  • Almost there... Fehlt noch jeweils die schliessende Klammer ) und damit kompiliert es dann durch. Danke fürs fixen, ich kanns leider nicht einchecken, meine Editoren scheinen zu spinnen. Aber das ist ein anderes Thema ;)
    cu

  • Ja, ich werde mir mal den MPEG-Decoder vornehmen, mal sehn was sich da machen lässt. Dort gibt es die meisten Probleme. Er ist einfach noch zu langsam. Ausserdem spukt er die Bilder einfach aus ohne den richtigen Zeitpunkt anzugeben und pip zeigt die Bilder an, egal ob der richtige Zeitpunkt für das Bild da ist oder nicht, was zur Folge hat, dass das kleine Bild mal vorgeht (wenn nur geringe Bitraten vorliegen) oder nachläuft bist zu Klötzchenbildung und Ruckler, bei höheren Bitraten.


    Quote

    Eine weitere Optimierungsmöglichkeit wäre vielleicht, wenn man irgendwie einbauen könnte, dass nur die Zeilen/Spalten des Bildes dekodiert werden, die auch im PiP angezeigt werden.
    Wenn ich das richtig verstanden habe, dann wird bisher jeweils das ganze Bild dekodiert und dann werden die nicht benötigten Bildpunkte rausgefiltert.


    Dies ist nicht möglich, es muss immer das gesammte Bid decodiert werden. Das ist eben bei MPEG2 so. Aber man könnte Geschwindigkeit gewinnen, wenn man die Rechengenauigkeit und damit aber auch die Bildqualität (die bei dem kleinen Bild aber nicht so ins Gewicht fällt) verringert.


    beste Grüße
    adenin


    [EDIT]


    Der Decoder tut doch Zeitinfos (PTS) liefern, pip nutzt sie nur noch nicht.


    [EDIT]
    Ich hab einige Tests mit verschiedenen Sendern gemacht. Bis ca. 4Mbit/s scheint der Dekoder sicher zu funktionieren, das betrifft die meisten Sender. Bei 4.5MBit/s gibt es mit Sicherheit periodische Bildstörungen. Kritische Sender sind: ARD ,ZDF, 3sat, ZDFinfo ...
    also die meisten der größenen öffentlich rechtlichen Sender Deutschlands. Die Grenze liegt im Moment also irgendwo zwischen 4.0 und 4.5 MBit/s.
    [EDIT]
    Es gibt ein offensichtlich ein Problem mit dem double buffering.
    Starte pip, verschiebe die Position des Bildes, beende pip und starte es erneut. pip startet an der Defaultposition aber an der verschobenen Position blitzt periodisch ein altes Bild auf.

  • Quote

    pip zeigt die Bilder an, egal ob der richtige Zeitpunkt für das Bild da ist oder nicht, was zur Folge hat, dass das kleine Bild mal vorgeht (wenn nur geringe Bitraten vorliegen) oder nachläuft bist zu Klötzchenbildung und Ruckler, bei höheren Bitraten.


    Sehe ich eigentlich nur als sinnvoll an um bei hohen Bitraten Frames zu verwerfen sobald das Hinterherhinken zu groß wird. Sonst spielt es ja prinzipiell keine Rolle ob das PiP etwas vorläuft...

    Ich bin nicht faul sondern im Energiesparmodus!

  • Naja, ich vermute eher, dass das Verwerfen der Bilder wohl durch den Decoder erledigt wird, oder durch die Dreambox selbst, wenn irgend einer der Puffer voll läuft. Das passiert aber nur bei Sendern mit hoher Bitrate (irgendwo über 4MBit/s).
    Ich kritisiere das Verhalte ja nicht, ich versuch nur, bevor ich etwas zusätzliches dazu programmiere, Schritt für Schritt rauszufinden, wie das Ding funktioniert. So findet man auch noch (ok - zufällig) Fehler im Enigma.


    beste Grüße
    adenin


    [EDIT]
    Ich nehme mir gerade den Decoder vor und habe da ein Problem.
    Der Code zeigt ein Stück aus der Routine copy_chunk.
    Mein Problem ist, wieso wird beim Verlassen (also wenn shift == 0x00000100 ist) der chunk_ptr noch einmal erhöht? Er zeigt doch aktuell auf die nächste zu schreibende Adresse. Damit ist doch dann ein nicht definiertes Byte im Datenstrom (ok, ausserhalb der Chunk's und damit anscheinend ohne sichtbare Auswirkung).


    Hat jemand eine Idee wieso das gemacht wurde?