Beiträge von FatFaster

Also Ich hab auch mal Vobs von so einer Cam mit PVAStrumenro demuxt, allerding gab es danach ruckler im Video (Keine Ahnung warum). Aber mit DVDLab hat das demuxing wunderbargeklappt

Sag ich doch

bei mir lag es aber wirklich am Script. Ich musste was dazu schreiben damit´s richtig funktioniert.

thick = yv12lutxy(c, exin, yexpr="y "+lum+" < y "+lum+" ? x "+thr+" + > x y "\		+lum+" < y "+lum+" ? - 0 ? "+str+" * x +",uexpr="x",vexpr="x")	thin = yv12lutxy(c.expand(),diff,yexpr="x y 127 - "+str+" 1 + * +")	return (thinning == 0) ? thick : maskedmerge(thin,thick,linemask,y=3,u=2,v=2)

thick = yv12lutxy(c, exin, yexpr="y "+lum+" < y "+lum+" ? x "+thr+" + > x y "\
		+lum+" < y "+lum+" ? - 0 ? "+str+" * x +",uexpr="x",vexpr="x",[B]u=2,v=2[/B])
	thin = yv12lutxy(c.expand(),diff,yexpr="x y 127 - "+str+" 1 + * +")
	return (thinning == 0) ? thick : maskedmerge(thin,thick,linemask,y=3,u=2,v=2)

Versuchs mal mit

tfm().tdecimate(mode=1)
converttoyuy2().pixiedust(3).ConvertToYV12()
fft3dfilter(sigma=1)

evtl. noch leicht schärfen, musst du selber gucken.

Nein das Bild wird grün bleiben. Probier das mal:

######################
# FastLineDarken 1.3 #
######################
#
# Written by Vectrangle, last update 12 Sept 04
#
#  * requires masktools 1.5.1 -- http://jourdan.madism.org/~manao/
#  * requires yv12 input
#
# Usage is FastLineDarken(strength, luma_cap, threshold, thinning),
#   named parameters are supported eg FastLineDarken(thinning=0)
# 
# Note that you must import this avs into your script using import("...\FastLineDarken 1.3.avs")
#
# Parameters are:
#  strength (integer)  - Line darkening amount, 0-256. Default 48. Represents the _maximum_ amount
#                        that the luma will be reduced by, weaker lines will be reduced by
#                        proportionately less.
#  luma_cap (integer)  - value from 0 (black) to 255 (white), used to stop the darkening
#                        determination from being 'blinded' by bright pixels, and to stop grey
#                        lines on white backgrounds being darkened. Any pixels brighter than
#                        luma_cap are treated as only being as bright as luma_cap. Lowering
#                        luma_cap tends to reduce line darkening. 255 disables capping. Default 191.
#  threshold (integer) - any pixels that were going to be darkened by an amount less than
#                        threshold will not be touched. setting this to 0 will disable it, setting
#                        it to 4 (default) is recommended, since often a lot of random pixels are
#                        marked for very slight darkening and a threshold of about 4 should fix
#                        them. Note if you set threshold too high, some lines will not be darkened
#  thinning (integer)  - optional line thinning amount, 0-256. Setting this to 0 will disable it,
#                        which is gives a _big_ speed increase. Note that thinning the lines will
#                        inherently darken the remaining pixels in each line a little. Default 24.
#
# Changelog:
#  1.3  - added ability to thin lines, now runs much slower unless thinning=0. Changed the defaults (again)
#  1.2  - huge speed increase using yv12lutxy =)
#       - weird darkening issues gone (they were caused by yv12layer)
#       - show option no longer available due to optimizations. Use subtract() instead
#  1.1  - added luma_cap option
#  1.0  - initial release
#




function FastLineDarken( clip c, int "strength", int "luma_cap", int "threshold", int "thinning") {
	str = string(default(strength, 48) /128.)
	lum = string(default(luma_cap, 191))
	thr = string(default(threshold, 4))
	thinning = default(thinning,24)
	thn = string(thinning /16.)
	exin=c.expand().inpand()
	diff = yv12lutxy(c,exin,yexpr="y "+lum+" < y "+lum+" ? x "+thr+" + > x y "\
		+lum+" < y "+lum+" ? - 0 ? 127 +",uexpr="x",vexpr="x",u=2,v=2)
	linemask = yv12lut(diff.inpand(),"x 127 - "+thn+" * 255 +")\
		.yv12convolution("1 1 1","1 1 1",y=3,u=0,v=0)
	thick = yv12lutxy(c, exin, yexpr="y "+lum+" < y "+lum+" ? x "+thr+" + > x y "\
		+lum+" < y "+lum+" ? - 0 ? "+str+" * x +",uexpr="x",vexpr="x",u=2,v=2)
	thin = yv12lutxy(c.expand(),diff,yexpr="x y 127 - "+str+" 1 + * +")
	return (thinning == 0) ? thick : maskedmerge(thin,thick,linemask,y=3,u=2,v=2)
}

[Blockierte Grafik: http://img441.imageshack.us/img441/3118/blocking5wd25sc.png]

hab fft3dfilter(sigma=2) und seesaw() dazugepackt und die blöcke sind wech.
Ich weiß aber nicht, wie der Sand dann in Dune aussehen würde

Ah da ist ja noch ne m2v-Datei *schnell runterladen^^*

Aber auch nur zu Anfang. Die Zahl 99999999999 wäre ja auch richtig gewesen :ani_lol:

Oh hab das Rätsel schon ganz vergessen :zunge:

Die Lösung ist ganz einfach. Die richtige Begründung wäre:
Die nächste Zahl muss einfach nur größer als die vorherige sein :ani_lol:

NVIDIA bald mit H264 Encoding wäre mir lieber

Der wird nicht im Kino laufen. Denn wirds nur auf DVD geben.
Komisch auf Amazon steht: Voraussichtlicher Erscheinungstermin: 7. Februar 2006. Aber nur Final Fantasy VII - Advent Children (UMD Mini für PSP) -.-

Das Burning Board Lite müsste es auch kostenlos zu download geben.

http://www.woltlab.de/products/burning_board_lite/index.php

Das einzige "gute" kostenlose Forum was ich kenne ist PHPbb. Zusätzlich gibt es noch tausende von Hacks dafür, mit denen man das Forum erweitern kann

Zitat

Filmlänge anhand der Frameanzahl berechenbar?

Ja klar:

wenn du einen Film hast der 135000 Frames hat, dann sind das:

135000 / 25 = 5400sek (25 natürlich nur bei PAL)
5400sek /60 = 90 min

135000 Frames = 1 stunde 30 min

Zitat

Warum, machste das filtern nicht auf den langsameren Kisten und das Encoden auf der Dualkiste?

hmm weiß nicht? Muss ausprobieren wie rum es schneller ist

Das könnte es natürlich sein :ja:
Hmm, ich hab noch einen 1GHz Rechner. Mit diesem könnte man diese Verzögerung doch umgehen!? Die beiden schnelleren PCs schicken ihre Daten zum 1GHz Rechner und dieser encodet nur. Jetzt muss ich mir nur noch ein zweites Netzwerkkabel besorgen um das mal zu testen

Aber es ist doch trotzdem sehr merkwürdig, dass die CPU Anzeige bei 35% ist.
Wenn ich mit Vdub "normal" encode, dann steht Die CPU auf 100%. Aber wenn ich in Vdub das Video + TCP öffne dann und an den anderen PC schicke, dann kommen keine 100% zustande. Woran könnte es denn dann liegen? An TCP?

Zitat

Portable Geräte wie handys

Dann kannst du x264 vergessen. Die decoding Anforderungen wären dann wohl zu hoch. Aber wie gesagt mit ein paar Filtern könntest du die Quali etwas erhöhen (lies dir einfach mal ein paar Beiträge im Forum durch). Bedenke aber je schärfer das Bild desto schlechter lässt es sich komprimieren! :ja:

Bei niedrigen Bitraten ist x264 besser als Xvid oder Divx. Mit ein paar Avisynth-Fltern kann man bestimmt die kompressionsfreudigkeit der Videos noch ein wenig erhöhen, was dann eine bessere Qualität bei gleicher Datenrate liefert.

Habs zum laufen gebracht, jedoch habe ich wenn überhaubt gerademal einen Geschwindigkeitsschub von 1 Frame gehabt.

So wie ich das jetzt verstanden habe, schickt PC A(TCPServer ), die in AVisynth fertig gerenderten Bilder, zum PC B(TCPsource). Dieser muss sie nur noch encoden!? Liege ich da richtig?

Allerdings müsste es so ja auch nicht viel bringen:
PC A - schickt daten
v = mpeg2source("video.d2v").crop.resize.smoothen. .... . sharpen
TCPServer(v, 113)

PC B - encodet
TCPSource("192.168.0.10",113)

Bei diesem Script hängt die Geschwindigkeit ja allein davon ab, wie schnell PC A die Datein in AVIsynth rendert und sie anschließend rüberschickt.

Edit:
So, hab ein wenig weiter experementiert
Diesmal habe ich das so verwirklicht, wie ich es schon von Anfang an wollte.

PCA
v = mpeg2source("video.d2v").crop.resize.smoothen
TCPServer(v, 113)

PCB
TCPSource("192.168.0.10",113,"LZO")
v = v..... . sharpen
TCPServer(v, 114)

PCA
TCPSource("192.168.0.11",114,"LZO")

PC A hat einen Dualcore Prozessor. Jedoch waren bei beiden PCs (A und B) die CPU Auslastung bei ~35%.
Was ich sehr komisch finde. Die Encoding-Geschwindigkeit hat sich dementsprechend nur sehr wenig erhöht.
Es gab aber kurzzeitig Phasen bei dem die CPU Auslastung bei 100% (besser gesagt 50% beim Dualcore) und die Frames/s schossen von 3-4 auf 6-7 frames/s. Die Netzwerkauslastung lag bei unter 10%
Meine Vermutung ist, dass Windoofs TCP irgendwie nicht "ersnt" nimmt und so nicht genügend Prozessorleistung rausrückt.

Bis jetzt ist die Zahlenreihe richtig.
Kleiner Tip. Nicht zu Mathematisch denken