Motion search Bug beim CCE 2.62

[YUV 4 2 0]

Hallo allersteits,

dank Edwin van Eggelen's Link2 ist ja endlich möglich geworden den CCE 2.62 + AVISynth fast ohne Geschwindigkeitsverminderung und ohne theoretischen Qualitätsverlust zu verwenden. Mich würde interessieren, wie ich den um eine Zeile verschlechterten "Motion search Bug" beim CCE 2.62 ausgleichen kann. Wenn ich mir anschaue wie FitCD für den CCE 2.50 optimiert, so scheint man nur in der Höhe eine Zeile kleiner resizen und unten eine Zeile hinzufügen zu müssen.

Beispiel:
Quelle = PAL DVD, 720x576 Pixel, Anamorphic
Coded Film pixel: 714x570

Ziel SVCD:
Skript für CCE 2.50:
BilinearResize(448,414,13,3,694,570)
AddBorders(16,81,16,81)

Skript für CCE 2.62
BilinearResize(448,413,13,3,694,570)
AddBorders(16,81,16,82)

Ziel VCD:
Skript für CCE 2.50:
BilinearResize(336,222,36,3,648,570)
AddBorders(8,33,8,33)

Skript für CCE 2.62:
BilinearResize(336,221,36,3,648,570)
AddBorders(8,33,8,34)

Ist das richtig so?
_________________
Schönen Gruß,
YUV

[mb1]

Du brauchst doch nur "upper field first" deselektieren, um die Problematik zu umgehen.
Dann kannst du die CCE-Skripts (von FitCD) problemlos in jeder CCE-Version übernehmen.

Der aktuelle CCE-Patcher 0.3.0 trägt dir das im übrigen standardmässig in die Registry (und damit in die Templates) ein.

Und die neue CCE-Version (2.66 SP beta) soll ja jetzt schon standardmässig avs und vdr unterstützen. Dann brauchts auch kein Link2.
_________________
Grüße
mb1

Prophet Mohammed:
"Ein für den Wissenserwerb verbrachter Tag ist Gott lieber als 100 Kriege für Gott."

[YUV 4 2 0]

hallo mb1,

wow, die Antowort kam ja schneller, als ich meine Signatur editieren kann

[mb1]

Meine Antwort widerspricht shh´s Readme nicht

Beispiel:
Normalerweise resized man für einen 2,35-Film zu 320 Pixel vertikal (nur reines Filmbild).
Wegen der CCE-Eigenheiten resized man aber zu 318 Pixel (CCE-Bug activation in FitCD), also jeweils oben und unten eine schwarze Pixelzeile mehr.

Wenn man nun aber im CCE (egal in welche Version) "upper field first" aktiviert hat, so verschiebt de CCE zusätzlich das Bild um eine Pixelreihe nach oben.
Das heißt, die eine schwarze Pixelreihe, die extra eingefügt wurde wird oben wieder kompensiert und der "Bug" tritt erneut auf.

Also entweder man fügt oben noch eine zweite schwarze Pixelreihe dazu, oder man schaltet einfach "upper field first" aus.

Der Bug ist in allen Versionen identisch und hat sich nicht "verschlechtert" ;)
_________________
Grüße
mb1

Prophet Mohammed:
"Ein für den Wissenserwerb verbrachter Tag ist Gott lieber als 100 Kriege für Gott."

[shh]

YUV,
Deine oben angeführten resinzig-Methoden für den CCE 2.62 sind richtig.
- "upper field first" aus
- oben eine Zeile schwarz
- unten zwei Zeilen schwarz
(Man muß also wirklich das CCE-script editieren)
Für den CCE 2.50 muß man am FitCD-script nichts machen, da wird schon richtig resized (oben und unten je eine Zeile schwarz).

Leider kann man nicht alle Programmoptionen einbauen oder alle bugs auffangen; man weiß ja jetzt schon garnicht mehr was wichtig ist, bei den ganzen Knöpfchen.

mb1> Der Bug ist in allen Versionen identisch und hat sich nicht "verschlechtert"

Das stimmt leider nicht. Beim CCE 2.62 sinds unten schon ein pixel mehr. (habs selbst kontrolliert)
Wenn einem immer mehr vom Bild durch die motion-compensation weggeschnitten wird, wirft das natürlich die Frage auf, ob das überhaupt ein bug ist. :0
Wo das bei einem pixel noch sein kann (zB <= statt < verwenden), kann das bei 2 pixel eigentlich garnicht mehr sein. Da muß im code aktiv - geduldet - der film-pixel-Rand übergangen worden sein.
Vorstellbar ist es ja, daß die motion-compensation + die nötigen "Lösch"-blocks (die blocks, die Reste der macroblocks, die über den Rand hinausschießen, wieder schwarz machen - löschen) in bestimmten Situationen sogar effektiver ist, als blindes Beschneiden der motion-compensation auf sichtbaren Film. [was natürlich jede Menge neuer Fragen aufwirft]

Schönen Gruß
shh
_________________
shh >>> shh's MPEG-tools

[mb1]

Aha, was gelernt in Bezug auf den CCE 2.62 (hat´s der 2.64 auch ?)

Allerdings sitz ich grad etwas auf der Leitung:
Wenn das Bild um 1 Pixel nach oben verschoben wird bei "upper field first" an, dann muss doch oben auch noch eine Pixelreihe dazu (und unten dann im Prinzip 3 Reihen, statt 2).

Das gilt natürlich nur bei "upper field first" an, aber warum sollte man das überhaupt noch anmachen, da es ja nicht "gebührend" berücksichtigt wird.

Bei "upper field first" aus dann so wie shh sagte !

Wenn aber der CCE tatsächlich so makroblockübergreifende motion compensation hat, dann stellt das doch tatsächlich ein herausragendes Feature dar (v.a. innerhalb des reinen Bildes).
Evtl. Nachteile an den Bildrändern am Schwarzübergang hat Custom Technology dann vielleicht bewußt in Kauf genommen (falls es tatsächlich Nachteile sind, wie du schon sagtest).

Muss ich vielleicht doch mal wieder mein Mpeg-Repair anschmeißen (1.593 oder so, gibt´s da schon was neueres, vielleicht mal eine 2.0 ?).

Gut, daß ich meine 4:3 DV-avis immer schon so behandle:
720x576 -> clip 712x572 -> resize auf 672x540 oder 448x540 oder 336x540.
Da hab ich das ja mal wieder intuitiv ;) richtig gemacht. Aber eigentlich nutze ich ja Tmpeg ;)

Bei interlaced Material sollte man übrigens besser nicht auf ungerade reine Bildhöhen resizen !
_________________
Grüße
mb1

Prophet Mohammed:
"Ein für den Wissenserwerb verbrachter Tag ist Gott lieber als 100 Kriege für Gott."

[YUV 4 2 0]

Hallo,

puh, ich dachte schon ich hätte mir nur eingebildet so was mal gelesen zu haben

Danke für Eure Antworten ;)

shh schrieb:

[shh]

> Wenn das Bild um 1 Pixel nach oben verschoben wird bei "upper field first" an, dann muss doch oben auch noch eine Pixelreihe dazu (und unten dann im Prinzip 3 Reihen, statt 2).

Oben wird letzlich eine Zeile abgeschnitten, unten eine schwarze Zeile eingefügt.
(Vielleicht hat das ja irgendwie mit dieser CCE-field-Tausch-Kuriosität zu tun)

> Ich verstehe nicht, warum es ein Feature sein soll zunächst Bits im schwarzen Bereich zu verschwenden um selbige danach wieder zu löschen

I.a. ist sowas wohl auch schlecht.
Durch die motion-compensation wird in anderen Bereichen (den "film-pixeln") aber *erheblich* bits gespart.
Vielleicht "sagt sich" der CCE:
Lieber durch motion-compensation in 16 Zeilen (weil ja macroblock basiert) jede Menge einsparen. Mit den eingesparten bits kann man die Reste im schwarzen Rand locker wieder ausgleichen.
Da der CCE das aber auch nicht immer macht, bzw nicht mit allen macroblocks, scheint eine Taktik dahinter zu stecken.

> das jedes von FitCD, für den CCE optimierte Ausgangsmaterial vom Resizing her falsch ist

Gottseidank nicht total falsch. Höchstens um 2 pixel.
Aber ja, das wäre dann falsch, weil der CCE das anscheinend besser weiß. Außer bei Leuten, die kein Gekräusel im schwarzen Rand haben wollen wäre das resizing noch richtig.
Ich glaube mich aber daran zu erinnern, daß ich bei einigen Tests doch merkbare Verbesserung bei einem speziellen CCE-resizing festgestellt habe.
Das sind aber alles nur Theorien, und leider weiß ich nicht, wie ich so etwas analysieren könnte...
Vielleicht ist's ja wirklich nur ein bug. ;)

Schönen Gruß
shh
_________________
shh >>> shh's MPEG-tools

[YUV 4 2 0]

Hallo,

>Ich glaube mich aber daran zu erinnern, daß ich bei einigen Tests doch merkbare Verbesserung bei einem speziellen CCE-resizing festgestellt habe.
Das muß genügen, also wird das Skript für den CCE 2.62 angepaßt

>Vielleicht ist's ja wirklich nur ein bug.
Hat der CCE 2.64 oder 2.66(Beta) den selben ähm...vielleicht Bug? Wenn höhere Versionen das nicht mehr machen, so ist mit hoher Wahrscheinlichkeit anzunehmen, daß es wirklich nur ein Fehler war.
_________________
Schönen Gruß,
YUV