Recherche avancée

Médias (0)

Mot : - Tags -/publication

Aucun média correspondant à vos critères n’est disponible sur le site.

Autres articles (40)

  • Les autorisations surchargées par les plugins

    27 avril 2010, par

    Mediaspip core
    autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs

  • Publier sur MédiaSpip

    13 juin 2013

    Puis-je poster des contenus à partir d’une tablette Ipad ?
    Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir

  • Support de tous types de médias

    10 avril 2011

    Contrairement à beaucoup de logiciels et autres plate-formes modernes de partage de documents, MediaSPIP a l’ambition de gérer un maximum de formats de documents différents qu’ils soient de type : images (png, gif, jpg, bmp et autres...) ; audio (MP3, Ogg, Wav et autres...) ; vidéo (Avi, MP4, Ogv, mpg, mov, wmv et autres...) ; contenu textuel, code ou autres (open office, microsoft office (tableur, présentation), web (html, css), LaTeX, Google Earth) (...)

Sur d’autres sites (7068)

  • Prevent suspend event when streaming video via HTML video tag

    24 septembre 2014, par jasongullickson

    I seem to be having the opposite problem of most people who are streaming video using the HTML video tag ; I’m saturating the client with data.

    When playing a long video served via ffserver (webm container) everything works great but eventually the browser (Chrome in this case) will begin throwing "suspend" events. After a number of these ( 50-100), a "stalled" event will fire and playback will stop.

    I believe the problem is that once Chrome has buffered a certain amount of video it goes into "suspend" and stops downloading more data. I’ve tested this theory by throttling the speed at which video data is delivered, and if I keep the delivered frame rate close to the playback rate, I can prevent this from happening, but of course deliberately holding back server performance isn’t ideal.

    What I’m looking for is either a way to suppress this "suspend" behavior altogether, or alternatively a way to respond to the event that prevents the eventual "stalled" state.

    Presumably the browser at some point exits the "suspend" state and begins requesting data again, but I haven’t actually observed this occurring. I’m using a chain of mpeg2 -> ffmpeg -> ffserver to stream the video so if the browser is attempting to resume loading data I don’t see the request in my application. I could use a proxy or a sniffer to watch for the traffic but I would expect that maybe there is an ffserver log that can tell me the same thing ? In any event if it’s attempting to resume the download it’s failing, and there’s no indication server-side that there’s a reason for the request to fail (in fact I can pull up the same video feed from ffserver and see it playing correctly).

    So I feel like I’ve isolated this to a client-side playback issue, and one where the browser is voluntarily giving up on loading the data, but I’m not sure how to convince it to "not do that", or at least attempt to resume when it runs the buffer dry.

  • avcodec/hevc_mvs : Pass HEVCLocalContext when slice-threading

    29 juin 2022, par Andreas Rheinhardt
    avcodec/hevc_mvs : Pass HEVCLocalContext when slice-threading

    The HEVC decoder has both HEVCContext and HEVCLocalContext
    
structures. The latter is supposed to be the structure
    
containing the per-slicethread state.
    

    Yet that is not how it is handled in practice : Each HEVCLocalContext
    
has a unique HEVCContext allocated for it and each of these
    
coincides except in exactly one field : The corresponding
    
HEVCLocalContext. This makes it possible to pass the HEVCContext
    
everywhere where logically a HEVCLocalContext should be used.
    

    This commit stops doing this for lavc/hevc_mvs.c ; it also constifies
    
everything that is possible in order to ensure that no slice thread
    
accidentally modifies the main HEVCContext state.
    

    Reviewed-by : Anton Khirnov <anton@khirnov.net>
    
Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
    • [DH] libavcodec/hevc_mvs.c
    • [DH] libavcodec/hevcdec.c
    • [DH] libavcodec/hevcdec.h

  • avcodec/hevc_cabac : Pass HEVCLocalContext when slice-threading

    30 juin 2022, par Andreas Rheinhardt
    avcodec/hevc_cabac : Pass HEVCLocalContext when slice-threading

    The HEVC decoder has both HEVCContext and HEVCLocalContext
    
structures. The latter is supposed to be the structure
    
containing the per-slicethread state.
    

    Yet that is not how it is handled in practice : Each HEVCLocalContext
    
has a unique HEVCContext allocated for it and each of these
    
coincides except in exactly one field : The corresponding
    
HEVCLocalContext. This makes it possible to pass the HEVCContext
    
everywhere where logically a HEVCLocalContext should be used.
    

    This commit stops doing this for lavc/hevc_cabac.c ; it also constifies
    
everything that is possible in order to ensure that no slice thread
    
accidentally modifies the main HEVCContext state.
    

    Reviewed-by : Anton Khirnov <anton@khirnov.net>
    
Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
    • [DH] libavcodec/hevc_cabac.c
    • [DH] libavcodec/hevcdec.c
    • [DH] libavcodec/hevcdec.h

Navigation