Archive for the ‘Video’ Category

Вся правда о Видео во Flex. Часть 5. NetStream, обработка напильником.

Sunday, October 21st, 2007

В этой части мы поругаемся на NetStream.

Грубо говоря NetStream – это основа всей работы с видео/аудио. На мой взгляд основа чего-либо должна быть идеальна, ну или хотя бы близка к идеалу. А тут нам подогнали реально сырое(? или просто глюченое) решение.
В процессе решения нам понадобится всего пара-тройка напильников

Напильник номер один

NetStream – как есть просто не приспособлен для работы с видео. Если попытаться использовать пример их хелпа, то мы после запуска видео сразу же ловим эксепшин:
[code lang=”actionscript”]
Error #2044: Unhandled AsyncErrorEvent:. text=Error #2095: flash.net.NetStream was unable to invoke callback onMetaData. error=ReferenceError: Error #1069: Property onMetaData not found on flash.net.NetStream and there is no default value.
[/code]
Добрые индусы забыли добавить в NetStream метод onMetaData. Верне не один метод а всего два: onCuePoint, onMetaData, вобщем эти методы я подглядел в классе VideoPlayer, правда уже после того как я наловился эксепшинов ) еще там они объявляют метод onPlayStatus, но я не сильно старался понять зачем этот пустой метод нужен:).
И тут на выручку нам приходит напильник, просто наследуемся от NetStream и вставляем не хватающие методы, я просто стал диспатчить события с полученной инфой чтобы все выглядело однообразно:
[code lang=”actionscript”]
class VideoNetStream extends NetStream
{
public function VideoNetStream(connection:NetConnection)
{
super(connection);
}

public function onMetaData(info:Object, … rest):void
{
var evt : NetStatusEvent = new NetStatusEvent(“metaData”);
evt.info = info;
dispatchEvent(evt);
}

public function onCuePoint(info:Object, … rest):void
{
var evt : NetStatusEvent = new NetStatusEvent(“cuePoint”);
evt.info = info;
dispatchEvent(evt);
}
}
[/code]

Напильник номер два

В данной ситуации я даже незнаю кого обвинять, или адоб или создателей firefox (далее фф). Вобщем в ФФ флеш плеер не соображает когда ему скормили неверный урл. вернее 50/50 иногда есть событие что поток не найден а иногда нет, вот например на такой урл [code]http://qweqweqweqweqw[/code] фф не будет ругаться и будет пытаться молча найти его всю свою жизнь, естественно уходы в раздумия на долго не радуют пользователя и он убивает фф :'(.
ИЕ работает как часики ) сразу же ругается на неверный урл.
Напильником номер два мы переопределяем метод play у NetStream и вставляем таймер который отвечает за таймаут соединения(если стрим в течении например минуты не отвечает то мы сам диспатчим событие об ошибке). Код я не буду приводить ибо его нужно чистить и приводить в порядок, а кому нужно тот сам напишет)

Грабли номер три

Если в ситуации описанной выше у ФФ еще делать close() (даже после таймера) и заново подсунуть неверный урл, то ФФ просто падает (play(badUrl) -> close() -> play(newBadUrl));
В данной ситуации нужно еще переопределить метод close() вставив проверку на то как жилось стриму до этого.

и закусочный напильник

Учитывая асинхронность работы NetStream при “нервном пользователе” не успевает сделать close(). На приход в себя, как показывает практика, достаточно 500-1000 мс.

Что я сделал собрав эти грабли с напильниками

У меня получился класс VideoNetStream, который сам справляется с критическими ситуациями, в моем случае он просто игнорирует вызовы всех методов до тех пор пока сервер или не отдаст ответ или пока сам стрим не поймет что он не дождался. я сделал флаг isBusy который показывает окружающему миру, что стрим еще думает.

Если есть какие-то еще “фичи” стрима, пишите, будем добавлять.
Если где-то написал не то говорите )

Продолжение серии может будет, а может и нет )

И немного десерта

читать и смотреть, сначало немного на русском, а потом и официальный сайт
с картинками



Вся правда о Видео во Flex. Часть 4. VideoDisplay – практическое применение, где мой шоколад?

Wednesday, October 10th, 2007

Почему же не получилось шоколада?

Причин в этом несколько.

1. Стабильность

Когда я был маленький, у нас вел программирование “злой дядя” Овсянник В.Н. , “злым” его считали за то, что он валил практически любую программу принесеную на ему на здачу (дз или курсач). Делал он это довольно просто – брал и вводил неадекватные данные (если нужно было ввести строку то пихал в нее этак символов 500, или нажимал клавиши кнопки не в той последовательности), и ПО юного программиста падало. Это было его первым действием и оно было на эффективно почти на все 100%. Естественно юные таланты отправлялись дорабатывать свою программу.

Таким способом я поступил со своим прототипом плеера. Получилось полная лажа.

Если у нас кроме плей и стоп, есть премотка, а еще не дай бог мы решили менять source у
VideoDisplay, то плеер наш “держится” аж 10-15 секунд усиленого клика ). Потом он уходит в ступор и уже не реагирует на кнопки и обратно уже не возвращается, о своем плохом состоянии он ничего никому не говорит. UPD: говорит, и возвращаеться! только ждать нужно ооооочень долго, в зависимости от наклацаного и коннекта у меня оказываеться просто не хвалило терпения дождаться, дождется ли пользователь? Помогает только F5.

2. Удобство для пользователя

Пользователь, сука, нервный.

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

Ситуация 2:
Я пользователь смотрю видео, но некоторые места мне не интересны я начинаю кликать по перемотке и если не дай бог какие-то тормоза (коннект, или машина слабая) и плеер не успевает мгновенно отреагировать то я кликаю еще раз что только усилывает тормоза, затем еще раз… а потом я решаю вернутся назад… вобщем кликаю много.
В при использовании VideoDislpay это вообще фатально ибо, у него не точный seek, что особенно заметно на очень маленьких роликах, он хранит всю(!) истории этих кликов (вернее команд перемодки). т.е. при перемотки он перематывает сначало на первый клик, раздупляется, мотает на второй, и т.д. А пользователь за время раздупления может сделать 5 кликов. И они все отобразятся. Выглядит просто это супер особенно если мотать на разные места, такая машина времени ), пользователь начинает нерничать и кликает еще и еще и плееру становится все хуже и хуже… Я пробовал – можно наклацать так что этот дергаться будет еще секунд 30 :D, а иногда оно просто уходит в ступор.

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

3. Удобство для разработчика

После того как я обернул VideoDisplay захотев шоколада, я захотел исправить ситуацию с неточностью у seek’a. Seek живет все в том же VideoPlayer, уже стало немного страшно. Но не теряя оптимизма я ринулся в бой. В VideoDisplay, плеер (VideoPlayer) объявлен как
[code lang=”actionscript”]
mx_internal var videoPlayer:VideoPlayer = null;
[/code]
вроде ниче страшного, дальше у VideoPlayer есть public метод seek – вообще замечательно, т.е. если сделать класс наследник от VideoDisplay и ему всесто VideoPlayer подсунуть наследника от VideoPlayer с оверайднутым seek’oм ситуация будет спасена. Но не тут то было публичный seek у VideoPlayer’а это иллюзия, фактическая перемотка происходит в приватном методе _seek который использует приватные переменные VideoPlayer’а причем одна из перменных является экземпляром класса VideoPlayerNetStream (наследник от NetStream), который объявлен в самом VideoPlayer.as, т.е. видимость этого класса начинается и заканчивается VideoPlayer’ом. Ну и за ними также тянуться все классы из mx.controls.videoclasses.*. Вобщем-то приплыли.

В результате получили чтобы доработать напильничном пару методов нужно копипастить все классы из mx.controls.videoclasses.* в свой пакетик, делать децельный рефакторинг (небольшой минут 15), потом брать свое приложение и менять в нем mx.controls.VideoDisplay на moy.mega.noviy.VideoDisplay и после этого мы готовы переписать требуемые методы.

Скажите не правдали удобно? на онанизм не похоже? Помоемому похоже.

Вобщем так и было вначале сделано, потом полезли всякие неприятности по стабильности плеера, это “приятная” очередь из seek’ов, уходы плеера в астрал если слишком много клацали по клавишам и т.д.

Сначало была мысль вылечить сам VideoPlayer, но посмотрев еще раз код, всего 3к строк (правда включая коментарии) + то что еще он супер универсальный

VideoPlayer is an easy to use wrapper for Video, NetConnection,
NetStream, etc. that makes playing FLV easy. It supports streaming
from Flash Communication Server (FCS) and http download of FLVs.

примая во внимание всего десяток таймеров, чужой полет чужой мысли, и то что конечный VideoDisplay все равно придется дорабатывать кувалдой-молотком-напильником было принято решение положить орган на эту ветку эволюции и начать свою ветку эволюции (или деградации).

Выводы

  • Не все то золото что блястит.
  • VideoDisplay тупиковая ветка развития. UPD: все еще можно исправить? Лучшее решение это ждать что адоб сам исправит ситуацию
  • Вывод VideoDisplay из тупика своими не поддается оценке времени в человекочасах и никому это особо не нужно при таких раскладах UPD: не все потеряно) Достаем бубен из кармана?
  • Возвращаемся к истокам (Video) и пытаемся родить свой работоспособный, пользователеустойчивый(с) аналог VideoDisplay учитывая, что
    • нам не нужно (пока) support streaming
      from Flash Communication Server (FCS)
    • Конструкция должна быть легкая и устойчивая в примении
    • Постаратся использовать чуть меньше таймеров 🙂
    • Нам не нужен хоровод из сиков
    • его внедрение в готовый код должно занять минимум усилий

Текущий результат

Имеем пока кучу потраченого в никуда времени и плеер который работает, если ничего не трогать.

В следующих сериях вы услышите увлекательные рассказы о NetStream и Video.

UPD: Мотыль Нарожняк подсказал новую ветку развития событий и еще раз показал, что не нужно суетится, а нужно изучать доки как можно внимательнее, [тут еще пара отмазок почему это произошло]).

Но всеравно NetStream”y достанется 😉



Вся правда о Видео во Flex. Часть 3. VideoDisplay – практическое применение

Wednesday, October 10th, 2007

Вообще-то вся правда о видео начала выеснятся именно из практического применения. Мне нужно было написать видео плеер, обычный без наворотов (плей/стоп/пауза/перемотка/че загрузили).

Добавил я VideoDisplay на сцену, кинул слайдер, кнопки, добавил обработчики. Ничего вроде сложного. Но не тут то было. Если с плей/стоп более мение понятно то с перемоткой сразу возникли проблемы. Сначало это туева хуча эксепшинов, если пользователь совершил шаг влево или вправо, причем по всем поводам заиграл null урл, перемотал куда-то вдаль или близь. Подумал, что я что-то не так делаю…

——-
Немного оффтопа:
Почему я ругаю адоб (вернее индусов которые там работают), я просто зол на них, а почему я зол на них? Я не считаю себя супер программистом, или гением и “по умолчанию” я считаю что в комманде разработчиков адоба работают не дураки и всем есть чему у них поучиться (не зря ж они работают там). Поэтому я изначально доверяю их коду, а если прибавить рекламу что “все стало удобнее и легко, и делается все с пол пинка” то и вроде доверия больше. Исходя из этих тезисов получается такая конструкция “Если у тебя что-то не работает, а адоб крут, то наверное это глюк в твоем коде, проверь все 3 раза”.. После чего ты проверяешь пару раз свой код, читаешь хелп, копипастишь из него примеры, а оно нихера не работает. И тут закрадывается сомнение, а может таки это косяк в коде от адоба? Начинается колупание в коде фреймворка. Вы скажете ну и что колупайся, ищи, изучай пиши свои решения, модифицируй существующий код. Я с этим почти согласен, но тут есть одно мрачное НО – это эстимейт. Когда делается проект у него есть сроки, чтобы выставить эти сроки, таратится время на изучение возможности реализации и сроков реализации той или иной функциональности. Естетсвенно почитав оптимистичные доки от адоба “а тут все в пол пинка делается”, прикинув вероятные трудности, ты устанавливаешь сроки реализации проекта, ушлый клиент тоже не дремлет, он тоже знает о фичах и если ты ему скажешь, что я заскиную тебе скрол за месяц, то он очень удивится, и скажет батенька да вы гоните тут работы на 2 часа. Потом придя к взаимовыгодному решению, заполнив бумажки вы стартуете проект, клиент ждет. После этого начинаеться самое интересное, делаешь это “пол пиночное” решение и видишь что ничего не работает, проверяешь себя пару раз(на проверку время-то тратится), вроде все правильно, лезешь в фрейворк начинаешь смотреть там (а миноточки и часы идут), фрейворк не маленьки, вы наверное это заметили ? )), зависимостей много, в результате найдя в чем проблема вы пытаетесь ее решить, сначало малой кровью (очень часто так не получается), затем уже глобальными способами, а время бежит, и способа сделать 36 часов в сутки никто еще не предложил. В итоге мы имеем просроченный дедлайн, если клиент адекватный и ему можно объяснить почему так, то все вроде хорошо, а если нет + мы имеем моральное неудовлетворени, нервотрепка, стрессы, вобщем нету кайфа от процесса. Поэтому я зол на адоб, ну на себя тоже (ибо я не идеален), но видоваты оба (хотя я люблю себя любимого, поэтому адоб больше %) ). Наверное эта ситуация знакома каждому?
——–

…Подумал, что я что-то не так делаю, или я “просто не умею его готовить”, перелопатив свой код я не нашел подвоха, полез во фреймворк и увидел в коде VideoPlayer следующее
[code lang=”actionscript”]
…..
public function play(url:String = null, isLive:Boolean = false, totalTime:Number = -1):void
{
…..
if (!isXnOK())
{
if (_state == CONNECTION_ERROR ||
_ncMgr == null ||
_ncMgr.netConnection == null)
throw new VideoError(VideoError.NO_CONNECTION);
else
{
….
[/code]
Бабах эксепшин, всего лишь 7 эксепшинов бабахается в VideoPlayer на неверный play, pause, seek и т.д. Так лезем в доку, в чем проблемы то, дока молчит, но посмотрев коментарий у VideoPlayer.play() вижу следующую инструкцию
[code lang=”actionscript”]

* Throws an exception if called with no args and no stream
* is connected. Use “stateChange” event and
* connected property to determine when it is
* safe to call this method.

[/code]

упс, думаю я, читатать нужно внимательнее хелп, но потом вспоминаю в хелпе нету этого класса, этот класс спрятан от чужих глаз!
Проверил VideoDisplay, там тоже никто ничего не проверяет.

Ну что же подумал я, не вопрос дабы сильно не напрягатся наследуюсь от VideoDisplay, оберну эти методы проверочками, не пущу эксепшины дальше и будет все в шоколаде. Обернул. Шоколада не получилось.



Вся правда о Видео во Flex. Часть 2. VideoDisplay

Monday, October 8th, 2007

Теперь переходим к VideoDisplay – это просто ахтунг!

В видео дисплее живет класс который называется VideoPlayer (mx.controls.videoClasses.VideoPlayer). Это сущее порождение зла), что мы можем узнать о нем? В хелпе его нету, заглянем ка во внутрь ради спортивного интереса

[code lang=”actionscript”][ExcludeClass]

/**
* @private
* VideoPlayer is an easy to use wrapper for Video, NetConnection,
* NetStream, etc. that makes playing FLV easy. It supports streaming
* from Flash Communication Server (FCS) and http download of FLVs.
*
* <p>VideoPlayer extends Video.</p>
*
* @tiptext VideoPlayer: FLV player
* @helpid ???
*/
public class VideoPlayer extends Video
….
[/code]
Едить-колотить да это супер клад который легко позволит нам работать с видео! Но почему же мы его не видим нигде? да потому что он сырой, недоделанный, причем по коментам сразу видно, что его тупо не успели сделать и спрятали с глаз долой – “только фанаты заглянут внутрь”.

теперь листаем дальше. А там [цензура][цензура][цензура][цензура][цензура]!
[code lang=”actionscript”]
//———————————-
// default times for intervals
//———————————-
public static const DEFAULT_UPDATE_TIME_INTERVAL:Number = 250; // .25 seconds
public static const DEFAULT_UPDATE_PROGRESS_INTERVAL:Number = 250; // .25 seconds
public static const DEFAULT_IDLE_TIMEOUT_INTERVAL:Number = 300000; // five minutes
public static const AUTO_RESIZE_INTERVAL:Number = 100; // .1 seconds
public static const AUTO_RESIZE_PLAYHEAD_TIMEOUT:Number = .5; // .5 seconds
public static const AUTO_RESIZE_METADATA_DELAY_MAX:Number = 5; // .5 seconds
public static const FINISH_AUTO_RESIZE_INTERVAL:Number = 250; // .25 seconds
public static const RTMP_DO_STOP_AT_END_INTERVAL:Number = 500; // .5 seconds
public static const RTMP_DO_SEEK_INTERVAL:Number = 100; // .1 seconds
public static const HTTP_DO_SEEK_INTERVAL:Number = 250; // .25 seconds
public static const HTTP_DO_SEEK_MAX_COUNT:Number = 4; // 4 times * .25 seconds = 1 second
public static const CLOSE_NS_INTERVAL:Number = .25; // .25 secconds
public static const HTTP_DELAYED_BUFFERING_INTERVAL:Number = 100; // .1 seconds
[/code]
представляете какую жопу можно организовать с таким количество таймеров, но не переживайте все 13 интервалов (интересное количество, наверное им все и объясняется) мы использовать не будем, в конструкторе мы проинициализировали всего лишь 9(!) таймеров. Я лично поставлю ящик пива кто сможет не запутавшись, написать и гарантировать мне корректность работы с таким количеством таймеров. А если еще добавить сюда NetStream который подкидывает программеру еще разные приятности, то хочется сказать:

“Респект и Уважуха Адобу! С его лучшим видео!”

а еще спасибо за все заботы о бедных программистах.
В следующих выпусках мы поговорим о практическом применением VideoDisplay и чем это грозит, поговорим NetStream’e и может что-то достанется и Video. До встречи



Вся правда о Видео во Flex. Часть 1. Буфер.

Monday, October 8th, 2007

Начнем с буфера у Video в 9 плеере/AS3.

Раньше было все хорошо, при проигрывании буфер равнялся порции видео которое было доступно для проигрывания/перемотки. Но индусы поразмыслив решили, что это лишняя информация о которой программеру вообще не нужно знать, и теперь мы имеем буфер в размере “децл” по умолчанию он скачет где-то 0.1 – 0.2 секунды, если мы задали буфер ручками то это наше число + этот децл. Спрашивается нахера нам это нужно знать? Мне эта инфа совсем не нужна, мне гораздо интереснее знать на сколько я могу позволить пользователю подвинуть бегунок перемотки, сколько у меня фактически загружено, а не этот “важный” децл. Теперь с подачи индусов у нас отняли все более менее нормальные способы довести до пользователя состояния видео (всего каких-то 3 показателя длинна, сколько уже загружено(в секундах) и где мы играем). Остались только мега извраты для определения состояния видео если нету у видео мета тегов, но мега извраты мы не используем.

*Немного о мега извратах:
самый извратистый изврат это сделать seek в бесконечность в какой-то момент времени и он вернет количество секунд которые на данный момент. Располагая этой инфой можно в приблизительно прикинуть длину видео без мета тегов, и воссоздать наши 3 заветные величины. Но опять же это ИЗВРАЩЕНИЕ.

Скажем дружно “Респект и Уважуха Адобу! С его лучшим видео!”




]]> rss о RIA от 33 Коровы
Забадать RSS!
]]>
~~~~~~