Recherche avancée

Médias (1)

Mot : - Tags -/ticket

Autres articles (24)

  • 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

  • La sauvegarde automatique de canaux SPIP

    1er avril 2010, par

    Dans le cadre de la mise en place d’une plateforme ouverte, il est important pour les hébergeurs de pouvoir disposer de sauvegardes assez régulières pour parer à tout problème éventuel.
    Pour réaliser cette tâche on se base sur deux plugins SPIP : Saveauto qui permet une sauvegarde régulière de la base de donnée sous la forme d’un dump mysql (utilisable dans phpmyadmin) mes_fichiers_2 qui permet de réaliser une archive au format zip des données importantes du site (les documents, les éléments (...)

  • Submit bugs and patches

    13 avril 2011

    Unfortunately a software is never perfect.
    If you think you have found a bug, report it using our ticket system. Please to help us to fix it by providing the following information : the browser you are using, including the exact version as precise an explanation as possible of the problem if possible, the steps taken resulting in the problem a link to the site / page in question
    If you think you have solved the bug, fill in a ticket and attach to it a corrective patch.
    You may also (...)

Sur d’autres sites (6463)

  • ffmpeg - put video atop of second and center it while keeping aspect ratio

    25 août 2022, par artolini

    I'm trying to put 16:9 video atop of same blurred 1:1 video just like on the photos.
I'm looking a wise guy with ffmpeg knowledge to help me with think of about the command which will :

    


      

    1. rescale 16:9 (sharp video) accordingly to blurred one height (keeping the width automatically to ratio)
    2. 


    3. center the 16:9 (sharp video) to x position = (blurredVideoWidth / 2) - (sharpVideoWidth / 2)
    4. 


    


    My current comment looks like this :

    


    ffmpeg -y -i ${squareBlurredVideoUri} -i ${square169VideoUri} -filter_complex "[1:v]scale=620:-1[v2];[0:v][v2]overlay=0:0" -codec:a copy ${squareFinalVideoUri}

    


    As you can see scale is hardcoded to 620 which is wrong because we should rescale it accordingly to blurred video height.

    


    Overlay is set to 0:0 which places sharp video to x = 0 and y = 0 and should center it

    


    Thank you in advance.

    


    Current result :
current
Desired result :
desired

    


  • Python Matplotlib Basemap animation with FFMpegwriter stops after 820 Frames ?

    5 août 2013, par cpaulik

    If I run the following code it just stops after 820 Frames. I tested this on both a Ubuntu 12.04 VM and on Linux Mint 15. Unfortunately there is no error message. The program just hangs after printing 2012-06-02T16:54:00

    import os, sys
    import matplotlib.pyplot as plt
    from mpl_toolkits.basemap import Basemap
    import matplotlib.animation as animation
    from datetime import datetime,timedelta

    def animation_test(start,end,fps=10,save_path='/home/username/animation_test/',\
    save_name="test.mp4",dpi=80):

       step = timedelta(minutes = 3)

       current = start

       dates =[]

       frame = 0

       while current <=end:
           dates.append(current)
           current += step

       fig = plt.figure(figsize=(16,9),facecolor='k',edgecolor='k')
       ax = fig.add_subplot(111)

       metadata = dict(title='Movie Test', artist='Matplotlib',
               comment='Movie support!')
       writer = animation.FFMpegWriter(fps=fps, metadata=metadata,bitrate=20000)

       direction = -0.5
       lat_current = 0
       lon_current = 0

       with writer.saving(fig,os.path.join(save_path,save_name),dpi):

           for current in dates:

               ax.cla()
               if direction > 0 and lat_current > 40 or \
                      direction < 0 and lat_current < -40:
                       direction = - direction

               lat_current = lat_current + direction
               lon_current = lon_current - 0.75
               if lon_current < -180 :
                   lon_current += 360
               basem = Basemap(projection='ortho', lat_0=lat_current, lon_0=lon_current, resolution='l',ax=ax)
               basem.drawcoastlines()

               #plt.show()

               plt.savefig(os.path.join(save_path, 'frame%d.png'%frame),
                   dpi=dpi,facecolor='w',edgecolor='k')

               writer.grab_frame()
               frame += 1
               print current.isoformat()

    start = datetime.now()
    animation_test(datetime(2012,6,1,0,0,0),datetime(2012,6,4,0,0,0),fps=10,dpi=80)
    print datetime.now() - start

    To explain the code a little bit :
    I want to make an animation of satellite data which comes in small 3 minute files and show it on a rotating globe. This is why I chose to make the loop in the following example code step through the animation in 3 minute steps. I just removed the reading and plotting of the satellite data in order to make the code executable by anyone.

    When I removed basemap from the program and just plotted a scatterplot of random data the program ran all the way through.

    I'm not sure but I don't think that it is a memory issue since my RAM is only utilized approx. 20% while the program is running.

    Thanks for any help in getting to the bottom of this.

  • Revision cdffeaaae0 : Add mode info arrays and mode info index. In non frame-parallel decoding, this

    10 juin 2014, par hkuang

    Changed Paths :
     Modify /vp9/common/vp9_alloccommon.c


     Modify /vp9/common/vp9_onyxc_int.h



    Add mode info arrays and mode info index.

    In non frame-parallel decoding, this works the same way as
    current decoding scheme. Every time after decoder finish
    decoding a frame, it will swap the current mode info pointer
    and previous mode info pointer if the decoded frame needs
    to be shown. Both mode info pointer and previous mode info
    pointer are from mode info arrays.

    In frame-parallel decoding, this will become more complicated
    as current frame’s mode info pointer will be shared with next
    frame as previous mode info pointer. But when one decoder
    thread finishes decoding one frame and starts to work on next
    available frame, it needs to retain the decoded frame’s mode
    info pointers until next frame finishes decoding. The mode info
    index will serve this purpose. The decoder will use different
    buffer in the mode info arrays and use the other buffer to save
    previous decoded frame’s mode info.

    Change-Id : If11d57d8eb0ee38c8876158e5482177fcb229428