Jump to content

    

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

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

Share this post


Link to post
Share on other sites
Нужно захватывать эти видеокадры и каждый перекодировать в png на лету.

 

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

Share this post


Link to post
Share on other sites

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

Share this post


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

 

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

Share this post


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

Share this post


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

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

Share this post


Link to post
Share on other sites
Добавлю, что JPEG (MJPEG) тоже успешно и часто используется.

 

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

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

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

Share this post


Link to post
Share on other sites

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

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

Edited by x736C

Share this post


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

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

 

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

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

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

 

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

 

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

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

https://opencores.org/projects

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this