Уведел свет (http://ffmpeg.org/pipermail/ffmpeg-devel/2013-July/145698.html) релиз мультимедиа-пакета FFmpeg 2.0 (http://ffmpeg.org/download.html), включающего набор приложений и коллекцию библиотек для манипулирования различными мультимедиа форматами (запись, преобразование и декодирование звуковых и видеоформатов). Кроме изменений, созданных внутри проекта, в новую версию также включены все последние наработки, добавленные в ветки ffmpeg-mt (http://gitorious.org/ffmpeg/ffmpeg-mt) (поддержка многопоточного декодирования) и libav (http://libav.org/) (форк FFmpeg). Пакет распространяется под лицензиями LGPL и GPL, разработка FFmpeg ведётся смежно с проектом MPlayer (http://www.mplayerhq.hu/).
Среди изменений, добавленных (http://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=Changelog) в FFmpeg 2.0, можно отметить:
- Поддержка OpenCL для привлечения мощностей GPU для ускорения работы различных компонентов пакета. В настоящее время OpenCL используется только в некоторых фильтрах, таких как фильтр масштабирования видео;
- Поддержка устройств вывода для V4L2 и XVideo;
- Поддержка протокола FTP для доступа к контенту по сети;
- Новые фильтры: curves, perms, aperms, audio phaser, separatefields, telecine, inverse telecine, colorbalance, colorchannelmixer, asetrate, interleave, astats, trim, atrim, extractplanes, avectorscope, zmq, DCT denoiser, vignette, rotate, psnr, 3D LUT. Из библиотеки libmpcodecs портированы фильтры mcdeint, sab и spp. На базе vid.stab подготовлены фильтры стабилизации видео vidstabdetect и vidstabtransform. Полностью переработан фильтр interlace. Из библиотеки libmpcodecs портирован фильтры подавления помех (Wavelet denoiser). Во всех фильтрах произведена унификация синтаксиса опций;
- Добавлены декодировщики для форматов: WebP, Go2Webinar, ADPCM DTK, ADPCM IMA Radical, Apple Intermediate Codec, Escape 130;
- Добавлены кодировщики для форматов: True Audio (TTA), SMPTE 302M Audio;
- Добавлены распаковщики медиа-контейнеров (demuxer): WebP, ADP, RSD, RedSpark. Добавлен декодировщик на базе libquvi;
- Надлежащая поддержка кодирования анимированных GIF-файлов;- В утилите ffplay добавлена поддержка использования фильтров для звука;
- Поддержка формата Monkey's Audio 3.93 и более новых версий;
- Оптимизация производительности кодирования потоков AAC на платформах x86 и MIPS позволила увеличить скорость кодирования на 10%;
- В утилиту ffmpeg добавлены опции "-filter_script" и "-filter_complex_script", позволяющие загрузить из файла описание графа работы фильтра. Увеличена точность расчёта смещений а звуковом потоке при указании опций "-t" и "-ss";
- Поддержка использования фильтров при редактировании по шкале времени;
- В упаковщике медиа-контейнеров (muxer) для формата Matroska появилась возможность помещения индекса в начало файла;
- Поддержка кодирования WavPack через libwavpack. Возможность упаковки медиа-контейнеров с использованием WavPack для форматов raw и Matroska;- В libavfilter обеспечена поддержка разбиение работы на части с обработки каждого задания в отдельном потоке;
- Поддержка генерации и фильтрации потока Hald CLUT;
- Поддержка чередования B-кадров для потока VC-1;- Поддержка библиотеки libgme.
URL: http://ffmpeg.org/pipermail/ffmpeg-devel/2013-July/145698.html
Новость: http://www.opennet.me/opennews/art.shtml?num=37393
А сильно он сейчас от libav отличается?
Прочитайте новость и поймете: http://www.opennet.me/opennews/art.shtml?num=34254
Читал я эту новость, ей уж год исполнился! Меня интересует текущее положение дел.
Мои личные наблюдения пользователя API:
0. и там и там кипит работа;
1. в libav.org много занимаются тотальной перезагрузкой внутренностей, в т. ч. API;
2. в ffmpeg.org мержат из libav.org всё, что можно, ведётся политика "ffmpeg может всё, что может libav";
3. со стороны libav.org утягивания нового функционала и исправлений из ffmpeg.org не ведётся;
4. вследствие п. 3 в libav.org заметно меньше набор фильтров libavfilter, насчёт остального не слежу, скорее всего картина похожая.
хм, если libav.org не утягивает новый функционал (нужный пользователям), то это не форк, а экспериментальная ветка, так получается? или пока рано вывод такой делать?
> хм, если libav.org не утягивает новый функционал (нужный пользователям), то это не
> форк, а экспериментальная ветка, так получается? или пока рано вывод такой
> делать?Называйте как хотите, по факту это два полноценных "лагеря", с историей взаимной вражды. Занимаются в лагерях разными вещами, а пользователи пользуются тем, что есть.
В debian по команде apt-get install ffmpeg ставится libav.org, но это уже другая история.
> хм, если libav.org не утягивает новый функционал (нужный пользователям), то это не
> форк, а экспериментальная ветка, так получается?Это независимый проект. История была такова что некоторых разработчиков достали некоторые моменты портящие им жизнь и они громко хлопнули дверью и отфоркались. Тут сразу и git появился вместо античного SVN и ряд изменений в код вкатили от которых долго отбрыкивались и прочая.
И что харакретно, ffmpeg тоже на git перешел быстренько и все эти изменения вкатил. Однако граждане из libav обозлены на ffmpeg за то что надоевшие проблемы решились только вот так и поэтому его в принципе игнорируют как класс. По этому поводу они могут не париться грузом совместимости и прочая. С другой стороны, участники ffmpeg выцепляют все полезные изменения libav в свой проект.
Кто там их них лучше, белее и пушистее - время покажет.
Спасибо.
Недавно пробовал и то и другое для кодирования vp8 - ffmpeg как год назад был быстрее avconv, так и остался. Причем быстрее намного.
> Недавно пробовал и то и другое для кодирования vp8 - ffmpeg как
> год назад был быстрее avconv, так и остался. Причем быстрее намного.Кодирование vp8 сейчас (и тем более раньше) и там и там производится гугловской библиотекой libvpx, так что тут про ffmpeg и avconv ничего сказать нельзя.
> Причем быстрее намного.Может они разные дефолты libvpx передают? Общий смысл прост: чем быстрее кодирование тем хуже соотношение битрейт-качество.
Тем не менее, на realtime дедлайне VP8 спокойно кодировал скринкаст 1024х768 в реалтайм и не подавился :)
А VP9 support в него попал?
собери с поддержкой libvpx и будет vp9
Там что в ffmpeg что в libav были добавлены патчи для этого. Они в этот выпуск попали?
молодцы, нет слов.
А если еще этот Wavelet denoiser заработает, то про avisynth можно забыть.
Ага, аналоги masktools будут? Тут-то и оно
как ffmpeg пересекается с Avisynth, потрудитесь просветить?
пространственно-временные фильтры, же
> Поддержка библиотеки libgmeЛучшее изменение :)
Дааа, можно им теперь Спектрумовские AY-треки слушать!!! =)
>> Поддержка библиотеки libgme
> Лучшее изменение :)Вернись, мы все простим.
Когда VP9 добавят? В Git уже довольно давно добавлена поддержка этого формата.
В какой бранч? Когда последний коммит в этом бранче был?
4 дня назад
когда они будут декодинг h264 оптимизировать? не говоря уже про новый h265. где качественные и быстрые оптимизации, под разные x86 процы, и их дополнительные команды. вообщев в репе то асм код есть, но он с бородатых времён не ковырялся совершенно. или разрабы надеются на чудесную работу компилятора gcc?
а нафига оптимизировать под х86, если это все равно fallback решение, а нормальное использует gpu (причем за реализацию драйвер отвечает)?
ну да, теперь все ленивые программисты надеются только на аппаратные костыли.
>нормальное использует gpu (причем за реализацию драйвер отвечает)С тучей ограничений на формат потока, что проще забыть на гпу
> С тучей ограничений на формат потока, что проще забыть на гпуНу не забить а спихнуть на него часть наиболее тяжелых операций через OpenCL :). Типа постпроцессинга всякого, который параллелится хорошо и ресурсов требует немеряно.
Постпроцессинг потому и пост-, что идёт после декодирования. Но если тот же gradfun допилят на opencl до хорошего состояния, то почему бы и нет?
> нормальное использует gpuВот только GPU которые бы умели декодировать H.265 или VP9 на аппаратном блоке - пока вообще не выпущено. Подумаешь, мелочи какие.
> а нафига оптимизировать под х86, если это все равно fallback решение, а
> нормальное использует gpu (причем за реализацию драйвер отвечает)?Ты делаешь это неправильно.
Зачем гпу, если даже fullhd отнимает не более 10% одного ядра процессора?
Выросло поколение... Ничего, что в ходу еще туча железа, которое через GPU не умеет вообще, и которое как раз чувствительно к декодированию на CPU?
Другое дело, что под него скорее всего уже сделано всё, что возможно, но это не к вашему посту.
> когда они будут декодинг h264 оптимизировать?Вообще-то постоянно оптимизируют. Недавно я смог посмотреть mplayer'ом 720p с youtube без выкидывания кадров на eeepc 701 (celeron 900MHz). Год назад без skipframe=nonref не получалось. Три года назад вообще не получалось — начинался рассинхрон.
а в youtube постоянно оптимизируют все, в том числе перекодируют то что есть (т. к. у них нету ни лимитов по мощностям, ни доп. расходов, а на таком объеме любое улучшение может дать вполне реальную выгоду).
> а в youtube постоянно оптимизируют все, в том числе перекодируют то что
> есть (т. к. у них нету ни лимитов по мощностям, ни
> доп. расходов, а на таком объеме любое улучшение может дать вполне
> реальную выгоду).Не знаю, зачем вы вспомнили про youtube, но были факты использования ffmpeg ютубом. Может, и сейчас пользуются.
youtube этого официально не подтверждал, но пару лет назад один из контрибьюторов ffmpeg писал, что находил в ютюбовских роликах следы собственных ошибок, которые он делал а коде ffmpeg! http://multimedia.cx/eggs/googles-youtube-uses-ffmpeg/
> youtube этого официально не подтверждал, но пару лет назад один из контрибьюторов
> ffmpeg писал, что находил в ютюбовских роликах следы собственных ошибок, которые
> он делал а коде ffmpeg! http://multimedia.cx/eggs/googles-youtube-uses-ffmpeg/Скорее всего MEncoder из-за w32codecs, чтобы проще управляться с теперь уже редкой проприетарщиной. Но надо понимать, что в мендкодере используется львинная доля ффмпега
> Вообще-то постоянно оптимизируют. Недавно я смог посмотреть mplayer'ом 720p с youtubeТам битрейт мелкий, вот и весь секрет :)
> когда они будут декодинг h264 оптимизировать?Может быть, когда не надо будет платить лицензионные отчисления держателям патентов на алгоритмы H.264? :)
>когда они будут декодинг h264наверное тогда, когда именно они будут над x264 работать
>>когда они будут декодинг h264
> наверное тогда, когда именно они будут над x264 работатьдекодинг h264 в ffmpeg свой, внутренний, не от libx264.
ffmpeg за это как раз не отвечает. Курите x264 либу.
libx264 разве не для кодирования? разве он умеет декодировать?
Как его в Debian поставить вместо libav?
deb-multimedia.org
>Из библиотеки libmpcodecs портирован фильтры подавления помех (Wavelet denoiser)Заценим. Тот что в mplayer - зело тормозной.
Хотя и с hqdn3d + gradfun тоже отлично живётся
За Go2Webinar огромнейшее спасибо разработчикам.