LINUX.ORG.RU

Theora RC1

 , ,


0

0

Никто не ждал, а она вышла. Встречаем: первый RC свободного видео кодека Theora. Из значимых новостей стоит упомянуть о заимствовании оптимизации из проекта Thusnelda (http://web.mit.edu/xiphmont/Public/th..., http://web.mit.edu/xiphmont/Public/th...). Thusnelda - это попытка сделать кодек более или менее соответствующим современным реалиям.

>>> Скачать

Ответ на: комментарий от SKYRiDER

>Наличие полностью свободного видеокодека — в любом случае шаг вперёд, несогласные с этим — просто недалёкие люди. SKYRiDER *** (*) (03.10.2008 19:45:45)

Ну зачем ты их обижаешь, они же не понимают слово "недалекие", надо на их языке писать - "тупое, безмозглое быдло". А их камменты сводятся к двум фразам:

ISO приняло OOXML в качестве стандарта: "Уря! Да штрафствует зоопарк сьтандартафф!"

Разработан первый свободный кодек: "Open Source - валасапедостроители!"

anonymous
()
Ответ на: комментарий от SKYRiDER

>Тем более что грядущий Firefox 3.1 будет поддерживать Theora и Vorbis внутри тега <video> из HTML5. Пруфлинк: http://www.theora.org/news/

Теперь надо писать плагин для осла и упрашивать известные кодек-пеки включить в их пакет. И от 20-30 процентов пользователей осла ситуация не сильно и измениться. Еще можно поросить, чтобы был в хроме, но пока не ясно, нужен ли этот хром вообще.

anonymous
()
Ответ на: комментарий от anonymous

Ибо от 20-30 процентов пользователей лисы ситуация не сильно и измениться.

хотел сказать

anonymous
()
Ответ на: комментарий от anonymous

>Ибо от 20-30 процентов пользователей лисы ситуация не сильно и измениться.

>хотел сказать

конк теперь тоже теору через тег играет, и сейчас чобы смотреть видео нужно ставить флеш плагин, а что его нету ни в ишаке ни в фф никого не волнует - хотите смотреть ютюбь - ставтье флешь, и тут та же история - хотите смотреть видео - ставьте нормальный браузер или плагин

anonymous
()
Ответ на: комментарий от anonymous

> Гражданин не местный, с противоположного лагеря

Я с обоих лагерей. Просто на десктопе меня пока подташнивает от Линукса, на сервере - от Windows.

DOKA
()

А где нибудь можно почитать как ей пользоваться совместно с mencoder'ом? Например какие опции задать после -lavcopts vcodec=libtheora для получения картинки неотличимой на глаз от исходного DVD источника?

fat_angel ★★★★★
()
Ответ на: комментарий от DOKA

> Просто на десктопе меня пока подташнивает от Линукса, на сервере - от Windows.

Попробуй поменять их местами! =)

anonymous
()

У вендузятников есть KMPlayer, который основан угадайте на чем, но играет в отличие от вообще все, ибо почему-то не брезгует включать в себя нужные кодеки вне зависимости от лецензии и прочей лабуды.

Barlog_M
()
Ответ на: комментарий от devl547

devl547> use ffdshow/gstreamer-plugins-*/mplayer
devl547> что сложного?

Сложность в проигрывании этого всего под embedded systems. Если операционка и предоставляет эффективную реализацию популярных декодеров типа MPEG-4 или H.263, то еще не факт, что она предоставит к ним вменяемый интерфейс. Хорошо знакомый мне пример - Symbian. Он умеет декодировать это все, но Video Streaming API Nokia просто так не дает, то есть свой полнофункциональный плеер с этими декодерами не сделаешь. Я недавно портировал теору под Симбиан - неплохо, хотя и не слишком хорошо, 25 fps удается тянуть лишь на довольно сильных девайсах типа N93. Но это - чисто сишный код, его, кажется, еще никто не пытался оптимизировать специально под ARM. Возможно, это бы помогло, если бы кто этим занялся. 10 fps даже без оптимизации (а для потокового видео этого достаточно) - лехко.

Насчет MPEG-4 и H.263 - я читал про энное количество попыток мужественных людей спортировать ffmpeg под Symbian - ничего хорошего не получается. В ffmpeg не так просто изолировать один нужный кодек от остальных, и в итоге размер библиотеки все равно измеряется несколькими мегабайтами, ffmpeg заточен для использования именно на i386. Ну и, наконец, результат всей этой мужественной работы - декодер работает неприемлемо МЕДЛЕННО.

elzhov
()
Ответ на: комментарий от elzhov

> Насчет MPEG-4 и H.263 - я читал про энное количество попыток мужественных людей спортировать ffmpeg под Symbian - ничего хорошего не получается.

Эх, этим мужественным людям еще бы и руки прямые, все проблемы бы сразу решились... Или Symbian настолько убогая система, что даже gcc для нее нет?

> В ffmpeg не так просто изолировать один нужный кодек от остальных, и в итоге размер библиотеки все равно измеряется несколькими мегабайтами,

При желании/умении все ненужное из ffmpeg легко выкидывается.

> ffmpeg заточен для использования именно на i386. Ну и, наконец, результат всей этой мужественной работы - декодер работает неприемлемо МЕДЛЕННО.

Вот уж что именно, а MPEG-1/MPEG-2/MPEG-4 ASP в FFmpeg оптимизирован под ARM как раз более-менее нормально. Или под Symbian ассемблерные оптимизации не завелись?

anonymous
()
Ответ на: комментарий от anonymous

Собственно, под Symbian приложения только gcc/g++ и собираются. Под Symbian >= 9.0 спортирован gcc 3.4.

Короче, вот одна из ссылок, от которых я отталкиваюсь: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-August/014044.html

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

Я вижу, что в сорцах ffmpeg'а есть директория с ассемблерными файлами для компиляции под ARM, и я сильно сомневаюсь, что те, кто это собирал под Симбиан, не использовали эту оптимизацию (если она возможна именно под этот процессор). Те несколько отчетов, которые я читал, рассказывали примерно об одних и тех же проблемах.

elzhov
()
Ответ на: комментарий от elzhov

> Собственно, под Symbian приложения только gcc/g++ и собираются. Под Symbian >= 9.0 спортирован gcc 3.4.

good

> Короче, вот одна из ссылок, от которых я отталкиваюсь: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-August/014044.html

Во-первых, это было очень давно и с 2006 года очень многое изменилось. Во-вторых, тот товарищ даже не пытался ничего собирать, а только *предполагал*, что все будет тормозить. Как, впрочем, и Вы :)

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

Потому как я собирал FFmpeg для ARM (правда только под Linux, а не Symbian) и имею представление о его быстродействии. Если у кого-то на сравнимом по характеристикам железе есть серьезные проблемы с быстродействием, а у меня их нет, значит есть вероятность, что те товарищи что-то делают не так.

anonymous
()
Ответ на: комментарий от anonymous

> Потому как я собирал FFmpeg для ARM (правда только под Linux, а не Symbian) и имею представление о его быстродействии. Если у кого-то на сравнимом по характеристикам железе есть серьезные проблемы с быстродействием, а у меня их нет, значит есть вероятность, что те товарищи что-то делают не так.

Да, это справедливо. Тем более, что компилятор один и тот же.

elzhov
()
Ответ на: комментарий от elzhov

> Ок. Какое железо, кстати? И памяти сколько?

Nokia 770, arm926ej-s 252MHz, 64MB RAM

Наиболее типичные проблемы с быстродействием при проигрывании видео:

1. не совсем оптимально отконфигурирован ffmpeg и ассемблерные оптимизации не работают

2. используется аудио декодер с floating point арифметикой на процессорее без FPU

3. YUV->RGB конверсия очень ресурсоемка, если есть аппаратная поддержка YUV colorspace для вывода видео, ее нужно использовать

anonymous
()
Ответ на: комментарий от anonymous

> Nokia 770, arm926ej-s 252MHz, 64MB RAM

Да, частота процессора та, что нужна, а про память, наверно, я зря спросил :) Потому что общее количество RAM мало что говорит о том, сколько реально свободно.

> 1. не совсем оптимально отконфигурирован ffmpeg и ассемблерные оптимизации не работают

Да? Почему?

> 2. используется аудио декодер с floating point арифметикой на процессорее без FPU

Что ж. Неприятно, конечно :)

> 3. YUV->RGB конверсия очень ресурсоемка, если есть аппаратная поддержка YUV colorspace для вывода видео, ее нужно использовать

Я использовал свою ф-цию (вернее не свою, а у кого-то давно заимствованную, не помню откуда), но я не заметил, чтоб конвертация сильно влияла на скорость. Когда кодек уже не тянет (время декодирования кадра примерно равна или больше 1/fps), кряхтит, то заметно, что при добавлении этой конвертации он кряхтит сильнее, но когда кодек уверенно справляется, то конвертация ничего не портит. В конвертировании ничего сложного нет, и можно при желании это все переписать на ассемблере, но я сомневаюсь, что там можно где-то обогнать компилятор - при конвертировании используются лишь инструкции, которые компилируются очень эффективно, там даже умножения нигде нет.

PS это уже свалилось в оффтопик, можно постучаться мне в аську 94802444, я б с удовольствием поспрашивал еще про ffmpeg под ARM :)

elzhov
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.