Перейти к содержанию
    

Перкодировка видео в png или bmp

Нужно наверное использовать raspivid , выводить видео в stdout и как-то организвать пипу для энкодера. Но за отсутвием опыта с Gstteamer (нужен ли он?) обращаюсь за советом. Нужно захватывать эти видеокадры и каждый перекодировать в png на лету. Если работать с камерой как с /dev/video0 то получается через pngenc , но с /dev/video0 засада он не понимает параметров, которые понимает raspivid интерфейс

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Нужно захватывать эти видеокадры и каждый перекодировать в png на лету.

 

Насколько велика частота кадров и разрешение? А то я что-то не припомню в камнях аппаратного PNG кодека :laughing:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

да это 4-ядерник 1.2ГГц и софтом то сможет влегкую, даже без GPU. 75 кадров 800*480/ Ну собсно png это от балды, так- то надо простой YUV в памяти для мат обработки поиметь. Если уж так туго то можно 320*240 хотя бы. Реально не хочется софтом делать своим, стример это явно умеет, только не пойму как пипу нарисовать

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

да это 4-ядерник 1.2ГГц и софтом то сможет влегкую, даже без GPU. 75 кадров 800*480/

 

На счет линукса и гпу не подскажу, но одноядерный МХ6, 1024х768х32 в png упаковывал несколько кадров в сек, без линукса, с кэшем и оптимизацией. 4х ядерник конечно покруче, но...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Нужно наверное использовать 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 вы будете иметь проблемы. Оно для статических картин хорошо, а не для видео.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Используют DIVX, XVID, MPEG2, h263, h264, h265. Вам следует хорошо подумать о формате. с png вы будете иметь проблемы. Оно для статических картин хорошо, а не для видео.

Добавлю, что JPEG (MJPEG) тоже успешно и часто используется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Добавлю, что JPEG (MJPEG) тоже успешно и часто используется.

 

Те что я перечислил как раз основаны на том, чтобы избежать использовать JPEG для всех кадров. Там JPEG используется один раз на много кадров, а последующие кадры только разницаа между новым и JPEG плюс ошибки, что гораздо экономнее чем одни JPEG посылать. Использование одних JPEG кадров это непрофессионально сегодня. Оно много информации требует. Но конечно если очень хочется, то можно и вообще не сжимать.

i-frames это и есть JPEG:

https://en.wikipedia.org/wiki/Video_compres...n_picture_types

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Насчет «непрофессионально сегодня» — это не так. Для широкого класса задач MJPEG намного удобнее, чем использование стандартов кодирования, предусматривающих межкадровое сжатие. За м/к сжатие приходится щедро платить сложностью кодера-декодера, задержками, дороговизной. Поэтому MJPEG вполне себе используется на самом профессиональном уровне.

Непрофессионально использовать MJPEG там, где более эффективным кодекам нет альтернативы, а так бывает не всегда.

Изменено пользователем x736C

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Насчет «непрофессионально сегодня» — это не так. Для широкого класса задач MJPEG намного удобнее, чем использование стандартов кодирования, предусматривающих межкадровое сжатие. За м/к сжатие приходится щедро платить сложностью кодера-декодера, задержками, дороговизной. Поэтому MJPEG вполне себе используется на самом профессиональном уровне.

Непрофессионально использовать MJPEG там, где более эффективным кодекам нет альтернативы, а так бывает не всегда.

 

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

"Для широкого класса задач MJPEG намного удобнее"

Я бы сказал понятнее и с меньшими усилиями. Что могу сказать? Не надо лениться, а делать над собой усилие и двигаться вперед. Я работал в последнее время над видео в некоторых системах. Обеспечивать в них MJPEG даже в голову никому не приходило.

 

Тем более, что в процессорах уже стоит кодек на отдельном DSP. iMX53, iMX6x например. Там они сделаны с Gstreamer интерфейсом. Пользоваться легко и без дополнительных знаний о методах несомненно очень непростого кодирования.

 

Насчет дорого.

Вот здесь бесплатно, но возможно придется поработать:

https://opencores.org/projects

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...