Recherche avancée

Sur d’autres sites (5386)

• 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 #3966 (Nouveau) : Date de création des contenus

  26 juin 2017, par tcharlss (*´_ゝ｀)

  Il n’y a pas longtemps j’ai eu besoin de faire des statistiques éditoriales : on voulait connaître l’évolution du nombre d’articles publiés chaque année.
  Mais les données ne sont pas fiables : les utilisateurs avaient pour habitude de faire des « remises en avant » en changeant la date de publication de vieux articles pour les refaire apparaître en page d’accueil. Donc un article écrit en 2014 mais remis en avant en 2017 se retrouve compté comme ayant été publié en 2017.

  Et c’est valable pour tout les objets éditoriaux en fait : on ne conserve pas leur date de création / 1ère publication.
  Certains objets ont une date de publication, mais elle peut être changée. Et d’autres objets n’ont tout simplement pas de date (hormis maj).

  Donc je me demandais s’il ne serait pas pertinent d’avoir cette information de façon générique pour tous les objets éditoriaux, un champ date_creation par exemple qui serait rempli soit à la création, soit à la 1ère publication, et qui ne bougerait pas ensuite.

  Ci-dessous, un tableau récapitulatif de ce qu’on a actuellement pour les principaux objets.

  Objet	Champ de date	Date pérènne ?
  Articles	date	Non : peut être modifiée manuellement
  Brèves	date_heure	Non : peut être modifiée manuellement
  Rubriques	date	Oui
  Auteurs	X	X
  Mot-clé	X	X
  Groupe de mots-clés	X	X
  Document	date	Oui
  Forum	date_heure	oui
  Pétition	X	X

• Anomalie #4543 : Accessibilité des chargements ajax (live regions)

  22 septembre 2020, par nicod _

  nicod _ a écrit :

  C’est bien ce que je comprends des recos, oui, attribut aria sur le premier résultat et redonner le focus sur cet élément.

  J’ai dit une bêtise : retirer l’attribut aria-live et juste gérer le focus.

  Précisions :

  (D’ailleurs, pour effectuer cela, afin de donner le focus à un élément qui normalement ne le reçoit pas, il faut lui ajouter un attribut tabindex="-1".)
  Enfin, il est vraiment important de voir en contexte leur nécessité, si je reprend l’exemple donné sur le github de la disic, à propos d’un panier d’achats, ce n’est pas aussi simple qu’ils l’ont écrit. Tout va dépendre du comportement global. Exemples, après avoir mis un article dans le panier :

  - je suis redirigé vers la page du panier s’affiche (rechargement de page) > alors pas d’aria-live
  je reste sur ma page produit et une "animation" montre mon article qui va dans le panier où le nombre d’article est incrémenté > là on utilise une live region qui va dire un truc du style "3 articles dans le panier" (ou qui peut être plus précise même : "l’article "x" a été ajouté, vous avez 3 articles dans le panier")
  - le panier s’affiche comme une modale (souvent c’est un panneau à droite de l’écran) -> là non plus, a priori pas d’aria-live nécessaire, comme il y a forcément une gestion du focus à prévoir pour amener l’utilisateur dans la bonne zone, on va donner le focus à un titre du style "votre panier (3 articles)"
  etc.