Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1440 connectés 

  FORUM HardWare.fr
  Programmation
  Algo

  Compression Camera-IEEE1394 -> Mpeg ou autre

 


 Mot :   Pseudo :  
 
 Page :   1  2
Page Précédente
Auteur Sujet :

Compression Camera-IEEE1394 -> Mpeg ou autre

n°384649
leFab
Itadakimasu !!!
Posté le 06-05-2003 à 16:09:24  profilanswer
 

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.


---------------
L'ennemi est con : il croit que c'est nous l'ennemi, alors que c'est lui ! (Desproges)
mood
Publicité
Posté le 06-05-2003 à 16:09:24  profilanswer
 

n°384673
skeye
Posté le 06-05-2003 à 16:18:32  profilanswer
 

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

n°384690
leFab
Itadakimasu !!!
Posté le 06-05-2003 à 16:25:26  profilanswer
 

skeye a écrit :

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.


---------------
L'ennemi est con : il croit que c'est nous l'ennemi, alors que c'est lui ! (Desproges)
n°384697
skeye
Posté le 06-05-2003 à 16:30:31  profilanswer
 

leFab a écrit :


 
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é?
 

n°384699
leFab
Itadakimasu !!!
Posté le 06-05-2003 à 16:31:39  profilanswer
 

skeye a écrit :


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.


---------------
L'ennemi est con : il croit que c'est nous l'ennemi, alors que c'est lui ! (Desproges)
n°384703
skeye
Posté le 06-05-2003 à 16:32:43  profilanswer
 

leFab a écrit :


 
Je reste volontairement vaste pour avoir un max de pistes.


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

n°384773
leFab
Itadakimasu !!!
Posté le 06-05-2003 à 16:56:28  profilanswer
 

skeye a écrit :


 :pfff:  
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...


Message édité par leFab le 06-05-2003 à 16:57:44

---------------
L'ennemi est con : il croit que c'est nous l'ennemi, alors que c'est lui ! (Desproges)
n°384875
bobuse
Posté le 06-05-2003 à 17:32:17  profilanswer
 

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


---------------
get amaroK plugin
n°384911
bjone
Insert booze to continue
Posté le 06-05-2003 à 17:41:56  profilanswer
 

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....)

n°384950
leFab
Itadakimasu !!!
Posté le 06-05-2003 à 18:15:30  profilanswer
 

bobuse a écrit :

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


 
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 ????  :??:


---------------
L'ennemi est con : il croit que c'est nous l'ennemi, alors que c'est lui ! (Desproges)
mood
Publicité
Posté le 06-05-2003 à 18:15:30  profilanswer
 

n°384967
gatorette
Posté le 06-05-2003 à 18:47:57  profilanswer
 

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.


---------------
each day I don't die is cheating
n°384975
skeye
Posté le 06-05-2003 à 19:00:31  profilanswer
 

leFab a écrit :


 
 :??:  
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):  


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

Citation :


1) Est ce qu'une carte d'acquisition est utile avec ce protocole (images non compressées) ?


 
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).
 

Citation :


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) ?


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

Citation :


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...


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à.


Message édité par skeye le 06-05-2003 à 19:01:53
n°384977
leFab
Itadakimasu !!!
Posté le 06-05-2003 à 19:02:12  profilanswer
 

gatorette a écrit :

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.


 
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.
 

Citation :

In consumer and broadcast equipment with an i.LINK
interface, DV-standard based video signals are transmitted,
combined with audio, time code and commands like ?play?,
?stop? and ?rewind?. The picture has fixed resolution, aspect
ratio (4:3 or 16:9) and frame rates (PAL/NTSC), and is
compressed with the audio through the AVC protocol,
typically at 33 Mb/s bandwidth.
For industrial video data, the camera is assumed to have any
resolution or frame rate, to transmit pure data without any
compression, and to be remotely controllable for DSP
functions. Therefore, adopting IEEE 1394 for industrial
cameras has provided a huge opportunity to overcome
previous limitations by using a specific protocol:
"1394-based Digital Camera Specification", issued by the
DC working group of the 1394 Trade Association.
Technologies


---------------
L'ennemi est con : il croit que c'est nous l'ennemi, alors que c'est lui ! (Desproges)
n°384978
skeye
Posté le 06-05-2003 à 19:04:40  profilanswer
 

leFab a écrit :


 
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 !  


 
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.
 

Citation :


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 ????  :??:  


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

n°384984
skeye
Posté le 06-05-2003 à 19:09:44  profilanswer
 

leFab a écrit :


In consumer and broadcast equipment with an i.LINK
interface, DV-standard based video signals are transmitted,
combined with audio, time code and commands like ?play?,
?stop? and ?rewind?. The picture has fixed resolution, aspect
ratio (4:3 or 16:9) and frame rates (PAL/NTSC), and is
compressed with the audio through the AVC protocol,
typically at 33 Mb/s bandwidth.
For industrial video data, the camera is assumed to have any
resolution or frame rate, to transmit pure data without any
compression, and to be remotely controllable for DSP
functions. Therefore, adopting IEEE 1394 for industrial
cameras has provided a huge opportunity to overcome
previous limitations by using a specific protocol:
"1394-based Digital Camera Specification", issued by the
DC working group of the 1394 Trade Association.
Technologies


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...

n°384986
leFab
Itadakimasu !!!
Posté le 06-05-2003 à 19:10:15  profilanswer
 

Citation :

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


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

Citation :

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).


 
Oui  :jap:, 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".
 

Citation :


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


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

Citation :


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à.


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


---------------
L'ennemi est con : il croit que c'est nous l'ennemi, alors que c'est lui ! (Desproges)
n°384987
leFab
Itadakimasu !!!
Posté le 06-05-2003 à 19:12:45  profilanswer
 

skeye a écrit :


 
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.


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


---------------
L'ennemi est con : il croit que c'est nous l'ennemi, alors que c'est lui ! (Desproges)
n°384992
skeye
Posté le 06-05-2003 à 19:14:33  profilanswer
 

leFab a écrit :


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


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"? :o
 
 

Citation :


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


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

Citation :


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


bof...


Message édité par skeye le 06-05-2003 à 19:15:46
n°384994
skeye
Posté le 06-05-2003 à 19:15:12  profilanswer
 

leFab a écrit :


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


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...


Message édité par skeye le 06-05-2003 à 19:19:07
n°384998
leFab
Itadakimasu !!!
Posté le 06-05-2003 à 19:19:31  profilanswer
 


Citation :

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"? :o


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

Citation :

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


 
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...


---------------
L'ennemi est con : il croit que c'est nous l'ennemi, alors que c'est lui ! (Desproges)
n°385005
leFab
Itadakimasu !!!
Posté le 06-05-2003 à 19:23:52  profilanswer
 

skeye a écrit :


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...


 
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. [:spamafote]
 
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".


---------------
L'ennemi est con : il croit que c'est nous l'ennemi, alors que c'est lui ! (Desproges)
n°385008
skeye
Posté le 06-05-2003 à 19:24:32  profilanswer
 

leFab a écrit :


Citation :

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"? :o


 
J'y peux rien moi si c'est le nom du protocole [:spamafote]. 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 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.
 

Citation :


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...


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...)?

n°385015
skeye
Posté le 06-05-2003 à 19:27:56  profilanswer
 

leFab a écrit :


 
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. [:spamafote]
 
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".


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...

n°385016
leFab
Itadakimasu !!!
Posté le 06-05-2003 à 19:30:22  profilanswer
 

skeye a écrit :


 
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.
 

Citation :


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...


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...)?
 


 
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...


---------------
L'ennemi est con : il croit que c'est nous l'ennemi, alors que c'est lui ! (Desproges)
n°385017
skeye
Posté le 06-05-2003 à 19:30:30  profilanswer
 

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...

n°385022
skeye
Posté le 06-05-2003 à 19:33:49  profilanswer
 

leFab a écrit :


 
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...


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.

n°385023
leFab
Itadakimasu !!!
Posté le 06-05-2003 à 19:33:59  profilanswer
 

skeye a écrit :


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...


 
 :jap: 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.
 
 :sweat:


---------------
L'ennemi est con : il croit que c'est nous l'ennemi, alors que c'est lui ! (Desproges)
n°385026
leFab
Itadakimasu !!!
Posté le 06-05-2003 à 19:35:05  profilanswer
 

skeye a écrit :


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...


 
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).


---------------
L'ennemi est con : il croit que c'est nous l'ennemi, alors que c'est lui ! (Desproges)
n°385028
leFab
Itadakimasu !!!
Posté le 06-05-2003 à 19:35:57  profilanswer
 

skeye a écrit :

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...


 
Cool  :)  
Tu as l'adresse ?


---------------
L'ennemi est con : il croit que c'est nous l'ennemi, alors que c'est lui ! (Desproges)
n°385030
skeye
Posté le 06-05-2003 à 19:38:23  profilanswer
 

leFab a écrit :


 
 :jap: 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.
 
 :sweat:  


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...

n°385031
skeye
Posté le 06-05-2003 à 19:39:05  profilanswer
 

leFab a écrit :


 
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).


c déjà pas mal!

n°385033
skeye
Posté le 06-05-2003 à 19:40:06  profilanswer
 

leFab a écrit :


 
Cool  :)  
Tu as l'adresse ?


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.

n°385036
leFab
Itadakimasu !!!
Posté le 06-05-2003 à 19:41:38  profilanswer
 

skeye a écrit :


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'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)  :sweat:


---------------
L'ennemi est con : il croit que c'est nous l'ennemi, alors que c'est lui ! (Desproges)
n°385046
skeye
Posté le 06-05-2003 à 19:45:49  profilanswer
 

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

n°385055
skeye
Posté le 06-05-2003 à 19:52:39  profilanswer
 

leFab a écrit :


 
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)  :sweat:  


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à...

n°385057
leFab
Itadakimasu !!!
Posté le 06-05-2003 à 19:53:15  profilanswer
 

skeye a écrit :


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...


 
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  [:carbonim]


---------------
L'ennemi est con : il croit que c'est nous l'ennemi, alors que c'est lui ! (Desproges)
n°385064
leFab
Itadakimasu !!!
Posté le 06-05-2003 à 19:56:11  profilanswer
 

skeye a écrit :

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


 
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".


---------------
L'ennemi est con : il croit que c'est nous l'ennemi, alors que c'est lui ! (Desproges)
n°385069
skeye
Posté le 06-05-2003 à 20:01:18  profilanswer
 

leFab a écrit :


 
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  [:carbonim]  


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.)

n°385072
leFab
Itadakimasu !!!
Posté le 06-05-2003 à 20:03:07  profilanswer
 

skeye a écrit :


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 :jap:


Message édité par leFab le 06-05-2003 à 20:03:35

---------------
L'ennemi est con : il croit que c'est nous l'ennemi, alors que c'est lui ! (Desproges)
n°385073
skeye
Posté le 06-05-2003 à 20:03:35  profilanswer
 

leFab a écrit :


 
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".


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


Message édité par skeye le 07-05-2003 à 10:51:53
mood
Publicité
Posté le   profilanswer
 

 Page :   1  2
Page Précédente

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  Algo

  Compression Camera-IEEE1394 -> Mpeg ou autre

 

Sujets relatifs
[JS] algo de compression, zip ou autre[OpenGL]Gestion de la souris en glut pour faire une caméra
Chercehe librairie de compression d'image losslessRecherche infos sur algo d'encodage MPEG, et autres ...
[Reseaux de neurones]Cherche infos sur: compression image, reco typo,Composant de compression/décompression de fichiers zip
compression gzip des pages (please help me!)compression zip
Compression de programmes (upc, etc...)Compression avec zlib (ou libz au choix)
Plus de sujets relatifs à : Compression Camera-IEEE1394 -> Mpeg ou autre


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR