Recherche avancée

Sur d’autres sites (7795)

• How would I assign multiple MMAP's from single file descriptor ?

  9 juin 2011, par Alex Stevens

  So, for my final year project, I'm using Video4Linux2 to pull YUV420 images from a camera, parse them through to x264 (which uses these images natively), and then send the encoded stream via Live555 to an RTP/RTCP compliant video player on a client over a wireless network. All of this I'm trying to do in real-time, so there'll be a control algorithm, but that's not the scope of this question. All of this - except Live555 - is being written in C. Currently, I'm near the end of encoding the video, but want to improve performance.

  To say the least, I've hit a snag... I'm trying to avoid User Space Pointers for V4L2 and use mmap(). I'm encoding video, but since it's YUV420, I've been malloc'ing new memory to hold the Y', U and V planes in three different variables for x264 to read upon. I would like to keep these variables as pointers to an mmap'ed piece of memory.

  However, the V4L2 device has one single file descriptor for the buffered stream, and I need to split the stream into three mmap'ed variables adhering to the YUV420 standard, like so...

  buffers[n_buffers].y_plane = mmap(NULL, (2 * width * height) / 3,
  
                                      PROT_READ | PROT_WRITE, MAP_SHARED,
  
                                      fd, buf.m.offset);
  
  buffers[n_buffers].u_plane = mmap(NULL, width * height / 6,
  
                                      PROT_READ | PROT_WRITE, MAP_SHARED,
  
                                      fd, buf.m.offset +
  
                                      ((2 * width * height) / 3 + 1) /
  
                                      sysconf(_SC_PAGE_SIZE));
  
  buffers[n_buffers].v_plane = mmap(NULL, width * height / 6,
  
                                      PROT_READ | PROT_WRITE, MAP_SHARED,
  
                                      fd, buf.m.offset +
  
                                      ((2 * width * height) / 3 + 
  
                                      width * height / 6 + 1) / 
  
                                      sysconf(_SC_PAGE_SIZE));

  Where "width" and "height" is the resolution of the video (eg. 640x480).

  From what I understand... MMAP seeks through a file, kind of like this (pseudoish-code) :

  fd = v4l2_open(...);
  
  lseek(fd, buf.m.offset + (2 * width * height) / 3);
  
  read(fd, buffers[n_buffers].u_plane, width * height / 6);

  My code is located in a Launchpad Repo here (for more background) :
  http://bazaar.launchpad.net/ alex-stevens/+junk/spyPanda/files (Revision 11)

  And the YUV420 format can be seen clearly from this Wiki illustration : http://en.wikipedia.org/wiki/File:Yuv420.svg (I essentially want to split up the Y, U, and V bytes into each mmap'ed memory)

  Anyone care to explain a way to mmap three variables to memory from the one file descriptor, or why I went wrong ? Or even hint at a better idea to parse the YUV420 buffer to x264 ? :P

  Cheers ! ^^

• Evolution #3603 : Ergonomie des onglets de sélection des plugins

  24 novembre 2015, par RastaPopoulos ♥

  Je suis d’accord que dans de nombreux cas, au lieu d’avoir une interface pleines d’options à choisir / cocher / cumuler, il est plus lisible d’avoir 3 ou 4 cas d’utilisation réels dont on sait qu’ils sont utiles, et n’avoir que ça. Évidemment il faut bien réfléchir alors pour être sûr que ne vont pas apparaitre d’autres cas utiles, qui feraient augmenter le nombre d’onglets. Mais là on est dans une interface très précise, qui ne s’occupent que des plugins, c’est à priori pas un truc qui peut augmenter, où des fonctionnalités peuvent apparaitre ou être ajoutées.

  Et au passage, du coup, au niveau ergonomique, ce sont VRAIMENT sémantiquement des onglets (alors que des "filtres" affichés graphiquement sous forme d’onglets, ce n’était pas du tout pertinent au niveau ergo).

• Evolution #4358 : Supprimer l’explication d’inscription qui préjuge de l’utilisation

  5 juillet 2019, par RastaPopoulos ♥

  Et je généralise : un formulaire, c’est un truc fonctionnel, qui sert à faire des actions en base : les formulaires fourni par défaut par SPIP devraient toujours être le plus génériques, car ils peuvent ensuite être appelés de diverses manières (dans l’admin, dans le public, etc), parfois même plusieurs fois dans le même site pour des besoins différents.

  Cela n’empêche en rien de construire des interfaces où il y a des explications humaines. Mais celles-ci doivent être le plus possible à l’extérieur des formulaires noyau génériques. Il peut rester des cas où une explication est impérative à l’intérieur même d’un formulaire, mais c’est quelque chose d’extrêmement rare.

  Là par exemple, ça n’a aucun sens de forcer un sens particulier, vu le nombre d’utilisations possibles d’une inscription.