Bonjour
 
Lorsque je découpe un mpg2 pour virer la pub (par exemple), la structure du GOP devient "variable" selon MediaInfo alors que le fichier initial comporte une structure du type M=3 N=24 (structure GOP moyen de diffusion Terrestre TNT).
 

 
Est-ce normal ? Peut-être que je découpe sur de mauvaises frames ? (Je coupe sur une I-frame pour le début et je termine sur une P-frame, il me semble que c'est correct ?).
 
Le logiciel que j'utilise est VideoRedo Plus. Dans les options de fichiers de sortie, il est possible de régler divers options :
 

 
Je laisse tout en "No Change".
 
J'ai lu sur divers site que la norme du GOP en DvD est de 15 en PAL et 18 en NTSC.
 
J'aimerais savoir si la structure du GOP (IBP...) est réellement importante ?  
 
Je compte par la suite démuxer le fichier mpg2 que j'ai redécoupé pour le remuxer avec IfoEdit est ainsi créer mon DvD pour la lecture sur platine de salon. Seulement, je ne sais pas si cela reste compatible à cause de la structure du GOP qui est variable (donc pas au norme DvD) ?
 
Si la structure du GOP est à prendre en compte, comment faire pour avoir une structure GOP de type DvD sans réencodage ?
 
Merci.

Sans ré-encodage, ce ne sera pas possible, mais j'ai lu que VideoRedo faisait du smart rendering quand on voulait rendre un fichier mpeg-2 compatible avec la norme dvd-vidéo (il y a une option pour ré-encoder les GOP trop longs).
Mais il paraît aussi que ça n'a pas vraiment d'importance et que les lecteurs de salon acceptent des GOP plus longs que 15 (en Pal, 18 en Ntsc), donc mieux vaut tester avec un extrait sur son lecteur de salon avant de ré-encoder inutilement. Parce que si tous les GOP sont trop longs, le smart rendering ressemblera plus à un ré-encodage complet qu'à du smart rendering.
Par contre, ce qui risque de poser problème c'est le débit maximal de 15 Mbps détecté par MediaInfo. Ce n'est en fait pas le débit réel, c'est une erreur d'en-tête (assez fréquente avec les enregistrements de TNT et DVB-C) qui peut se corriger assez facilement.
Pour ce faire, analyse ton fichier mpeg ou ts avec Bitrate Viewer, note le débit maximal (pas le moyen) indiqué à la fin de l'analyse, dé-multiplexe ton fichier mpeg ou ts en mpv ou m2v, ouvre-le dans ReStream et remplace le débit indiqué par celui indiqué par Bitrate Viewer, sans oublier de rajouter 000 (3 zéro) à la fin puisque ReStream donne le débit en bps et Bitrate Viewer en kbps.
Puis tu l'exportes et tu verras que MediaInfo indique bien le débit mis dans ReStream.

Merci pour ces explications.
 
En effet, j'ai pu remarquer un ré-encodage du fichier si je change la structure des gop avec videoredo. C'est surtout au niveau du logo de la chaîne que c'est le plus flagrant.
 
 
Par contre, pour la manipulation que tu me proposes, y aura-t il un ré-encodage du fichier ?
 
Autre question : quand on découpe un fichier, on commence sur une I frame et on termine sur une P frame c'est bien ça ?
 
Merci.

Ben non, j'ai bien parlé de correction d'en-tête.
 

Si le logiciel peut faire du smart rendering, ça n'a pas d'importance.
Sinon, tu commences sur une I frame et tu termines sur une frame qui précède une I frame, je ne sais pas si ce sera d'office une P frame ou si ça peut être une B frame.
Et avec Virtual Dub, je pense qu'il faut terminer sur une I frame, il coupera automatiquement sur la frame précédente.

Ok. C'est quoi du smart rendering ?
Et comment je fais pour savoir ?
 
Merci.

C'est un ré-encodage partiel qui ne concerne que ce qu'il faut ré-encoder. Donc les parties modifiées d'un montage par exemple, ou les GOP trop longs dans ce cas-ci.
Ça doit être marqué dans le manuel du logiciel ou alors il est marqué au moment de l'export que x % de l'image seront ré-encodés. Ce serait bien sûr 100 % s'il n'y avait pas de smart rendering.
Apparemment VideoRedo fait du smart rendering pour les GOP trop longs.
Et tu peux voir ça aussi à la vitesse d'encodage, beaucoup plus rapide qu'un ré-encodage complet.

Videoredo ne marque rien du tout concernant le % d'image qui sont ré-encodées. Cependant, il est rapide lors de la découpe d'un fichier (2 à 3 minutes pour un reportage d'une heure par exemple).
 
Donc si j'ai bien compris même si je découpe sur de mauvaises frames grâce au smart rendering le logiciel ne ré-encodera pas le fichier complet mais uniquement la partie mal decoupé pour "fermer" le gop. C'est ça grosso modo ?

Oui.

Ok merci pour ton aide.

 
Par contre pour ça, je dois le faire sur le fichier d'origine ou je peux le faire aussi sur le fichier redécoupé ?
 
Puis, il a pas pas mal d'option sur ReStream, je laisse tout par défaut mis à par le débit ?
 

Comme tu veux.
 

Oui.
Tu peux éventuellement cocher TFF si c'est du TFF (voir dans MediaInfo).

 
Je vois rien de ça dans MediaInfo :

Alors ne le coche pas dans ReStream.
C'est la dernière version de MediaInfo ?
Sinon tu peux éventuellement voir ça dans Gspot, un vieux programme dans le style MediaInfo très bien pour le mpeg et l'avi, il montre des choses que MediaInfo ne montre pas.

Ok je vais télécharger Gspot.
 
 
Dernière chose qui me préoccupe, j'ai le "time code de la première image" à 00:00:00:19. Pourtant, dans mon fichier d'origine tout est à zéro mais quand je fais la découpe avec VideoRedo Plus, le "time code de la première image" change.
 

 
Je voudrais savoir à quoi ça correspond et si je dois mettre tout à zéro (j'ai parcouru pas mal de mes dvd, le time code de la première image est chaque fois à 00:00:00:00). J'ai vu que je pouvais le changer dans ReStream.
 

 
Merci
 
 
Édit : Gspot détecte TFF pour le fichier.
 

Pour time code de la première image, je ne peux pas t'aider, je ne connaissais pas ce paramètre.
Essaye de faire une recherche (et aussi en anglais pour plus de résultats) pour voir si c'est problématique.
Ce que tu peux tenter, c'est de découper sur la 19ème image (avec le son pour que tout reste synchro) pour qu'elle se retrouve en premier, à 00:00:00:00.

 
Ok je vais voir ça et je réup si j'ai un soucis de compréhension

Je viens d'éditer mon message précédent pour y rajouter une ligne

Oui mais c'est lorsque je découpe que ça me fait ça. Alors si je découpe à la 19ème image dans ce que j'ai déjà découpé je n'aurais plus le début de l'émission (ça fait beaucoup de découpe )

Je me demande si ce ne serait pas le timecode de la première image Intra, ce qui voudrait dire que VideoRedo ne ré-encode pas le premier GOP, ce serait étonnant.
On peut voir ça dans Virtual Dub (qui a besoin d'un plugin pour le mpeg-2) ou Virtual Dub Mpeg-2 (plugin intégré). Il suffit de cliquer sur next ou previous keyframe et voir s'il y en a une sur la première image.
Ou dans Mpeg Video Wizard (de Womble, payant) qui montre la nature de chaque image (I, P ou B).

Avec videoredo aussi on peut voir la structure de chaque image. Et la première est une I-frame. C'est ça que tu veux savoir ?
 
 
Édit : gSpot le fait aussi
 
Sinon, j'ai pas beaucoup trouver d'info sur le first-gop timecode.

Alors teste cette vidéo sur ton lecteur et vois si ça passe.
 

Oui, donc je ne sais pas ce qu'est ce first-gop timecode.
 

Ah oui, en cliquant sur VGS,tu m'as fait découvrir un truc là

J'ai mis le timecode tout à 0 (grâce à restream). Je verrais si ça passe sur mon lecteur de salon.
 

Encore moins moi... Si une personne sait de quoi il s'agit et passe par ici ce serait sympa de sa part
 

Content de ça

Il faudrait peut-être le tester aussi en laissant comme c'était (à 00:00:00:19) pour voir si les 2 passent.

En faisant une recherche sur first gop timecode, j'ai trouvé ça ;
http://www.womble.com/support/vcr-faq21.html

Et je découvre par la même occasion que Mpeg Video Wizard est capable aussi de ré-encoder les GOP trop longs.  
 
Mais je n'ai pas encore bien pigé si ce timecode devait forcément être à 00:00:00:00.

 
Oui dans les options de Wizard il me semble qu'il est possible de cocher une case "GOP size compliance for DVD recording" ce qui permet de ré-encoder le fichier mpg2 à la norme dvd.
 

 
Si je prend le fichier "VTS_01_1.VOB" d'un dvd, MediaInfo indique le time code de la première image à 00:00:00:00. Si je prend le fichier "VTS_01_2.VOB" du même dvd, MediaInfo indique le time code de la première image à 00:31:03:14, etc... (le time code du second vob dépend du premier vob)
 
Donc dans une logique (mais cela reste mon avis perso je ne suis pas un expert) cela signifie que le timecode de la première image doit être à zéro (si le fichier est unique ou pour le premier fichier dans la structure d'un dvd).

Possible, mais je me demande pourquoi dans ton cas ça se retrouve à 00:00:00:19.
Tu as testé sur un lecteur de salon ?

Pas encore mais je compte le faire

J'ai un petit soucis sur un nouvel enregistrement.
 
J'aimerais passer le fichier dans ReStream pour corriger le débit maximal de 15 Mbps à cause des erreurs d'en-tête récurrentes sur les enregistrements TNT.
 
Seulement, MediaInfo m'indique que la vidéo est en mode progressif et gSpot en mode entrelacé donc je ne sais pas ce que je dois cocher dans ReStream.  
 

 

 

 
Les deux programmes sont à jour, qui je dois croire du coup ?
 
Puis c'est quoi la différence entre "FrameType progressive" et "Progressive sequence" dans Restream ?
 
Merci

Bonne question, merci de l'avoir posée    
Je ne sais pas.  
 
Pour ta 1ère question, je crois que c'est d'office entrelacé et TFF quand ça vient de la télé, donc n'y touche pas. Et le progressif est considéré comme TFF, donc si tu mets TFF ça devrait être lu correctement.
Le BFF est surtout utilisé par les caméras DV.

Ok donc je coche "top field first" dans Restram et c'est tout.
Par contre, j'ai remarqué que quand j'ouvre l'enregistrement en question dans Restream ce dernier coche la case "frametype progressive" par défaut. Je dois la décocher du coup ?

T'en as encore beaucoup des questions comme ça ?  
C'est un cas assez particulier et je ne veux pas t'induire en erreur, il faudrait se renseigner sur le rôle exact de ces réglages.
Il est possible que s'il s'agit d'un film, l'image soit considérée comme de type progressif, bien qu'étant encodée en entrelacé, comme les films sur Dvd (Pal, parce qu'en ntsc c'est plus compliqué à cause du flag de 3:2 pulldown).

Désolé d'être chiant avec mes questions débiles... Toi, tu ne veux pas m'induire en erreur et moi, je ne veux pas en faire. Seulement, je ne trouve pas beaucoup d'information sur Restream. En tout cas, j'ai déjà appris pas mal de chose grâce à toi et je t'en remercie
 

Ce n'est pas un film, c'est une émission télé... le reste c'est un peu du charabia pour moi. Je ne comprends pas comment une vidéo peut être considérée en mode progressif en étant encodé en mode entrelacé. C'est trop technique pour moi ces choses là
 
Sinon, j'ai trouvé un petit tuto (et c'est bien le seul) : http://www.digitalfaq.com/guides/v [...] -order.htm
 

Le logiciel au chargement du fichier coche automatiquement ce qui lui semble correct selon son analyse du fichier.
 

Cependant, il se peut que le fichier censé entrelacé soit enregistré en format progressif (ça rejoint ce que tu disais dans ton précédent post), ce qui a une incidence sur le balayage (après je ne sais pas comment on procède pour constater ce problème). Bref, ça voudrait dire que le fichier a mal été encodé et qu'il faudrait le ré-encoder.
 

 
Un exemple est donné avec le TFF auto-coché lors du chargement du fichier, mais un bug est constaté sur le fichier final dû au mauvais paramètres d'entrelacement. Pour corriger ce problème il faut dé-sélectionner la case TFF.
 
Donc en conclusion, il faut jouer avec les paramètres selon le ou les problèmes constatés sur le fichier final mais dans mon cas je ne sais pas si c'est possible de voir à l’œil nu si un fichier est réellement entrelacé ou progressif (peut être en faisant un arrêt sur image) car avec les logiciels ça ne m'a pas l'air d'être fiable à 100%.
 
Après comme tu le dis les chaines de télé doivent certaines envoyées de l'entrelacé d'office histoire d'économiser en bande passante.

Elles n'ont pas le choix, c'est encodé en entrelacé, et je pense que la télé est toujours en TFF, donc je crois que tu peux cocher tff et décocher progressive frame.
Et quand on dit économiser en bande passante, oui et non. Oui dans le sens où on n'envoie qu'une demi image à la fois (un champ pair ou impair), mais non dans le sens où ça augmente un peu le débit total ; 50 demi images prennent plus de place que 25 entières.
 

Dans Virtual dub, tu regardes un passage en mouvement et tu vois s'il y a un effet de peigne. A condition que progressive soit choisi dans options, preview field mode (normalement c'est le réglage par défaut). Ça veut dire qu'il va afficher les 2 champs en même temps, sans désentrelacer.
Si la source est d'origine progressive, tu ne verras pas d'effet de peigne.
Et si la source est entrelacée et qu'il y a une mauvaise parité des champs (bbf au lieu de tff ou l'inverse), les mouvements ne sont pas du tout fluides. On voit ça parfois dans des reportages pendant les JT (notamment sur FR2).
Mais ça je pense que tu ne le verras pas dans Virtual dub dans ce mode-là (progressive dans preview field mode) puisqu'il ne tient plus compte de l'ordre des champs, il les affiche en même temps. C'est plutôt avec un logiciel de lecture que tu pourras constater s'il y a mauvaise parité, ou en changeant le mode dans preview field mode.
 

Une source progressive (film) peut être encodée en entrelacé. Ça veut simplement dire que chaque image sera divisée en 2 champs (pair et impair) à l'encodage, mais vu que ces 2 champs proviennent de la même image (filmés en même temps), le fait de l'encoder en entrelacé ne va pas modifier sa structure et ne changera rien par rapport à un encodage en progressif, c'est simplement un empaquetage différent pour une meilleure compatibilité avec les lecteurs.
C'est surtout si on met bff au lieu de tff (ou l'inverse) que ça pose problème, donc dans le cas d'une source vraiment entrelacée (filmée en entrelacé).
 
Pour bien comprendre les sources entrelacées, il faut faire abstraction de la notion de champs pair et impair et il faut se dire que ce sont des images différentes.
Imagine qu'on filme en TFF et le premier champ est le n°1 et le suivant le 2. Ensemble ils forment une image, sauf qu'elle contient en réalité 2 demi images qui n'ont pas été filmées en même temps, donc elles sont différentes et ne peuvent pas être affichées en même temps, sinon on voit le fameux effet de peigne.
Et leur ordre a de l'importance, parce que si tu mets un flag bff au lieu de tff, le lecteur va lire les champs dans le mauvais ordre, ce qui va fortement nuire à la fluidité. Ça revient à lire les images dans cet ordre : 2, 1 - 4, 3 - 6, 5 - 8, 7 - 10, 9 - 12, 11 ... au lieu de 1, 2 - 3, 4 - 5, 6 -...

 
Ok je vais faire ça
 
Merci pour toutes les explications.

 
Je rebondis sur cet aspect là.
 
Est-ce que ce problème d'en-tête est présent aussi dans les enregistrements TNT HD ?
Si c'est le cas, est ce qu'il existe des logiciels comme Bitrate Viewer et ReStream qui ne sont pas compatibles avec la HD ?
 
Merci
 

Je crois que la question ne se pose pas avec le codec AVC, c'est avec le mpeg-2 qu'on rencontre ce genre de problèmes et la HD européenne n'est pas en mpeg-2 mais en AVC (alors qu'aux USA la HD est en mpeg-2).
Et de toute façon, même en admettant qu'il y ait une erreur d'en-tête concernant le débit, ça ne posera aucun problème aux lecteurs HD.

Je ne savais pas que les US avaient adopté le mpg2 pour la HD. Génial, j'ai encore appris quelque chose
 
Merci arnuche.

C'est parce qu'ils l'ont adoptée à une époque où l'AVC n'existait pas, dès les années 90', comme le Japon.
Mais je ne serais pas étonné que des opérateurs japonais proposent désormais de la HD en AVC, quitte à obliger tout le monde à changer de décodeur, parce qu'ils aiment se renouveler, ce qui est moins le cas des américains.

Les jap aiment se renouveler mais être aussi à jour voir en avance dans la technologie numérique