Recherche avancée

Sur d’autres sites (7676)

• Re-encoding vlc-created mpeg2 .ts file results in 20 second file ; AKA : multi-stream file with hidden streams

  6 septembre 2017, par insaner

  I was recording something with vlc off v4l2 (in case that makes a difference), and I just selected the first format that worked, being mpeg2 using TS container. File resulted in .ts extension, as automatically selected by vlc. When I then tried to put the video file in my video editor, it said the video was 19,884 hours long, when it should be about 6 minutes (it is 80mb in size). When I try to play it in xine, it correctly shows the duration (vlc doesn’t), and when I use ffprobe :

  [mpegts @ 0x9b2c0a0] max_analyze_duration 5000000 reached at 5000000
  
  Input #0, mpegts, from 'loopbacktestcap.ts':   Duration: N/A, start:
  
  17978.139456, bitrate: N/A   Program 1 
  
       Stream #0:0[0x44](): Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p, 640x480 [SAR 1:1 DAR 4:3], 104857 kb/s, 30 fps, 30
  
  tbr, 90k tbn, 60 tbc
  
       Stream #0:1[0x46](): Video: mpeg2video ([2][0][0][0] / 0x0002), 90k tbn

  Notice especially this line :

     Duration: N/A, start: 17978.139456, bitrate: N/A   Program 1 

  I looked it up and it seems the lack of duration has to do with the container. But I have tried a few things to reencode (I tried -vcodec copy, mpeg2, libx264...) and all I can get is 20 second files of 1.1mb - 1.8mb.

  So how can I reencode this file so the duration appears, and I get the full 6 minutes, instead of just the first 20 seconds ?

• Compiling FFmpeg with Libass using MSVC

  2 avril 2019, par maxhap

  First a bit of background.

  I’m trying to compile ffmpeg on windows with the libass extensions/configuration option.

  Using the visual studio project libass-msvc I built libass using Visual Studio as a static lib.

  I then installed MinGW with MSYS and pkg-config. Following the instructions on the ffmpeg MSVC installation guide I configured the environment to build with the MSVC linker and to build in x64.

  When I try to configure libass for compilation using ./configure —enable-libass —toolchain=msvc I get the following error in the log file :

  File not found ass/ass.h

  pkg-config can not find libass

  I have tried the following to fix this.

  1. Create a .pc file for libass and add this to the PKG_CONFIG_PATH environment variable. See file content below. (After doing this pkg-config libass —version prints 0.81, not the right version number but at least something.)

  2. Copy libass .h files into a MinGW/include/ass folder and the .lib file into the MinGW/libs folder.

  3. Add libass include and bin folders to PATH environment variable

  4. Download libass and dependencies source then try to build it using MSYS with MSVC compiler. My aim here was to be able to use "make install" and let MinGW install libass to the correct locations. After hours of trying to fix linker errors, I abandoned this idea as some of the libass dependencies make files only work with the GCC GNU compiler.

  5. Compile libass with GCC GNU using MinGW make/make install then try and install libass using the GNU libs. Again this led to linker errors (I know this was a bad idea but was worth a try).

  6. Tried using extra lib and include build configuration options —extra-cflags="ffmpeg-dir/extra/include" \
     — extra-ldflags="ffmped-dir/extra/ffmpeg_build/lib" then adding the libs and .h files into those locations

  .pc file

  libass.pc:
  
  prefix=/MinGW
  
  includedir=libass-directory/include
  
  libdir=libass-director/x64/bin/
  
  
  
  Name: libass
  
  Description: Libass project
  
  Version: 0.13.7

  I am now completely stuck and out of ideas if anyone could give any insight or suggestions into what I’m doing wrong that would be fantastic.

  Update

  I created INCLUDE and LIBDIR environment path variable containing the libass paths. Which now correctly includes libass. However, I now get the following linker error for the function check_ass_library_init.

  check_func_headers ass/ass.h ass_library_init
  check_ld cc
  check_cc
  BEGIN ./ffconf.RZMYFWdc/test.c
  1 #include
  2 #include
  3 long check_ass_library_init(void) return (long)
  ass_library_init ;
  4 int main(void) int ret = 0 ;
  5 ret |= ((intptr_t)check_ass_library_init) & 0xFFFF ;
  6 return ret ;
  END ./ffconf.RZMYFWdc/test.c
  cl -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -
  D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_WARNINGS -
  D_WIN32_WINNT=0x0502 -nologo -c -Fo./ffconf.RZMYFWdc/test.o
  ./ffconf.RZMYFWdc/test.c
  test.c
  ./ffconf.RZMYFWdc/test.c(3) : warning C4311 : ’type cast’ : pointer truncation
  from ’ASS_Library *(__cdecl *)(void)’ to ’long’
  ./compat/windows/mslink -nologo -out :./ffconf.RZMYFWdc/test.exe
  ./ffconf.RZMYFWdc/test.o psapi.lib advapi32.lib shell32.lib ole32.lib
  test.o : error LNK2019 : unresolved external symbol ass_library_init
  referenced in function check_ass_library_init
  ./ffconf.RZMYFWdc/test.exe : fatal error LNK1120 : 1 unresolved externals
  ERROR : libass not found using pkg-config

  The libass test project which uses ass_library_init compiles fine using the same lib files, the libs appear to be fine.

  From what I see from this line "./compat/windows/mslink -nologo -out:./ffconf.RZMYFWdc/test.exe ./ffconf.RZMYFWdc/test.o psapi.lib advapi32.lib shell32.lib ole32.lib" libass is not being passed to the linker.
  I suspect that the configuration file is not creating the link to libass in the make file when compiling with MSVC.

  Am I correct or am I going about compiling this in the wrong way ?

• FFMPEG : RTSP to HLS restream stops with "No more output streams to write to, finishing."

  1er juin 2022, par Tim W

  I'm trying to do a live restream an RTSP feed from a webcam using ffmpeg, but the stream repeatedly stops with the error :

  



  "No more output streams to write to, finishing."

  



  The problem seems to get worse at higher bitrates (256kbps is mostly reliable) and is pretty random in its occurrence. At 1mbps, sometimes the stream will run for several hours without any trouble, on other occasions the stream will fail every few minutes. I've got a cron job running which restarts the stream automatically when it fails, but I would prefer to avoid the continued interruptions.

  



  I have seen this problem reported in a handful of other forums, so this is not a unique problem, but not one of those reports had a solution attached to it. My ffmpeg command looks like this :

  



  ffmpeg -loglevel verbose -r 25 -rtsp_transport tcp -i rtsp ://user:password@camera.url/live/ch0 -reset_timestamps 1 -movflags frag_keyframe+empty_moov -bufsize 7168k -stimeout 60000 -hls_flags temp_file -hls_time 5 -hls_wrap 180 -acodec copy -vcodec copy streaming.m3u8 > encode.log 2>&1

  



  What gets me is that the error makes no sense, this is a live stream so output is always wanted until I shut off the stream. So having it shut down because output isn't wanted is downright odd. If ffmpeg was complaining because of a problem with input it would make more sense.

  



  I'm running version 3.3.4, which I believe is the latest.

  



  Update 13 Oct 17 :

  



  After extensive testing I've established that "No more outputs" error message generated by FFMPEG is very misleading. The error seems to be generated if the data coming in from RTSP is delayed, eg by other activity on the router the camera is connected via. I've got a large buffer and timeout set which should be sufficient for 60 seconds, but I can still deliberately trigger this error with far shorter interruptions, so clearly the buffer and timeout aren't having the desired effect. This might be fixed by setting a QOS policy on the router and by checking that the TCP packets from the camera have a suitably high priority set, it's possible this isn't the case.

  



  However, I would still like to improve the robustness of the input stream if it is briefly interrupted. Is there any way to persuade FFMPEG to tolerate this or to actually make use of the buffer it seems to be ignoring ? Can FFMPEG be persuaded to simply stop writing output and wait for input to become available rather than bailing out ? Or could I get FFMPEG to duplicate the last complete frame until it's able to get more data ? I can live with the stream stuttering a bit, but I've got to significantly reduce the current behaviour where the stream drops at the slightest hint of a problem.

  



  Further update 13 Oct 2017 :

  



  After more tests, I've found that the problem actually seems to be that HLS is incapable of coping with a discontinuity in the incoming video stream. If I deliberately cut the network connection between the camera and FFMPEG, FFMPEG will wait for the connection to be re-established for quite a long time. If the interruption was long (>10 seconds) the stream will immediately drop with the "No More Outputs" error the instant that the connection is re-established. If the interruption is short, then RTSP will actually start pulling data from the camera again, but the stream will then drop with the same error a few seconds later. So it seems clear that the gap in the input data is causing the HLS encoder to have a fit and give up once the stream is resumed, but the size of the gap has an impact on whether the drop is instant or not.