Recherche avancée

Sur d’autres sites (13234)

• Configure error for ffmpeg 6.1 when executing in bash 5.0.17

  1er mars 2024, par user2715311

  I am trying to install ffmpeg 6.1 (https://ffmpeg.org/releases/ffmpeg-6.1.1.tar.xz), but when executing the configure script my bash version 5.0.17 removes the double quotes from the parameters containing the condition to select the version of the libraries being searched for to pass this parameter to pkg-config.

  


  For example, when processing code

  


  check_pkg_config libopenjpeg "libopenjp2 >= 2.1.0" openjpeg.h opj_version


  


  , the pkg-config call will look something like

  


  pkg-config --exists libopenjp2 >= 2.1.0


  


  As a result, configure execution stops with the following error.

  


  ERROR: libopenjp2 >= 2.1.0 not found using pkg-config


  


  As a hint, you may be prompted to set the path to the 2.1.0.pc file in PKG_CONFIG_PATH.

  


  It is interesting that this is the case in other versions of bash, for example, this problem is not observed in version 5.1.16.

  


  Does this mean that bash version 5.0.17 will actually not be able to work with configure to build most code sources, because such version selection conditions are used quite often when searching for the right libraries ?

  


  Or perhaps I can influence this bash behaviour in some way ? Or, alternatively, have I misinterpreted the problem at all and the solution is in a completely different area ?

  


  The problem was identified in the Linux Mint 20.1 distribution.

  


  $ lsb_release -a
No LSB modules are available.
Distributor ID: Linuxmint
Description:    Linux Mint 20.1
Release:    20.1
Codename:   ulyssa


  


  First of all, I checked that if I call pkg-config correctly, it can find the right library on my system.

  


  $ pkg-config --exists "libopenjp2 >= 2.1.0"
$ echo $?
0


  


  or

  


  $ pkg-config --cflags --libs "libopenjp2 >= 2.1.0"
-I/usr/include/openjpeg-2.3 -lopenjp2


  


  Next, I examined the configure code associated with this problem and came to the conclusion I outlined above.

  


• 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