The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Релиз мультимедиа-пакета FFmpeg 2.0

10.07.2013 16:23

Увидел свет релиз мультимедиа-пакета FFmpeg 2.0, включающий набор приложений и коллекцию библиотек для операций над различными мультимедиа-форматами (запись, преобразование и декодирование звуковых и видеоформатов). Кроме изменений, созданных внутри проекта, в новую версию также включены все последние наработки, добавленные в ветки ffmpeg-mt (поддержка многопоточного декодирования) и libav (форк FFmpeg). Пакет распространяется под лицензиями LGPL и GPL, разработка FFmpeg ведётся смежно с проектом MPlayer.

Из изменений, добавленных в 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 с реализацией форматов музыкальных файлов для старых игр.


  1. Главная ссылка к новости (http://ffmpeg.org/pipermail/ff...)
  2. OpenNews: Продолжающийся конфликт между FFmpeg и Libav мешает развитию обоих проектов
Лицензия: CC-BY
Тип: Программы
Ключевые слова: ffmpeg, media, video, audio
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (48) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.2, dq0s4y71 (??), 17:34, 10/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А сильно он сейчас от libav отличается?
     
     
  • 2.3, BratSinot (ok), 17:49, 10/07/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Прочитайте новость и поймете: http://www.opennet.ru/opennews/art.shtml?num=34254
     
     
  • 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 в свой проект.

    Кто там их них лучше, белее и пушистее - время покажет.

     
  • 5.31, dq0s4y71 (??), 12:04, 11/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо.
     
  • 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 в реалтайм и не подавился :)


     

  • 1.5, Аноним (-), 18:36, 10/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А VP9 support в него попал?
     
     
  • 2.8, FFmpegUser (?), 20:32, 10/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    собери с поддержкой libvpx и будет vp9
     
     
  • 3.19, Аноним (-), 06:00, 11/07/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Там что в ffmpeg что в libav были добавлены патчи для этого. Они в этот выпуск попали?
     

  • 1.6, brothermechanic (?), 18:59, 10/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    молодцы, нет слов.
    А если еще этот Wavelet denoiser заработает, то про avisynth можно забыть.
     
     
  • 2.10, Аноним (-), 21:31, 10/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, аналоги masktools будут? Тут-то и оно
     
  • 2.33, ripper (?), 12:09, 11/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    как ffmpeg пересекается с Avisynth, потрудитесь просветить?
     
     
  • 3.46, brothermechanic (?), 17:29, 11/07/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    пространственно-временные фильтры, же
     

  • 1.7, GArik (?), 19:08, 10/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Поддержка библиотеки libgme

    Лучшее изменение :)

     
     
  • 2.26, Loooooker (ok), 11:24, 11/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Дааа, можно им теперь Спектрумовские AY-треки слушать!!! =)
     
  • 2.47, oziris (??), 17:33, 11/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Поддержка библиотеки libgme
    > Лучшее изменение :)

    Вернись, мы все простим.

     

  • 1.9, lucentcode (ok), 21:11, 10/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Когда VP9 добавят? В Git уже довольно давно добавлена поддержка этого формата.
     
     
  • 2.15, Аноним (-), 01:02, 11/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    В какой бранч? Когда последний коммит в этом бранче был?
     
     
  • 3.49, Аноним (-), 09:45, 13/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    4 дня назад
     

  • 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 ютубом. Может, и сейчас пользуются.

     
     
  • 5.35, dq0s4y71 (??), 12:20, 11/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    youtube этого официально не подтверждал, но пару лет назад один из контрибьюторов ffmpeg писал, что находил в ютюбовских роликах следы собственных ошибок, которые он делал а коде ffmpeg! http://multimedia.cx/eggs/googles-youtube-uses-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.

     
  • 2.45, tessel (?), 15:52, 11/07/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ffmpeg за это как раз не отвечает. Курите x264 либу.
     
     
  • 3.48, хрюкотающий зелюк (?), 21:05, 12/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    libx264 разве не для кодирования? разве он умеет декодировать?
     

  • 1.22, Аноним (-), 09:51, 11/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Как его в Debian поставить вместо libav?
     
     
  • 2.36, Аноним (36), 12:31, 11/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    deb-multimedia.org
     

  • 1.39, kurokaze (ok), 14:13, 11/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Из библиотеки libmpcodecs портирован фильтры подавления помех (Wavelet denoiser)

    Заценим. Тот что в mplayer - зело тормозной.
    Хотя и с hqdn3d + gradfun тоже отлично живётся

     
  • 1.43, zburguy (ok), 15:18, 11/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    За Go2Webinar огромнейшее спасибо разработчикам.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    MIRhosting
    Fornex
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру