Recherche avancée

Sur d’autres sites (10732)

• Recording with libx264 results in audio muting prior to recording being stopped depending on preset

  24 janvier 2020, par Pyon

  ffmpeg -thread_queue_size 512 -f dshow -i audio="AudioDevice" -thread_queue_size 512 -f gdigrab -rtbufsize 100000000 -hwaccel auto -framerate 60 -offset_x 332 -offset_y 720 -video_size 340x162 -probesize 10000000 -i desktop -c:v libx264 -preset veryslow -crf 23 -pix_fmt yuv420p "output.mp4"

  I’m using the above command to record desktop video/audio in a defined region.
  The video is being recorded using gdigrab while the audio is being recorded using dshow with a custom loopback driver.

  When the libx264 preset is set to anything below "ultrafast" like "veryslow", the audio will be muted around 80% into the recording (varies depending on video size and the preset selected, worsening for slower presets). By muted I mean : If I record a 10 second video, the video will be 10 seconds in length but the audio will only be audible for the first 8 seconds.

  I’m not really sure what could be causing this, but is there any way around it ?

  Below are simplified versions which produces same results..

  Veryslow preset (audio issue) :

  ffmpeg -thread_queue_size 512 -f dshow -i audio="PriAudio" -thread_queue_size 512 -f gdigrab -i desktop -c:v libx264 -preset veryslow -crf 23 -pix_fmt yuv420p "output.mp4"

  Ultrafast preset (no audio issue) :

  ffmpeg -thread_queue_size 512 -f dshow -i audio="PriAudio" -thread_queue_size 512 -f gdigrab -i desktop -c:v libx264 -preset ultrafast -crf 23 -pix_fmt yuv420p "output.mp4"

  I don’t want to use ultrafast because it results in poor quality/compression ratio.

• Revision ed2dc59c1b : Integral projection based motion estimation This commit introduces a new block

  13 février 2015, par Jingning Han

  Changed Paths :
   Modify /vp9/common/vp9_rtcd_defs.pl

  
   Modify /vp9/encoder/vp9_avg.c

  
   Modify /vp9/encoder/vp9_encodeframe.c

  
   Modify /vp9/encoder/x86/vp9_avg_intrin_sse2.c

  
  
  Integral projection based motion estimation

  This commit introduces a new block match motion estimation
  using integral projection measurement. The 2-D block and the nearby
  region is projected onto the horizontal and vertical 1-D vectors,
  respectively. It then runs vector match, instead of block match,
  over the two separate 1-D vectors to locate the motion compensated
  reference block.

  This process is run per 64x64 block to align the reference before
  choosing partitioning in speed 6. The overall CPU cycle cost due
  to this additional 64x64 block match (SSE2 version) takes around 2%
  at low bit-rate rtc speed 6. When strong motion activities exist in
  the video sequence, it substantially improves the partition
  selection accuracy, thereby achieving better compression performance
  and lower CPU cycles.

  The experiments were tested in RTC speed -6 setting :
  cloud 1080p 500 kbps
  17006 b/f, 37.086 dB, 5386 ms ->
  16669 b/f, 37.970 dB, 5085 ms (>0.9dB gain and 6% faster)

  pedestrian_area 1080p 500 kbps
  53537 b/f, 36.771 dB, 18706 ms ->
  51897 b/f, 36.792 dB, 18585 ms (4% bit-rate savings)

  blue_sky 1080p 500 kbps
  70214 b/f, 33.600 dB, 13979 ms ->
  53885 b/f, 33.645 dB, 10878 ms (30% bit-rate savings, 25% faster)

  jimred 400 kbps
  13380 b/f, 36.014 dB, 5723 ms ->
  13377 b/f, 36.087 dB, 5831 ms (2% bit-rate savings, 2% slower)

  Change-Id : Iffdb6ea5b16b77016bfa3dd3904d284168ae649c

• 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.