Recherche avancée

Sur d’autres sites (15325)

• Using libav, how to force RTSP stream over TCP ?

  15 août 2023, par hamidi

  By using ffmpeg or ffplay you may specify "-rtsp_transport tcp" switch to force the rtsp stream be opened via tcp. In programming, I'm using libav to open the rtsp stream with the following code :

  


  AVDictionary *options = NULL;
av_dict_set(&options, "rtsp_transport", "tcp", 0);
int status = avformat_open_input(&mFormatContext, path.c_str(), inputFormat, &options);


  


  and I expect the same behavior. But the url 'path' is opened via udp. I may figure this out this way :

  


  I create an SDP file with libav and write the received packets to it. Then I use ffplay to process and play the sdp file. I get errors like :

  


  


  RTP : missed 1 packets

  


  


  


  error while decoding MB 75 38, bytestream -48

  


  


  If the rtsp stream has been opened via TCP, I should not miss any packets, and the second type of error, I think, is caused by losing packets too. So, it seems that the rtsp_transport option is not working.

  


  Any idea ?

  


  Update

  


  I found that av_dict_set works as expected, but the SDP file is made incorrectly (maybe). Its content is like :

  


  v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 226.1.1.15/0
t=0 0
a=tool:libavformat 56.40.101
m=video 43908 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; sprop-parameter-sets=Z00AKpY1QPAET8s3AQEBAgA=,aO48gAA=; profile-level-id=4D002A


  


  I researched about it and found that the line beginning with 'm' should contain TCP instead of RTP/AVP, although all of this is my guess. The ffplay is reading the sdp file in the same system, so no socket or network connection exists between ffplay and the sdp file. So my guess may be incorrect. What do you think about the sdp file ? May it be incorrect ? I make it by av_sdp_create function and don't change it. I write it directly to the file.

  


• Evolution #3498 (Fermé) : 3.1 : SPIP 3.1.0-beta [22291] SVP (bouton "version obsolete")

  4 juillet 2015, par YannX DYX

  Mini-amélioration (perte de fonctionnalité par rapport à 3.0)

  L’affichage des plugins* ecrire/ ?exec=admin_plugin*
  montre en plus eventuellement des "short" "information" pour pour les plugins en version
  - incompatible
  - obsolete
  Ces blocs, générés dans svp/formulaires/inc-admin_plugin.html écrasent et masquent le nom du plugin (car ils ont un padding-top & padding-bottom trop imposants) : padding : 0.6925em 10px 0.6925em 40px ; )
  

  
  
  version incompatible
  
  

  
  Leur stylisation dépend de .formulaire_spip ... .information
  que l’on pourrait re-styler (sans doute dans svp/prive/style_prive_plugin_svp.html ) pour réduire à 2px ... ce qui rendrait la lecture et l’usage plus facile

  Par ailleurs je recupère (en PHP 5.3.13 ! ) un :
  Warning : Invalid argument supplied for foreach() in I :\www\.4LR\plugins-dist\svp\formulaires\admin_plugin.php on line 126

  Et, "last but not least" les boutons individuels d’action (visibles au survol, et à la coche) sur les plugins ne fonctionnent pas, avec un message !
  (X) Aucun plugin sélectionné...

  Désolé, mais je ne sais pas aller plus loin...

• Merge commit ’46bacb5cc6169ff5e8e982495c4925467c1d8bb7’

  14 janvier 2014, par Michael Niedermayer

  Merge commit ’46bacb5cc6169ff5e8e982495c4925467c1d8bb7’
  * commit ’46bacb5cc6169ff5e8e982495c4925467c1d8bb7’ :
  
    x86 : Consistently use cpu flag detection macros in places that still miss it
  Merged-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavcodec/x86/mpegaudiodsp.c
  • [DH] libswscale/x86/swscale.c
  • [DH] libswscale/x86/yuv2rgb.c