Recherche avancée

Sur d’autres sites (7475)

• Getting motion vector side data from ffmpeg from the compressed domain (without performing full decode)

  4 mai 2019, par John Allard

  The ffmepg source code comes with a file extract_mvs.c which is quite helpful in showing how to extract the motion vectors from an h264-encoded video file. Unfortunately, it performs a full decode before getting the motion vectors from the side data of the stream.

  One should be technically able to (as was confirmed by FFMPEG developer Carl Eugen in this thread https://ffmpeg.org/pipermail/libav-user/2016-December/009913.html) get the motion vectors from the compressed domain before performing a full decode step. This would obviously be less computationally intensive as one wouldn’t have to perform a full decode.

  Is it possible to do this with ffmpeg/libavcodec as is ? I know Carl said that it wasn’t possible but that was 3 years ago. If it is not currently possible, does anyone have any hints on how one would go about modifying the ffmpeg source code to do this ?

  Thanks

• avutil/hwcontext_videotoolbox : BGRA should be full range

  3 janvier 2023, par Zhao Zhili

  avutil/hwcontext_videotoolbox : BGRA should be full range
  HEVC alpha layer encoding is broken without the patch.
  Signed-off-by : Zhao Zhili <zhilizhao@tencent.com>
  

  • [DH] libavutil/hwcontext_videotoolbox.c

• Real-Time Buffer Too Full (FFMPEG)

  25 janvier 2018, par Nimble

  So I’ve been having this issue with ffmpeg, it has been a journey getting the hardware and command to actually do what I want, but I still have one problem.

  Sometimes when I’m recording I just start dropping frames like crazy, this can be after an hour of recording or even ten hours in... Everything will be working fine and then suddenly I’ll start dropping frames due to "real-time buffer too full or near too full". This happens regardless of how low I put the bitrate, and the buffer size is high as it will allow, eventually I’ll just start dropping frames. Almost seems like it could be like a power saving feature kicking in but it’s too inconsistent it seems. Like I said sometimes I can go 10 hours without having this issue.

  Any ideas ?

  Here is my block of code :

  ffmpeg -guess_layout_max 0 -y -f dshow -video_size 3440x1440 -rtbufsize 2147.48M -pixel_format nv12 -framerate 200 ^
  
  -i video="Video (00 Pro Capture HDMI 4K+)":audio="SPDIF/ADAT (1+2) (RME Fireface UC)" -map 0:0,0:1 -map 0:1 ^
  
  -preset: llhp -codec:v h264_nvenc -pix_fmt nv12 -b:v 250M -maxrate:v 250M -minrate:v 250M -bufsize:v 250M -b:a 320k ^
  
  -ac 2 -r 100 -async 1 -vsync 1 -segment_time 600 -segment_wrap 9 -f segment C:\Users\djcim\Videos\PC\PC%02d.mp4 ^
  
  -guess_layout_max 0 -f dshow -rtbufsize 2000M -i audio="Analog (3+4) (RME Fireface UC)" -map 1:0 -b:a 320k -ac 2 ^
  
  -af "adelay=200|200" -segment_time 600 -segment_wrap 9 -f segment C:\Users\djcim\Videos\PC\Voices\Theirs\TPC%02d.wav ^
  
  -guess_layout_max 0 -f dshow -rtbufsize 2000M -i audio="Analog (5+6) (RME Fireface UC)" -map 2:0 -b:a 320k -ac 2 ^
  
  -af "adelay=825|825" -segment_time 600 -segment_wrap 9 -f segment C:\Users\djcim\Videos\PC\Voices\Mine\MPC%02d.wav

  Here is the error, it repeated around 300 times before locking up ffmpeg forcing my to quit before starting the recording again :

  [dshow @ 0000019a596bdcc0] real-time buffer [Video (00 Pro Capture HDMI 4K+)] [video input] too full or near too full (62% of size: 2147480000 [rtbufsize parameter])! frame dropped!