Hello !
J'ai inventé un moyen de diffuser de la vidéo en direct avec un simple serveur apache avec extension php.
Le principe (je schématise un peu) : Enregistrement/encodage d'une source vidéo dans un fichier -> transfert de ce fichier en continue par FTP sur un serveur Web -> Découpage par un script php pour n'envoyer que l'en-tête et les paquets les plus récents au lecteur.
Si ça vous intéresse, j'ai mis toutes les explication, schéma à l'appui et les sources (sous GPL) sur mon blog :
http://jeanmichel.lacroix.free.fr/
# Comme promis...
Posté par Bruce Le Nain (site web personnel) . Évalué à 3.
"faut juste adapter un peu" ? :D
[^] # Re: Comme promis...
Posté par jml94 . Évalué à 1.
L'encodage devrait pouvoir se faire avec VLC. Faudrait que je me plonge un peu dans le format avi (ou autre) ou que je trouve une lib python pour le faire... en tout cas, ça sera sûrement mieux documenté que le wmv.
[^] # Re: Comme promis...
Posté par Moonz . Évalué à 3.
* jette un rapide coup d'oeil aux sources *
En dehors de ça, je trouve les 5 dernières lignes de ftpstream.py particulièrement tarabiscottées :) (et c'est quoi ce +30+6 à headerSize ?)
Mais effectivement, AMHA ça devrait vraiment pas être difficile à adapter à un format libre.
Et en plus, je pense que toute la partie acquisition/encodage/ftpstream pourrait se faire facilement à l'aide d'une chaine gstreamer avec l'aide de gnome-vfs, genre:
gst-launch v4l2src ! ffmpegcolorspace ! theoraenc ! oggmux ! gnomevfssink location=ftp://user:password@server/stream.ogg
Yapuka :p
[^] # Re: Comme promis...
Posté par jml94 . Évalué à 5.
C'est vrai que le "+30+16" doit paraître un peut bizarre mais il y a une explication :
wmainfo donne la taille de l'en-tête sans les 30 octets inutile de la fin (réservés mais non utilisés). Pour le +16, je me suis aperçu qu'il y avais encore 16 octets non documentés avant les paquets de données. Fichue doc...
[^] # Re: Comme promis...
Posté par psychoslave__ (site web personnel) . Évalué à 10.
# remplissage?
Posté par ʭ ☯ . Évalué à 3.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: remplissage?
Posté par jml94 . Évalué à 2.
Mais si on est vraiment limité en place, on peu imaginer un système façon logrotate :
Au bout d'une taille définie, l'envoi ftp se fait sur un autre fichier et le premier est effacé au bout d'un temps de latence pour permettre à stream.php de passer de l'un à l'autre.
# Mwais...
Posté par ragoutoutou . Évalué à 3.
Mais ton approche est intéressante, pas recommandée pour faire de la diffusion de gros volumes, mais intéressante.
[^] # Re: Mwais...
Posté par Anonyme . Évalué à 4.
rtp est plus adapté mais s'il n'y avait que ca comme enjeu ! ce que du vrai streaming d'homme est capable de faire :
- seek non pas dans le tampon, mais a distance (client qui dit au serveur "lis a partir de là maintenant") - bon le seek avant marchera moyen pour du live ;)
- adaptation côté serveur a la bande passante du client pour éviter des tailles tampons qui explosent ou une video qui se coupe 10s toutes a chaque 5s de lecture (sans réencodage mains nécessite des codecs évolués)
- encore mieux avec une adaptation aux débits client dynamique pour résister aux aléas de connection.
- flux multicanal ou le client peut zapper de l'un a l'autre dans le même stream (sans reconnection) mais la ca commence a être très musclé.
La liste n'est pas longue, mais du joli casse tête quand même :)
[^] # Re: Mwais...
Posté par ragoutoutou . Évalué à 5.
Je ne te dis pas le chantier... mais ça marche...
Sinon le seek avant, on a essayé pour le lotto, mais ça marche pas...
[^] # Re: Mwais...
Posté par briaeros007 . Évalué à 2.
Tu peux me donner les codecs ?
Car dans toutes les solutions que j'ai vu il FALLAIT un double encodage.
Et c'est le conteneur qui faisait le boulot.
[^] # Re: Mwais...
Posté par Anonyme . Évalué à 2.
Vu que le Jpeg2000 commence a dater un poil, je suis parti du principe que des applications a la vidéo étaient déjà sorties. En tous cas pour VP6 y'a un truc intéressant (même si tu l'as sans doutes étudié) :
«Achieves any requested data rate by choosing automatically to adjust quantization levels, adjust encoded frame dimensions, or drop frames altogether.»
[^] # Re: Mwais...
Posté par briaeros007 . Évalué à 2.
Ca m'étonnait donc que ca existe déja;)
http://en.wikipedia.org/wiki/Scalable_Video_Coding
# FTP ...
Posté par TazForEver . Évalué à 0.
[^] # Re: FTP ...
Posté par Sylvain (site web personnel) . Évalué à 4.
[^] # Re: FTP ...
Posté par Mildred (site web personnel) . Évalué à 2.
Mais je n'ai pas l'impression que Mac OS le comprenne malgré son grand âge.
[^] # Re: FTP ...
Posté par jeffcom . Évalué à 1.
~~>[]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.