Recherche avancée

Médias (91)

Autres articles (93)

  • Utilisation et configuration du script

    19 janvier 2011, par

    Informations spécifiques à la distribution Debian
    Si vous utilisez cette distribution, vous devrez activer les dépôts "debian-multimedia" comme expliqué ici :
    Depuis la version 0.3.1 du script, le dépôt peut être automatiquement activé à la suite d’une question.
    Récupération du script
    Le script d’installation peut être récupéré de deux manières différentes.
    Via svn en utilisant la commande pour récupérer le code source à jour :
    svn co (...)

  • Configuration spécifique d’Apache

    4 février 2011, par

    Modules spécifiques
    Pour la configuration d’Apache, il est conseillé d’activer certains modules non spécifiques à MediaSPIP, mais permettant d’améliorer les performances : mod_deflate et mod_headers pour compresser automatiquement via Apache les pages. Cf ce tutoriel ; mode_expires pour gérer correctement l’expiration des hits. Cf ce tutoriel ;
    Il est également conseillé d’ajouter la prise en charge par apache du mime-type pour les fichiers WebM comme indiqué dans ce tutoriel.
    Création d’un (...)

  • MediaSPIP Player : problèmes potentiels

    22 février 2011, par

    Le lecteur ne fonctionne pas sur Internet Explorer
    Sur Internet Explorer (8 et 7 au moins), le plugin utilise le lecteur Flash flowplayer pour lire vidéos et son. Si le lecteur ne semble pas fonctionner, cela peut venir de la configuration du mod_deflate d’Apache.
    Si dans la configuration de ce module Apache vous avez une ligne qui ressemble à la suivante, essayez de la supprimer ou de la commenter pour voir si le lecteur fonctionne correctement : /** * GeSHi (C) 2004 - 2007 Nigel McNie, (...)

Sur d’autres sites (3390)

  • avformat/matroskaenc : Actually apply timestamp offset for Opus

    31 août 2022, par Andreas Rheinhardt
    avformat/matroskaenc : Actually apply timestamp offset for Opus

    Matroska generally requires timestamps to be nonnegative, but
    
there is an exception : Data that corresponds to encoder delay
    
and is not supposed to be output anyway can have a negative
    
timestamp. This is achieved by using the CodecDelay header
    
field : The demuxer has to subtract this value from the raw
    
(nonnegative) timestamps of the corresponding track.
    
Therefore the muxer has to add this value first to write
    
this raw timestamp.
    

    Support for writing CodecDelay has been added in FFmpeg commit
    
d92b1b1babe69268971863649c225e1747358a74 and in Libav commit
    
a1aa37dd0b96710d4a17718198a3f56aea2040c1. The former simply
    
wrote the header field and did not apply any timestamp offsets,
    
leading to desynchronisation (if one uses multiple tracks).
    
The latter applied it at two places, but not at the one where
    
it actually matters, namely in mkv_write_block(), leading to
    
the same desynchronisation as with the former commit. It furthermore
    
used the wrong stream timebase to convert the delay to the
    
stream's timebase, as the conversion used the timebase from
    
before avpriv_set_pts_info().
    

    When the latter was merged in 82e4f39883932c1b1e5c7792a1be12dec6ab603d,
    
it was only done in a deactivated state that still did not
    
offset the timestamps when muxing due to "assertion failures
    
and av sync errors". a1aa37dd0b96710d4a17718198a3f56aea2040c1
    
made it definitely more likely to run into assertion failures
    
(namely if the relative block timestamp doesn't fit into an int16_t).
    

    Yet all of the above issues have been fixed (in commits
    
962d63157322466a9a82f9f9d84c1b6f1b582f65,
    
5d3953a5dcfd5f71391b7f34908517eb6f7e5146 and
    
4ebeab15b037a21f195696cef1f7522daf42f3ee. This commit therefore
    
enables applying CodecDelay, fixing ticket #7182.
    

    There is just one slight regression from this : If one has input
    
with encoder delay where the first timestamp is negative, but
    
the pts of the part of the data that is actually intended to be
    
output is nonnegative, then the timestamps will currently by default
    
be shifted to make them nonnegative before they reach the muxer ;
    
the muxer will then ensure that the shifted timestamps are retained.
    
Before this commit, the muxer did not ensure this ; instead the
    
timestamps that the demuxer will output were shifted and
    
if the first timestamp of the actually intended output was zero
    
before shifting, then this unintentional shift just cancels
    
the shift performed before the packet reached the muxer.
    
(But notice that this only applies if all the tracks use the same
    
CodecDelay, or the relative sync between tracks will be impaired.)
    
This happens in the matroska-opus-remux and matroska-ogg-opus-remux
    
FATE tests. Future commits will forward the information that
    
the Matroska muxer has a limited capability to handle negative
    
timestamps so that the shifting in libavformat can take advantage
    
of it.
    

    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
    • [DH] libavformat/matroskaenc.c
    • [DH] tests/ref/fate/matroska-ogg-opus-remux
    • [DH] tests/ref/fate/matroska-opus-remux

  • how to apply video filter in ffserver live streaming

    28 mai 2015, par Razack

    We are live streaming from camera in to ffserver through ffmpeg. We are converting the live streaming into side by side (SBS) using ffmpeg stereo3d filter. we have no problem getting the required output directly playing in MPlayer. When we stream through FFServer into a player what we get is not side by side but a single.
    ffmpeg -i source.mp4 -vf stereo3d=sbsl:abl http://x.x.x.x:8090/feed1.ffm
    Thanks for your help

  • vulkan : only apply shortcut for next context selection if selection has a submission

    23 novembre 2024, par Lynne
    vulkan : only apply shortcut for next context selection if selection has a submission
    • [DH] libavutil/vulkan.c

Navigation