je n'ai pas fait encore des tests comparatifs, et puis avant de le
faire, je me suis dit que ça a du être déjà fait...
et hors son, bien entendu, puisque ma demande ne porte que sur la
vidéo, quel est le meilleur compromis ?
(sachant qu'on part d'une source 1080p - en fait une série télé qui
prend une place pas possible)
entre:
* la dimension de l'image
* le codec (xvid, h264 ?)
* le bitrate
* la taille de sortie
* la vitesse de compression (choix du codec et 1 ou 2 passes ?)
pour un visionnage correct sur un écran de plus de 50'
avec une taille de sortie de 12Mo/minute (1Go/1h30), je rappelle, hors
son évidemment.
S'il y avait une série de vidéos presentant un court extrait avec une
scene lente, une scene rapide, en plusieurs formats, ça serait pas
mal... ça n'existe pas deja ?
merde quand vous y comprendrez quelque chose, on vous sonnera
Pehache a parfaitement compris les choses
non
c'est votre dernier mot Thierry ?
Alf92
"Thierry M." a écrit
(...) on en reste a une série de vecteurs bidirectionnels,
un vecteur bidirectionnel ??? tu devrais postuler pour la Médaille Fields !!
quand tu lis "bidirectionnel" en matière de compression video, c'est de l'échelle de temps dont on parle. c'est précisément les B-frames.
pffff supprimez bidirectionnel si vous voulez ça veut simplement dire que ce ne sont que des déplacements linéaires, c'est précisé dans le travail cité plus haut
pris individuellement, tous les micros déplacements sont linéaires. zoomer sur un objet correspond, en matière de compression video, à plusieurs vecteurs de directions différentes mais qui convergent ou divergent tous vers un même point. zoomer peut donc être décrit comme une somme de déplacements linéaires. même si à cela s'ajoute un travelling, une rotation,... on obtient encore au final une somme de déplacements linéaires modélisables pas des vecteurs.
"Thierry M." <thry.NOSPAM.martin@wanadoo.fr.INVALID> a écrit
(...)
on en reste a une série de vecteurs bidirectionnels,
un vecteur bidirectionnel ???
tu devrais postuler pour la Médaille Fields !!
quand tu lis "bidirectionnel" en matière de compression video, c'est de
l'échelle de temps dont on parle.
c'est précisément les B-frames.
pffff
supprimez bidirectionnel si vous voulez
ça veut simplement dire que ce ne sont que des déplacements linéaires, c'est
précisé dans le travail cité plus haut
pris individuellement, tous les micros déplacements sont linéaires.
zoomer sur un objet correspond, en matière de compression video, à plusieurs
vecteurs de directions différentes mais qui convergent ou divergent tous vers un
même point.
zoomer peut donc être décrit comme une somme de déplacements linéaires.
même si à cela s'ajoute un travelling, une rotation,... on obtient encore au
final une somme de déplacements linéaires modélisables pas des vecteurs.
(...) on en reste a une série de vecteurs bidirectionnels,
un vecteur bidirectionnel ??? tu devrais postuler pour la Médaille Fields !!
quand tu lis "bidirectionnel" en matière de compression video, c'est de l'échelle de temps dont on parle. c'est précisément les B-frames.
pffff supprimez bidirectionnel si vous voulez ça veut simplement dire que ce ne sont que des déplacements linéaires, c'est précisé dans le travail cité plus haut
pris individuellement, tous les micros déplacements sont linéaires. zoomer sur un objet correspond, en matière de compression video, à plusieurs vecteurs de directions différentes mais qui convergent ou divergent tous vers un même point. zoomer peut donc être décrit comme une somme de déplacements linéaires. même si à cela s'ajoute un travelling, une rotation,... on obtient encore au final une somme de déplacements linéaires modélisables pas des vecteurs.
Thierry M.
pehache vient de nous annoncer :
Quand on saura faire ça on n'aura plus besoin de tourner des films
il s'agit ici de réflexion sur la compression (ou de conversion 3d ou d'utilitaire aux incrustations), pas de mise en scene ou de jeu d'acteur
donner un déplacement scalaire sur un ensemble de pixels n'est pas une approximation ! l'approximation, c'est faire "comme si" les petits mouvements étaient tous des translations
Ben oui et ça marche.
ne pas mettre de vecteurs du tout aussi "ça marche" ne pas compresser du tout aussi "ça marche"
donner un déplacement scalaire sur un ensemble de pixels n'est pas une
approximation !
l'approximation, c'est faire "comme si" les petits mouvements étaient
tous des translations
Ben oui et ça marche.
ne pas mettre de vecteurs du tout aussi "ça marche"
ne pas compresser du tout aussi "ça marche"
donner un déplacement scalaire sur un ensemble de pixels n'est pas une approximation ! l'approximation, c'est faire "comme si" les petits mouvements étaient tous des translations
Ben oui et ça marche.
ne pas mettre de vecteurs du tout aussi "ça marche" ne pas compresser du tout aussi "ça marche"
donner un déplacement scalaire sur un ensemble de pixels n'est pas une approximation ! l'approximation, c'est faire "comme si" les petits mouvements étaient tous des translations
Ben oui et ça marche.
ne pas mettre de vecteurs du tout aussi "ça marche" ne pas compresser du tout aussi "ça marche"
Vu que tu as coupé la suite (sur les paramètres de rotation/zoom sans avoir besoin de faire de la reconnaissance d'objets), ta réponse devient "facile"
Le 19/05/12 16:47, Thierry M. a écrit :
Il se trouve que pehache a formulé :
donner un déplacement scalaire sur un ensemble de pixels n'est pas une
approximation !
l'approximation, c'est faire "comme si" les petits mouvements étaient
tous des translations
Ben oui et ça marche.
ne pas mettre de vecteurs du tout aussi "ça marche"
ne pas compresser du tout aussi "ça marche"
Vu que tu as coupé la suite (sur les paramètres de rotation/zoom sans
avoir besoin de faire de la reconnaissance d'objets), ta réponse devient
"facile"
donner un déplacement scalaire sur un ensemble de pixels n'est pas une approximation ! l'approximation, c'est faire "comme si" les petits mouvements étaient tous des translations
Ben oui et ça marche.
ne pas mettre de vecteurs du tout aussi "ça marche" ne pas compresser du tout aussi "ça marche"
Vu que tu as coupé la suite (sur les paramètres de rotation/zoom sans avoir besoin de faire de la reconnaissance d'objets), ta réponse devient "facile"
Thierry M.
pehache :
Vu que tu as coupé la suite (sur les paramètres de rotation/zoom sans avoir besoin de faire de la reconnaissance d'objets), ta réponse devient "facile"
aucun intérêt dans mon discours, c'est la technique actuelle, qui évacue le problème des rotations/zoom et des déplacements globaux. c'est de la force brute qui ne peux évoluer (ou même ne serait ce que déjà se paramétrer) qu'en necessitant des progrès en temps processeur, y compris dans la décompression. Je ne dis pas qu'il ne faudra pas aussi du temps processeur pour déterminer les paramètres de transformation globale d'une forme, mais une fois fait, il suffit de très peu de paramètres pour la reconstituer (translation, rotation, zoom) et ce pour la forme tout entière, d'un coup d'un seul : c'était juste ça de "ce dont je quoi je causais" dans ma première intervention sur le sujet.
Et on peut aller encore plus loin si on modélise carrément la forme en 3D et son déplacement dans les 3 dimensions, mais la, on est pour l'instant en pleine science fiction, c'est ce que j'appelle l'aboutissement ultime ou on pourra aussi modéliser parfaitement une scene en 3D a partir d'une scène en 2D pour réaliser des conversions ou des incrustations (2D ou 3D) sans l'intervention du facteur humain, comme c'est le cas actuellement.
Et encore une fois, science fiction (dans l'acceptation litterale non pejorative du terme) ou pas, c'est bien la dessus que les recherches se font, puisque les tentatives de détermination automatique des plans de perspective d'une scene 2D font bien appel à ça !
Donc je n'invente que l'eau chaude et le fil a couper le beurre et je n'avais aucune autre prétention que de donner mon sentiment sur le sujet et non partir en couille dans tous les sens comme vous vous êtes efforcés de le faire !
je ne participe plus a cette discussion.
-- Thierry Qu'est-ce qu' un embryon ? un foetus ? (cours a l'intention des étudiants en médecine - site suisse) http://www.embryology.ch/francais/jfetalperiod/entwicklung01.html#fetal
pehache :
Vu que tu as coupé la suite (sur les paramètres de rotation/zoom sans avoir
besoin de faire de la reconnaissance d'objets), ta réponse devient "facile"
aucun intérêt dans mon discours, c'est la technique actuelle, qui
évacue le problème des rotations/zoom et des déplacements globaux.
c'est de la force brute qui ne peux évoluer (ou même ne serait ce que
déjà se paramétrer) qu'en necessitant des progrès en temps processeur,
y compris dans la décompression. Je ne dis pas qu'il ne faudra pas
aussi du temps processeur pour déterminer les paramètres de
transformation globale d'une forme, mais une fois fait, il suffit de
très peu de paramètres pour la reconstituer (translation, rotation,
zoom) et ce pour la forme tout entière, d'un coup d'un seul : c'était
juste ça de "ce dont je quoi je causais" dans ma première intervention
sur le sujet.
Et on peut aller encore plus loin si on modélise carrément la forme en
3D et son déplacement dans les 3 dimensions, mais la, on est pour
l'instant en pleine science fiction, c'est ce que j'appelle
l'aboutissement ultime ou on pourra aussi modéliser parfaitement une
scene en 3D a partir d'une scène en 2D pour réaliser des conversions ou
des incrustations (2D ou 3D) sans l'intervention du facteur humain,
comme c'est le cas actuellement.
Et encore une fois, science fiction (dans l'acceptation litterale non
pejorative du terme) ou pas, c'est bien la dessus que les recherches se
font, puisque les tentatives de détermination automatique des plans de
perspective d'une scene 2D font bien appel à ça !
Donc je n'invente que l'eau chaude et le fil a couper le beurre
et je n'avais aucune autre prétention que de donner mon sentiment sur
le sujet et non partir en couille dans tous les sens comme vous vous
êtes efforcés de le faire !
je ne participe plus a cette discussion.
--
Thierry
Qu'est-ce qu' un embryon ? un foetus ?
(cours a l'intention des étudiants en médecine - site suisse)
http://www.embryology.ch/francais/jfetalperiod/entwicklung01.html#fetal
Vu que tu as coupé la suite (sur les paramètres de rotation/zoom sans avoir besoin de faire de la reconnaissance d'objets), ta réponse devient "facile"
aucun intérêt dans mon discours, c'est la technique actuelle, qui évacue le problème des rotations/zoom et des déplacements globaux. c'est de la force brute qui ne peux évoluer (ou même ne serait ce que déjà se paramétrer) qu'en necessitant des progrès en temps processeur, y compris dans la décompression. Je ne dis pas qu'il ne faudra pas aussi du temps processeur pour déterminer les paramètres de transformation globale d'une forme, mais une fois fait, il suffit de très peu de paramètres pour la reconstituer (translation, rotation, zoom) et ce pour la forme tout entière, d'un coup d'un seul : c'était juste ça de "ce dont je quoi je causais" dans ma première intervention sur le sujet.
Et on peut aller encore plus loin si on modélise carrément la forme en 3D et son déplacement dans les 3 dimensions, mais la, on est pour l'instant en pleine science fiction, c'est ce que j'appelle l'aboutissement ultime ou on pourra aussi modéliser parfaitement une scene en 3D a partir d'une scène en 2D pour réaliser des conversions ou des incrustations (2D ou 3D) sans l'intervention du facteur humain, comme c'est le cas actuellement.
Et encore une fois, science fiction (dans l'acceptation litterale non pejorative du terme) ou pas, c'est bien la dessus que les recherches se font, puisque les tentatives de détermination automatique des plans de perspective d'une scene 2D font bien appel à ça !
Donc je n'invente que l'eau chaude et le fil a couper le beurre et je n'avais aucune autre prétention que de donner mon sentiment sur le sujet et non partir en couille dans tous les sens comme vous vous êtes efforcés de le faire !
je ne participe plus a cette discussion.
-- Thierry Qu'est-ce qu' un embryon ? un foetus ? (cours a l'intention des étudiants en médecine - site suisse) http://www.embryology.ch/francais/jfetalperiod/entwicklung01.html#fetal
pehache
Le 19/05/12 16:41, Thierry M. a écrit :
pehache vient de nous annoncer :
Quand on saura faire ça on n'aura plus besoin de tourner des films
il s'agit ici de réflexion sur la compression (ou de conversion 3d ou d'utilitaire aux incrustations), pas de mise en scene ou de jeu d'acteur
Au lieu de tourner des videos pour ensuite les analyser et en extraire des objets, mieux vaut créer directement des images de synthèse qui sont justement à base d'objets.
Le 19/05/12 16:41, Thierry M. a écrit :
pehache vient de nous annoncer :
Quand on saura faire ça on n'aura plus besoin de tourner des films
il s'agit ici de réflexion sur la compression (ou de conversion 3d ou
d'utilitaire aux incrustations), pas de mise en scene ou de jeu d'acteur
Au lieu de tourner des videos pour ensuite les analyser et en extraire
des objets, mieux vaut créer directement des images de synthèse qui sont
justement à base d'objets.
Quand on saura faire ça on n'aura plus besoin de tourner des films
il s'agit ici de réflexion sur la compression (ou de conversion 3d ou d'utilitaire aux incrustations), pas de mise en scene ou de jeu d'acteur
Au lieu de tourner des videos pour ensuite les analyser et en extraire des objets, mieux vaut créer directement des images de synthèse qui sont justement à base d'objets.
pehache
Le 19/05/12 18:12, Thierry M. a écrit :
pehache :
Vu que tu as coupé la suite (sur les paramètres de rotation/zoom sans avoir besoin de faire de la reconnaissance d'objets), ta réponse devient "facile"
aucun intérêt dans mon discours, c'est la technique actuelle, qui évacue le problème des rotations/zoom et des déplacements globaux.
Non ils ne sont pas évacués. Ils ne sont pas explicites mais ils sont approximés néamoins.
Et comme je te l'ai déjà dit, même avec le principe des blocs on pourrait parfaitement scanner non pas seulement une translation mais aussi un paramètre de rotation et un paramètre de zoom. C'est tellement évident que ça a forcément dû être déjà essayé, et si ça n'a pas été retenu c'est encore une fois certainement parce que les calculs supplémentaire que ça demande n'apporte pas un gain suffisant en compression.
c'est de la force brute qui ne peux évoluer (ou même ne serait ce que déjà se paramétrer) qu'en necessitant des progrès en temps processeur, y compris dans la décompression.
Oui ben toute l'histoire de la compression repose (en partie) sur les progrès en puissance CPU.
Je ne dis pas qu'il ne faudra pas aussi du temps processeur pour déterminer les paramètres de transformation globale d'une forme, mais une fois fait, il suffit de très peu de paramètres pour la reconstituer (translation, rotation, zoom) et ce pour la forme tout entière, d'un coup d'un seul :
Je crois que tu sous-estimes *sévèrement* la puissance de calcul qu'il faut pour 1) identifier les objets, et 2) analyser leur déplacement.
Le 19/05/12 18:12, Thierry M. a écrit :
pehache :
Vu que tu as coupé la suite (sur les paramètres de rotation/zoom sans
avoir besoin de faire de la reconnaissance d'objets), ta réponse
devient "facile"
aucun intérêt dans mon discours, c'est la technique actuelle, qui évacue
le problème des rotations/zoom et des déplacements globaux.
Non ils ne sont pas évacués. Ils ne sont pas explicites mais ils sont
approximés néamoins.
Et comme je te l'ai déjà dit, même avec le principe des blocs on
pourrait parfaitement scanner non pas seulement une translation mais
aussi un paramètre de rotation et un paramètre de zoom. C'est tellement
évident que ça a forcément dû être déjà essayé, et si ça n'a pas été
retenu c'est encore une fois certainement parce que les calculs
supplémentaire que ça demande n'apporte pas un gain suffisant en
compression.
c'est de la force brute qui ne peux évoluer (ou même ne serait ce que
déjà se paramétrer) qu'en necessitant des progrès en temps processeur, y
compris dans la décompression.
Oui ben toute l'histoire de la compression repose (en partie) sur les
progrès en puissance CPU.
Je ne dis pas qu'il ne faudra pas aussi
du temps processeur pour déterminer les paramètres de transformation
globale d'une forme, mais une fois fait, il suffit de très peu de
paramètres pour la reconstituer (translation, rotation, zoom) et ce pour
la forme tout entière, d'un coup d'un seul :
Je crois que tu sous-estimes *sévèrement* la puissance de calcul qu'il
faut pour 1) identifier les objets, et 2) analyser leur déplacement.
Vu que tu as coupé la suite (sur les paramètres de rotation/zoom sans avoir besoin de faire de la reconnaissance d'objets), ta réponse devient "facile"
aucun intérêt dans mon discours, c'est la technique actuelle, qui évacue le problème des rotations/zoom et des déplacements globaux.
Non ils ne sont pas évacués. Ils ne sont pas explicites mais ils sont approximés néamoins.
Et comme je te l'ai déjà dit, même avec le principe des blocs on pourrait parfaitement scanner non pas seulement une translation mais aussi un paramètre de rotation et un paramètre de zoom. C'est tellement évident que ça a forcément dû être déjà essayé, et si ça n'a pas été retenu c'est encore une fois certainement parce que les calculs supplémentaire que ça demande n'apporte pas un gain suffisant en compression.
c'est de la force brute qui ne peux évoluer (ou même ne serait ce que déjà se paramétrer) qu'en necessitant des progrès en temps processeur, y compris dans la décompression.
Oui ben toute l'histoire de la compression repose (en partie) sur les progrès en puissance CPU.
Je ne dis pas qu'il ne faudra pas aussi du temps processeur pour déterminer les paramètres de transformation globale d'une forme, mais une fois fait, il suffit de très peu de paramètres pour la reconstituer (translation, rotation, zoom) et ce pour la forme tout entière, d'un coup d'un seul :
Je crois que tu sous-estimes *sévèrement* la puissance de calcul qu'il faut pour 1) identifier les objets, et 2) analyser leur déplacement.
