> > Der Witz der GMC ist, dass durch die global motion estimation man
> > eben massiv Bandbreite spart.
> Das gerade nur dann, wenn das Material und die Encoder-Umgebung paßt.
> Zuerst einmal sind S-Frames im GMC-Fall lediglich als Ersatz bzw.
> Erweiterung zu P-Frames einsetzbar. Dazu kommt pro Bild ein
> Satz von globalen Verzerrungskoordinaten plus 1 Bit PRO Makroblock.
> Die GMC muß demnach passende Parameter erwirtschaften, um überhaupt
> für hinreichend viele Makroblöcke einen adäquaten Ersatz der
> lokalen Bewegungsvektoren darstellen zu können. Quintessenz: das
> Material muß passen (z.B. Kameraschwenks, Zoom, Rotation usw.).
Nun ja - interessant waere es, wenn mit einem variablen Frameraster
gearbeitet wird. Sprich - man sieht die S frames nur dann, wenn es
auch was bringt (sonst halt p frames). Leider ist aber das format
eben pro film vordefiniert und kann nicht dynamisch geaendert werden
(soweit ich weiss).
Ich stimme dir ja zu, dass das GMC nicht immer etwas bringt - aber
meine Tests mit verschiedem Material lieferten durchweg bessere
Ergebnisse.
Sehen tut man es meistens trotzdem nicht, ausser man setzt die
Bandbreite extrem runter - und dann wirds doch recht offensichtlich.
Kann ich nur dazu raten - ich war mir auch nie ganz bewusst, wie viel
es bringt, bis ichs ausprobiert habe (mit verschiedenen sourcen).
Sicher mag es fuer einzelne Faelle halt auch Ausnahmen geben, aber
gross testen tu ich das Ausgangsmaterial heute nicht mehr.
Ich codier eigentlich alels mit saemtlichen optionen on und im 2-pass
verfahren.
> > B-Frames bringt dann noch mal zusaetzlich Bandbreite - da B-frames
> > die Frames sind, die am wenigsten brauchen.
> Auch der Gewinn von B-Frames hängt stark vom Material ab, da wiederum
> B-Frames signalisieren müssen, welches Referenzbild (von zweien) nun
> zur Prädiktion herangezogen wird. Die Referenzbilder liegen darüber
> hinaus zeitlich recht weit auseinander. Somit steigt der spatiale
> Suchraum des Encoders und dessen Rechenzeit entsprechend an.
Deswegen werden ja auch B frames in einer anderen Reihenfolge
abgelegt, als mit der sie eigentlich kodiert wurden.
Und der Suchraum des Encoders ist mir an sich reichlich egal.
Und wenn es 10 mal so lange dauert wie sonst, wenn das ergebnis
deutlich besser ist das okay.
Der Decoder kann die Daten ja nahezu genauso schnell abspielen als
vorher. Nur eben die Frames sind in einer anderen Reihenfolge, da er
eventl. einen der vorigen frames braucht.
Das sollte ebenfalls aber rein praktisch beim dekodieren nichts
ausmachen.
> Zurück zum Thema: Beim kombinierten Einsatz von B-Frames und GMC
> kommt es zu mehreren Effekten: Erstens sinkt der Einfluß der
> S-Frames,
> die wie erläutert nur anstelle von P-Frames einsetzbar sind. Die
> B-Frames können GMC NICHT verwenden. Desweiteren liegt für die GMC
> das Problem darin, einen Koordinatensatz mit dem mehrfachen Suchraum
> zu finden, da die B-Frames zeitlich zwischen I und S-Frame bzw.
> S-Frame
> und S-Frame liegen. (z.B. Reihenfolge IBBSBBS = 3-facher Suchraum) Je
> größer der Suchraum, desto höher ist auch die Wahrscheinlichkeit, daß
> die entstehenden Bildverzerrungen nicht mehr durch das globale Modell
> erfaßt werden können und wiederum der Schätzer inkonsistent wird.
Nun ja - wie gesagt die Groesse des Suchraums vergroessert die
benoetigte Rechenleistung - das ist mir aber beim encoden recht
wurst.
Wenn allerdings der Schaetzer versagt, dann muss in einem B-Frame
mehr gespeichert werden, als wenn man mit P frames arbeiten wuerde.
Mag ja stimmen.
> > Klar - QPEL dagegen braucht mehr bandbreite - bringt dann aber auch
> > hoehere Qualitaet - hatte ich aber so geschrieben - oder?
> Mehr Bandbreite bedeutet implizit mehr Qualität. Die Effizienz
> eines CoDecs wird bekanntlich in Qualität/Bandbreite angegeben und
> auch QPEL ist ein Tool, welches nur mit viel Grips und passendem
> Material deutliche Vorteile bringt.
Hmms also die Movie die ich bisher erstellt habe, (sofern sie nicht
grad Ueberlaenge haben), kann man optisch kaum vom Orginal erstellen.
Trotzdem sind sie oft nur 650 MB gross.
Wenn ich die gmc,b-frames und qpel ausschalte, dann reicht die
qualitaet leider oft nicht.
Allerdings braucht es halt alles uferlos rechenpower zum encoden -
aber das ist ja auch okay so.
Wenn es mich mal packt, dann nehm ich mal ein paar kurze Demovideos
mit der Videokamera auf und encode die dann auf die verschiedensten
Bitraten usw. udn pack das Ganze auf meine HP.
Dann kann jeder selber entscheiden :)
Wuenschen wuerde ich mir einen codec, der die frametypen variable
gestalten kann - so ne art header von ein paar bit in jedem frame,
die angeben, was es jetzt fuern frame ist.
Das wuerde sicherlich noch mal eine ganze menge bringen, dann kann
der encoder entscheiden, nehm ich p oder s frame und 'schiebe ich
noch ein paar mehr b frames ein'?
Waere sicherlich ganz witzig.
> > eben massiv Bandbreite spart.
> Das gerade nur dann, wenn das Material und die Encoder-Umgebung paßt.
> Zuerst einmal sind S-Frames im GMC-Fall lediglich als Ersatz bzw.
> Erweiterung zu P-Frames einsetzbar. Dazu kommt pro Bild ein
> Satz von globalen Verzerrungskoordinaten plus 1 Bit PRO Makroblock.
> Die GMC muß demnach passende Parameter erwirtschaften, um überhaupt
> für hinreichend viele Makroblöcke einen adäquaten Ersatz der
> lokalen Bewegungsvektoren darstellen zu können. Quintessenz: das
> Material muß passen (z.B. Kameraschwenks, Zoom, Rotation usw.).
Nun ja - interessant waere es, wenn mit einem variablen Frameraster
gearbeitet wird. Sprich - man sieht die S frames nur dann, wenn es
auch was bringt (sonst halt p frames). Leider ist aber das format
eben pro film vordefiniert und kann nicht dynamisch geaendert werden
(soweit ich weiss).
Ich stimme dir ja zu, dass das GMC nicht immer etwas bringt - aber
meine Tests mit verschiedem Material lieferten durchweg bessere
Ergebnisse.
Sehen tut man es meistens trotzdem nicht, ausser man setzt die
Bandbreite extrem runter - und dann wirds doch recht offensichtlich.
Kann ich nur dazu raten - ich war mir auch nie ganz bewusst, wie viel
es bringt, bis ichs ausprobiert habe (mit verschiedenen sourcen).
Sicher mag es fuer einzelne Faelle halt auch Ausnahmen geben, aber
gross testen tu ich das Ausgangsmaterial heute nicht mehr.
Ich codier eigentlich alels mit saemtlichen optionen on und im 2-pass
verfahren.
> > B-Frames bringt dann noch mal zusaetzlich Bandbreite - da B-frames
> > die Frames sind, die am wenigsten brauchen.
> Auch der Gewinn von B-Frames hängt stark vom Material ab, da wiederum
> B-Frames signalisieren müssen, welches Referenzbild (von zweien) nun
> zur Prädiktion herangezogen wird. Die Referenzbilder liegen darüber
> hinaus zeitlich recht weit auseinander. Somit steigt der spatiale
> Suchraum des Encoders und dessen Rechenzeit entsprechend an.
Deswegen werden ja auch B frames in einer anderen Reihenfolge
abgelegt, als mit der sie eigentlich kodiert wurden.
Und der Suchraum des Encoders ist mir an sich reichlich egal.
Und wenn es 10 mal so lange dauert wie sonst, wenn das ergebnis
deutlich besser ist das okay.
Der Decoder kann die Daten ja nahezu genauso schnell abspielen als
vorher. Nur eben die Frames sind in einer anderen Reihenfolge, da er
eventl. einen der vorigen frames braucht.
Das sollte ebenfalls aber rein praktisch beim dekodieren nichts
ausmachen.
> Zurück zum Thema: Beim kombinierten Einsatz von B-Frames und GMC
> kommt es zu mehreren Effekten: Erstens sinkt der Einfluß der
> S-Frames,
> die wie erläutert nur anstelle von P-Frames einsetzbar sind. Die
> B-Frames können GMC NICHT verwenden. Desweiteren liegt für die GMC
> das Problem darin, einen Koordinatensatz mit dem mehrfachen Suchraum
> zu finden, da die B-Frames zeitlich zwischen I und S-Frame bzw.
> S-Frame
> und S-Frame liegen. (z.B. Reihenfolge IBBSBBS = 3-facher Suchraum) Je
> größer der Suchraum, desto höher ist auch die Wahrscheinlichkeit, daß
> die entstehenden Bildverzerrungen nicht mehr durch das globale Modell
> erfaßt werden können und wiederum der Schätzer inkonsistent wird.
Nun ja - wie gesagt die Groesse des Suchraums vergroessert die
benoetigte Rechenleistung - das ist mir aber beim encoden recht
wurst.
Wenn allerdings der Schaetzer versagt, dann muss in einem B-Frame
mehr gespeichert werden, als wenn man mit P frames arbeiten wuerde.
Mag ja stimmen.
> > Klar - QPEL dagegen braucht mehr bandbreite - bringt dann aber auch
> > hoehere Qualitaet - hatte ich aber so geschrieben - oder?
> Mehr Bandbreite bedeutet implizit mehr Qualität. Die Effizienz
> eines CoDecs wird bekanntlich in Qualität/Bandbreite angegeben und
> auch QPEL ist ein Tool, welches nur mit viel Grips und passendem
> Material deutliche Vorteile bringt.
Hmms also die Movie die ich bisher erstellt habe, (sofern sie nicht
grad Ueberlaenge haben), kann man optisch kaum vom Orginal erstellen.
Trotzdem sind sie oft nur 650 MB gross.
Wenn ich die gmc,b-frames und qpel ausschalte, dann reicht die
qualitaet leider oft nicht.
Allerdings braucht es halt alles uferlos rechenpower zum encoden -
aber das ist ja auch okay so.
Wenn es mich mal packt, dann nehm ich mal ein paar kurze Demovideos
mit der Videokamera auf und encode die dann auf die verschiedensten
Bitraten usw. udn pack das Ganze auf meine HP.
Dann kann jeder selber entscheiden :)
Wuenschen wuerde ich mir einen codec, der die frametypen variable
gestalten kann - so ne art header von ein paar bit in jedem frame,
die angeben, was es jetzt fuern frame ist.
Das wuerde sicherlich noch mal eine ganze menge bringen, dann kann
der encoder entscheiden, nehm ich p oder s frame und 'schiebe ich
noch ein paar mehr b frames ein'?
Waere sicherlich ganz witzig.