Hello,
 
Voilà la situation : j'ai une camera connectée à un PC par BUS IEEE-1394, elle fournit des données par le protocole ?1394 - based Digital Camera Specification?. Je veux compresser ces données en temps réel et les envoyer par wifi.
 
1) Une carte d'acquisition est elle nécessaire (les données fournies sont non compressées donc je ne vois pas l'utilité d'une carte d'acquisition) ?
 
2) Existe t'il des solutions softs pour compresser ces données brutes ?
 
Merci.

Skoi le rapport avec programmation?
Demande plutot dans video/son, non?

 
Je cherche des algos pour faire cette compression. Au pire un soft s'il existe.

Il faudrait un peu plus de précisions...
OS, but recherché?
Impératifs de taille, de qualité?
 

 
Je reste volontairement vaste pour avoir un max de pistes.

   
Alors je peux pas t'aider...c'est beaucoup trop vaste, je ne sais pas (du tout) par ou commencer!

 
   
Déjà peu de gens connaissent/utilisent le protocole ?1394 - based Digital Camera Specification?, toute information sera bonne à prendre (de toute façon, mes questions sont pour l'instant d'ordre général):  
 
1) Est ce qu'une carte d'acquisition est utile avec ce protocole (images non compressées) ?
 
2) Est il facile (existe t'il des softs/SDK) de passer de ce format à un autre format plus compressé (débit de l'ordre de 3 Mbps) ?
 
Soit tu peux répondre soit tu peux pas. Mais je ne vois pas en quoi c'est impossible de répondre à ça "sans plus de précisions".
 
Je n'en suis qu'à une phase de définition de specs...

si tu recois les images en non-compressees avec ton protocole, tu n'as pas besoin de carte d'acquisition, car a priori le signal reçu est numerique, donc pas de conversion en hard a faire.
Les donnees reçu doivent tout de meme etre dans dans un format specifique (pas forcement du RVB), faut esperer que c'est en YUV 4:2:0 (c'est le plus courant pour de la video).
Pour les compresser en soft, il faut quand meme prevoir une machine "relativement" puissante ...
il existe bien sur des softs/API libre pour compresser tes donnes dans des formats varies repondant a une norme (Mpeg x,H26x).
 
La solution qui me parait la plus simple consiste a utiliser un soft (en ligne de commande) pour compresser ton signal. Le choix va dependre de l'OS, et pour ca, va voir dans la cat. video

tu veux faire quoi en fait ?
 
passke un solution sous windows, serait d'utiliser video for windows ou autre, et d'utiliser un codec de compression (divx/xvid....)

 
Merci pour tes infos.
 
C'est du YUV 4:2:2 en 1300*1030.
Si tu connais des softs de compression temps réel qui prennent en entrée des données issues du protocole "1394 - based Digital Camera Specification", je suis preneur !  
 
Est il simple de faire ainsi du quasi-direct (décalage non perceptible pour l'humain) : "réception + compression + envoi par wifi + reception wifi + décompression" en continu et en temps réel ????  

A moins que je ne me plante misérablement (ce qui n'est pas à exclure), le protocole IEEE 1394, c'est du DV (ou iLink, ou autre...). Tu doit pouvoir connecter ta caméra sur n'importe quelle carte DV. A partir de là, regarde comment tu peux récupérer les infos de la carte DV, mais la plupart sont compatibles DirectShow (en effet MS a déjà fait le filtre d'acquisition DV) et tu peux donc utiliser quasimment tous les logiciels disponibles sous Windows et tu peux même, en utilisant le SDK DirectShow, faire toi même ton soft.

Ca veut rien dire ca.
Le protocole c'est 1394 => firewire!
 
 

 
dépend de ta machine...
Si tu as un port firewire pas besoin (à moins qu'elle ne soit pas capable d'assurer la capture au débit de ta caméra).
 

 
Tous les logiciels d'édition video doivent le faire, maintenant.
 

Tu ne posais quasiment aucune question précise en rapport avec la programmation, pour ce genre de renseignements la catégorie video/son est là.

 
Non justement, c'est là le hic : la camera n'est pas DV. Le protocole IEEE-1394, c'est le FireWire. Sony a intégré le IEEE-1394 sous le nom "iLink" permettant de transmettre des données au format DV, format à destination du grand public ou des applications industrielles ne nécessitant pas un grand contrôle sur le format des données transmises (figé et imposé). Le "1394-based Digital Camera Specification" est un autre protocole utilisant le même le IEEE-1394.
 

 
Un soft de compression temps réel ca existe pas...par définition la rapidité d'un soft dépend de la machine sur laquelle il tourne.
 

cf plus haut...il n'y a pas de réponse universelle.
Sur un pentium 200 ce ne sera pas facile, en tout cas.

En gros c'est des données brutes qui transitent via firewire...Pas de raison que les logiciels d'édition video existants ne sachent pas lire ca...

 
Là, excuse moi, mais tu es mal renseigné ! (cf post précédent).
 

 
Oui  , implicitement bien sur, la question était "Est ce que j'ai besoin d'une carte d'acquisition avec ce protocole si j'ai déjà un port firewire".
 

 
En es tu sur ? Parce que ce protocole est très spécifique (c'est pas du DV).  
 

 
C'est une question d'ordre général certes, mais je pense que ce topic a sa place ici. (post précédent).

 
Tu sais ce que c'est un programme temps réel     ?

T'aurais pas pu le dire plus tot au lieu de nous sortir ce truc qui en gros veut dire "specification de camera digitale basée sur le protocole 1394"?
 
 

 
D'après le texte que tu as collé c'est du brut...
Ca devrait pas être trop violent à décoder, donc...

bof...

Donne tjrs ta définition...
Chez moi du temps réel pour de la compression vidéo c'est un prog capable de sortir la video compressée à la même vitesse que les données brutes lui sont fournies...

 
J'y peux rien moi si c'est le nom du protocole . Je traduis pas "FireWire" par "Fil métallique de feu", paskeu sinon, ceux qui connaissent le FireWire ne sauraient pas de quoi je parle.
 

 
Je suis d'accord, mais ya qd même du boulot pour lire les trames (isoler la partie données, pixels au format YUV 4:2:2...), donc si c'est déjà fait...

 
Pour moi le caractère "temps réel" d'une application n'est pas remis en cause par le fait qu'on puisse trouver une machine suffisamment peu puissante sur laquelle l'application ne sera plus temps réel.
 
Qd je disais chercher un soft de compression temps réel, c'était bien évidemment sous entendu "temps réel sur le PC moyen actuel".

 
Je te demande pas de traduire...je te demande juste d'exposer le maximum de données du pb qd tu poses une question...ca evite de partir sur de fausses pistes et tout le monde gagne du temps.
 

Tu n'as pas d'échantillons de video récupérées via cette caméra?
Tu n'as pas de specs plus précises du format?
Il doit bien y avoir kkchose de fourni avec ce matos (soft, drivers, sdk, doc...)?

La config moyenne du moment est pas forcément facile à définir...
Tu n'as que de la video ou également du son?
Tu as des contraintes de débit ou non? (débit du wifi???)
Ca va bcp dépendre de l'algorithme de compression que tu vas utiliser...entre du divx et du mjpeg par exemple il y a un monde...

 
Si j'ai des specs, mais franchement, elles sont assez indigestes, je vais pas te les faire lire, c'est assomant    
 
Bah justement apparemment ya pas grd chose de fourni avec (ils n'en disent rien en tout cas). J'ai juste trouvé une librairie qui permet "l'acquisition" de ce format :
 
http://www-2.cs.cmu.edu/~iwan/1394/
 
En fait le rôle de cette lib est assez peu clair pour moi...

Une source pour avoir un ordre d'idée de la puissance nécéssaire pourrait être le forum dévelo de k!tv...
Au cas ou tu ne connaitrais pas c'est un soft pour mater la tv, qui permet depuis quelques version d'enregistrer avec compression.
C'est évidemment une résolution bien plus faible, mais ca peut tjrs te donner une intuition pour ton cas...

A priori cette lib te permet de piloter le driver fourni avec, non?
En plus tu as une appli d'exemple fournie avec...!
Il semblerait donc que tu aies déjà tout ce qui concerne la gestion de la caméra de fait.
Dasn ce cas il ne devrait plus te rester comme a dit gatorette qu'à utiliser directshow pour ton appli.

 
  Justement, je cherche un format streamable entre ces deux formats extrèmes:  
 
DivX :  
peu de bande passante -> OK pour le wifi
compression temporelle -> demande un certain nombre de frames -> décalage -> perte éventuelle du "direct"
 
MJpeg :
pas de compression temporelle -> pas de "bufferisation" -> "direct" assuré.
Bande passante énorme -> chaud par wifi.
 
 

 
Que de la video.  
Débit du wifi : pas compter plus de 3-4 Mbps en pratique pour du 802.11b (11 Mbps théoriques).

 
Cool    
Tu as l'adresse ?

Le mieux c'est de faire des tests, non?
Tu commences par faire une étude du débit que tu as à ta dispo, et tu regardes grosso modo ce que ca donne comme compression...
La puissance machine nécéssaire sera inversement proportionnelle au débit disponible...
De tte façon avec directshow tu codes de la même façon kksoit le codec employé à priori...

c déjà pas mal!

http://forumdev.fr.st/
Ils pourront certainement t'aider pour directshow, si tu leur demandes gentiment.
De tte façon tu pourras voir les sources de k!tv je pense, c'est opensource il me semble.

 
C'est tout le pb des specs :
 
Evaluer la puissance nécessaire avant que les algos soient développés et sans pouvoir faire de tests puisque le matos n'est par encore commandé (il le sera quand les specs seront terminées et que j'aurais opté pour un matos particulier choisi en fonction de ces specs)  

Autre indice: une machine assez récente est capable d'encoder un dvd en divx en temps réel...

Tu as déjà la caméra ou pas?
Si oui rien ne t'empeche de te faire une idée en l'installant sur une machine dont tu disposes déjà...

 
Tu es sur de ça ?
 
J'ai constaté en lecture de DivX (et donc sans doute également en compression d'image brute qui est l'opération inverse), que plus le bitrate était élevé (plus le taux de compression était faible donc), plus les ressources proco étaient utilisées plein pot...
 
Intuitivement, on a tendance à penser que plus le taux de compression est faible, moins le proco a de boulot à faire pour décompresser la vidéo. Pourtant, si on se met à penser "FFT" (fast fourrier transform), on se rend compte que :
 
faible taux de compression => plus d'info codées en fréquentiel à retransformer : l'algo a plus de données à traiter.
 
Quel est le bon raisonnement  

 
Je me demande si algorythmiquement le passage du MPEG2 au DivX se fait avec un intermédiaire "décompression complète du MPEG2" ou non.
 
Si c'est le cas, il y a des chances pour que la compression en DivX depuis le format Mpeg2 soit moins gourmande que depuis le formatr "images non compressées".

bah euh...pas sur-sur, mais à priori oui...
C'est vrai que j'y ai pas réfléchi avec l'algo de la fft sous les yeux, mais intuitivement plus tu as de bp dispo moins tu vas avoir à faire d'efforts pour y faire rentrer tes données...
Après il faut voir aussi bcp de choses, notamment si tu te permets de modifier la réso de sortie, voire d'avoir une réso de sortie variable, etc...
En sortie il se passera quoi concrètement?
 
(to be continued  ce soir ou demain...on m'attend pour manger.)

 
Merci pour ton aide en tout cas

Possible...voir la cat video/son!
à contacter:
bruce
blacksun
jesus-christ
...