Sur d’autres sites (8745)

• Ffmpeg cpp libav randomly uses high cpu and less gpu or uses high gpu and less cpu with hw accel

  29 avril 2024, par cngkyt

  I am using ffmpeg as library with cpp
the integration of library is perfectly done i am using AVFilterGraph as audio resampler and video pixfmt converter.

  


  I cannot share code because it is a complete library and contains too many files but i can assure there is no problem about code but maybe approach.

  


  My whole class is based on the transcode example of ffmpeg
text

  


  The problem is when i run my program that encodes approx 90 streams

  


  it starts with 25% cpu usage 80% gpu encode usage %85 gpu decode usage with 100% sm utilization

  


  or

  


  it starts with 80% cpu usage 45% gpu encode usage 50% gpu decode usage with 60% sm utilization

  


  when it start like second type of utilization videos are perfect
but when it starts like the first type of utilization videos are freezing

  


  my program uses pure gpu for encoding for all streams but using gpu decoding for every 3 cpu deoding
that means i use hwaccel for 1/3 of streams
because my cards are 4070 ti super and they have 2 NVENC 1 NVDEC chips

  


  my program takes udp streams and encode it and outputs udp mpegts

  


  bitrate and quality settings are persistent across streams depending on resolution

  


  i always test on same streams

  


  the problem happens randomly
but if it starts with high cpu and low gpu utilization it goes on like this
when i restart program problem occurs randomly again

  


  what can couse this

  


  just as an info i have experience on c++ more than 25 years

  


  if there is someone who can teach me something i will be happy

  


  thanks for your further helps

  


  i have tried to reproduce it with compiled ffmpeg instead of my libav library usage
same thing happens but not often

  


  i have tried using hevc_cuvid instead of hwacceleration with avcodec_find_decoder_by_name function

  


• ffmpeg audio out of sync with video stacking

  3 avril 2024, par s0mbre

  The problem

  


  When trying to do horizontal stacking of two videos in ffmpeg, the combined audio track loses sync with the video on the second input. As far as I've look it up, this problem is very common, not to say notorious with ffmpeg.

  


  I do hstack muxing like this :

  


  ffmpeg -i 1.mp4 -i 2.mp4 -filter_complex \
"[0:v]scale=1280:-2,crop=w=640:h=720:x=0[v1]; \
[1:v]scale=1280:-2,crop=w=640:h=720:x=0[v2]; \
[v1][v2]hstack=shortest=1[v]; \
[0:a][1:a]amix=duration=shortest[a]" \
-map [v] -map [a] -c:v libx264 -c:a libmp3lame -r 30 -y stuff/out.mp4


  


  It encodes just fine as far as the hsplit goes. But the resulting video is out of sync with the audio : the second input (located on the right side in the resulting split) demonstrates about 3 sec. audio off-syncking, where the audio track is ahead of the picture. I realize this is somehow connected with the source videos' timestamps, but no popular remediation recipes helped (see below).

  


  What I expect

  


  I'd expect a resulting stacked video where the audio track is muxed with exact correspondence to the original input pictures.

  


  What I tried (all in vain !)

  


  Something I've tried but to no avail :

  


  

  1. Appending -async 1 option as suggested here and here

  


  2. Using the aresample=async=1 or aresample=async=1000 filter on each audio input as suggested here and here

  


  3. Padding each audio track with apad as suggested here

  


  4. Using the adelay=0 and adelay=[delay]s filters on the failing input

  


  5. Changing the audio codec to a number of alternatives (aac etc.)

  


  6. Infinite combinations of 1-5 above...

  


  


  What seems indeed to work is manual passing a delay value to the -itsoffset filter as suggested here and in the docs and using the offset track as an extra (pure audio) input. But how do I find the exact offset with a different set of videos ?

  


  In short, I am at a standstill after 7+ days of ravenous search-and-try.

  


• aarch64 : hevc : Split the epel_*_hv functions into two parts

  12 mars 2024, par Martin Storsjö

  aarch64 : hevc : Split the epel_*_hv functions into two parts
  The first horizontal filter can use either i8mm or plain neon
  
  versions, while the second part is a pure neon implementation.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavcodec/aarch64/hevcdsp_epel_neon.S