Recherche avancée

Médias (91)

Autres articles (30)

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

  • Publier sur MédiaSpip

    13 juin 2013

    Puis-je poster des contenus à partir d’une tablette Ipad ?
    Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir

  • Contribute to documentation

    13 avril 2011

    Documentation is vital to the development of improved technical capabilities.
    MediaSPIP welcomes documentation by users as well as developers - including : critique of existing features and functions articles contributed by developers, administrators, content producers and editors screenshots to illustrate the above translations of existing documentation into other languages
    To contribute, register to the project users’ mailing (...)

Sur d’autres sites (7078)

  • 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