Эмулируйте трубу с несколькими выходами. Достаточно ли быстр Python для этого?

Question

Эмулируйте трубу с несколькими выходами. Достаточно ли быстр Python для этого?

1

У меня есть входные байты из ffmpeg. Я бы хотел отправить этот вывод на несколько других процессов ffmpeg. Так как я не могу использовать Unix Pipe, Socket, для этого (или я могу?), Я использую python в качестве принимающего конца канала. Затем подпрограмма копирует полученные данные во все ранее "зарегистрированные" выходы.

Это неправильно!

В частности, я чувствую, что это означает много копирования памяти. Он работает прямо сейчас. Но я серьезно хотел бы начать "правильный путь" этого.

    def writeData(self,data):
    """Write 'data' to all outputs"""
    if len(self.outlets) > 0:
        for outlet in self.outlets:
            outlet.writeData(data)
    else:
        self.logger.warn("Received data but no outlets registred (yet?)")

Thorsten 10 фев. 2011, в 22:19

Источник

Теги:

python

unix

3 ответа

2

EDIT. Спасибо Филу, который исправил ошибку в более ранней версии (см. комментарии).

Используя bash, вы можете сделать

ffmpeg ... | tee >(ffmpeg ...) >(ffmpeg ...) >(ffmepg ...) > /dev/null

Это будет передавать вывод первого ffmpeg третьим.

Если вы не используете bash, вы можете вручную создать именованные каналы, подключить их к процессам ffmpeg и использовать tee для подключения к именованным каналам:

mkfifo pipe1 pipe2
ffmpeg ... < pipe1
ffmpeg ... < pipe2
ffmpeg ... | tee pipe1 pipe2 | ffmpeg ...
rm pipe1 pipe2

Вышеупомянутый код bash в основном тот же. Создание и удаление названных каналов происходит прозрачно.

Sven Marnach 10 фев. 2011, в 18:55

0

Ти, по сути, делает то же самое, что и Python выше, верно? Мне было интересно, если путь питона значительно медленнее. Я спрашиваю, потому что я бы предпочел Python для гибкости.
Thorsten 10 фев. 2011, в 20:59
0

@Thorsten: Я согласен с Грегом - скорее всего, это не будет узким местом, но чтобы быть действительно уверенным, вам придется попробовать себя. Так как ввод / вывод обычно выполняется большими кусками, я не ожидал бы, что Python создаст много накладных расходов.
Sven Marnach 10 фев. 2011, в 21:05
1

Осторожно, это перенаправит вывод первого, второго и третьего ffmpegs в четвертый. Лучшим примером является «a | tee> (b)> (c)> (d)> / dev / null»
Phil 11 фев. 2011, в 14:42
0

@Phil: ты пробовал это? Я проверил свою версию, и она не передает все результаты до последнего процесса. Не уверен, о чем ты говоришь.
Sven Marnach 11 фев. 2011, в 14:47
1

@Sven: echo dog | tee >( grep d ) >( grep o ) | tr az AZ дает мне все DOG в верхнем регистре, предполагая, что stdouts grep были переданы в tr. Однако echo dog | tee >( grep d ) >( grep o ) >( tr az AZ ) > /dev/null не смешивает потоки. Упорядочить обработку оболочки, которая вызывает это, сложно; какой был твой тест и результат?
Phil 11 фев. 2011, в 15:11
0

@Phil: Понял мою ошибку. Мой тест был в основном echo dog | tee >(grep d) >(grep o) > some_file для проверки того, что собирается в stdout, но это не то же самое, что echo dog | tee >(grep d) >(grep o) | cat > some_file , который я ошибочно предположил (я понимаю, почему сейчас все по-другому)
Sven Marnach 11 фев. 2011, в 15:29

Показать ещё 4 комментария

1

Вы просмотрели утилиту "pee" из пакета moreutils? Он делает то, что вы описываете:

ffmpeg | pee 'ffmpeg -stuff1' 'ffmpeg -stuff2' 'ffmpeg -stuff3'

Phil 11 фев. 2011, в 11:50

Ещё вопросы

Ти, по сути, делает то же самое, что и Python выше, верно? Мне было интересно, если путь питона значительно медленнее. Я спрашиваю, потому что я бы предпочел Python для гибкости.
@Thorsten: Я согласен с Грегом - скорее всего, это не будет узким местом, но чтобы быть действительно уверенным, вам придется попробовать себя. Так как ввод / вывод обычно выполняется большими кусками, я не ожидал бы, что Python создаст много накладных расходов.
Осторожно, это перенаправит вывод первого, второго и третьего ffmpegs в четвертый. Лучшим примером является «a | tee> (b)> (c)> (d)> / dev / null»
@Phil: ты пробовал это? Я проверил свою версию, и она не передает все результаты до последнего процесса. Не уверен, о чем ты говоришь.
@Sven: echo dog | tee >( grep d ) >( grep o ) | tr az AZ дает мне все DOG в верхнем регистре, предполагая, что stdouts grep были переданы в tr. Однако echo dog | tee >( grep d ) >( grep o ) >( tr az AZ ) > /dev/null не смешивает потоки. Упорядочить обработку оболочки, которая вызывает это, сложно; какой был твой тест и результат?
@Phil: Понял мою ошибку. Мой тест был в основном echo dog | tee >(grep d) >(grep o) > some_file для проверки того, что собирается в stdout, но это не то же самое, что echo dog | tee >(grep d) >(grep o) | cat > some_file , который я ошибочно предположил (я понимаю, почему сейчас все по-другому)

Greg Hewgill · Accepted Answer · 2011-02-10T18-53-00.000Z

Скорее всего, это будет достаточно быстро, особенно со скоростью процессоров теперь по сравнению с относительно низкой пропускной способностью сжатых видеоданных.

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