ich hab mir mal mit Dr.Divx und mit Xvid die Encodiervorgänge am Beispiel
einer Stargate-Folge angesehen und bin zum Schluß gekommen, daß bei schnellen Kamerawechseln (Zwei Personen unterhalten sich - schneller und häufiger Wechsel von Gesicht zu Gesicht). Jedesmal speichern die Encoder
dabei einen Extra I-Frame (Key) ab. Also intelligenterweise müßte ein Encoder innerhalb eines bestimmten Bereiches die Keyframes vergleichen und feststellen können ob man sich bei schnellen Wechsel nicht "verlängerte B-Frames nehmen könnte oder zwei Stream nimmt zwischen denen umgeschaltet wird.. was meint ihr??
MPEG-4 weiterentwickelt?
-
-
hey!
dass da ein i-frame gesetzt wird ist insofern logisch, da die p-frames aus dem i-frames abgeleitet werden und bei schnellen bewegungen sich das bild nunmal sehr oft ändert...
die b-frames encoden noch stärker als die p-frames und wenn du dann weniger i-frames bei schnellen bewegungen hast nimmt die qualität ab (da das letzte i-frame ja komplett anders war)...
einleuchtend?
mfg
scrat -
das weiss ich ja... nur... ich probier das mal anders zu erklären...
Original: AaaaaaaaaaBbbbbbbbbAaaaaaaaaBbbbbbbbbbAaaaaaaaaBbbbbbbbbb
MPEG4: Aax.Bbx.Aax.Bbx.Aax.Bbx
meine Idee: Aax.Bbx.ax.bx.ax.bx
oder gleich: Aax.Bbx (mit Sprungsteuerung)
damit fallen diese Frames weg die enorm viel Speicherplatz verbrauchen
OHNE!!! die Qualität zu mindernDer Encoder muß dazu nur sagen wir mal Szenenwechsel innerhalb von 10-20 sek merken und die I-Frames vergleichen
Der Decoder muß nur angewiesene Frames merken die Bezugsquelle von B-Frames werden (kann er ja schon nur das diesmal die B-Frames nicht im Millisekundenbereich sondern im Sekundenbereich folgen)Ich meine hier keine KameraSCHWENKS sondern DIALOGSCHNITTWECHSEL
-
diese Idee kam mir auch schon vor einiger Zeit, nur wuerde sie
1) den encodiervorgang verlangsamen
2) den SPeicherbadarf waehrend des Playbacks enorm in die Hoehe treiben
3) inkompatibel zu AVI sein... -
Zitat von scharfis_brain
diese Idee kam mir auch schon vor einiger Zeit, nur wuerde sie
1) den encodiervorgang verlangsamen
2) den SPeicherbadarf waehrend des Playbacks enorm in die Hoehe treiben
3) inkompatibel zu AVI sein...zu 1) ein aktuelles I-Frame mit den letzten 3-4 I-Frames vergleichen
kann wohl nicht die große Bremse sein?
zu 2) wieso sich 3-4 Frames zusätzlich merken.. soll ich lachen ???
zu 3) B-Frames kann AVI ja sowieso nur mit einem HACK verarbeiten -
Zitat von DJ oSSi
meine Idee: Aax.Bbx.ax.bx.ax.bx
oder gleich: Aax.Bbx (mit Sprungsteuerung)Der Encoder muß dazu nur sagen wir mal Szenenwechsel innerhalb von 10-20 sek merken und die I-Frames vergleichen
Der Decoder muß nur angewiesene Frames merken die Bezugsquelle von B-Frames werden (kann er ja schon nur das diesmal die B-Frames nicht im Millisekundenbereich sondern im Sekundenbereich folgen)
lustige Idee. du willst sozusagen die länge einer GOP extrem vergrößern und es gleichzeitig aber ermöglichen, nach jedem Frame durch einen sprungpunkt die wiedergabe woanders fortzusetzen. mich deucht, das klingt mehr nach MPEG - The next generation. allerdings will mir abgesehen von deinem dialog beispiel der nutzen nicht recht einleuchten. ungeachtet dessen, daß die anforderungen an rechengeschwindigkeit und puffergröße enorm anwüchsen. ums mal vorsichtig auszudrücken.Zap
-
Die I-Frames sind nicht identisch. sie sind sich nur ähnlich.
AC-Chan(Robert Vincenz)
-
also bis jetzt machen die encoder doch folgendes:
JEDES FRAME (25fps) untersucht er auf Szenenänderung
und führt wegen Bitratenverteilung auch Buch darüber
doch plötzlich!! er stellt fest:
extrem sprungartige szenenänderung (AHA ein Schnitt) er meint:
Nagut machen wir ein I-Frame und codet munter weiter...mein Vorschlag:
Die Buchführung über die Szenenwechsel erhält eine kleine Extratabelle
mit den extremsten Ausschlägen der letzten 20 sek. dürfte
auf 90 min Film grade mal eine Sekunde Extraberechnung ausmachen.
er merkt sich 4 Timecodes (8 Byte reichen für 4 Timecodes)
er merkt sich 4 I-Frames (was verbraucht ein I-Frame?? 10KB?)
wieviele Frames von allen sind extreme Szenenwechsel? nicht mal 1%
das heisst das er zu unter 1% Fällen nicht zwei Bilder vergleicht sondern
eben 4 mal 2 Bilder vergleicht.
geschätztes Resümee: 1% langsamer, 5% bessere Komprimierung und
zusätzlicher Arbeitsspeicherbedarf von 500KB -
natürlich könnte man das optimieren indem man nicht die I-Frames vergleicht sondern das Bild vor Szenenwechsel A mit dem Bild nach Szenenwechsel B vergleicht
-
eine schwierigkeit worüber ich hier noch nicht nachgedacht habe ist.. MPEG4 ist ja für gute schneid und cutbarkeit ausgelegt worden... die verlustlosen cutter müssten unter umständen dann doch i-frames setzen wenn die szenenwechselreihenfolge sich ändert...
-
bei meiner idee könnte man sogar bei einem fertigen MP4-Film die Optimierung
hinzufügen... ein Collector sammelt alle I-Frames und macht ein Ähnlichkeitsvergleich
und ersetzt dann evtl. I-Frames durch "spezielle B-Frames" solange sie nicht doch Keyframes bleiben sollen -
Du solltest deine Beitraege besser editieren, anstatt jedesmal einen Neuen zu verfassen.
-
oh sorry....
aber ich hab das ganze mal aufs Audio übertragen..
siehe http://forum.gleitz.info/showthread.php?t=10205 -
DJ oSSi: lies Dir mal AVC aka. h264 durch.
siehe: http://bs.hhi.de/~wiegand/JVT.html
vorallen den Draft (JVT-G050.zip)
und das Paper über CabacCu Selur
-
Du kannst ja mal einen Test von Hand machen und schauen, wie sich das auf die Kompression auswirkt:
Du baust dir ein avisynth Skript, dass in einem solchen Dialog die Einstellungen in einzelne Clips aufteilt und dann sortiert wieder aneinanderhängt.
Also anstatt dem Dialog A1B1A2B2A3B3A4B4 (A=Janeway B =SevenofNine)
in A1A2A3A4B1B2B3B4.
Dann encodest du beide Skripte mit konstantem Quantiser und vergleichst die Dateigrößen.
Zum abspielen musst du dir dann halt wieder ein Skript bauen, dass die einzelnen Einstellungen wieder richtig hinsortiert.
Zum anderen könnte ich mir vorstellen, dass das einiges an Overhead ergibt, wenn du immer noch angeben musst, auf welches I Frame sich das entsprechende P oder B Frame bezieht.
Und der Vorteil wäre wieder nur in ganz speziellen Fällen wirklich groß, nämlih bei Dialogen mit vielen Einstellungswechseln. -
wie soll ich die beiden versionen per Größe vergleichen können?
in der modifizierten version würde der encoder die eingesparten
KBs der I-Frames ausgleichenderweise dafür nutzen höhere
Qualität woanders zu erhalten... und dafür ist meine Idee
im eigentlichem Sinne ja auch gedacht gewesen...
nur wenn man von einem MP4-File (ein fertiges) die I-Frames
oder die Frames vor den I-Frames zu einem eigenem kleinem Film zusammenstellt
kann man die unkomprimierte (MJPEG) mit der als MPeG4 komprimierte I-Film vergleichen.. -
Kopernikus hat doch geschrieben das du einen festen Quantiser verwenden sollst. Daher kann sich nur die Dateigroesze, nicht aber die Qualitaet aendern.
-
alles klar ... ich kenn mich aber weder mit avisynth aus noch hab ich je an quantizer oder matrizen rumgefummelt... ich benutze GraphEdit und VirtualDub ab und zu..
und naja schnippeln tu ich inzwischen mit Nero Vision Express... und schlag mich sonst mit Dr.Divx und Recode rum....
siehe http://forum.gleitz.info/showthread.php?t=10177Selur - Willst du mich jetzt mit einem englischsprachigem Kompendium erschlagen dessen Inhaltsverzeichnis in kleiner Schrift 11 Seiten umfaßt??
Aber ich hab mal weiter überlegt...
man könnte den Videostream in z.B. zwei Streams aufsplitten
und außer bei dualen Szenenwechsel alles in 100% Schwarz halten
oder das Bild vor dem I-Frame als Standbild erhalten...
so würde man den Prozeß auch verstehen können.
Zumal MPEG-4 auch mal zu interaktiven Inhalten herhalten soll. -
Ich hab es jetzt mal ausprobiert.... hab grade mal 1,5 % größenverringerung erhalten..
nun waren das nur die I-Frames.. müsste das nochmal mit den frames VOr den I-Frames probieren.... vielleicht dann 2%... bei einem 700MB Video sind es dann immerhin 14MB... Credits und Vorspänne wegcutten bringt nochmal 5%... 35MB
AC3 in HE-AAC wandeln bringt nochmal 100MB .. hätten wir aus nem 700MB 550MB gemacht... ist ne Menge Spielraum für Qualitätserhaltungen, wenn man eine DVD in eine CD wandeln will... -
DJ oSSi: wenn Du gelsen hättest was ich da gelinkt habe, dann wüssteste was in h264 geplant/möglich ist udn inwieweit, deine Idee 'neu' ist.
Außerdem sollteste mal generell nachlesen was in den einzelnen, zum großen Teil noch nicht implementierten Mpeg4 Videoprofiles möglich/geplant ist.
Cu Selur
-
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!