а почему N810 никто не обсуждает?

[Mikhail Kostousov]

Почему 4? На данный момент - можно иметь на машинке 10gb. 8gb miniSD +2gb internal

[gLobster]

Карточка занята только картами (простите за тафтологиию), которые можно легко удалять и грузить обратно.

[Siarhei Siamashka]

С видео там всё не так просто. Уже в голове всё перемешалось, в каком форуме читал объяснения участника порта mPlayer под Maemo. Он вроде как раз писал, что не хвтает мощности процессора, и что лучше проигрывается видео с частой расстановкой полных кадров, чем с высоким уровнем комрессии.

Я собственно его же и имел в виду, только я понял совершенно иначе - с процессором все нормально, проблема именно в шине памяти (видео?). Может он сам тут появится и всё объяснит?

Всю информацию можно найти тут в списке рассылки maemo-developers: http://www.gossamer-threads.com/lists/m ... pers/19711

Весь вопрос только в том, как ее правильно интерпретировать

Если описать все в нескольких словах, то получается следующая картина. Framebuffer в Nokia 770 и N800 (и скорее всего N810) представляет из себя просто фрагмент системной памяти. Соответственно чтение/запись данных в эту облась памяти могут выполняться довольно быстро. Настоящая видеопамять находится во внешнем LCD контроллере (S1D13742
для Nokia 770, S1D13745 для N800, полная документация по крайней мере для S1D13742 свободно доступна для скачивания с http://www.erd.epson.com/). Изображение на LCD панели обновляется в соответствии с тем, что хранится в видеопамяти с некоторой частотой (что-то между 50Hz и 60Hz). Теперь самое интересное. Данные из фреймбуфера пересылаются в реальную видеопамять через DMA по мере необходимости (при вызове ioctl(fd, OMAPFB_UPDATE_WINDOW, &update)). Данный процесс пересылки данных в реальную видеопамять является полностью асинхронным и не загружает основной процессор, т.е. ioctl(fd, OMAPFB_UPDATE_WINDOW, &update) возвращает управление практически мгновенно и мы можем спокойно решать какие-либо другие задачи (например, декодирование следующего кадра видео). Если есть необходимость гарантированно дождаться завершения пересылки данных в видеопамять, можно вызвать ioctl(fd, OMAPFB_SYNC_GFX), при этом выполнение данного потока программы блокируется и процессор просто ожидает завершения передачи данных через DMA. Вся эта схема работает замечательно при одном условии - пересылка данных в видеопамять должна успеть завершиться до следующей попытки обновления экрана (в этом случае сам факт асинхронного обновления экрана с точки зрения программы совершенно незаметен, мы как будто работаем с очень быстрой видеопамятью).

Теперь если оценить скорость передачи данных между 'фреймбуфером' и видеопамятью, получается, что у Nokia 770 эта величина порядка 55MB/s (для сравнения, скорость memcpy на Nokia 770 чуть больше 100MB/s), в то время, как на N800 скорость передачи данных в видеопамять всего лишь около 18MB/s. Такая низкая скорость естественным образом ограничивает максимальную частоту кадров при высоком разрешении (размер кадра 800x480*16-bit = 768000 байт). Получается, что максимальная частота кадров при полноэкранных апдейтах достигает значения всего лишь около 23-24 кадров в секунду. Такая низкая скорость обновления экрана еще приводит к такому эффекту, как tearing. Но все эти проблемы по большей части относятся только к полноэкранным RGB апдейтам экрана (скроллинг в браузере и т.д.). Ситуация с видео намного лучше (кроме самой первой ревизии прошивки для N800, но об этом ниже). Во-первых, для видео используется не RGB, а YUV представление цветов (используется 12 бит на пиксель вместо 16 бит для RGB). Во вторых, поскольку LCD контроллер выполняет масштабирование сам, то и пересылается в него картинка с оригинальным разрешением видео (например, при проигрывании видео с разрешением 640x360, через графическую шину проходит только 640x360x12-bit = 345600 байт для каждого кадра), и в процессе пересылки, "на лету" средствами LCD контроллера преобразуется в 800x450 при записи в видеопамять. Таким образом, проигрывание видео наименее подвержено данной проблеме (если, конечно, кто-то не ).

С самой первой ревизией прошивки для N800 была отдельная история. Из-за проблем в драйвере (недостаточных оптимизаций), любой апдейт экрана в YUV-формате (независимо от размера области, для которой требовалось выполнить обновление экрана), занимал порядка 41 миллисекунды. В результате были некоторые проблемы с пропуском кадров даже для видео низкого разрешения, если была необходима частота кадров равная 30.

Борьба с tearing-эффектом - отдельный вопрос. В N800 есть возможность синхронизировать начало процесса DMA пересылки данных в LCD контроллер с внутренней частотой вертикальной развертки (которая составляет, как я уже говорил, порядка 50-60Hz). Это включение режима ожидания начала процесса вертикальной развертки (флаг OMAPFB_FORMAT_FLAG_TEARSYNC из omapfb.h) приводит к тому, что и так медленная графическая шина еще иногда дополнительно простаивает (как я писал в maemo-developers, время полного апдейта экрана начинает "прыгать" в интервале от 41 до 58 миллисекунд вместо стабильных 41 миллисекунд). Кроме того, при медленной пересылке данных (если пересылка данных занимает по времени более 2 циклов вертикальной развертки), наблюдается весьма некрасивый эффект - вместо "разрывов" экрана в случайных местах при отсутствии какой-либо синхронизации, мы получаем "разрыв" экрана в строго определенном месте в нижней части экрана.

Соответственно tearsync флаг включен при проигрывании видео (поскольку там есть хоть какой-то запас, если не пытаться проигрывать видео очень высокого разрешения) и выключен для нормальных RGB апдейтов (победить tearing для апдейтов экрана 800x480 в RGB формате принципиально невозможно из-за низкой скорости графической шины).

PS. Есть у меня смутное подозрение, что и в теперешней реализации видеодрайвера для N800 есть какая-то проблема с быстродействием (т.е. в низкой скорости кроме железа еще может быть виноват и софт). Не исключено, что скорость обновления экрана еще можно несколько улучшить.

[maslovsky]

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

Например, беру первый встречный AVI, скаченный из torrent, с серией из сериала. Размер: 624 x 352, битрейт видео: 1078Kbps (реально в районе 700-900), аудио: 164Kbps. Данный файл на N800 комфортно не пойдёт! Во всяком случае в тех версиях mplayer, которые я пробовал пока у меня была N800. Заниматься перекодировкой я точно не буду - одно дело переписывать с DVD для просмотра, другое дело плодить дупликаты файлов специально для КПК.

Надеюсь, что в N810 всё-таки есть изменеиня на аппаратной уровне и можно будет видео без перекодировки. Возможно достаточно было бы поднять частоту системной шины?

[gLobster]

А можно для примера ссылку на такое видео? Чтобы при случае проверить? Но вроде 810 сделали на том же железе, что и 800

[Siarhei Siamashka]

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

Тут как раз все наоборот Для видео 624x352 достаточно простая арифметика показывает, что время на пересылку одного кадра в LCD контроллер будет составлять (624 * 352 * 12bpp) / 18000000 = 0.0183 секунды. Добавляем сюда худший случай по времени ожидания вертикальной развертки (17 миллисекунд), получаем 35.3 миллисекунды. Это время соответствует где-то 28 кадрам в секунду. Если исходное видео имеет частоту кадров 24 или 25 fps, то скорость графической шины никаких проблем не вызовет. Если частота кадров в данном видео файле равна 30-ти, то следует принимать во внимание, что я брал самую пессимистичную оценку для времени ожидиния вертикальной развертки, в реальности скорее всего при таком разрешении и 30 fps будет отображаться нормально (либо будут очень редкие пропуски кадров). С другой стороны очевидно, что у N800 никакого запаса по пропускной способности графической шины практически нет совсем (о чем и велось обсуждение в списке рассылки maemo-developers). У Nokia 770 такая проблема отсутствует в принципе и о ней можно вообще никогда не вспоминать, как о потенциально ограничивающем факторе, там скорости графической шины хватает с очень большим запасом (зато хватает других проблем).

Делать выводы о том, что ВСЕ проблемы с проигрыванием видео на N800 вызваны медленной графической шиной абсолютно некорректно.

Поскольку для видео такого разрешения графическая шина не является узким местом, все упирается в скорость работы процессора и оперативной памяти. Прибавка в 70MHz к частоте процессора в OS2008 должна заметно помочь в проигрывании видео. Скорость проигрывания видео с высоким битрейтом в основном зависит от скорости работы процессора.

Например, беру первый встречный AVI, скаченный из torrent, с серией из сериала. Размер: 624 x 352, битрейт видео: 1078Kbps (реально в районе 700-900), аудио: 164Kbps. Данный файл на N800 комфортно не пойдёт!

Проблемы с таким файлом могут быть вызваны аудиокодеком (если там вдруг используется, например, AAC для звука). Ну и видео кодеки тоже могут быть различными (вдруг там что-то вроде WMV?). Что касается DIVX/XVID (и прочих MPEG4 ASP кодеков), то если тот, кто кодировал данное видео не изгалялся с включением различных дополнительных опций вроде GMC (которые дают мизерную прибавку качества за счет более ресурсоемкого кодирования/декодирования), то как раз такой файл должен бы на данный момент проигрываться mplayer'ом более-менее нормально.

Еще один возможный вариант - баг в аудио или видео кодеке, либо в демуксере при обработке данного конкретного файла. Например что-то вроде этого: https://garage.maemo.org/tracker/index. ... 4&atid=269

Естественно, такие проблемы должны выявляться и исправляться. Списывать все на скорость процессора или иные проблемы в железе смысла мало.

Во всяком случае в тех версиях mplayer, которые я пробовал пока у меня была N800.

Практически в каждой новой сборке mplayer для N800 были улучшения быстродействия (иногда очень заметные). Самая первая сборка mplayer для N800 даже когда-то проигрывала в качестве проигрывания видео 770-ой модели

[maslovsky]

Короче, дело ясное, что дело тёмное Нужно будет проверять на реальном железе, причем сравнивать оба аппарата на новой 2008-й прошивке.

[maslovsky]

А можно для примера ссылку на такое видео? Чтобы при случае проверить? Но вроде 810 сделали на том же железе, что и 800

Скачай любую серию любого сериала с lostfilm.tv

[maslovsky]

Судя по всему, у N810 будут те же самые проблемы с воспроизведением видео, что и у N800:

On Thu, Oct 18, 2007 at 02:01:59PM -0700, ext Dan Amelang wrote:
> Hi all (specifically to Daniel Stone, actually, but others might be
> interested in the answer),
>
> Does the N810 have the same memory bandwidth problems that the N800
> has, as discussed here?

Sparing Daniel the hard time -- the answer is yes.


--
MDK

Источник: http://lists.maemo.org/pipermail//maemo ... 12086.html

[sparrowson]

Надеюсь, что в перспективе возьмутся за это направление ещё плотнее и, может, даже будут выпускать две разных модели таблеток.

Всё-таки не беспочвенно я надеялся. Оказывается, теперь будет таблеточная линейка, пусть и из двух моделей

The Nokia N810 is an Internet appliance from Nokia, announced on 17 October 2007. The Nokia N810 and the Nokia N800 will be in production at the same time. The Nokia N810 is not intended to replace the Nokia N800.

Так что действительно - в следующий раз на замену можно ждать не одну таблетку, а очередную линейку.

[gLobster]

Или закрытие направления, как бесперспективного

[AndyKK]

Editor33, разрешите с вами не согласится, Everun, безусловно интересный аппарат, как с технической точки зрения, так и цены. Мне кажется у него один существенный недостаток: десктопная ось. т.е. приложения не расчитаны на малый размер экрана, прийдется использовать скроллинг.

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

Соглашусь с gLobster, вполне этот проект могут закрыть, похоже, что особой прибыли нокии он не приносит.....

[Kirill Limping]

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

У них была одна серийная модель подобного планшета на Symbian Series 90 - это направление свернули, затем клавиатурные коммуникаторы на Series 80 - фактически свернули. Остался один Series 60, который до сих пор без тачскрина и вообще ориентирован на телефонный форм-фактор. В общем на symbian сплошной регресс.

[sparrowson]

По мне, так как раз наоборот - Nokia с высокой степенью вероятности связывается с Linux, планируя большой задел на будущее. Возможно, Symbian постепенно уйдёт на второй план.

К тому же (здесь, кстати, уже обсуждалось в другой теме - кажется, той, которая про Nokia 770) сделать с нуля таблетку проще под Linux - хотя бы из-за разрешения экрана. Кто видел симбиановые агрегаты с 800x480?

[AndyKK]

Чем вам не нравится последняя 60-ка: простая и незатейливая, интуитивно-понятная, почти как мультизадачный Палм ОС, к томуже с "кучей" разнообразного софта....

Что касается разрешения экрана, когда вышла Е61, то с ее разрешением работал только установленный софт, прошло пару месяцев и ситуация быстро поправилась, производители скорректировали свое ПО....