Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Выпуск мультимедиа-пакета FFmpeg 4.1, opennews (ok), 06-Ноя-18, (0) [смотреть все] А зачем это в наборе мультимедиа-библиотек , A.Stahl (ok), 11:21 , 06-Ноя-18, (1) +2   // Потоковое вещание в шифрованием , Аноним (3), 11:26 , 06-Ноя-18, (3) +6   // разве потоковое вещание не дело сервиса потокового вещания, а не мультимедиа-биб, Антон (??), 12:07 , 06-Ноя-18, (8) –1   // Ffmpeg умеет работать сервисом потокового вещания К О , Annoynymous (ok), 12:23 , 06-Ноя-18, (11) +4   А кодировать видео без крашей и утечек памяти Ffmpeg уже научился , Аноним (19), 13:25 , 06-Ноя-18, (19) –14   Авторизация для потокового вещания тоже доступна , Твоя мамка (?), 14:48 , 06-Ноя-18, (31) +1   Судя по дислайкам - нет , Qwerty (??), 15:05 , 06-Ноя-18, (32) –2   Гугель именно им ютуб кодирует, если не ошибаюсь Поучи их видео кодировать, умн, Аноним (-), 08:14 , 07-Ноя-18, (48) +1   Что-что, а ффмпег в этом плане достаточно надежный Люди и я в тч годами исполь, Аноним (59), 10:11 , 07-Ноя-18, (59) +2   Хм А зачем шифровать потоковое видео Это же не авторизация на сайте, Zenitur (ok), 13:36 , 06-Ноя-18, (26) –3   // КЭП Дабы организовывать закрытые трансляции , фывфывфыв (?), 15:22 , 06-Ноя-18, (33) +3   Да даже обычный https - для защиты приватности, чтобы пров не собирал досье кто , Аноним (-), 08:15 , 07-Ноя-18, (49)   ffmpeg умеет воспроизводить не только файлы, но и по сети Соответственно TLS дл, Mihail Zenkov (ok), 12:49 , 06-Ноя-18, (14)   // CD DVD Болванки умеет прожигать , Аноним (19), 13:31 , 06-Ноя-18, (24) –4   // В нём даже пасьянса нет, какие болванки , A.Stahl (ok), 14:43 , 06-Ноя-18, (29) +7   И директикс не ставит Не то что неро , Аноним (56), 08:56 , 07-Ноя-18, (56)   Какой неугомонный анонимчик Неудачные выходные , Аноним (30), 14:47 , 06-Ноя-18, (30)   Не настолько хорошо, как ты табуретки , anonymous (??), 17:41 , 06-Ноя-18, (38) +4   Почему нельзя работу с TLS оставить плееру Почему линковка с этими библиотеками, Stax (ok), 15:28 , 06-Ноя-18, (34) +3   // Эту хитрую работу со всеми возможными сетевыми протоколами по-любому кто долже, Аноним (36), 16:41 , 06-Ноя-18, (36)   Пускай А зачем объединять демуксеры бинарных форматов и расширенную работу с се, Stax (ok), 20:42 , 06-Ноя-18, (41)   Может потому что демукс протокола от демукса файла не так уж принципиально отлич, Аноним (-), 08:20 , 07-Ноя-18, (50) +1   Я выше написал про вопрос безопасности - поддержка огромного числа контейнеров, , Stax (ok), 13:53 , 07-Ноя-18, (62) +2   с каких пор ffmpeg вам что-то должен вам уже разжевали куча форматов видео _в, пох (?), 20:04 , 08-Ноя-18, (67)   Он должен не мне, а своим пользователям с точки зрения здравого смысла Хотя бы , Stax (ok), 23:25 , 09-Ноя-18, (70)   1 ffmpeg лазит не сам, а через openssl openssh Если этим будет заниматься кто-, Mihail Zenkov (ok), 12:06 , 10-Ноя-18, (71)   тут могут быть сюрпризы - модные-молодежные эшелон-ноденизабудимлефтпад-игого по, пох (?), 13:18 , 12-Ноя-18, (73)   Сейчас еще DASH актуален В нем ютуб вещает, да и остальные веб-сервисы видео в , Аноним (75), 00:54 , 19-Ноя-18, (75)   у него, к счастью, нет пользователей в вашем смысле Ну то есть есть некоторое , пох (?), 13:15 , 12-Ноя-18, (72)   А на чем еще реализовывать критичный к скорости код Безопасность там кстати здо, Аноним (75), 00:50 , 19-Ноя-18, (74)   Потому что круг использования ffmpeg плеерами не ограничивается более того, обы, Аноним (43), 00:10 , 07-Ноя-18, (43) +1   Тайминги Воспроизведение видео завязано на них Надо вовремя прочитать, вовремя, Ordu (ok), 14:17 , 07-Ноя-18, (64) +2   Более того - вся логика DASH сводится к тому что если это не получилось, следующ, Аноним (75), 00:57 , 19-Ноя-18, (76) +1   Да, спасибо за пример Очень показательно Я сам не могу приводить примеров, ибо, Ordu (ok), 03:58 , 19-Ноя-18, (79)   ffmpeg не работает с TLS, это делает сторонная библиотека, которой пользуется ff, ттт (?), 17:16 , 06-Ноя-18, (37)   // Ясен пень, что алгоритма шифрования там нет Но все-таки это именно библиотека с, Stax (ok), 17:50 , 06-Ноя-18, (39)   // Было бы странно если бы он умеючи HTTPSные урлы не умел бы TLS , Аноним (56), 08:57 , 07-Ноя-18, (57)   Затем что ffmpeg и прочие ffplay умеют видео не только локально из файлов, но и , Аноним (-), 08:13 , 07-Ноя-18, (47)   сколько лет работы 4-ядерного проца потребуется, чтобы закодировать в нем 10-мин, Аноним (2), 11:23 , 06-Ноя-18, (2) // В апреле этого года 1 секунда 1080p кодировалась 5 часов Сейчас ситуация измени, Аноним (9), 12:11 , 06-Ноя-18, (9) +9 // Добавим данных маленько Вот, например, на Ryzen 1700x скорость кодирования 0 2 , Crazy Alex (ok), 12:41 , 06-Ноя-18, (13) +2 Вот ещё ссылочка - если коротко, то он здорово улучшился и в прицнипе уже на жив, Crazy Alex (ok), 12:53 , 06-Ноя-18, (15) +2 // При равных опциях cpu-used 0 разница в 40 раз Разница уменьшается до 10 раз п, Mihail Zenkov (ok), 13:25 , 06-Ноя-18, (20) Большинство оптимизаций идет в cpu-used 1, 0 для перфекционистов, которым ЛЮБОЙ, Аноним (-), 08:38 , 07-Ноя-18, (52) BBB в 480p целиком за ночь кодируется в 4 потока, speed 1 3 Это не самый гла, Аноним (-), 08:23 , 07-Ноя-18, (51) // Кому нужны результаты сжатия в 480p в 2018 Пиарщикам Типа, посмотрите, как вс, Аноним (65), 14:49 , 07-Ноя-18, (65) Вяленый достиг готовности ещё в 2012 году Вы все не понимаете о чём говорите , Аноним (68), 09:18 , 09-Ноя-18, (68) А еще ему 480p не нравится, видите ли А пусть этот умник попробует для начала с, Аноним (-), 01:13 , 19-Ноя-18, (78) В 500 кбитах то Тем кто мувик по сети будет смотреть на дохлом канале, например, Аноним (-), 01:06 , 19-Ноя-18, (77) С версии 3 4 до версии 4 0 скорость в наших тестах возрасла в два разаGpu h264Ну, Олег (??), 11:32 , 06-Ноя-18, (4) +2 // В версии 4 1 упала в три , Аноним (19), 13:25 , 06-Ноя-18, (21) –6 // Проверяли , Олег (??), 14:10 , 06-Ноя-18, (28) +1 // Это клоуны пишут , Аноним (45), 07:53 , 07-Ноя-18, (45) Расскажите, чем сейчас в Линуксе можно восстановить цифровую копию с VHS-пленки , h31 (ok), 11:52 , 06-Ноя-18, (6) // Тогда у тебя будет больше мыла Если совсем руками то OpenCV и самому ручками, вс, Ivan_83 (ok), 11:58 , 06-Ноя-18, (7) http www vapoursynth com , Kido Katsuragi (?), 13:24 , 06-Ноя-18, (18) +1 Да тем же сабжем и восстановить, делая не просто кодирование а еще и -vf денойз, Аноним (-), 08:45 , 07-Ноя-18, (53) Похоже, скоро можно будет удобненько нейронно-автоматически раскрашивать ч б вид, Андрей (??), 12:30 , 06-Ноя-18, (12) +1 Нигде внятно не нашел, как прикрутить IntelQuickSync для сжатия H264 на FreeBSD, guest34567 (ok), 13:06 , 06-Ноя-18, (16) // Спроси на канале Anime, Аноним (19), 13:26 , 06-Ноя-18, (22) +4 https unrelenting technology articles freebsd-on-the-thinkpad-x240https www , Аноним (25), 13:35 , 06-Ноя-18, (25) // а если нет Х-ов на сервере какие пакеты еще доставлять Добавил BEIGNET, скомпи, guest2222 (?), 00:05 , 07-Ноя-18, (42) // Кишки MESA - va-drivers для MESA, libdrm и плагин к ней для конкретного gpu Как, Аноним (56), 08:53 , 07-Ноя-18, (54) Собрать пакет , Олег (??), 14:09 , 06-Ноя-18, (27) Такой большой объём изменений каждый выпуск, а кто спонсирует разработку , АнонимЪ (?), 13:21 , 06-Ноя-18, (17) // Ну во всяком случае не мы с , Аноним (35), 16:11 , 06-Ноя-18, (35) Список более менее похож на Just-for-Fun, т е основные разработчки устроены в т, Андрей (??), 05:57 , 07-Ноя-18, (44) Недавно откопал 15 летний КПК Dell Axim X5 320х240, CPU 300MHz Полностью испра, Вот оно че (?), 13:27 , 06-Ноя-18, (23) +3 AV1 разработан альянсом Open Media AOMedia и позиционируется как общедоступный, Андрей (??), 19:00 , 06-Ноя-18, (40) // gpu декодер будет ну, как обычно, не в линуксе , надо же как-то продвигать боле, нах (?), 10:37 , 07-Ноя-18, (60) Теперь на MacOS ffplay показывает черный квадрат вместо видео Как теперь кино с, Аноним (46), 08:04 , 07-Ноя-18, (46) // А это надо было багрепорт ДО релиза писать наверное Можно и после, конечно, но , Аноним (56), 08:55 , 07-Ноя-18, (55) Написать аппле, все как вы любите , Аноним (59), 10:30 , 09-Ноя-18, (69) На FreeBSD прилетел ffmpeg-4 1 Теперь в браузере Firefox на сайте Youtube нельз, iZEN (ok), 09:53 , 07-Ноя-18, (58) Сергей Шаблин Blender dev недавно сказал, что еще Intel делает какие-то оптимиз, Аноним (61), 11:35 , 07-Ноя-18, (61) // Libx264 затачивается под avx-512Правда уже года два пилят, Олег (??), 18:52 , 08-Ноя-18, (66) 1,2,4,6,12,16,17,23,40,46,58,61

Сообщения

[Сортировка по времени | RSS]

1. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+2 +/–
Сообщение от A.Stahl (ok), 06-Ноя-18, 11:21
>TLS А зачем это в наборе мультимедиа-библиотек?
Ответить | Правка | Наверх | Cообщить модератору

	3. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+6 +/–
	Сообщение от Аноним (3), 06-Ноя-18, 11:26
	>>TLS > А зачем это в наборе мультимедиа-библиотек? Потоковое вещание в шифрованием.
	Ответить | Правка | Наверх | Cообщить модератору

	8. "Выпуск мультимедиа-пакета FFmpeg 4.1"	–1 +/–
	Сообщение от Антон (??), 06-Ноя-18, 12:07
	разве потоковое вещание не дело сервиса потокового вещания, а не мультимедиа-библиотеки?
	Ответить | Правка | Наверх | Cообщить модератору

	11. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+4 +/–
	Сообщение от Annoynymous (ok), 06-Ноя-18, 12:23
	Ffmpeg умеет работать сервисом потокового вещания. //К.О.
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Выпуск мультимедиа-пакета FFmpeg 4.1"	–14 +/–
	Сообщение от Аноним (19), 06-Ноя-18, 13:25
	А кодировать видео без крашей и утечек памяти Ffmpeg уже научился?
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+1 +/–
	Сообщение от Твоя мамка (?), 06-Ноя-18, 14:48
	Авторизация для потокового вещания тоже доступна.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Выпуск мультимедиа-пакета FFmpeg 4.1"	–2 +/–
	Сообщение от Qwerty (??), 06-Ноя-18, 15:05
	Судя по дислайкам - нет.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	48. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+1 +/–
	Сообщение от Аноним (-), 07-Ноя-18, 08:14
	> А кодировать видео без крашей и утечек памяти Ffmpeg уже научился? Гугель именно им ютуб кодирует, если не ошибаюсь. Поучи их видео кодировать, умник.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	59. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+2 +/–
	Сообщение от Аноним (59), 07-Ноя-18, 10:11
	Что-что, а ффмпег в этом плане достаточно надежный. Люди(и я в тч) годами используют его для круглосуточного кодирования без проблем. Плохому танцору как говорится.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	26. "Выпуск мультимедиа-пакета FFmpeg 4.1"	–3 +/–
	Сообщение от Zenitur (ok), 06-Ноя-18, 13:36
	Хм. А зачем шифровать потоковое видео? Это же не авторизация на сайте
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	33. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+3 +/–
	Сообщение от фывфывфыв (?), 06-Ноя-18, 15:22
	КЭП: Дабы организовывать закрытые трансляции.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (-), 07-Ноя-18, 08:15
	> Хм. А зачем шифровать потоковое видео? Это же не авторизация на сайте Да даже обычный https - для защиты приватности, чтобы пров не собирал досье кто и что смотрел крупным оптом, например.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	14. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Mihail Zenkov (ok), 06-Ноя-18, 12:49
	ffmpeg умеет воспроизводить не только файлы, но и по сети. Соответственно TLS для https нужен. На сколько я понимаю, теперь для встроенных решений можно не тянуть OpenSSL/LibreSSL, а использовать более компактную mbedTLS.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	24. "Выпуск мультимедиа-пакета FFmpeg 4.1"	–4 +/–
	Сообщение от Аноним (19), 06-Ноя-18, 13:31
	>ffmpeg умеет воспроизводить не только файлы, но и по сети. Соответственно TLS для https нужен. CD/DVD Болванки умеет прожигать?
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+7 +/–
	Сообщение от A.Stahl (ok), 06-Ноя-18, 14:43
	В нём даже пасьянса нет, какие болванки?
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (56), 07-Ноя-18, 08:56
	> В нём даже пасьянса нет, какие болванки? И директикс не ставит. Не то что неро!
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (30), 06-Ноя-18, 14:47
	> CD/DVD Болванки умеет прожигать? Какой неугомонный анонимчик. Неудачные выходные?
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	38. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+4 +/–
	Сообщение от anonymous (??), 06-Ноя-18, 17:41
	> CD/DVD Болванки умеет прожигать? Не настолько хорошо, как ты табуретки.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	34. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+3 +/–
	Сообщение от Stax (ok), 06-Ноя-18, 15:28
	Почему нельзя работу с TLS оставить плееру? Почему линковка с этими библиотеками засунута в библиотеку работы с форматами? Более того, оно даже libssh готово подтянуть туда же для проигрывания через ssh: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/lib... Это просто клиника какая-то, запредельный уровень наплевательства на безопасность. В библиотеку, которая занимается разбором бинарных данных кучи разных форматов с реализациями различной степени качества и потенциально кучей уязвимостей, тащить хитрую работу со всеми возможными сетевыми протоколами, которым можно это самое видео скачать? Далеко ходить не надо, https://security.googleblog.com/2014/01/ffmpeg-and-thousand-... - что совершенно неудивительно с учетом того, что форматов там реально ОЧЕНЬ много, пишут их куча людей, в т.ч. студенты и далеко не все достаточным образом проверено на безопасность - их тесты в целом требуют только эталонного разбора и декодирования форматов. И в этот же код, эти же библиотеки суют HTTP, TLS, RTP, SSH и прочее.. Этому место снаружи, как минимум в коде, который не является общим с демуксером (если уж авторам ffmpeg так хочется дать готовые библоитеки для работы с сетью).
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	36. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (36), 06-Ноя-18, 16:41
	Эту "хитрую работу со всеми возможными сетевыми протоколами" по-любому кто должен будет делать. Так пусть её делает кто-то из команды ffmpeg, совместно и согласованно с остальной командой ffmpeg.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Stax (ok), 06-Ноя-18, 20:42
	Пускай. А зачем объединять демуксеры бинарных форматов и расширенную работу с сетью в одну библиотеку?
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+1 +/–
	Сообщение от Аноним (-), 07-Ноя-18, 08:20
	> Пускай. А зачем объединять демуксеры бинарных форматов и расширенную работу с сетью > в одну библиотеку? Может потому что демукс протокола от демукса файла не так уж принципиально отличается? А в каком-нибудь HLS и DASH так еще одно завязано на другое и гораздо плотнее чем может показаться. Например половина смысла оных: если видно что сеть или что там еще не тянут текущий поток, при запросе очередного куска разрешение видео плавно даунгрейдится до того что фактически пролезает и прожевывается. Прозрачно для юзера и даже в рамках обычного HTTP(S). И вот это требует от декодера осознать проблемы и сообщить уровню выше что мы хотим другой кусок стрима, с другим разрешением. И как бы если оно будет в совсем разных либах, то удачи, конечно, но...
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+2 +/–
	Сообщение от Stax (ok), 07-Ноя-18, 13:53
	Я выше написал про вопрос безопасности - поддержка огромного числа контейнеров, для разбора которых требуются хитрые манипуляции байтами с реализацией на C (и высокими рисками каких-либо уязвимостей, что подтверждается практикой) и код, который умеет ходить по ssh не должны совмещаться. И тем более этого не должно происходить в одной библиотеке, которую потом подключает все кому не лень. И далеко не всем из тех, кто использует ffmpeg нужно работать с сетью - но этот код разом оказывается во всех этих приложениям. Ходить в сеть "прозрачно для юзера", как вы пишете, в т.ч. по ssh, в приложении, которое просто хотело сделать какие-то мультимедиа-конвертации - это очень-очень плохо с точки зрения безопасности. Если вы этого не понимаете, не вижу смысла обсуждать это с вами дальше. Может так станет понятнее, пример приложений, линкующихся к libavformat: telegram-desktop (я может там в приватном чате пароль к архиву кидаю, а оно мне это куда-нибудь по ssh?..), HandBrake-gui (обертка для конвертации), x264 (тупо конвертер и файлика в файлик!! И теперь ВНЕЗАПНО получил возможность ходить по сети как угодно, ему можно передать URL и тп) и т.п.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от пох (?), 08-Ноя-18, 20:04
	> Я выше написал про вопрос безопасности - поддержка огромного числа контейнеров, для > разбора которых требуются хитрые манипуляции байтами с реализацией на C (и > высокими рисками каких-либо уязвимостей, что подтверждается практикой) и код, который > умеет ходить по ssh не должны совмещаться. с каких пор ffmpeg вам что-то "должен"? вам уже разжевали: куча форматов видео _в_принципе_ не существует в виде однозначного файла, точнее, где-то может этот файл и есть, но вам его не отдают. И парсинг этих сетевых радостей ничем не отличается (и да, он такой же или еще менее надежный, нехрен мешать порно с конями с банковскими акаунтами). > Может так станет понятнее, пример приложений, линкующихся к libavformat: telegram-desktop > (я может там в приватном чате пароль к архиву кидаю, а то есть вы уже слили свой пароль телеграмму (без всякого ssh, православнейшим вебом, и совершенно неотличимо от, скажем, авторизации самого телеграмма - можно даже для удобства в один пакет упаковать), но вас беспокоит только то, что он, _теоретически_возможно_, каким-то невероятным образом, утечет ssh'ем (ssh'ем! С риском уже подставить хост потенциального злоумышленника, вот уж глупее не придумать) ? > оно мне это куда-нибудь по ssh?..), HandBrake-gui (обертка для конвертации), x264 x264 - совершенно самостоятельный проект, ffmpeg, наоборот, использует его кодек. Если включить. > (тупо конвертер и файлика в файлик!! И теперь ВНЕЗАПНО получил возможность > ходить по сети как угодно, ему можно передать URL и тп) да, и иногда это вполне удобно, не таскать ненужный двенадцатигиговый файлик через еще один диск, а перекодировать на лету. ну и вишенка на тортике: почти любые форматы, как и почти любые кодеки, внезапно, отключаются при сборке ffmpeg. Но типичный опеннетчик ничего сам собрать, конечно же, не умеет и не будет, ждет ебилдов.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Stax (ok), 09-Ноя-18, 23:25
	>> Я выше написал про вопрос безопасности - поддержка огромного числа контейнеров, для >> разбора которых требуются хитрые манипуляции байтами с реализацией на C (и >> высокими рисками каких-либо уязвимостей, что подтверждается практикой) и код, который >> умеет ходить по ssh не должны совмещаться. > с каких пор ffmpeg вам что-то "должен"? Он должен не мне, а своим пользователям с точки зрения здравого смысла. Хотя бы чтобы не быть насквозь уязвимым рещетом. > вам уже разжевали: куча форматов видео _в_принципе_ не существует в виде однозначного > файла, точнее, где-то может этот файл и есть, но вам его > не отдают. Это редкие исключения, а не правила. И ниоткуда не следует, что работа с абстракцией "это находится не тут" должна быть там же, где разбор бинарного формата. >> оно мне это куда-нибудь по ssh?..), HandBrake-gui (обертка для конвертации), x264 > x264 - совершенно самостоятельный проект, ffmpeg, наоборот, использует его кодек. Если > включить. Да что вы говорите! $ ldd `which x264`|grep libav     libavformat.so.58 => /lib64/libavformat.so.58 (0x00007fe0b585b000)     libavcodec.so.58 => /lib64/libavcodec.so.58 (0x00007fe0b4537000)     libavutil.so.56 => /lib64/libavutil.so.56 (0x00007fe0b44bd000) Что там использует ffmpeg дело десятое. А x264 как утилита командной строки это тулза для конвертации из <что-нибудь> в, собственно, сжатый H.264 поток. Они решили добавить фильтры и расширенные входные форматы. И ради этого линкуются с ffmpeg, в т.ч. libavformat, который любезно готов ходить по сети. Мне вот категорически не нравится, когда то, что всегда было простым, надежным и безопасным локальным конвертером вдруг научилось лазить по сети куда не попадя. Этим должен заниматься кто-то другой. Не примитивная command-line обертка над библиотекой кодера. Но текущее состояние ffmpeg не дает такой возможности. > да, и иногда это вполне удобно, не таскать ненужный двенадцатигиговый файлик через > еще один диск, а перекодировать на лету. Ну идите в свою винду, пользуйтесь комбайнами. А я умею curl, пайпы, vfs и кучу других абстракций. Это юникс, тут так не принято - как минимум потому, что это небезопасно. > ну и вишенка на тортике: почти любые форматы, как и почти любые > кодеки, внезапно, отключаются при сборке ffmpeg. Но типичный опеннетчик ничего сам > собрать, конечно же, не умеет и не будет, ждет ебилдов. А после этого придется пересобрать vlc, x264, telegram-desktop и кучу-кучу всего? Чтобы сделать систему чуточку безопаснее? Вот спасибо!
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Mihail Zenkov (ok), 10-Ноя-18, 12:06
	> Мне вот категорически не нравится, когда то, что всегда было простым, надежным > и безопасным локальным конвертером вдруг научилось лазить по сети куда не > попадя. Этим должен заниматься кто-то другой. Не примитивная command-line обертка над > библиотекой кодера. Но текущее состояние ffmpeg не дает такой возможности. 1. ffmpeg лазит не сам, а через openssl/openssh. Если этим будет заниматься кто-то другой, то почему это будет безопаснее? 2. ffmpeg поддерживает много всего, кроме ssh/https:  async bluray cache concat crypto data ffrtmpcrypt ffrtmphttp file ftp gopher hls http httpproxy https icecast librtmp librtmpe librtmps librtmpt librtmpte libsmbclient libsrt libssh md5 mmsh mmst pipe prompeg rtmp rtmpe rtmps rtmpt rtmpte rtmpts rtp sctp srtp subfile tcp tee tls udp udplite Предлагаете все выпилить, даже явно мультимедиа типа rtmp*/hls ? Как уже отмечали - не будут вещи типа hls работать нормально, если их реализовывать без связи с демуксером. 3. Текущий подход наоборот безопаснее: все плееры и прочий мультимедиа софт использует одну и ту же реализацию из ffmpeg - это упрощает сам софт (меньше кода, меньше багов) и позволяет быстрее выявлять/исправлять проблемы. >> да, и иногда это вполне удобно, не таскать ненужный двенадцатигиговый файлик через >> еще один диск, а перекодировать на лету. > Ну идите в свою винду, пользуйтесь комбайнами. А я умею curl, пайпы, > vfs и кучу других абстракций. Это юникс, тут так не принято > - как минимум потому, что это небезопасно. Я сам ретроград и за unix way, но ffmpeg - правильный комбайн: он покрывает работу мультимедиа форматами, в том числе и с сетевыми, что здорово облегчает жизнь в наше время (практически все мы берем из сети). >> ну и вишенка на тортике: почти любые форматы, как и почти любые >> кодеки, внезапно, отключаются при сборке ffmpeg. Но типичный опеннетчик ничего сам >> собрать, конечно же, не умеет и не будет, ждет ебилдов. > А после этого придется пересобрать vlc, x264, telegram-desktop и кучу-кучу всего? Чтобы > сделать систему чуточку безопаснее? Вот спасибо! Нет, собираете тот же ffmpeg, что и в системе, но с нужными вам опциями. Больше пересобирать ничего не нужно (если линковка была динамической). Можно собрать две версии ffmpeg - с сетью и без и подсовывать их софту через LD_PRELOAD в зависимости от задачи.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от пох (?), 12-Ноя-18, 13:18
	> Нет, собираете тот же ffmpeg, что и в системе, но с нужными вам опциями. Больше пересобирать > ничего не нужно (если линковка была динамической). тут могут быть сюрпризы - модные-молодежные эшелон-ноденизабудимлефтпад-игого поделочки могут оказаться с намертво embedded кривособранным. Но он как раз _будет_ требовать сетевой и tls стек, иначе как же вы в телефсбграмм-десктопе будете видео-то передавать?
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (75), 19-Ноя-18, 00:54
	> Предлагаете все выпилить, даже явно мультимедиа типа rtmp*/hls ? Сейчас еще DASH актуален. В нем ютуб вещает, да и остальные веб-сервисы видео в основном на него переползают. Ну и ffmpeg резонно научили с ним работать. И на input и на output. Чтобы генерить серверам это, а потом как клиенту - жевать то что нагенерили. > 3. Текущий подход наоборот безопаснее: все плееры и прочий мультимедиа софт использует > одну и ту же реализацию из ffmpeg Вот именно. Обновить 1 либу с майнтайнерами которые в курсе политик безопасности - лучше чем 20 мелких, полузаброшенных, где автор чего доброго полагает что его супер-ЯП спасет от всего и вся, так что получается как у мозиллы с пдф и битмесаги с эвалом входных данных.
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	72. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от пох (?), 12-Ноя-18, 13:15
	> Он должен не мне, а своим пользователям у него, к счастью, нет "пользователей" в вашем смысле. Ну то есть есть некоторое количество странных людей, включая меня, использующих именно ffmpeg, но их единицы и они знают что делают, в основном. > Это редкие исключения, а не правила. ffmpeg весь - "редкие исключения", а для "правила" вам вон av1 с единственно-верным кодеком положон. То есть он почти весь - миллион странных форматов и кодеков, и именно ради них и пилится в настоящее время. > А x264 как утилита командной строки это тулза для конвертации из <что-нибудь> в, собственно, > сжатый H.264 поток. Они решили добавить фильтры и расширенные входные форматы. ну и прекрасно - вот им и адресуйте свою попоболь, со словами что они добавили в том числе и https: в качестве формата (а может и quic заодно), и он очень, очень несекьюрно. Вдруг уговорите? к счастью, я использую очень старую версию x264, поскольку никаких чудес в самом кодеке не жду, и меня эта проблема не беспокоит, тем более что использую ее как кодек для ffmpeg и не более. На мой век хватит, x264 не изменится завтра с выходом новой камеры. > Мне вот категорически не нравится, когда то, что всегда было простым, надежным и безопасным > локальным конвертером вы просто не владеете темой, оно им не было со времен Белларда (да и тогда, вероятнее всего, могло нечаянно поисполнять подсунутый "видеофайл" как код, автора интересовали совершенно другие вещи) эта штука всегда была сложной, с кучей особенностей применения. Одной из них, кстати, является возможность собрать ее так, как надо применяющему для его узкоспециального случая. Но, боюсь у авторов x264 случай совсем не ваш - они не для того добавили в свою поделку libavformat, чтобы отрезать часть форматов - наоборот, именно для того и добавляли, чтобы форматы были. > А я умею curl, пайпы, vfs и кучу других абстракций. а знаний не имеете. например, что для mse это все не очень поможет.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	74. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (75), 19-Ноя-18, 00:50
	> Я выше написал про вопрос безопасности - поддержка огромного числа контейнеров, для > разбора которых требуются хитрые манипуляции байтами с реализацией на C А на чем еще реализовывать критичный к скорости код? Безопасность там кстати здорово подтянули - гугель фуззит это добро непрерывно, так что баги чинятся еще до того как их хакеры найдут. И если кто считает что его парсеры валидируются лучше - на честное слово мы ему таки не поверим, пусть делом докажет. Реализовав столько же парсинга с производительностью не хуже и безопаснее. Тогда будет разговор. > (и высокими рисками каких-либо уязвимостей, что подтверждается практикой) Практика сейчас такова что там continious fuzzing и куча тестов вылавливают в парсерах самые чудесатые баги. > и код, который умеет ходить по ssh не должны совмещаться. Очень интересный вывод. Наверное, уровень экспертизы такой же как и с безопасностью. > И тем более этого не должно происходить в одной библиотеке, которую потом подключает > все кому не лень. А может быть, правильный ответ - в том что эта библиотека все-же должна стать безопасной? И таки в этом направлении они хорошо подвинулись, нарулив фуззинг и тесты оптом. Если кто думает что может лучше - пусть придет и покажет, вместо разглагольствований о том что, чему и сколько "должен". Вас никто не заставляет пользоваться этими библиотеками вообще. А то что там парсеров дофига и в них баги случаются - да, человечество придумало дофига форматов и протоколов. Некоторые из них даже навороченные и без багов их все реализовать может быть нетривиально. Но наверное в этом не ffmpeg виноват. И даже более того - лажа будет и с другими ЯП и проч. > И далеко не всем из тех, кто использует ffmpeg нужно работать с сетью > - но этот код разом оказывается во всех этих приложениям. И, собственно, чего? Поэтому предлагается нагнуть тех кто все-таки хочет какое-нибудь потоковое аудио и видео? Так не пойдет. > ssh, в приложении, которое просто хотело сделать какие-то мультимедиа-конвертации - это > очень-очень плохо с точки зрения безопасности. Если вы этого не понимаете, > не вижу смысла обсуждать это с вами дальше. У меня ffmpeg сможет вылезти в сеть только очень гранулярно, контролируемо и тогда когда я этого явно захочу. И вот тогда мне будет вполне удобно и хорошо. Поговорите еще со мной о безопасности, мистер эксперт. > Может так станет понятнее, пример приложений, линкующихся к libavformat: telegram-desktop Пардон, он без сети бесполезен чуть более чем полностью. > (я может там в приватном чате пароль к архиву кидаю, И чего? Там еще и кутя мегов на сто кода. При том это не какие-то парсеры которые фуззером можно прозвонить а круто абстрагированные плюсы, на синтаксическом анализе которых спятит что угодно. Туда же и пихтонр@сты всякие, кстати - там вообще безопасность по методу неуловимого Джо. Когда Джо начинает шуметь, у него находят eval() на входных данных вообще, как в bitmessage (который в отличие от телеги еще и явно пиарился как такой из себя весь секурный, а достаточно то всего разик посмотреть в тот код, чтобы оценить чего ждать от этих кодеров). > а оно мне это куда-нибудь по ssh?..), Оно по ssh будет ломиться только если программа об этом явно попросит. И если твой телеграм уже поимели настолько что он просит либу сходить по ssh - жалкие потуги обрубить фичу в либе тебя явно не спасут, о великий спец по безопасности. > HandBrake-gui (обертка для конвертации), x264 > (тупо конвертер и файлика в файлик!! Так они и не вызывают функций работающих с сетью. Если стремно можно в контейнер вообще засунуть. > И теперь ВНЕЗАПНО получил возможность ходить по сети как угодно, > ему можно передать URL и тп) и т.п. А вот это еще не факт. Впрочем, если handbrake сможет транскодинг сразу с урлы - да это вообще пожалуй фича а не баг.
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	43. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+1 +/–
	Сообщение от Аноним (43), 07-Ноя-18, 00:10
	Потому что круг использования ffmpeg плеерами не ограничивается (более того, обычно он напрямую в плеерах не используется).
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	64. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+2 +/–
	Сообщение от Ordu (ok), 07-Ноя-18, 14:17
	> Почему нельзя работу с TLS оставить плееру? Почему линковка с этими библиотеками засунута в библиотеку работы с форматами? Тайминги. Воспроизведение видео завязано на них. Надо вовремя прочитать, вовремя декодировать и вовремя отрендерить. Если у нас временной лаг на чтении, то это выльется в лаги на экране. Эти проблемы можно решать generic способом включая буферизацию на несколько секунд вперёд, но это приведёт к задержке в несколько секунд (что может быть существенно в каких-то сценариях использования), и к перерасходу памяти. ffmpeg идёт другим путём, он использует стратегии чтения наилучшим образом подходящие для носителя: если мы читаем с жёсткого диска, то достаточно иметь небольшой кеш упреждающего чтения, если мы читаем по сети, то... тут я чесслово не знаю какого масштаба усложнения начинаются, но если предполагать по максимуму, то надо договориться с передающей стороной о том, как много мы хотим читать вперёд, какого размера кусками, как долго ждать до повторной передачи куска, в случае отсутствия подтверждения о получении, надо получая эти куски правильно их переупорядочивать,... большую часть этого на себя берёт стек tcp/ip, но стеку ведь можно подсказать как лучше действовать в данной ситуации. Но вообще может быть любопытной задачей создание какого-нибудь внятного API между декодером и reader'ом, которое позволило бы разнести их по разным адресным пространствам, сохранить гибкость системы при подстройке к конкретной ситуации, не потерять в производительности, и не столкнуться при этом с проблемой breaking changes в каждой минорной версии этого API. Если ты такой умный, как выглядишь, то займись этим -- разнеси код ffmpeg на два процесса и создай API между ними.
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	76. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+1 +/–
	Сообщение от Аноним (75), 19-Ноя-18, 00:57
	> Тайминги. Воспроизведение видео завязано на них. Надо вовремя прочитать, вовремя декодировать > и вовремя отрендерить. Более того - вся логика DASH сводится к тому что если это не получилось, следующий сегмент будет взять с более паршивым качеством. Автоматически. Так что у юзера видео по сети будет такое, какое его железо и сети реально способны прожевать. А не так что мы тут пытаемся 10-мегабитный поток впихивать в несчастного GPRSника до упора, а тот смотрит его рывками по 3 секунды каждые полчаса.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Ordu (ok), 19-Ноя-18, 03:58
	Да, спасибо за пример. Очень показательно. Я сам не могу приводить примеров, ибо не в теме вообще, рассуждаю из самых общих соображений.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от ттт (?), 06-Ноя-18, 17:16
	ffmpeg не работает с TLS, это делает сторонная библиотека, которой пользуется ffmpeg.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	39. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Stax (ok), 06-Ноя-18, 17:50
	Ясен пень, что алгоритма шифрования там нет. Но все-таки это именно библиотека с демуксерами форматов (libavformat) работает с TLS: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/tls.c https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/tls... https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/tls...
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (56), 07-Ноя-18, 08:57
	Было бы странно если бы он умеючи HTTPSные урлы не умел бы TLS :)
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (-), 07-Ноя-18, 08:13
	> А зачем это в наборе мультимедиа-библиотек? Затем что ffmpeg и прочие ffplay умеют видео не только локально из файлов, но и по сети. Включая http(s). Сюрприз.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема