Recherche avancée

Médias (1)

Mot : - Tags -/bug

Autres articles (85)

  • MediaSPIP 0.1 Beta version

    25 avril 2011, par

    MediaSPIP 0.1 beta is the first version of MediaSPIP proclaimed as "usable".
    The zip file provided here only contains the sources of MediaSPIP in its standalone version.
    To get a working installation, you must manually install all-software dependencies on the server.
    If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...)

  • MediaSPIP version 0.1 Beta

    16 avril 2011, par

    MediaSPIP 0.1 beta est la première version de MediaSPIP décrétée comme "utilisable".
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Pour avoir une installation fonctionnelle, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
    Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)

  • Le profil des utilisateurs

    12 avril 2011, par

    Chaque utilisateur dispose d’une page de profil lui permettant de modifier ses informations personnelle. Dans le menu de haut de page par défaut, un élément de menu est automatiquement créé à l’initialisation de MediaSPIP, visible uniquement si le visiteur est identifié sur le site.
    L’utilisateur a accès à la modification de profil depuis sa page auteur, un lien dans la navigation "Modifier votre profil" est (...)

Sur d’autres sites (8009)

  • ffmpeg output seeking not accurate even after -i [closed]

    3 septembre 2023, par hl037_

    In the documentation of ffmpeg, it is stated that if -ss is passed after -i, then it is frame accurate (Other questions are for -ss before -i).

    


    Here is my command :

    


    ffmpeg -i vid.mkv -ss 53 -codec copy test.mkv -y 


    


    However, it is still not accurate, and seems to jump to the nearest keyframe. Am i missing something ?

    


    Note : the problem only occurs when the video steam is copied. If reencoded or discarded, it works as expected

    


    Note2 (As I am doing other tries) : There are also strange things with audio :

    


    ffmpeg -i vid.mkv -ss 53 -codec copy test1.mkv -y 
ffmpeg -i vid.mkv -ss 54 -codec copy test2.mkv -y 
ffmpeg -i test1.mkv -vn -c:a copy test1a.mkv -y
ffmpeg -i test2.mkv -vn -c:a copy test2a.mkv -y


    


      

    • test1.mkv is reported to be the right lenght, but the first frame correspond to the frame at 0:50 in original (end is good)
    • 


    • test2.mkv is reported to be the right lenght, but the first frame correspond to the frame at 0:55 in original (end is good)
    • 


    • test1a.mkv is the expected audio (starts at 0:53 of the original)
    • 


    • test2a.mkv is the expected audio (starts at 0:54 of the original)
    • 


    


  • Tour of Part of the VP8 Process

    18 novembre 2010, par Multimedia Mike — VP8

    My toy VP8 encoder outputs a lot of textual data to illustrate exactly what it’s doing. For those who may not be exactly clear on how this or related algorithms operate, this may prove illuminating.

    Let’s look at subblock 0 of macroblock 0 of a luma plane :

     subblock 0 (original)
      92  91  89  86
      91  90  88  86
      89  89  89  88
      89  87  88  93
    

    Since it’s in the top-left corner of the image to be encoded, the phantom samples above and to the left are implicitly 128 for the purpose of intra prediction (in the VP8 algorithm).

     subblock 0 (original)
         128 128 128 128
     128  92  91  89  86
     128  91  90  88  86
     128  89  89  89  88
     128  89  87  88  93
    


    Using the 4×4 DC prediction mode means averaging the 4 top predictors and 4 left predictors. So, the predictor is 128. Subtract this from each element of the subblock :

     subblock 0, predictor removed
     -36 -37 -39 -42
     -37 -38 -40 -42
     -39 -39 -39 -40
     -39 -41 -40 -35
    

    Next, run the subblock through the forward transform :

     subblock 0, transformed
     -312   7   1   0
        1  12  -5   2
        2  -3   3  -1
        1   0  -2   1
    

    Quantize (integer divide) each element ; the DC (first element) and AC (rest of the elements) quantizers are both 4 :

     subblock 0, quantized
     -78   1   0   0
       0   3  -1   0
       0   0   0   0
       0   0   0   0
    

    The above block contains the coefficients that are actually transmitted (zigzagged and entropy-encoded) through the bitstream and decoded on the other end.

    The decoding process looks something like this– after the same coefficients are decoded and rearranged, they are dequantized (multiplied) by the original quantizers :

     subblock 0, dequantized
     -312   4   0   0
        0  12  -4   0
        0   0   0   0
        0   0   0   0
    

    Note that these coefficients are not exactly the same as the original, pre-quantized coefficients. This is a large part of where the “lossy” in “lossy video compression” comes from.

    Next, the decoder generates a base predictor subblock. In this case, it’s all 128 (DC prediction for top-left subblock) :

     subblock 0, predictor
      128 128 128 128
      128 128 128 128
      128 128 128 128
      128 128 128 128
    

    Finally, the dequantized coefficients are shoved through the inverse transform and added to the base predictor block :

     subblock 0, reconstructed
      91  91  89  85
      90  90  89  87
      89  88  89  90
      88  88  89  92
    

    Again, not exactly the same as the original block, but an incredible facsimile thereof.

    Note that this decoding-after-encoding demonstration is not merely pedagogical– the encoder has to decode the subblock because the encoding of successive subblocks may depend on this subblock. The encoder can’t rely on the original representation of the subblock because the decoder won’t have that– it will have the reconstructed block.

    For example, here’s the next subblock :

     subblock 1 (original)
      84  84  87  90
      85  85  86  93
      86  83  83  89
      91  85  84  87
    

    Let’s assume DC prediction once more. The 4 top predictors are still all 128 since this subblock lies along the top row. However, the 4 left predictors are the right edge of the subblock reconstructed in the previous example :

     subblock 1 (original)
        128 128 128 128
     85  84  84  87  90
     87  85  85  86  93
     90  86  83  83  89
     92  91  85  84  87
    

    The DC predictor is computed as (128 + 128 + 128 + 128 + 85 + 87 + 90 + 92 + 4) / 8 = 108 (the extra +4 is for rounding considerations). (Note that in this case, using the original subblock’s right edge would also have resulted in 108, but that’s beside the point.)

    Continuing through the same process as in subblock 0 :

     subblock 1, predictor removed
     -24 -24 -21 -18
     -23 -23 -22 -15
     -22 -25 -25 -19
     -17 -23 -24 -21
    

    subblock 1, transformed
    -173 -9 14 -1
    2 -11 -4 0
    1 6 -2 3
    -5 1 0 1

    subblock 1, quantized
    -43 -2 3 0
    0 -2 -1 0
    0 1 0 0
    -1 0 0 0

    subblock 1, dequantized
    -172 -8 12 0
    0 -8 -4 0
    0 4 0 0
    -4 0 0 0

    subblock 1, predictor
    108 108 108 108
    108 108 108 108
    108 108 108 108
    108 108 108 108

    subblock 1, reconstructed
    84 84 87 89
    86 85 87 91
    86 83 84 89
    90 85 84 88

    I hope this concrete example (straight from a working codec) clarifies this part of the VP8 process.

  • Replace part of a video (without replacing the audio) in ffmpeg [closed]

    13 février 2021, par Real Noob

    I have a video file that is divided into three different sections. I want to replace the middle part of this video with another clip. However, I still want to keep the audio of the original video. Can I do that in ffmpeg ?

    


    Here are my requirements :

    


      

    1. Original Video is 60 seconds long.
    2. 


    3. The part I want to replace is from 25 to 45 seconds.
    4. 


    5. I want to keep the original audio from 25 to 45 seconds and just replace the visual part with some other clip.
    6. 


    7. The generated video will also be 60 seconds long. However, it will have the new video from 25 to 45 seconds.
    8. 


    


    Thanks.