Recherche avancée

Sur d’autres sites (12548)

• Why JPEG compressing an uncompressed image differs its original (FFmpeg, NvJPEG, ...)

  22 juin 2021, par Fruchtzwerg

  I am currently struggling to understand why recompressing an uncompressed JPEG image differs its original.

  


  It's clear, that JPEG is a lossy compression, but what if the image to compress is already uncompressed, which means all sampling losses are already included ? In other words : Downsampling and DCT should be inversable at this point without loosing data.

  


  

  


  To make sure losses are not effected by the color space conversion, this step is skipped and YUV images are used.

  


  

  1. Compress YUV image to JPEG (image.yuv —> image.yuv.jpg)

  


  2. Uncompress JPEG image to YUV image (image.yuv.jpg —> image.yuv.jpg.yuv)

  


  3. Compress YUV image to JPEG (image.yuv.jpg.yuv —> image.yuv.jpg.yuv.jpg)

  


  4. Uncompress JPEG image to YUV image (image.yuv.jpg.yuv.jpg —> image.yuv.jpg.yuv.jpg.yuv)

  


  


  Step 1 includes a lossy compression, so we will not deal with this step anymore. For me, intresting is what happens afterwards :

  


  Uncompressing the JPEG image back to YUV (step 2) leads to an image which perfectly fits all sampling steps if compressed again (step 3). So the JPEG image after step 3 should (from my understanding) be exactly the same as after step 1. Also the YUV images after step 4 and step 2 should equal each other.

  


  Looking at the steps for one 8x8 block the following simplified sequence should illustrate what I am trying to descibe. Lets start with the original YUV image, which can only be decompressed loosing all decimal places :

  


  [ 1.123, 2.345, 3.456, ... ]    (YUV)
    DTC + Quantization
[ -26, -3, -6, ... ]            (Quantized frequency space)
    Inverse DTC + Quantization
[ 1, 2, 3, ... ]                (YUV)


  


  Doing this with input, which already matches all steps, which may lead to loss of data afterwards (using round numbers in my example), the decompressed image should match its original :

  


  [ 1, 2, 3, ... ]                (YUV)
    DTC + Quantization
[ -26, -3, -6, ... ]            (Quantized frequency space)
    Inverse DTC + Quantization
[ 1, 2, 3, ... ]                (YUV)


  


  There are also some sources and discussions, which are confirming my idea :

  


  

  • need help creating Jpeg Generational Degradation code

  


  • What factors cause or prevent “generational loss” when JPEGs are recompressed multiple times ?

  


  • Lossless Chroma Subampling

  


  


  So much for theory. In praxis, I've runned these steps using ffmpeg and Nvidias jpeg samples (using NvJPEGEncoder).

  


  ffmpeg :

  


  #Create YUV image
ffmpeg -y -i image.jpg -s 1920x1080 -pix_fmt yuv420p image.yuv
#YUV to JPEG
ffmpeg -y -s 1920x1080 -pix_fmt yuv420p -i image.yuv image.yuv.jpg
#JPEG TO YUV
ffmpeg -y -i image.yuv.jpg -s 1920x1080 -pix_fmt yuv420p image.yuv.jpg.yuv
#YUV to JPEG
ffmpeg -y -s 1920x1080 -pix_fmt yuv420p -i image.yuv.jpg.yuv image.yuv.jpg.yuv.jpg
#JPEG TO YUV
ffmpeg -y -i image.yuv.jpg.yuv.jpg -s 1920x1080 -pix_fmt yuv420p image.yuv.jpg.yuv.jpg.yuv
#YUV to JPEG
ffmpeg -y -s 1920x1080 -pix_fmt yuv420p -i image.yuv.jpg.yuv.jpg.yuv image.yuv.jpg.yuv.jpg.yuv.jpg


  


  Nvidia :

  


  #Create YUV image
./jpeg_decode num_files 1 image.jpg image.yuv
#YUV to JPEG
./jpeg_encode image.yuv 1920 1080 image.yuv.jpg
#JPEG TO YUV
./jpeg_decode num_files 1 image.yuv.jpg image.yuv.jpg.yuv
#YUV to JPEG
./jpeg_encode image.yuv.jpg.yuv 1920 1080 image.yuv.jpg.yuv.jpg
#JPEG TO YUV
./jpeg_decode num_files 1 image.yuv.jpg.yuv.jpg image.yuv.jpg.yuv.jpg.yuv
#YUV to JPEG
./jpeg_encode image.yuv.jpg.yuv.jpg.yuv 1920 1080 image.yuv.jpg.yuv.jpg.yuv.jpg


  


  But a comparison of the images

  


  

  • image.yuv.jpg.yuv and image.yuv.jpg.yuv.jpg.yuv

  


  • image.yuv.jpg.yuv.jpg and image.yuv.jpg.yuv.jpg.yuv.jpg

  


  


  showing differences in the files. That brings me to my question why and where the difference gets happen, since from my understanding the files should be equal.

  


• Overlay Video on Video FFMPEG

  9 août 2017, par user3354787

  I have found a link explaining how to do this, however I do not know how to do it with a streaming video. FFmpeg - Overlay one video onto another video ?

  I am running a robot that uses FFMPEg to send straming video to letsrobot.tv You can see my bot on the website called patton II. I wnated to overlay a video HUD on the stream. If you can help me with a step by step that would be great. Sorry for such an open ended question but I am new to this whole thing but i will correct it or answer anything you need in order for you to help me

      overlayCommand = '-vf dynoverlay=overlayfile=/home/pi/runmyrobot/images/hud.png:check_interval=500'
  
  videoCommandLine = '/usr/local/bin/ffmpeg -f v4l2 -framerate 25 -video_size 640x480 -i /dev/video%s %s -f mpegts -codec:v mpeg1video -s 640x480 -b:v %dk -bf 0 -muxdelay 0.001 %s http://%s:%s/hello/640/480/' % (deviceAnswer, rotationOption, args.kbps, overlayCommand, server, videoPort)
  
  audioCommandLine = '/usr/local/bin/ffmpeg -f alsa -ar 44100 -i hw:1 -ac 2 -f mpegts -codec:a mp2 -b:a 32k -muxdelay 0.001 http://%s:%s/hello/640/480/' % (server, audioPort)

• html5 video tag m3u8 file not working

  9 décembre 2014, par Mr.Park

  Step 1. ffmpeg work : .mp4 -> .m3u8 and .tp Files create

  ffmpeg options :

  ffmpeg -y -i Internet.mp4 -pix_fmt yuv420p -vcodec libx264 -acodec ac3 -r 30 -profile:v baseline -b:v 1500k -maxrate 2000k -s 480x300 -map 0 -flags -global_header -f segment -segment_list index_1500.m3u8 -segment_time 10 -segment_format mpeg_ts -segment_list_type m3u8 segment%05d.ts

  Like this

  Step 2. HTML5 programing

  < !DOCTYPE html>
  
  
  
  < html>
  
  
  
  < head>
  
  
  
  < title > Storage.html < /title >
  
  
  
  < /head >
  
  
  
  < body >
  
  
  
  < video width="352" height="198" src="index_1500.m3u8"/>
  
  
  
  < /body>
  
  
  
  < /html>

  html file create

  but video play not working...

  but, vlc media player [index_1500.m3u8] file play very well

  Please Help..