DivX 5 a bidirectional encoding

Protože se v diskuzní skupině objevily dohady o chování kodeku DivX 5.0 a vypouštění druhého snímku, uvedeme to na pravou míru a doplnili jsme do článku o DivX 5.0 odstavec, který toto vysvětluje. Abyste nemuseli hledat, máte ho rovnou i tady:

Zastavme se také u bidirectional encoding. Zde je trochu problém. Vysvětleme si, jak vůbec pracují kodeky s programem. Ten posílá kodeku jednotlivé framy jeden po druhém a kodek mu tento frame vrátí zkomprimovaný. Není možná žádná prodleva ve vracení snímků. Normálně nelze udělat, aby kodek dostal několik framů a teprve potom je poslal zpět programu. Pro bidirectional encoding je ale potřeba znát následující snímek, abychom mohli zakódovat ten předchozí. Proto DivX 5 toto obchází takto: první frame videa je vždy I-frame a ten vrátí zakódovaný normálně, druhý frame ale nevrátí a místo něj vrátí delta (P) frame, který je shodný jako první frame (delta frame říká jen změnu, ovšem změna není žádná, takže je velmi malý). Místo třetího framu je pak vrácen druhý frame, místo čtvrtého třetí atd. Tím má kodek k dispozici jeden frame navíc, který je nutný právě pro bidirectional encoding. Vznikne tím ale časový posun videa vůči zvuku o 1/počet snímků za vteřinu, tedy 40ms pro 25fps. Navíc poslední snímek je "ztracen", protože ho software již nevyžaduje. Nevěšte ale hlavu, řešení tohoto problému existuje. Nová verze VirtualDubu 1.4.10 s tímto počítá a ten druhý shodný frame "zahodí" a všechny následující (které jsou normálně o jeden zpožděny) posunou na správné místo. Počítá se i s posledním snímkem, který se tak neztratí. Zajímavé je také, že vždy dva snímky jsou spojeny do jednoho a data uložená v dalším framu ve streamu nejsou použita (resp. tento frame je téměř nulový). To je ale interní věc kodeku, jak si data zakóduje. Při dekódování se vždy dekódují tyto dva snímky společně a ten druhý je uložen v paměti pro přehrání na správném místě, nevznikne tím žádné narušení posloupnosti snímků.