LINUX.ORG.RU

консольные программы - двусторонний обмен данными


0

2

вот что интересно, есть допустим программа захвата видео, ее вывод перенаправляется на ffmpeg, из него на vlc, там на x264, далее еще как-то

а в какой формате, по какому стандарту это происходит? пользовался только выводом в файл при помощи >

вопрос: как организовать обмен данными с консольной программой? и как называется этот механизм/процесс?

есть допустим какая-то библиотека и есть для нее программа-wrapper (часто такое бывает - библиотека + консольная утилита, которая позволяется воспользоваться ей из консоли) - можно ли организовать взаимодействие своего кода с такой оберткой чтобы не вдаваться в детали работы той или иной библиотеки а воспользоваться отлаженной оберткой? (производительность тоже интересует, нет ли тут излишних копирований из памяти в память)

а в какой формате, по какому стандарту это происходит?

Байтовый поток.

Остального не понял.

tailgunner ★★★★★
()
Ответ на: комментарий от Kosyak

Ааа... а то я думал, может объективных причин напишет, почему оно Г :)

xterro ★★★★★
()
Ответ на: комментарий от Delirium_veritas

он был школолтой и три года назад
и год назад, и так и остался
анон гарантирует

anonymous
()
Ответ на: комментарий от xterro

потому что он тормозной и не имеет смысла. Любые другие методы IPC намного быстрее (UNIX-сокеты, пайпы, shared memory, etc.) DBus имело бы смысл пользовать если бы в нём была сетевая прозрачность. Но, к сожалению, разрабы забили на это, хотя изначально она была в планах. Такие дела.

anonymous
()
Ответ на: комментарий от anonymous

Я всегда считал что это такая универсальная и удобная штука. Добавил её поддержку, и все приложения теперь могут общаться с твоим )

xterro ★★★★★
()
Ответ на: комментарий от xterro

эта «универсальная» и «удобная» штука существует только под лялепсом и наполовину под xBSD, в остальном всё печально. Текстовые протоколы намного более универсальны.

anonymous
()
Ответ на: комментарий от anonymous

Текстовые протоколы намного более универсальны.

Т.е парсинг выхлопа?

xterro ★★★★★
()
Ответ на: комментарий от tailgunner

неужели байтовый, это невероятно!

я привел пример - допустим vlc захватывает с v4l2 устройства а далее этот результат работы подаетчя на ffmpeg и сжимается - этот вызов записан в одну строку в консоли

там идет байтовый поток но блин, это же как то называется, как то же отдельные кадры обозначаются - длина блока и т.д.

что за протокол

З.Ы. это гениально - зайти в топик и газифицировать «ааааа это все знают у него X звезд и не знает аааааа а мы огого аааа уууу» гениально

это я про некоторых коментаторов

I-Love-Microsoft ★★★★★
() автор топика
Ответ на: комментарий от I-Love-Microsoft

там идет байтовый поток но блин, это же как то называется, как то же отдельные кадры обозначаются - длина блока и т.д.

а причем тут перенаправление? | на более низком уровне, он про ваши кадры ничего не знает.

anonymous
()
Ответ на: комментарий от I-Love-Microsoft

неужели байтовый, это невероятно!

А ты что хотел? Битовый? Или что? Может блочный?

demmsnt
()

вот что интересно, есть допустим программа захвата видео, ее вывод перенаправляется на ffmpeg, из него на vlc, там на x264, далее еще как-то

Пайпом. Банальный поток байтов. BTW, vlc использует x264 и/или ffmpeg, как библиотеки, и поэтому ему это не нужно.

вопрос: как организовать обмен данными с консольной программой? и как называется этот механизм/процесс?

man popen (ты получаешь FILE*, который связан с тем, что комманда, переданная первым аргументом, считает консолью)

В более общих случаях напрямую вызывать pipe.

есть допустим какая-то библиотека и есть для нее программа-wrapper (часто такое бывает - библиотека + консольная утилита, которая позволяется воспользоваться ей из консоли) - можно ли организовать взаимодействие своего кода с такой оберткой чтобы не вдаваться в детали работы той или иной библиотеки а воспользоваться отлаженной оберткой?

Можно, но это бред. Намного правильнее и производительнее будет использовать библиотеку.

Deleted
()
Ответ на: комментарий от xterro

dbus, к сожалению, умеют далеко не все.

Deleted
()
Ответ на: комментарий от anonymous

потому что он тормозной и не имеет смысла.

Предложи другой адекватный RPC.

Любые другие методы IPC намного быстрее (UNIX-сокеты, пайпы, shared memory, etc.)

IPC. А RPC?

Deleted
()
Ответ на: комментарий от anonymous

Оно работает под всеми Unix-like, AFAIK. Есть порт под винду, но «вечная бета».

И таки универсальная и удобная. Быстрый и при этом удобный RPC.

Deleted
()
Ответ на: комментарий от I-Love-Microsoft

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

Deleted
()
Ответ на: комментарий от Deleted

согласен, насколько мне известно, D-Bus одинаково хорошо реализован под все ОС кроме маздая но и там он в каком то виде тоже существует

ну а QNXы и прочие экзотики... хз

I-Love-Microsoft ★★★★★
() автор топика
Ответ на: комментарий от Deleted

ок, спасибо, понял - простой краткий внятный ответ (все бы так) :)

I-Love-Microsoft ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.