Recherche avancée

Sur d’autres sites (7562)

• ffmpeg to kurento rtp stream choppy video issue

  29 juillet 2020, par ahmetsarias

  I use ffmpeg to make an rtp stream to kurento media server and then send it to browsers via webrtc.

  


  ffmpeg (h264 RTP) -> Kurento -> (h264 WebRTC) Browser

  


  I'm capturing virtual xorg display.
This is my ffmpeg command :

  


  ffmpeg -y -v info -fflags +genpts -f x11grab -draw_mouse 0 -r 25 -s 1280x720 -thread_queue_size 4096 -i :0.0+0,0 -an -c:v libx264 -preset veryfast -crf 25 -g 50 -pix_fmt yuv420p -maxrate 2976k -bufsize 5952k -ssrc 112233 -payload_type 103 -tune zerolatency -f rtp rtp://172.16.1.115:40258

  


  This is my fake sdp offer used in negotiation with kurento RtpEndpoint

  


  v=0
o=- 0 0 IN IP4 127.0.0.1
s=Stream
c=IN IP4 127.0.0.1
t=0 0
m=video 9 RTP/AVP 103
a=rtpmap:103 H264/90000
a=fmtp:103 packetization-mode=1
a=sendonly
a=direction:active
a=ssrc:112233 cname:user@example.com 


  


  Here is the problem :

  


  Some I-frames are choppy on bottom half slice of the frame while others have no problem.

  


  It is sometimes corrected when another I-frame has arrived, but mostly choppy.

  


  When choppiness happened, Kms log says :

  


  


  kmsutils kmsutils.c:483:gap_detection_probe:kmsagnosticbin2-108:sink Stream gap detected, timestamp : 0:51:22.574766908, duration : 0:00:00.000008237

  


  


  Normal stream (No choppy at all)

  


  

  


  Choppy stream

  


  

  


  When it is corrected with an I-Frame (Sometimes it happens)

  


  

  


  I have no clue about what could lead the issue.

  


  Things that I tried to solve the problem.

  


  

  • Adding ?pkt_size=1000 (1100,900,1200. Since the mtu in kurento is 1200 default)

  


  • Changing -crf to different values in between 18-35

  


  • Changing -preset between medium and ultrafast

  


  • Changing framerate

  


  • Changing gop length (When i lower the gop length -More I-Frames- choppiness become shorter in duration but more frequent)

  


  • When I disable sliced-threads, there is no issue with bottom side but whole screen freezes in same scenario

  


  


  Any help would be appreciated. Thanks.

  


• avcodec/put_bits : Make bit buffers 64-bit

  18 juillet 2020, par Steinar H. Gunderson

  avcodec/put_bits : Make bit buffers 64-bit
  Change BitBuf into uint64_t on 64-bit x86. This means we need to flush the
  
  buffer less often, which is a significant speed win. All other platforms,
  
  including all 32-bit ones, are unchanged. Output bitstream is the same.
  All API constraints are kept in place, e.g., you still cannot put_bits()
  
  more than 31 bits at a time. This is so that codecs cannot accidentally
  
  become 64-bit-only or similar.
  Benchmarking on transcoding to various formats shows consistently
  
  positive results :
    dnxhd                 25.60 fps ->  26.26 fps ( +2.6%)
  
    dvvideo               24.88 fps ->  25.17 fps ( +1.2%)
  
    ffv1                  14.32 fps ->  14.58 fps ( +1.8%)
  
    huffyuv               58.75 fps ->  63.27 fps ( +7.7%)
  
    jpegls                 6.22 fps ->   6.34 fps ( +1.8%)
  
    magicyuv              57.10 fps ->  63.29 fps (+10.8%)
  
    mjpeg                 48.65 fps ->  49.01 fps ( +0.7%)
  
    mpeg1video            76.41 fps ->  77.01 fps ( +0.8%)
  
    mpeg2video            75.99 fps ->  77.43 fps ( +1.9%)
  
    mpeg4                 80.66 fps ->  81.37 fps ( +0.9%)
  
    prores                12.35 fps ->  12.88 fps ( +4.3%)
  
    prores_ks             16.20 fps ->  16.80 fps ( +3.7%)
  
    rv20                  62.80 fps ->  62.99 fps ( +0.3%)
  
    utvideo               68.41 fps ->  76.32 fps (+11.6%)
  Note that this includes video decoding and all other encoding work,
  
  such as DCTs. If you isolate the actual bit-writing routines, it is
  
  likely to be much more.
  Benchmark details : Transcoding the first 30 seconds of Big Buck Bunny
  
  in 1080p, Haswell 2.1 GHz, GCC 8.3, generally quantizer locked to
  
  5.0. (Exceptions : DNxHD needs fixed bitrate, and JPEG-LS is so slow
  
  that I only took the first 10 seconds, not 30.) All runs were done
  
  ten times and single-threaded, top and bottom two results discarded to
  
  get rid of outliers, arithmetic mean between the remaining six.
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/asvenc.c
  • [DH] libavcodec/put_bits.h

• Use FFMPEG to combine different MP4s with srt into one file

  17 juin 2021, par anonymous1a

  So...probably a very basic question for those of you familiar with FFMPEG (I'm really not). I know that you can combine multiple videos into one using FFMPEG, but what about if each video has its own srt file, saved separately in a 'subs' folder and NOT included in the video itself ?

  



  Is it possible for FFMPEG to also combine the srt files into a single one (and recalculate the timestamps), and then merge this into the final, combined video ? If so, what would the command be ?

  



  For example, I have video1.mp4 and video2.mp4. They have corresponding sub1.srt and sub2.srt. When video1.mp4 and video2.mp4 are merged, the timestamps for sub2.srt will, of course, be out of sync now and need to be corrected by adding the duration of video1.mp4 to the individual timestamps (i.e., if video1 is 30 seconds long, and the first subtitle in sub2.srt appears at the 2-second mark, then after the combination, it should now appear at the (30+2)=32-second mark, and so on.

  



  If it helps, all the files are mp4, and have the same dimensions (720p).