nafigue, почему бы не воспользоваться самым очевидным способом и не изменить в munin.conf эту строчку htmldir ?
насколько я помню, там сейчас автоматически удаляется звук, если ролик содержит популярную лицензированную аудиокомпозицию
Andron_buton, это единственное, что мне приходит на ум, если три раза объяснили причем тут ядра и многопоточность .
Потенциальная цензура и отсутствие четкого неизменяемого API для перекодировки на ютубе.
Romka_Kharkov, было б зачем. Сервису важнее равномерно удовлетворить всех пользователей, а не нагрузить максимальное число ядер. А небольшой самоличный сайт скорее просто подождет конвертации в один поток, чем будет за это платить.
Andron_buton, а я предлагаю вам не только на знакомые ключевые слова реагировать, но понимать их смысл и делать выводы.
"размещение пользовательского видео" подразумевает перекодировку.
Да, тут вроде неплохо поддерживают. У меня как-то нет привычки надеяться на дядю, так что я не слежу за всякими сборочками.
В любом случае не понятно какие преимущества дает windows для этой задачи.
А вы не учитываете, что используете в качестве источника информации Хабр :) Читайте хотя бы повнимательнее.
Webm точно не актуален и не известно будет ли. Видимо, имелось ввиду два контейнера, flv для flash-плагина и mp4 для apple html5. Но я имел ввиду поддержку h.264 железом (по крайней мере простых профилей h.264) и поэтому все равно мое утверждение верное. Внутри-то в обоих случаях h.264. Это кодек никуда не денется.
В принципе, с поддержкой mp4 в nginx, можно отказаться от двойного кодирования и держать только h.264 в контейнере m4v. Возможно, старые не обновленные flash-плагины не будут это играть. Надо бы уточнить когда именно поддержка m4v появилась у флеша.
Вот с профилями h.264 засада. Чтобы уж совсем хорошо было, нужно обеспечить и качественное видео для десктопа и быстро играющееся для мобильных. Тут действительно лучше две копии держать разного разрешения. Вместе с двухпроходным кодированием, требования к процессору еще больше вырастают. Никому же не захочется чтобы от момента заливки видео до появления на сайте прошел час.
Будет, но медленнее. И, я так понял, вы предлагали вообще не перекодировать.
Из термина "пользовательское видео" следует, что видео пользователи будут заливать, а не редакторы или админы. Такие файлы нужно перекодировать обычно.
1 это неправда
2 на windows вообще задолбаешься разнообразные библиотеки искать, а работа с пользовательским видео подразумевает максимально возможное их число.
3. никакие другие кодеки, кроме h.264 (на выходе) для современного интернет-видео не важны.
4. в конкретной реализации ffmpeg и x.264 многопоточность вроде работает. Другой вопрос дает ли она какой-то заметный толк при большом числе потоков.
5. как бы ни везло на первых порах, в любом случае, при настырных попытках перекодирования пользовательского видео любой виртуальный хостинг вас попросит удалиться. А одноядерных VPS будет недостаточно. Свой сервер, конечно нужен. ---------- Добавлено 21.08.2012 в 22:55 ----------
Пользователей сложно заставить размещать видео точно в нужном для стриминга формате, да еще и добавлять метаданные для перемотки. В любом случае встанет вопрос о перекодировке.
myhand, в качестве личного примера, сделаю вид, что послушал вас.
За конфликтность. Ну и когда её бьют, вопросы типа "зачем" не рассматривают обычно.
