| |
| |
| 3.4, dq0s4y71 (??), 18:35, 10/07/2013 [^] [^^] [^^^] [ответить]
| +/– |
Читал я эту новость, ей уж год исполнился! Меня интересует текущее положение дел.
| | |
| |
| 4.14, Андрей Уткин (?), 00:14, 11/07/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Мои личные наблюдения пользователя API:
0. и там и там кипит работа;
1. в libav.org много занимаются тотальной перезагрузкой внутренностей, в т. ч. API;
2. в ffmpeg.org мержат из libav.org всё, что можно, ведётся политика "ffmpeg может всё, что может libav";
3. со стороны libav.org утягивания нового функционала и исправлений из ffmpeg.org не ведётся;
4. вследствие п. 3 в libav.org заметно меньше набор фильтров libavfilter, насчёт остального не слежу, скорее всего картина похожая.
| | |
| |
| 5.20, Алексей (??), 07:24, 11/07/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
хм, если libav.org не утягивает новый функционал (нужный пользователям), то это не форк, а экспериментальная ветка, так получается? или пока рано вывод такой делать?
| | |
| |
| 6.24, Андрей Уткин (?), 11:19, 11/07/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> хм, если libav.org не утягивает новый функционал (нужный пользователям), то это не
> форк, а экспериментальная ветка, так получается? или пока рано вывод такой
> делать?
Называйте как хотите, по факту это два полноценных "лагеря", с историей взаимной вражды. Занимаются в лагерях разными вещами, а пользователи пользуются тем, что есть.
В debian по команде apt-get install ffmpeg ставится libav.org, но это уже другая история.
| | |
| 6.32, Аноним (-), 12:08, 11/07/2013 [^] [^^] [^^^] [ответить]
| +/– |
> хм, если libav.org не утягивает новый функционал (нужный пользователям), то это не
> форк, а экспериментальная ветка, так получается?
Это независимый проект. История была такова что некоторых разработчиков достали некоторые моменты портящие им жизнь и они громко хлопнули дверью и отфоркались. Тут сразу и git появился вместо античного SVN и ряд изменений в код вкатили от которых долго отбрыкивались и прочая.
И что харакретно, ffmpeg тоже на git перешел быстренько и все эти изменения вкатил. Однако граждане из libav обозлены на ffmpeg за то что надоевшие проблемы решились только вот так и поэтому его в принципе игнорируют как класс. По этому поводу они могут не париться грузом совместимости и прочая. С другой стороны, участники ffmpeg выцепляют все полезные изменения libav в свой проект.
Кто там их них лучше, белее и пушистее - время покажет.
| | |
|
|
| 4.21, anonim (?), 09:26, 11/07/2013 [^] [^^] [^^^] [ответить]
| +/– |
Недавно пробовал и то и другое для кодирования vp8 - ffmpeg как год назад был быстрее avconv, так и остался. Причем быстрее намного.
| | |
| |
| 5.25, Андрей Уткин (?), 11:23, 11/07/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Недавно пробовал и то и другое для кодирования vp8 - ffmpeg как
> год назад был быстрее avconv, так и остался. Причем быстрее намного.
Кодирование vp8 сейчас (и тем более раньше) и там и там производится гугловской библиотекой libvpx, так что тут про ffmpeg и avconv ничего сказать нельзя.
| | |
| 5.30, Аноним (-), 12:03, 11/07/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Причем быстрее намного.
Может они разные дефолты libvpx передают? Общий смысл прост: чем быстрее кодирование тем хуже соотношение битрейт-качество.
Тем не менее, на realtime дедлайне VP8 спокойно кодировал скринкаст 1024х768 в реалтайм и не подавился :)
| | |
|
|
|
|
| |
| |
| 3.19, Аноним (-), 06:00, 11/07/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
Там что в ffmpeg что в libav были добавлены патчи для этого. Они в этот выпуск попали?
| | |
|
|
| |
| 2.47, oziris (??), 17:33, 11/07/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> Поддержка библиотеки libgme
> Лучшее изменение :)
Вернись, мы все простим.
| | |
|
| 1.11, аннон (?), 22:07, 10/07/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 когда они будут декодинг h264 оптимизировать? не говоря уже про новый h265. где качественные и быстрые оптимизации, под разные x86 процы, и их дополнительные команды. вообщев в репе то асм код есть, но он с бородатых времён не ковырялся совершенно. или разрабы надеются на чудесную работу компилятора gcc?
| | |
| |
| 2.12, Алексей (??), 22:37, 10/07/2013 [^] [^^] [^^^] [ответить]
| +3 +/– |
а нафига оптимизировать под х86, если это все равно fallback решение, а нормальное использует gpu (причем за реализацию драйвер отвечает)?
| | |
| |
| 3.13, аннон (?), 22:58, 10/07/2013 [^] [^^] [^^^] [ответить]
| +/– |
ну да, теперь все ленивые программисты надеются только на аппаратные костыли.
| | |
| 3.17, Аноним (-), 01:47, 11/07/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>нормальное использует gpu (причем за реализацию драйвер отвечает)
С тучей ограничений на формат потока, что проще забыть на гпу
| | |
| |
| 4.29, Аноним (-), 12:01, 11/07/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> С тучей ограничений на формат потока, что проще забыть на гпу
Ну не забить а спихнуть на него часть наиболее тяжелых операций через OpenCL :). Типа постпроцессинга всякого, который параллелится хорошо и ресурсов требует немеряно.
| | |
| |
| 5.37, Аноним (-), 12:37, 11/07/2013 [^] [^^] [^^^] [ответить]
| +/– |
Постпроцессинг потому и пост-, что идёт после декодирования. Но если тот же gradfun допилят на opencl до хорошего состояния, то почему бы и нет?
| | |
|
|
| 3.27, Аноним (-), 11:58, 11/07/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> нормальное использует gpu
Вот только GPU которые бы умели декодировать H.265 или VP9 на аппаратном блоке - пока вообще не выпущено. Подумаешь, мелочи какие.
| | |
| 3.41, kurokaze (ok), 14:17, 11/07/2013 [^] [^^] [^^^] [ответить]
| +/– |
 > а нафига оптимизировать под х86, если это все равно fallback решение, а
> нормальное использует gpu (причем за реализацию драйвер отвечает)?
Ты делаешь это неправильно.
Зачем гпу, если даже fullhd отнимает не более 10% одного ядра процессора?
| | |
| 3.44, qux (ok), 15:37, 11/07/2013 [^] [^^] [^^^] [ответить]
| +/– |
 Выросло поколение... Ничего, что в ходу еще туча железа, которое через GPU не умеет вообще, и которое как раз чувствительно к декодированию на CPU?
Другое дело, что под него скорее всего уже сделано всё, что возможно, но это не к вашему посту.
| | |
|
| 2.16, Аноним (-), 01:13, 11/07/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> когда они будут декодинг h264 оптимизировать?
Вообще-то постоянно оптимизируют. Недавно я смог посмотреть mplayer'ом 720p с youtube без выкидывания кадров на eeepc 701 (celeron 900MHz). Год назад без skipframe=nonref не получалось. Три года назад вообще не получалось — начинался рассинхрон.
| | |
| |
| 3.18, Алексей (??), 03:55, 11/07/2013 [^] [^^] [^^^] [ответить]
| +/– |
а в youtube постоянно оптимизируют все, в том числе перекодируют то что есть (т. к. у них нету ни лимитов по мощностям, ни доп. расходов, а на таком объеме любое улучшение может дать вполне реальную выгоду).
| | |
| |
| 4.23, Андрей Уткин (?), 11:16, 11/07/2013 [^] [^^] [^^^] [ответить]
| +/– |
> а в youtube постоянно оптимизируют все, в том числе перекодируют то что
> есть (т. к. у них нету ни лимитов по мощностям, ни
> доп. расходов, а на таком объеме любое улучшение может дать вполне
> реальную выгоду).
Не знаю, зачем вы вспомнили про youtube, но были факты использования ffmpeg ютубом. Может, и сейчас пользуются.
| | |
| |
| |
| 6.38, Аноним (-), 12:43, 11/07/2013 [^] [^^] [^^^] [ответить]
| +/– |
> youtube этого официально не подтверждал, но пару лет назад один из контрибьюторов
> ffmpeg писал, что находил в ютюбовских роликах следы собственных ошибок, которые
> он делал а коде ffmpeg! http://multimedia.cx/eggs/googles-youtube-uses-ffmpeg/
Скорее всего MEncoder из-за w32codecs, чтобы проще управляться с теперь уже редкой проприетарщиной. Но надо понимать, что в мендкодере используется львинная доля ффмпега
| | |
|
|
|
| 3.28, Аноним (-), 11:59, 11/07/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Вообще-то постоянно оптимизируют. Недавно я смог посмотреть mplayer'ом 720p с youtube
Там битрейт мелкий, вот и весь секрет :)
| | |
|
| 2.34, dq0s4y71 (??), 12:10, 11/07/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> когда они будут декодинг h264 оптимизировать?
Может быть, когда не надо будет платить лицензионные отчисления держателям патентов на алгоритмы H.264? :)
| | |
| 2.40, kurokaze (ok), 14:16, 11/07/2013 [^] [^^] [^^^] [ответить]
| +/– | |
>когда они будут декодинг h264
наверное тогда, когда именно они будут над x264 работать
| | |
| |
| 3.42, Андрей Уткин (?), 14:21, 11/07/2013 [^] [^^] [^^^] [ответить]
| +/– |
>>когда они будут декодинг h264
> наверное тогда, когда именно они будут над x264 работать
декодинг h264 в ffmpeg свой, внутренний, не от libx264.
| | |
|
|
| 1.39, kurokaze (ok), 14:13, 11/07/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Из библиотеки libmpcodecs портирован фильтры подавления помех (Wavelet denoiser)
Заценим. Тот что в mplayer - зело тормозной.
Хотя и с hqdn3d + gradfun тоже отлично живётся
| | |
|
