ModĂ©rateurs: Staff Home-CinĂ©ma, Staff Juridique • Utilisateurs parcourant ce forum: Aucun utilisateur enregistrĂ© et 4 invitĂ©s

Bien comprendre l'Ultra HD, la 4K, et les normes THX, Dolby, DTS, Auro 3D

Le 819 lignes sans efforts (simu PC)

Message » 25 Avr 2009 15:11

(long post, mais les aspects pratiques sont au début)

Dupliqué sur PCHC, aux modos de decider si c'est un blasphème/sacrilège/foutage de gueule...

Si, comme moi, vous ĂŞtes curieux de voir (ou revoir) du 819 lignes, mais :
- Vous êtes dépités par le fait que les convertisseurs Aurora ne font du 819 qu'à partir de 625 gonflé
- Vous doutez de vos chances de récupérer un poste 819 réparable
- Vous doutez encore plus de vos capacités à le remettre en état
- Vous n'êtes pas pressé de fourrer vos doigts dans le 15 kv ou d'admirer de près l'implosion
d'un tube cathodique

alors, j'ai une solution alternative Ă  vous proposer.

Ce que vous obtiendrez :
Une vidéo à la résolution théorique du 819, extraite à partir d'une source en 1080p/25 ou éventuellement
1080p/50, presque en plein écran (bordure noire de 20 pixels au pire), en noir et blanc, et accompagnée
d'un son monophonique, avec Ă©mulation de l'entrelacement sur le moniteur PC travaillant en progressif.

Ceci représente la qualité maximale possible avec le standard, sans tenir compte des dégradations
Apportées par les imperfections des téléviseurs ou des caméras, la modulation/démodulation et
Les conditions de propagation. Mais on pourrait les modéliser et les rajouter dans la simulation.

Pour cela il vous faudra :
Impérativement un moniteur 4/3 capable de travailler avec une résolution strictement égale à 1024x768 :
Soit un CRT utilisé en XGA, soit un LCD avec une matrice native à ce format (non testé et moins proche de
La vérité historique qu'un CRT, de toutes manières).

Idéalement, il faut aussi que ce moniteur puisse être mis en 50 Hz, mais j'ai été surpris de constater
qu'utiliser une autre fréquence de rafraichissement ne créait pas d'artefacts inacceptables)

Un PC avec un CPU et un disque dur capables de lire en temps réél du « 819p/50 » encodé avec une compression
sans pertes (HuffYuv) , son monophonique AAC, container mp4

Un logiciel compatible avec ces formats et débits. J'ai pour ma part obtenu des résultats satisfaisants avec :
VLC (vidéolan)
Media Player Classic- Home Cinema + Reclock
Mplayer/MPUI
et mĂŞme Window media Player

La méthode du moindre effort :
- Vous téléchargez ma vidéo toute faite (attention c'est 500 Mo pour seulement une vingtaine de secondes) :
http://dl.free.fr/jkwwx9Kyt
- Vous passez votre moniteur en 1024x768@50Hz
- Vous ouvrez la vidéo dans un player compatible et vous passez en plein écran (obligatoire)

Attention, il faut désactiver le désentrelacement (donne une vidéo clignotante avec MPC-HC).

Pour ce qui me concerne, j'ai eu des soucis avec mon abruti de driver ATI qui me permet de passer en 50 Hz
ou en 1024x768, mais pas les deux en mĂŞme temps. J'ai du passer par une version d'essai de Powerstrip
pour obtenir ce que je voulais.

Il est préférable de mettre du cache à cause des débits importants.
Dans VLC, ouvrir le fichier en mode avancé, afficher plus d'options et mettre 1000 ms.
Dans MPUI, rajouter -cache 50000 dans les paramètres , dans « préférences ».

On peut aussi mettre la vidéo en boucle, pour avoir le temps d'apprécier, vu la courte durée.

Reste eventuellement Ă  se placer Ă  une distance du moniteur qui produit une taille apparente de l'image
Ă©quivalente Ă  ce que les spectateurs de l'Ă©poque ont pu connaitre. Les distances sont dans les mĂŞmes
proportions que les diagonales, et la diagonale de l'image simulée est celle du moniteur multipliée
par 0.96 pour tenir compte des bandes noires. Par exemple, si avec un moniteur 17" (43.18cm) on veut
avoir la mĂŞme impression qu'avec un ecran de 55 cm vu Ă  3 m, il faut se placer Ă  une distance
d = 3 x (0.96 x 43.18) / 55 = 2.26 m

Cette vidéo est dite "film mode" car elle est tirée d'un document d'origine 24p. Je prevois d'en
mettre une autre créée à partir du même document extrapolé en 50p par compensation de mouvement,
histoire d'accentuer les effets de l'entrelacement. Si par contre vous avez un lien sur du vrai
1080p/50, je suis preneur.

Autre methode, Si vous voulez des vidéos différentes ou plus longues :
Utiliser les scripts Avisynth que je propose plus loin, pour réaliser vos propres vidéos 819 lignes.
Cela suppose que vous installiez les outils correspondant sur votre PC

Le principe :
Entrelacé encapsulé dans du progressif (je sais, d'habitude on fait l'inverse):
Apres avoir coupé et redimensionné le full HD pour obtenir une image 4/3 à la résolution du 819,
je la divise en lignes paires et impaire et dans chacune des trames, je remplace les lignes
manquantes par des lignes noires.
En partant de 25p, j'obtiens donc un flux Ă  50p, avec des images progressives qui ont alternativement les
lignes paires et Impaires noircies ; en les faisant défiler à 50 Hz, on émule l'impression visuelle produite par
l'alternance des trames paires et impaires sur une CRT entrelacé.

La structure obtenue ne peut en aucun cas ĂŞtre mise Ă  l'Ă©chelle (en tous cas verticalement) et doit ĂŞtre
affichée exactement à la résolution a laquelle elle a été créée (c'est toujours le cas pour l'entrelacé).
C'est pourquoi si votre player démarre en mode fenêtré, vous observerez une forte dégradation de l'image,
qui disparait lorsque l'on passe en plein Ă©cran.

Pourquoi une compression sans pertes ?
L'alternance de lignes est définie au niveau du pixel, et ne tolèrerait pas la perte de
finesse qu'introduit une compression classique avec pertes. De plus les algorithmes de compensation
de mouvement utilisés risquent d'être déboussolés par l'alternance continuelle de noir et de non noir.
Enfin, ce ne sont pas de vraies images entrelacées mais une suite d'image progressives.
Les modes entrelacé des codecs sont donc inutilisables.
Je n'ai même pas essayé et je suis parti sur une compression sans pertes.

Cette compression était nécessaire parce que mon PC ne parvenait pas à traiter le script avisynth en temps réel, il fallait donc stocker le résultat dans un fichier pour le rejouer ensuite ; mais le flux non compressé était trop important et posait d'autres soucis. La compression sans pertes et le réglages des caches m'a permis d'obtenir une vidéo fluide (sur dual core 2.4 Ghz).

Autre chose : la résolution théorique visible à l'écran du 819 est de 816x737 (voir entre autres wikipedia).
J'utilise en fait 816x736, car mes outils me réclament un multiple de 4.
Le téléviseur étire cette image en 4/3, créant ainsi des pixels rectangulaires. La résolution 1027x768 des
PC suppose des pixels carrés. Pour émuler cet étirement, je redimensionne donc en 984x736, en repartant bien
du 816x736, et pas de l'image full HD d'origine. De la sorte, l'image finale ne contient pas plus
d'information que le 819 authentique.

Au final, mon script fait les opérations suivantes, en partant pour cet exemple d'une vidéo d'origine
1080p/24, en 16/9 :
- Forçage de la cadence à 25p
- Coupure des cotés pour obtenir une image 4/3 centrée (1440x1080)
- Passage en noir et blanc
- Redimensionnement en 816x736
- SĂ©paration en trame paire/impaire (trames Ă  50 p)
- Ajout de lignes noires pour obtenir des images complètes en 50p
- Redimensionnement horizontal pour avoir du 984x736
- Ajout de bordures noires (20 pixels Ă  gauche et Ă  droite, 16 pixels en haut et en bas)
pour obtenir une image 1024x768 et interdire ainsi toute tentative de mise Ă  l'Ă©chelle de la part du lecteur

Utilisation possible des scripts:
Vous pouvez faire un seul script qui cumule toutes les opérations précédentes et vous sortez une vidéo que vous comprimez en Huffyuv (par exemple sous virtualdub + ffdshow). L'avantage est que l'utilisateur n'a pas besoin d'avisynth pour lire le résultat. Mais ça limite la durée de la vidéo et c'est évidemment très consommateur d'espace disque.

L'autre méthode consiste à rassembler dans un premier script toutes les opérations de redimensionnement pour obtenir une vidéo en 984x736 que l'on comprime avec les codecs habituels et qui peut donc être longue. Puis on l'ouvre avec un deuxième script qui regroupe les operations de simulation d'entrelacement. Ces opérations sont suffisament rapides pour etre effectuées en temps réel. Il suffit alors d'ouvrir ce deuxieme script directement dans le player. On peut distribuer la video comprimée accompagnée du second script.
L'inconvénient est que l'utilisateur doit installer avisynth.

Avant d'inclure le script, quelques considerations sur la comparaison 819 / 720p :
Les 837 lignes verticales du 819 font mieux que les 720 du 720p, Ă  premiere vue.

Mais une image étant un objet à deux dimensions, sa résolution est plutôt donnée
par le nombre total de pixels.
819 : 816x737 = 601 392
720p : 1280x720 = 921 600

Cependant le 720p est en 16/9, alors que le 819 visait du 4/3. Si on essaye de comparer
la densité de pixels sur l'ecran, par exemple en découpant une portion de 4/3 dans du 720p,
on voit que ce dernier serait capable d'y loger 960x720 = 691 200 pixels, donc encore
15% de mieux que le 819. A titre de comparaison, le 576i europeen a 20% de resolution
de plus que le 480i americain. On voit donc qu'on est quand mĂŞme dans les mĂŞmes ordre
de grandeur.

Peut-on envisager une situation dans laquelle les deux standards seraient visuellement
comparables, avec d'un coté du 16/9 couleur progressif et de l'autre du 4/3 noir et blanc
entrelacé ? Oui, ce serait le cas lors de la diffusion d'un vieux film de cinema noir et
blanc au format 4/3 (ce format a existé en standard au cinéma avant que la télévision
ne se l'approprie). Dans cette situation, la nature progressive du film minimise
la difference entre les deux types de balayage, la source noir et blanc Ă©limine la
couleur du 720p, et le format 4/3 d'origine, s'il est respecté dans la diffusion 720p,
elimine l'avantage du 16/9. On verrait alors des images assez proches sur des
ecrans placés côte à côte.

Reste à rappeller quand même que le 819 a demarré ses diffusions officielles en 1949 (!)
et le 720p seulement en 1998. Ca ne fait jamais qu'un demi-siècle d'ecart.

Et un dernier petit atout qu'avait le 819 : il n'etait absolument pas compressé.

J'en ai fini, voici le script que j'ai utilisé (pas forcement optimisé, j'en conviens);
Les commentaires sont en anglais car je le diffuserai peut etre sur des forums anglophones :

#Source video 1920x1080p/24 (16/9)
DirectShowSource("C:\chemin\VideoFullHD.mp4")

AssumeFPS(25000,1000)

#Crop sides to get a 4/3 picture (1440 x 1080)
crop( 240, 0, -240, 0)

#Turn to black & white
greyscale()

#Scale to target 819 resolution (non-square pixels)
#normally 737 but some tools want a 4-multiple
LanczosResize(816,736)

#Resize to square pixels for PC display
# (c'est bien height qu'il faut utiliser)
A=LAST
A=A.bilinearresize(984,A.height)
A

# Megui/x.264 claims it needs this
ConvertToYV12()

#======================================================
#Split here in two scripts if you want to
#do real time interlace emulation from a
#normally compressed video.
#======================================================

#If this part is used in real time standalone mode, open the compressed video here
#DirectShowSource("C:\chemin\CompressedScaledVideo.mp4")

AssumeTFF

Original=SeparateFields

EvenFields=SelectEven(Original)
EvenFields=AssumeFrameBased(EvenFields)

OddFields=SelectOdd(Original)
OddFields=AssumeFrameBased(OddFields)

BlackFields=Blankclip(EvenFields,color=$000000)

Even=Interleave(EvenFields,BlackFields)
Even=AssumeFieldBased(Even)
Even=AssumeTFF(Even)
Evenprog=Weave(Even)

Odd=Interleave(OddFields,BlackFields)
Odd=AssumeFieldBased(Odd)
Odd=AssumeBFF(Odd)
OddProg=Weave(Odd)

Interleave(EvenProg,OddProg)

#Add black borders to prevent scaling
AddBorders(20,16,20,16)
gammaburst
 
Messages: 567
Inscription: 08 Avr 2003 13:20
  • offline

Annonce

Message par Google » 25 Avr 2009 15:11

Publicite

 
Encart supprimé pour les membres HCFR

Message » 26 Avr 2009 11:59

Comme promis, voici la deuxieme vidéo tirée d'une source 50p, synthetisée par compensation de mouvement avec mvflowfps.

Le principe reste le même, mais je prélève la trame paire dans les images paires et la trame impaire dans les images impaires, (ou l'inverse, vu que Avisynth numerote à partir de 0, la première trame est donc paire).

http://dl.free.fr/jfJsWPcIg

Il y a pas mal de mouvement transversal. Je voulais ainsi mettre en evidence des artefacts d'entrelacement, mais il semble que le peu d'artefacts visible est plutot du Ă  la compensation de mouvement.
gammaburst
 
Messages: 567
Inscription: 08 Avr 2003 13:20
  • offline

Message » 26 Avr 2009 12:01

Copie du message precedent postée par erreur. Si un admin passe par ici, il est encouragé à détruire ce texte ci.
Dernière édition par gammaburst le 25 Fév 2017 14:13, édité 1 fois.
gammaburst
 
Messages: 567
Inscription: 08 Avr 2003 13:20
  • offline

Message » 25 FĂ©v 2017 14:10

Rafraichissement du lien pour la version "50p":

https://share.orange.fr/#PpO9Fb3w183a421a30fd
(531 Mo)
gammaburst
 
Messages: 567
Inscription: 08 Avr 2003 13:20
  • offline


Retourner vers Normes