Recherche avancée

Sur d’autres sites (12522)

• FFMPEG error with avformat_open_input returning -135

  28 avril 2015, par LawfulEvil

  I have a DLL one of my applications uses to receive video from RTSP cameras. Under the hood, the DLL uses FFMPEG libs from this release zip :

  ffmpeg-20141022-git-6dc99fd-win64-shared.7z

  We have a wide variety of cameras in house and most of them work just fine. However, on one particular Pelco Model Number : IXE20DN-OCP, I am unable to connect. I tested the camera and rtsp connection string on VLC and it connects to the camera just fine.

  I found the connection string here : http://www.ispyconnect.com/man.aspx?n=Pelco

  rtsp://IPADDRESS:554/1/stream1

  Oddly, even if I leave the port off of VLC, it connects, so I’m guessing its the default RTSP port or that VLC tries a variety of things based on your input.

  In any case, when I attempt to connect, I get an error from av_format_open_input. It returns a code of -135. When I looked in the error code list I didn’t see that listed. For good measure, I printed out all the errors in error.h just to see what their values were.

  DumpErrorCodes - Error Code : AVERROR_BSF_NOT_FOUND = -1179861752
  
  DumpErrorCodes - Error Code : AVERROR_BUG = -558323010
  
  DumpErrorCodes - Error Code : AVERROR_BUFFER_TOO_SMALL = -1397118274
  
  DumpErrorCodes - Error Code : AVERROR_DECODER_NOT_FOUND = -1128613112
  
  DumpErrorCodes - Error Code : AVERROR_DEMUXER_NOT_FOUND = -1296385272
  
  DumpErrorCodes - Error Code : AVERROR_ENCODER_NOT_FOUND = -1129203192
  
  DumpErrorCodes - Error Code : AVERROR_EOF = -541478725
  
  DumpErrorCodes - Error Code : AVERROR_EXIT = -1414092869
  
  DumpErrorCodes - Error Code : AVERROR_EXTERNAL = -542398533
  
  DumpErrorCodes - Error Code : AVERROR_FILTER_NOT_FOUND = -1279870712
  
  DumpErrorCodes - Error Code : AVERROR_INVALIDDATA = -1094995529
  
  DumpErrorCodes - Error Code : AVERROR_MUXER_NOT_FOUND = -1481985528
  
  DumpErrorCodes - Error Code : AVERROR_OPTION_NOT_FOUND = -1414549496
  
  DumpErrorCodes - Error Code : AVERROR_PATCHWELCOME = -1163346256
  
  DumpErrorCodes - Error Code : AVERROR_PROTOCOL_NOT_FOUND = -1330794744
  
  DumpErrorCodes - Error Code : AVERROR_STREAM_NOT_FOUND = -1381258232
  
  DumpErrorCodes - Error Code : AVERROR_BUG2 = -541545794
  
  DumpErrorCodes - Error Code : AVERROR_UNKNOWN = -1313558101
  
  DumpErrorCodes - Error Code : AVERROR_EXPERIMENTAL = -733130664
  
  DumpErrorCodes - Error Code : AVERROR_INPUT_CHANGED = -1668179713
  
  DumpErrorCodes - Error Code : AVERROR_OUTPUT_CHANGED = -1668179714
  
  DumpErrorCodes - Error Code : AVERROR_HTTP_BAD_REQUEST = -808465656
  
  DumpErrorCodes - Error Code : AVERROR_HTTP_UNAUTHORIZED = -825242872
  
  DumpErrorCodes - Error Code : AVERROR_HTTP_FORBIDDEN = -858797304
  
  DumpErrorCodes - Error Code : AVERROR_HTTP_NOT_FOUND = -875574520
  
  DumpErrorCodes - Error Code : AVERROR_HTTP_OTHER_4XX = -1482175736
  
  DumpErrorCodes - Error Code : AVERROR_HTTP_SERVER_ERROR = -1482175992

  Nothing even close to -135. I did find this error, sort of on stack overflow, here runtime error when linking ffmpeg libraries in qt creator where the author claims it is a DLL loading problem error. I’m not sure what led him to think that, but I followed the advice and used the dependency walker (http://www.dependencywalker.com/) to checkout what dependencies it thought my DLL needed. It listed a few, but they were already provided in my install package.

  To make sure it was picking them up, I manually removed them from the install and observed a radical change in program behavior(that being my DLL didn’t load and start to run at all).

  So, I’ve got a bit of init code :

  void FfmpegInitialize()
  
  {
  
   av_lockmgr_register(&LockManagerCb);
  
   av_register_all();
  
   LOG_DEBUG0("av_register_all returned\n");
  
  }

  Then I’ve got my main open connection routine ...

  int RTSPConnect(const char *URL, int width, int height, frameReceived callbackFunction)
  
  {
  
  
  
      int errCode =0;
  
      if ((errCode = avformat_network_init()) != 0)
  
      {
  
          LOG_ERROR1("avformat_network_init returned error code %d\n", errCode);  
  
      }
  
      LOG_DEBUG0("avformat_network_init returned\n");
  
      //Allocate space and setup the the object to be used for storing all info needed for this connection
  
      fContextReadFrame = avformat_alloc_context(); // free'd in the Close method
  
  
  
      if (fContextReadFrame == 0)
  
      {
  
          LOG_ERROR1("Unable to set rtsp_transport options.   Error code = %d\n", errCode);
  
          return FFMPEG_OPTION_SET_FAILURE;
  
      }
  
  
  
      LOG_DEBUG1("avformat_alloc_context returned %p\n", fContextReadFrame);
  
  
  
      AVDictionary *opts = 0;
  
      if ((errCode = av_dict_set(&opts, "rtsp_transport", "tcp", 0)) < 0)
  
      {
  
          LOG_ERROR1("Unable to set rtsp_transport options.   Error code = %d\n", errCode);
  
          return FFMPEG_OPTION_SET_FAILURE;
  
      }
  
      LOG_DEBUG1("av_dict_set returned %d\n", errCode);
  
  
  
      //open rtsp
  
      DumpErrorCodes();
  
      if ((errCode = avformat_open_input(&fContextReadFrame, URL, NULL, &opts)) < 0)
  
      {
  
          LOG_ERROR2("Unable to open avFormat RF inputs.   URL = %s, and Error code = %d\n", URL, errCode);       
  
          LOG_ERROR2("Error Code %d = %s\n", errCode, errMsg(errCode));       
  
          // NOTE context is free'd on failure.
  
          return FFMPEG_FORMAT_OPEN_FAILURE;
  
      }
  
  ...

  To be sure I didn’t misunderstand the error code I printed the error message from ffmpeg but the error isn’t found and my canned error message is returned instead.

  My next step was going to be hooking up wireshark on my connection attempt and on the VLC connection attempt and trying to figure out what differences(if any) are causing the problem and what I can do to ffmpeg to make it work. As I said, I’ve got a dozen other cameras in house that use RTSP and they work with my DLL. Some utilize usernames/passwords/etc as well(so I know that isn’t the problem).

  Also, my run logs :

  FfmpegInitialize - av_register_all returned
  
  Open - Open called.  Pointers valid, passing control.
  
  Rtsp::RtspInterface::Open - Rtsp::RtspInterface::Open called
  
  Rtsp::RtspInterface::Open - VideoSourceString(35) = rtsp://192.168.14.60:554/1/stream1
  
  Rtsp::RtspInterface::Open - Base URL = (192.168.14.60:554/1/stream1)
  
  Rtsp::RtspInterface::Open - Attempting to open (rtsp://192.168.14.60:554/1/stream1) for WxH(320x240) video
  
  RTSPSetFormatH264 - RTSPSetFormatH264
  
  RTSPConnect - Called
  
  LockManagerCb - LockManagerCb invoked for op 1
  
  LockManagerCb - LockManagerCb invoked for op 2
  
  RTSPConnect - avformat_network_init returned
  
  RTSPConnect - avformat_alloc_context returned 019E6000
  
  RTSPConnect - av_dict_set returned 0
  
  DumpErrorCodes - Error Code : AVERROR_BSF_NOT_FOUND = -1179861752
  
  ...
  
  DumpErrorCodes - Error Code : AVERROR_HTTP_SERVER_ERROR = -1482175992
  
  RTSPConnect - Unable to open avFormat RF inputs.   URL = rtsp://192.168.14.60:554/1/stream1, and Error code = -135
  
  RTSPConnect - Error Code -135 = No Error Message Available

  I’m going to move forward with wireshark but would like to know the origin of the -135 error code from ffmpeg. When I look at the code if ’ret’ is getting set to -135, it must be happening as a result of the return code from a helper method and not directly in the avformat_open_input method.

  https://www.ffmpeg.org/doxygen/2.5/libavformat_2utils_8c_source.html#l00398

  After upgrading to the latest daily ffmpeg build, I get data on wireshark. Real Time Streaming Protocol :

  Request: SETUP rtsp://192.168.14.60/stream1/track1 RTSP/1.0\r\n
  
  Method: SETUP
  
  URL: rtsp://192.168.14.60/stream1/track1
  
  Transport: RTP/AVP/TCP;unicast;interleaved=0-1
  
  CSeq: 3\r\n
  
  User-Agent: Lavf56.31.100\r\n
  
  \r\n

  The response to that is the first ’error’ that I can detect in the initiation.

  Response: RTSP/1.0 461 Unsupported Transport\r\n
  
  Status: 461
  
  CSeq: 3\r\n
  
  Date: Sun, Jan 04 1970 16:03:05 GMT\r\n
  
  \r\n

  I’m going to guess that... it means the transport we selected was unsupported. I quick check of the code reveals I picked ’tcp’. Looking through the reply to the DESCRIBE command, it appears :

  Media Protocol: RTP/AVP

  Further, when SETUP is issued by ffmpeg, it specifies :

  Transport: RTP/AVP/TCP;unicast;interleaved=0-1

  I’m going to try, on failure here to pick another transport type and see how that works. Still don’t know where the -135 comes from.

• Game Music Appreciation, One Year Later

  1er août 2013, par Multimedia Mike — General

  I released my game music website last year about this time. It was a good start and had potential to grow in a lot of directions. But I’m a bit disappointed that I haven’t evolved it as quickly as I would like to. I have made a few improvements, like adjusting the play lengths of many metadata-less songs and revising the original atrocious design of the website using something called Twitter Bootstrap (and, wow, once you know what Bootstrap is, you start noticing it everywhere on the modern web). However, here are a few of the challenges that have slowed me down over the year :

  Problems With Native Client – Build System
  The technology which enables this project — Google’s Native Client (NaCl) — can be troublesome. One of my key frustrations with the environment is that every single revision of the NaCl SDK seems to adopt a completely new build system layout. If you want to port your NaCl project forward to newer revisions, you have to spend time wrapping your head around whatever the favored build system is. When I first investigated NaCl, I think it was using vanilla GNU Make. Then it switched to SCons. Then I forgot about NaCl for about a year and when I came back, the SDK had reverted back to GNU Make. While that has been consistent, the layout of the SDK sometimes changes and a different example Makefile shows the way.

  The very latest version of the API has required me to really overhaul the Makefile and to truly understand the zen of Makefile programming. I’m even starting to grasp the relationship it has to functional programming.

  Problems With Native Client – API Versions and Chrome Bugs
  I built the original Salty Game Music Player when NaCl API version 16 was current. By the time I published the v16 version, v19 was available. I made the effort to port forward (a few APIs had superfically changed, nothing too dramatic). However, when I would experiment with this new player, I would see intermittent problems on my Windows 7 desktop. Because of this, I was hesitant to make a new player release.

  Around the end of May, I started getting bug reports from site users that their Chrome browsers weren’t allowing them to activate the Salty Game Music Player — the upshot was that they couldn’t play music unless they manually flipped a setting in their browser configuration. It turns out that Chrome 27 introduced a bug that caused this problem. Not only that, but my player was one of only 2 known NaCl apps that used the problematic feature (the other was developed by the Google engineer who entered the bug).

  After feeling negligent for a long while about not doing anything to fix the bug, I made a concerted and creative effort to work around the bug and pushed out a new version of the player (based on API v25). My effort didn’t work and I had to roll it back somewhat (but still using the new player binaries). The bug was something that I couldn’t work around. However, at about the same time that I was attempting to do this, Google was rolling out Chrome 28 which fixed the bug, rendering my worry and effort moot.

  Problems With Native Client – Still Not In The Clear
  I felt reasonably secure about releasing the updated player since I couldn’t make my aforementioned problem occur on my Windows 7 setup anymore. I actually have a written test plan for this player, believe it or not. However, I quickly started receiving new bug reports from Windows users. Mostly, these are Windows 8 users. The player basically doesn’t work at all for them now. One user reports the problem on Windows 7 (and another on Windows 2008 Server, I think). But I can’t see it.

  I have a theory about what might be going wrong, but of course I’ll need to test it, and determine how to fix it.

  Database Difficulties
  The player is only half of the site ; the other half is the organization of music files. Working on this project has repeatedly reminded me of my fundamental lack of skill concerning databases. I have a ‘production’ database– now I’m afraid to do anything with it for fear of messing it up. It’s an an SQLite3 database, so it’s easy to make backups and to create a copy in order to test and debug a new script. Still, I feel like I’m missing an entire career path worth of database best practices.

  There is also the matter of ongoing database maintenance. There are graphical frontends for SQLite3 which make casual updates easier and obviate the need for anything more sophisticated (like a custom web app). However, I have a slightly more complicated database entry task that I fear will require, well, a custom web app in order to smoothly process hundreds, if not thousands of new song files (which have quirks which prohibit the easy mass processing I have been able to get away with so far).

  Going Forward
  I remain hopeful that I’ll gradually overcome these difficulties. I still love this project and I have received nothing but positive feedback over the past year (modulo the assorted recommendations that I port the entire player to pure JavaScript).

  You would think I would learn a lesson about building anything on top of a Google platform in the future, especially Native Client. Despite all this, I have another NaCl project planned.

• Anomalie #3409 (Nouveau) : Bug mot de passe pour connexion base de données PostgreSQL

  15 mars 2015, par Jacques Deguest

  SPIP version 3.0.17
  Résumé :
  Mot de passe inopérant s’il contient un espace.

  Détail :
  Dans le fichier écrire/req/pg.php a la ligne 46 (et un peu plus bas encore) :
  @$link = pg_connect("host=$host$port dbname=$db user=$login password=$pass", PGSQL_CONNECT_FORCE_NEW) ;

  Solutions suggérés :
  1) Entourer $pass de guillemets simples
  2) Renforcer l’interdiction d’espace dans le mot de passe dans le formulaire web de configuration de SPIP