Recherche avancée

Sur d’autres sites (7912)

• Procedure entry point could not be found ?

  30 décembre 2012, par ronag

  I've encountered a strange problem. After updating to the latest ffmpeg headers/lib/dll I keep getting the error :

  The procedure entry point __glewProgramUniform1i could not be located in the dynamic link library

  If I change so that I link to glew using static linking, then that specific error disappears and it instead complains about some other procedure entry point in some other dll, and so on.

  As soon as a revert to the old ffmpeg headers/lib/dll the problem disappears.

  What could cause this behavior ? How do I debug this ?

  NOTE : This only happens during release builds, not during debug builds.

  

  

  Depends profile log :

  Started "CONHOST.EXE" (process 0x1BBC) at address 0x000007F63CF60000.  Successfully hooked module.
  
  Loaded "NTDLL.DLL" at address 0x000007F945C30000.  Successfully hooked module.
  
  Loaded "KERNEL32.DLL" at address 0x000007F943400000.  Successfully hooked module.
  
  Loaded "KERNELBASE.DLL" at address 0x000007F942D10000.  Successfully hooked module.
  
  DllMain(0x000007F942D10000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "KERNELBASE.DLL" called.
  
  DllMain(0x000007F942D10000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "KERNELBASE.DLL" returned 1 (0x1).
  
  DllMain(0x000007F943400000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "KERNEL32.DLL" called.
  
  DllMain(0x000007F943400000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "KERNEL32.DLL" returned 1 (0x1).
  
  Injected "DEPENDS.DLL" at address 0x000000005ACD0000.
  
  DllMain(0x000000005ACD0000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "DEPENDS.DLL" called.
  
  DllMain(0x000000005ACD0000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "DEPENDS.DLL" returned 1 (0x1).
  
  Loaded "GDI32.DLL" at address 0x000007F945970000.  Successfully hooked module.
  
  Loaded "USER32.DLL" at address 0x000007F943860000.  Successfully hooked module.
  
  Loaded "MSVCRT.DLL" at address 0x000007F945430000.  Successfully hooked module.
  
  Loaded "IMM32.DLL" at address 0x000007F945320000.  Successfully hooked module.
  
  Loaded "OLEAUT32.DLL" at address 0x000007F9454E0000.  Successfully hooked module.
  
  Loaded "COMBASE.DLL" at address 0x000007F9457C0000.  Successfully hooked module.
  
  Loaded "MSCTF.DLL" at address 0x000007F944FD0000.  Successfully hooked module.
  
  Loaded "RPCRT4.DLL" at address 0x000007F944CF0000.  Successfully hooked module.
  
  Entrypoint reached. All implicit modules have been loaded.
  
  DllMain(0x000007F943860000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "USER32.DLL" called.
  
  DllMain(0x000007F945430000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "MSVCRT.DLL" called.
  
  DllMain(0x000007F945430000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "MSVCRT.DLL" returned 1 (0x1).
  
  DllMain(0x000007F943860000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "USER32.DLL" returned 1 (0x1).
  
  DllMain(0x000007F945970000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "GDI32.DLL" called.
  
  DllMain(0x000007F945970000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "GDI32.DLL" returned 1 (0x1).
  
  DllMain(0x000007F944FD0000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "MSCTF.DLL" called.
  
  DllMain(0x000007F944FD0000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "MSCTF.DLL" returned 1 (0x1).
  
  DllMain(0x000007F945320000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "IMM32.DLL" called.
  
  DllMain(0x000007F945320000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "IMM32.DLL" returned 1 (0x1).
  
  DllMain(0x000007F944CF0000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "RPCRT4.DLL" called.
  
  DllMain(0x000007F944CF0000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "RPCRT4.DLL" returned 1154577921 (0x44D17601).
  
  DllMain(0x000007F9457C0000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "COMBASE.DLL" called.
  
  DllMain(0x000007F9457C0000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "COMBASE.DLL" returned 1 (0x1).
  
  DllMain(0x000007F9454E0000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "OLEAUT32.DLL" called.
  
  DllMain(0x000007F9454E0000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "OLEAUT32.DLL" returned 1 (0x1).
  
  Loaded "UXTHEME.DLL" at address 0x000007F941950000.  Successfully hooked module.
  
  DllMain(0x000007F941950000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "UXTHEME.DLL" called.
  
  DllMain(0x000007F941950000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "UXTHEME.DLL" returned 1 (0x1).
  
  Error writing a breakpoint at the entrypoint return of "".  Entrypoint cannot be hooked. Invalid access to memory location (998).
  
  Loaded "" at address 0x00000019D1220000.  Successfully hooked module.
  
  Unloaded "" at address 0x00000019D1220000.
  
  Loaded "START8_64.DLL" at address 0x000007F93A130000.  Successfully hooked module.
  
  DllMain(0x000007F93A130000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "START8_64.DLL" called.
  
  GetProcAddress(0x000007F943860000 [USER32.DLL], "CreateWindowInBand") called from "START8_64.DLL" at address 0x000007F93A1C0941 and returned 0x000007F943872C20.
  
  LoadLibraryA("ADVAPI32.dll") called from "START8_64.DLL" at address 0x000007F93A1A1D5C.
  
  Loaded "ADVAPI32.DLL" at address 0x000007F944E40000.  Successfully hooked module.
  
  Loaded "SECHOST.DLL" at address 0x000007F9439B0000.  Successfully hooked module.
  
  DllMain(0x000007F9439B0000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "SECHOST.DLL" called.
  
  DllMain(0x000007F9439B0000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "SECHOST.DLL" returned 1 (0x1).
  
  DllMain(0x000007F944E40000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "ADVAPI32.DLL" called.
  
  DllMain(0x000007F944E40000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "ADVAPI32.DLL" returned 1 (0x1).
  
  LoadLibraryA("ADVAPI32.dll") returned 0x000007F944E40000.
  
  GetProcAddress(0x000007F944E40000 [ADVAPI32.DLL], "RegOpenKeyExW") called from "START8_64.DLL" at address 0x000007F93A1A1E59 and returned 0x000007F944E413D0.
  
  GetProcAddress(0x000007F944E40000 [ADVAPI32.DLL], "RegQueryValueExW") called from "START8_64.DLL" at address 0x000007F93A1A1E59 and returned 0x000007F944E413F0.
  
  GetProcAddress(0x000007F944E40000 [ADVAPI32.DLL], "RegCloseKey") called from "START8_64.DLL" at address 0x000007F93A1A1E59 and returned 0x000007F944E413B0.
  
  GetProcAddress(0x000007F943860000 [USER32.DLL], "GetWindowBand") called from "START8_64.DLL" at address 0x000007F93A1C0A91 and returned 0x000007F943863210.
  
  GetProcAddress(0x000007F943860000 [USER32.DLL], "SetWindowBand") called from "START8_64.DLL" at address 0x000007F93A1C0AC1 and returned 0x000007F943872BB0.
  
  DllMain(0x000007F93A130000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "START8_64.DLL" returned 1 (0x1).
  
  Loaded "DWMAPI.DLL" at address 0x000007F941120000.  Successfully hooked module.
  
  DllMain(0x000007F941120000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "DWMAPI.DLL" called.
  
  DllMain(0x000007F941120000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "DWMAPI.DLL" returned 1 (0x1).
  
  Loaded "COMCTL32.DLL" at address 0x000007F940010000.  Successfully hooked module.
  
  DllMain(0x000007F940010000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "COMCTL32.DLL" called.
  
  DllMain(0x000007F940010000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "COMCTL32.DLL" returned 1 (0x1).
  
  Loaded "OLE32.DLL" at address 0x000007F945AB0000.  Successfully hooked module.
  
  DllMain(0x000007F945AB0000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "OLE32.DLL" called.
  
  DllMain(0x000007F945AB0000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "OLE32.DLL" returned 1 (0x1).
  
  Loaded "CRYPTBASE.DLL" at address 0x000007F9429A0000.  Successfully hooked module.
  
  Loaded "BCRYPTPRIMITIVES.DLL" at address 0x000007F942940000.  Successfully hooked module.
  
  DllMain(0x000007F942940000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "BCRYPTPRIMITIVES.DLL" called.
  
  DllMain(0x000007F942940000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "BCRYPTPRIMITIVES.DLL" returned 1 (0x1).
  
  DllMain(0x000007F9429A0000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "CRYPTBASE.DLL" called.
  
  DllMain(0x000007F9429A0000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "CRYPTBASE.DLL" returned 1 (0x1).
  
  Loaded "SHCORE.DLL" at address 0x000007F941D20000.  Successfully hooked module.
  
  DllMain(0x000007F941D20000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "SHCORE.DLL" called.
  
  DllMain(0x000007F941D20000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "SHCORE.DLL" returned 1 (0x1).

• Capturing snapshot works on one RTSP stream and fails on another

  29 mars 2012, par Saurabh Gandhi

  I am using the VLM feature (over telnet) of VLC to re-stream a live camera RTSP stream using VOD (video on demand). This provides me with two options of viewing the live stream :

  1. Original camera stream
  2. VOD stream generated using VLM

  Both these streams are working fine when viewed within VLC player. I would like to take a snapshot from both these streams whenever the user presses a key. So, I am using command-line vlc interface to grab a snapshot, the command for which is :

  • Snapshot from original camera stream (Case I)

  cvlc -V dummy --video-filter scene --scene-format jpeg --scene-prefix myscene --start-time=0 --stop-time=1 --scene-replace --scene-path /var/www/ <original camera="camera" stream="stream"> vlc://quit;
  
  </original>

  • Snapshot from VOD stream (Case II)

  cvlc -V dummy --video-filter scene --scene-format jpeg --scene-prefix myscene --start-time=0 --stop-time=1 --scene-replace --scene-path /var/www/ <vod stream="stream" generated="generated" using="using" vlm="vlm"> vlc://quit;
  
  </vod>

  Now, case I seems to work fine but case II does not work, in-spite of confirming that both the live streams are working fine. What could be the problem ?

  Here are the logs of VLC when case II is executed on command-line :

  saurabh@saurabh-Latitude-E5510:~/Desktop/html_trial$ cvlc -V dummy --video-filter scene --scene-format jpeg --scene-prefix myscene --start-time=0 --stop-time=1 --scene-replace --scene-path /var/www/ rtsp://10.17.1.150:5544/vid1 vlc://quit; 
  
  
  
  VLC media player 1.1.9 The Luggage (revision exported) 
  
  Blocked: call to unsetenv("DBUS_ACTIVATION_ADDRESS") 
  
  Blocked: call to unsetenv("DBUS_ACTIVATION_BUS_TYPE") 
  
  [0x97c684c] dummy interface: using the dummy interface module... 
  
  rc buffer underflow 
  
  rc buffer underflow 
  
  rc buffer underflow 
  
  rc buffer underflow 
  
  ^C[0x97be2ac] signals interface error: Caught Interrupt signal, exiting...

  Regards,

  Saurabh Gandhi

• Adventures in Unicode

  29 novembre 2012, par Multimedia Mike — Programming, php, Python, sqlite3, unicode

  Tangential to multimedia hacking is proper metadata handling. Recently, I have gathered an interest in processing a large corpus of multimedia files which are likely to contain metadata strings which do not fall into the lower ASCII set. This is significant because the lower ASCII set intersects perfectly with my own programming comfort zone. Indeed, all of my programming life, I have insisted on covering my ears and loudly asserting “LA LA LA LA LA ! ALL TEXT EVERYWHERE IS ASCII !” I suspect I’m not alone in this.

  Thus, I took this as an opportunity to conquer my longstanding fear of Unicode. I developed a self-learning course comprised of a series of exercises which add up to this diagram :

  
  
  

  Part 1 : Understanding Text Encoding
  Python has regular strings by default and then it has Unicode strings. The latter are prefixed by the letter ‘u’. This is what ‘ö’ looks like encoded in each type.

  python

  < view plain text >

  1. >>> ’ö’, u’ö’
  2. (’\xc3\xb6’, u’\xf6’)

  A large part of my frustration with Unicode comes from Python yelling at me about UnicodeDecodeErrors and an inability to handle the number 0xc3 for some reason. This usually comes when I’m trying to wrap my head around an unrelated problem and don’t care to get sidetracked by text encoding issues. However, when I studied the above output, I finally understood where the 0xc3 comes from. I just didn’t understand what the encoding represents exactly.
  

  I can see from assorted tables that ‘ö’ is character 0xF6 in various encodings (in Unicode and Latin-1), so u’\xf6′ makes sense. But what does ‘\xc3\xb6′ mean ? It’s my style to excavate straight down to the lowest levels, and I wanted to understand exactly how characters are represented in memory. The UTF-8 encoding tables inform us that any Unicode code point above 0x7F but less than 0×800 will be encoded with 2 bytes :

   110xxxxx 10xxxxxx
  

  Applying this pattern to the \xc3\xb6 encoding :

              hex : 0xc3      0xb6
             bits : 11000011  10110110
   important bits : ---00011  —110110
        assembled : 00011110110
       code point : 0xf6
  

  I was elated when I drew that out and made the connection. Maybe I’m the last programmer to figure this stuff out. But I’m still happy that I actually understand those Python errors pertaining to the number 0xc3 and that I won’t have to apply canned solutions without understanding the core problem.

  I’m cheating on this part of this exercise just a little bit since the diagram implied that the Unicode text needs to come from a binary file. I’ll return to that in a bit. For now, I’ll just contrive the following Unicode string from the Python REPL :

  python

  < view plain text >

  1. >>> u = u’Üñìçôđé’
  2. >>> u
  3. u’\xdc\xf1\xec\xe7\xf4\u0111\xe9’

  Part 2 : From Python To SQLite3
  The next step is to see what happens when I use Python’s SQLite3 module to dump the string into a new database. Will the Unicode encoding be preserved on disk ? What will UTF-8 look like on disk anyway ?

  python

  < view plain text >

  1. >>> import sqlite3
  2. >>> conn = sqlite3.connect(’unicode.db’)
  3. >>> conn.execute("CREATE TABLE t (t text)")
  4. >>> conn.execute("INSERT INTO t VALUES (?)", (u, ))
  5. >>> conn.commit()
  6. >>> conn.close()

  Next, I manually view the resulting database file (unicode.db) using a hex editor and look for strings. Here we go :

  000007F0   02 29 C3 9C  C3 B1 C3 AC  C3 A7 C3 B4  C4 91 C3 A9
  

  Look at that ! It’s just like the \xc3\xf6 encoding we see in the regular Python strings.

  Part 3 : From SQLite3 To A Web Page Via PHP
  Finally, use PHP (love it or hate it, but it’s what’s most convenient on my hosting provider) to query the string from the database and display it on a web page, completing the outlined processing pipeline.

  php

  < view plain text >

  1. < ?php
  2. $dbh = new PDO("sqlite:unicode.db") ;
  3. foreach ($dbh->query("SELECT t from t") as $row) ;
  4. $unicode_string = $row[’t’] ;
  5.  ?>
  6.  
  7. <html>
  8. <head><meta http-equiv="Content-Type" content="text/html ; charset=utf-8"></meta></head>
  9. <body><h1>< ?=$unicode_string ?></h1></body>
  10. </html>

  I tested the foregoing PHP script on 3 separate browsers that I had handy (Firefox, Internet Explorer, and Chrome) :

  
  
  

  I’d say that counts as success ! It’s important to note that the “meta http-equiv” tag is absolutely necessary. Omit and see something like this :

  
  
  

  Since we know what the UTF-8 stream looks like, it’s pretty obvious how the mapping is operating here : 0xc3 and 0xc4 correspond to ‘Ã’ and ‘Ä’, respectively. This corresponds to an encoding named ISO/IEC 8859-1, a.k.a. Latin-1. Speaking of which…

  Part 4 : Converting Binary Data To Unicode
  At the start of the experiment, I was trying to extract metadata strings from these binary multimedia files and I noticed characters like our friend ‘ö’ from above. In the bytestream, this was represented simply with 0xf6. I mistakenly believed that this was the on-disk representation of UTF-8. Wrong. Turns out it’s Latin-1.

  However, I still need to solve the problem of transforming such strings into Unicode to be shoved through the pipeline diagrammed above. For this experiment, I created a 9-byte file with the Latin-1 string ‘Üñìçôdé’ couched by 0′s, to simulate yanking a string out of a binary file. Here’s unicode.file :

  00000000   00 DC F1 EC  E7 F4 64 E9  00         ......d..
  

  (Aside : this experiment uses plain ‘d’ since the ‘đ’ with a bar through it doesn’t occur in Latin-1 ; shows up all over the place in Vietnamese, at least.)

  I’ve been mashing around Python code via the REPL, trying to get this string into a Unicode-friendly format. This is a successful method but it’s probably not the best :

  python

  < view plain text >

  1. >>> import struct
  2. >>> f = open(’unicode.file’, ’r’).read()
  3. >>> u = u’’
  4. >>> for c in struct.unpack("B"*7, f[1 :8]) :
  5. ... u += unichr(c)
  6. ...
  7. >>> u
  8. u’\xdc\xf1\xec\xe7\xf4d\xe9’
  9. >>> print u
  10. Üñìçôdé

  Conclusion
  Dealing with text encoding matters reminds me of dealing with integer endian-ness concerns. When you’re just dealing with one system, you probably don’t need to think too much about it because the system is usually handling everything consistently underneath the covers.

  However, when the data leaves one system and will be interpreted by another system, that’s when a programmer needs to be cognizant of matters such as integer endianness or text encoding.