MPEG-4 weiterentwickelt?

    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??

    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

    Matroska Guide - Encoden mit GordianKnot, VirtualDubMod im x264/Xvid Format *Update: 25.09.2005*

    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 mindern

    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)

    Ich meine hier keine KameraSCHWENKS sondern DIALOGSCHNITTWECHSEL

    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

    "Wer grundlegende Freiheiten aufgibt, um vorübergehend ein wenig Sicherheit zu gewinnen, verdient weder Freiheit noch Sicherheit."
    Benjamin Franklin

    mein Rechenknecht

    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 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.

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

    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=10177

    Selur - 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!

Benutzerkonto erstellen Anmelden