Flash / Flex: прогрессивная загрузка против RTMP - PullRequest
Новая
       18

Flash / Flex: прогрессивная загрузка против RTMP

7 голосов
/ 17 ноября 2009

Я пытаюсь понять и действительно точно определить, когда использовать прогрессивную загрузку по сравнению с rtmp в flex / flash Кажется, что главное в том, что rtmp не обслуживается с http, тогда как прогрессивная загрузка -. Поскольку это не rtmp, ресурс защищен, так как нет никакого способа подключиться к серверу rtmp извне swf.

Даже если пользователь может видеть этот объектный код и может определить местоположение 

<object data="http://media.example.com/jw-player/player.swf" >
    <param value="streamer=rtmp://sub.example.com/video
           &amp;file=1330/title/folder2/theflvresource.flv
           &amp;id=FlvPlayer" name="flashvars">
</object>

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

Ответы [ 3 ]

6 голосов
/ 17 ноября 2009

Я согласен с xtat , но хочу добавить гораздо больше.

За и против RTMP (или любого протокола потоковой передачи на основе UDP) по сравнению с «прогрессивной загрузкой» (которая на самом деле является лишь подмножеством потоковой передачи на основе HTTP), по моему не столь скромному мнению:

  • Потоковая передача на основе UDP
    • Pros
      • В настоящее время значительно сложнее воровать потоки
      • В настоящее время поддерживает прямую трансляцию, которая на основе HTTP не
      • Возможность многоадресной передачи, которая может быть желательна в интрасетях
    • Cons
      • Значительно более высокое использование ресурсов по сравнению с подходом на основе http
      • Потребность в специализированных серверах (FMS, Red5, Wowza, что угодно)
      • Более заметная буферизация
      • Проблемы с брандмауэром, особенно у корпоративных клиентов
  • потоковая передача по HTTP
    • Pros
      • Мёртвый простой
      • Может искать в СМИ. FLV и MP4 (с некоторыми усилиями)
    • Cons
      • Тривиально воровать потоки. Например: Real Downloader
      • Прямые трансляции в настоящее время невозможны, но дайте им год. Apple делает это реальностью.
      • нет мульти-кастинга

Весь подход, основанный на HTTP, заполнен и / но / if * if ситуациями, множеством недоразумений относительно того, что является и не возможно, и отсутствием общих определений.

При обсуждении потоковой передачи на основе HTTP люди обращают внимание на две основные характеристики: поиск и регулируемая пропускная способность . Отсюда мы получаем все эти термины, такие как «псевдопоток», «прогрессивная загрузка» и т. Д.

Вот определения, которые я использую для описания потоковых серверов на основе HTTP:

  • регулируемая скорость передачи в битах : файл плоского мультимедиа анализируется сервером и отправляет мультимедиа так быстро, как проигрыватель должен воспроизвести мультимедиа без буферизации.
  • seek : способность веб-сервера осуществлять поиск в медиа и эффективно создавать на лету новый «файл» для использования клиентом. Аналогичен запросу в диапазоне байтов http, за исключением того, что заголовки и медиа-метаданные добавляются / изменяются.
  • прогрессивная загрузка : Просто отправьте файл как можно быстрее. По сути, поместите файл мультимедиа на веб-сервер, который отправляет клиенту «тупым» образом, например, в виде большого файла .iso или .zip.
  • псевдопоток : возможность веб-сервера отправлять мультимедийные файлы клиенту с регулируемой скоростью передачи данных и выполнять поиск в файлах.
2 голосов
/ 17 ноября 2009

В наши дни, если вам не нужно записывать, нет смысла использовать RTMP. HTTP проще и, очевидно, гораздо более широко поддерживается, его легче отлаживать, и он действительно позволяет выполнять поиск даже по CDN. Это то, что я настроил на Viddler.

2 голосов
/ 17 ноября 2009

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

...