Recherche avancée

Sur d’autres sites (4452)

• Evolution #4493 (Nouveau) : Ajouter des robots à l’écran de sécurité

  17 mai 2020

  Bonjour,

  J’ai quelques sites qui ont des nombres de visites bizarres (trop grand, d’un facteur 10 à 30 certains jours).

  J’ai fait un patch : https://git.spip.net/RealET/spip/commit/ce2ce832b697ab0754a78e0fc8b298ae1e9c992b
  Mais je ne sais pas comment en faire un PR.

  Pour info, voici un extrait d’awstats pour le serveur concerné :
  Pour info :
  MJ12bot 2 241 164+29470 32.60 Go 17 Mai 2020 - 11:50
  AhrefsBot 1 388 315+9242 28.07 Go 17 Mai 2020 - 11:50
  SemrushBot 1 251 075+74309 23.91 Go 17 Mai 2020 - 11:50
  bingbot 619 488+28872 22.38 Go 17 Mai 2020 - 11:50
  DotBot 394 445+7038 22.52 Go 17 Mai 2020 - 11:50
  Googlebot 297 801+35895 11.64 Go 17 Mai 2020 - 11:50
  crawl 243 784+325 4.66 Go 17 Mai 2020 - 11:39
  MegaIndex.ru 172 567+51 5.41 Go 17 Mai 2020 - 04:50
  BLEXBot 161 178+4405 4.24 Go 17 Mai 2020 - 06:42
  Applebot 136 660+2443 3.20 Go 17 Mai 2020 - 11:50
  robot 129 533+3017 7.80 Go 17 Mai 2020 - 11:50
  empty user agent string 117 782+778 6.55 Go 17 Mai 2020 - 11:49
  Firefox version 10 and lower - various robots 106 252+366 1.87 Go 17 Mai 2020 - 11:50
  qwantify 83 743+3013 3.61 Go 17 Mai 2020 - 11:50
  Unknown robot identified by bot* 53 246+1846 2.25 Go 17 Mai 2020 - 11:37
  spip 46 253 554.75 Mo 17 Mai 2020 - 11:50
  link 44 510+567 761.38 Mo 17 Mai 2020 - 11:50
  Googlebot-Image 36 704 1.24 Go 17 Mai 2020 - 11:48
  facebookexternalhit 35 176+1 1.31 Go 17 Mai 2020 - 11:49
  MSIE 6 - ( Rogue Robot ) 33 090 1.10 Go 17 Mai 2020 - 11:47
  YandexBot 21 272+9245 822.57 Mo 17 Mai 2020 - 11:50
  Unknown robot (identified by hit on robots.txt) 0+27213 98.21 Mo 17 Mai 2020 - 11:48
  LinkpadBot 17 954 289.02 Mo 17 Mai 2020 - 06:46
  infobot 15 038+1887 198.28 Mo 17 Mai 2020 - 04:19
  MSIE 5 - ( Rogue Robot ) 16 110+1 980.04 Mo 17 Mai 2020 - 11:18
  Sogou web spider 14 514+453 239.14 Mo 17 Mai 2020 - 11:49
  ltx71 10 593+3663 378.89 Mo 17 Mai 2020 - 11:50
  BingPreview 11 920 1.87 Go 17 Mai 2020 - 11:40
  nbot 8 476+1023 230.66 Mo 17 Mai 2020 - 11:42
  Apache-HttpClient 7 897+43 99.64 Mo 17 Mai 2020 - 11:01
  Curl 7 752 151.93 Mo 17 Mai 2020 - 11:49
  CFNetwork 7 313 779.65 Mo 17 Mai 2020 - 11:25
  core 7 295+2 174.93 Mo 17 Mai 2020 - 11:35
  oBot 7 064+230 338.14 Mo 17 Mai 2020 - 08:06
  SeznamBot 3 677+3204 148.02 Mo 16 Mai 2020 - 22:36
  twitterbot 4 264+2518 100.64 Mo 17 Mai 2020 - 11:44
  panscient 6 298+397 97.66 Mo 17 Mai 2020 - 06:37
  A PHP script 6 395 13.36 Mo 17 Mai 2020 - 11:50
  archive.org_bot 4 917+385 157.65 Mo 17 Mai 2020 - 11:50
  vagabondo 5 022+12 197.93 Mo 17 Mai 2020 - 09:58
  Feedfetcher-Google 4 808 137.78 Mo 17 Mai 2020 - 11:41
  zend_http_client 4 535 20.98 Mo 17 Mai 2020 - 11:34
  ia_archiver 4 411+98 302.37 Mo 17 Mai 2020 - 03:58
  feed 4 401 127.40 Mo 17 Mai 2020 - 11:45
  dataprovider.com 4 003+167 169.38 Mo 17 Mai 2020 - 10:31
  universalfeedparser 4 156 82.26 Mo 17 Mai 2020 - 11:36
  Baidu ( catchall ) 3 956 260.02 Mo 17 Mai 2020 - 11:11
  coccoc 1 509+2374 33.71 Mo 17 Mai 2020 - 10:37
  python 3 607+87 54.82 Mo 17 Mai 2020 - 11:44
  Mail.RU Bot 1 969+1492 177.25 Mo 17 Mai 2020 - 11:13

• Portable YUV Drawing Context

  1er juin 2017, par Leif Andersen

  I have a stream of YUV data (from a video file) that I want to stream to a screen in real time. (Basically, I want to write a program that plays the video in real time.)

  As such, I am looking for a portable way to send YUV data to the screen. I would ideally like to use something portable so I don’t have to reimplement it for every major platform.

  I have found a few options, but all of them seem to have significant issues. They are :

  1. Use OpenGL directly, converting the YUV data to RGB. (And using the single quad for the whole screen trick.)

  This obviously won’t work because converting RGB to YUV on the CPU is going to be too slow for displaying images in real time.

  2. Use OpenGL, but use a shader to convert the YUV stream to RGB.

  This option is a bit better. Although the problem here is that (afaict), this will involve making two streams and splicing them together. It might work, but may have issues with larger resolutions.

  3. Instead use SDL, which has the option of creating a YUV context directly.

  The problem with this is I already am using a cross platform widget library for other aspects of my program (such as playback controls). As far as I can tell, SDL only opens up in its on (possibly borderless) window. I would ideally like my controls and drawing context to be in the same window. Which I can do with opengl, but not SDL.

  4. Use SDL, and also use something like Qt for the on screen widgets, use a message passing protocol to communicate between the two libraries. Have the (borderless) SDL window constantly move itself on top of the opengl window.

  While this approach is clever, it seems like the two windows could get out of sink easily making the user experience sub-optimal.

  5. Forget a cross platform library, do thinks OS specific, making use of hardware acceleration if present.

  This is a fine solution although its not cross platform.

  As such, is there any good way to draw YUV data to a screen that ideally is :

  1. Portable (at least to the major platforms).
  2. Fast enough to be real time.
  3. Allows other widgets in the same window.

• What is the GLFW screen format for ffmpeg encoding ?

  3 septembre 2022, par Turgut

  I have a program where I have a GLFW window and read that window using glReadPixels(0, 0,window_width, window_height, GL_RGBA, GL_UNSIGNED_BYTE, (GLvoid*) Buffer); then use that Buffer to encode a frame via ffmpeg. It works fine however the resolution is a bit low.

  


  I tried changing bit-rates to no avail so I started experimenting with formats. Normally I'm using AV_PIX_FMT_YUV420P in my encoder as my format since the data that comes from the glfw window is RGBA but this format result in the said low resolution video. The result video is a lot more pixelated than whats seen on the GLFW window.

  


  What could be the optimal pixel format for reading GLFW window ? Some formats straight up not work resulting in Specified pixel format  yuyv422 is invalid or not supported error.

  


  And here is where I got that error from :

  


  ret = avcodec_open2(c, codec, &opt);


  


  This line causes me to get Specified pixel format  yuyv422 is invalid or not supported error when I use something other than YUV420.

  


  I also have this setting #define SCALE_FLAGS SWS_BICUBIC which im not sure what it does but may also cause my error. (Not likeliy since this comes after the line mentioned above, but I could just keep the format at YUV420 and change SWS_BICUBIC instead.)

  


  I'm using ubuntu, ffmpeg, glfw and glad (GLSL) to render the texture writeen in the frames. I got the encoder from ffmpegs muxing.c example.

  


  Edit : Using AV_PIX_FMT_RGBA also results in a similar error.

  


  Edit : Here is my sample code where I convert Buffer to ffmepg format :

  


  #define STREAM_PIX_FMT AV_PIX_FMT_YUV420P
...
void video_encoder::set_frame_yuv_from_rgb(AVFrame *frame, struct SwsContext *sws_context) {
    const int in_linesize[1] = { 4 * width };

    sws_context = sws_getContext(
            width, height, AV_PIX_FMT_RGBA,
            width, height, STREAM_PIX_FMT,
            SWS_BICUBIC, 0, 0, 0);

    sws_scale(sws_context, (const uint8_t * const *)&rgb_data, in_linesize, 0,
            height, frame->data, frame->linesize);
}