флэш/гибкий:прогрессивная загрузка против.RTMP

Question

Я пытаюсь понять и точно определить, когда использовать прогрессивную загрузку, а когда нет.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 кажется более полезным, когда вы хотите защитить ресурс?И это все, что нужно?

Answer 1

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

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

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

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

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

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

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

Answer 2

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

Answer 3

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