Recherche avancée

Sur d’autres sites (9276)

• Merge commit ’3176217c60ca7828712985092d9102d331ea4f3d’

  12 juin 2016, par Clément Bœsch

  Merge commit ’3176217c60ca7828712985092d9102d331ea4f3d’
  * commit ’3176217c60ca7828712985092d9102d331ea4f3d’ :
  
    h264 : decouple h264_ps from the h264 decoder
  Main changes :
   a local GetBitContext is created for the various
  
    ff_h264_decode_seq_parameter_set() attempts
   just like the old code, remove_sps() is adjusted so it doesn’t remove
  
    the pps.
    Fixes decode with Ticket #631
  
    http://ffmpeg.org/pipermail/ffmpeg-user/attachments/20111108/dae58f17/attachment.mp4
  
    but see next point as well.
   ff_h264_update_thread_context() is updated to work even when SPS
  
    isn’t set as it breaks current skip_frame code. This makes sure we
  
    can still decode the sample from ticket #631 without the need for
  
    -flags2 +chunks. (Thanks to Michael)
   keep sps,pps_ref pointers that stay alive even when the active
  
    pps/sps get removed from the available lists (patch by michaelni with
  
    additionnal frees in ff_h264_free_context() from mateo)
   added a check on sps in avpriv_h264_has_num_reorder_frames() to fix
  
    crashes with mpegts_with_dvbsubs.ts from Ticket #4074
  
    http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4074/mpegts_with_dvbsubs.ts
   in h264_parser.c:h264_parse(), after the ff_h264_decode_extradata() is
  
    called, the pps and sps from the local parser context are updated with
  
    the pps and sps from the used h264context. This fixes fate-flv-demux.
   in h264_slice.c, "PPS changed between slices" error is not triggered
  
    anymore in one condition as it makes fate-h264-xavc-4389 fails with
  
    THREADS=N (Thanks to Michael)
  Merged-by : Clément Bœsch <clement@stupeflix.com>
  
  Merged-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Merged-by : Matthieu Bouron <matthieu.bouron@stupeflix.com>
  

  • [DH] libavcodec/dxva2_h264.c
  • [DH] libavcodec/h264.c
  • [DH] libavcodec/h264.h
  • [DH] libavcodec/h264_cabac.c
  • [DH] libavcodec/h264_cavlc.c
  • [DH] libavcodec/h264_direct.c
  • [DH] libavcodec/h264_loopfilter.c
  • [DH] libavcodec/h264_mb.c
  • [DH] libavcodec/h264_mb_template.c
  • [DH] libavcodec/h264_mvpred.h
  • [DH] libavcodec/h264_parser.c
  • [DH] libavcodec/h264_ps.c
  • [DH] libavcodec/h264_refs.c
  • [DH] libavcodec/h264_sei.c
  • [DH] libavcodec/h264_slice.c
  • [DH] libavcodec/vaapi_h264.c
  • [DH] libavcodec/vdpau.c
  • [DH] libavcodec/vdpau_h264.c
  • [DH] libavcodec/videotoolbox.c

• Anomalie #4309 (Rejeté) : 3.2 appel valider_xml en cas d’erreur sur un paquet.xml

  7 mars 2019, par Yannyx Spip

  Quand la page admin_plugin affiche des messages d’erreurs (provoqués par lecture de paquet.xml invalide d’un plugin en test), elle construit les liens valider_xml sur ces fichiers paquets, en indiquant l’URL absolue du paquet, construite par generer_url en infos_paquets.php⁸¹ $h = $GLOBALS[’meta’][’adresse_site’] . ’/’
  . substr("$dir_plugins$plug/", strlen(_DIR_RACINE)) . ’paquet.xml’ ;

  => http://localhost/ecrire/?exec=valider_xml&var_url=http://localhost/plugins/zdistous/paquet.xml

  Mais comme l’URL fournie contient http:// elle s’avère doublement rejetée :
  - par l’écran de sécurité³⁷⁸, qui refuse :// ou :\
  - et par valider_xml⁵⁴ (qui refuse aussi :// et :\ ),
  Moralité : si l’utilisateur ne sait pas recopier le lien généré sous le message additionnel, et le relancer en supprimant #URL_SITE_SPIP, il ne peut pas avoir accès à l’outil d’explication de l’erreur

  SPIP 3.2.3 sur PHP 3.5.38 en Wamp 3.1.7x64

• ImageJ / Fiji shows wrong number of frames in video (FFMPEG import)

  28 avril 2023, par locoric_polska

  I am counting the number of animals in a an area using Fiji. I import the video through the FFMPEG plug-in (videos are mp4 with mpeg-4 codec). However, I noticed that when I import the videos Fiji uploads the wrong number of frames, and I cannot understand why and how.

  


  An example. I have a video shot at 25fps which is 1582s long. If I do the calculations the video should have 39550 frames in total (1582*25). When I open it through a Computer vision package in R, I see that the video correctly contains 39550 frames. However, when loaded in Fiji, the shown number of frames is 49511. So Fiji is adding 9961 frames to the video. This is consistent across all videos that are recorded in 25fps, while it does not appear in videos shot at 24fps.

  


  Curiously, I found that the ratio between the number of frames read by Fiji and the 'real' number of frames is consistent between 0.79 and 0.80. This makes me think that Fiji is expecting the video to be 30fps and (possibly) duplicating frames to adjust the video to this assumption.

  


  Unfortunately, I discovered all this after finishing my analysis and while trying to merge this dataset with another obtained through CV. The number of frame does not match between datasets and I am not sure how to solve this.

  


  Any help would be greatly appreciated !!

  


  An idea is to multiply all the frame numbers by 0.8 to adjust them to the old assumption. This solution assumes that Fiji is duplicating frames throughout the video in a consistent way