Recherche avancée

Sur d’autres sites (10629)

• swscale/vscale : Increase type strictness

  26 avril 2020, par Andreas Rheinhardt

  swscale/vscale : Increase type strictness
  libswscale/vscale.c makes extensive use of function pointers and in
  
  doing so it converts these function pointers to and from a pointer to
  
  void. Yet this is actually against the C standard :
  
  C90 only guarantees that one can convert a pointer to any incomplete
  
  type or object type to void* and back with the result comparing equal
  
  to the original which makes pointers to void generic pointers to
  
  incomplete or object type. Yet C90 lacks a generic function pointer
  
  type.
  
  C99 additionally guarantees that a pointer to a function of one type may
  
  be converted to a pointer to a function of another type with the result
  
  and the original comparing equal when converting back.
  
  This makes any function pointer type a generic function pointer type.
  
  Yet even this does not make pointers to void generic function pointers.
  Both GCC and Clang emit warnings for this when in pedantic mode.
  This commit fixes this by using a union that can hold one member of any
  
  of the required function pointer types to store the function pointer.
  
  This works even for C90.
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libswscale/vscale.c

• Revision f6582d6928 : Revert "Simplify mask checking in loop filters" Jingning saw bitstream change w

  4 décembre 2013, par Yunqing Wang

  Changed Paths :
   Modify /vp9/common/vp9_loopfilter.c

  
  
  Revert "Simplify mask checking in loop filters"

  Jingning saw bitstream change with this patch. It could be true
  that (mask_16x16_0 & 1) is 1, but (mask_16x16_1 & 1) is 0 in some
  edge cases.

  This reverts commit 8f05e70340533b9922be5b1c97c37e50607fd862.

  Change-Id : I0a529435ce816a1e14653eb510d5090de276070a

• WebRTC Stream Freezes When Picture Complexity Increases

  12 octobre 2021, par user1259576

  I am developing an application that uses WebRTC to display a live video stream being captured from a V4L2 source. The stream originates from a Linux box that has a DVI-USB capture card, is encoded to H264 by ffmpeg and sent to RTP, received by a Janus WebRTC server which is accessed by the web interface.

  


  Here is my current ffmpeg command - pretty simple :
ffmpeg -f v4l2 -i /dev/video0 -vf "transpose=1,scale=768:1024" -vcodec libx264 -profile:v baseline -pix_fmt yuv420p -f rtp rtp ://10.116.80.86:8004

  


  I can't go into details, but the DVI source generates a portrait 768x1024 image that initially is a simple image where the only movement is a small clock near the center that increments every second. At this stage, everything appears to work great. The image is high-quality and continuous/smooth in the browser.

  


  Once I interact with the DVI source, a more complex image is generated, with some text/lines in the upper half. Still not very complex - only 2 colors involved and some basic 1px line shapes, and only the little clock is moving. At this point, the video starts to freeze frequently, and only updates once in a while for a few seconds. Bandwidth should not be an issue here, and the bitrate appears to stay high. However, many fewer frames are decoded.

  


  I have also tried scaling the video down to 480x640 from 768x1024 and with that change the issue does not occur. However, I really need the full resolution and, again, there should not be a bandwidth issue here.

  


  I have also tried capturing the output of ffmpeg to a file rather than streaming to RTP and in the file everything is good.

  


  Here is a screenshot of the WebRTC internals (in Edge) for this stream. You can clearly see when the video image changes from the simple clock to including more shapes & text (nothing is changed here other than the image from the DVI source) :

  


  

  


  In Firefox, the video just freezes whenever frames are not decoded. In Edge, the video goes black after a moment with no frames decoded.

  


  Any ideas as to what might be causing this ?