В предыдущей заметке я рассказал про то, как сделать видео для iPhone, которое можно передавать на гаджет с использованием принципа Smooth Streaming. И даже дал ссылку на собственный проект, где применил результаты своего знания. К сожалению, как оказалось – весьма поспешно: люди, проверившие ресурс на iPhone 3G, сообщили, что ничего не работает и выдается одна и та же ошибка, схожая с той, которую получал я на своем аппарате – «Формат видео не поддерживается».

То, что я посчитал ограничением первой версии аппарата, оказалось более системным. Сложилось так, что эмуляция iPhone в SDK, распространяемом Apple, строится на немного иных принципах, нежели традиционная эмуляция аппаратуры, как это делали в QEMU в проекте OpenMoko. Если во втором случае действительно эмулировался ARM SoC, то разработчики iPhone пошли по пути меньшего сопротивления – они просто пересобрали среду под традиционную платформу (которая x86), и когда запускался эмулятор – по сути дела работает родной для платформы код, но с ограничениями, налагаемыми эмулятором. А когда программу для гаджета необходимо перенести на устройство – используется кросс-компиляция и уже генерируется код для платформы ARM.

Разумеется, при первых испытаниях трансляции псевдо-потока я использовал iPhone первого поколения и результат был плачевен – устройство от казалось играть данный формат. Но попытка воспроизвести тот же самый фрагмент в эмуляторе оказалась успешной, что и привело к ошибочному выводу, позднее опровергнутому посетителями ресурса. Скорее всего, эмулятор использует мультимедиа-прослойку операционной системы, гораздо менее привередливую, нежели та, которая используется в iPhone OS (у которой ноги растут тоже из Mac OS X). Поэтому он беспроблемно показал то видео, которое мой телефон посчитал сбойным.

Причина же невоспроизведения видео кроется не в формате, а в кодеке видео h.264. В его реализации для мобильной платформы Apple внесло ряд ограничений, нарушение которых ведет к тому, что файл просто не воспроизводется. Поэтому правильно подобранные параметры из ссылки в предыдущей статье приводят к закономерно успешному результату.

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

Как я уже ранее писал, вещать видео на iPhone можно было начиная с самых первых версий прошивки в псевдо-потоковом режиме, как, собственно, и делал популярный сервис YouTube. Т.е. через сеть поверх HTTP-протокола отдавался mp4-файл, а сервер умел отрабатывать параметры, передаваемые плеером и формировать заголовки формата в случае, если пользователь желал посмотреть ролик с середины.
Подробнее »»

Сейчас, когда идет keynote WWDC 2009 и о новшествах третьей версии прошивки говорят открыто, раскрою и я завесу тайны, надеясь не попасть при этом под NDA. Тем более, что еще во время объявления оных свойств, многие пользователи и разработчики захлебывались слюной на этот счет.
Подробнее »»

Мир не идеален, чего уж говорить про программы, которые пишутся одними людьми для других. Редко бывает так, чтобы все работало хорошо и гладко, и виной тому – не злобные программисты, а сочетания множества факторов, начиная от состояния аппаратного обеспечения, заканчивая сложностью программирования как таковой. Увы, наш уважаемый iPhone – не исключение. Доводилось ли вам наблюдать, как программы на нем перестают работать, реагировать на действия пользователя, выдавать несообразные данные или вообще отказываются запускаться? Думаю да, и не раз. Эмоциональный пользователь, скрипя зубами, удалит раздражающее приложение с телефона, поставит ему минимальную оценку, напишет гневный отзыв и с десяток раз пожалеет о потраченном времени и деньгах. Пользователь же дотошный напишет гневное письмо, где во всех подробностях и не стесняясь в выражениях перечислит все найденные ошибки. Чем, конечно, непомерно поможет разработчику и обяжет его устранить неполадки, дабы сохранить свое лицо. Но, увы, часто пользовательское описание внешнего проявления ошибки ничем не поможет разработчику – именно в силу сложности предметной области и множества факторов, влияющих на возникновения сбоя. Поэтому, наилучший способ предоставить разработчику информацию об ошибки и заставить его отработать потраченные на приложение $0.99 – это послать ему отчет о сбое (т.н. крэш-репорт), который волею компании Apple и ее системных программистов сохраняется на телефоне. Этот отчет содержит подробную техническою информацию об инциденте (состояние стека всех выполняющихся потоков и т.п.) и не содержит никаких персональных данных владельца, за исключением, пожалуй, ТТХ устройства. Эта информация гораздо более полезна для программиста и позволит понять суть ошибки и локализовать ее гораздо быстрее, нежели благодаря описанию «не запускается и все тут».

Когда пользователь синхронизирует своё устройство с помощью iTunes, крэш-репорты автоматически копируются в директорию на диске на пользовательском компьютере. Если приложение было скачано из App Store и пользователь включил отправку крэш-репортов в Apple, то крэш-логи будут автоматически отправлены iTunes в Apple и разработчик сможет скачать их через iTunes Connect. В этом случае дотошным пользователям беспокоится не стоит – автор приложения и так все увидит.

В случае же приложений, которые были получены через систему Ad Hoc тестирования, или разрабатываются внутри компаний для своих сотрудников (т.н. Enterprise метод), или пользователь не включил отправку крэш-репортов в Apple, придется совершить ряд дополнительных, но довольно несложных телодвижений. Пользователю нужно будет извлечь крэш-репорты из папки, куда они копируются iTunes. В зависимости от платформы, папки могут быть следующими:

* Mac OS X: ~/Library/Logs/CrashReporter/MobileDevice/
* Windows XP: C:\Documents and Settings\\Application Data\Apple Computer\Logs\CrashReporter\MobileDevice\
* Windows Vista: C:\Users\\AppData\Roaming\Apple Computer\Logs\CrashReporter\MobileDevice\

где – это имя пользователя на компьютере, под которым осуществялась синхронизация c iPhone, а – это имя пользовательского устройства, которое дается при синхронизации в iTunes. Имена крэш-репортов начинаются с имени приложения, содержат информацию о дате и времени, когда произошёл инцидент и – самый главный признак при их поиске – имеют расширение .crash.

Если же ваше устройство было взломано (jailbrake) и синхронизации с настольным компьютером не было и не предвидится, то крэш-репорты можно найти на самом аппарате в папке /private/var/logs mobile/CrashReporter/. В этом случае достаточно просто скопировать эти файлы при помощи scp или любого файлового менеджера, поддерживающего передачу данных поверх защищенного протокола SSH.

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

Специально для ru_iphonedev, совместно с Романом Бусыгиным.

Спустя почти месяц молчания расскажу про покупку права присоединения Apple iPhone Developer Programm, точнее – о моем опыте в этом деле. Ну а прежде, чем приступить к сему благостному занятию, вкратце расскажу о том, что планирую в будущем написать.

Так, в планах:

• описание простейшей CRM, которую мы сейчас разрабатываем в компании;
• интерфейс информационного ресурса для использования в сетях IPTV для получения информации при помощи традиционных STB;
• вкусности iPhone OS 3.

Ну а теперь, когда интерес подогрет, приступлю к основной теме.
Подробнее »»

Сейчас все силы и чаяния брошены на работу с ТулаВидео – региональным медиа-сайтом. В принципе, это сумма того, чем пришлось заниматься почти все лето.

Подробнее »»

После краха с отработанной методикой сжатия h.264-кодеком, которая давала для Flash-а весьма недурственный результат, захотелось понять, почему iPhone, а, точнее, Appl-овский декодер столь привердлив, нежели VLC и прочие. После серии экспериментов удалось исключить пару параметров, которые не давали заметного выигрыша по сжатию, но весьма раздражали iPhon-овский медиа-проигрыватель.
Подробнее »»

Как известно, помимо традиционного AppStore для iPhone имеется два метода управления программным обеспечением, не требующих ковыряния во внутренностях ОС аппарата – Installer и Cydia. Если первый представляет собой управление пакетами посредством их XML-описания и не отслеживает зависимости ПО (что по сути равнозначно «скачал, распаковал – пользуйтесь как хотите»), то вторая система управления пакетами построена на базе Дебиановского dpkg со всеми вытекающими.
Подробнее »»

Простая с виду задача – переконвертировать видео для просмотра на вышеупомянутом мобильном устройстве – таила в себе много проблем.

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

Устройство страшно сопротивлялось QT-вской картинкой. Выход был найден в удалении всех параметров кодека (видимо, какой-то из них и вводил декодер в ступорное состояние). Качество видео ухудшилось, но показывает

Итак, toolchains у нас есть, теперь можно попробовать что-то сделать. Но прежде чем приступать, озаботимся слегка инфраструктурой сборки и развертывания приложений.
Существует одна объективная сложность – поскольку у нас нет эмулятора iPhone (точнее, он есть в официальном SDK, которое только под Mac и beta), а допиливать до нужного состояния что-то вроде QEMU и ему подобного – дело продожительное и не факт, что оправданное – тестирование приложений придется производить боем на аппарате.
Подробнее »»