Recherche avancée

Médias (1)

Mot : - Tags -/belgique

Autres articles (41)

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

  • Ajouter des informations spécifiques aux utilisateurs et autres modifications de comportement liées aux auteurs

    12 avril 2011, par

    La manière la plus simple d’ajouter des informations aux auteurs est d’installer le plugin Inscription3. Il permet également de modifier certains comportements liés aux utilisateurs (référez-vous à sa documentation pour plus d’informations).
    Il est également possible d’ajouter des champs aux auteurs en installant les plugins champs extras 2 et Interface pour champs extras.

  • Possibilité de déploiement en ferme

    12 avril 2011, par

    MediaSPIP peut être installé comme une ferme, avec un seul "noyau" hébergé sur un serveur dédié et utilisé par une multitude de sites différents.
    Cela permet, par exemple : de pouvoir partager les frais de mise en œuvre entre plusieurs projets / individus ; de pouvoir déployer rapidement une multitude de sites uniques ; d’éviter d’avoir à mettre l’ensemble des créations dans un fourre-tout numérique comme c’est le cas pour les grandes plate-formes tout public disséminées sur le (...)

Sur d’autres sites (4933)

  • Revert "avcodec/nvenc : fix b-frame DTS behavior with fractional framerates"

    14 juin 2023, par Timo Rothenpieler
    Revert "avcodec/nvenc : fix b-frame DTS behavior with fractional framerates"

    This reverts commit 9a245bdf5d7860b8bc5e5c21a105a075925b719a.
    

    This commit basically broke all samples with fractional framerates,
    
rather than fixing them.
    
I at this point do not understand the original issue anymore, and I'm
    
not sure how this slipped my initial testing.
    
All my test samples must have happened to have a simple timebase.
    

    The actual dts values pretty much always are just a simple chain of
    
1,2,3,4,5,... Or maybe slightly bigger steps. Each increase by one means
    
an advance in time by one unit of the timebase.
    
So a fractional framerate/timebase is already not an issue.
    

    So with this patch applied, the calculation might end up substracting
    
huge values (1001 is a common one) from the dts, which would be an
    
offset of that many frames, not of that many fractions of a second.
    
This broke at least muxing into mp4, if the sample happened to have a
    
fractional framerate.
    

    I do not thing the original issue this patch tried to fix existed in the
    
first place, so it can be reverted without further consequences.
    • [DH] libavcodec/nvenc.c

  • Revert "avcodec/arm/hevc : remove duplicate mov of deblock neon"

    23 mars 2023, par Martin Storsjö
    Revert "avcodec/arm/hevc : remove duplicate mov of deblock neon"

    This reverts commit 9413bdc381112711a7beb6d6b8d8fc4b4ff6ca01.
    

    That commit broke the fate HEVC tests - unfortunately I only
    
tested checkasm for that patch, and that function is still
    
lacking checkasm coverage.
    

    Signed-off-by : Martin Storsjö <martin@martin.st>
    • [DH] libavcodec/arm/hevcdsp_deblock_neon.S

  • Controlling "Real-Time" sending rate in RTP Streaming with FFMpeg

    14 décembre 2020, par Robert_Ordis

    I'm trying to build an experimental audio telephony system with ffmpeg to talk some G.711 VoIP machine.

    &#xA;

    Then, I tried this command.

    &#xA;

    .\ffmpeg.exe -re -f dshow -i audio="CABLE Output (VB-Audio Virtual Cable)" -ac 1 -ab 64k -ar 8000 -f mulaw -f rtp "rtp://192.168.3.175:4449?fifo_size=240&amp;localrtpport=5100&amp;pkt_size=240"&#xA;

    &#xA;

    In WireShark capturing, the audio in each packets was actually divided in each around 30[ms].

    &#xA;

    However, 17- 18 packets was sent together once per 500[ms].

    &#xA;

    Sent audio was correct, but in this situation, an opponent machine can't treat this correctly.

    &#xA;

    How do I send these packets in per "UNDER 0.5 SEC" ?

    &#xA;

Navigation