[MPEG2] Le macro-blocking... Explications, Images, Exemples

» 07 Jan 2005 13:40

Il y a eu un disque Denon pour corriger le pb specifique

» 10 Jan 2005 22:16

Blade a écrit:Un décodeur qui les supprime s’exposent à un risque : Le fait de rendre flou un bloc peut amener à une qualité moindre que celle prévue par l’encodeur, ce
dernier se référant toujours à ce que l’utilisateur doit voir.

Faux: l'encodeur ne se réfère pas à ce que l'utilisateur doit voir, mais au résultat du décodage (l'encodeur contient un décodeur). Le post-processing intervient après le décodage, et ne doit effectivement pas corrompre les images de référence du décodeur. Ceci est vrai pour MPEG2, MPEG4, mais pas pour H263 ou H264 où le filtre de deblocking est normalisé et fait partie de la boucle de décodage.

Tous les filtres et autres techniques ajoutées dans un lecteur pour réduire le "macro-blocking" peuvent être bénéfiques mais doivent être débrayables pour permettre de retrouver la qualité initiale.

Un macro-block, c'est un carré 16x16 pixels. Le terme de "macro-blocking" est impropre, car c'est un effet block (8x8 pixels). "Blocking artifact" est plus correct.
En français: "effet bloc".

Yoghourt

» 10 Jan 2005 22:28

Blade a écrit:Au sein même du flux de données entre l’encodeur et le décodeur il est possible de transmettre des informations concernant ce deblocking.

Il n'y a quasiment pas d'info spécifique au deblocking dans MPEG4, où le deblocking filter est appliqué en post-processing seulement (pas dans la boucle de décodage). La quasi-totalité des infos nécéssaires à la décision de deblocking sont issues du décodage normal (paramètres de quantification, bloc intra/inter, ...)
Il est donc tout à fait possible de dériver pour MPEG2 un filtre de deblocking performant en s'inspirant de la norme MPEG4.

Le deblocking sur un fichier MPEG4 Vidéo adouci considérablement le rendu mais a été prévu dés le départ…

Pour info, le deblocking filter MPEG4 n'est pas normatif, mais informel. On peut implémenter ce qu'on veut à la place et rester conforme MPEG4.

Il n’existe pour le MPEG2 Vidéo aucun moyen pour savoir si les blocs "de mauvaises qualités" sont dû à un manque d’espace ou volontaires.

Si. Mais c'est à l'encodage que ça peut être mesuré (typiquement par PSNR).

» 10 Jan 2005 22:32

Blade a écrit:En fait si tous les décodeurs respectaient scrupuleusement correctement la norme de décodage, il n'y aurait aucun problème.

Si je ne me trompe, la DCT de MPEG2 est comme celle de MPEG4: définie en flottant dans le standard. Ce qui fait que le résultat de 2 décodeurs différents n'est pas forcément identique (DCT donnant des résultats différents). Dans H264, ils ont fait l'effort de tout définir en arithmétique entière (ou virgule fixe), ce qui est AMHA un grand pas en avant.

Or il semblerait que certains (beaucoup) ne respectent pas la norme mais ne se gêne pas écrire "lecteur DVD Vidéo".

Cf ma remarque ci-dessus.

Ce n'est pas le diffuseur ou le décodeur le responsable du macro-blocking, mais l'encodeur.

Et le gars qui paramètre l'encodeur...

» 10 Jan 2005 22:49

Blade a écrit:Le filtrage est génant car les moyens développés pour un lecteur de DVD ne sont pas les mêmes que sur un PC.
Donc, il n'est pas aussi efficace; il a un taux d'erreur plus élevé.

*cough* cough* *cough*
Scusez-moi, je m'étouffe.
Je ne connais pas un seul PC qui tourne à 300MHz et qui encode/decode en MPEG4 ou en H264 du VGA 30Hz. Par contre, je connais du hardware dédié qui le fait. C'est diablement efficace pour faire ça, et rien que ça (pas question de jouer à doom avec un codec en hardware dédié, c'est sûr).
Il faut plus de temps pour faire du hardware dédié optimisé que pour porter à l'arrache le codec de référence sur un PC, ça, c'est sûr aussi.
Et je vois pas ce que le "taux d'erreur" (PSNR?) vient faire là-dedans.
Et du hardware dédié pour le deblocking filter, c'est TRES interessant, car c'est un filtre très gourmand au moins en temps de calcul et bande passante (en tout cas pour MPEG4 et H264).

C'est un filtre il corrige, c'est tout.

Ouais, enfin, bon, c'est quand même paramêtré par le décodeur, et en plus c'est un filtre adaptatif, et il est taillé pour détecter et corriger un type spécifique de défaut.

Donc pour réduire les risques les side-effects et les coûts inutiles, autant se passer de ce genre d'artifice pour les lecteurs "abordables".

Concu correctement, ce n'est pas un artifice...
Comme je le disais précédemment, c'est un filtre coûteux (temps de calcul, harware dédié, mémoire, bande passante), sans compter le temps de développement et de validation pour le fabricant. Je pense que c'est plutôt pour cela qu'on ne le trouve pas forcément dans les codecs "pas chers".

» 12 Jan 2005 10:31

yoghourt> Tu es allé trop loin dans le côté technique, je n'ai pas voulu le faire pour être le plus compréhensible possible. C'est pas toujours simple d'expliquer des choses extrèmement complexes. Ne te pouffe pas de dire, on est sur la même longueur d'onde, même si j'ai volontairement altéré les informations.

» 20 Jan 2005 9:37

Je donne mon conseil de grand-mère si jamais cela peut servir:
j'ai réussi à faire diminuer fortement ce phénomène sur mon petit bloom en jouant sur les paramètres de l'image, dont le brightness en particulier. Je n'ai pas d'explication logique, mais c'est un fait.

Le DVD qui est champion pour révéler ce genre de phénomème (en tout cas pour mon bloom), c'est la série 24 (la troisième saison). Cette série adore les scène très sombres, ambiance sur fond noir, macroblocking à chaque image.

» 09 Déc 2007 2:47

yoghourt a écrit:Je ne connais pas un seul PC qui tourne à 300MHz et qui encode/decode en MPEG4 ou en H264 du VGA 30Hz. Par contre, je connais du hardware dédié qui le fait. C'est diablement efficace pour faire ça, et rien que ça (pas question de jouer à doom avec un codec en hardware dédié, c'est sûr).

tu as la reference d'un chip à 300mhz qui encode du h264 ?

» 10 Déc 2007 23:51

oui

Le STn8815 supporte encode+decode qcif 15Hz (visiophonie). Donc il supporte probablement encode cif 15 ou 30Hz sans trop forcer.
Le STn8820 (page 14) était censé sortir cette année. Il devrait supporter au moins encode H.264 VGA 30Hz, voire même encode H.264 SDTV 30Hz.
http://epnc.co.kr/pdf/2007/200710/01200710051.pdf

C'est le 1er chip qui me vient à l'esprit. Il y en a probablement d'autres (pas forcément multi-standard et qui fait le café) chez d'autres fabricants que ST

» 11 Déc 2007 0:52

marrant je m'attendais à ce que tu me parles de ST

bon sinon désolé je n'avais pas lu ta mention de la résolution

à noter que même un 7100 arrive à encoder en soft (sur les LX) en petite résolution (cif 15fps comme tu le mentionnes)

quoiqu'il en soit ca n'a rien à voir avec ce à quoi je pensais (encodage broadcast)

» 11 Déc 2007 23:28

quoiqu'il en soit ca n'a rien à voir avec ce à quoi je pensais (encodage broadcast)

Ben là, je lis pas dans les pensées, donc je suis pas sûr de comprendre la question... :S:

» 11 Déc 2007 23:43

je pensais que tu parlais de chips à 300mhz capables d'encoder du h264 en temps-réel mais en qualité broadcast, pas en qualité visio lol

» 12 Déc 2007 0:32

Ah oui, là, on avance dans le contenu technique et la discussion constructive :roll:

T'as vu la tronche des 1er contenus broadcast TDMB allemands il y a 1 an et demi? A vomir.

On est sur HCFR, tu devrais donc savoir que les DVDs superbit donnaient un résultat qualitatif nettement meilleur que les DVDs classiques. Tout simplement le résultat d'un encodage soigneux à bitrate plus important.

Je t'ai donné un exemple (plus approprié pour l'encodage qu'une puce pour set-top-box), et une piste. Si ça te gonfle à la fois de chercher et d'expliquer ce que tu cherches, faudra pas s'étonner que j'ai pas top envie de répondre. :mdr:

» 12 Déc 2007 12:03

pardon, apparemment on s'est mal compris

comme je te l'ai dit, je me demandais si tu connaissais des chips à 300mhz capables d'encoder du h264 en temps-réel, parce que ca me surprenait que ca existe

mais je ne pensais pas à des chips pour téléphones, plutôt pour des produits du genre thomson vibe ou doremi v1-hd

parce que pour moi encoder du h264 en temps-réel à ce niveau de qualité ca demande à l'heure actuelle un fpga et quelques dsp pour épauler derrière ..

désolé de ne pas avoir précisé

» 12 Déc 2007 12:09

En tout cas, en 1ere page ... belle explication de Blade