| |
| 2.3, Аноним (3), 11:26, 06/11/2018 [^] [^^] [^^^] [ответить]
| +6 +/– |
>>TLS
> А зачем это в наборе мультимедиа-библиотек?
Потоковое вещание в шифрованием.
| | |
| |
| 3.8, Антон (??), 12:07, 06/11/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
разве потоковое вещание не дело сервиса потокового вещания, а не мультимедиа-библиотеки?
| | |
| |
| |
| 5.19, Аноним (19), 13:25, 06/11/2018 [^] [^^] [^^^] [ответить]
| –14 +/– |
А кодировать видео без крашей и утечек памяти Ffmpeg уже научился?
| | |
| |
| 6.48, Аноним (-), 08:14, 07/11/2018 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> А кодировать видео без крашей и утечек памяти Ffmpeg уже научился?
Гугель именно им ютуб кодирует, если не ошибаюсь. Поучи их видео кодировать, умник.
| | |
| 6.59, Аноним (59), 10:11, 07/11/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Что-что, а ффмпег в этом плане достаточно надежный. Люди(и я в тч) годами используют его для круглосуточного кодирования без проблем. Плохому танцору как говорится.
| | |
|
|
|
| 3.26, Zenitur (ok), 13:36, 06/11/2018 [^] [^^] [^^^] [ответить]
| –3 +/– |
 Хм. А зачем шифровать потоковое видео? Это же не авторизация на сайте
| | |
| |
| 4.49, Аноним (-), 08:15, 07/11/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Хм. А зачем шифровать потоковое видео? Это же не авторизация на сайте
Да даже обычный https - для защиты приватности, чтобы пров не собирал досье кто и что смотрел крупным оптом, например.
| | |
|
|
| 2.14, Mihail Zenkov (ok), 12:49, 06/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
 ffmpeg умеет воспроизводить не только файлы, но и по сети. Соответственно TLS для https нужен.
На сколько я понимаю, теперь для встроенных решений можно не тянуть OpenSSL/LibreSSL, а использовать более компактную mbedTLS.
| | |
| |
| 3.24, Аноним (19), 13:31, 06/11/2018 [^] [^^] [^^^] [ответить]
| –4 +/– | |
>ffmpeg умеет воспроизводить не только файлы, но и по сети. Соответственно TLS для https нужен.
CD/DVD Болванки умеет прожигать?
| | |
| |
| |
| 5.56, Аноним (56), 08:56, 07/11/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> В нём даже пасьянса нет, какие болванки?
И директикс не ставит. Не то что неро!
| | |
|
| 4.30, Аноним (30), 14:47, 06/11/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> CD/DVD Болванки умеет прожигать?
Какой неугомонный анонимчик. Неудачные выходные?
| | |
| 4.38, anonymous (??), 17:41, 06/11/2018 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> CD/DVD Болванки умеет прожигать?
Не настолько хорошо, как ты табуретки.
| | |
|
| 3.34, Stax (ok), 15:28, 06/11/2018 [^] [^^] [^^^] [ответить]
| +3 +/– |
 Почему нельзя работу с TLS оставить плееру? Почему линковка с этими библиотеками засунута в библиотеку работы с форматами? Более того, оно даже libssh готово подтянуть туда же для проигрывания через ssh: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/libssh.c
Это просто клиника какая-то, запредельный уровень наплевательства на безопасность. В библиотеку, которая занимается разбором бинарных данных кучи разных форматов с реализациями различной степени качества и потенциально кучей уязвимостей, тащить хитрую работу со всеми возможными сетевыми протоколами, которым можно это самое видео скачать?
Далеко ходить не надо, https://security.googleblog.com/2014/01/ffmpeg-and-thousand-fixes.html - что совершенно неудивительно с учетом того, что форматов там реально ОЧЕНЬ много, пишут их куча людей, в т.ч. студенты и далеко не все достаточным образом проверено на безопасность - их тесты в целом требуют только эталонного разбора и декодирования форматов. И в этот же код, эти же библиотеки суют HTTP, TLS, RTP, SSH и прочее.. Этому место снаружи, как минимум в коде, который не является общим с демуксером (если уж авторам ffmpeg так хочется дать готовые библоитеки для работы с сетью).
| | |
| |
| 4.36, Аноним (36), 16:41, 06/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
Эту "хитрую работу со всеми возможными сетевыми протоколами" по-любому кто должен будет делать. Так пусть её делает кто-то из команды ffmpeg, совместно и согласованно с остальной командой ffmpeg.
| | |
| |
| 5.41, Stax (ok), 20:42, 06/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
Пускай. А зачем объединять демуксеры бинарных форматов и расширенную работу с сетью в одну библиотеку?
| | |
| |
| 6.50, Аноним (-), 08:20, 07/11/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Пускай. А зачем объединять демуксеры бинарных форматов и расширенную работу с сетью
> в одну библиотеку?
Может потому что демукс протокола от демукса файла не так уж принципиально отличается? А в каком-нибудь HLS и DASH так еще одно завязано на другое и гораздо плотнее чем может показаться.
Например половина смысла оных: если видно что сеть или что там еще не тянут текущий поток, при запросе очередного куска разрешение видео плавно даунгрейдится до того что фактически пролезает и прожевывается. Прозрачно для юзера и даже в рамках обычного HTTP(S). И вот это требует от декодера осознать проблемы и сообщить уровню выше что мы хотим другой кусок стрима, с другим разрешением. И как бы если оно будет в совсем разных либах, то удачи, конечно, но...
| | |
| |
| 7.62, Stax (ok), 13:53, 07/11/2018 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Я выше написал про вопрос безопасности - поддержка огромного числа контейнеров, для разбора которых требуются хитрые манипуляции байтами с реализацией на C (и высокими рисками каких-либо уязвимостей, что подтверждается практикой) и код, который умеет ходить по ssh не должны совмещаться. И тем более этого не должно происходить в одной библиотеке, которую потом подключает все кому не лень. И далеко не всем из тех, кто использует ffmpeg нужно работать с сетью - но этот код разом оказывается во всех этих приложениям.
Ходить в сеть "прозрачно для юзера", как вы пишете, в т.ч. по ssh, в приложении, которое просто хотело сделать какие-то мультимедиа-конвертации - это очень-очень плохо с точки зрения безопасности. Если вы этого не понимаете, не вижу смысла обсуждать это с вами дальше.
Может так станет понятнее, пример приложений, линкующихся к libavformat: telegram-desktop (я может там в приватном чате пароль к архиву кидаю, а оно мне это куда-нибудь по ssh?..), HandBrake-gui (обертка для конвертации), x264 (тупо конвертер и файлика в файлик!! И теперь ВНЕЗАПНО получил возможность ходить по сети как угодно, ему можно передать URL и тп) и т.п.
| | |
| |
| 8.67, пох (?), 20:04, 08/11/2018 [^] [^^] [^^^] [ответить] | +/– | с каких пор ffmpeg вам что-то должен вам уже разжевали куча форматов видео _... текст свёрнут, показать | | |
| |
| 9.70, Stax (ok), 23:25, 09/11/2018 [^] [^^] [^^^] [ответить] | +/– | Он должен не мне, а своим пользователям с точки зрения здравого смысла Хотя бы ... большой текст свёрнут, показать | | |
| |
| |
| 11.73, пох (?), 13:18, 12/11/2018 [^] [^^] [^^^] [ответить] | +/– | тут могут быть сюрпризы - модные-молодежные эшелон-ноденизабудимлефтпад-игого по... текст свёрнут, показать | | |
|
| 10.72, пох (?), 13:15, 12/11/2018 [^] [^^] [^^^] [ответить] | +/– | у него, к счастью, нет пользователей в вашем смысле Ну то есть есть некоторое... текст свёрнут, показать | | |
|
|
| 8.74, Аноним (75), 00:50, 19/11/2018 [^] [^^] [^^^] [ответить] | +/– | А на чем еще реализовывать критичный к скорости код Безопасность там кстати здо... большой текст свёрнут, показать | | |
|
|
|
|
| 4.43, Аноним (43), 00:10, 07/11/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Потому что круг использования ffmpeg плеерами не ограничивается (более того, обычно он напрямую в плеерах не используется).
| | |
| 4.64, Ordu (ok), 14:17, 07/11/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > Почему нельзя работу с TLS оставить плееру? Почему линковка с этими библиотеками засунута в библиотеку работы с форматами?
Тайминги. Воспроизведение видео завязано на них. Надо вовремя прочитать, вовремя декодировать и вовремя отрендерить. Если у нас временной лаг на чтении, то это выльется в лаги на экране. Эти проблемы можно решать generic способом включая буферизацию на несколько секунд вперёд, но это приведёт к задержке в несколько секунд (что может быть существенно в каких-то сценариях использования), и к перерасходу памяти. ffmpeg идёт другим путём, он использует стратегии чтения наилучшим образом подходящие для носителя: если мы читаем с жёсткого диска, то достаточно иметь небольшой кеш упреждающего чтения, если мы читаем по сети, то... тут я чесслово не знаю какого масштаба усложнения начинаются, но если предполагать по максимуму, то надо договориться с передающей стороной о том, как много мы хотим читать вперёд, какого размера кусками, как долго ждать до повторной передачи куска, в случае отсутствия подтверждения о получении, надо получая эти куски правильно их переупорядочивать,... большую часть этого на себя берёт стек tcp/ip, но стеку ведь можно подсказать как лучше действовать в данной ситуации.
Но вообще может быть любопытной задачей создание какого-нибудь внятного API между декодером и reader'ом, которое позволило бы разнести их по разным адресным пространствам, сохранить гибкость системы при подстройке к конкретной ситуации, не потерять в производительности, и не столкнуться при этом с проблемой breaking changes в каждой минорной версии этого API. Если ты такой умный, как выглядишь, то займись этим -- разнеси код ffmpeg на два процесса и создай API между ними.
| | |
| |
| 5.76, Аноним (75), 00:57, 19/11/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Тайминги. Воспроизведение видео завязано на них. Надо вовремя прочитать, вовремя декодировать
> и вовремя отрендерить.
Более того - вся логика DASH сводится к тому что если это не получилось, следующий сегмент будет взять с более паршивым качеством. Автоматически. Так что у юзера видео по сети будет такое, какое его железо и сети реально способны прожевать. А не так что мы тут пытаемся 10-мегабитный поток впихивать в несчастного GPRSника до упора, а тот смотрит его рывками по 3 секунды каждые полчаса.
| | |
| |
| 6.79, Ordu (ok), 03:58, 19/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
Да, спасибо за пример. Очень показательно. Я сам не могу приводить примеров, ибо не в теме вообще, рассуждаю из самых общих соображений.
| | |
|
|
|
|
| 2.37, ттт (?), 17:16, 06/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
ffmpeg не работает с TLS, это делает сторонная библиотека, которой пользуется ffmpeg.
| | |
| |
| |
| 4.57, Аноним (56), 08:57, 07/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
Было бы странно если бы он умеючи HTTPSные урлы не умел бы TLS :)
| | |
|
|
| 2.47, Аноним (-), 08:13, 07/11/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> А зачем это в наборе мультимедиа-библиотек?
Затем что ffmpeg и прочие ffplay умеют видео не только локально из файлов, но и по сети. Включая http(s). Сюрприз.
| | |
|
| 1.2, Аноним (2), 11:23, 06/11/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>AV1 разработан альянсом Open Media (AOMedia) и позиционируется как общедоступный
сколько лет работы 4-ядерного проца потребуется, чтобы закодировать в нем 10-минутный ролик?
| | |
| |
| 2.9, Аноним (9), 12:11, 06/11/2018 [^] [^^] [^^^] [ответить]
| +9 +/– |
В апреле этого года 1 секунда 1080p кодировалась 5 часов. Сейчас ситуация изменилась, но ненамного - результаты тестов широкой публике особо не представляются.
По сути AV1 становится вторым вейландом. Он вот-вот будет готов, чтобы вытеснить все прочие кодеки. Вот еще чуть-чуть. Уже совсем скоро... Его даже начали поддерживать браузеры. То есть не то чтобы начали... Но скоро начнут.
| | |
| |
| |
| 4.20, Mihail Zenkov (ok), 13:25, 06/11/2018 [^] [^^] [^^^] [ответить]
| +/– | |
При равных опциях (cpu-used=0) разница в 40 раз. Разница уменьшается до 10 раз при cpu-used=2 у av1 и cpu-used=0 у vp9.
Если я правильно понял, то при увеличении cpu-used падает качество, так что не понятно, будет ли av1 при таком подходе существенно лучше сжимать, чем vp9.
Вообще как ни крути, а все равно очень медленно, особенно в сравнении с h264.
| | |
| |
| 5.52, Аноним (-), 08:38, 07/11/2018 [^] [^^] [^^^] [ответить] | +/– | Большинство оптимизаций идет в cpu-used 1, 0 для перфекционистов, которым ЛЮБОЙ... большой текст свёрнут, показать | | |
|
|
| 3.51, Аноним (-), 08:23, 07/11/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> В апреле этого года 1 секунда 1080p кодировалась 5 часов.
BBB в 480p целиком за ночь кодируется в 4 потока, speed = 1..3. Это не самый гламурный 0, но тоже весьма ничего.
> результаты тестов широкой публике особо не представляются.
Они меняются по три раза на дню. И при том - в правильную сторону.
> То есть не то чтобы начали... Но скоро начнут.
В смысле? Хромиум его просто берет и играет. Гугля за словом и делом в карман не лезет - вкомитили и включили.
| | |
| |
| 4.65, Аноним (65), 14:49, 07/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
Кому нужны результаты сжатия в 480p в 2018? Пиарщикам? Типа, "посмотрите, как все здорово, обработка не занимает две недели... правда, это справедливо только для sd качества". С тем же успехом можно хвалиться скоростью сжатия видео в 240p.
Как-то модно стало выкатывать полуготовые решения, но зато на каждом углу орать, что это прорыв технологий и будущее. Анон выше уже сравнил этот "прорыв" с вяленым, который лет 10 все никак не достигнет готовности.
| | |
| |
| 5.68, Аноним (68), 09:18, 09/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
Вяленый достиг готовности ещё в 2012 году. Вы все не понимаете о чём говорите.
| | |
| |
| 6.78, Аноним (-), 01:13, 19/11/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Вяленый достиг готовности ещё в 2012 году. Вы все не понимаете о чём говорите.
А еще ему 480p не нравится, видите ли. А пусть этот умник попробует для начала сохранить себе на винч нежатый YUV в 1080p и посмотрит сколько это весит и какая там скорость потока, чтоли. Тогда узнает почему "лайтовые" забеги на посмотреть как вообще кодек были в 480p.
| | |
|
| 5.77, Аноним (-), 01:06, 19/11/2018 [^] [^^] [^^^] [ответить] | +/– | В 500 кбитах то Тем кто мувик по сети будет смотреть на дохлом канале, например... большой текст свёрнут, показать | | |
|
|
|
|
| 1.4, Олег (??), 11:32, 06/11/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
С версии 3.4 до версии 4.0 скорость в наших тестах возрасла в два раза
Gpu h264
Нужно тестить 4.1)
| | |
| 1.6, h31 (ok), 11:52, 06/11/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Расскажите, чем сейчас в Линуксе можно восстановить цифровую копию с VHS-пленки? Даже не для качества, а чтобы весь этот шум и дребезг не увеличивали размер закодированного файла.
| | |
| |
| 2.7, Ivan_83 (ok), 11:58, 06/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
 Тогда у тебя будет больше мыла.
Если совсем руками то OpenCV и самому ручками, всякие готоые фильтры можно через сабж поприменять.
| | |
| 2.53, Аноним (-), 08:45, 07/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
> не для качества, а чтобы весь этот шум и дребезг не
> увеличивали размер закодированного файла.
Да тем же сабжем и восстановить, делая не просто кодирование а еще и -vf=<денойзер_по_вкусу>. Который из них на VHS лучше работает - черт бы его знает, но очень зашумленное видео с мобилы в темноте удалось окультурить очень даже. Я даже и не думал что там столько информации и что оно так хорошо восстановится.
| | |
|
| 1.12, Андрей (??), 12:30, 06/11/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> Для фильтров на основе методов глубинного машинного обучения (DNN), таких как srcnn (Super-Resolution Convolutional Neural Network), подготовлен новый бэкенд на основе libtensorflow;
Похоже, скоро можно будет удобненько нейронно-автоматически раскрашивать ч/б видео, используя софт из недавней новости: https://www.opennet.me/opennews/art.shtml?num=49550
:)
| | |
| |
| |
| 3.42, guest2222 (?), 00:05, 07/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
а если нет Х-ов на сервере? какие пакеты еще доставлять? Добавил BEIGNET, скомпилил. При запуске вылетает с ошибкой:
[AVHWDeviceContext @ 0x80cc1b080] No VA display found for device: /dev/dri/renderD128.
Device creation failed: -22.
[h264 @ 0x80cc17e00] No device available for decoder: device type vaapi needed for codec h264.
kldstat:
1 47 0xffffffff80200000 20647f8 kernel
2 1 0xffffffff82266000 381080 zfs.ko
3 2 0xffffffff825e8000 a380 opensolaris.ko
4 3 0xffffffff825f3000 44d70 ipfw.ko
5 2 0xffffffff82638000 13850 libalias.ko
6 1 0xffffffff8264c000 61a8 ipfw_nat.ko
7 1 0xffffffff82653000 253a0 dummynet.ko
8 1 0xffffffff82b11000 7a2b8 i915kms.ko
9 1 0xffffffff82b8c000 3f8cc drm2.ko
10 4 0xffffffff82bcc000 1ed0 iicbus.ko
11 1 0xffffffff82bce000 e58 iic.ko
12 1 0xffffffff82bcf000 1570 iicbb.ko
| | |
| |
| 4.54, Аноним (56), 08:53, 07/11/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> а если нет Х-ов на сервере? какие пакеты еще доставлять?
Кишки MESA - va-drivers для MESA, libdrm и плагин к ней для конкретного gpu. Как это в бзде называется и есть ли отличия - логично где-то в их вике смотреть.
И список модулей прекрасно, но на нем одном вы далеко не уедете. FFmpeg как бы не будет вызывать напрямую ядерный модуль, или где?!
| | |
|
|
|
| |
| 2.44, Андрей (??), 05:57, 07/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
Список более менее похож на Just-for-Fun, т.е. основные разработчки устроены в типа нон-профит организациях и получают зарплату (и удовольствие), а остальные получают только удовольствие, и вообще им была оказана честь, что их патчи приняли. Вот если бы какие-то ошибки были исправлены! Что даже за деньги не хочется делать.
| | |
|
| 1.23, Вот оно че (?), 13:27, 06/11/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– | |
Недавно откопал 15 летний КПК Dell Axim X5(320х240, CPU 300MHz). Полностью исправный, даже акк не деградировал. Отдал ребенку баловаться. А там еще флеха 2Gb. Думаю, дай-ка попробую погонять видео на нем.
Перекодировал ffmpeg'ом под разрешение экрана, mpeg4, видео поток 128Кб/сек, звук 22050, моно. 1 час видео ~70Мб. Тянет норм, качество картинки удовлетворительное.
Добавил в контекстное меню Thunar'а пункт для перекодировки .avi файлов. Красота!
| | |
| 1.40, Андрей (??), 19:00, 06/11/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 AV1 разработан альянсом Open Media (AOMedia) и позиционируется как общедоступный и не требующий оплаты отчислений свободный формат кодирования видео, который заметно опережает H.264 и VP9 по уровню сжатия; ---пффф, пока единственное что у этого av1 заметно, причем очень и очень сильно, то только то что он на corei7 слайд шоу показывает. а уж про то что на этом же corei7 что то пожать попытаться, в этот av1 я вообще не говорю даже, так как боюсь к моему пенсионному возрасту едва первый фильм только конвертироваться закончится, да и то не факт что вообще до этого момента получиться дожить. аппаратного декодинга нет, и не предвидится, а в софте такое непотребство ну ненужно совершенно.
| | |
| |
| 2.60, нах (?), 10:37, 07/11/2018 [^] [^^] [^^^] [ответить]
| +/– | |
gpu декодер будет (ну, как обычно, не в линуксе), надо же как-то продвигать более мощные видеокарты, майнеры что-то подустали.
а аппаратный это для умных телевизоров и прочей мути - будет, как только код стабилизируется. Не выпускать же какому-нибудь самсуню апдейты прошивок к телевизору - его пользователи этого и не поймут-с.
| | |
|
| 1.46, Аноним (46), 08:04, 07/11/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Теперь на MacOS ffplay показывает черный квадрат вместо видео. Как теперь кино смотреть?
| | |
| |
| 2.55, Аноним (56), 08:55, 07/11/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Теперь на MacOS ffplay показывает черный квадрат вместо видео. Как теперь кино смотреть?
А это надо было багрепорт ДО релиза писать наверное. Можно и после, конечно, но тогда вот так.
| | |
|
| 1.58, iZEN (ok), 09:53, 07/11/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 На FreeBSD прилетел ffmpeg-4.1. Теперь в браузере Firefox на сайте Youtube нельзя выставить разрешение видео больше 720p. В "Статистике для сисадминов" используются кодеки: avc1.64001F, mp4a.40.2. При этом дропнутых кадров 2,5%!
| | |
| 1.61, Аноним (61), 11:35, 07/11/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Сергей Шаблин(Blender dev) недавно сказал, что еще Intel делает какие-то оптимизации для FFMPEG(ну и для Blender тоже) под новые процы. Этих оптимизаций здесь нет или про такие вещи не пишут в новостях?
| | |
| |
| 2.66, Олег (??), 18:52, 08/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
Libx264 затачивается под avx-512
Правда уже года два пилят
| | |
|
|
