Вышел XviD 1.0.0 beta1

yeah!!!

Пользуясь случаем, задам вопрос: есть такое нехорошее свойство у сжатого видео - когда камера вращается на месте (и, соответственно, изображение скользит относительно экрана вбок), картинка двигается рывками или смазывается вообще. Что это? Свойства некоторых кодеков, режимов сжатия или жатого видео вобщем? И можно ли этого избежать?

Нет, это эффект кривых рук, которые снимали рывками.

"Пользуясь случаем, задам вопрос: есть такое нехорошее свойство у сжатого видео - когда камера вращается на месте (и, соответственно, изображение скользит относительно экрана вбок), картинка двигается рывками или смазывается вообще. Что это? Свойства некоторых кодеков, режимов сжатия или жатого видео вобщем? И можно ли этого избежать?"

А каким кодеком сжато? Каково качаество несжатого видео?

mplayer не цепляет его :((

Да я не вел статистику кодеков, битрейтов и пр. Это общие наблюдения по mpeg4... Такой эффект довольно часто встречается у фильмов жатых в mpeg4. А вот для tv или видака это не характерно. А хочется, чтобы фильм плавно шел. И запас по процу есть - обычная загрузка - 20-30% - ан нет... ИМХО, дело все-таки в сжатии.

На панарамах с подвижной камерой резко подскакивает поребность bitrate, и различные mpeg4 кодеки можгут не только сыпать квадратами но и drop-ить кадры. Также при повышенном битрэйте, некоторые тачки могут неуспевать декодировать и пропускать через все памяти, мосты и процессоры повышенные обьемы данных (яркий пример тормозящий у всех в свое время двд рип фильма Брат). Также на подвижных сценах наиболее заметны всяческие (De)Interlace ппроявления. В частности некоторые долботехи и приборы конвертируют NTSC в PAL добавлением 25-го кадра дублирующего 24-ый.

http://www.linux.org.ru/view-message.jsp?msgid=438825&back=view-group.jsp...

я вот здесь вот немножко обсуждал похожую проблему, к сожалению видео, полученное с TV source, не очень хорошо жмется кодеками от divx, я думаю что с xvid будет тоже самое. Для такого видио нужно делать предварительную обработку различного рода препроцессинг фильтрами, а также натравлаять алгоритмы деинтерлейсинга. В divx эти алгоритмы есть, и в DivX Guide рекомендуют их использовать для TV video, но они включены только в проффесиональную версию DivX, которой, к тому же, не существует под линукс :-(

А под слакой работает ?

Уже XviD 1.0.0 beta2 вышла:

This is the second beta of XviD 1.0.0. Codenamed "Ciao".

Binary compatibility is preserved, but API has changed for the second pass plugin (a simple field renaming).

Changes since 1.0.0 beta1 (Aloha):
xvidcore:
MPEG4 compliance is back (beta1 was missing the VOS header)
matrix quantization is finally thread safe
improved vop type decision
2pass2 plugin: min key interval was a misleading name. It's been renamed to kfthreshold. And as the kfthresholding behavior was a bit too aggressive, it's been disabled until we decide how it should behave w/o hurting quality
single plugin: fixed quant capping
interlacing artefacts fixed.


VFW fontend:
some misuses of xvidcore were fixed
min key frame widget renamed and moved to the 2pass panel

Debian package:
small errors in the control file reported and fixed by Nicolas Boos

Next beta releases will focus on tuning for better quality and/or speed. Though we don't know of any standard compliance problem at the moment, continue using beta releases with care.

дык как ее к mplayerу прикрутить? зачем он без него нужен?

Подождать пока выйдет final - тогда он появится в mplayer.

>>>По поводу смазывания при вращении и т.д.

Это Vector motion - кодек пытается определить передвижение областей в кадрике и соотвественно нихрена с этой областью не делать в следуещем кадрике - кроме как переместить ее - почти во всех кодеках реализация далека от соовершенства - отсюда и вышеописанные глюки.