Recherche avancée

Sur d’autres sites (9194)

• Anomalie #4701 : Jointures automatiques erronées ? (ex. : groupe au lieu de groupe_mots)

  23 mars 2021, par cedric -

  "avant ça fonctionnait" c’est un bien grand mot. Disons que la requête sortait un résultat, mais il était faux !

  Voici ce que j’obtiens en SPIP 3.2 : on note l’absence de clause sur L1.objet qui est une erreur :
  ```
  SELECT L1.id_objet, L1.id_objet AS id_groupe
  FROM spip_documents_liens AS `L1`
  INNER JOIN spip_documents AS L2 ON ( L2.id_document = L1.id_document )
  WHERE (L2.titre = ’toto’)
  GROUP BY L1.id_objet
  ```

  Je pense que le bug apparait plus clairement depuis https://git.spip.net/spip/spip/commit/81b3f6dd22d699986ca2d5a068959ec0011b4253 qui en effet introduit la clause where de façon plus robuste

• ffmpeg - when scaling, how to keep shapes of people's heads

  19 janvier 2017, par Dave

  Ok, I’m quite familiar with FFMPEG utility in general, and have used it for
  years to cut short snippets from videos, etc. But it’s only in the last
  month that and I decided to learn to use it to transcode with video-filters
  etc. (Before that, I was using other tools such as ’Handbrake’ and ’FreeMake’
  and VLC, etc.)

  For my ffmpeg transcodes, my target output resolution will always be constant, from one transcode run to the next. But the resolution and display aspect-ratio of the input file, from one transcode run to the next, will vary...could be almost any values.
  The input files will never already have black-bars when displayed.

  So, the relevant portion [ i.e. the video-filter(s) part) of my cmd line ] presently is as follows :

  ffmpeg ... -vf "scale=720:406,setsar=1,pad=720:506:0:40:Black" ...

  Also note : I do NOT use the "-aspect" option in the cmd-line. (Maybe I’ll
  need to (???) to solve my issue, but I’m unsure about how that interacts
  with scaling.)

  ( EDIT : Oh, I happen to have chosen that resolution value of 720x406, for
  the image-area (i.e. inside the top/bottom black bars) because it
  has an aspect ratio of 16:9 (Of course, 16:9 ratio is common these days. )

  My cmd always executes cleanly and produces an output file (a WebM, tho I doubt
  that container types and/or vcodec choices matter at all to scaling algorithm issues).

  So the issue/problem that I’m trying to solve is how to prevent any stretching
  in either direction. In other words, a round soccer ball in the input file
  must yield a round ball in the output file ! (NOT oval-shaped in either axis).

  ( Edit #2 : Oh, I forgot to mention that I’m not have the same amount of stretching from one ffmpeg output file to the next. Sometimes there is
  no stretch in my output file, and with some other input file, the
  people are too tall in the output, and some other output file will have
  people are too wide. I’m assuming
  there is some single cmd that will always work for each randomly sized
  input file, WITHOUT having to resort to examining meta-data of each
  input and then having to adjust portions of the needed ffmpeg cmd.
  I assume this because I have used a tool called "FreeMake" that needs
  no such adjustment. When you do a ’scale’ with that program, it asks
  you to choose one of four adjustment-algorithms labeled "original"
  "stretched", "zoom..." and "auto". If I recall correctly, it was the
  "auto" choice that prevented any stretching.)

  The goal of that last filter (i.e. the "pad=720:506:0:40:Black" phrase) is to
  add a black bar of 40 pixels to the top and 60 pixels to the bottom.
  (That filter IS producing the black-bands, as desired. I mention it,
  because I’m unsure whether it could be having any effect on the altered
  shape of the ’round soccer ball’). If the "pad" filter IS part of the
  issue, then maybe I’ll need to make multiple ffmpeg cmds to achieve
  my overall goal (!?!?). [I’d LIKE to be able to do everything in just
  one ffmpeg cmd, as shown.]

  OK ?

  So are there any image-processing and ffmpeg gurus out there that
  know how to fix my problem ?

  TIA...

  Dave

• armv6 : Accelerate ff_fft_calc for general case (nbits != 4)

  16 juillet 2014, par Ben Avison

  armv6 : Accelerate ff_fft_calc for general case (nbits != 4)
  The previous implementation targeted DTS Coherent Acoustics, which only
  
  requires nbits == 4 (fft16()). This case was (and still is) linked directly
  
  rather than being indirected through ff_fft_calc_vfp(), but now the full
  
  range from radix-4 up to radix-65536 is available. This benefits other codecs
  
  such as AAC and AC3.
  The implementaion is based upon the C version, with each routine larger than
  
  radix-16 calling a hierarchy of smaller FFT functions, then performing a
  
  post-processing pass. This pass benefits a lot from loop unrolling to
  
  counter the long pipelines in the VFP. A relaxed calling standard also
  
  reduces the overhead of the call hierarchy, and avoiding the excessive
  
  inlining performed by GCC probably helps with I-cache utilisation too.
  I benchmarked the result by measuring the number of gperftools samples that
  
  hit anywhere in the AAC decoder (starting from aac_decode_frame()) or
  
  specifically in the FFT routines (fft4() to fft512() and pass()) for the
  
  same sample AAC stream :
                Before          After
  
                Mean   StdDev   Mean   StdDev  Confidence  Change
  
  Audio decode  2245.5 53.1     1599.6 43.8    100.0%      +40.4%
  
  FFT routines  940.6  22.0     348.1  20.8    100.0%      +170.2%
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavcodec/arm/fft_init_arm.c
  • [DH] libavcodec/arm/fft_vfp.S