Recherche avancée

Médias (2)

Mot : - Tags -/doc2img

Autres articles (112)

  • Mise à jour de la version 0.1 vers 0.2

    24 juin 2013, par

    Explications des différents changements notables lors du passage de la version 0.1 de MediaSPIP à la version 0.3. Quelles sont les nouveautés
    Au niveau des dépendances logicielles Utilisation des dernières versions de FFMpeg (>= v1.2.1) ; Installation des dépendances pour Smush ; Installation de MediaInfo et FFprobe pour la récupération des métadonnées ; On n’utilise plus ffmpeg2theora ; On n’installe plus flvtool2 au profit de flvtool++ ; On n’installe plus ffmpeg-php qui n’est plus maintenu au (...)

  • Personnaliser en ajoutant son logo, sa bannière ou son image de fond

    5 septembre 2013, par

    Certains thèmes prennent en compte trois éléments de personnalisation : l’ajout d’un logo ; l’ajout d’une bannière l’ajout d’une image de fond ;

  • Ecrire une actualité

    21 juin 2013, par

    Présentez les changements dans votre MédiaSPIP ou les actualités de vos projets sur votre MédiaSPIP grâce à la rubrique actualités.
    Dans le thème par défaut spipeo de MédiaSPIP, les actualités sont affichées en bas de la page principale sous les éditoriaux.
    Vous pouvez personnaliser le formulaire de création d’une actualité.
    Formulaire de création d’une actualité Dans le cas d’un document de type actualité, les champs proposés par défaut sont : Date de publication ( personnaliser la date de publication ) (...)

Sur d’autres sites (8452)

  • Path to publish FFMPEG video files to Azure Blob Storage ?

    25 janvier 2016, par CG-Guy

    Please kindly help me get out of a bad situation with a very very unhappy client. I am using FFMPEG based app to publish video files to Azure Blob storage, but the files are not going through the network. FFMPEG app has full access to firewall ports. FFMPEG communication shell show files are published without errors. A look at TCP connections shows the app is making connection with Azure account remote address 104.208.XXX.XX and remote port 443. However, it drops the connection and starts repeating attempts over and over. It will then time out after countless attempts and crash the app. Here is my publish point. Is this the correct publish point for this kind of connection ? What is the proper connection string ? :

    https://account-name.blob.core.windows.net/video/video.flv /DestKey :account-storage-key

    I have also tried http:// without success. Same thing happens. It attempts connecting to remote address and port 80. Again, after several attempts it will timeout and crash. System is a Server 2008 R2 unit on-site, not VM. Your help is much appreciated. Thanks a lot !

  • How to upload files to Azure Blob Stotage like FTP ?

    25 janvier 2016, par CG-Guy

    I am able to upload files from my ffmpeg app to an FTP using this path :

    ftp://[user:password]@server[:port]/MyFolder/video/video.flv

    How do I achieve the same thing in Azure Blob ? I have tried this path :

    https://[account-name].blob.core.windows.net/video/video.flv /DestKey:[account-storage-key]

    But that doesn’t seem to work. TCP connection shows the app is making a connection with the Azure account to the remote address 104.208.XXX.XX and remote port 443. However, it drops the connection and starts attempts to reconnect repeatedly. It will then time out after countless attempts and crash the app. I have also tried /> without success. The same thing happens. It attempts connecting to the remote address and port 80.

    The FFMPEG app has full access to firewall ports and the app communication shell show files are published without errors. System is a Server 2008 R2 unit on-site, not VM.

  • dnxhddec : Decode and use interlace mb flag

    26 septembre 2015, par Christophe Gisquet
    dnxhddec : Decode and use interlace mb flag

    This bit is 1 in some samples, and seems to coincide with interlaced
    
mbs and CID1260. 2008 specs do not know about it, and maintain qscale
    
is 11 bits. This looks oversized, but may help larger bitdepths.
    

    Currently, it leads to an obviously incorrect qscale value, meaning
    
its syntax is shifted by 1. However, reading 11 bits also leads to
    
obviously incorrect decoding : qscale seems to be 10 bits.
    

    However, as most profiles still have 11bits qscale, the feature is
    
restricted to the CID1260 profile (this flag is dependent on
    
a higher-level flag located in the header).
    

    The encoder writes 12 bits of syntax, last and first bits always 0,
    
which is now somewhat inconsistent with the decoder, but ends up with
    
the same effect (progressive + reserved bit).
    

    Signed-off-by : Vittorio Giovara <vittorio.giovara@gmail.com>
    • [DH] libavcodec/dnxhddec.c

Navigation