Recherche avancée

Sur d’autres sites (5828)

• avformat/rtpdec_jpeg : fix low contrast image on low quality setting

  24 mars 2016, par Ico Doornekamp

  avformat/rtpdec_jpeg : fix low contrast image on low quality setting
  Original mail and my own followup on ffmpeg-user earlier today :
  I have a device sending out a MJPEG/RTP stream on a low quality setting.
  
  Decoding and displaying the video with libavformat results in a washed
  
  out, low contrast, greyish image. Playing the same stream with VLC results
  
  in proper color representation.
  Screenshots for comparison :
    http://zevv.nl/div/libav/shot-ffplay.jpg
  
    http://zevv.nl/div/libav/shot-vlc.jpg
  A pcap capture of a few seconds of video and SDP file for playing the
  
  stream are available at
    http://zevv.nl/div/libav/mjpeg.pcap
  
    http://zevv.nl/div/libav/mjpeg.sdp
  I believe the problem might be in the calculation of the quantization
  
  tables in the function create_default_qtables(), the attached patch
  
  solves the issue for me.
  The problem is that the argument ’q’ is of the type uint8_t. According to the
  
  JPEG standard, if 1 <= q <= 50, the scale factor ’S’ should be 5000 / Q.
  
  Because the create_default_qtables() reuses the variable ’q’ to store the
  
  result of this calculation, for small values of q < 19, q wil subsequently
  
  overflow and give wrong results in the calculated quantization tables. The
  
  patch below uses a new variable ’S’ (same name as in RFC2435) with the proper
  
  range to store the result of the division.
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/rtpdec_jpeg.c

• avcodec : disallow hwaccel with frame threads

  23 octobre 2015, par Hendrik Leppkes

  avcodec : disallow hwaccel with frame threads
  HWAccels with frame threads are fundamentally flawed in avcodecs current
  
  design, and there are several known problems ranging from image corruption
  
  to driver crashes.
  These problems come down to two design problems in the interaction of
  
  threads and HWAccel decoding :
  (1)
  
  While avcodec prevents parallel decoding and as such simultaneous access
  
  to the hardware accelerator from the decoding threads, it cannot account
  
  for the user code and its access to the hardware surfaces and the hardware
  
  itself.
  This can result in image corruption or even driver crashes if the
  
  user code locks image surfaces while they are being used by the decoder
  
  threads as reference frames.
  The current HWAccel API does not offer any way to ensure exclusive access
  
  to the hardware or the surfaces if frame threading is used.
  (2)
  
  Initialization of the HWAccel with frame threads is non-trivial, and many
  
  decoders had and still have issues that cause excess calls to the
  
  get_format callback.
  This will potentially cause duplicate HWAccel initialization, which in
  
  extreme cases can even lead to driver crashes if the HWAccel is
  
  re-initialized while the user code is actively accessing the hardware
  
  surfaces associated with it, or lead to image corruption due to lost
  
  reference frames.
  While both of these issues are solvable, fixing (1) would at least require
  
  a huge API redesign which would move a lot of complexity into the user
  
  code.
  The only reason the combination of frame threads and HWAccel was
  
  considered useful is to allow a seamless fallback to multi-threaded
  
  software decoding if the HWAccel is not available, however the issues
  
  outlined above far outweigh this.
  The proper solution for a fallback is to re-open the AVCodecContext with
  
  threading enabled if the HWAccel failed, which is a practice commonly used
  
  by various user applications using avcodec today already.
  Reviewed-by : Gwenole Beauchesne <gb.devel@gmail.com>
  
  Reviewed-by : wm4 <nfxjfg@googlemail.com>
  
  Signed-off-by : Hendrik Leppkes <h.leppkes@gmail.com>
  

  • [DH] libavcodec/utils.c

• Grafika and OpenGL to record a video on android in square shape

  3 octobre 2015, par Cédric Portmann

  I am currently trying to record a video in square shape and create a output as .mp4. It seems to be really challenging. I tried diffrent approches including : OnPreviewFrame and FFMpeg. But never got a satisfing result. Today i found Grafika. And it seems to be the right way. But because of the complextity of the Code i am stuck now. Using the Example : CameraCaptureActivity.java i managed to record a video. But its shape is rectangluar and not square. Furthermore the camera is rotated by 90 degrees. I was already trying to manipulate certain parameters but never got a good video. Some where squeezed and so on.

  Does anybody know what parameters i need to change inside Grafikas example to get the right result ?
  In the end the camera of my android phone should record Videos like Vine or Instagram.

  Thanks for your help !