LINUX.ORG.RU

Потоковое видео MPEG4 под Линукс!


0

0

Интернет видео для следующего поколения!

Что такое потоковое видео? Обычно, чтобы посмотреть какой-нибудь фильм или просто мультик, мы скачиваем целый файл для того чтобы проиграть его. С помощью же потока, видео данные, посылающиеся на потоковый клиент проигрываются сразу же по принятию этих данных. Такие решения как видео-конференция, видео-по-требованию построены именно на технологии потокового видео.

Приведенная здесь ссылка на документацию рассказывает как настроить простой потоковый видео сервер в кодеке MPEG4.

>>> Streaming MPEG-4 with Linux

anonymous

Проверено: green

Люди кто пробывал жать фильмы и DivX и XviD и как впечатления ? Где можно почитать о них ? У них что общие исходники на определенный момент были ?

anonymous
()

Да ! Рассказите что сейчас стоит использовать при сжатии ? Зачем будущее ?

anonymous
()

Пробывал недавно ffmpeg (ffserver) для стриминга в локалку через v4l - глюкалово еще то - сыроват он еще.
Недавно нашел другую софтину - palantir - совсем безглючный стример + есть свой клиент под винды, а под линухом через мозилу смотрю - multi-part jpeg :)

FreeBSD ★★★
()
Ответ на: комментарий от FreeBSD

Да, ffserver пока сыроват, но в некоторых приложениях он просто незаменим. Например если стримить нужно не прямо с v4l, а получать фреймы из какого-то приложения (которое, возможно, само грабит видео) или файла. Palantir такую задачу не может выполнять.

anonymous
()

А в мпег4 можно звук в формате 5.1 запихнуть?Только не ас3 а кодированный а то ас3 350мегов весит.

anonymous
()

> Интернет видео для следующего поколения!

Твое поколение, видать, не вкусит радости потокового видео. Соображать надо, что пишешь.

anonymous
()


> Обычно, чтобы посмотреть какой-нибудь фильм или просто мультик, мы скачиваем целый файл для того чтобы проиграть его.

Это неправда. Соответственно все остальное - тоже полная чушь.
Проведи эксперимент. Положи файл с фильмом на сервер samba/nfs.
Запусти `mplayer /path/to/movie.avi. И удивись. Файл целиком не
скачивается, и вообще загрузка сети минимальна. Он делает короткие seek'и в начале, а затем получается практически полный
аналог твоего потокового видео.

anonymous
()

> 2 last anonymous

It was just a translation of the original article on Linux Journal!

anonymous
()

> Это неправда. Соответственно все остальное - тоже полная чушь.
> Проведи эксперимент. Положи файл с фильмом на сервер samba/nfs.
> Запусти `mplayer /path/to/movie.avi. И удивись. Файл целиком не
> скачивается, и вообще загрузка сети минимальна. Он делает короткие seek'и в
> начале, а затем получается практически полный
> аналог твоего потокового видео.

Так, енто же как с локального диска получается. Ты попробуй с наших эфтипишников так проиграть! Нашелся умник!

anonymous
()
Ответ на: комментарий от anonymous

> Это неправда. Соответственно все остальное - тоже полная чушь.

Это вы, батенька, чушь городите. Потоковое видео - это нечто иное.

anonymous
()
Ответ на: комментарий от anonymous

Легко! Ставим на закачку с ftp или http mplayer -idx file - и смотри себе на здоровье! Вот только насчет опции не уверен

ShaD0FF
()

Ну раз ты такой умный - обреж половину файла и попробуй его проиграть.
1 половину, потом 2-ю и подумай, в чем разница.

jackill ★★★★★
()
Ответ на: комментарий от jackill

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

ShaD0FF
()
Ответ на: комментарий от ShaD0FF

Эти два метода отличаются тем, что потоковое видео СНАЧАЛА формирует пакет с параметрами потока, а, например, avi записывает свои параметры как в начале файла, так и в конце (индекс). МС МПлеер незаконченный avi проиграть не сможет. Линуксовый МПлеер может, но не всегда корректно. Но вообще-то главное не это. Важно вот что : Когда считываешь файл, то просмотр прервется как только будет достигнут конец файла. При просмотре потока, теоретически, вывод потока будет бесконечен. Если плеер отображает быстрее, чем сервер генерит пакеты, то плеер просто ждет, когда они поступят (теоретически любое заданное время).

mealiv
()
Ответ на: комментарий от ShaD0FF

-- Легко! Ставим на закачку с ftp или http mplayer -idx file - и смотри себе на здоровье! Вот только насчет опции не уверен

нельзя путать стриминг видео/аудио и полустриминг типа wmv/wma или того же avi.
Но! avi должен иметь индекса, иначе -idx ничего не поможет.

uranium
()
Ответ на: комментарий от anonymous


> Это вы, батенька, чушь городите. Потоковое видео - это нечто иное.

Не путай тему. Неправда в том, что в ньюсе говорится про
необходимость полной скачки файла для проигрывания. Это
неправда. От потокового видио конечно имеется несущественное
отличие. Я это отличие указал. На втором этапе (после
получения сведений о структуре файла) это отличие минимально.

anonymous
()
Ответ на: комментарий от anonymous


> Ты попробуй с наших эфтипишников так проиграть! Нашелся умник!

Ничего сверхумного не вижу. Обычные рутинные действия.

wget ftp://server/file.avi -O - | mplayer -cache 8192 -

Прекрасно работает. Еще раз повторяю: файл начинает проигрываться сразу, без полного скачивания.

anonymous
()

stream video

Приятно что появляются такие статьи А то когда по "яшику" идет что нибудь интерестное (Чемпионат мира по хоккею) чтобы транслировать в сетку (99% состояшшей из win) приходится с вмндой связыватся

D_D
()

2FreeBSD Ну и как этот multipart-jpeg ? ваобще смотреть можно ? глаз не боится, под шкаф не прячется ? 

ezhikov
()

А потоковое видео случайно не асоциируется с Real Time протоколами которые обычно работают по UDP без необходимости получения всего файла за счет качества изображения? Может разница между просто закачкой именно в этом????

trink
()

Давайте тогда разбираться что вы считаете потоковым видео.
Что вы думаете, например, о cisco ip-tv?
Четыре года назад я в одной сетке крутил по вечерам фильмы, используя
данный сервер. Вещание ведется бродкастом на определенный адрес,
а сервера эти адреса слушают.
После включения клиентской программы на нужный бродкаст примерно
через три-четыре секунды появляется видео и звук, а дальше уже все
от сетки зависит. С любого места можно смотреть то, что идет.
При этом сервер не грузится.

Что касается точка-точка, как это сделано у микрософта (real video
не трогал - не знаю), то это ведь тоже потоковое видео - люди
спокойно подключались ко мне и отключались посреди трансляции.
Однако не прижился такой метод из-за частых отключений клиентов
и растущей загрузки сервера от числа клиентов.

Надо сказать, что цифровалось все вживую, так что гипотетических
авишек на ftp или чем-нить еще просто не было - только видеокассеты.

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

Главная фишка потокового видео - все в один и тот же момент
смотрят одно и то же. Человек может включиться и отключиться
от трансляции в любой момент. Это телевизор, а файлик
на ftp-шнике - это видак.

jackill ★★★★★
()

2jackill: не путай broadcast и multicast. Это разные вещи.

anonymous
()

народ а какой софт необходим что бы под линухом делать трансляцию для сетки с тв тюнера ?

anonymous
()

2mealiv:

> Важно вот что : Когда считываешь файл, то просмотр прервется как только будет достигнут конец файла. При просмотре потока, >теоретически, вывод потока будет бесконечен. Если плеер отображает быстрее, чем сервер генерит пакеты, то плеер просто ждет, когда они поступят >(теоретически любое заданное время).

Так это тоже неправда в общем случае! Если твоя программа считает, что как только получила конец файла, так надо завершать, она так сделает. Можешь написать такую программу, которая по любому обычному FTP или HTTP будет играть не прерываясь (я имею в виду, что скачиванием занимается тот же wget, а плеер читает растущий файл). Собственно, ничего страшного нет, если написать так, что при наступлении конца файла (read() вернул 0) программа будет так же ждать и периодически делать read(), пока он что-то не прочитает, или пока не скажут хватит. И будет вам потоковое видео? Толку то что, если больше времени ждем, чем смотрим. Настоящее потоковое - это если как раз оно к тебе идет, и в идеале ты вообще можешь заказывать скорость передачи исходя из своих возможностей, а сервер бы это выполнял, скажем, простым выбрасыванием части кусков, которые мог бы передать. И это бы оборачивалось либо пропуском кадров, либо потерей качества картинки. Зато без перерывов. При широковещании эту задачу должно быть возможно возложить не на источник данных, а на промежуточные передающие серверы, обслуживающие конкретных получателей. Вот это специализированная видеотехнология.

anonymous
()

FreeBSD!

плиз, расскажи подробнее про palantir. и работает ли под FreeBSD? или только Линукс? играет ли DivX, или только MPEG4.

я пробовал эпловский Darwin Streaming Server. Облом в том, что он стримует только честные MPEG4 файлы, причем не простоые, а с какой-то синхродорожкой(как точно это называется не помню).

А перегнать DivX в этот формат ничем не получилось. Ни ffmpeg, ни микрософтовский энкодер.

slai

anonymous
()

вспомнил Darwin Streaming Server может работать с так называемыми hinted MPEG-4 файлы.

anonymous
()

mpeg4ip насколько я знаю вполне приличное и законченное решение для того что здесь обсуждают.

shuras
()

Там нехватает только стриминга с dvb девайсов что вполне возможно появится в ближайщее время. Зато поддержка нормальных кодеков и клиенты в асортименте.

shuras
()

Хмм... Всё это интересно, но я делаю так: Качаю с FTP DivX и когда понимаю, что оставшееся время его скачивания меньше длинны фильма (а иногда так получается почти с самого начала), то начинаю смотреть его через mplayer. Что я неправильно делаю?

dem1urg
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.