Recherche avancée

Sur d’autres sites (5849)

• avcodec/magicyuv : Fix edge case of building Huffman table

  23 septembre 2020, par Andreas Rheinhardt

  avcodec/magicyuv : Fix edge case of building Huffman table
  The MagicYUV format stores Huffman tables in its bitstream by coding
  
  the length of a given symbol ; it does not code the actual code directly,
  
  instead this is to be inferred by the rule that a symbol is to the left
  
  of every shorter symbol in the Huffman tree and that for symbols of the
  
  same length the symbol is ascending from left to right. With one
  
  exception, this is also what our decoder did.
  The exception only matters when there are codes of length 32, because
  
  in this case the first symbol of this length did not get the code 0,
  
  but 1 ; e.g. if there were exactly two nodes of length 32, then they
  
  would get assigned the codes 1 and 2 and a node of length 31 will get
  
  the 31-bit code 1 which is a prefix of the 32 bit code 2, making the
  
  Huffman table invalid. On the other hand, if there were only one symbol
  
  with the length 32, the earlier code would accept this un-Huffman-tree.
  Reviewed-by : Paul B Mahol <onemda@gmail.com>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavcodec/magicyuv.c

• How to detect noisy R channel in ffmpeg ? [closed]

  17 novembre 2024, par davidvankemenade

  Does anyone know how ffmpeg can identify that the R channel in the example below is noisy ?

  


  waveform : noisy R channel
flac file with noisy R channel

  


  For reference, the following file's R channel is not noisy (except from the first few seconds) :

  


  waveform : normal R channel
flac file with normal R channel

  


  How could ffmpeg be used to classify the first file as "poor" and the second file as "OK" ?

  


  I've not yet been able to find an example to solve this problem.

  


• YUV422 to TIFF and PNG conversion giving different values

  30 novembre 2019, par Garry

  I’ve been doing some work with images captured from a CMOS image sensor and saved to YUV422. I’ve converted them to TIFF and PNG formats using both ImageMagick and FFMPEG and done some analysis of the images and noticed that the RGB values differ between the two image formats. I’m a little confused as to why as they’re both lossless formats and the images are in the sRGB colourspace (verified with ImageMagick ’identify’ command).
  Do they not use the same YCbCr->sRGB conversion algorithm ? Am I missing something about the conversion process ?

  I used the following commands to convert the images :

  ffmpeg -pix_fmt uyvy422 -s 972x972 -i input.yuv output.png
  
  ffmpeg -pix_fmt uyvy422 -s 972x972 -i input.yuv output.tiff
  
  
  
  magick -size "972x972" pal:input.yuv output.png
  
  magick -size "972x972" pal:input.yuv output.tiff