Recherche avancée

Sur d’autres sites (10921)

• avcodec/pngdec : Fix APNG_DISPOSE_OP_BACKGROUND

  20 août 2022, par Andreas Rheinhardt

  avcodec/pngdec : Fix APNG_DISPOSE_OP_BACKGROUND
  APNG works with a single reference frame and an output frame.
  
  According to the spec, decoding APNG works by decoding
  
  the current IDAT/fdAT chunks (which decodes to a rectangular
  
  subregion of the whole image region), followed by either
  
  overwriting the region of the output frame with the newly
  
  decoded data or by blending the newly decoded data with
  
  the data from the reference frame onto the current subregion
  
  of the output frame. The remainder of the output frame
  
  is just copied from the reference frame.
  
  Then the reference frame might be left untouched
  
  (APNG_DISPOSE_OP_PREVIOUS), it might be replaced by the output
  
  frame (APNG_DISPOSE_OP_NONE) or the rectangular subregion
  
  corresponding to the just decoded frame has to be reset
  
  to black (APNG_DISPOSE_OP_BACKGROUND).
  The latter case is not handled correctly by our decoder :
  
  It only performs resetting the rectangle in the reference frame
  
  when decoding the next frame ; and since commit
  
  b593abda6c642cb0c3959752dd235c2faf66837f it does not reset
  
  the reference frame permanently, but only temporarily (i.e.
  
  it only affects decoding the frame after the frame with
  
  APNG_DISPOSE_OP_BACKGROUND). This is a problem if the
  
  frame after the APNG_DISPOSE_OP_BACKGROUND frame uses
  
  APNG_DISPOSE_OP_PREVIOUS, because then the frame after
  
  the APNG_DISPOSE_OP_PREVIOUS frame has an incorrect reference
  
  frame. (If it is not followed by an APNG_DISPOSE_OP_PREVIOUS
  
  frame, the decoder only keeps a reference to the output frame,
  
  which is ok.)
  This commit fixes this by being much closer to the spec
  
  than the earlier code : Resetting the background is no longer
  
  postponed until the next frame ; instead it is applied to
  
  the reference frame.
  Fixes ticket #9602.
  (For multithreaded decoding it was actually already broken
  
  since commit 5663301560d77486c7f7c03c1aa5f542fab23c24.)
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/pngdec.c

• ffmpeg : concatinating files creates audio artefacts

  28 octobre 2022, par LML

  I'm currently trying to create a video out of multiple short video files. However, the final video always has audio artefacts, where it sounds like a short high pitch or echo at certain times during the audio. All the audio is a text-to-speech generated voice. No music. The artefacts appear sometimes more, sometimes less. But I would obviously prefer to have 0 of it.

  


  My starting point is a long audio file (mono with audio codec "mp3" according to ffprobe). Within that file are a bunch of short pauses of 4-5 seconds. I detect the silences and create individual audio files from there. Afterwards I create an mp4 file with this audio and a still image. Up to this point, the audio is perfectly fine and sounds the exact same as in the original file.

  


  After this I want to create the final video : each of the individual parts added into one long video. There is a transition between each file to mark the changing of image and audio. But even when skipping the transition and simply adding all of these clips that were generated the same way together, the artefacts are still present.

  


  The commands I use to create the different files.

  


  Create individual audio files :
.\ffmpeg.exe -y -hide_banner -i TTSAudio.mp3 -ss 359.944 -to 372.02479 -c copy partXY.mp3

  


  Create individual video files by using a .png file as the video stream and the partXY.mp3 as the audio stream :
.\ffmpeg.exe -y -hide_banner -framerate 30 -loop 1 -i XY_full.png -i partXY.mp3 -c:v libx265 -c:a copy -shortest partXY.mp4

  


  For concatenating the files :
.\ffmpeg.exe -y -hide_banner -i part000.mp4 -i part001.mp4 -i part002.mp4 -filter_complex "[0:v] [0:a] [1:v] [1:a] [2:v] [2:a] concat=n=3:v=1:a=1 [v] [a]" -map "[v]" -map "[a]" -c:v copy -c:a copy final_video.mp4

  


  I've tried a lot of different things and codecs for the audio, without any luck. I use h265, as using h264 was causing weird video artefacts after uploading the file to YouTube.
I have tried reencoding, instead of copying (-c:a copy) at various stages, especially the final video. All without any luck.
I've used the different concatenation where you provide a list of files, which created a whole different set of problems.

  


  I've managed to filter the artefacts out by using -af "lowpass=f=2800", but that changes the voice a lot. I was also not able to notice the pitch visually when opening the audio in audacity, for example.

  


  Example :
https://soundcloud.com/thelml/sets/ffmpeg-audio-artefacts/s-LNr6UaMPgz9?si=f7b30e1e64bf4333ad055fa1fe21e9ec
Due to the files being so short, I seem to have to sometimes have to replay the bugged file to hear the artefact.

  


  So my question is : how do I fix this, without using a lowpass that basically changes the whole voice ?

  


• hw_base_encode : make recon_frames_ref optional

  30 août 2024, par Lynne

  hw_base_encode : make recon_frames_ref optional
  Vulkan supports some stupidly odd hardware, that unfortunately,
  
  most modern GPUs happen to be.
  
  The DPB images for encoders may be required to be preallocated
  
  all at once, and rather than be individual frames, be layers of
  
  a single frame.
  As the hw_base_encode code is written with the thought that either
  
  the driver or the device itself supports sane image allocation,
  
  Vulkan does not leave us with this option.
  So, in the case that the hardware does not support individual
  
  frames to be used as DPBs, make the DBP frames context optional,
  
  and let the subsystem manage this.
  

  • [DH] libavcodec/hw_base_encode.c