Recherche avancée

Sur d’autres sites (6330)

• 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.

  


• ffmpeg : Extracted wav from mp4 video does not have equal duration as the original video

  26 juillet 2021, par John Smith

  I have a mp4 video that is 0.92 seconds, and I am trying to extract the audio of the video to a wav format. I have tried several commands (I have provided a list of some of the commands that I have tried), however, the resulting wav does not have the same duration as the original video (the resulting wav often has a duration of 0.96 seconds instead of 0.92 seconds). Ensuring that the video and audio are synchronous is crucial for what I am doing (the videos are typically videos of a person speaking, and it is important that the speech (audio) is in-sync with the mouth movements of the speaker).

  


  I find it odd that, by extracting audio from a video, the duration changes, even despite what is happening under the hood for the conversion (in terms of codecs used, etc).

  


  Some of the commands that I've tried include :

  


  ffmpeg -i <input /> -c copy -map 0:a -sample_rate 16000 <output>&#xA;&#xA;ffmpeg -i <input /> -async  1 -f wav <output>&#xA;&#xA;ffmpeg -i <input /> -vn -acodec copy <output>&#xA;&#xA;ffmpeg -i <input /> -ac 2 -f wav <output>&#xA;</output></output></output></output>

  


  Any insight would be highly appreciated.
Thanks !

  


  Edit Output of the command ffmpeg -ignore_editlist true -i 00026.mp4 output.wav

  


  ffmpeg version 2021-02-28-git-85ab9deb98-full_build-www.gyan.dev Copyright (c) 2000-2021 the FFmpeg developers
  built with gcc 10.2.0 (Rev6, Built by MSYS2 project)
  configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-lzma --enable-lib
snappy --enable-zlib --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libdav1d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --en
able-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libaom --enable-libopenjpeg --enable-libvpx --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libvidstab --e
nable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libglslang --enable-vulkan --
enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwben
c --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --en
able-libsoxr --enable-chromaprint
  libavutil      56. 66.100 / 56. 66.100
  libavcodec     58.126.100 / 58.126.100
  libavformat    58. 68.100 / 58. 68.100
  libavdevice    58. 12.100 / 58. 12.100
  libavfilter     7.107.100 /  7.107.100
  libswscale      5.  8.100 /  5.  8.100
  libswresample   3.  8.100 /  3.  8.100
  libpostproc    55.  8.100 / 55.  8.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '00026.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2mp41
    encoder         : Lavf57.37.101
  Duration: 00:00:00.98, start: 0.000000, bitrate: 599 kb/s
  Stream #0:0(und): Video: mpeg4 (Simple Profile) (mp4v / 0x7634706D), yuv420p, 160x160 [SAR 1:1 DAR 1:1], 556 kb/s, 25 fps, 25 tbr, 12800 tbn, 25 tbc (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
  Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 16000 Hz, mono, fltp, 65 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]
Stream mapping:
  Stream #0:1 -> #0:0 (aac (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
Output #0, wav, to 'output.wav':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2mp41
    ISFT            : Lavf58.68.100
  Stream #0:0(und): Audio: pcm_s16le ([1][0][0][0] / 0x0001), 16000 Hz, mono, s16, 256 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]
      encoder         : Lavc58.126.100 pcm_s16le
size=      32kB time=00:00:00.96 bitrate= 273.7kbits/s speed= 212x
video:0kB audio:32kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.238037%


  


• ffmpeg - Convert files but keep Same Date Modification as Original ?

  9 septembre 2021, par user5894146

  So I want to start with that ffmpeg and powershell isn't really my strength but I have been using the following powershell command to convert every .flac file in a certain directory to a 320K file.

  


  dir *.flac | foreach {ffmpeg -i $_.FullName -c:v copy  -b:a 320k  $_.FullName.Replace('flac', 'mp3')}


  


  This works exactly how I want to without any album art being transcoded but I want to incorporate a way so that the new .mp3 files that are created have the SAME DATE MODIFICATION value of the .flac files. Is something like this even possible ?

  


  audio_ex.flac = Date Modification: 1/1/2010
audio_ex.mp3 = Date Modification: 9/8/2021


  


  should be instead

  


  audio_ex.flac = Date Modification: 1/1/2010
audio_ex.mp3 = Date Modification: 1/1/2010


  


  I have a folder of 6K files and want each original date modified to match the newly created files so if I can do the above command and also have the date mod time match within one execution, that would be ideal.

  


  I thought of manually changing each files mod time using 3rd party tools but it will be too time consuming.