Мне кажется, и в том и в другом. Реализацию рано или поздно подтянут я думаю, будет проигрывать h264 не более чем в 2-3 раза. Мне очень интересно как реализовали в avcodec'e (ffmpeg). Как только, так сразу пощупаю.На счет дизайна.. Ну например там есть одна особенность (точнее она присутствует во всех кодеках On2, т.е. VP1...VP8): у них не используются B-frame'ы.
На всякий случай поясню что это такое:
В видеопотоке бывают три вида кадров:
I - это т.н. ключевой кадр. по сути -- обычная jpeg картинка. Соответственно видеопоток mjpeg'a полностью состоит именно из I-кадров. I-кадр не зависит от кого-либо ещё. I-frame является опорным кадром.
P - это кадр для формирования которого используется последний опорный кадр. Грубо говоря, P-frame это diff исходного изображения с изображением предыдущего опорного кадра. P-frame также является опорным кадром.
B - это кадр для формирования которого используются сразу два опорных кадра. Предыдущий и СЛЕДУЮЩИЙ. B-frame не является опорным.
Соответственно они идут как-то так: IBBP, или так: IBPBPBP
(это называется GOP -- group of pictures. после этого последовательность повторяется, т.е. IBBPIBBP и т.д. , также следует учесть, что обычно GOP size (число кадров в GOP'е) существенно больше нежели в примере. в примере gop size = 4, на самом деле не редко и gop size = 40).
B-frame в несколько раз меньше чем P-frame, которые опять таки в несколько раз меньше чем I-frame (это самое "несколько" -- порядка 10). На кодирование B-frame существенно менее ресурсоёмко нежели P-frame.
Т.о. для достижения того же качества картинки при том же битрейте VP8 придется использовать более сложные алгоритмы для формирования P-кадров (B-кадров то нет).
Тут на самом деле есть ещё один нюанс: если у нас конечный терминал (например мобильник, или нетбук) не справляется с декодированием нашего видеопотока (ведь ему не только декодировать, но ещё и рисовать надо, т.е. такое бывает), то в случае кодека с B-кадрами мы можем (по запросу терминала, т.е. он определит такую ситуацию и нас попросит) совершенно спокойно снизить fps без перекодирования потока, просто посредством выбрасывания B-кадров. Ведь они на другие кадры не влияют т.о. мы ещё и трафик сэкономим. Либо, если такового мезанизма оповещения нет, сам терминал может игнорировать B-кадры, не пытаясь их декодировать (для детекта B-кадра достаточно просмотреть заголовок пакета -- это очень быстро).
С VP8 (равно как и VP6, VP3 и т.п.) такой финт ушами не пройдет. Там все кадры опорные. Выкинув хотя бы один получим гарантированную порчу картинки до тех пор, пока не придет ключевой кадр (I-frame) а он может приходить довольно редко -- раз в три секунды например, а то и реже.
Собственно в самом первом H263 (1995 год) тоже не было B-кадров. Но потом таки появились. В H264 они есть от рождения (потому как развитие H263'тьего).
