Bug 30374 - Вернуть поддержку ffmpeg/libav
: Вернуть поддержку ffmpeg/libav
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/libopencv2.4)
: unstable
: all Linux
: P3 normal
Assigned To:
:
: http://docs.opencv.org/modules/highgu...
:
:
: 30150
  Show dependency tree
 
Reported: 2014-10-04 13:16 by
Modified: 2014-10-06 22:55 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2014-10-04 13:16:03
Нужно, чтобы, например, вот в этом месте:
http://docs.opencv.org/modules/highgui/doc/reading_and_writing_images_and_video.html#videocapture
снова поддерживались все контейнеры и кодеки, которые поддерживает текущий
стабильный ffmpeg или libav.

ffmpeg сейчас фактически промышленный стандарт, поэтому нужна поддержка не
конкретного списка форматов, а именно поддержка ffmpeg.
------- Comment #1 From 2014-10-06 13:55:31 -------
Не совсем понял, что вам нужно?
"все контейнеры и кодеки, которые поддерживает текущий
стабильный ffmpeg или libav", "Вернуть поддержку ffmpeg/libav" или "именно
поддержка ffmpeg"?
------- Comment #2 From 2014-10-06 17:26:28 -------
Дмитрий, прошу пояснить. Содержательно, без эмоций.
------- Comment #3 From 2014-10-06 18:40:45 -------
1. Одна из основных сфер применения libopencv — анализ видеопотока. Учитывая
огромное разнообразие контейнеров, кодеков и их реализаций, для обеспечения
совместимости важно иметь возможность сослаться на некий эталонный
энкодер/декодер и мультиплексор/демультиплексор.

2. Фактическим стандартом для обмена потоковой видеоинформацией сейчас является
ffmpeg, при этом на данный момент не так важно, какая именно реализация —
«оригинальный» или libav. Далее под «ffmpeg» будет подразумеваться оригинальный
ffmpeg или libav.

3. Использование gstreamer в качестве интерфейса к ffmpeg не является
прозрачной заменой, так как gstreamer представляет собой дополнительную
прослойку с собственным набором ошибок и несовместимостей, и уже не является
той самой эталонной реализацией.

Так понятно?
------- Comment #4 From 2014-10-06 18:57:59 -------
> 
> Так понятно?

Нет. 
Что нужно сделать? Что было сломано и в каком пакете?
2zerg: Вам понятно?
------- Comment #5 From 2014-10-06 20:21:21 -------
а то, что gstreamer используется по умолчанию в сборке RH/Fedora - не аргумент
?

собственно понятно почему они так делают - gst умеет чуть больше ffmpeg, и это,
видимо,кому-то удобно. но gst умеет и ffmpeg в том числе.

и да, нет никаких проблем собрать с libav, и если Дима, тебя чем-то не
устраивает сборка - давно б исправил ошибку, сделанную другим мейнтейнером.
никто ж не против. 
Патч для работы с новой версией libav есть.
------- Comment #6 From 2014-10-06 20:24:07 -------
Зергу, кстати, фиолетово с чем будет собрано opencv. просто ему нужна была
новая версия для сборки каких-то новых пакетов KDE, а ты обновлять её не
спешил.

Вот отсюда и расколбас.
Кстати, плюс сборки с gst - его API постабильнее чем API libav/ffmpeg и
исправлять в случае новой версии libav придётся меньше пакетов.
------- Comment #7 From 2014-10-06 21:45:16 -------
(В ответ на комментарий №4)
> Что нужно сделать? Что было сломано и в каком пакете?
> 2zerg: Вам понятно?
Мне только понятно, что DD хочет, чтоб у нас был ffmpeg вместо libav, собирая
пакеты лишь для своих личных нужд.
------- Comment #8 From 2014-10-06 22:54:17 -------
(В ответ на комментарий №5)
> а то, что gstreamer используется по умолчанию в сборке RH/Fedora - не аргумент
> ?

Аргумент. И я обязательно его рассмотрю. Но только в плановом порядке, а не в
авральном. Думаю, что вполне вероятно, что и мы в итоге остановимся на
gstreamer.

> собственно понятно почему они так делают - gst умеет чуть больше ffmpeg, и это,
> видимо,кому-то удобно. но gst умеет и ffmpeg в том числе.

Звучит вполне логично. Но это всё нужно тестировать, чтобы не испортить
случайно то, что уже работает. А у меня сейчас, к сожалению, нет возможности
такое тестирование провести.
------- Comment #9 From 2014-10-06 22:55:36 -------
Спасибо!