sunxi-vdpau WIP (ehemals interlaced branch)

Wie könnte man das denn Reverse Engineeren? Gibt es ein Programm, das libve benutzt?

Zitat von WoF

Wie könnte man das denn Reverse Engineeren? Gibt es ein Programm, das libve benutzt?

Ich habe bisher nur versucht mich einzulesen. Startpunkt wäre hier. Da sind ein paar Seiten verlinkt, mit denen die REer der sunxi community so arbeiten.
https://github.com/blobslaundry/cedarblobs
https://gitorious.org/recedro/recedro/source/master:

Viel Spaß :p

Andreas

Zitat von WoF

Wie könnte man das denn Reverse Engineeren? Gibt es ein Programm, das libve benutzt?

Was glaubst du wie libvdpau-sunxi entstanden ist?

Das Problem das ich gerade sehe ist, das use_maf flag scheint es nur in der alten libve zu geben, in den neuen, leichter zu verwendenden, scheint es zu fehlen. Und in der "Anleitung" zur neuen lib steht hinter flag_addr, flag_stride usw. 预留,不用, was soviel heißen müsste wie "reseved, not used"

Wenn ich Lust hab versuch ich über Weihnachten nochmal die alten libs zum laufen zu bringen, aber eigentlich hab ich keine Lust auf das Chaos.

Momentan wird MAF_BOB benutzt. Von MAF erwarte ich keine höhere Qualität. Die Klötzchenbildung kommt vom Decoder. Da anzusetzen halte ich für sinnvoller.

Gruss zille.

Zitat von Zille

Momentan wird MAF_BOB benutzt. Von MAF erwarte ich keine höhere Qualität. Die Klötzchenbildung kommt vom Decoder. Da anzusetzen halte ich für sinnvoller.

Wenn momentan MAF zum deinterlacing benutzt wird, obwohl an der dazu notwendigen flag_addr nichts sinnvolles steht, würde ich doch eher behaupten es liegt nicht am Decoder.
Kann mir mal jemand ein Video wo es zur Klötzchenbildung kommt schicken? Alle die ich bisher probiert hatte waren nämlich sauber, waren aber auch nicht interlaced.

Die Variablen maf_flag_addr und maf_linestride werden bei DIT_MODE_MAF benutzt. Bei DIT_MODE_MAF_BOB wird das nicht verlangt. Siehe da. Der disp Treiber nutzt wohl pre_frame_addr. Die grössten Probleme mit Klötzern treten bei 576i Mpeg2 auf. Durch das Skalieren werden die dann auch noch mit gross gezogen. Bei 1080i sieht's schon schick aus.

jemk,
hab eine gmx Media Einladung nach *@gmail.com geschickt. Da liegt eine ntv Aufnahme.

Gruss zille

Zitat von rell

Ich finde, wir sind schon ein ganzes Stück weiter gekommen. Allerdings sollten wir bedenken, dass auch andere Programme auf libvdpau-sunxi zugreifen und somit die Abhängigkeit von interlaced von der Bildhöhe in libvdpau nicht korrekt sein kann.

Dem stimme ich zu. Die Variante mit toggle top_field_first hat mir besser gefallen.

Zitat von jodamm

Hmm, bei meinen vielen Versuchen hatte ich irgendwann mal einen Einfluss darauf, vielleicht hatte ich es auch auf weave stehen was ja kein Deinterlace sein soll.

Das sollte noch mal getestet werden. Das kann die Ursache sein das interlace nicht gesetzt war.

Gruss zille

Hallo zusammen,

erst einmal vielen Dank an alle, die die Entwicklung auf dem Cubieboard so voran getrieben haben!
Dank des super Howto von jodamm läuft bei mir nun auch der Vdr als Client auf meinem CB2.
Über die Feiertage möchte ich mich auch etwas in die Thematik einarbeiten und mittesten.

Der Vdr läuft nun seit ca. einer Stunde und ich konnte noch keine Abstürtze oder wirklich störende Effekte (HD und SD) feststellen?!

Wo liegen momentan noch die größten Schwierigkeiten/Probleme?
Könnt ihr mir bitte mal eure Entwicklungsumgebung beschreiben, also wie programmiert bzw. debuggt ihr, nutzt ihr dazu eine IDE auf einem Rechner oder entwickelt ihr direkt auf dem Cubieboard?

Schon mal vielen Dank!

Gruß,
ape

Zitat von ape

Wo liegen momentan noch die größten Schwierigkeiten/Probleme?

Die Schwierigkeiten wirst du dann im Betrieb selbst feststellen. Dazu benötigts Tester...

Offene Tasks wären aber imho:

- Vernünftige Implementierung der ganzen Deinterlacer Sache - ohne die Kompatibilität mit anderen Programmen zu brechen
- Versuchen MAF zum Laufen zu bringen
- Verzicht auf glib.h, stattdessen Nutzen einer eigenen Queue
- Erstellen einer HowTo Seite auf linux-sunxi.org (auf das VDR spezifische beschränkt!)
- grundlegende Organisation: Erstellen einer Todo-Liste / organisierende WIP Seite im Wiki (wie z.b. hier)
- Zusammenfassung der notwendigen Kernel Anpassungen (VE mem reserve, disp bug fixes ...)
- etc....

Zitat von ape

Könnt ihr mir bitte mal eure Entwicklungsumgebung beschreiben, also wie programmiert bzw. debuggt ihr, nutzt ihr dazu eine IDE auf einem Rechner oder entwickelt ihr direkt auf dem Cubieboard?

Bei mir ganz spartanisch. libvdpau-sunxi baue ich direkt auf der Arm Kiste. Code schreiben direkt über die hauseigenen Editoren (mcedit).
VDR wird cross kompiliert in einer VM. Hier ebenfalls keine IDE. Kernel ebenfalls.
Debugging passiert über den Einbau von printf an den wichtigen Stellen.

Ich denke, jeder kann etwas dazu beitragen, und wenn wir es schaffen, dass das ganze vernünftig läuft, haben wir eine schicken schlanken und günstigen VDR-Client :p

Gruß
Andreas

Zitat von Zille

Die Klötzchenbildung kommt vom Decoder. Da anzusetzen halte ich für sinnvoller.

Hab das gerade nochmal mit Zilles sample getestet, da ist wohl wirklich was nicht in Ordnung, ist mir aber bei meinen Samples noch nie aufgefallen.
Ich werd mal schauen ob sich was machen lässt, aber die original libve liefert das gleiche Ergebnis. Was jetzt nichts heißen muss, die hat bei h264 auch diverse Fehler gemacht die in vdpau-sunxi jetzt behoben sind.

EDIT: Hattest wohl recht, man sollte nicht einfach Code aus dem Testprogramm nach libvdpau copy&pasten ohne zu merken das bei vdpau die Reihenfolge der Matrixelemente anders ist als im Testprogramm... Bei meinen Samples fällt das (fast) nicht auf. Fix ist im git.

Hallo Jemk,

das sieht schon viel viel besser aus! Vielen Dank! Hast Du mal einen Blick auf den Deint Branch geworfen? Gibt es eine Chance das in Dein Master zu integrieren?

Die Änderung von Jemk habe ich in den deint Branch übernommen.

Gruss zille

Das sieht deutlich besser aus. Im Vergleich zu VLC unter Windows am gleichen TV-Gerät ist noch MPEG-Rauschen sichtbar. Ich dachte vielleicht, dass es bei mir daran liegt, dass meine Aufzeichnung die alternative Scan-Tabelle benutzt und habe die zusätzlich mal in den Code eingebaut , aber ich kann keinen gravierenden Unterschied feststellen.

Schön, es sind bestimmt noch ein paar Sachen falsch, ich hatte die mpeg engine nie genauer untersucht nachdem es einmal lief. Also wenn euch noch was auffällt...

Zitat von WoF

... dass meine Aufzeichnung die alternative Scan-Tabelle benutzt und habe die zusätzlich mal in den Code eingebaut , aber ich kann keinen gravierenden Unterschied feststellen.

Die hatte ich auch schon drin, musste aber fest stellen das das nicht passen kann. Zilles sample hatte alternate_scan=1, wenn ich aber die alternative Tabelle genutzt habe gab es ein haufen Fehler. Mein Sample hat alternate_scan=0 und es geht auch mit der Tabelle und nicht mit der alternativen. Ich vermute fast das die Hardware diese Unterscheidung selbst macht und immer die gleiche Reihenfolge von uns bekommt.

Zitat von Zille

Hast Du mal einen Blick auf den Deint Branch geworfen? Gibt es eine Chance das in Dein Master zu integrieren?

Auf lange Sicht schon, ich hätte nur gern mal die presentation Sachen auch etwas aufgeräumt.Ich hab das damals alles nur kurz zusammengehackt um ein Bild raus zu bekommen, da ist kein wirklicher Plan dahinter (eigentlich ist bei fast nichts in der lib ein Plan dahinter...) und es sind auch viele Dinge nicht korrekt. Zum Beispiel bräuchte man auch mal einen richtigen X Event Loop damit man mal von dem XClearWindow jedes Frame wegkommt, das frisst ein Haufen CPU Leistung. Also wenn jemand Lust hat das schön sauber zu machen hab ich da überhaupt nichts dagegen, wobei ich mein Durcheinander eigentlich selber aufräumen müsste und nicht an andere abdrücken.

Hallo Jens,

weißt du was die Register MACC_MPEG_IQ_INPUT und MACC_MPEG_IQ_IDCT_INPUT machen? Hat das vielleicht etwas mit dem Quantizer Scale Factor zu tun? Bei meiner Test-Datei ist nämlich q_scale_type gesetzt. Die Einträge in der Quantisierungsmatrix müssen also, so wie ich das verstanden habe, mit einem nicht linearen Faktor multipliziert werden. Evtl. müssen wir das selbst machen? Denn der quantizer_scale_code ist nicht im Picture-Header enthalten und wird auch nicht an den HW-Dekoder weitergegeben - er weiß also gar nichts davon. Ich hätte mal ausprobiert den Faktor auf die Quantisierungsmatrix anzuwenden, aber ich weiß nicht wie man an der Stelle an den Slice-Header herankommt um den quantizer_scale_code auszulesen...

Wenn ich mich nicht irre bekommt der hw-Dekoder den kompletten Slice inklusive Header (der den quantizer_scale_code enthält), ich denke mal er parst das selber. Und q_scale_type kommt ja über das picture header register.
Aber wie gesagt, mit der MPEG Engine hab ich mich nie eingehender beschäftigt, die war nur ein Zwischenschritt zum Kennenlernen der Hardware um das Prinzip zu verstehen und dann die deutlich kompliziertere h264 engine zu reverse engineeren. An MACC_MPEG_IQ_INPUT und MACC_MPEG_IQ_IDCT_INPUT kann ich mich jedenfalls nicht erinnern die jemals in Verwendung gesehen zu haben, die Namen kommen glaub ich von wingrime aus den Debuginfos der libve, keine Ahnung ob die richtig sind und was sie machen.

Erst einmal vielen Dank an alle, die an der Lib gearbeitet haben. Ein Punkt fällt mir noch auf beim Testen: Im Deinterlacer-Mode ist das Bild deutlich dunkler als sonst. Kann man da noch was machen?

LG
beta

Hallo beta,

das habe ich noch nicht beobachten können. Kannst du 20-30 Sekunden von deiner Videodatei irgendwo hochladen?

Hallo WoF,

ich habe einen Schnipsel hier hochgeladen.

LG
beta