Перейти к содержанию
Fire Monkey от А до Я
  • 0

[TVideoCaptureDevice] Как оптимизировать скорость считывания данных с камеры?TVideoCaptureDevice


kolyalyan

Вопрос

У меня следующая проблема, когда подключаюсь к камере телефона, то кадры отображаются с ужасной задержкой, нааамного медленнее чем в сторонних приложениях работающих с камерой.

Для подключения к камере использую следующий код:
 

procedure TForm1.FormShow(Sender: TObject);
var 
   CDM : TCaptureDeviceManager;
   VC : TVideoCaptureDevice;

begin
   CDM := TCaptureDeviceManager.Current;
   VC := CDM.DefaultVideoCaptureDevice; 
   if (VC <> nil) then VC.OnSampleBufferReady := VideoBufferReady;

   VC.StartCapture;
end;

Для загрузки кадров в TImage этот:
 

procedure TForml.VideoBufferReady(Sender: TObject; const ATime: int64); 
var 
   VCD : TVideoCaptureDevice; 

begin
   VCD := Sender as TVideoCaptureDevice;
   VCD.SampleBufferToBitmap(Image1.Bitmap, True);
end;

Ещё раз повторюсь, что всё работает, но чрезвычайно медленно. Пробовал стандартный компонент TCameraComponent, но он работает также или даже ещё медленнее.

Ссылка на комментарий

Рекомендуемые сообщения

  • 0

Поддерживаю сей вопрос. Модель смарта Note 3, а тормозит так, как будто Dendi

Если это нормальная, штатная ситуация, которую нельзя исправить, то мы это примем пока как есть. А если это можно исправить, то хотелось бы знать как? 

Ссылка на комментарий
  • 0

ActionList умеет делать фотку, вызывая стандартную камеру...

А мне нужно 30 кадров в секунду. Потом еще и обрабатывать все эти кадры на лету, но это отдельная тема, проблем быть не должно. Главное - поучить эти кадры в виде Битмапов в приложении...

Ссылка на комментарий
  • 0

Как фото сделать, по осипову просто нужно cameracomponent.Active:=true и событие потом отловить. Стандартное приложение не открывается. Следовательно вопрос, как сделать фото и принять в софте?

Ссылка на комментарий
  • 0

Добрый день

Данная тема обсуждалась на форуме (топик не смог найти).

Если вам надо снять видео на Android, то стандартного решения в delphi нет (это связано с проблемами в iOS).

Вам придётся задать Intent для ОС, и в намерении указать куда сохранять файл.

можно перевести в Delphi код с официального сайта Google

http://developer.android.com/guide/topics/media/camera.html

Ссылка на комментарий
  • 0

Добрый день

Данная тема обсуждалась на форуме (топик не смог найти).

Если вам надо снять видео на Android, то стандартного решения в delphi нет (это связано с проблемами в iOS).

Вам придётся задать Intent для ОС, и в намерении указать куда сохранять файл.

можно перевести в Delphi код с официального сайта Google

http://developer.android.com/guide/topics/media/camera.html

а можете по шагам показать, как перевести код с сайта google в delphi.

Ссылка на комментарий
  • 0

Стандартными средствами - никак!

Я не уверен, но думаю что предложенный [zonik] вариант тоже не поможет... Но тут, повторяюсь, я не уверен.

И еще. Сохранение снятого видео в файл - это еще пол беды, и решить его не сложно. Намного сложнее вопрос - что делать, если нужна потоковая обработка видео? Например - для передачи по сети. И то решение которое существует (с несколькими кадрами в сек.) - не лезет ни в какие ворота...

В этом смысле меня иной раз напрягает отношение разработчиков к данной проблеме. Это ведь касается и не только видео. Когда они (эмбаркадеровцы) начинают показывать - "смотрите какие клевые фишки можно делать в 3D" (типа всяких лесенок..), и при этом не решают самых главных проблем - быстродействие GUI при решении элементарных задач обычного интерфейса.

Ссылка на комментарий
  • 0

AlexG, а вы случайно не связывались с разработчиками ПО, которые делали на RAD Studio клиент для просмотра видеопотоков с IP-камер? Я где-то видел ролик, в котором их решение довольно шустро отрабатывало выведение потока как с IP камеры, так и с другого мобильного устройства. 

Ссылка на комментарий
  • 0

AlexG, а вы случайно не связывались с разработчиками ПО, которые делали на RAD Studio клиент для просмотра видеопотоков с IP-камер? Я где-то видел ролик, в котором их решение довольно шустро отрабатывало выведение потока как с IP камеры, так и с другого мобильного устройства. 

Я практически уверен, что это нереально. Вот попробуйте в AndroidStudio накидать простой пример(либо глянуть один из стандартных сэмплов) захвата кадров с камеры и последующим обработкой\сохранением\передачей\ваш_вариант. Работает идеально. Прокиньте свои java-классы\функции через абракадабровский wrapper(JNI). Работает очень медленно ! По-этому я для себя сделал такой вывод: дело не в TCameraComponent(гляньте его ведро-реализацию - все очень просто), все дело в JNI. На простых\однократных операциях это не заметно. Там где начинаются обработки фото\видео\звука - начинается кошмар. Называйте это "пингом" между fmx и android'ом, или как-то по-другому, но факт есть факт: JNI(или хз что там конкретно, какой-то "мост") работает очень медленно. По-этому если Вам нужны реально высокопроизводительные приложения под ведро\иос - смотрите в сторону инструментов, предлагаемых компаниями-разработчиками данных ОС, ну или Xamarin. Вот испульзуя эти инструменты, Вы получите реально "true native". А так.. все "это" годно только для простейших свисто-перделок, "блокнотов" и АРМов из 3-х таблицы(по типу Employee Directory).

 

п.с. Сам я потихоньку "переезжаю" на VisualStudio, AndroidStudio

Ссылка на комментарий
  • 0

[Вячеслав] - нет, не связывался.

В данном случае я согласен с [ruslan].

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

Ссылка на комментарий
  • 0

 По-этому если Вам нужны реально высокопроизводительные приложения под ведро\иос - смотрите в сторону инструментов, предлагаемых компаниями-разработчиками данных ОС, ну или Xamarin. Вот испульзуя эти инструменты, Вы получите реально "true native". А так.. все "это" годно только для простейших свисто-перделок, "блокнотов" и АРМов из 3-х таблицы(по типу Employee Directory).

 

 

п.с. Сам я потихоньку "переезжаю" на VisualStudio, AndroidStudio

 

я об этом догадывался, но тщетная надежда все эти годы становления fmx тлела,

видимо это последний, решающий аргумент, печально  :(

Изменено пользователем Sergionn
Ссылка на комментарий
  • 0

http://www.fmxexpress.com/ten-tips-for-migrating-from-c-and-net-to-multi-platform-object-pascal-and-delphi-firemonkey/

поржал от души ))

для опытного дельфиста не составит особого труда изучить .net. 

Я для себя нашел столько полезного...

Только нужно привыкнуть: 

- условие операторе  if условие всегда заключается в скобки

- {} вместо begin end

- нету процедур. есть функции возвращающие void

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

- в паскале все классы обычно начинают с T, в шарпе такого нет, префиксы не указывают

- имена классов, методов, переменных чувствительны к регистру

- нету "объявлений" классов. все "по месту". т.е. interface и implementation объединены

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

- вместо class function идет static

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

- наследование дженериков(да и вообще наследование) реализовано шикарно, не как в дельфях

 

это только то, к чему нужно привыкнуть..

а так... небо и земля... я вот даже преимущество дельфей не могу перечислить, хотя не один год писал...

+ visual studio community edition. все бесплатно.

по поводу ксамарина.. полное покрытие всего апи,

собирал демки: размер апк, объем занимаемой в оперативе памяти, как если бы собирал андроид студией.

да, нужно изучать api каждой платформы( android\ios ), да gui рисуется отдельно для каждой платформы, но подумайте сколько времени Вы тратите на "рисование" гуи, а сколько на отлов багов\исправление "недо-фич", а сколько нервишек то сэкономиться...

Может кто и не согласен, готов побеседовать..

Это ведь так... мой скромный опыт

Ссылка на комментарий
  • 0

Только нужно привыкнуть: 

- условие операторе  if условие всегда заключается в скобки

- {} вместо begin end

- нету процедур. есть функции возвращающие void

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

- в паскале все классы обычно начинают с T, в шарпе такого нет, префиксы не указывают

- имена классов, методов, переменных чувствительны к регистру

- нету "объявлений" классов. все "по месту". т.е. interface и implementation объединены

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

- вместо class function идет static

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

- наследование дженериков(да и вообще наследование) реализовано шикарно, не как в дельфях

 

Дак так во всех СИ подобных языках.

Ссылка на комментарий
  • 0

Лично меня жуть как раздражает XCode, ничего не могу с собой поделать, несколько раз пытался заставить себя юзать этот Objective-C и Swift новый, отвращение от самой студии и языка не передать словами. Xamarin  как я посмотрел на видосе, лагает при прокрутке большого простого списка, т.е. тоже так себе вариант.

Ссылка на комментарий
  • 0

Насрать что сишарп. Качаю, посмотрим :)

Честно говоря, в плане написания для IOS'а абракадабра меня устраивает на все 100. Нет не решаемых задач, и работает шустро, нет никаких подлагиваний, за исключением некоторых моментов с анимацией контролов. Я так понял что у всех нарекания к абракадабре именно из-за андроида.

Изменено пользователем xenon54
Ссылка на комментарий
  • 0

ну... давай вперед ) удачи тебе )

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

насчет xamarin утверждать не буду, не так хорошо его знаю, но поверьте в сообществе стока косяков обсуждают, только других, что грустно становится!

про родные среды (android studio и xcode) все понятно! конечно лучше использовать их и только их, но, как тут ранее сообщалось, меня, например, от java тошнит, от objective-c не так...., понравилась среда (xCode)!

т.к. я программист одиночка, для меня важно накидать единый код и получить android и ios. не всегда получается, но в целом, для прототипов приложений очень даже хорошо! сильно снижаются издержки. автоматом получить 2 приложения! как то так... 

Ссылка на комментарий
  • 0

сначала ждешь первого апдейта, потом второго...

а потом ждать устаешь..

 

не всегда получается, но в целом, для прототипов приложений очень даже хорошо! сильно снижаются издержки. автоматом получить 2 приложения! как то так... 

вот именно, что для ПРОТОТИПОВ !

Ссылка на комментарий
  • 0

По большей части расстраивает даже не ожидание, а результат.

Ждем то апдейтов, а вместо них выходят новые версии. Ну бывают, конечно, апдейты. Но они в реальности не существенны.

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

И это не говоря уже о необходимости постоянной покупки новых версий.

Все понятно, разумеется, что Embarcadero вынуждена поступать таким образом чтобы поддерживать "на плаву" свое детище и как-то развиваться. Но проблема то как-раз и заключается в том что - "поддерживать на плаву"...

 

З.Ы. Очень хотелось бы видеть не одно, в лучшем случае, обновление, а постоянные апдейты, с действительно необходимыми исправлениями багов. А не добавление новых фишек с привнесением очередной порции глюков.

Сообщество Delphi (и RAD Studio) само бы развило бы функционал за счет новых модулей, компонентов и т.д. Однако это требует стабильности работы и среды и компилятора, и исправление багов.

А то большая часть времени создания проектов уходит именно не написание проекта, а на ловлю багов и глюков FMX.

 

Как-то так...

 

З.З.Ы. Без личных притензий к владельцам форума! (Им за этот форум - отдельное спасибо!)

Изменено пользователем AlexG
Ссылка на комментарий
  • 0
В 14.07.2014 в 16:45, kolyalyan сказал:

У меня следующая проблема, когда подключаюсь к камере телефона, то кадры отображаются с ужасной задержкой, нааамного медленнее чем в сторонних приложениях работающих с камерой.

Для подключения к камере использую следующий код:
 


procedure TForm1.FormShow(Sender: TObject);
var 
   CDM : TCaptureDeviceManager;
   VC : TVideoCaptureDevice;

begin
   CDM := TCaptureDeviceManager.Current;
   VC := CDM.DefaultVideoCaptureDevice; 
   if (VC <> nil) then VC.OnSampleBufferReady := VideoBufferReady;

   VC.StartCapture;
end;

Для загрузки кадров в TImage этот:
 


procedure TForml.VideoBufferReady(Sender: TObject; const ATime: int64); 
var 
   VCD : TVideoCaptureDevice; 

begin
   VCD := Sender as TVideoCaptureDevice;
   VCD.SampleBufferToBitmap(Image1.Bitmap, True);
end;

Ещё раз повторюсь, что всё работает, но чрезвычайно медленно. Пробовал стандартный компонент TCameraComponent, но он работает также или даже ещё медленнее.

Замеры делали в отладчик? На каком методе потери идут?

Ссылка на комментарий
  • 0
1 час назад, Pax Beach сказал:

Замеры делали в отладчик? На каком методе потери идут?

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

Хотя меня тоже интересует тема записи видео в Android :)

Ссылка на комментарий

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

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

Гость
Ответить на вопрос...

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

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

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

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

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

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