Recherche avancée

Sur d’autres sites (12475)

• Evolution #3091 : Gérer le timeout lors du calcul des filtres images

  10 août 2014, par cedric -

  Le problème ne vient pas du nombre de modèles <doc></doc> ou <img style='max-width: 300px; max-height: 300px' /> proprement dit, mais du nombre d’images réduites qu’il faut générer lors de l’affichage de la page. Ainsi, lors du premier affichage, on doit calculer toutes les images réduites d’un coup, ce qui prend du temps, et on fait timeout. Il suffit en général de ré-afficher la page une fois (ou plusieurs si il y en a vraiment beaucoup) pour que le calcul des images se finisse, et l’article s’affichera très bien ensuite.

  Il n’est pas question de limiter le nombre de documents/images insérées dans un article, car ce serait trop limitatif.
  Idéalement il faudrait être capable de gérer proprement ce timeout, et relancer le hit automatiquement au besoin.

• FMP4 moof box sequence number ordering

  15 avril 2024, par Daniel

  I wanted to do a basic fragmented mp4 broadcast program with avformat libs and HTML5 video and MSE.

  



  This is a live stream and I use avformat to copy h264 data to mp4 fragments.

  



  Here is my basic drawing of clients attaching to the stream :

  



  

  



  So, with words :

  



  

  1. C1J : First Client joins :


     

     • avformat process starts

     


     • ftyp, moov, moof, mdat boxes will be served to Client1

     


     • ftyp and moov atoms are both saved for later reuse

     


  


  2. C2J : Second Client joins (later in time) :


     

     • avformat process is ongoing (because it is still serving moof and mdat boxes for Client1)

     


     • previously saved ftyp and moov boxes will be served first to Client2

     


     • after ftyp and moov boxes were served, Client2 will join to the stream at the next moof box.

     


  


  



  I have saved an mp4 file to disk from both clients.

  



  Atoms' order within both files looks good : ftype, moov, moof, mdat, moof, mdat...

  



  Both files can be played by media players (like VLC) and also in browsers directly (Opera).

  



  Client1 can be played also via MSE in the browser (Opera), but Client2's stream is not displaying with MSE (Opera).

  



  No errors on the JS console, and media-internals looks also good (at least equivalent with Client1's one).

  



  Now I realized that every moof box contains an mfhd box (header) with a sequenceNumber field.

  



  Of course in Client1's first moof box this sequenceNumber is 1.
However in the later joined Client2's first moof box this sequenceNumber is always >= 1 (in my case it is 16).

  



  What do I need to modify in the moof boxes in Client2 to have a valid fmp4 from the beginning ?

  



  I think Opera's HTML5 video does not like if sequenceNumber does not start from 1, but there shall be other requirements for being it valid.

  


• avcodec/mpeg4videodec : Clear bits_per_raw_sample if it has originated from a previous...

  9 juin 2018, par Michael Niedermayer

  avcodec/mpeg4videodec : Clear bits_per_raw_sample if it has originated from a previous instance
  Fixes : assertion failure
  
  Fixes : ffmpeg_crash_5.avi
  Found-by : Thuan Pham <thuanpv@comp.nus.edu.sg>, Marcel Böhme, Andrew Santosa and Alexandru Razvan Caciulescu with AFLSmart
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/mpeg4videodec.c