DASM 0 22 мая, 2017 Опубликовано 22 мая, 2017 · Жалоба Нужно наверное использовать raspivid , выводить видео в stdout и как-то организвать пипу для энкодера. Но за отсутвием опыта с Gstteamer (нужен ли он?) обращаюсь за советом. Нужно захватывать эти видеокадры и каждый перекодировать в png на лету. Если работать с камерой как с /dev/video0 то получается через pngenc , но с /dev/video0 засада он не понимает параметров, которые понимает raspivid интерфейс Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 49 23 мая, 2017 Опубликовано 23 мая, 2017 · Жалоба Нужно захватывать эти видеокадры и каждый перекодировать в png на лету. Насколько велика частота кадров и разрешение? А то я что-то не припомню в камнях аппаратного PNG кодека :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DASM 0 25 мая, 2017 Опубликовано 25 мая, 2017 · Жалоба да это 4-ядерник 1.2ГГц и софтом то сможет влегкую, даже без GPU. 75 кадров 800*480/ Ну собсно png это от балды, так- то надо простой YUV в памяти для мат обработки поиметь. Если уж так туго то можно 320*240 хотя бы. Реально не хочется софтом делать своим, стример это явно умеет, только не пойму как пипу нарисовать Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 49 26 мая, 2017 Опубликовано 26 мая, 2017 · Жалоба да это 4-ядерник 1.2ГГц и софтом то сможет влегкую, даже без GPU. 75 кадров 800*480/ На счет линукса и гпу не подскажу, но одноядерный МХ6, 1024х768х32 в png упаковывал несколько кадров в сек, без линукса, с кэшем и оптимизацией. 4х ядерник конечно покруче, но... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 21 июня, 2017 Опубликовано 21 июня, 2017 · Жалоба Нужно наверное использовать raspivid , выводить видео в stdout и как-то организвать пипу для энкодера. Но за отсутвием опыта с Gstteamer (нужен ли он?) обращаюсь за советом. Нужно захватывать эти видеокадры и каждый перекодировать в png на лету. Если работать с камерой как с /dev/video0 то получается через pngenc , но с /dev/video0 засада он не понимает параметров, которые понимает raspivid интерфейс У меня есть опыт с gstreamer. stdout это для текстового вывода. У gstreamer есть видео sink. Что говорит команда gst-inspect | grep sink ? gst-inspect может быть в разных написаниях (часто номер версии добавляют в конце). Нажмите после ввода два раза табуляцию -- он покажет варианты. png для видео использовать нерационально. Используют DIVX, XVID, MPEG2, h263, h264, h265. Вам следует хорошо подумать о формате. с png вы будете иметь проблемы. Оно для статических картин хорошо, а не для видео. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x736C 0 22 июня, 2017 Опубликовано 22 июня, 2017 · Жалоба Используют DIVX, XVID, MPEG2, h263, h264, h265. Вам следует хорошо подумать о формате. с png вы будете иметь проблемы. Оно для статических картин хорошо, а не для видео. Добавлю, что JPEG (MJPEG) тоже успешно и часто используется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 24 июня, 2017 Опубликовано 24 июня, 2017 · Жалоба Добавлю, что JPEG (MJPEG) тоже успешно и часто используется. Те что я перечислил как раз основаны на том, чтобы избежать использовать JPEG для всех кадров. Там JPEG используется один раз на много кадров, а последующие кадры только разницаа между новым и JPEG плюс ошибки, что гораздо экономнее чем одни JPEG посылать. Использование одних JPEG кадров это непрофессионально сегодня. Оно много информации требует. Но конечно если очень хочется, то можно и вообще не сжимать. i-frames это и есть JPEG: https://en.wikipedia.org/wiki/Video_compres...n_picture_types Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x736C 0 24 июня, 2017 Опубликовано 24 июня, 2017 (изменено) · Жалоба Насчет «непрофессионально сегодня» — это не так. Для широкого класса задач MJPEG намного удобнее, чем использование стандартов кодирования, предусматривающих межкадровое сжатие. За м/к сжатие приходится щедро платить сложностью кодера-декодера, задержками, дороговизной. Поэтому MJPEG вполне себе используется на самом профессиональном уровне. Непрофессионально использовать MJPEG там, где более эффективным кодекам нет альтернативы, а так бывает не всегда. Изменено 24 июня, 2017 пользователем x736C Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 25 июня, 2017 Опубликовано 25 июня, 2017 · Жалоба Насчет «непрофессионально сегодня» — это не так. Для широкого класса задач MJPEG намного удобнее, чем использование стандартов кодирования, предусматривающих межкадровое сжатие. За м/к сжатие приходится щедро платить сложностью кодера-декодера, задержками, дороговизной. Поэтому MJPEG вполне себе используется на самом профессиональном уровне. Непрофессионально использовать MJPEG там, где более эффективным кодекам нет альтернативы, а так бывает не всегда. Ну если вы делаете систему без передачи видео по линиям связи и без записи на носитель, то разумется пофиг. Если вам не важно сколько каналов видео вы сможете передать по линии связи и сколько часов записи поместится на ваш диск. "Для широкого класса задач MJPEG намного удобнее" Я бы сказал понятнее и с меньшими усилиями. Что могу сказать? Не надо лениться, а делать над собой усилие и двигаться вперед. Я работал в последнее время над видео в некоторых системах. Обеспечивать в них MJPEG даже в голову никому не приходило. Тем более, что в процессорах уже стоит кодек на отдельном DSP. iMX53, iMX6x например. Там они сделаны с Gstreamer интерфейсом. Пользоваться легко и без дополнительных знаний о методах несомненно очень непростого кодирования. Насчет дорого. Вот здесь бесплатно, но возможно придется поработать: https://opencores.org/projects Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться