Форум: КПК и смартфоны на Linux: Zaurus, планшеты Nokia, прочее
Тема: а почему N810 никто не обсуждает?
Страницы: 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
[Ответить]
AndyKK [23.10.2007 15:42] :
Kirill Limping, это опять не из той оперы, а в тошибе на ВМ2003, было приложение, которое включало режим 640х480.
У вас был завр, вам комфортно было работать, скажем в pdaXrom, запустив FireFox, мне нет, так как все было очень мелко, та же история есть на никии...., если честно то мне уже надоело....
Neopes [23.10.2007 15:56] :
хм, я привык к такому раскладу в пдаХром, в полне удобно
alien8 [23.10.2007 16:24] :
AndyKK
Большое разрешение на маленьких экранах неудобно в том случае, если интерфейс не согласован. Вот на Завре в Cacko мне не мелко. А в "иксах" - уже "мелкота" больше чувствуется (ну что-то настраиваемо, но тем не менее)
AndyKK [23.10.2007 16:28] :
А я о чем, комуто комфортно, комуто нет, а то развели бодягу....
maslovsky [23.10.2007 17:42] :
- S.H.A.D.E писал(а):
Mikhail Kostousov И сколько сейчас N800 стоит?
Mikhail Kostousov [24.10.2007 23:56] :
Почему 4? На данный момент - можно иметь на машинке 10gb. 8gb miniSD +2gb internal
gLobster [25.10.2007 08:10] :
Карточка занята только картами (простите за тафтологиию), которые можно легко удалять и грузить обратно.
Siarhei Siamashka [25.10.2007 18:25] :
- maslovsky писал(а):
[quote:dfbe5091c2="gLobster"]С видео там всё не так просто. Уже в голове всё перемешалось, в каком форуме читал объяснения участника порта mPlayer под Maemo. Он вроде как раз писал, что не хвтает мощности процессора, и что лучше проигрывается видео с частой расстановкой полных кадров, чем с высоким уровнем комрессии.
Всю информацию можно найти тут в списке рассылки maemo-developers: http://www.gossamer-threads.com/lists/maemo/developers/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 [25.10.2007 20:03] :
Спасибо за развернутый ответ! Собственно, как я и говорил, можно сделать вывод, что без изменений в железе одним только повышением скорости процессора принципиальных изменений в скорости воспроизведения видео с достаточно выкоим битрейтом не получить!
Например, беру первый встречный AVI, скаченный из torrent, с серией из сериала. Размер: 624 x 352, битрейт видео: 1078Kbps (реально в районе 700-900), аудио: 164Kbps. Данный файл на N800 комфортно не пойдёт! Во всяком случае в тех версиях mplayer, которые я пробовал пока у меня была N800. Заниматься перекодировкой я точно не буду - одно дело переписывать с DVD для просмотра, другое дело плодить дупликаты файлов специально для КПК.
Надеюсь, что в N810 всё-таки есть изменеиня на аппаратной уровне и можно будет видео без перекодировки. Возможно достаточно было бы поднять частоту системной шины?
gLobster [25.10.2007 21:36] :
А можно для примера ссылку на такое видео? Чтобы при случае проверить? Но вроде 810 сделали на том же железе, что и 800
[Ответить]
[< Назад] [Вперед >]