Hast du in den Softhddevice Einstellungen bei den Interlaced Auflösungen den Interlacer auf Temporal umgestellt? Dann sollte es eigentlich weg sein.
Nein, das hat keinen Einfluss. Es wird nur geschaut ob top_field_first von field zu field wechselt. Wenn ja wird der Deinterlacer eingeschaltet. Die Einstellung in softhddevice hat KEINEN Einfluss.
Die Qualität kann mit nvidia-vdpau nicht mithalten. Aber gegenüber dem früheren Gezappel sieht es schon gut aus oder?
Gruss zille.
Hallo,
es gibt im Kernel eine Variable mit dem vielversprechendem Namen pre_frame_valid. Das habe ich an bekannter Stelle jetzt mal hart gesetzt. Das hat aber nur Einfluss auf weniger Kammartefakte! Die Schattenbildung beeinflusst das nicht.
Happy testing!
Nein, das hat keinen Einfluss. Es wird nur geschaut ob top_field_first von field zu field wechselt. Wenn ja wird der Deinterlacer eingeschaltet. Die Einstellung in softhddevice hat KEINEN Einfluss.
Die Qualität kann mit nvidia-vdpau nicht mithalten. Aber gegenüber dem früheren Gezappel sieht es schon gut aus oder?
Gruss zille.
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.
Aber ich werde es nochmal testen. Ich habe gerade ein HOWTO geschrieben wie ich meine Installation gemacht habe, und spiele die jetzt nochmal durch. Dann werde ich es ja sehen. 
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.
Schau in den Code. Egal was da eingestellt ist. Es hat keinen Einfluss.
Das Howto ist gut! Aber sunxi_ve_mem_reserve=190 in der Kernelcommandline funktioniert mit dem aktuellen 3.4er Kernel leider nicht. Das muss in sunxi_cedar.c gepatcht werden.
Gruss zille
Das Howto ist gut! Aber sunxi_ve_mem_reserve=190 in der Kernelcommandline funktioniert leider nicht. Das muss in sunxi_cedar.c gepatcht werden.Gruss zille
Bei den Images von Igor Pečovnik funktioniert das weiterhin, er hat da wohl schon was geändert und kompiliert ohne CMA.
Igors Image kenn ich nicht. Hab Gentoo hier im Einsatz. Was ist CMA?
Gruss zille
CMA ist der Grund warum sunxi_ve_mem_reserve=190 nicht mehr geht. CMA heißt "Continuous Memory Allocator" hat irgendwas mit der Speicherverwaltung vom Linux Kernel zu tun. Und das beißt sich wohl mit dem Variablen mem_reserve.
Schau in den Code. Egal was da eingestellt ist. Es hat keinen Einfluss.
So die Installation ist durch, hab es jetzt nochmal getestet. Wenn man es auf Weave/None stellt ist Deinterlace deaktiviert, wenn es auf irgendwas anderes gestellt wird ist Deinterlace aktiv.
Hallo zille,
deine Ergänzung von pre_frame_valid bringt keine Änderung. Ich habe aber testweise mal video.interlace fest auf TRUE gesetzt, und damit sind die restlichen Kammartefakte weg. Dabei habe ich gesehen, dass wir im Moment nur Bob verwenden. Vielleicht ist das auch der Grund für die miserable Dekodierqualität?
Es gibt da noch ein flag das maf_valid heißt. Wenn ich das setze habe ich in der Horizontalen unterbrochene Kammartefakte. Sieht sehr komisch aus. Wahrscheinlich muss man noch die Parameter flag_stride und flag_addr setzen. In der A20-Doku steht dazu nur "Current frame tile flag buffer address" und "tile flag line-stride". Weiß jemand wir groß die Stride ist?
Hallo WoF,
bei meinen Versuchen hat der disp Treiber immer auf DIT_MODE_MAF_BOB geschaltet. Ich werde das heute Abend noch mal nachtesten. Bei der Gelegenheit schau ich mir top_field_first noch einmal an. Als ich das geschrieben hab hat es zuverlässig gearbeitet. Ich kann ja wieder alles ausser 720 breit durch den Deinterlacer jagen. Die Variante hatte ich am Anfang drin.
Gruss zille.
Hallo zille,
deine Ergänzung von pre_frame_valid bringt keine Änderung. Ich habe aber testweise mal video.interlace fest auf TRUE gesetzt, und damit sind die restlichen Kammartefakte weg. Dabei habe ich gesehen, dass wir im Moment nur Bob verwenden. Vielleicht ist das auch der Grund für die miserable Dekodierqualität?
Es gibt da noch ein flag das maf_valid heißt. Wenn ich das setze habe ich in der Horizontalen unterbrochene Kammartefakte. Sieht sehr komisch aus. Wahrscheinlich muss man noch die Parameter flag_stride und flag_addr setzen. In der A20-Doku steht dazu nur "Current frame tile flag buffer address" und "tile flag line-stride". Weiß jemand wir groß die Stride ist?
flag_stride und flag_addr sind notwendig, um MAF zu benutzen. Bisher ist aber nicht klar, wo wir diese Werte herbekommen. Eine Vermutung wäre, dass sie von den Registern 0x30-0x4c der Video Engine geliefert werden. Allerdings ist die genaue Belegung der Register nicht bekannt. Beispielcode von Allwinner gibts hierzu auch nicht...
pre_frame_valid setzt den Parameter tempdiff_en. Mir stellt sich nur die Frage, was es mit dem "//todo" hier auf sich hat, und was passiert, wenn man tempdiff_en auf TRUE lässt...
Gruß Andreas
Hallo,
habe gerade die Howto von jodamm durchgearbeitet und bei allen Sendern (HD und SD) ein Bild ohne freeze an meinem cubieboard2. 
Ich Danke allen für die bisherige Arbeit an vdpau. 
Finde das hier _richtig_ viel passiert ist die letzten Monate...
PS: Ich nutze die vdpau Version aus dem Howto (git clone -b deint https://github.com/zillevdr/libvdpau-sunxi/))
So die Installation ist durch, hab es jetzt nochmal getestet. Wenn man es auf Weave/None stellt ist Deinterlace deaktiviert, wenn es auf irgendwas anderes gestellt wird ist Deinterlace aktiv.
Wenn softhddevice top_field_first bei ausgeschaltetem Deinterlacer nicht mehr weiter gibt. Kann ich mir vorstellen.
und was passiert, wenn man tempdiff_en auf TRUE lässt...
Ja, nur Mut! 
Gruss zille
Ich habe aber testweise mal video.interlace fest auf TRUE gesetzt, und damit sind die restlichen Kammartefakte weg.
Im git wird jetzt geprüft ob die Höhe des Bildes nicht 720 ist. Dann wird der Deinterlacer gesetzt. Es sollte jetzt stabil erkannt werden.
Gruss zille
Hallo zille,
die Erkennung funktioniert jetzt zuverlässig mit 576i, 720p und 1080i. Servus TV HD sieht jetzt richtig gut aus, ich finde das kann man so benutzen. Bei 720p sieht man leichtes MPEG-Rauschen (Körnung), da ist der Dekodierer vom A20 wahrscheinlich einfach nicht so toll. Bei SD sieht man die MPEG-Artefakte/Schatten wie oben in den "Screenshots", aber keine ausgefransten Kanten mehr. Wenn man genau hinschaut sieht man aber noch innerhalb(!) von sich überblendenen Flächen (z.B. Gesichter oder Programminformationen) Kammstrukturen. Siehe Anhang.
Im git wird jetzt geprüft ob die Höhe des Bildes nicht 720 ist. Dann wird der Deinterlacer gesetzt. Es sollte jetzt stabil erkannt werden.Gruss zille
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.
Als workaround für VDR ok, aber für die anderen müsste das sauber gelöst werden. Den Beispielprogrammen von Allwinner gibt diese Information m.E. der Decoder als frame_info mit.
Tatsächlich sollte versucht werden mit den interlaced Angaben von softhddevice umzugehen, hier wird ja im Prinzip die Variable schon abhängig von der Bildhöhe gemacht.
Gruß Andreas
Hallo Andreas,
ich würde vorschlagen "Make it work, make it fast, make it nice", aber prinzipiell bin ich da auch bei dir. Du hast Beispielcode von Allwinner erwähnt. Wo hast du den gesehen?
Kennt jemand noch andere Anwendungen die den HW-Deinterlacer vom disp-Treiber verwenden? Dann könnte man dort ja evtl. etwas abgucken.
Hallo Andreas,
ich würde vorschlagen "Make it work, make it fast, make it nice", aber prinzipiell bin ich da auch bei dir. Du hast Beispielcode von Allwinner erwähnt. Wo hast du den gesehen?
z.B. hier
Kennt jemand noch andere Anwendungen die den HW-Deinterlacer vom disp-Treiber verwenden? Dann könnte man dort ja evtl. etwas abgucken.
Nicht wirklich. Alle cedarx samples, die ich im Netz ausfpüren konnte, sind gleich oder ähnlich dem o.g. Beispiel.
Auch der wrapper libcedarx holt sich die Information aus vpicture_t.
Möglicherweise was interessantess habe ich hier gefunden. Der Code ist zwar für den A80, aber in disp_video.c wird "cur_maf_flag_addr" und "pre_maf_flag_addr" übergeben. Der Speicher dafür wird in der "disp_video_init()" reserviert. Aber irgendwer muss den ja füllen... Ich denke, darum kümmert sich die VE.
Die Speichergröße für flag_addr beträgt im Beispiel:
static __u32 maf_flag_mem_len = 2048*2/8*544*2
Der Stride wird so berechnet:
maf_linestride = (((scaler->src_win.width + 31) & 0xffffffe0)*2/8 + 31) & 0xffffffe0;Ich bin gerade mit Allwinner wegen MAF in Kontakt. Eine Antwort kam schon, allerdings ist noch nicht alles geklärt. Mal sehen, vielleicht gibts hier Aufklärung.
Gruß Andreas
Ich habe die MAF-Beispiele mal blind übernommen und geguckt was passiert:
video.flag_addr = maf_flag_mem + 0x40000000; // convert to bus address
video.flag_stride = (((layer_info.fb.size.width + 31) & 0xffffffe0)*2/8 + 31) & 0xffffffe0;
video.maf_valid = 1;Wenn man eine der drei Variablen ändert, sehen die Kammartefakte jedes Mal anders aus. Mal sind sie nur in Flächen zu sehen, mal als Klötzchen auf dem ganzen Bild und mal als vertikale Streifen über die ganze Höhe.
maf_flag_mem habe ich mit malloc und nicht mit kmalloc alloziert, da wir ja im user-space sind. Wenn man eine "Müll"-Adresse in video.flag_addr schreibt, schmiert er nicht ab. Das wäre ein Indiz dafür, dass er nur lesend auf diesen Bereich zugreift, wir ihn also füllen müssten...?
Ich bin gerade mit Allwinner wegen MAF in Kontakt. Eine Antwort kam
schon, allerdings ist noch nicht alles geklärt. Mal sehen, vielleicht
gibts hier Aufklärung.
Das klingt erfreulich!
Ich habe die MAF-Beispiele mal blind übernommen und geguckt was passiert:
Codevideo.flag_addr = maf_flag_mem + 0x40000000; // convert to bus address video.flag_stride = (((layer_info.fb.size.width + 31) & 0xffffffe0)*2/8 + 31) & 0xffffffe0; video.maf_valid = 1;Wenn man eine der drei Variablen ändert, sehen die Kammartefakte jedes Mal anders aus. Mal sind sie nur in Flächen zu sehen, mal als Klötzchen auf dem ganzen Bild und mal als vertikale Streifen über die ganze Höhe.
maf_flag_mem habe ich mit malloc und nicht mit kmalloc alloziert, da wir ja im user-space sind. Wenn man eine "Müll"-Adresse in video.flag_addr schreibt, schmiert er nicht ab. Das wäre ein Indiz dafür, dass er nur lesend auf diesen Bereich zugreift, wir ihn also füllen müssten...?
Der reinen Bezeichnung nach könnte der Inhalt evtl. im Register 0x0040 der VE abgeholt werden. Damit da was steht, muss wahrscheinlich mindestens noch was in MACC_VE_MAF_CTRL gesetzt werden. Und evtl. noch in weiteren Registern ...
Es gibt im Libve User Guide einen vconfig_t parameter namens "use_maf", der sehr verdächtig dafür zuständig zu sein scheint. Ein weiterer Weg wäre daher, übers reverse engineering herauszufinden, was der cedar-blob mit den Registern anstellt, wenn use_maf gesetzt ist. Dann könnte man die fehlenden Register auslesen und evtl. sogar zuordnen.
Das war die erste Antwort von Allwinner:
maf: motion adapt flag, which indicate the specified block of video frame is still or not.
flag_addr： maf buffer address, available when maf_valid is true.
flag_stride：maf buffer address linestride, available when maf_valid is true
maf_valid: indicate if there is motion adapt flag(maf) buffer.
pre_frame_valid: indicate if the pre_frame is available for de-interlacer. de-interlacer could do better if pre_frame is available(using two frame)bob mode: when maf_valid and pre_frame_valid are both false
maf bob mode: when maf_valid is true and pre_frame_valid is false
maf mode: when maf_valid and pre_frame_valid are both true.maf > maf bob > bob (effect)
Technisch machbar sollte es sein....
Gruß
Andreas
Don’t have an account yet? Register yourself now and be a part of our community!