Recherche avancée

Sur d’autres sites (6076)

• avcodec_encode_video2 crash on MinGW32 (but not on MinGW64)

  27 février 2018, par ksb496

  I have been testing for years a software that I am developing, compiled only for 64-bit systems through Qt-MinGW64, without experiencing any kind of issue regarding video encoding (which is one of the features of such application). Recently, I have been attempting to build the corresponding x86 version of my software by compiling it with Qt-MingGW32.

  However, after bulding the same ffmpeg and x264 library versions to create the 32-bit versions and successfully linking them to my project, the application keeps crashing after few frames are encoded, due to segmentation fault error. This is very strange because, as I indicated before, it works flawlessly when compiled for 64-bit systems.

  I have also lost a considerable amount hours trying to combine a big amount of different versions of both ffmpeg and x264 libraries, but with no luck either. Neither it works when disabling threads both for x264 and ffmpeg libraries, hence it does not seem to be a win32 threading issue. Therefore, I have concluded that the error is most likely in my code, which by some chance beyond my comprehension tells ffmpeg to allocate the right amount of memory in the x64 version, but not in the x86 version.

  It must be pointed out also that before the avcodec_encode_video2 call, I do the following calls, among others, in order to allocate the memory associated to the corresponding items (AVFrame, AVCodec, etc.), such as

  avcodec_open2( my_codec_context, my_codec, &opt );
  
  my_av_frame=av_frame_alloc();

  More precisely, the details involving the code structure that I am using can be found here.

  Therefore, the error appears to be more subtle than just issues regarding uninitialized memory.

  Many thanks in advance.

  UPDATE :

  I have discovered the focus of the problem. For some reason, FFmpeg/x264 libraries behave abnormally in Win32 GUI applications compiled with Qt-MinGW32, while they run correctly in Win32 console applications, also compiled with Qt-WinGW32. I have proven this claim performing two dummy tests, in which the exact same piece of code is run through a console application and on a GUI application, succeeding in the first case and failing in the latter one. The code for such tests can be found below, along with the x264 and FFmpeg libraries used in my projects, together with instructions to build them in msys2 with MinGW32 :

  https://takeafile.com/?f=hisusinivi

  I have no idea whether it can be solved by simply tweaking the code or it is a serious bug involving an incompatibility issue. If it is the latter, should it be reported to the Qt/FFmpeg/x264 staff as a major bug ?

• avcodec_encode_video2 crash on MinGW32 (but not on MinGW64)

  27 février 2018, par ksb496

  I have been testing for years a software that I am developing, compiled only for 64-bit systems through Qt-MinGW64, without experiencing any kind of issue regarding video encoding (which is one of the features of such application). Recently, I have been attempting to build the corresponding x86 version of my software by compiling it with Qt-MingGW32.

  However, after bulding the same ffmpeg and x264 library versions to create the 32-bit versions and successfully linking them to my project, the application keeps crashing after few frames are encoded, due to segmentation fault error. This is very strange because, as I indicated before, it works flawlessly when compiled for 64-bit systems.

  I have also lost a considerable amount hours trying to combine a big amount of different versions of both ffmpeg and x264 libraries, but with no luck either. Neither it works when disabling threads both for x264 and ffmpeg libraries, hence it does not seem to be a win32 threading issue. Therefore, I have concluded that the error is most likely in my code, which by some chance beyond my comprehension tells ffmpeg to allocate the right amount of memory in the x64 version, but not in the x86 version.

  It must be pointed out also that before the avcodec_encode_video2 call, I do the following calls, among others, in order to allocate the memory associated to the corresponding items (AVFrame, AVCodec, etc.), such as

  avcodec_open2( my_codec_context, my_codec, &opt );
  
  my_av_frame=av_frame_alloc();

  More precisely, the details involving the code structure that I am using can be found here.

  Therefore, the error appears to be more subtle than just issues regarding uninitialized memory.

  Many thanks in advance.

  UPDATE :

  I have discovered the focus of the problem. For some reason, FFmpeg/x264 libraries behave abnormally in Win32 GUI applications compiled with Qt-MinGW32, while they run correctly in Win32 console applications, also compiled with Qt-WinGW32. I have proven this claim performing two dummy tests, in which the exact same piece of code is run through a console application and on a GUI application, succeeding in the first case and failing in the latter one. The code for such tests can be found below, along with the x264 and FFmpeg libraries used in my projects, together with instructions to build them in msys2 with MinGW32 :

  https://takeafile.com/?f=hisusinivi

  I have no idea whether it can be solved by simply tweaking the code or it is a serious bug involving an incompatibility issue. If it is the latter, should it be reported to the Qt/FFmpeg/x264 staff as a major bug ?

• ffmpeg problem with split & combine portions of same video [closed]

  10 février 2024, par icyGuy

  I'm trying to split & combine multiple portions of the same video file.

  


  Since there are multiple portions that I want to combine, I want to use filtercomplex to do this.

  


  Also, since some of the portions are quite small in duration, I want to use precise timestamps (setpts=PTS-STARTPTS)

  


  Please see the code below inside the "script.txt" file.

  


  [0:v]trim=0.823625:5.88717,setpts=PTS-STARTPTS[v0];
[0:a]atrim=0.823625:5.88717,asetpts=PTS-STARTPTS[a0];
[0:v]trim=6.87858:10.2093,setpts=PTS-STARTPTS[v1];
[0:a]atrim=6.87858:10.2093,asetpts=PTS-STARTPTS[a1];
[0:v]trim=10.5683:11.5989,setpts=PTS-STARTPTS[v2];
[0:a]atrim=10.5683:11.5989,asetpts=PTS-STARTPTS[a2];
[0:v]trim=11.9066:13.2301,setpts=PTS-STARTPTS[v3];
[0:a]atrim=11.9066:13.2301,asetpts=PTS-STARTPTS[a3];
[0:v]trim=14.2123:14.903,setpts=PTS-STARTPTS[v4];
[0:a]atrim=14.2123:14.903,asetpts=PTS-STARTPTS[a4];
[0:v]trim=15.2467:16.5819,setpts=PTS-STARTPTS[v5];
[0:a]atrim=15.2467:16.5819,asetpts=PTS-STARTPTS[a5];
[0:v]trim=17.1012:20.1223,setpts=PTS-STARTPTS[v6];
[0:a]atrim=17.1012:20.1223,asetpts=PTS-STARTPTS[a6];
[0:v]trim=20.9504:22.5714,setpts=PTS-STARTPTS[v7];
[0:a]atrim=20.9504:22.5714,asetpts=PTS-STARTPTS[a7];
[0:v]trim=23.4482:24.8745,setpts=PTS-STARTPTS[v8];
[0:a]atrim=23.4482:24.8745,asetpts=PTS-STARTPTS[a8];
[0:v]trim=25.5697:26.8718,setpts=PTS-STARTPTS[v9];
[0:a]atrim=25.5697:26.8718,asetpts=PTS-STARTPTS[a9];
[0:v]trim=27.5758:27.9942,setpts=PTS-STARTPTS[v10];
[0:a]atrim=27.5758:27.9942,asetpts=PTS-STARTPTS[a10];
[0:v]trim=28.5431:30,setpts=PTS-STARTPTS[v11];
[0:a]atrim=28.5431:30,asetpts=PTS-STARTPTS[a11];
[v0][a0][v1][a1][v2][a2][v3][a3][v4][a4][v5][a5][v6][a6][v7][a7][v8][a8][v9][a9][v10][a10][v11][a11]
concat=n=12:v=1:a=1[outv][outa]


  


  The command that I am using to run ffmpeg with this script file is as below

  


  ffmpeg -i "input.mp4" -c:v libx265 -filter_complex_script "script.txt" -map [outv] -map [outa] "output.txt"


  


  But, after running this command, the output video file is only 5 seconds long (the very first portion of the input video).

  


  As we can see from the first line of the "script.txt", the start timestamp is 0.8 & the end timestamp is 5.8 giving a duration of 5s for the first piece of the output video.

  


  So, ffmpeg is not joining any other parts of the input video after the first part. I am unable to understand why so.

  


  I am facing this problem since the past couple of months after i updated ffmpeg. The same syntax of script file & command line used to work fine before that. Did any changes in the update alter the syntax that ffmpeg expects for this task ?

  


  Any help is much appreciated.