Multimedia programming
11 отговора
374 прегледа
Multimedia programming
Търся информация за обработка на видео:
Т.е ако имам miniDV камера и искам през USB интерфейс да обработвам потока ми трябват спецификациите му и т.н.
Въобще интересува ме всичко което е свързано с lowLevel programming за видео:
Спецификации
Сорсове - АСМ/Ц/Ц++
Сериализиране във стриим
Възпроизвеждане на видео от стиим и т.н
Т.е ако имам miniDV камера и искам през USB интерфейс да обработвам потока ми трябват спецификациите му и т.н.
Въобще интересува ме всичко което е свързано с lowLevel programming за видео:
Спецификации
Сорсове - АСМ/Ц/Ц++
Сериализиране във стриим
Възпроизвеждане на видео от стиим и т.н
Re: Multimedia programming
първо искам да отбележа че съм пил доста, така че предварително моля за извинение ако надрънкам някоя глупост.
така, по същество:
за да се прихване видео вход аз поне съм използевал гнусното нещо наречено DirectShow. това чудо е организирано по доста странен начин - някой тъпак се е опитал да подражава на хардуераните системи и е натворил такива дивотии, че като резултат повечето програми които касаят тази сфера ползват собствени драйвери, с цел избягване на кочината наречена DS. в DS фундаменталната едница е филтърът. филтърът е жалко подражание на хардуерните блокове, като има входни и изходни пинове. всичките компоненти на DS са интерфейси, така че общо взето преди да се захванеш с него, по добре е да хвърлиш едно око на COMа. "схемата" в DS се съсздава с една чудесия наречена IGraphBuilder.тая чудесия може да свързва "филтри" в схема, по подражание на тъпия поялник от реалния живот. за да почнеш да градиш видео граф, първо трябва да хванеш видео сорса. това става по различни начини, ама все тая. търси в мсдн-а за филтри. понеже съм пил много, и едвам си помня името, ето ти един откъс от мсдн-а, по него можеш да си хванеш базовата страница, от която ще разберешщ всичко. съжалявам, толкова от мене. аз си имам клас който съм написал с цел дистанциране от кочината DS, ама няма да ти го дам. айде търси това нещо и сам си блъскай тиквата:
Interfaces
This topic contains reference information for the Microsoft® DirectShow® COM interfaces. To provide broad support for various types of hardware, file formats, and stream operations, DirectShow implements a large number of interfaces. Some are used by applications; others are used internally by filters and other DirectShow components.
Any particular application will use only a small subset of these interfaces. Which interfaces you need depends on the nature of the application. The following tables summarize the application-level interfaces according to their purpose:
Working with Filter Graphs
Audio Capture and Rendering
DVD
External Device Control
Video Capture
Video Encoding and Decoding
Video Rendering, Scaling, and Overlays
TV Tuning
See also:
Alphabetical List of DirectShow Interfaces
DirectShow Filters
DirectShow Components
така, по същество:
за да се прихване видео вход аз поне съм използевал гнусното нещо наречено DirectShow. това чудо е организирано по доста странен начин - някой тъпак се е опитал да подражава на хардуераните системи и е натворил такива дивотии, че като резултат повечето програми които касаят тази сфера ползват собствени драйвери, с цел избягване на кочината наречена DS. в DS фундаменталната едница е филтърът. филтърът е жалко подражание на хардуерните блокове, като има входни и изходни пинове. всичките компоненти на DS са интерфейси, така че общо взето преди да се захванеш с него, по добре е да хвърлиш едно око на COMа. "схемата" в DS се съсздава с една чудесия наречена IGraphBuilder.тая чудесия може да свързва "филтри" в схема, по подражание на тъпия поялник от реалния живот. за да почнеш да градиш видео граф, първо трябва да хванеш видео сорса. това става по различни начини, ама все тая. търси в мсдн-а за филтри. понеже съм пил много, и едвам си помня името, ето ти един откъс от мсдн-а, по него можеш да си хванеш базовата страница, от която ще разберешщ всичко. съжалявам, толкова от мене. аз си имам клас който съм написал с цел дистанциране от кочината DS, ама няма да ти го дам. айде търси това нещо и сам си блъскай тиквата:
Interfaces
This topic contains reference information for the Microsoft® DirectShow® COM interfaces. To provide broad support for various types of hardware, file formats, and stream operations, DirectShow implements a large number of interfaces. Some are used by applications; others are used internally by filters and other DirectShow components.
Any particular application will use only a small subset of these interfaces. Which interfaces you need depends on the nature of the application. The following tables summarize the application-level interfaces according to their purpose:
Working with Filter Graphs
Audio Capture and Rendering
DVD
External Device Control
Video Capture
Video Encoding and Decoding
Video Rendering, Scaling, and Overlays
TV Tuning
See also:
Alphabetical List of DirectShow Interfaces
DirectShow Filters
DirectShow Components
Re: Multimedia programming
като за начало смея да кажа, че за пийнал човек се справяш направо чудесно....!!!
Благодаря за инфото.
Благодаря за инфото.
Re: Multimedia programming
С много неблагодарна работа си се захванал...
Всичко което каза zaphod е вярно, плюс гнусното нещо че използвайки DirectShow, не може да разчиташ на никаква точност: кога-какво (не) е дошло на видео/аудио входовете.
А иначе ако си говорим за "low level" програмиране, трябва (почти) да забравиш за DirectShow и да погледнеш другото чудо наречено kernel streaming. С него аз успях да си реша проблемите (почти) по отношение на време на пристигане, брой пропуснати кадри и прочие...
А ето ти човека който е измислил DirectShow:
Geraint Davies
[линк]
---
Не е важно да си добър, важното е да си ман-и-як!
Всичко което каза zaphod е вярно, плюс гнусното нещо че използвайки DirectShow, не може да разчиташ на никаква точност: кога-какво (не) е дошло на видео/аудио входовете.
А иначе ако си говорим за "low level" програмиране, трябва (почти) да забравиш за DirectShow и да погледнеш другото чудо наречено kernel streaming. С него аз успях да си реша проблемите (почти) по отношение на време на пристигане, брой пропуснати кадри и прочие...
А ето ти човека който е измислил DirectShow:
Geraint Davies
[линк]
---
Не е важно да си добър, важното е да си ман-и-як!
Re: Multimedia programming
Доколкото си спомням някакви историческо-клюкарски статийки които четох навремето, идиотския дизайн на DirectShow е резултат не от имитиране на хардуер, а от прекомерна любов към функционалното програмиране.
а какво е функционално програмиране?
щото ако наистина е резултат от него, ще се вардя като дявол от тамян
какъв е тоя kernel streaming?
аз нямам оплаквания от пропускане на кадри и забавяне, обаче ми е любопитно все пак. по името ми прилича на нещо дето бачка в ринг 0.
Re: а какво е функционално програмиране?
Да ти обясни човека с функционално-програмиращ ник ;-)
И, господа, грижете се за мързеливите: недейте да пишете важни неща в subject-а на постовете, че в e-mail notification-а тъпия софтуер на ДИРа не ги праща...
И, господа, грижете се за мързеливите: недейте да пишете важни неща в subject-а на постовете, че в e-mail notification-а тъпия софтуер на ДИРа не ги праща...
Re: какъв е тоя kernel streaming?
О, щастливец си ти...
Зависи какво правиш. Например ако имаш програма която сваля full PAL video & audio и пишеш в компресиран файл (AVI), като по същото това време четеш и декомпресираш файла от произволно място, доста зор ще видиш. И не защото процесора и диска е бавен, ами защото стават много threads, messages и прочие в системата (които трябва да са real-time ако може) и тя се чуди на кого да обърне внимание. Да не говорим, че някои драйвери на capture платки просто не докладват пропуснатите кадри. Сигурен съм в това, защото винаги съм свалял материал с вграден time-code в картината и се вижда как drop-ва без да каже...
А kernel-streaming е нещото (user-side, ring 3) което се ползва от DirectShow. Работейки само с него, обаче, имаш пълен контрол върху процеса на сваляне, като знаеш точно кога ти е пристигнал поредният frame, и можеш да си правиш сметката дали си пропуснал или не.
В заключение, мога да кажа само едно: с трици маймуни не се ловят.
Т.е. с евтин хардуер (capture платка за $40-50) и generic software (DirectShow) не става...Поне едно от нещата трябва да е по-custom и пак не 100% сигурно.
---
Не е важно да си добър, важното е да си ман-и-як!
Зависи какво правиш. Например ако имаш програма която сваля full PAL video & audio и пишеш в компресиран файл (AVI), като по същото това време четеш и декомпресираш файла от произволно място, доста зор ще видиш. И не защото процесора и диска е бавен, ами защото стават много threads, messages и прочие в системата (които трябва да са real-time ако може) и тя се чуди на кого да обърне внимание. Да не говорим, че някои драйвери на capture платки просто не докладват пропуснатите кадри. Сигурен съм в това, защото винаги съм свалял материал с вграден time-code в картината и се вижда как drop-ва без да каже...
А kernel-streaming е нещото (user-side, ring 3) което се ползва от DirectShow. Работейки само с него, обаче, имаш пълен контрол върху процеса на сваляне, като знаеш точно кога ти е пристигнал поредният frame, и можеш да си правиш сметката дали си пропуснал или не.
В заключение, мога да кажа само едно: с трици маймуни не се ловят.
Т.е. с евтин хардуер (capture платка за $40-50) и generic software (DirectShow) не става...Поне едно от нещата трябва да е по-custom и пак не 100% сигурно.
---
Не е важно да си добър, важното е да си ман-и-як!
Re: какъв е тоя kernel streaming?
наплаши ме бе човек
- мен изтърването на кадри ми е много нежелано, та се обезпокоих от това което каза.
но може би това с изтърването на кадрите зависи от драйвера, щото кепчъра ми е възможно най-евтин. аз съм набарал един драйвер и го слагам на всички платки с чип на конексант. драйвера е за 2000, но върви и под 98. не съм забелязал да изтърва кадри, а процесора ми е максимално натоварен. кепчъра ми трябва за да следя координати на светещ обект, който се появява за много малко - да речем 1милисекунда. ако имаше изтървани кадри, щях да изтървам появяването му понякога, но не ми се е случвало, поне не съм забелязал.
но може би това с изтърването на кадрите зависи от драйвера, щото кепчъра ми е възможно най-евтин. аз съм набарал един драйвер и го слагам на всички платки с чип на конексант. драйвера е за 2000, но върви и под 98. не съм забелязал да изтърва кадри, а процесора ми е максимално натоварен. кепчъра ми трябва за да следя координати на светещ обект, който се появява за много малко - да речем 1милисекунда. ако имаше изтървани кадри, щях да изтървам появяването му понякога, но не ми се е случвало, поне не съм забелязал.
Re: какъв е тоя kernel streaming?
Интересно какви са драйверите? Има едни free, които са за Brooktree Bt848,Bt849,Bt878 и Bt879 (т.е. вече Conexant):
[линк]
Да не са те?
А по отношение на светещият обект, ми е много странно това което казваш: по принцип (би трябвало да знаеш), че видео кепчърите дигитализират минимално на 20мс (PAL), т.е. един полу-кадър (field) и предават цял кадър/квадрат (frame) на 40мс - т.е. 25 в секунда. Не съм сигурен какво е времето за вертикалната синхронизация (т.е. превключването между отделните полу-кадри) и за колко време чипа се усеща и започва да дигитализира, ама да не се окаже че има проблем? Не съм много запознат с PAL стандарта, може би някой друг (примерно от ТУ) трябва да каже.
А за изтърваните кадри, проблема при тебе може и да не стои, ако входа ти е от камера, но ако сваляш от какъвто и да е (т.е. амортизирано битово видео примерно), тогава входният сигнал може да е нестабилен и това създава проблеми - както споменах по-горе, чипа следи разни синхро импулси и може да не прещрака навреме и се отказва. И тогава губиш....
А като се намеси и синхронизация с аудиото - направо си в джаза
---
Не е важно да си добър, важното е да си ман-и-як!
[линк]
Да не са те?
А по отношение на светещият обект, ми е много странно това което казваш: по принцип (би трябвало да знаеш), че видео кепчърите дигитализират минимално на 20мс (PAL), т.е. един полу-кадър (field) и предават цял кадър/квадрат (frame) на 40мс - т.е. 25 в секунда. Не съм сигурен какво е времето за вертикалната синхронизация (т.е. превключването между отделните полу-кадри) и за колко време чипа се усеща и започва да дигитализира, ама да не се окаже че има проблем? Не съм много запознат с PAL стандарта, може би някой друг (примерно от ТУ) трябва да каже.
А за изтърваните кадри, проблема при тебе може и да не стои, ако входа ти е от камера, но ако сваляш от какъвто и да е (т.е. амортизирано битово видео примерно), тогава входният сигнал може да е нестабилен и това създава проблеми - както споменах по-горе, чипа следи разни синхро импулси и може да не прещрака навреме и се отказва. И тогава губиш....
А като се намеси и синхронизация с аудиото - направо си в джаза
---
Не е важно да си добър, важното е да си ман-и-як!
Re: какъв е тоя kernel streaming?
абе драйверите дойдоха с един кепчър, оказаха се добри и ги тикам навсякъде. сложих ги и на домашния си компот, който до преди това беше безнадежден по отношение на програми ползващи DS. не мога да ги разпозная по линка който даваш, познавам ги по цвета на ЦДто на което са - сино с лилава ивица
а относно стандарта на видеосигнала - прав си един полукадър е 20мс и аз много се дразня че кепчъра ги събира и дава цял кадър на всеки 40мс. това води до супернеприятен ефект - назъбване на движещите се обекти.
а относно краткия светещ сигнал - няма проблем да се хване, стига да не попадне в така наречения "shuter" - време през което камерата е сляпа. регулирането на това време е един вид "бленда". ако камерата работи на тъмно, шатъра става почти 0, но за съжаление не съвсем. така че има долна граница на минимално краткия импулс който може да се хване. но не всички камери са така, някои правят регулирането по друг начин.
а аудио през DS не съм ползвал никога, и дано не ми се налага.
а относно стандарта на видеосигнала - прав си един полукадър е 20мс и аз много се дразня че кепчъра ги събира и дава цял кадър на всеки 40мс. това води до супернеприятен ефект - назъбване на движещите се обекти.
а относно краткия светещ сигнал - няма проблем да се хване, стига да не попадне в така наречения "shuter" - време през което камерата е сляпа. регулирането на това време е един вид "бленда". ако камерата работи на тъмно, шатъра става почти 0, но за съжаление не съвсем. така че има долна граница на минимално краткия импулс който може да се хване. но не всички камери са така, някои правят регулирането по друг начин.
а аудио през DS не съм ползвал никога, и дано не ми се налага.