Discussion :

[DaOurZ]

Bonjour,

J'ai un petit souci dont je vais vous faire part. J'aimerai créer un graphique avec en abscisse les numéros de frames et en ordonnée le poids de ces-dites frames, dans une vidéo, par exemple MPEG-4, le tout à des fins statistiques.

Je parle bien des frames, et non des images. La frame 1, qui est de type I (Intra-Coded) pèsera donc plus lourd qu'une frame de type B ou P.

Je pense que le plus simple est de programmer un petit logiciel à part qui fera mouliner une vidéo et ressortira un petit graphique. Mais je ne vois pas comment récupérer le poids de ces frames (d'où mon souci).

Le mieux aurait été de pouvoir inclure l'algorithme à l'encodage de la vidéo (par exemple avec ffmpeg) pour que l'encodage ainsi que mon graphique se fasse en même temps en une seule passe, mais je pense que la visibilité de l'encodeur est limitée (en effet, il voit une vidéo comme une succession de groupe d'images (les GOP) et non comme des frames déjà compressées, mais je me trompe peut-être, qu'en pensez-vous ?)

Voili voilou pour ce "petit" problème, si vous pouviez éclairer ma lanterne ce serait magnifique ! Merci d'avance.

PS : Si jamais j'ai posté ce sujet dans la mauvaise catégorie, merci de me le signaler, je m'y perds un peu avec toutes ces catégories..

[moldavi]

Bonjour.

Si j'ai bien compris, tu veux faire un graphisme avec la taille en octets des frames I, P et B, pendant l'encodage de la vidéo...

[DaOurZ]

Bonjour,

Merci de la réponse (et de la critique.. ). Bon, alors si je n'ai pas été clair (ce qui est le cas..), je vais essayer d'éclaircir les points soulevés.

Ce que j'ai besoin en gros, c'est de connaître la "taille" d'une frame d'une vidéo MPEG en octets, de sorte de connaître le trafic réseau que celle-ci va induire. On aurait par exemple "la première frame, avec cette vidéo encodée en MPEG-4, va générer 540 Ko de charge réseau, la deuxième frame générera 120 Ko, etc.".
Si mon approche par frame est mauvaise, je peux réviser mon choix et me baser sur une notion de temporalité, avec des secondes par exemple.. Donc on aurait "pendant la première seconde, avec cette vidéo encodée en MPEG-4, on va générer 10 Mo de charge réseau, pendant la deuxième seconde, ça fera 8 Mo, etc."

Donc ça, c'était pour éclaircir la première partie.

Pour la deuxième partie avec l'encodage, en fait, c'est juste que ce serait plus pratique pour moi d'avoir une vidéo quelconque dans un format quelconque, de la passer dans la moulinette de ffmpeg ou autre (un encodeur) pour la mettre en MPEG et pour générer ce que j'ai dit au-dessus (au-dessus, on part déjà d'une vidéo MPEG, ici d'une vidéo dans un format quelconque qu'on veut mettre en MPEG dans le vue d'une diffusion, ça m'éviterait une étape, mais ce n'est pas primordial).

Voilàààà ! Si jamais d'autres questions (et réponses j'espère ) pointent leur nez, je ne suis pas loin.

Merci encore.

PS : j'ai répondu avant l'édition du message, mais je laisse comme ça, pour que ce soit effectivement plus clair..

[moldavi]

...

mais je pense que la visibilité de l'encodeur est limitée (en effet, il voit une vidéo comme une succession de groupe d'images (les GOP) et non comme des frames déjà compressées, mais je me trompe peut-être, qu'en pensez-vous ?)

Ben l'encodeur, c'est bien lui qui comprime les frames qui se trouvent à l'intérieur des GOP...

Cross-Post, j'ai retiré ce que je raconte dans le premier, suis fatigué je pense...

[moldavi]

Re.

Petite précision, c'est pour du streaming vidéo ? Parce que dans tous les cas que fais-tu du poids des frames audio ?

[DaOurZ]

Merci de la remarque. Bizarrement, j'avais écarté le flux audio de mon champ d'action, ce qui est complètement ridicule.. :p

Donc oui, c'est pour du streaming, et j'ai aussi besoin du "poids" en octets de la piste audio en fonction du temps..

Hém, et j'espère qu'il est inutile de préciser que c'est dans un environnement VBR... (oui oui, j'avais oublié de le dire.. :p)

Merci encore pour ton temps..

[moldavi]

Re.

Tu utilises quel protocole de streaming ?

[DaOurZ]

En fait à la base, je ne voulais me servir que d'une simulation sous ns-2 avec des sources émettant en VBR suivant le graphique (celui que je veux créer à partir d'une vidéo). Mauvaise idée ?

Sinon, je n'ai donc pas vraiment réfléchi (oui, encore... :p) à un protocole quelconque de streaming, vu que je ne comptais faire qu'une simulation..

[moldavi]

Re.

Disons que suivant le protocole de streaming utilisé, c'est lui qui va être déterminant dans le calcul du trafic réseau.

Pour l'intant, le graphique que tu souhaites faire ne te permettra que de vérifier le taux de compression induit par l'encodeur.

[DaOurZ]

Bonjour,

En fait, vu que c'était dans le cadre d'une simulation, je ne pensais pas faire des recherches sur un protocole existant, je pensais juste prendre les données "comme elles viennent", les empaqueter dans de l'UDP et de l'IP après les avoir fragmentées correctement pour s'accorder avec les caractéristiques du réseau, et c'était tout.. Vu que c'est une vidéo VBR, la charge réseau sera différente à chaque moment de la vidéo puisque l'on est en streaming.. J'ai tout faux ?

J'ai regardé un peu les protocoles de streaming, le plus intéressant est certainement RTSP couplé à RTP, car l'un des plus évolué et abouti..

Merci encore de t'intéresser à mon cas..

[moldavi]

Bonjour.

Oui en effet, RTSP est le protocole que j'utiliserais si je devais faire du streaming. Même si je n'ai que de très faibles notions sur ce protocole, ça suffit à me faire dire que pour ta simulation réseau tu dois en tenir compte.

Tu pars du principe que tu vas émettre des données "semi-décompressées", alors que tu n'es pas certain que ce protocole fait de même. J'imagine même plutôt qu'il y a une compression des données pour une meilleure utilisation de la bande passante. Mais à vrai dire je ne sais pas à quel niveau. Sachant qu'une vidéo est souvent ultra-compressée, difficile de faire mieux parfois ou alors en dégradant l'image et le son de celle-ci. J'imagine que ce protocole propose plusieurs compromis entre efficacité réseau et qualité de son et d'image. Des compromis aussi pour les fonctionnalités : streaming direct - possibilité d'avance ou de retour dans le flux, etc...

Si ta simulation a des exigences de réalisme (côté pratique), tu dois alors tenir compte du protocole de streaming.

PS: tu risques peut-être même te rendre compte que le format vidéo de départ pour faire du streaming est "figé". Dans le sens ou par exemple le variable bitrate est à proscrire. Je dis ça parce que pour un maximum d'efficacité, j'imagine que le format vidéo de base a déjà des exigences pour
s'adapter au streaming, et que certains formats ne le sont pas.