Recherche avancée

Médias (91)

Autres articles (62)

  • MediaSPIP v0.2

    21 juin 2013, par

    MediaSPIP 0.2 est la première version de MediaSPIP stable.
    Sa date de sortie officielle est le 21 juin 2013 et est annoncée ici.
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Comme pour la version précédente, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
    Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)

  • Les tâches Cron régulières de la ferme

    1er décembre 2010, par

    La gestion de la ferme passe par l’exécution à intervalle régulier de plusieurs tâches répétitives dites Cron.
    Le super Cron (gestion_mutu_super_cron)
    Cette tâche, planifiée chaque minute, a pour simple effet d’appeler le Cron de l’ensemble des instances de la mutualisation régulièrement. Couplée avec un Cron système sur le site central de la mutualisation, cela permet de simplement générer des visites régulières sur les différents sites et éviter que les tâches des sites peu visités soient trop (...)

  • Mise à disposition des fichiers

    14 avril 2011, par

    Par défaut, lors de son initialisation, MediaSPIP ne permet pas aux visiteurs de télécharger les fichiers qu’ils soient originaux ou le résultat de leur transformation ou encodage. Il permet uniquement de les visualiser.
    Cependant, il est possible et facile d’autoriser les visiteurs à avoir accès à ces documents et ce sous différentes formes.
    Tout cela se passe dans la page de configuration du squelette. Il vous faut aller dans l’espace d’administration du canal, et choisir dans la navigation (...)

Sur d’autres sites (9003)

  • webRTC issue converting from webm+wav to mp4

    16 janvier 2015, par DevStarlight

    After I got my .webm video and my .wav audio I decided to join it into an .mp4 file container.

    I followed the library of muaz-khan ffmpeg-asm.js to do this conversion but when It finished, I got the blob which apparently was empty of video but after I downloaded I could reproduce it on my windows media player.

    This is the code I have created for this test : jsfiddle

    Checking some other sources, I found that there is another guy who reported the problem directly to muaz-khan 1 month ago webrtc-experiment.com (Last comment).

    I don’t think it’s a problem related to conversion, I rather think is much more a problem of codecs.

    How could I solve this problem (if it’s possible to solve it) in order to watch my videos ?

    Thanks in advice.

  • the problem using "yt-dlp —download-sections" [closed]

    15 avril 2024, par talent

    I tried to use "yt-dlp —download-sections" to download specific segment of YouTube video.

    


    But I have confronted some error.

    


    If I use the cammand as followed, it will be ok, and download the whole video successfully.

    


    yt-dlp -P [path] [URL]


    


    But, if I add the "—download-sections" to download specific segment, it seems something wrong.
the command is as followed.

    


    yt-dlp -P [path] --download-sections "*00:08:06-00:08:17" https://www.youtube.com/watch?v=6Vkmb4cUuLs 


    


    the eccor message

    


    Plus, the operation system is Windows. And I have used vpn(proxy).

    


    ffmpeg configuration

    


    I'd be tremendously appreciated if anyone can give me the early response to solve it !!!

    


  • YouTube's HD Video Streaming Server Technology ?

    30 septembre 2013, par bgentry

    Lately I've been researching different methods for streaming MP4s to the browser. Flash Media Server is an obvious choice here (using Cloudfront), and most solutions I've seen use the RTMP protocol.

    However, I spent some time on YouTube with Firebug and Chrome debugger figuring out how their streaming worked and I discovered some interesting differences between some of their videos and quality rates.

    My two sample videos are A and B. A is available up to 480p and B is available up to 1080p. For both videos, all rates up to 480p are served in an FLV container with H.264 video and AAC audio, over HTTP. What's interesting here is that if you have not yet downloaded (cached) the entire video, and you try to skip forward to an uncached part of the video, a new request will be made with a 'begin' parameter equal to the target offset in milliseconds. Example from Video A at 480p :

    http://v11.lscache8.c.youtube.com/videoplayback?ip=0.0.0.0&sparams=id%2Cexpire%2Cip%2Cipbits%2Citag%2Calgorithm%2Cburst%2Cfactor%2Coc%3AU0dWTldQVF9FSkNNNl9PSlhJ&fexp=904806%2C902906%2C903711&algorithm=throttle-factor&itag=35&ipbits=0&burst=40&sver=3&expire=1279756800&key=yt1&signature=D2D704D63C242CF187CAA5B5D5BAFB8DFACAC5FF.39180C01559C976717B651A7EB1D0C6249231EB7&factor=1.25&id=8568eb3135971f6f&begin=111863

    Response Headers:
    Cache-Control:public,max-age=23472
    Connection:close
    Content-Length:14320637
    Content-Type:video/x-flv
    Date:Wed, 21 Jul 2010 17:23:48 GMT
    Expires:Wed, 21 Jul 2010 23:55:00 GMT
    Last-Modified:Wed, 19 May 2010 12:31:41 GMT
    Server:gvs 1.0
    X-Content-Type-Options:nosniff

    The file returned by this URL is a fully valid FLV containing only the portion of the video after the requested offset.

    I did the same kind of test on the higher resolution versions of Video B. At 720p and 1080p, YouTube will return a video in an MP4 container, also with H.264 video and AAC audio. What's impressive to me is that their server takes the same type of offset for an MP4 video (via the 'begin' parameter) and returns a valid, streamable MP4 (moov atom at the front of the file with correct offsets) that also only includes the requested portion of the video.

    So, how does YouTube do this ? How do they generate the FLV or MP4 container on the fly with the correct headers and only the desired segment of the requested video ? I know this can be accomplished using FFMPEG to seek to the desired start point and the qt-faststart script to reposition the moov atom to the front of the stream, but it seems like this would be too slow to handle on-demand for millions of YouTube viewers.

    Ideas ?

    Thanks in advance !

    Footnote : I am not allowed to include more than 1 link at this point, so here is Video A's URL : http:// www.youtube .com/watch ?v=hWjrMTWXH28 "Video available up to 480p"