Здравствуйте, мыщъх, Вы писали:

М>присоединяюсь к вопросу. и в упор не понимаю, почему нельзя жать только разницу с предыдущим кадром. в реальное время это укладывалось еще во времена третьих пней, причем степь сжатия была уже сопоставима с "оффлайновыми" компрессорами. существует очень немного причин, чтобы сжимать кадры независимо друг от друга, поскольку степень сжатия при этом получается очень низкая.
Когда-то давно, когда я только выбирал подходящие по параметрам алгоритмы, я пробовал так же добавлять разницу с предыдущим кадром. На скорость сжатия повлияло в худшую сторону, потому оказался.

М>это если картинку сжимать одним блоком. а на фига это делать при таком разрешении? любые алгоритмы сжатия покажут не чуть не худший результат по степени сжатия если картинку разбить на несколько частей (например, на четыре) и сжимать их отдельно друг от друга. но это опять-таки от алгоритма и формата данных зависит...
Вот как раз я и хочу отойти от "формата" один кадр на одно ядро и перейти к один кадр на все ядра.

М>кстати, настораживает то, что картинка квадратная
Да я это для упрощения

М>и еще настораживает то, куда и как складируются сжатые кадры. допустим, у нас есть четыре ядра, которые захватывают четыре соседних кадра и жмут их. допустим так же, что волею случая ядра заканчивают работу в обратном порядке, т.е. четвертый кадр сжимается раньше всех, а последним сжимается первый кадр. что делают ядра? тупо ждут окончания сжатия первого кадра?
Сейчас сделано так — перебираются ядра, закончившие работу и их результат в порядке очередности скидывается на диск.
Да, ждут. Ситуация, когда четвертый сожмется быстрее первого ну очень маловероятна, потому я такой потерей пренебрег.