Recherche avancée

Sur d’autres sites (10724)

• lavc/opusdsp : rewrite R-V V postfilter

  2 novembre 2023, par Rémi Denis-Courmont

  lavc/opusdsp : rewrite R-V V postfilter
  This uses a more traditional approach allowing up processing of up to
  
  period minus two elements per iteration. This also allows the algorithm
  
  to work for all and any vector length.
  As the T-Head C908 device under test can load 16 elements loop, there is
  
  unsurprisingly a little performance drop when the period is minimal and
  
  the parallelism is capped at 13 elements :
  Before :
  
  postfilter_15_c :         21222.2
  
  postfilter_15_rvv_f32 :   22007.7
  
  postfilter_512_c :        20189.7
  
  postfilter_512_rvv_f32 :  22004.2
  
  postfilter_1022_c :       20189.7
  
  postfilter_1022_rvv_f32 : 22004.2
  After :
  
  postfilter_15_c :         20189.5
  
  postfilter_15_rvv_f32 :    7057.2
  
  postfilter_512_c :        20189.5
  
  postfilter_512_rvv_f32 :   5667.2
  
  postfilter_1022_c :       20192.7
  
  postfilter_1022_rvv_f32 :  5667.2
  

  • [DH] libavcodec/riscv/opusdsp_init.c
  • [DH] libavcodec/riscv/opusdsp_rvv.S

• lavu/riscv : CPU flag for the Zbb extension

  2 octobre 2022, par Rémi Denis-Courmont

  lavu/riscv : CPU flag for the Zbb extension
  Unfortunately, it is common, and will remain so, that the Bit
  
  manipulations are not enabled at compilation time. This is an official
  
  policy for Debian ports in general (though they do not support RISC-V
  
  officially as of yet) to stick to the minimal target baseline, which
  
  does not include the B extension or even its Zbb subset.
  For inline helpers (CPOP, REV8), compiler builtins (CTZ, CLZ) or
  
  even plain C code (MIN, MAX, MINU, MAXU), run-time detection seems
  
  impractical. But at least it can work for the byte-swap DSP functions.
  

  • [DH] libavutil/cpu.c
  • [DH] libavutil/cpu.h
  • [DH] libavutil/riscv/cpu.c
  • [DH] tests/checkasm/checkasm.c

• Streaming Webcam Over LAN : HTML5 Video Element Not Loading

  27 novembre 2023, par Franck Freiburger

  I am currently working on a project where I aim to stream my webcam over my LAN and read the stream in an HTML5 video element with minimal setup. My setup involves a server (192.168.0.1 dev/video0 -> ffmpeg) and a client (192.168.0.2 html5 browser). I am using ffmpeg with the codec set to h264.

  


  Here is the ffmpeg command I am using :

  


  ffmpeg -f video4linux2 -i /dev/video0
  -an -c:v libx264 -b:v 1024k -video_size 800x600 -pix_fmt yuv420p -preset ultrafast
  -tune zerolatency -g 16 -keyint_min 16 -f mpegts pipe:1


  


  This command is spawned by a simple Node.js server that shares this stream without any transformation (just pipe ffpmeg stream to each incoming connection).

  


  When I use vlc or ffplay with the following command, it works very well :

  


  ffplay -fflags nobuffer -flags low_delay -probesize 32 -analyzeduration 0 -framedrop http://192.168.0.1:3000/stream


  


  I can even run multiple instances of ffplay and the video is properly played. However, when I try to use the HTML5 element like this :

  


  <video src="http://127.0.0.1:3000/stream" type="video/mp4"></video>&#xA;

  


  The video seems to "load forever" without any error, nothing suspect in chrome://media-internals. I can see in the network tab that the network is reading the stream, but the video does not play (got same result using hljs and videojs).

  


  

  


  I am looking for help to understand :

  


  

  • What is wrong with the <video></video> element in this context ?

  


  • Is there a better approach to achieve this ?

  


  


  Any help or guidance would be greatly appreciated.