Recherche avancée

Sur d’autres sites (11731)

• FFMPEG : Is defining a context for a codec compulsary ?

  28 novembre 2013, par sam

  I'm having a a decoder code. I'm trying to integrate it into ffmpeg framework.

  I'm referring to the HOW TO given here : http://wiki.multimedia.cx/index.php?title=FFmpeg_codec_howto

  According to that article i need to define a structure in my decoder_name.c file.

  The example structure is shown below :

  AVCodec sample_decoder =
  
  {
  
      .name           = "sample",
  
      .type           = AVCODEC_TYPE_VIDEO,
  
      .id             = AVCODEC_ID_SAMPLE,
  
     // .priv_data_size = sizeof(COOKContext),
  
      .init           = sample_decode_init,
  
      .close          = sample_decode_close,
  
      .decode         = sample_decode_frame,
  
  };

  Where,

  .name -> specifies the short name of my decoder.
  
  
  
  .type -> is used to specify that it is a video decoder.
  
  
  
  .id -> is an unique id that i'm assigning to my video decoder.
  
  
  
  .init -> is a function pointer to the function in my decoder code that performs decoder related initializations
  
  
  
  .decode -> is a function pointer to the function in my decoder code that decodes a single frame, given the input data (elementary stream).
  
  
  
  .close -> is a function pointer to the function in my decoder that frees all allocated memory i.e. the memory allocated in init.

  However, my doubt is according to the above mentioned article, there is another field called .priv_data_size which hold the size of some context.

  Is it compulsory to have this field .priv_data_size because according to the above article, i need not define all the parameters of the structure AVCodec. Further i do not possess any such context for my decoder.

  However, when i go through the code of other available decoders in libavcodec of ffmpeg, i find that every decoder has defined this. Will my decoder work if i do not specify this ? I'm unable to proceed because of this. please provide some guidance regrading the same.

  —Thanks in advance.

• How to efficiently create H264 mpeg from two clips with known different motion intensity ?

  14 février 2017, par Serge

  Given an audio and an image we create a static image "video" and then append a short clip that has a rather intense motion.

  Audio and image varies from run to run. Appended animation is always the same. Rendering is done with ffmpeg on a remote server. Rendered file must be in h264 codec mpg.

  Speed of encoding is crucial. Is there a fast and effective way to generate and merge the two clips quickly ?

  Atm we use the following ffmpeg commands :

  // create first clip from image
  
  ffmpeg -loop 1 -r 24 -i $IMAGE -i $AUDIO -t $AUDIO_LENGTH -c:a aac -profile:a aac_low -ar 48000 -b:a 192k -bsf:a aac_adtstoasc -strict -2 -y -c:v libx264 -profile:v high -preset veryfast  -tune stillimage -crf 24 -x264opts bframes=2 -pix_fmt yuv420p -safe 0  clip1.mpg
  
  // . . .
  
  // then append the animation
  
  ffmpeg -f concat -safe 0 -i list.txt -c copy -y -safe 0 final.mpg 

  Intuition is that we can benefit form knowing exact timing of a first clip with a static image and the second one with intense animation – like it is determined in the 1-st pass of a 2-pass compression.

  Someone experienced in tech of h264 codec and mpeg please advice.

• Evolution #4613 (Nouveau) : créer une aide ré-actualisée pour Spip 3.*

  10 décembre 2020, par Laurent Lefebvre

  Bonjour,

  quelques affirmations concernant les retours à la ligne sont fausses depuis Spip 3.0 :

  Ex :

  • "Le fait de simplement « revenir à la ligne » (retour-chariot) sans séparer les deux paragraphes par une ligne vide ne suffit pas pour provoquer un changement de paragraphe (cela ne provoque même pas un retour à la ligne)._" -> Il faudrait retirer la parenthèse et son contenu.
  • "Notez : ici un simple retour à la ligne suffit (on peut faire des énumérations dans le même paragraphe) ; mais si l’on « saute » une ligne avant la ligne commençant par un tiret, une ligne vide est affichée avant l’énumération._" -> Ce paragraphe ne sert plus dans le contexte Spip 3.*

  On pourrait aussi moderniser l’aide. Ajouter la mention aux touches raccourcis par exemple ( pour l’italique, le gras, les intertitres ... ).
  En attendant ce changement, ne pourrait-on pas modifier rapidement les affirmations sur les retours à la ligne ? (c’est crucial pour les nouveaux utilisateurs et ce sont eux qui utilisent l’aide.)