Recherche avancée

Médias (1)

Mot : - Tags -/iphone

Autres articles (62)

  • Des sites réalisés avec MediaSPIP

    2 mai 2011, par

    Cette page présente quelques-uns des sites fonctionnant sous MediaSPIP.
    Vous pouvez bien entendu ajouter le votre grâce au formulaire en bas de page.

  • 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 (...)

  • 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

Sur d’autres sites (8703)

  • libavcodec/jpeg2000 : fix precinct coordinate calculation

    11 avril 2020, par Gautam Ramakrishnan
    libavcodec/jpeg2000 : fix precinct coordinate calculation

    The calculation of precinct boundaries has been
    
fixed. The precinct boundaries were calculated
    
as an offset to the band boundary, but must
    
instead be calculated as an offset from the
    
reslevel. This patch fixes #4669 and #4679.
    

    Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
    • [DH] libavcodec/jpeg2000.c

  • h264_mp4toannexb : Don't forget numOfPictureParameterSets

    14 décembre 2019, par Andreas Rheinhardt
    h264_mp4toannexb : Don't forget numOfPictureParameterSets

    The format of an AVCDecoderConfigurationRecord, the out-of-band
    
extradata of H.264 in mp4, is as follows : First four bytes containing
    
version, profile and level, one byte for the length size and one byte
    
each for the number of SPS, followed by the SPS (each with its own size
    
field), followed by a byte containing the number of PPS followed by the
    
PPS with their size fields. While the number of SPS/PPS may be zero, the
    
bytes containing these numbers are mandatory. Yet the byte containing
    
the number of PPS has been ignored in two places :
    
1. In the initial check for whether the extradata can contain an
    
AVCDecoderConfigurationRecord. The minimum size is 7, not 6.
    
2. No check is made for whether the extradata ended right after the last
    
byte of the last SPS of the SPS array. Instead the first byte of the
    
padding is read as if it were part of the extradata and contained the
    
number of PPS (namely zero, given that the padding is zeroed). No error
    
or warning was ever raised.
    
This has been changed. Such truncated extradata is now considered
    
invalid ; the check for 2. has been incorporated into the general size
    
check.
    

    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
    
Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
    • [DH] libavcodec/h264_mp4toannexb_bsf.c

  • h264_mp4toannexb : Try to avoid four byte startcodes

    14 décembre 2019, par Andreas Rheinhardt
    h264_mp4toannexb : Try to avoid four byte startcodes

    According to the H.264 specifications, the only NAL units that need to
    
have four byte startcodes in H.264 Annex B format are SPS/PPS units and
    
units that start a new access unit. Before af7e953a, the first of these
    
conditions wasn't upheld as already existing in-band parameter sets
    
would not automatically be written with a four byte startcode, but only
    
when they already were at the beginning of their input packets. But it
    
made four byte startcodes be used too often as every unit that is written
    
together with a parameter set that is inserted from extradata received a
    
four byte startcode although a three byte start code would suffice
    
unless the unit itself were a parameter set.
    

    FATE has been updated to reflect the changes. Although the patch leaves
    
the extradata unchanged, the size of the extradata according to the FATE
    
reports changes. This is due to a quirk in ff_h2645_packet_split which
    
is used by extract_extradata : If the input is Annex B, the first zero of
    
a four byte startcode is considered a part of the last unit (if any).
    

    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
    
Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
    • [DH] libavcodec/h264_mp4toannexb_bsf.c
    • [DH] tests/ref/fate/h264-bsf-mp4toannexb
    • [DH] tests/ref/fate/h264_mp4toannexb_ticket2991
    • [DH] tests/ref/fate/h264_mp4toannexb_ticket5927
    • [DH] tests/ref/fate/h264_mp4toannexb_ticket5927_2
    • [DH] tests/ref/fate/segment-mp4-to-ts

Navigation