Recherche avancée

Médias (0)

Mot : - Tags -/xmlrpc

Aucun média correspondant à vos critères n’est disponible sur le site.

Autres articles (34)

  • 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 ;

  • Diogene : création de masques spécifiques de formulaires d’édition de contenus

    26 octobre 2010, par

    Diogene est un des plugins ? SPIP activé par défaut (extension) lors de l’initialisation de MediaSPIP.
    A quoi sert ce plugin
    Création de masques de formulaires
    Le plugin Diogène permet de créer des masques de formulaires spécifiques par secteur sur les trois objets spécifiques SPIP que sont : les articles ; les rubriques ; les sites
    Il permet ainsi de définir en fonction d’un secteur particulier, un masque de formulaire par objet, ajoutant ou enlevant ainsi des champs afin de rendre le formulaire (...)

  • Librairies et binaires spécifiques au traitement vidéo et sonore

    31 janvier 2010, par

    Les logiciels et librairies suivantes sont utilisées par SPIPmotion d’une manière ou d’une autre.
    Binaires obligatoires FFMpeg : encodeur principal, permet de transcoder presque tous les types de fichiers vidéo et sonores dans les formats lisibles sur Internet. CF ce tutoriel pour son installation ; Oggz-tools : outils d’inspection de fichiers ogg ; Mediainfo : récupération d’informations depuis la plupart des formats vidéos et sonores ;
    Binaires complémentaires et facultatifs flvtool2 : (...)

Sur d’autres sites (3833)

  • How can I remove silence from an MP3 programmatically ?

    27 mars, par Benjamin Oakes

    I have MP3 files that sometimes have silence at the end. I would like to remove this silence automatically. From what I can tell, it is "perfect" silence (0 amplitude), not background noise. The length of the content and the silence varies.

    



    I found some other questions about cropping to the first 30 seconds or cropping to X and X+N seconds using ffmpeg. I would think I could use a similar approach, as long as I have a way to find when the silence starts. How would I do that programatically ?

    



    For example, one possible solution would be to have a command that finds the beginning of the "silence". I'd expect a sequence like this

    



    end=$(ffmpeg some-command-to-find-start-of-silence)
ffmpeg -t "$end" -acodec copy -i inputfile.mp3 outputfile.mp3


    



    The solution does not have to use ffmpeg, but it does need to be available on Ubuntu.

    


  • Duplicated PTS value when using rtsp transport UDP (H264 FU-A)

    25 janvier, par Christoph

    I’m implementing a packet loss counter based on the PTS from the av_packet, and it works fine when using RTSP/TCP as the transport mode. However, when I switched to RTSP/UDP, two packets consistently share the same PTS. This puzzled me because I assumed that av_read_frame would parse the stream and provide "valid" packets.

    


    In both cases, the stream is FU-A H.264, and I expected FFmpeg to handle reassembly in both transport modes identically. My understanding was that if UDP packets were splitted, FFmpeg would reassemble them into a single av_packet, similar to how it handles reassembly for TCP packets split due to MTU and FU-A.

    


    I could adapt my packet loss calculation by simply ignoring packets with the same PTS as the previous one, but I want to understand what’s happening here.

    


    TCP

    


    packet pts: -9223372036854775808, dts: -9223372036854775808, size: 52672, key-frame: true, discard: false, corrupt: false
packet pts: 3598, dts: 3598, size: 6034, key-frame: false, discard: false, corrupt: false
packet pts: 7196, dts: 7196, size: 5730, key-frame: false, discard: false, corrupt: false
packet pts: 10794, dts: 10794, size: 6153, key-frame: false, discard: false, corrupt: false
packet pts: 14392, dts: 14392, size: 2269, key-frame: false, discard: false, corrupt: false
packet pts: 17989, dts: 17989, size: 2656, key-frame: false, discard: false, corrupt: false
packet pts: 21587, dts: 21587, size: 2659, key-frame: false, discard: false, corrupt: false


    


    UDP

    


    packet pts: -9223372036854775808, dts: -9223372036854775808, size: 1391, key-frame: true, discard: false, corrupt: false
packet pts: 0, dts: 0, size: 109265, key-frame: true, discard: false, corrupt: false
packet pts: 3598, dts: 3598, size: 878, key-frame: false, discard: false, corrupt: false
packet pts: -> 3598, dts: 3598, size: 7728, key-frame: false, discard: false, corrupt: false
packet pts: 7195, dts: 7195, size: 887, key-frame: false, discard: false, corrupt: false
packet pts: -> 7195, dts: 7195, size: 7149, key-frame: false, discard: false, corrupt: false
packet pts: 10793, dts: 10793, size: 795, key-frame: false, discard: false, corrupt: false
packet pts: -> 10793, dts: 10793, size: 7777, key-frame: false, discard: false, corrupt: false
packet pts: 14391, dts: 14391, size: 119, key-frame: false, discard: false, corrupt: false
packet pts: -> 14391, dts: 14391, size: 2075, key-frame: false, discard: false, corrupt: false


    


    For reference here my code

    


    // PackageLossDetection detects possible packet loss based on PTS (Presentation Time Stamp) values.
// It compares the PTS of the packet with the expected PTS, calculated using the stream's time base and average frame rate.
// If the deviation between the expected and actual PTS exceeds a defined tolerance.
//
// Parameters:
//   - pkt: incoming packet whose PTS is to be checked.
//   - stream: the stream containing time base and average frame rate information.
func (s *AvSource) PackageLossDetection(pkt *astiav.Packet, stream *astiav.Stream) {

    // When using UDP as RTSP Transport packages in tuple has same PTS
    // TODO: Maybe we should invest more time to find a better solution
    if s.lastPts == pkt.Pts() {
        return
    }

    if pkt.Pts() > 0 {

        const tolerance = 4 // Allowable deviation in PTS steps
        if stream.AvgFrameRate().Num() == 0 {
            s.log.Warn().Str("stream", s.stream.Name).Msg("PackageLossDetection, no frame rate information available")
            return
        }

        var ptsBetween = stream.TimeBase().Den() * stream.TimeBase().Num() / stream.AvgFrameRate().Num()
        if math.Abs(float64(pkt.Pts()-(s.lastPts+int64(ptsBetween)))) > tolerance {
            s.log.Warn().Str("stream", s.stream.Name).Msgf("PackageLossDetection, PTS steps: %d, expected: %d, got: %d", int(ptsBetween), s.lastPts+int64(ptsBetween), pkt.Pts())
            utils.SafeIncrementInt64(&s.metrics.LossCount)
        }

        s.lastPts = pkt.Pts()
    }
}


    


  • avcodec/aarch64/opusdsp_neon : Simplify opus_postfilter_neon

    7 février, par Krzysztof Pyrkosz
    avcodec/aarch64/opusdsp_neon : Simplify opus_postfilter_neon
    

    This change removes one extra floating point operation and simplifies
    load operations at the beginning of the loop by using dedicated register
    for each of the 5 pointers and interleaving it with calculations. The
    first case seems to be a bit slower, but the performance increase is
    substantial in the other two.

    A78 before :
    postfilter_15_neon : 1684.8 ( 4.23x)
    postfilter_512_neon : 1395.5 ( 5.10x)
    postfilter_1022_neon : 1357.0 ( 5.25x)

    After :
    postfilter_15_neon : 1742.2 ( 4.09x)
    postfilter_512_neon : 1169.8 ( 6.09x)
    postfilter_1022_neon : 1160.0 ( 6.12x)

    A72 before :
    postfilter_15_neon : 3144.8 ( 2.39x)
    postfilter_512_neon : 3141.2 ( 2.39x)
    postfilter_1022_neon : 3230.0 ( 2.33x)

    After :
    postfilter_15_neon : 2847.8 ( 2.64x)
    postfilter_512_neon : 2877.8 ( 2.61x)
    postfilter_1022_neon : 2837.2 ( 2.65x)

    x13s before :
    postfilter_15_neon : 1615.4 ( 2.61x)
    postfilter_512_neon : 963.1 ( 4.39x)
    postfilter_1022_neon : 963.6 ( 4.39x)

    After :
    postfilter_15_neon : 1749.6 ( 2.41x)
    postfilter_512_neon : 707.1 ( 5.97x)
    postfilter_1022_neon : 706.1 ( 5.99x)

    Signed-off-by : Martin Storsjö <martin@martin.st>

    • [DH] libavcodec/aarch64/opusdsp_neon.S