Recherche avancée

Médias (0)

Mot : - Tags -/alertes

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

Autres articles (17)

  • XMP PHP

    13 mai 2011, par

    Dixit Wikipedia, XMP signifie :
    Extensible Metadata Platform ou XMP est un format de métadonnées basé sur XML utilisé dans les applications PDF, de photographie et de graphisme. Il a été lancé par Adobe Systems en avril 2001 en étant intégré à la version 5.0 d’Adobe Acrobat.
    Étant basé sur XML, il gère un ensemble de tags dynamiques pour l’utilisation dans le cadre du Web sémantique.
    XMP permet d’enregistrer sous forme d’un document XML des informations relatives à un fichier : titre, auteur, historique (...)

  • Les formats acceptés

    28 janvier 2010, par

    Les commandes suivantes permettent d’avoir des informations sur les formats et codecs gérés par l’installation local de ffmpeg :
    ffmpeg -codecs ffmpeg -formats
    Les format videos acceptés en entrée
    Cette liste est non exhaustive, elle met en exergue les principaux formats utilisés : h264 : H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 m4v : raw MPEG-4 video format flv : Flash Video (FLV) / Sorenson Spark / Sorenson H.263 Theora wmv :
    Les formats vidéos de sortie possibles
    Dans un premier temps on (...)

  • Gestion générale des documents

    13 mai 2011, par

    MédiaSPIP ne modifie jamais le document original mis en ligne.
    Pour chaque document mis en ligne il effectue deux opérations successives : la création d’une version supplémentaire qui peut être facilement consultée en ligne tout en laissant l’original téléchargeable dans le cas où le document original ne peut être lu dans un navigateur Internet ; la récupération des métadonnées du document original pour illustrer textuellement le fichier ;
    Les tableaux ci-dessous expliquent ce que peut faire MédiaSPIP (...)

Sur d’autres sites (5075)

  • Evolution #3751 : Ajouter le support du SNI au proxy connect

    24 août 2017, par - Equipement

    Je viens d’effectuer un test (en PHP 5.6) avec la version SPIP SVN du 24/08/2017. Lorsque je clique sur le bouton "Essayer le proxy", il n’y a plus de message d’erreur.
    Merci d’avoir résolu ce problème.

  • x264 encoding taking longer when encoding static frames (than

    14 septembre 2015, par Danilo

    ​Hi,
    I’m using x264 for live video streaming and I’ve noticed that the thread
    responsible for encoding uses ​​more cpu (sometimes 50% more with 1920x1080) when the video stream is frozen (i.e. : camera is sending the same frame over an over again) or when I make it encode the same image over and over again.

    This seems somewhat counter intuitive to me, as I would expect x264 to use
    more processing power when encoding complex scenes other then static ones.

    My encoder settings are the following :

    1280x720 fps=25/1 timebase=0/0 bitdepth=8 cabac=0 ref=1 deblock=1:0:0 analyse=0x3:0x113
    
me=hex subme=2 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1
    
8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=1 lookahead_threads=0
    
sliced_threads=0 slice_max_size=1190 nr=60 decimate=1 interlaced=0 bluray_compat=0
    
constrained_intra=0 bframes=0 weightp=0  keyint=1200 keyint_min=120 scenecut=40
    
intra_refresh=0 rc_lookahead=0 rc=crf mbtree=0 crf=24.0 qcomp=0.60 qpmin=0 qpmax=69
    
qpstep=4 vbv_maxrate=1024 vbv_bufsize=350 crf_max=35.0 nal_hrd=none

    I created a github gist based on the example.c encoder bundled in x264’s
    source code and tested encoding times with it. (You can find it here :
    https://gist.github.com/danilogr/ab4976ff4e0831ab274b)

    Average encoding time for the static scene is 38% bigger than for a scene
    with movements. (You can find my test case and also the output from my test
    encoder on the link above).

    ​​
    ​I’ve also noticed that by setting ​​scenecut=0, subme=0, trellis=0 and me=dia I can get rid of this problem​, but with noticeable quality​ decrease.

    ​
    ​Could anyone, please, shed some light on the reasons for this odd behavior ?
    ​Also, what can be done in order to avoid this situation without a major decrease in quality ?​

  • x264 encoding taking longer when encoding static frames (than

    14 septembre 2015, par Danilo

    ​Hi,
    I’m using x264 for live video streaming and I’ve noticed that the thread
    responsible for encoding uses ​​more cpu (sometimes 50% more with 1920x1080) when the video stream is frozen (i.e. : camera is sending the same frame over an over again) or when I make it encode the same image over and over again.

    This seems somewhat counter intuitive to me, as I would expect x264 to use
    more processing power when encoding complex scenes other then static ones.

    My encoder settings are the following :

    1280x720 fps=25/1 timebase=0/0 bitdepth=8 cabac=0 ref=1 deblock=1:0:0 analyse=0x3:0x113
    
me=hex subme=2 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1
    
8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=1 lookahead_threads=0
    
sliced_threads=0 slice_max_size=1190 nr=60 decimate=1 interlaced=0 bluray_compat=0
    
constrained_intra=0 bframes=0 weightp=0  keyint=1200 keyint_min=120 scenecut=40
    
intra_refresh=0 rc_lookahead=0 rc=crf mbtree=0 crf=24.0 qcomp=0.60 qpmin=0 qpmax=69
    
qpstep=4 vbv_maxrate=1024 vbv_bufsize=350 crf_max=35.0 nal_hrd=none

    I created a github gist based on the example.c encoder bundled in x264’s
    source code and tested encoding times with it. (You can find it here :
    https://gist.github.com/danilogr/ab4976ff4e0831ab274b)

    Average encoding time for the static scene is 38% bigger than for a scene
    with movements. (You can find my test case and also the output from my test
    encoder on the link above).

    ​​
    ​I’ve also noticed that by setting ​​scenecut=0, subme=0, trellis=0 and me=dia I can get rid of this problem​, but with noticeable quality​ decrease.

    ​
    ​Could anyone, please, shed some light on the reasons for this odd behavior ?
    ​Also, what can be done in order to avoid this situation without a major decrease in quality ?​

Navigation