Alleine dieser "Segen" überall zu laufen ist es schon Wert mpg (2) mit nur I-Frames statt mjpg einzusetzen. Ich werde doch wohl ein Interesse haben, daß mein Material überall abspielbar bleibt.
Ich habe doch nur gesagt, dass das format solange es lokal bleibt und die bedürfnisse erfüllt egal ist (Sobald das rohmaterial ausgetausch werden muss, sollte aber ein nicht zu exotisches format eingesetzt werden. d.h. etwas genormtes!). Wenn ein vorhandener soft mpg(2) encoder, den man auch noch in den reinen i-frame mode versetzen können muss, bessere resultate liefert als ein mjpg oder huffyuv oder keyframe-vbr-divx, dann in gottes namen. Ich jedenfalls habe alle genannte softcodecs ausser mpg(2) (da gibt es halt die hardware) und glaube dass noch ein format überflüssig ist, da genug funktionierende alternativen zur verfügung stehen. Weitergeben will ich die rohdaten eh nicht und das endergebnis wird dann natürlich normgerecht.
"Merkt man das einer daraus entstandenen VCD an, oder tut sich da nix in der Bildquali? Verstanden? Danke!" MPEG Material wird nachgesagt kein Generationen Problem zu haben...
Als material für die weiterverarbeitung ist keyframe-only unkomprimiert/verlustlos/verlustarm immer besser als die normalen deltaframe-verlustbehafteten, wobei dort die parameterwahl eine waffengleichheit herstellen kann. Hängt alles von der soft- und hardwareausstattung ab. Über generationskonflikte bei mpg weiss ich nix, aber besser wird dadurch jedenfalls sicher nichts und es sollte ja auch nur genau eine generation dazukommen, die finalversion.
Bei mir ist MPEG (2 bzw. 4) meißt nur Ausgansmaterial. Schneiden kann man damit zwar auch prima, aber da mein Eingangsmaterial DV (ist übrigens cbr) basierend ist, mach ich mir nicht die Mühe das erst in ein anderes Format zu konvertieren.
Das schneiden vom mpg2/mpg4 mit deltaframes ist ein riesiger krampf, vorwärts spulen geht ja noch, aber springen oder gar bildweise rückwärts ist reine folter (besonders bei mpg4)! Wen das beim schneiden nicht stört, hat entweder ein sehr ruhiges gemüt und sehr viel zeit oder ist profimasochist (alternativ besitzer einer höllenmaschine mit unglaublich power). Dass DV cbr ist, ist leicht nachzuvollziehen, denn pufferspeicher für abr wäre viel zu teuer und echtes vbr geht wegen der mechanischen (bandtransport) aufzeichnung nicht. Da die kompression nur ganz schwach ist, ist das auch nicht tragisch. Das konvertieren in ein anderes format brächte ja auch nur nachteile mit sich (höherer speicherverbrauch, dauer der umwandlung, qualitätsverluste, bei formaten mit deltaframes ärger beim schneiden usw.).
Bei dem HW-Encoder Problem kann ich Dir von daher nicht groß weiterhelfen. Wie schon gesagt damit die Busverwendung der pvr nicht isochor ist, bräuchte sie einen ordentlichen Speicher. Aber ich weiß nicht, ob das der Weisheit letzter Schluß ist. Eigendlich sollte man alle möglichen Aktionen Paralell zum Capturen ausführen können. Jedenfalls sind alle Aktionen mit einem Buszugriff verbunden.
Danke, aber durch den hardwarewechsel hoffe ich mir selber zu helfen. Der buszugriff der pvr muss im weiteren sinne isochor sein, denn die daten kommen unbarmherzig an und müssen übertragen werden. Da der pci bus von vielen übertragungswilligen beansprucht wird führt es zu kurzzeitigen überlastungen und die eigenart des via-chipsatzes, die burst-transfer viel zu früh abzubrechen sowie die (völlig sinnleere) angewohnheit der sb-live den bus zu belegen, bringen den (für diesen härtefall) zu kleinen pufferspeicher (ringspeicher) der pvr gelegentlich zum überlaufen. Der verdacht, dass window$ selbst zum schlamassel beiträgt, in dem die zu schreibenden daten lange im ram gehortet und dann auf einmal im xxl pack auf die platte geschrieben werden und dadurch zusätzliche hochlast auf den pci-bus kommt, lässt sich nicht erhärten, da dort ca. zwei mal pro sekunde ein bisschen geschrieben wird (deutlich weniger als der plattencache und damit blitz schnell). Die verfälschten daten sind aber blöderweise schon komprimiert und richten dadurch verheerende schäden am material an, währen die systemauslatung bei einigen prozent dahin dümpelt. Auch im booktree betrieb ist dieser effekt vorhanden (sogar viel schlimmer, da dort ca 22BM/s übertragen werden müssen und somit noch mehr konkurrenz entsteht) aber da werden bloss einige horizontale streifen aus dem letzten frame nicht aktualisiert (d.h. bei ruhigen bildern merkt man gar nix, nur bei schwenks, schnitten und ähnlich dynamischen situationen) und der ton läuft eh über die sb-live, die komischer weise keine probs hat.
Vielmehr die Frage: Warum nimmt sich die SB-Live das Recht den Bus so in Anspruch zunehmen, daß es zu den Artefakten kommt? Wenn es unter deinem Betriebssystem möglich ist die Intrrupt Priorität selbst zu setzten kannst Du die der SB-Live runtersetzen.
Tja, die sb-live ist eben ein schwein, ein "pci-busmaster-hog". Da das kein interrupt, sondern ein busmaster problem ist könnte auch eine prioritätenänderung an den interrupts nicht helfen, die karte überträgt "eigenmächtig" daten an der cpu vorbei über den pci-bus. Andere karten sollen da wesentlich sozialer sein. Auch einstellungen am chipsatz (buffer, waitstates, latency, pci/cpu priority etc.) helfen da nicht wirklich, aber wie gesagt, nforce2 soll es richten.
mr.escape
mr.escape
