Комментарии 16
Выглядит все мило :) Но занимаясь этим 3 года, могу сказать, что это ад :) Не в плане проектировки системы, а надежности работы кодирующих приложений ffmpeg/vlc и даже той же wowza. Память течет, не все видео нормально конвертируется и это получая еще более менее стандартизированое от производителей. В общем весело.
У нас были большие проблемы с WMV. Что касается wowza, то отзывы по ней не всегда хорошие, но прежде всего из-за плохого «customization».
Мы в свое время пользовались wmdrm, потом перешли на DivxOVS, помнится тоже wmv не радовал. Сейчас же для вовзы транскодингом занимается vlc. Тюнингом и допиливанием постоянно занимаются. Но все же wowza себя показывает хорошо, потому что все-таки полноценное решение и не нужно заниматься такой штукой, как отслеживание работы стрима.
а были какие-то численные оценки, сколько серверных ресурсов жрет RTMP сравнительно с HTTP?
Если не ошибаюсь, RTMP на 20-30% потребляет меньше ресурсов нежели HTTP. Но в контексте live stream вещания это не сильно сказывается, потому что по нашим расчетам на 1 поток выделяется 2 ядра при качестве в 800-1000кб.
это точно? RTMP по идее должен потреблять раза в полтора больше, учитывая, что передача файла в сеть вообще ничего не стоит, а синхронизация потока, мне кажется, сильно ест процессор
Очень странно, ведь RTMP требует очень множественного перекопирования в памяти.
Плюс сам по себе RTMP более пухлый, чем сырая отдача mp4
Плюс сам по себе RTMP более пухлый, чем сырая отдача mp4
Не буду спорить, потому что фактически все упирается не в ресурсы сервера, а количество обслуживаемых им клиентов.
По моим представлениям RTMP должен жрать существенно больше, т.к. ему требуется не просто прочесть файл, но и распарсить + найти нужные фреймы + синхронизация и проч.
В то время как HTTP это просто sendfile, а если файл в дисковом кэше, то это вообще молниеносно.
Хотя я это все написал и подумал про skip-ahead (HTTP ?start=), который, наверное, дает какой-то overhead…
В то время как HTTP это просто sendfile, а если файл в дисковом кэше, то это вообще молниеносно.
Хотя я это все написал и подумал про skip-ahead (HTTP ?start=), который, наверное, дает какой-то overhead…
Да, мне тоже многие клиенты жалуются на wowza в плане утечек.
Могу четко сказать, что я бы не стал винить её авторов за это. Дело в том, что такую специфичную задачу, как стриминг на джаве вообще очень сложно решать: очень легко память потерять.
erlyvideo всё таки отличается тем, что он при нормальных условиях не течет.
Могу четко сказать, что я бы не стал винить её авторов за это. Дело в том, что такую специфичную задачу, как стриминг на джаве вообще очень сложно решать: очень легко память потерять.
erlyvideo всё таки отличается тем, что он при нормальных условиях не течет.
А не предпринималось ли попыток использовать некоторые общие черты распространённых видео форматов, дабы качество и скорость улучшить?
Грубо говоря, пережимая из mpeg2 в h264 с ресайзом, «ресайз» можно выполнить ещё в процессе «разжатия». Или motion estimate брать из видео с бОльшим разрешением и использовать в видео с меньшим, таким образом точность получается значительно выше, и характерных артефактов даже при высокой степени сжатия значительно меньше что особенно актуально для низких разрешений.
Грубо говоря, пережимая из mpeg2 в h264 с ресайзом, «ресайз» можно выполнить ещё в процессе «разжатия». Или motion estimate брать из видео с бОльшим разрешением и использовать в видео с меньшим, таким образом точность получается значительно выше, и характерных артефактов даже при высокой степени сжатия значительно меньше что особенно актуально для низких разрешений.
Можно. Конкретно в том проекте, где мы это делали, ресайз как отдельная ступень не применялся, в основном потому, что цепочка трансформации была довольно сложная. Однако если форматов много, отдельный ресайз может иметь право на жизнь.
а как предлагаете использовать motion estimation из одного кодека в другом?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как устроен видео-хостинг