[devel] Сборка ffmpeg в p8

[devel] Сборка ffmpeg в p8

[Vitaly Lipatov]

Всем добрый день!

Вопрос о сборке ffmpeg в p8 очень интересный, потому что попытки его 
решения выявляют ряд проблем и ограничений, многие из которых не носят 
технического характера.
Так получилось, что так или иначе тему ffmpeg я обсуждал с разными 
специалистами, но они не всегда знали мнение друг друга, поэтому я хотел 
бы их увидеть в этой цепочке обсуждения.

На самом деле я очень мало разбираюсь в проблеме. Я не собирал ffmpeg, и 
не проводил ту большую работу, которую провёл rider@ в Сизифе, благодаря 
которой мы не только получили актуальную версию ffmpeg, но и знаем 
теперь о том, что переход возможен.

Итак. Как обычно, всё начинается с того, что почти все программы, 
хотящие воспроизводить видео, хотят использовать ffmpeg. Которого — 
неожиданно — в p8 нет.

Среди них такие базовые в наше время программы, как chromium и firefox.
Кстати, у них интересное отличие. Если chromium просто несёт ffmpeg 
внутри себя и собирает его в библиотеку, которую носит с собой, то 
firefox носит с собой некоторые огрызки и headers, а потом при 
исполнении перебирает по списку, что он может загрузить из
   "libavcodec-ffmpeg.so.57",
   "libavcodec-ffmpeg.so.56",
   "libavcodec.so.57",
   "libavcodec.so.56",
   "libavcodec.so.55",
   "libavcodec.so.54",
   "libavcodec.so.53",

Что интересно с chromium. Многие библиотеки, которые он несёт с собой, 
он собирает динамически и кладёт в свой каталог:
/usr/lib64/chromium/libffmpeg.so
/usr/lib64/chromium/libicui18n.so
/usr/lib64/chromium/libicuuc.so
/usr/lib64/chromium/libv8.so

Кто даёт гарантии, что какие-то библиотеки, используемые chromium, не 
слинкуются с какими-то системными вариантами этих библиотек и chromium 
не начнёт падать?
В тоже время один из аргументов против моего робкого предложения собрать 
ffmpeg в %_libdir/ffmpeg, чтобы он никому не мешал кроме тех, кто решит 
явно с ним линковаться, заключается как раз в попытке избежать такой 
ситуации.

Далее. Сейчас очень популярным является создание desktop-программ на 
движке Electon (всё началось с редактора Atom, потом MS Visual Studio 
Code, клиенты Skype, VK Messenger, разные там Franz, WebTorrent, 
PopcornTime, Sia UI и пр).
Если посмотреть на то, как electron собран, видно, с какими библиотеками 
он собран или носит с собой.
$ rpm -ql electron
/usr/lib64/electron/electron
/usr/lib64/electron/icudtl.dat
/usr/lib64/electron/libffmpeg.so
/usr/lib64/electron/libnode.so

Возможность собрать крупный проект, используя системные библиотеки 
дистрибутива — это свойство не только проекта, но ещё и показатель 
зрелости дистрибутива. Это же простой вопрос — можно ли построить на 
платформе что-то стабильное, или всё надо принести с собой.

Вот у нас (а может только у меня в системе) есть 3 библиотеки libpng 
одновременно:
$ ls /usr/lib64/libpng*.so.*.0 -1
/usr/lib64/libpng12.so.0.50.0
/usr/lib64/libpng15.so.15.28.0
/usr/lib64/libpng16.so.16.29.0
и этого не пугает никого.
В тоже время появление альтернативных библиотек ffmpeg выглядит страшно.

Я слышал простое предложение носить линковаться с ffmpeg статически. 
Конечно, я никогда не стану собирать незаметно ffmpeg внутри пакета и 
линковаться с ней. Я бы собрал некий ffmpeg-devel-static со статическими 
библиотеками и собирался с ней. Но если мы на простой проблеме так легко 
отказываемся от динамической линковки, зачем в других случаях 
рассказывать, как важно иметь возможность в случае необходимости 
пересобирать библиотеку с security fixes, не пересобирая все проекты, её 
использующие.
Я уж молчу о разделении памяти и совсем отдельная тема, что смена 
способа линковки может вызывать лицензионные столкновения.

Затрудняюсь привести все аргументы против сборки в p8, которые я услышал 
от уважаемых коллег. Мне показалось, что частично они защищают 
репозиторий от недальновидных мантейнеров, а частично выглядят немного 
смешно. И почти не носят технический характер. Поэтому я прошу, если 
аргументы против остались в силе, процитировать их здесь самостоятельно.

Закончу фразой, что репозиторий, в который нельзя собрать пакет, 
становится не интересен.


P.S.
А mplayer в Сизифе слинкован с десятками сумасшедших библиотек проекта 
samba. Видимо, со всем содержимым
/usr/lib64/samba/:
...
	libutil-tdb-samba4.so => /usr/lib64/samba/libutil-tdb-samba4.so 
(0x00007f3138760000)
	libsamba-sockets-samba4.so => 
/usr/lib64/samba/libsamba-sockets-samba4.so (0x00007f3138548000)
...

$ ldd /usr/bin/mplayer | grep samba | wc -l
54


-- 
С уважением,
Виталий Липатов,
Etersoft

Re: [devel] Сборка ffmpeg в p8

[Sergey V Turchin]

On Friday, 21 July 2017 23:58:17 MSK Vitaly Lipatov wrote:

[...]
> Конечно, я никогда не стану собирать незаметно ffmpeg внутри пакета и
> линковаться с ней.
А зря. Никто не заметил бы, если бы при сборке для p8 telegram-desktop 
тихонечко клал в уголок доступные ему одному библиотеки, как делают chromium, 
firefox и подобные.

[...]

-- 
Regards, Sergey.

Re: [devel] Сборка ffmpeg в p8

[Motsyo Gennadi aka Drool]

22.07.2017 09:27, Anton Farygin пишет:
> Это с одной стороны. С другой стороны - stable на то он и stable, что бы
> там никто не проводил подобных "фокусов" по смене одной из ключевых
> библиотек системы. Лучше и проще дождаться p9 и там то уж точно всё
> будет прекрасно.

	p9 идеальный вариант решения проблемы, но все же есть некоторый набор 
софта, который из-за libav вместо ffmpeg либо криво работает (mpv и 
субтитры), либо малопригоден (audacity без ffmpeg имеет смешной набор 
поддерживаемых форматов).

Re: [devel] bundled libraries

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

On Sat, Jul 22, 2017 at 10:35:34AM +0300, Sergey V Turchin wrote:
> On Friday, 21 July 2017 23:58:17 MSK Vitaly Lipatov wrote:
> 
> [...]
> > Конечно, я никогда не стану собирать незаметно ffmpeg внутри пакета и
> > линковаться с ней.
> А зря. Никто не заметил бы,

В логе сборки это очень заметно.

См. тж.
https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries
https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
https://fedoraproject.org/wiki/Bundled_Libraries_Virtual_Provides


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Сборка ffmpeg в p8

[Alexey Gladkov]

On Sat, Jul 22, 2017 at 10:35:34AM +0300, Sergey V Turchin wrote:
> On Friday, 21 July 2017 23:58:17 MSK Vitaly Lipatov wrote:
> 
> [...]
> > Конечно, я никогда не стану собирать незаметно ffmpeg внутри пакета и
> > линковаться с ней.
> А зря. Никто не заметил бы, если бы при сборке для p8 telegram-desktop 
> тихонечко клал в уголок доступные ему одному библиотеки, как делают chromium, 
> firefox и подобные.

И оба эти проекта поступают неправильно. Некласть их внутрь не получается
по ряду причин. Проекты используют внутренний API или патчат код
библиотек.

-- 
Rgrds, legion

Re: [devel] Сборка ffmpeg в p8

[Sergey V Turchin]

On Saturday, 22 July 2017 12:49:32 MSK Alexey Gladkov wrote:
> On Sat, Jul 22, 2017 at 10:35:34AM +0300, Sergey V Turchin wrote:
> > On Friday, 21 July 2017 23:58:17 MSK Vitaly Lipatov wrote:
> > 
> > [...]
> > 
> > > Конечно, я никогда не стану собирать незаметно ffmpeg внутри пакета и
> > > линковаться с ней.
> > 
> > А зря. Никто не заметил бы, если бы при сборке для p8 telegram-desktop
> > тихонечко клал в уголок доступные ему одному библиотеки, как делают
> > chromium, firefox и подобные.
> 
> И оба эти проекта поступают неправильно. 
Не оба, а побольше. У меня парочка есть, например.

> Некласть их внутрь не получается по ряду причин.
Я и раньше был уверен и про "ряд" и про "причин".

> Проекты используют внутренний API или патчат код библиотек.
Или используют API ffmpeg.

-- 
Regards, Sergey.

Re: [devel] bundled libraries

[Sergey V Turchin]

On Saturday, 22 July 2017 12:30:47 MSK Dmitry V wrote:
> On Sat, Jul 22, 2017 at 10:35:34AM +0300, Sergey V Turchin wrote:
> > On Friday, 21 July 2017 23:58:17 MSK Vitaly Lipatov wrote:
> > 
> > [...]
> > 
> > > Конечно, я никогда не стану собирать незаметно ffmpeg внутри пакета и
> > > линковаться с ней.
> > 
> > А зря. Никто не заметил бы,
> 
> В логе сборки это очень заметно.
Да я образно. Пользователи не читают эти логи. ;-)

> См. тж.
И так всё понятно.

[...]

-- 
Regards, Sergey.

Re: [devel] Сборка ffmpeg в p8

[Alexey V. Vissarionov]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

On 22-Jul-2017 10:35:34 +0300, Sergey V Turchin wrote:

 > > Конечно, я никогда не стану собирать незаметно ffmpeg
 > > внутри пакета и линковаться с ней.
 > А зря. Никто не заметил бы, если бы при сборке для p8
 > telegram-desktop тихонечко клал в уголок доступные ему
 > одному библиотеки, как делают chromium, firefox и подобные.

Чтобы не просто не заметили, а даже случайно не наткнулись,
подобные библиотеки полагается либо вкомпилячивать статически,
либо делать общесистемными.

В частности, какой-нибудь gnutls лучше вообще не использовать,
а если без него вообще никак нельзя обойтись, то собрать пакет
-devel-static (Provides: %name-devel) и впредь использовать его.


-- 
Alexey V. Vissarionov
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [devel] Сборка ffmpeg в p8

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 2422 bytes --]

Здравствуйте Alexey V. Vissarionov
  В сообщении от 24 июля 2017 Alexey V. Vissarionov написал(a):
> Чтобы не просто не заметили, а даже случайно не наткнулись,
> подобные библиотеки полагается либо вкомпилячивать статически,
> либо делать общесистемными.

Как это в общесистемные не наткнутся. Не понял ваши мысли. 
А если делать отдельный статический пакет, да ещё если ое будет 
провайдить динамический (т.е. вводить мантейнера других пакетов 
в заблуждение), то такая чехарда начнётся ...

А так. допустим пакет N-libs.rpm таскает в себе динамические 
библиотеки  ffmpeg для пакета N (вариант N-libs и N один и 
тот-же пакет), которые лежат в /usr/libs/N-libs/ffmpeg, да ещё 
файлы *.so лежат в N-libs-devel и N-libs  никак не провайдит 
ffmpeg.  
Что в этом страшного, кроме избыточности?

Продолжаем. 

Про удаление избыточности:
Если пакеты K, L и М хотят использовать ffmpeg из N-libs, а не 
использовать libav, то не является-ли достаточным условием, что 
в них стоял запрет на линковку с libav. 

Осталось понять как этот запрет можно реализовать в рамках 
существующей сборочной реальности. 
Пальцем в небо:
Типа антидота-пустышки, который отвергал линковку с реальным 
libav. - я думаю нереализуемо.
Какие-то сборочные зависимости - если есть N-lib, то в сборочнице 
не должен находится ffmpeg. 


-- 
  А ещё говорят так  (fortune): 
 
Actually, my goal is to have a sandwich named after me. 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Сборка ffmpeg в p8

[Sergey V Turchin]

On Monday, 24 July 2017 09:31:41 MSK Alexey V wrote:
> On 22-Jul-2017 10:35:34 +0300, Sergey V Turchin wrote:
>  > > Конечно, я никогда не стану собирать незаметно ffmpeg
>  > > внутри пакета и линковаться с ней.
>  > 
>  > А зря. Никто не заметил бы, если бы при сборке для p8
>  > telegram-desktop тихонечко клал в уголок доступные ему
>  > одному библиотеки, как делают chromium, firefox и подобные.
> 
> Чтобы не просто не заметили, а даже случайно не наткнулись,
> подобные библиотеки полагается либо вкомпилячивать статически,
> либо делать общесистемными.
Для этого достаточно собрать динамически, положить в отдельный каталог и не 
паковать заголовки.

[...]

-- 
Regards, Sergey.

Re: [devel] Сборка ffmpeg в p8

[Alexey V. Vissarionov]

[-- Attachment #1: Type: text/plain, Size: 2867 bytes --]

On 24-Jul-2017 10:14:51 +0300, Hihin Ruslan wrote:

 > > Чтобы не просто не заметили, а даже случайно не наткнулись,
 > > подобные библиотеки полагается либо вкомпилячивать статически,
 > > либо делать общесистемными.
 > Как это в общесистемные не наткнутся. Не понял ваши мысли.

Если динамические библиотеки бывают только общесистемными - все
пакеты будут использовать именно их. Единственная альтернатива,
позволяющая собрать один-два пакета с какой-нибудь экзотикой -
livexotics-devel-static.

 > А если делать отдельный статический пакет, да ещё если ое будет
 > провайдить динамический (т.е. вводить мантейнера других пакетов
 > в заблуждение), то такая чехарда начнётся ...

Так... Кто сказал, что %name-devel - это обязательно динамические
библиотеки? И что мешает, например, собрать

%package devel-shared
Provides: %name-devel = %version
Conflicts: %name-devel-static

%package devel-static
Provides: %name-devel = %version
Conflicts: %name-devel-shared

А еще есть вариант, когда %name-devel требует %name-devel-headers
и %name-devel-libs, а %name-devel-libs обеспечивается либо пакетом
%name-devel-libs-shared, либо %name-devel-libs-static - это чуть
более трудоемко при сборке (многабукф в .spec), но сильно упрощает
жизнь людям, которые потом будут использовать библиотеку:

Requires: example-devel, example-devel-libs-shared

 > А так. допустим пакет N-libs.rpm таскает в себе динамические
 > библиотеки ffmpeg для пакета N (вариант N-libs и N один и
 > тот-же пакет), которые лежат в /usr/libs/N-libs/ffmpeg, да ещё
 > файлы *.so лежат в N-libs-devel и N-libs никак не провайдит
 > ffmpeg. Что в этом страшного, кроме избыточности?

Простейший пример: в том же ffmpeg обнаруживается очередная дыра,
причем такая, что User Otus Vulgaris (усер ушастый обыкновенный)
перепугался и решил проверить, не затрагивает ли это его:

% rpm -q ffmpeg
ffmpeg-X.Y-...

Ура, он свежий! А смотреть, что там в N-libs, никто не будет, и в
результате у того усера останется дырявая софтина.

 > Продолжаем. Про удаление избыточности:
 > Если пакеты K, L и М хотят использовать ffmpeg из N-libs, а не
 > использовать libav, то не является-ли достаточным условием, что
 > в них стоял запрет на линковку с libav.

А почему именно из N-libs, а не просто ffmpeg-devel?

 > Осталось понять как этот запрет можно реализовать в рамках
 > существующей сборочной реальности.
 > Пальцем в небо:
 > Типа антидота-пустышки, который отвергал линковку с реальным
 > libav. - я думаю нереализуемо.
 > Какие-то сборочные зависимости - если есть N-lib, то в сборочнице
 > не должен находится ffmpeg.

Теоретически можно разрулить на уровне зависимостей. А на практике
проще и правильнее будет просто избегать помойки.


-- 
Alexey V. Vissarionov
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [devel] Сборка ffmpeg в p8

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

Здравствуйте Alexey V. Vissarionov
  В сообщении от 24 июля 2017 Alexey V. Vissarionov написал(a):
> Если динамические библиотеки бывают только общесистемными -
> все пакеты будут использовать именно их.

И тут начнётся чехарда между libav и ffmpeg

-- 
  А ещё говорят так  (fortune): 
 
Stay the curse. 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Сборка ffmpeg в p8

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

Здравствуйте Alexey V. Vissarionov
  В сообщении от 24 июля 2017 Alexey V. Vissarionov написал(a):
> Простейший пример: в том же ffmpeg обнаруживается очередная
> дыра, причем такая, что User Otus Vulgaris (усер ушастый
> обыкновенный) перепугался и решил проверить, не затрагивает ли
> это его:
>
> % rpm -q ffmpeg
> ffmpeg-X.Y-...
>
> Ура, он свежий! А смотреть, что там в N-libs, никто не будет,
> и в результате у того усера останется дырявая софтина.

а нету ffmpeg - есть только libav

-- 
  А ещё говорят так  (fortune): 
 
<raorn> Гг. <raorn> wRAR: это на самом деле "ггг" сбоку в 
перспективе 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Сборка ffmpeg в p8

[Alexey V. Vissarionov]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

On 24-Jul-2017 10:21:40 +0300, Sergey V Turchin wrote:

 > > Чтобы не просто не заметили, а даже случайно не наткнулись,
 > > подобные библиотеки полагается либо вкомпилячивать статически,
 > > либо делать общесистемными.
 > Для этого достаточно собрать динамически, положить в отдельный
 > каталог и не паковать заголовки.

Теоретически - да, можно.

Но я только что написал, и еще раз повторю: проще и правильнее
будет просто избегать помойки.


-- 
Alexey V. Vissarionov
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [devel] Сборка ffmpeg в p8

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

Здравствуйте Alexey V. Vissarionov
  В сообщении от 24 июля 2017 Alexey V. Vissarionov написал(a):
> А почему именно из N-libs, а не просто ffmpeg-devel?

Что-бы "шибко умные' (скприты ;-) ) с ним не линковались вместо 
libav ;-)

-- 
  А ещё говорят так  (fortune): 
 
applications applnk apps autostart bin bookmarks.xml config 
config.kcfg desktop-directories doc emoticons icons locale 
mimelnk services servicetypes share sounds templates Phaedrus 
wishes he could get a machine that consists of Sparc IO, Alpha 
Processors and sleek design of an SGI <pp> And intel prices -- 
Seen on #Linux 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Сборка ffmpeg в p8

[Sergey V Turchin]

On Monday, 24 July 2017 10:41:33 MSK Alexey V wrote:

[...]
> А на практике проще и правильнее будет просто избегать помойки.
Значит, вам не составит труда собрать telegram-desktop в p8, чем вы поможете 
Виталию и исключите причину появления этого обсуждения.

-- 
Regards, Sergey.

Re: [devel] Сборка ffmpeg в p8

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

Здравствуйте Alexey V. Vissarionov
  В сообщении от 24 июля 2017 Alexey V. Vissarionov написал(a):
> Теоретически можно разрулить на уровне зависимостей. А на
> практике проще и правильнее будет просто избегать помойки.

Вопрос и состоит как избежать, при основном libav и в 
исключительных случаях ffmpeg

-- 
  А ещё говорят так  (fortune): 
 
Опыт показывает, что трогать svn qutim-а опасно для психического 
здоровья. -- evg in #21064 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Сборка ffmpeg в p8

[Sergey V Turchin]

On Monday, 24 July 2017 10:50:30 MSK Alexey V wrote:

[...]
> Но я только что написал, и еще раз повторю: проще и правильнее
> будет просто избегать помойки.
Так соберите telegram-desktop в p8 и дело в шляпе.

-- 
Regards, Sergey.

Re: [devel] Сборка ffmpeg в p8 (mplayer в Сизифе слинкован с десятками сумасшедших библиотек проекта samba)

[Vladimir D. Seleznev]

On Fri, Jul 21, 2017 at 11:58:17PM +0300, Vitaly Lipatov wrote:
> P.S.
> А mplayer в Сизифе слинкован с десятками сумасшедших библиотек проекта 
> samba. Видимо, со всем содержимым
> /usr/lib64/samba/:
> ...
> 	libutil-tdb-samba4.so => /usr/lib64/samba/libutil-tdb-samba4.so 
> (0x00007f3138760000)
> 	libsamba-sockets-samba4.so => 
> /usr/lib64/samba/libsamba-sockets-samba4.so (0x00007f3138548000)
> ...
> 
> $ ldd /usr/bin/mplayer | grep samba | wc -l
> 54

Это неправда.

$ objdump -p /usr/bin/mplayer | grep NEEDED | egrep "smb|samba"
  NEEDED               libsmbclient.so.0

MPlayer слинкован только с libsmbclient.so.0, у которого использует
только несколько функций. ldd(1) же показывает замыкание требуемых
сошников.

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] Сборка ffmpeg в p8 (mplayer в Сизифе слинкован с десятками сумасшедших библиотек проекта samba)

[Vitaly Lipatov]

Vladimir D. Seleznev писал 25.7.17 13:37:
...
>> $ ldd /usr/bin/mplayer | grep samba | wc -l
>> 54
> 
> Это неправда.
> 
> $ objdump -p /usr/bin/mplayer | grep NEEDED | egrep "smb|samba"
>   NEEDED               libsmbclient.so.0
> 
> MPlayer слинкован только с libsmbclient.so.0, у которого использует
> только несколько функций. ldd(1) же показывает замыкание требуемых
> сошников.
А, точно. Это я со временем стал считать, что ldd -r будет показывать 
список рекурсивно.
Извините :)



-- 
С уважением,
Виталий Липатов,
Etersoft

Re: [devel] Сборка ffmpeg в p8

[Vitaly Lipatov]

Motsyo Gennadi aka Drool писал 22.7.17 11:35:
> 22.07.2017 09:27, Anton Farygin пишет:
>> Это с одной стороны. С другой стороны - stable на то он и stable, что 
>> бы
>> там никто не проводил подобных "фокусов" по смене одной из ключевых
>> библиотек системы. Лучше и проще дождаться p9 и там то уж точно всё
>> будет прекрасно.
> 
> 	p9 идеальный вариант решения проблемы, но все же есть некоторый набор
> софта, который из-за libav вместо ffmpeg либо криво работает (mpv и
> субтитры), либо малопригоден (audacity без ffmpeg имеет смешной набор
> поддерживаемых форматов).
> 

В довершение дискуссии сообщу, что пакет libffmpeg-devel-static в p8. 
Собраться с ним случайно очень сложно.
Рекомендуется использовать только при сборке прикладных программ (не 
библиотек). Особенно важно проверить, чтобы одновременно приложение не 
использовало другие способы работы с видео (phonon, vlc, gstreamer и 
т.п.), которые приведут к конфликту.

В спеке я использую такую конструкцию:
%if %__ubt_branch_id == "M80P"
BuildRequires: libffmpeg-devel-static
%def_with ffmpeg_static
%else
BuildRequires: libavdevice-devel libavformat-devel libswscale-devel 
libswresample-devel
%endif

...
%build
%if_with ffmpeg_static
export PKG_CONFIG_PATH=%_libdir/ffmpeg-static/%_lib/pkgconfig/
%endif

Телеграм и qtox собрались просто отлично.


С уважением,
Виталий Липатов,
Etersoft

-- 
С уважением,
Виталий Липатов,
Etersoft

Re: [devel] Сборка ffmpeg в p8

[Sergey V Turchin]

On Saturday, 7 October 2017 09:56:58 MSK Vitaly Lipatov wrote:

[...]
> В спеке я использую такую конструкцию:
> %if %__ubt_branch_id == "M80P"
Есть %ubt_id
Надо было 10 подчеркиваний в начале названия макроса сделать. ;-)

-- 
Regards, Sergey.

Re: [devel] Сборка ffmpeg в p8

[Sergey V Turchin]

On Saturday, 7 October 2017 09:56:58 MSK Vitaly Lipatov wrote:

[...]
> В спеке я использую такую конструкцию:
> %if %__ubt_branch_id == "M80P"
> BuildRequires: libffmpeg-devel-static
Можно более нейтрально
http://git.altlinux.org/people/zerg/packages/?p=kde4-soundkonverter.git;a=commitdiff;h=88335ecb079fdbe27c050d90d0ab14a896f296a4

-- 
Regards, Sergey.

Re: [devel] Сборка ffmpeg в p8

[Anton Farygin]

09.10.2017 17:40, Sergey V Turchin пишет:
> On Saturday, 7 October 2017 09:56:58 MSK Vitaly Lipatov wrote:
>
> [...]
>> В спеке я использую такую конструкцию:
>> %if %__ubt_branch_id == "M80P"
>> BuildRequires: libffmpeg-devel-static
> Можно более нейтрально
> http://git.altlinux.org/people/zerg/packages/?p=kde4-soundkonverter.git;a=commitdiff;h=88335ecb079fdbe27c050d90d0ab14a896f296a4

Линковаться статически с ffmpeg - это очень плохая идея.

Re: [devel] Сборка ffmpeg в p8

[Sergey V Turchin]

On Monday, 9 October 2017 17:50:00 MSK Anton Farygin wrote:

[...]
> Линковаться статически с ffmpeg - это очень плохая идея.
Не всегда, но да.

-- 
Regards, Sergey.

Re: [devel] Сборка ffmpeg в p8

[Vitaly Lipatov]

Sergey V Turchin писал 9.10.17 17:40:
> On Saturday, 7 October 2017 09:56:58 MSK Vitaly Lipatov wrote:
> 
> [...]
>> В спеке я использую такую конструкцию:
>> %if %__ubt_branch_id == "M80P"
>> BuildRequires: libffmpeg-devel-static
> Можно более нейтрально
> http://git.altlinux.org/people/zerg/packages/?p=kde4-soundkonverter.git;a=commitdiff;h=88335ecb079fdbe27c050d90d0ab14a896f296a4

Спасибо, так и сделаю!

-- 
С уважением,
Виталий Липатов,
Etersoft

Re: [devel] Сборка ffmpeg в p8

[Vitaly Lipatov]

Sergey V Turchin писал 9.10.17 17:40:
> On Saturday, 7 October 2017 09:56:58 MSK Vitaly Lipatov wrote:
> 
> [...]
>> В спеке я использую такую конструкцию:
>> %if %__ubt_branch_id == "M80P"
>> BuildRequires: libffmpeg-devel-static
> Можно более нейтрально
> http://git.altlinux.org/people/zerg/packages/?p=kde4-soundkonverter.git;a=commitdiff;h=88335ecb079fdbe27c050d90d0ab14a896f296a4

Эээ... к сожалению, некоторые пакеты по-другому называются, типа
libswresample-devel vs libavresample-devel.

-- 
С уважением,
Виталий Липатов,
Etersoft

Re: [devel] Сборка ffmpeg в p8

[Sergey V Turchin]

В письме от пятница, 13 октября 2017 г. 17:40:54 MSK пользователь Vitaly 
Lipatov написал:

[...]
> > http://git.altlinux.org/people/zerg/packages/?p=kde4-soundkonverter.git;a=
> > commitdiff;h=88335ecb079fdbe27c050d90d0ab14a896f296a4
> Эээ... к сожалению, некоторые пакеты по-другому называются, типа
> libswresample-devel vs libavresample-devel.
По ссылке пример про ffmpeg и avconv.

-- 
Regards, Sergey.