Recherche avancée

Sur d’autres sites (11948)

• FPS from RTSP stream info does not match actual framerate

  17 mai 2021, par Krapow

  I have a 25FPS RTSP stream coming from an IP-camera. I can successfully display the video stream. But when analyzing the stream with ffmpeg (ffprobe actually), I observe fewer frames per second rate :

  


  $ ffprobe -rtsp_transport tcp -i rtsp://camera_ip:554/stream -select_streams v:0 -show_frames -show_entries frame=coded_picture_number,pkt_pts_time -of csv=p=0
Stream #0:0: Video: h264 (Main), yuvj420p(pc, bt709, progressive), 640x480, 25 fps, 25 tbr, 90k tbn, 50 tbc
0.400000,0
0.080000,1
0.120000,2
0.200000,3
0.240000,4
0.320000,5
0.360000,6
0.440000,7
0.480000,8
0.560000,9
0.600000,10
0.680000,11
0.720000,12
0.800000,13
0.840000,14
0.920000,15
0.960000,16
1.040000,17
1.080000,18
1.160000,19
1.200000,20
1.280000,21
1.320000,22
1.400000,23
1.440000,24
1.520000,25
1.560000,26
1.640000,27
1.680000,28
1.760000,29
1.800000,30
1.880000,31
1.920000,32
2.000000,33


  


  We can clearly see the 80ms gap between some of the frames, resulting in a 16fps stream.

  


  I have observed the same framerate issue with GStreamer (printing information in the rtpjitterbuffer indicates the frame gap is sometimes 80ms and sometimes 40ms). But the weird thing is, I encountered the same issue with an HDMI-RJ45 decoder, and I doubt the same issue comes from 2 different devices.
I didn't get much more informations using -loglevel debug or trace.
Does anybody have an idea about what is going wrong in the stream ?

  


  (I used ffprobe 4.2.3 and the last "2021-05-09-git-8649f5dca6-full_build-www.gyan.dev" with the same results, and GStreamer 1.16.2 with a pipeline like "urisourcebin ! h264depay ! h264parse ! fakesink")

  


  EDIT : The camera skipping of frames was caused by the activation of a third stream in the options. I find it really weird that it skips exactly the same frames every seconds. However, I still haven't found the cause of the downrate on my RTSP encoder.
Anyway, this was actually hardware related and not software related.

  


• Live Streaming and watching HLS stream on VLC

  9 avril 2015, par TakeruDavis

  I have been trying to livestream a video in HLS using ffmpeg (trying both hls and segment mode) and everything looks like it should, m3u8 file is created and the content matches with examples.

  TS files look good as well, briefly looking at their headers in HEX editor makes them seem okay and separately, they are playable.

  But when I enter the URL of the m3u8 playlist into VLC, at first, it does nothing, then it seems like it is trying to open files with weird filenames. My best guess is it opens those TS files and treats their content as another playlist.

  Can someone help me figure out what might be the problem ?

  PS : I think I set up Apache properly too, it should be giving correct MIME types for both things.

• How to decrypt encrypted m3u8 video ?

  13 janvier 2017, par yuwix

  I have zip file containing a .m3u8, .key, and several .ts files. I tried using ffmpeg to decrypt it, but it fails :

  N:\Downloads\11991>ffmpeg -i 7c38gv8Xz7S86yZVwxHMc4CV3Q_rmcvideo_1080P_1920_5120_192.m3u8 -c copy out.ts
  
  ffmpeg version N-82324-g872b358 Copyright (c) 2000-2016 the FFmpeg developers
  
    built with gcc 5.4.0 (GCC)
  
    configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-dxva2 --enable-libmfx --enable-nvenc --enable-avisynth --enable-bzlib --enable-libebur128 --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-lzma --enable-decklink --enable-zlib
  
    libavutil      55. 36.100 / 55. 36.100
  
    libavcodec     57. 66.101 / 57. 66.101
  
    libavformat    57. 57.100 / 57. 57.100
  
    libavdevice    57.  2.100 / 57.  2.100
  
    libavfilter     6. 66.100 /  6. 66.100
  
    libswscale      4.  3.100 /  4.  3.100
  
    libswresample   2.  4.100 /  2.  4.100
  
    libpostproc    54.  2.100 / 54.  2.100
  
  [hls,applehttp @ 0000000000657060] Error when loading first segment '7c38gv8Xz7S86yZVwxHMc4CV3Q_rmcvideo_1080P_1920_5120_192-000000.ts'
  
  7c38gv8Xz7S86yZVwxHMc4CV3Q_rmcvideo_1080P_1920_5120_192.m3u8: Invalid data found when processing input

  m3u8 file :

  #EXTM3U
  
  #EXT-X-VERSION:3
  
  #EXT-X-MEDIA-SEQUENCE:0
  
  #EXT-X-TARGETDURATION:6
  
  #EXT-X-KEY:METHOD=AES-128,URI="7c38gv8Xz7S86yZVwxHMc4CV3Q_rmcvideo_1080P_1920_5120_192.key"
  
  #EXTINF:5.755755,
  
  7c38gv8Xz7S86yZVwxHMc4CV3Q_rmcvideo_1080P_1920_5120_192-000000.ts
  
  #EXTINF:5.088422,
  
  7c38gv8Xz7S86yZVwxHMc4CV3Q_rmcvideo_1080P_1920_5120_192-000001.ts
  
  ...

  The key seems to be weird, it’s 256 bits but the m3u8 file has #EXT-X-KEY:METHOD=AES-128 & it’s a bunch of weird characters compared to other keys I’ve seen :

  ¹š›aGŽªñ•|ÿÀ¦D7Ð/’V¦R¸:‹s

  This zip file was downloaded from an Android app and only playable within it. I’m guessing the key is encoded somehow by the app before actually being used to decrypt the video ?

  Any help would be appreciated