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 ?
je ne connais aucun moyen fiable en HD de corriger le décalage son qui se produit en transcodant depuis l'enregistrement de la télé vers quoi que ce soit d'autre (ni même de moyen de couper la partie qui m'intéresse), la suite est donc sans utilité :-(
Note que j'aimerai pouvoir le faire, il y a des émissions que j'aimerai bien garder, mais comme l'original est commencé 15 minutes avant et souvent fini deux heures après, la taille prise est ingérable :-(
je comprends pas le problème, il suffit de demuxer, on a la video d'un côté et de l'autre une piste son PCM de même durée.
c'est quand même pas un problème de remuxer tout ça synchro dans un container quelconque ?
mpegstreamclip (gratuit)
http://www.squared5.com/
doit normalement faire de l'édition basique, cut/join sur le l'HD
(pas eu le temps de tester perso)
Le 13/05/2012 08:51, jean-daniel dodin a écrit :
je ne connais aucun moyen fiable en HD de corriger le décalage son qui
se produit en transcodant depuis l'enregistrement de la télé vers quoi
que ce soit d'autre (ni même de moyen de couper la partie qui
m'intéresse), la suite est donc sans utilité :-(
Note que j'aimerai pouvoir le faire, il y a des émissions que j'aimerai
bien garder, mais comme l'original est commencé 15 minutes avant et
souvent fini deux heures après, la taille prise est ingérable :-(
je comprends pas le problème, il suffit de demuxer, on a la
video d'un côté et de l'autre une piste son PCM de même durée.
c'est quand même pas un problème de remuxer tout ça synchro dans
un container quelconque ?
mpegstreamclip (gratuit)
http://www.squared5.com/
doit normalement faire de l'édition basique, cut/join sur le l'HD
je ne connais aucun moyen fiable en HD de corriger le décalage son qui se produit en transcodant depuis l'enregistrement de la télé vers quoi que ce soit d'autre (ni même de moyen de couper la partie qui m'intéresse), la suite est donc sans utilité :-(
Note que j'aimerai pouvoir le faire, il y a des émissions que j'aimerai bien garder, mais comme l'original est commencé 15 minutes avant et souvent fini deux heures après, la taille prise est ingérable :-(
je comprends pas le problème, il suffit de demuxer, on a la video d'un côté et de l'autre une piste son PCM de même durée.
c'est quand même pas un problème de remuxer tout ça synchro dans un container quelconque ?
mpegstreamclip (gratuit)
http://www.squared5.com/
doit normalement faire de l'édition basique, cut/join sur le l'HD
(pas eu le temps de tester perso)
Stephane Legras-Decussy
Le 13/05/2012 20:02, Alf92 a écrit :
"jp willm" a écrit
J'aime le conteneur mkv avec dedans du x264 et du ogg vorbis en attendant de pouvoir faire du webm
pourquoi du ogg vorbis ? l'AAC est plus standard.
ou du brave mp3 stereo, on s'en fout un peu de gagner des cacahouètes sur le son, non ?
Le 13/05/2012 20:02, Alf92 a écrit :
"jp willm" <nicole.jeanpaul.willm@wanadoo.fr> a écrit
J'aime le conteneur mkv avec dedans du x264 et du ogg vorbis en
attendant de pouvoir faire du webm
pourquoi du ogg vorbis ?
l'AAC est plus standard.
ou du brave mp3 stereo, on s'en fout un peu de gagner
des cacahouètes sur le son, non ?
J'aime le conteneur mkv avec dedans du x264 et du ogg vorbis en attendant de pouvoir faire du webm
pourquoi du ogg vorbis ? l'AAC est plus standard.
ou du brave mp3 stereo, on s'en fout un peu de gagner des cacahouètes sur le son, non ?
Stephane Legras-Decussy
Le 13/05/2012 07:47, Thierry M. a écrit :
* 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.
h264 à 1600kbps. ça c'est clair.
après le point à tester c'est est-ce que c'est mieux avec ces valeurs en 720p ou en 1080p d'origine.
c'est pas évident... les quelques tests que j'ai fait me font penser qu'il vaut mieux une bonne définition compressée grossièrement qu'une faible définition compressée finement.
mais à voir... j'aimerais beaucoup un retour sur ce point avec ton 50".
Le 13/05/2012 07:47, Thierry M. a écrit :
* 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.
h264 à 1600kbps. ça c'est clair.
après le point à tester c'est est-ce que c'est mieux avec
ces valeurs en 720p ou en 1080p d'origine.
c'est pas évident... les quelques tests que j'ai fait
me font penser qu'il vaut mieux une bonne définition
compressée grossièrement qu'une faible définition compressée finement.
mais à voir... j'aimerais beaucoup un retour sur ce point
avec ton 50".
* 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.
h264 à 1600kbps. ça c'est clair.
après le point à tester c'est est-ce que c'est mieux avec ces valeurs en 720p ou en 1080p d'origine.
c'est pas évident... les quelques tests que j'ai fait me font penser qu'il vaut mieux une bonne définition compressée grossièrement qu'une faible définition compressée finement.
mais à voir... j'aimerais beaucoup un retour sur ce point avec ton 50".
jdd
Le 13/05/2012 22:27, Stephane Legras-Decussy a écrit :
c'est quand même pas un problème de remuxer tout ça synchro dans un container quelconque ?
ben oui
il manque des images, donc la durée du pcm n'est pas la même que celle de la video
en fait si, elle est la même, mais il manque une partie du son à la fin. J'ai vu ca il y a quelques années, en essayant de numériser des cassettes VHS avec un appareil pas assez puissant, il y avait 1/4 d'heure de décalage sur un film :-)
en TNT, c'est dû aux pertes d'images (freeze) dus aux parasites. C'est génant et c'est quelques images toutes les quelques minutes
Ceci dit les lecteurs des box lisent très bien ca synchro, je ne comprends donc pas pourquoi ,il n'y a pas plus de softs capables de le traduire en fichier lisible.
jdd
-- Pour nous montrer vos photos, créez votre album sur le compte frpm (demandez-nous login et mot de passe, on vous le donnera!) http://www.flickr.com/photos//
Le 13/05/2012 22:27, Stephane Legras-Decussy a écrit :
c'est quand même pas un problème de remuxer tout ça synchro dans
un container quelconque ?
ben oui
il manque des images, donc la durée du pcm n'est pas la même que celle
de la video
en fait si, elle est la même, mais il manque une partie du son à la
fin. J'ai vu ca il y a quelques années, en essayant de numériser des
cassettes VHS avec un appareil pas assez puissant, il y avait 1/4
d'heure de décalage sur un film :-)
en TNT, c'est dû aux pertes d'images (freeze) dus aux parasites. C'est
génant et c'est quelques images toutes les quelques minutes
Ceci dit les lecteurs des box lisent très bien ca synchro, je ne
comprends donc pas pourquoi ,il n'y a pas plus de softs capables de le
traduire en fichier lisible.
jdd
--
Pour nous montrer vos photos, créez votre album sur le compte frpm
(demandez-nous login et mot de passe, on vous le donnera!)
http://www.flickr.com/photos/76105150@N07/
Le 13/05/2012 22:27, Stephane Legras-Decussy a écrit :
c'est quand même pas un problème de remuxer tout ça synchro dans un container quelconque ?
ben oui
il manque des images, donc la durée du pcm n'est pas la même que celle de la video
en fait si, elle est la même, mais il manque une partie du son à la fin. J'ai vu ca il y a quelques années, en essayant de numériser des cassettes VHS avec un appareil pas assez puissant, il y avait 1/4 d'heure de décalage sur un film :-)
en TNT, c'est dû aux pertes d'images (freeze) dus aux parasites. C'est génant et c'est quelques images toutes les quelques minutes
Ceci dit les lecteurs des box lisent très bien ca synchro, je ne comprends donc pas pourquoi ,il n'y a pas plus de softs capables de le traduire en fichier lisible.
jdd
-- Pour nous montrer vos photos, créez votre album sur le compte frpm (demandez-nous login et mot de passe, on vous le donnera!) http://www.flickr.com/photos//
Alf92
"Stephane Legras-Decussy" a écrit
je ne connais aucun moyen fiable en HD de corriger le décalage son qui se produit en transcodant depuis l'enregistrement de la télé vers quoi que ce soit d'autre (ni même de moyen de couper la partie qui m'intéresse), la suite est donc sans utilité :-(
je comprends pas le problème, il suffit de demuxer, on a la video d'un côté et de l'autre une piste son PCM de même durée.
c'est quand même pas un problème de remuxer tout ça synchro dans un container quelconque ?
non c'est pas si simple. je me suis arraché les cheveux pendant longtemps sur le transcodage d'enregistrement TNT ou Flux ADSL (type Freebox). en fait les transmissions sont bourrées d'erreurs (trames manquantes) corrigées à la volé par un algo quelconque. afin qu'il n'y ai pas en permanence des désynchros image-son dues à ces erreurs, il y a des balises temporels. c'est balises sont spécifiques au flux TS (TS : transport stream), elles n'existent pas dans un fichier video (PS : program stream). voilà pourquoi c'est une tannée de passer d'un flux TS (issu de TNT ou ADSL) à un flux PS. peu de softs savent supprimer ces balises temporelles en tenant compte des trames manquantes, et donc ne pas créer des désynchros. ça marche relativement bien en MPEG2 (TNT et flux ADSL SD type freebox standard). c'est assez hasardeux en H264 (TNT HD, flux ADSL HD type freebox HD et flux ADSL SD bas débit type freebox bas débit).
"Stephane Legras-Decussy" <admin@facebook.com> a écrit
je ne connais aucun moyen fiable en HD de corriger le décalage son qui
se produit en transcodant depuis l'enregistrement de la télé vers quoi
que ce soit d'autre (ni même de moyen de couper la partie qui
m'intéresse), la suite est donc sans utilité :-(
je comprends pas le problème, il suffit de demuxer, on a la
video d'un côté et de l'autre une piste son PCM de même durée.
c'est quand même pas un problème de remuxer tout ça synchro dans
un container quelconque ?
non c'est pas si simple.
je me suis arraché les cheveux pendant longtemps sur le transcodage
d'enregistrement TNT ou Flux ADSL (type Freebox).
en fait les transmissions sont bourrées d'erreurs (trames manquantes) corrigées
à la volé par un algo quelconque.
afin qu'il n'y ai pas en permanence des désynchros image-son dues à ces erreurs,
il y a des balises temporels.
c'est balises sont spécifiques au flux TS (TS : transport stream), elles
n'existent pas dans un fichier video (PS : program stream).
voilà pourquoi c'est une tannée de passer d'un flux TS (issu de TNT ou ADSL) à
un flux PS.
peu de softs savent supprimer ces balises temporelles en tenant compte des
trames manquantes, et donc ne pas créer des désynchros.
ça marche relativement bien en MPEG2 (TNT et flux ADSL SD type freebox
standard).
c'est assez hasardeux en H264 (TNT HD, flux ADSL HD type freebox HD et flux ADSL
SD bas débit type freebox bas débit).
je ne connais aucun moyen fiable en HD de corriger le décalage son qui se produit en transcodant depuis l'enregistrement de la télé vers quoi que ce soit d'autre (ni même de moyen de couper la partie qui m'intéresse), la suite est donc sans utilité :-(
je comprends pas le problème, il suffit de demuxer, on a la video d'un côté et de l'autre une piste son PCM de même durée.
c'est quand même pas un problème de remuxer tout ça synchro dans un container quelconque ?
non c'est pas si simple. je me suis arraché les cheveux pendant longtemps sur le transcodage d'enregistrement TNT ou Flux ADSL (type Freebox). en fait les transmissions sont bourrées d'erreurs (trames manquantes) corrigées à la volé par un algo quelconque. afin qu'il n'y ai pas en permanence des désynchros image-son dues à ces erreurs, il y a des balises temporels. c'est balises sont spécifiques au flux TS (TS : transport stream), elles n'existent pas dans un fichier video (PS : program stream). voilà pourquoi c'est une tannée de passer d'un flux TS (issu de TNT ou ADSL) à un flux PS. peu de softs savent supprimer ces balises temporelles en tenant compte des trames manquantes, et donc ne pas créer des désynchros. ça marche relativement bien en MPEG2 (TNT et flux ADSL SD type freebox standard). c'est assez hasardeux en H264 (TNT HD, flux ADSL HD type freebox HD et flux ADSL SD bas débit type freebox bas débit).
pehache
Le 13/05/12 20:09, Alf92 a écrit :
"pehache" a écrit
la double passe n'apporte pas grand chose.
Pas d'accord du tout. Avec un bitrate cible, le double passe est indispensable pour réellement allouer le plus de bits possibles aux passages complexes et réciproquement.
biensur, mais le gain de qualité est assez négligeable en H264. c'est plus visible en MPEG2 ou en Xvid par exemple.
Parce que la qualité moyenne des films encodés en h264 est meilleure à la base. Mais le problème est exactement le même si on se met à pousser la compression (en HD pour ne pas prendre une place énorme)
Si on veut économiser une passe il faut utiliser non pas un bitrate cible mais le mode à qualité constante (en lequel -peut-être à tort- je n'ai pas hyper confiance)
le bitrate peut être : constant,
Utile uniquement pour du streaming sur un réseau "lent"
variable ou moyen.
J'ai du mal à saisir la nuance: je suppose que ce que tu appelles "variable", c'est le mode "qualité constante" ?
le bitrate moyen avec tolérance de +/- 50% donne de bon résultat, et la taille finale est le plus souvent très proche de celle calculé sur la valeur moyenne.
Uniquement parce l'algo ne s'éloigne pas de la valeur moyenne autant qu'il le pourrait avec une seconde passe, parce qu'il fait varier le bitrate non seulement pour s'adapter à la complexité de la video sur un passage donné, mais aussi en fonction du bitrate moyen utilisé depuis le début... Sinon, en une passe, un dessin animé en ligne claire finirait très en dessous du bitrate moyen demandé, et un film d'action finirait très au-dessus : or comme tu le dis toi-même ce n'est pas le cas, on ne finit jamais très loin.
Le 13/05/12 20:09, Alf92 a écrit :
"pehache" <pehache.7@gmail.com> a écrit
la double passe n'apporte pas grand chose.
Pas d'accord du tout.
Avec un bitrate cible, le double passe est indispensable pour
réellement allouer le plus de bits possibles aux passages complexes et
réciproquement.
biensur, mais le gain de qualité est assez négligeable en H264.
c'est plus visible en MPEG2 ou en Xvid par exemple.
Parce que la qualité moyenne des films encodés en h264 est meilleure à
la base. Mais le problème est exactement le même si on se met à pousser
la compression (en HD pour ne pas prendre une place énorme)
Si on veut économiser une passe il faut utiliser non pas un bitrate
cible mais le mode à qualité constante (en lequel -peut-être à tort-
je n'ai pas hyper confiance)
le bitrate peut être :
constant,
Utile uniquement pour du streaming sur un réseau "lent"
variable ou moyen.
J'ai du mal à saisir la nuance: je suppose que ce que tu appelles
"variable", c'est le mode "qualité constante" ?
le bitrate moyen avec tolérance de +/- 50% donne de bon résultat, et la
taille finale est le plus souvent très proche de celle calculé sur la
valeur moyenne.
Uniquement parce l'algo ne s'éloigne pas de la valeur moyenne autant
qu'il le pourrait avec une seconde passe, parce qu'il fait varier le
bitrate non seulement pour s'adapter à la complexité de la video sur un
passage donné, mais aussi en fonction du bitrate moyen utilisé depuis le
début... Sinon, en une passe, un dessin animé en ligne claire finirait
très en dessous du bitrate moyen demandé, et un film d'action finirait
très au-dessus : or comme tu le dis toi-même ce n'est pas le cas, on ne
finit jamais très loin.
Pas d'accord du tout. Avec un bitrate cible, le double passe est indispensable pour réellement allouer le plus de bits possibles aux passages complexes et réciproquement.
biensur, mais le gain de qualité est assez négligeable en H264. c'est plus visible en MPEG2 ou en Xvid par exemple.
Parce que la qualité moyenne des films encodés en h264 est meilleure à la base. Mais le problème est exactement le même si on se met à pousser la compression (en HD pour ne pas prendre une place énorme)
Si on veut économiser une passe il faut utiliser non pas un bitrate cible mais le mode à qualité constante (en lequel -peut-être à tort- je n'ai pas hyper confiance)
le bitrate peut être : constant,
Utile uniquement pour du streaming sur un réseau "lent"
variable ou moyen.
J'ai du mal à saisir la nuance: je suppose que ce que tu appelles "variable", c'est le mode "qualité constante" ?
le bitrate moyen avec tolérance de +/- 50% donne de bon résultat, et la taille finale est le plus souvent très proche de celle calculé sur la valeur moyenne.
Uniquement parce l'algo ne s'éloigne pas de la valeur moyenne autant qu'il le pourrait avec une seconde passe, parce qu'il fait varier le bitrate non seulement pour s'adapter à la complexité de la video sur un passage donné, mais aussi en fonction du bitrate moyen utilisé depuis le début... Sinon, en une passe, un dessin animé en ligne claire finirait très en dessous du bitrate moyen demandé, et un film d'action finirait très au-dessus : or comme tu le dis toi-même ce n'est pas le cas, on ne finit jamais très loin.
Alf92
"Stephane Legras-Decussy" a écrit
J'aime le conteneur mkv avec dedans du x264 et du ogg vorbis en attendant de pouvoir faire du webm
pourquoi du ogg vorbis ? l'AAC est plus standard.
ou du brave mp3 stereo, on s'en fout un peu de gagner des cacahouètes sur le son, non ?
MP2-192kbps <=> MP3-128kbps <=> AAC-96kbps
même si les players d'aujourd'hui se démerdent avec à peu près n'importe quoi, c'est élégant de faire un truc cohérent, voir standard. si un jour tu veux faire un blu-ray, tu seras obligé de réencoder ton MP3 en AAC. bons couples : MPEG2/MP2 MPEG4/MP3 H264/AAC
"Stephane Legras-Decussy" <admin@facebook.com> a écrit
J'aime le conteneur mkv avec dedans du x264 et du ogg vorbis en
attendant de pouvoir faire du webm
pourquoi du ogg vorbis ?
l'AAC est plus standard.
ou du brave mp3 stereo, on s'en fout un peu de gagner
des cacahouètes sur le son, non ?
MP2-192kbps <=> MP3-128kbps <=> AAC-96kbps
même si les players d'aujourd'hui se démerdent avec à peu près n'importe quoi,
c'est élégant de faire un truc cohérent, voir standard.
si un jour tu veux faire un blu-ray, tu seras obligé de réencoder ton MP3 en
AAC.
bons couples :
MPEG2/MP2
MPEG4/MP3
H264/AAC
J'aime le conteneur mkv avec dedans du x264 et du ogg vorbis en attendant de pouvoir faire du webm
pourquoi du ogg vorbis ? l'AAC est plus standard.
ou du brave mp3 stereo, on s'en fout un peu de gagner des cacahouètes sur le son, non ?
MP2-192kbps <=> MP3-128kbps <=> AAC-96kbps
même si les players d'aujourd'hui se démerdent avec à peu près n'importe quoi, c'est élégant de faire un truc cohérent, voir standard. si un jour tu veux faire un blu-ray, tu seras obligé de réencoder ton MP3 en AAC. bons couples : MPEG2/MP2 MPEG4/MP3 H264/AAC
Alf92
"Stephane Legras-Decussy" a écrit
h264 à 1600kbps. ça c'est clair.
après le point à tester c'est est-ce que c'est mieux avec ces valeurs en 720p ou en 1080p d'origine.
c'est pas évident... les quelques tests que j'ai fait me font penser qu'il vaut mieux une bonne définition compressée grossièrement qu'une faible définition compressée finement.
l'inverse de ce que l'on disait sur le MPEG2 et le Xvid.
"Stephane Legras-Decussy" <admin@facebook.com> a écrit
h264 à 1600kbps. ça c'est clair.
après le point à tester c'est est-ce que c'est mieux avec
ces valeurs en 720p ou en 1080p d'origine.
c'est pas évident... les quelques tests que j'ai fait
me font penser qu'il vaut mieux une bonne définition
compressée grossièrement qu'une faible définition compressée finement.
l'inverse de ce que l'on disait sur le MPEG2 et le Xvid.
après le point à tester c'est est-ce que c'est mieux avec ces valeurs en 720p ou en 1080p d'origine.
c'est pas évident... les quelques tests que j'ai fait me font penser qu'il vaut mieux une bonne définition compressée grossièrement qu'une faible définition compressée finement.
l'inverse de ce que l'on disait sur le MPEG2 et le Xvid.
pehache
Le 13/05/12 23:12, Alf92 a écrit :
"Stephane Legras-Decussy" a écrit
je ne connais aucun moyen fiable en HD de corriger le décalage son qui se produit en transcodant depuis l'enregistrement de la télé vers quoi que ce soit d'autre (ni même de moyen de couper la partie qui m'intéresse), la suite est donc sans utilité :-(
je comprends pas le problème, il suffit de demuxer, on a la video d'un côté et de l'autre une piste son PCM de même durée.
c'est quand même pas un problème de remuxer tout ça synchro dans un container quelconque ?
non c'est pas si simple. je me suis arraché les cheveux pendant longtemps sur le transcodage d'enregistrement TNT ou Flux ADSL (type Freebox). en fait les transmissions sont bourrées d'erreurs (trames manquantes) corrigées à la volé par un algo quelconque. afin qu'il n'y ai pas en permanence des désynchros image-son dues à ces erreurs, il y a des balises temporels. c'est balises sont spécifiques au flux TS (TS : transport stream), elles n'existent pas dans un fichier video (PS : program stream). voilà pourquoi c'est une tannée de passer d'un flux TS (issu de TNT ou ADSL) à un flux PS. peu de softs savent supprimer ces balises temporelles en tenant compte des trames manquantes, et donc ne pas créer des désynchros. ça marche relativement bien en MPEG2 (TNT et flux ADSL SD type freebox standard). c'est assez hasardeux en H264 (TNT HD, flux ADSL HD type freebox HD et flux ADSL SD bas débit type freebox bas débit).
HandBrake semble le faire assez bien. Disons que la seule fois où j'ai voulu le faire sur de la HD, c'est le seul soft qui a réussi (ffmpeg sait faire aussi en principe, mais il plantait carrément sur la lecture de ces fichiers)
Le 13/05/12 23:12, Alf92 a écrit :
"Stephane Legras-Decussy" <admin@facebook.com> a écrit
je ne connais aucun moyen fiable en HD de corriger le décalage son qui
se produit en transcodant depuis l'enregistrement de la télé vers quoi
que ce soit d'autre (ni même de moyen de couper la partie qui
m'intéresse), la suite est donc sans utilité :-(
je comprends pas le problème, il suffit de demuxer, on a la
video d'un côté et de l'autre une piste son PCM de même durée.
c'est quand même pas un problème de remuxer tout ça synchro dans
un container quelconque ?
non c'est pas si simple.
je me suis arraché les cheveux pendant longtemps sur le transcodage
d'enregistrement TNT ou Flux ADSL (type Freebox).
en fait les transmissions sont bourrées d'erreurs (trames manquantes)
corrigées à la volé par un algo quelconque.
afin qu'il n'y ai pas en permanence des désynchros image-son dues à ces
erreurs, il y a des balises temporels.
c'est balises sont spécifiques au flux TS (TS : transport stream), elles
n'existent pas dans un fichier video (PS : program stream).
voilà pourquoi c'est une tannée de passer d'un flux TS (issu de TNT ou
ADSL) à un flux PS.
peu de softs savent supprimer ces balises temporelles en tenant compte
des trames manquantes, et donc ne pas créer des désynchros.
ça marche relativement bien en MPEG2 (TNT et flux ADSL SD type freebox
standard).
c'est assez hasardeux en H264 (TNT HD, flux ADSL HD type freebox HD et
flux ADSL SD bas débit type freebox bas débit).
HandBrake semble le faire assez bien. Disons que la seule fois où j'ai
voulu le faire sur de la HD, c'est le seul soft qui a réussi (ffmpeg
sait faire aussi en principe, mais il plantait carrément sur la lecture
de ces fichiers)
je ne connais aucun moyen fiable en HD de corriger le décalage son qui se produit en transcodant depuis l'enregistrement de la télé vers quoi que ce soit d'autre (ni même de moyen de couper la partie qui m'intéresse), la suite est donc sans utilité :-(
je comprends pas le problème, il suffit de demuxer, on a la video d'un côté et de l'autre une piste son PCM de même durée.
c'est quand même pas un problème de remuxer tout ça synchro dans un container quelconque ?
non c'est pas si simple. je me suis arraché les cheveux pendant longtemps sur le transcodage d'enregistrement TNT ou Flux ADSL (type Freebox). en fait les transmissions sont bourrées d'erreurs (trames manquantes) corrigées à la volé par un algo quelconque. afin qu'il n'y ai pas en permanence des désynchros image-son dues à ces erreurs, il y a des balises temporels. c'est balises sont spécifiques au flux TS (TS : transport stream), elles n'existent pas dans un fichier video (PS : program stream). voilà pourquoi c'est une tannée de passer d'un flux TS (issu de TNT ou ADSL) à un flux PS. peu de softs savent supprimer ces balises temporelles en tenant compte des trames manquantes, et donc ne pas créer des désynchros. ça marche relativement bien en MPEG2 (TNT et flux ADSL SD type freebox standard). c'est assez hasardeux en H264 (TNT HD, flux ADSL HD type freebox HD et flux ADSL SD bas débit type freebox bas débit).
HandBrake semble le faire assez bien. Disons que la seule fois où j'ai voulu le faire sur de la HD, c'est le seul soft qui a réussi (ffmpeg sait faire aussi en principe, mais il plantait carrément sur la lecture de ces fichiers)
Alf92
"pehache" a écrit
la double passe n'apporte pas grand chose.
Pas d'accord du tout. Avec un bitrate cible, le double passe est indispensable pour réellement allouer le plus de bits possibles aux passages complexes et réciproquement.
biensur, mais le gain de qualité est assez négligeable en H264. c'est plus visible en MPEG2 ou en Xvid par exemple.
Parce que la qualité moyenne des films encodés en h264 est meilleure à la base. Mais le problème est exactement le même si on se met à pousser la compression (en HD pour ne pas prendre une place énorme)
Si on veut économiser une passe il faut utiliser non pas un bitrate cible mais le mode à qualité constante (en lequel -peut-être à tort- je n'ai pas hyper confiance)
le bitrate peut être : constant,
Utile uniquement pour du streaming sur un réseau "lent"
variable ou moyen.
J'ai du mal à saisir la nuance: je suppose que ce que tu appelles "variable", c'est le mode "qualité constante" ?
le bitrate moyen avec tolérance de +/- 50% donne de bon résultat, et la taille finale est le plus souvent très proche de celle calculé sur la valeur moyenne.
Uniquement parce l'algo ne s'éloigne pas de la valeur moyenne autant qu'il le pourrait avec une seconde passe, parce qu'il fait varier le bitrate non seulement pour s'adapter à la complexité de la video sur un passage donné, mais aussi en fonction du bitrate moyen utilisé depuis le début... Sinon, en une passe, un dessin animé en ligne claire finirait très en dessous du bitrate moyen demandé, et un film d'action finirait très au-dessus : or comme tu le dis toi-même ce n'est pas le cas, on ne finit jamais très loin.
oui pour tout.
"pehache" <pehache.7@gmail.com> a écrit
la double passe n'apporte pas grand chose.
Pas d'accord du tout.
Avec un bitrate cible, le double passe est indispensable pour
réellement allouer le plus de bits possibles aux passages complexes et
réciproquement.
biensur, mais le gain de qualité est assez négligeable en H264.
c'est plus visible en MPEG2 ou en Xvid par exemple.
Parce que la qualité moyenne des films encodés en h264 est meilleure à la
base. Mais le problème est exactement le même si on se met à pousser la
compression (en HD pour ne pas prendre une place énorme)
Si on veut économiser une passe il faut utiliser non pas un bitrate
cible mais le mode à qualité constante (en lequel -peut-être à tort-
je n'ai pas hyper confiance)
le bitrate peut être :
constant,
Utile uniquement pour du streaming sur un réseau "lent"
variable ou moyen.
J'ai du mal à saisir la nuance: je suppose que ce que tu appelles "variable",
c'est le mode "qualité constante" ?
le bitrate moyen avec tolérance de +/- 50% donne de bon résultat, et la
taille finale est le plus souvent très proche de celle calculé sur la
valeur moyenne.
Uniquement parce l'algo ne s'éloigne pas de la valeur moyenne autant qu'il le
pourrait avec une seconde passe, parce qu'il fait varier le bitrate non
seulement pour s'adapter à la complexité de la video sur un passage donné,
mais aussi en fonction du bitrate moyen utilisé depuis le début... Sinon, en
une passe, un dessin animé en ligne claire finirait très en dessous du bitrate
moyen demandé, et un film d'action finirait très au-dessus : or comme tu le
dis toi-même ce n'est pas le cas, on ne finit jamais très loin.
Pas d'accord du tout. Avec un bitrate cible, le double passe est indispensable pour réellement allouer le plus de bits possibles aux passages complexes et réciproquement.
biensur, mais le gain de qualité est assez négligeable en H264. c'est plus visible en MPEG2 ou en Xvid par exemple.
Parce que la qualité moyenne des films encodés en h264 est meilleure à la base. Mais le problème est exactement le même si on se met à pousser la compression (en HD pour ne pas prendre une place énorme)
Si on veut économiser une passe il faut utiliser non pas un bitrate cible mais le mode à qualité constante (en lequel -peut-être à tort- je n'ai pas hyper confiance)
le bitrate peut être : constant,
Utile uniquement pour du streaming sur un réseau "lent"
variable ou moyen.
J'ai du mal à saisir la nuance: je suppose que ce que tu appelles "variable", c'est le mode "qualité constante" ?
le bitrate moyen avec tolérance de +/- 50% donne de bon résultat, et la taille finale est le plus souvent très proche de celle calculé sur la valeur moyenne.
Uniquement parce l'algo ne s'éloigne pas de la valeur moyenne autant qu'il le pourrait avec une seconde passe, parce qu'il fait varier le bitrate non seulement pour s'adapter à la complexité de la video sur un passage donné, mais aussi en fonction du bitrate moyen utilisé depuis le début... Sinon, en une passe, un dessin animé en ligne claire finirait très en dessous du bitrate moyen demandé, et un film d'action finirait très au-dessus : or comme tu le dis toi-même ce n'est pas le cas, on ne finit jamais très loin.
