Файлы из живых источников в gstreamer повреждены

У меня проблема с файлами, записанными из живых источников (веб-камеры) и псевдоживых источников (скриншоты) в GStreamer. Полученные файлы не имеют временной длины и, как следствие, вообще не воспроизводятся в Media Player Classic. В Firefox они играют, но без временной длины и иногда с повышенной скоростью.

Кажется, не имеет значения, какой (псевдо) живой источник я использую, какой кодек или контейнер. История всегда одна и та же; неправильные медиафайлы без установленной продолжительности.

Однако, когда я добавляю параметр «num-buffers=100» в dx9screencapsrc, элемент src отправляет событие EOS после этого количества буферов, после чего файл корректно отображается в MPC и Firefox. Таким образом, событие EOS, кажется, что-то делает, чтобы файл закрывался должным образом.

Я пробовал обычные способы остановки конвейера (через setState(...)). Попытался вручную отправить событие EOS всем элементам, прослушивая событие EOS на шине, а затем выходя из конвейера. Все безрезультатно, файлы остаются поврежденными.

Мой вопрос в том, как я могу остановить конвейер при использовании (псевдо) живых источников и создать правильные файлы (т.е. в этом случае имеет правильную продолжительность).

Я использую gstreamer-java с GStreamer 0.10 на Java 6 и Windows 8. В качестве примера возьмем следующий конвейер:

dx9screencapsrc ! video/x-raw-rgb,framerate=15/1 ! ffmpegcolorspace ! vp8enc ! webmmux ! filesink location=%s

На данный момент я в недоумении, как решить эту проблему. Любая помощь приветствуется!

ИСПРАВЛЕНО Как оказалось, мне пришлось отправлять событие EOS только элементу src, а не каждому элементу в конвейере.


pipeline gstreamer java-gstreamer
person Bastiaan de Jong    schedule 26.05.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Правильным способом было бы отправить событие EOS в конвейер и подождать, пока вы не получите его как GstMessage на шине.

Если вы говорите, что пробовали это, и это не сработало, это может быть ошибка в задействованных элементах (маловероятно), в привязках java или в вашем коде.

Чтобы исключить ошибки в задействованных элементах, я бы рекомендовал попробовать:

gst-launch-0.10 -e dx9screencapsrc ! video/x-raw-rgb,framerate=15/1 ! ffmpegcolorspace ! vp8enc ! webmmux ! filesink location=%s

Флаг -e включает eos-on-shutdown, что означает, что как только вы прервете процесс, он отправит EOS и будет ждать его на шине (как и должно делать ваше приложение). Если это сработает, я бы порекомендовал просмотреть ваш код.

Важно отметить, что вы используете gstreamer 0.10, который уже 3 года устарел и не поддерживается. Настоятельно рекомендуется перейти на серию 1.x.

person thiagoss    schedule 27.05.2015
comment
Спасибо за Ваш ответ! Как оказалось, мне пришлось отправить событие EOS только элементу src, а не каждому элементу конвейера. Видимо, это была моя ошибка. Как вы сказали, опция -e отлично работает в командной строке. Мы хотели бы использовать gstreamer 1.x, однако ни одна из привязок java, которые мы пробовали, не работает. Или, по крайней мере, не для нас. Тем не менее, мы обязательно рассмотрим это снова в будущем. - person Bastiaan de Jong; 05.06.2015
comment
Вам не нужно самостоятельно отправлять EOS элементам, просто отправьте eos непосредственно в объект пайплайна, и пайплайн сам решит, что делать с событием. - person thiagoss; 05.06.2015