Recherche avancée

Sur d’autres sites (11425)

• Wrong video duration when trying to make screen capture with libav\ffmpeg

  16 juin 2023, par Ларионов Фёдор

  I am performing screen capture using libav/c++ with the gdbigrab InputFormat and saving the transcoded video with h.264 to an .mp4 container. Despite doing all the necessary conversions from pts/dts frames and packets, the final video has an issue with its duration. When playing the video, it stops a few seconds before the end and rewinds back to the end.

  


  To diagnose the problem, I used FFprobe to examine the recorded video stream and found the following issues :

  


  ffprobe my_video.mp4 -show_streams

  


  Provides the following information :

  


  time_base=1/12800
start_pts=28096
start_time=2.195000
duration_ts=38945
duration=3.042578


  


  Although I tracked the frame and burst timestamps while recording, starting at zero and ending at the expected pts for the number of frames recorded, I tried to set the start and end time of the stream manually. I observed this problem with different time_base and different video durations, do some minor and major fixes that does not affected this issue. Interestingly, the start time always has the same offset, and the expected/specified video duration in the code is close to the sum of the duration of the video stream and its start time. What am I missing ?

  


  


  UPDATE :

  


  


  There is the source of problem :

  


  [mov,mp4,m4a,3gp,3g2,mj2 @ 000002a69f15b380] Processing st: 0, edit list 0 - media time: -1, duration: 27059
[mov,mp4,m4a,3gp,3g2,mj2 @ 000002a69f15b380] Processing st: 0, edit list 1 - media time: 0, duration: 38912 


  


  which i get by that command ffmpeg -hide_banner -y -v 9 -loglevel 99 -i sc_test.mp4

  


  The question is where this edits happend.

  


• libavformat/mov.c : use calculated dts offset when seeking in streams

  29 octobre 2017, par Jonas Licht

  libavformat/mov.c : use calculated dts offset when seeking in streams
  Subtract the calculated dts offset from the requested timestamp before
  
  seeking. This fixes an error "Error while filtering : Operation not
  
  permitted" observed with a short file which contains only one key frame
  
  and starts with negative timestamps.
  Then, av_index_search_timestamp() returns a valid negative timestamp,
  
  but mov_seek_stream bails out with AVERROR_INVALIDDATA.
  Fixes ticket #6139.
  Signed-off-by : Jonas Licht <jonas.licht@fem.tu-ilmenau.de>
  
  Signed-off-by : Peter Große <pegro@friiks.de>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/mov.c
  • [DH] tests/ref/seek/extra-mp4

• checkasm : Remove unnecessary const on scalar parameters

  15 décembre 2023, par Martin Storsjö

  checkasm : Remove unnecessary const on scalar parameters
  The ffmpeg coding style doesn't usually use const on scalar
  
  parameters (or on the pointer values - as opposed to the type
  
  that is pointed to, where it has a semantic meaning), contrary
  
  to the dav1d coding style (where this was imported from).
  This avoids warnings about differences in the type signatures
  
  between declaration and definition of this function, with older
  
  versions of MSVC.
  The issue was observed with one version of MSVC 2017,
  
  19.16.27024.1, with warnings like these :
      src/tests/checkasm/checkasm.c(969) : warning C4028 : formal parameter 3 different from declaration
  The warning itself is bogus as the const here is harmless, and
  
  newer versions of MSVC no longer warn about this.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] tests/checkasm/checkasm.c
  • [DH] tests/checkasm/checkasm.h