Recherche avancée

Médias (1)

Mot : - Tags -/bug

Autres articles (75)

  • La file d’attente de SPIPmotion

    28 novembre 2010, par

    Une file d’attente stockée dans la base de donnée
    Lors de son installation, SPIPmotion crée une nouvelle table dans la base de donnée intitulée spip_spipmotion_attentes.
    Cette nouvelle table est constituée des champs suivants : id_spipmotion_attente, l’identifiant numérique unique de la tâche à traiter ; id_document, l’identifiant numérique du document original à encoder ; id_objet l’identifiant unique de l’objet auquel le document encodé devra être attaché automatiquement ; objet, le type d’objet auquel (...)

  • Multilang : améliorer l’interface pour les blocs multilingues

    18 février 2011, par

    Multilang est un plugin supplémentaire qui n’est pas activé par défaut lors de l’initialisation de MediaSPIP.
    Après son activation, une préconfiguration est mise en place automatiquement par MediaSPIP init permettant à la nouvelle fonctionnalité d’être automatiquement opérationnelle. Il n’est donc pas obligatoire de passer par une étape de configuration pour cela.

  • Gestion des droits de création et d’édition des objets

    8 février 2011, par

    Par défaut, beaucoup de fonctionnalités sont limitées aux administrateurs mais restent configurables indépendamment pour modifier leur statut minimal d’utilisation notamment : la rédaction de contenus sur le site modifiables dans la gestion des templates de formulaires ; l’ajout de notes aux articles ; l’ajout de légendes et d’annotations sur les images ;

Sur d’autres sites (6348)

  • avcodec/atrac3plus : reorder channels to match the output layout

    31 octobre 2022, par James Almer
    avcodec/atrac3plus : reorder channels to match the output layout

    The order in which the channels are coded in the bitstream do not always follow
    
the native, bitmask-based order of channels both signaled by the WAV container
    
and forced by this same decoder. This is the case with layouts containing an
    
LFE channel, as it's always coded last.
    

    Fixes ticket #9964.
    

    Signed-off-by : James Almer <jamrial@gmail.com>
    • [DH] libavcodec/atrac3plusdec.c

  • lavu/pixdesc : favour formats where depth and subsampling exactly match

    8 septembre 2022, par Philip Langdale
    lavu/pixdesc : favour formats where depth and subsampling exactly match

    Since introducing the various packed formats used by VAAPI (and p012),
    
we've noticed that there's actually a gap in how
    
av_find_best_pix_fmt_of_2 works. It doesn't actually assign any value
    
to having the same bit depth as the source format, when comparing
    
against formats with a higher bit depth. This usually doesn't matter,
    
because av_get_padded_bits_per_pixel() will account for it.
    

    However, as many of these formats use padding internally, we find that
    
av_get_padded_bits_per_pixel() actually returns the same value for the
    
10 bit, 12 bit, 16 bit flavours, etc. In these tied situations, we end
    
up just picking the first of the two provided formats, even if the
    
second one should be preferred because it matches the actual bit depth.
    

    This bug already existed if you tried to compare yuv420p10 against p016
    
and p010, for example, but it simply hadn't come up before so we never
    
noticed.
    

    But now, we actually got a situation in the VAAPI VP9 decoder where it
    
offers both p010 and p012 because Profile 3 could be either depth and
    
ends up picking p012 for 10 bit content due to the ordering of the
    
testing.
    

    In addition, in the process of testing the fix, I realised we have the
    
same gap when it comes to chroma subsampling - we do not favour a
    
format that has exactly the same subsampling vs one with less
    
subsampling when all else is equal.
    

    To fix this, I'm introducing a small score penalty if the bit depth or
    
subsampling doesn't exactly match the source format. This will break
    
the tie in favour of the format with the exact match, but not offset
    
any of the other scoring penalties we already have.
    

    I have added a set of tests around these formats which will fail
    
without this fix.
    • [DH] libavutil/pixdesc.c
    • [DH] libavutil/pixdesc.h
    • [DH] libavutil/tests/pixfmt_best.c
    • [DH] libavutil/version.h
    • [DH] tests/ref/fate/pixfmt_best

  • Why don't VideoIntelligence end_time_offset values match for the same video ?

    3 septembre 2022, par ProGirlXOXO

    When parsing the results of Google's Video Intelligence API, I've noticed that speech_transcriptions and all other annotation results are split into two separate list items within annotation_results. See the example output below.

    &#xA;

    Digging further, I've noticed they have slightly varied end_time_offset values.

    &#xA;

      &#xA;
    1. Why are these end_time_offset values different ? I expect them both to show the exact same value since the exact same video is being analyzed for both sets of features. In some cases this value is off by more than a second.

      2. &#xA;

    2. Assuming this is not an error, which end_time_offset I trust if I want to determine the total duration of the video ?

      3. &#xA;

    3. Why is feature output split into two different list items ?

      4. &#xA;

    &#xA;

    {&#xA;    "annotation_results": [&#xA;        {&#xA;            "input_uri": "<redacted>.mp4",&#xA;            "segment": {&#xA;                "start_time_offset": {},&#xA;                "end_time_offset": {&#xA;                    "seconds": 57,&#xA;                    "nanos": 849516000&#xA;                }&#xA;            },&#xA;            "shot_label_annotations": [],&#xA;            "shot_annotations": [],&#xA;            "explicit_annotation": {},&#xA;            "text_annotations": [],&#xA;            "logo_recognition_annotations": []&#xA;        },&#xA;        {&#xA;            "input_uri": "<redacted>.mp4",&#xA;            "segment": {&#xA;                "start_time_offset": {},&#xA;                "end_time_offset": {&#xA;                    "seconds": 58,&#xA;                    "nanos": 69333000&#xA;                }&#xA;            },&#xA;            "speech_transcriptions": []&#xA;        }&#xA;    ]&#xA;}&#xA;</redacted></redacted>

    &#xA;

Navigation