Archiv Sound, Video, MP3 und Co 8.736 Themen, 38.491 Beiträge

Verfolgung starten Optionen

AVI - eine theoretische Frage

Promille2 / 13 Antworten / Baumansicht Nickles

Hallo zusammen, ich bins mal wieder zum Thema "Videobearbeitung" (hoffe, ich nerve euch nicht langsam aber das Thema ist für mich recht kompliziert). Wenn ich etwas capture, kann ich es ja aus Platzgründen codieren (z.B. mit DIVX). Angenommen ich habe eine große Festplatte und ca. 40 GB nur für Filmbearbeitung. Ist die Filmqualität besser wenn ich dann die AVI-Datei unkomprimiert habe als wenn sie mit DIVX komprimiert wurde. Merkt man das einer daraus entstandenen VCD an, oder tut sich da nix in der Bildquali? Verstanden? Danke!

Simboy Promille2 „AVI - eine theoretische Frage“
Optionen

eine unkomprimiertie datei ist qualitativ natürlich besser (ausser mit lossless o.ä. codecs).ABER: benötigt viel platz. ob du bei ner VCD was merkst oder nicht, hängt davon ab mit welchen einstellungen du aufnimmst und evtl. noch vom mpegenc. wirst aber imo keinen grossen unterschied merken

martinh29 Promille2 „AVI - eine theoretische Frage“
Optionen

Einen qualititiven Unterschied sollte man schon bemerken. Besser als lossless-Codecs (ca. 2:1) oder unkomprimiert (1:1) sind aber MJPEG (3:1 - 15:1) oder DV-Codecs (ca. 5:1). Hier ist zwar die Komprimierung verlustbehaftet, aber das Ergebnis ist trotzdem besser als mit DivX, und man braucht weniger Platz.
Nach der Umwandlung zu VCD besonders aber zu SVCD ist der Unterschied schon zu sehen, würde ich sagen.

Minesweeper XL martinh29 „Einen qualititiven Unterschied sollte man schon bemerken. Besser als...“
Optionen

@Martinh29 - bloß nicht MJPEG... Es ist kein ordentlicher Standard(ist der Vorgänger von MPEG) und zeigt, da er das Bild nicht in Macroböcke einteilt, einen starken Drang zum "Einschwingen" (also nach einem harten Schnitt schwankt die Bildqualität).

mr.escape Minesweeper XL „@Martinh29 - bloß nicht MJPEG... Es ist kein ordentlicher Standard ist der...“
Optionen
Es ist kein ordentlicher Standard(ist der Vorgänger von MPEG) und zeigt, da er das Bild nicht in Macroböcke einteilt, einen starken Drang zum "Einschwingen" (also nach einem harten Schnitt schwankt die Bildqualität).
Hä? Was haben macroböcke mit folgenden bildern zu tun?
MJPEG kodiert jedes bild einzeln und unabhängig. Das ist der riesen vorteil beim schneiden und spulen! Es ist so eine art highspeed jpg encoder (braucht aber etwas mehr platz als ein gleich gutes standard jpg, eben speed und nicht platz optimiert). Wenn das rohmaterial kein schwanken hat, pumpt da gar nix, egal wie krass die schnitte sind. Das schwanken der bildqualität tritt hingegen bei formaten mit deltaframes auf, wenn bei schnitten nicht automatisch ein keyframe gesetzt wird (und das ist eben auch nichts anderes als eine art jpg)!
Eine alternative zu mjpeg ist huffyuv. Ebenfalls ohne deltaframes

mr.escape
Minesweeper XL mr.escape „ Hä? Was haben macroböcke mit folgenden bildern zu tun? MJPEG kodiert jedes...“
Optionen

Macroblöcke werden bei MPEG gebildet anstatt wie bei JPEG (bzw. seine einfache Erweiterung MJPEG) der das komplette Bild mittels der DCT in den Frequenzbereich überträgt. Stellt nun der Encoder fest, daß das codierte Bild größer ist als der vom User maximal vorgegebene Wert für die Bitrate, regelt er die Qualität des gesamten folge Frames deutlich runter. Daraufhin wird erkannt das das codierte Ergebniss von Frame2 noch einiges an Reserven gegenüber der vorgegebenen Bitrate zur Verfügung hat und das komplette 3.Frame wird schwächer codiert. Dieser Vorgang zieht sich über weit mehr als 3 Frames und kann als Einschwingvorgang bezeichnet werden.
MJPEG kann also immer nur die Stärke der Codierung (größe der Werte in der Quantisierungstabelle) für das gesamte Bild regeln.
MPEG hingegen teilt das Bild in Blöcke auf. Die Quantisierung (stärke des Kompressionsgrades) erfolgt nun auf jeden Macroblock. Somit schwankt die Bildqualität nicht in dem Maße wie bei MJPEG.

>>braucht aber etwas mehr platz als ein gleich gutes standard jpg, eben speed und nicht platz optimiert. Das "Hä" dahinter erspar ich mir.
MJPEG steht für Motion (Bewegung) JPEG. Es handelt sich tatsächlich um das normale ".jpg"(ist nur die Kurzform von JPEG) mit einem Aufsatz für Bewegtbilder (Film). Der Grund warum .jpg (JPEG)kleiner sind ist nicht eine "speedoptimierung" sondern einfach der Fall, daß es sich um 1 Bild (auch Frame genannt) handelt.
Wenn Du eine geringe aber schnelle Kompression von Video haben willst, nimmst Du einfach MPEG mit einer Quantisierungstabelle mit kleinen Werten und machst nur I-Frames (keine B- oder P-Frames).

Minesweeper XL

mr.escape Minesweeper XL „Macroblöcke werden bei MPEG gebildet anstatt wie bei JPEG bzw. seine einfache...“
Optionen

Hoppla, da habe ich wohl die typischen artefakte kacheln von jpg (und auch mpg) mit den verschiebeblöcken verwechselt, aber an meiner aussage ändert das nix (ausser der sache mit macroblock und folgebildern logischer weise).
Wenn die bitratenregelung zu schnell und/oder zu stark regelt (innerhalb weniger frames) und dadurch ins schwingen gerät ist dort mit den parameter etwas gewaltig falsch. Erstens, dass sie so schnell reagiert und nicht einige zig bis hunderte frames mittelt und zweitens, dass sie überhaupt die bitrate regelt, anstelle nur die fest eingestellte quantisierung anzuwenden und somit nicht das cbr oder abr sondern das vbr verfahren anzuwenden. Und selbst wenn man cbr oder wenigstens abr verwenden will ist das problem nicht der harte schnitt, sondern die komplexität der bilder, den was vor dem aktuellen frame oder danach kommt ist bedeutungslos (ausser indirekt für die bitratenregelung). Nur für die transformation der macroblöcke und die kompression der entstehenden differenzbilder spielen die zukünftigen und vergangenen bildinhalte eine rolle.

Der Grund warum .jpg (JPEG)kleiner sind ist nicht eine "speedoptimierung" sondern einfach der Fall, daß es sich um 1 Bild (auch Frame genannt) handelt.
Ein mjpg encoder wird sicherlich darauf getrimmt, seine 25-30 voll- respektive 50-60 halbbilder pro sekunde auch tatsächlich kodiert zu bekommen, als auf optimale qualität. Der lässt dort auch mal fünf grade sein (d.h. rechnet nicht unbedingt mit höchstmöglicher genauigkeit) um zeitig fertig zu werden, da solche fehler sowieso nur ein kleines temporäres rauschen bedeuten und nur im standbild richtig fies zu geltung kommen.

Wenn Du eine geringe aber schnelle Kompression von Video haben willst, nimmst Du einfach MPEG mit einer Quantisierungstabelle mit kleinen Werten und machst nur I-Frames (keine B- oder P-Frames).
Das ist doch (vom genauen format/standard abgesehen) vbr-mjpg. Da kann man auch keyframe-only-quality_based-divx nehmen, welcher besser ist, hängt wohl vom jeweiligen encoder ab bzw. wo man die parameter überhaupt so einstellen kann (bei mjpg und divx geht es, software mpg verwende ich wegen vorhandenem hardwareencoder (ohne einstellmöglichkeit) nicht).

mr.escape

Minesweeper XL mr.escape „Hoppla, da habe ich wohl die typischen artefakte kacheln von jpg und auch mpg...“
Optionen

>>Erstens, dass sie so schnell reagiert und nicht einige zig bis hunderte frames mittelt und zweitens, dass sie überhaupt die bitrate regelt.
1. Wenn die Reaktion über 100 Frames gezogen wird, hast Du das schwanken über einen größen Zeitraum. Mit den Frames mitteln ist so ne Sache wenn die Vorgabe Xkbit/s lautet und das erste Frame DEUTLICH drüber liegt und das zweite DEUTLICH drunter würde im Mittel zwar tatsächlich Xkbit/s eingehalten. Aber es ändert nichts an der Tatsache, daß das erste Bild nicht der Vorgabe entspricht.
2. Auch bei vbr muß der encoder "wissen" in welchen Grenzen er sich aufhalten soll (Bsp. SVCD). Aber richtig, man kann dem Einschwingvorgang damit erheblich entgegenwirken. Es kommt also jetzt in erheblichem Maße auf das Speichermedium an (Extremfall für cbr ist Band).

>>Und selbst wenn man cbr oder wenigstens abr verwenden will ist das problem nicht der harte schnitt, sondern die komplexität der bilder, den was vor dem aktuellen frame oder danach kommt ist bedeutungslos (ausser indirekt für die bitratenregelung).
Ja, sehe ich ein. Ich kenne jdf. keine "Version" von MJPG bei dem Prädiktion angewandt wird. Apropos "Version" genau das ist ja das Problem mit MJPEG. Wenn Du z.B. an einem Fast Schnittplatz ein MJPEG File erstellst kannst Du den aus lauter inkompatibilität nicht an einem Anderen Schnittplatz verwenden. Deswegen hat man sich ja auch hingesetzt und eine neue EPG (Expert Group) gebildet. Die Motion Picture Expert Group (die Mitmischenden Firmen sind im Prinzip die Gleichen wie auch bei JPEG). Die Gruppe hatte sich zum Ziel gesetzt endlich einen gemeinsamen Nenner für die Speicherung datenreduzierter digitaler Signale zu entwerfen: MPEG.
Für die Transformation der Macroblöcke in den Frequenzbereich spielt die vorgegebene Datenrate übrigens keine Rolle. Einzig und allein die Quantisierung entscheidet über den Reduktionsgrad. Das ist die Schraube an der "gedreht" werden kann.

>>Ein mjpg encoder wird sicherlich darauf getrimmt, seine 25-30 voll- respektive 50-60 halbbilder pro sekunde auch tatsächlich kodiert zu bekommen, als auf optimale qualität.
Ich will mal schwer hoffen, daß er es auf die Reihe bekommt den vorgegebenen an Bildern/sek zu erzeugen. Das sollte er auch mit einem 386er - gib him genügend Zeit. Aber auch MPEG schafft alle gängigen Vertikalfrequenzen ebenfalls auf einer langsamen Kiste - mit genügend Zeit. Ich nehme mal stark an Dir geht es um Echtzeitcodierung. Da darf es natürlich auch nicht zu dropped Frames bei der Codierung kommen. Und wen wunderts: MPEG, daß gegenüber MJPEG auch eine Prädiktion/Differenzbildübertragung der Bilder zulässt (und damit einen höheren Datenreduktionsgrad)wird in der Regel höhere Rechneranforderungen für Echtzeitcodierung mit sich bringen. - In der Regel. Deswegen die Variante mit dem "nur I-Frames". Außerdem haben doch fast alle die richtigen "Kisten" zum echtzeit MPEGII codieren.

>>Das ist doch (vom genauen format/standard abgesehen) vbr-mjpg.
Bis auf das es überall (Weltweit) von allen Geräten, die sich MPEGII decoder schimpfen abgespielt werden kann. Ich sehe das als signifikanten Vorteil.

>>Da kann man auch keyframe-only-quality_based-divx nehmen, welcher besser ist, hängt wohl vom jeweiligen encoder ab .
Naja, die MPEG hat sich inzwischen noch öfters getroffen und MPEG4 entwickelt. Zusammengefasst: Der Grad der Datenreduktion ist gestiegen und es gibt nicht allzu viele MPEG4 Standalone Geräte. DIVX ist nur der gehackte MPEG4 von Microsoft. Die übrigens auch in der MPEG sitzen und weil die anderen nicht auf M$ hören wollten hat M$ einen eigenen MPEG4 encoder rausgebracht. Der Rest der Gruppe kloppt sich gerne um Lizenzen...zurück zum Thema DivX hat braucht auch mehr Resourcen als MPEG2 für eine Echtzeitcodierung. Also keine wirkliche Altanative, wenn Dir MPEGII zu Resourcen fressend ist.

Neugierig wie ich bin würde ich jetzt nur noch gerne Wissen welchen Hardware MPEG Encoder Du verwendest. Zum Probieren mit den MPEG encodern empfehle ich TMPGEnc.

Gruß
Minesweeper XL

mr.escape Minesweeper XL „ Erstens, dass sie so schnell reagiert und nicht einige zig bis hunderte frames...“
Optionen

Bevor hier noch irgendwelche missverständnisse oder irritationen entstehen, muss ich noch klar stellen, dass meine argumentation vor dem hintergrund des threadkopfes zu betrachten ist, d.h. ausschliesslich das encoden beim capturen und die besonderheiten dabei (keine dropped frames und ressourcenschonung).
Dass als finales archivformat natürlich am besten eine multipass cinemacraft mpg2 dvd steht ist unbestritten (am besten von einer hochwertigen digitalen quelle, z.b. 3ccd profi dv cam, vom profi bedient, vom profi ausgeleuchtet etc.). Für reine pc anwendungen evtl. auch eine mpg4 variante mit allen schikanen (full res, ibp, qpel, gmc, keyframe detection, multipass vbr).
Beim capturen ist eine (ausreichend) niedrige cpu auslastung, hohe komprimierung, geringer qualitätsverlust und (als zwischenformat) eine leichte nachbearbeitung erforderlich. Die rollenverteilung zwischen cpu auslastung, komprimierung und qualität ist vom encoder und den vorhandenen ressourcen abhängig (cpu nicht zu weit unter 100%, man will ja nix verschenken), das fehlen von deltaframes aber fast schon zwingend für angenehmes schneiden erforderlich. Nur deshalb sollte ein (auch ohne weltweiten segen irgend welcher standardisierungsgremien) keyframe_only-quality_based-vbr format eingesetzt werden, wie z.b. huffyuv, mjpg, mpg(2) und mpg4-derivate mit entsprechenden parametern etc. Bei nicht zu extremen inhalten sollte auch die dateigrösse nicht zu grossen überraschungen führen, cbr ist aber in der regel nur nachteilig. Sobald das rohmaterial ausgetausch werden muss, sollte aber ein nicht zu exotisches format eingesetzt werden.
Als mpg2 hardware encoder benutze ich eine wintv-pvr-pci, die, sofern sie funktioniert, per s-video oder kabertuner ordentliche ergebnisse liefert. Die motivation für den einsatz war die aussicht auf minimale systembelastung bei absolut synchronem bild/ton (bei erträglichen 6mbit/s mpg2, 224kbit/s mp2, 704x576 kommen einige prozent cpu und 0.75MB/s festplatte zusammen und die hätte sich erwähnter 386 auch noch locker aus den rippen geleiert). Leider scheinen sich der via chipsatz (der berüchtigte kt133), eine sb-live und die pvr bezüglich der isochoren pci-bus verwendung nicht immer einig zu sein und da die pvr wohl viel zu wenig pufferspeicher hat verliert sie hin und wieder etwas von den kodierten mpg2 daten. Das ergibt dann schöne blockartefakte im bild und gezwitscher im ton. Ein zugesifftes win2k, extra usb2 karte (die auch nicht den ausschlag gibt, aber die sachlage noch verschärft) etc. machen die situation auch nicht besser. Das ausblenden des tv-fensters (wegen yuv/rgb pci-busmaster vom booktree in die graka) und die realtime priorität der tv-software erlauben aber meistens einwandfreie ergebnisse.
Wenn die in kürze anstehen migration auf nforce2 (bessere pci implementierung, keine extra netzwerkkarte, keine s-blive (verwende spdif), keine extra usb2 karte) die situation nicht bahnbrechend ändert, ist wohl der tausch gegen eine andere (vidac?) tv-mpg-karte fällig.

mr.escape

Minesweeper XL mr.escape „Bevor hier noch irgendwelche missverständnisse oder irritationen entstehen,...“
Optionen

>>Nur deshalb sollte ein (auch ohne weltweiten segen irgend welcher standardisierungsgremien) keyframe_only-quality_based-vbr format eingesetzt werden, wie z.b. huffyuv, mjpg, mpg(2).
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. Um an dieser Stelle auch nochmal auf die Ursprüngliche Frage drauf einzugehen:"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...
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.
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. Wozu sonst ein Hardwareencoder? 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.

Gruß
Minesweeper XL

Promille2 Minesweeper XL „ Nur deshalb sollte ein auch ohne weltweiten segen irgend welcher...“
Optionen

Hallo, auch wenn ich der fachlichen Diskussion nicht immer folgen konnte, sag ich mal "Danke".

mr.escape Minesweeper XL „ Nur deshalb sollte ein auch ohne weltweiten segen irgend welcher...“
Optionen
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
Minesweeper XL mr.escape „ Ich habe doch nur gesagt, dass das format solange es lokal bleibt und die...“
Optionen

>>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)!
Ja, bei MPEG4 hab ich auch keine Schnitterfahrungen gesammelt, aber MPEG 2 schneidet sich wie DV, wenn man keine Bildprädiktion (P-Frames. In beide Richtungen: B-Frames) zulässt. Deswegen red' ich mir ja den Mund so fusselig von I-Frames.

>>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.
Ich meine mal gehört zu haben daß die Karten Buszugriffe anfordern, denen dann vom zuständigen Controller die Erlaubnis erteilt wird oder nicht. Eine Zusage bedeutet für das System eine Unterbrechung (Interrupt) der bisher ausgeführten Aktion. Die höhe der Priorität entscheidet über zulassen oder nicht. Aber ich lasse mich in diesem Punkt gerne eines Besseren belehren. Ich glaub nur das wir hier anfangen zu nerven. ;)

@Promille2: Bitte

Gruß
Minesweeper XL

mr.escape Minesweeper XL „ Das schneiden vom mpg2/mpg4 mit deltaframes ist ein riesiger krampf, vorwärts...“
Optionen
Ja, bei MPEG4 hab ich auch keine Schnitterfahrungen gesammelt, aber MPEG 2 schneidet sich wie DV, wenn man keine Bildprädiktion (P-Frames. In beide Richtungen: B-Frames) zulässt. Deswegen red' ich mir ja den Mund so fusselig von I-Frames.
Da sagen wir doch das gleiche, formate ohne deltaframes (egal welche bezeichnung sie auch haben) lassen sich sauber schneiden. Die standardeinstellung bei mpg(2) (und die einzige, die ich an der pvr fahren kann) ist das aber nicht und damit wird das schneiden zur qual. Kann man den enkoder in den reinen i-mode versetzen ist alles in butter. Wie gesagt, bei meiner hardware ist so eine einstellung nicht möglich (oder extrem gut versteckt) und wie es um softenkoder bestellt ist weiss ich nicht, voreingestellt ist es aber sicher nicht und normale, nicht aufgeklärte user werden dort auch sicher nix verstellen.

Beim pci bus kann man soweit ich weiss nicht einzelne slots frei priorisieren sondern nur gemeinsam bzw über die anordnung. Ist mir aber inzwischen auch egal, das neue board hat hoffentlich nicht solche probleme.

mr.escape