2012-03-25 8 views
0

Der Versuch, Xuggler unter Windows zu bauen. Xuggler ist ein Kern von nativen Code-Funktionen, die zur Soundverarbeitung (einschließlich ffmpeg) in Java eingebunden sind.Warum kann fread() nicht funktionieren (überspringt Bytes) unter Msys/MinGw?

Mein Windows ist x64 Win 7 prof, aber alle verwendeten Bibliotheken sind 32bit. Ich betreiben Compilierung unter MinGW/MSys, unter Msys Shell mit dem followinf Skript:

#!/bin/sh 
export JAVA_HOME=/C/Program\ Files\ \(x86\)/Java/jdk1.6.0_25 
export XUGGLE_HOME=/C/Xuggler 

PATH=$XUGGLE_HOME/bin:/C/Program\ Files\ \(x86\)/Java/jdk1.6.0_25/bin:/d/APPS/msysgit/msysgit/bin/git:/D/APPS/MinGW/bin:/bin:/D/APPS/apa che-ant-1.8.2/bin:/D/Users/Dims/Design/MinGW/Util:$PATH 
ant -Dbuild.m64=no run-tests 

Ant-Ziel enthält am Ende einige Tests, die einen Fehler geben. Der Fehler folgt

[exec] Running 6 tests.. 
[exec] In StdioURLProtocolHandlerTest::testRead: 
[exec] ../../../../../../../../../test/csrc/com/xuggle/xuggler/io/StdioURLProtocolHandlerTest.cpp:108: Error: Expected (4546420 == totalBytes), found (4546420 != 1042) 
[exec] In StdioURLProtocolHandlerTest::testReadWrite: 
[exec] ../../../../../../../../../test/csrc/com/xuggle/xuggler/io/StdioURLProtocolHandlerTest.cpp:185: Error: Expected (4546420 == totalBytes), found (4546420 != 1042) 
[exec] In StdioURLProtocolHandlerTest::testSeek: 
[exec] ../../../../../../../../../test/csrc/com/xuggle/xuggler/io/StdioURLProtocolHandlerTest.cpp:139: Error: Expected (4546420 == totalBytes), found (4546420 != 1042) 
[exec] . 
[exec] Failed 3 of 6 tests 
[exec] Success rate: 50% 
[exec] FAIL: xugglerioTestStdioURLProtocolHandler.exe 

UPDATE 1

Der Code Test folgt:

int32_t totalBytes = 0; 
do { 
    unsigned char buf[2048]; 
    retval = handler->url_read(buf, (int)sizeof(buf)); 
    if (retval > 0) 
     totalBytes+= retval; 
} while (retval > 0); 
VS_TUT_ENSURE_EQUALS("", 4546420, totalBytes); 

Während der url_read Code folgt:

int 
StdioURLProtocolHandler :: url_read(unsigned char* buf, int size) 
{ 
    if (!mFile) 
     return -1; 
    return (int) fread(buf, 1, size, mFile); 
} 

Ich verstehe nicht, Unter welchen Umständen kann es 1042 zurückgeben? ? Könnten 64 Bit hier irgendwie spielen?

UPDATE 2

druckte ich Dateinamen verwendet, und es war

d:/......./../../../test/fixtures/testfile.flv 

der Pfad korrekt ist, sondern begann mit d:/ nicht mit /d/

dies eine Rolle unter Msys spielen können ?

UPDATE 3

ich den READEN Bytes mit realem Inhalt der Testdatei und gefunden verglichen habe, überspringt die fread() aus irgendeinem Grunde einige Bytes. Sie wissen nicht, was noch Bytes, wahrscheinlich sind diese CR/LF

UPDATE 4

Nicht mit CR/LF bezogen, denke ich.

Original-Bytes ist

46 4C 56 01 05 00 00 00 09 00 00 00 00 12 00 00 F4 00 00 00 00 00 00 00 02 00 0A 6F 6E 4D 65 74 61 44 61 74 61 08 00 00 ... 

READEN Bytes sind

46 4C 56 15 00 09 00 00 12 00 F4 00 00 00 02 0A 6F 6E 4D 65 74 61 44 61 74 61 80 00 B0 86 47 57 26 17 46 96 F6 E0 40 62 ... 

Diese Datei FLV beginnen. Ich verstehe das Prinzip der Korruption nicht. Wie kann 01 05 00 00 in nur 15 transformieren?

UPDATE 5

Datei geöffnet wird, wie folgt

getan
void 
StdioURLProtocolHandlerTest :: testRead() 
{ 
    StdioURLProtocolManager::registerProtocol("test"); 
    URLProtocolHandler* handler = StdioURLProtocolManager::findHandler("test:foo", 0,0); 
    VS_TUT_ENSURE("", handler); 

    int retval = 0; 
    retval = handler->url_open(mSampleFile, URLProtocolHandler::URL_RDONLY_MODE); 
    VS_TUT_ENSURE("", retval >= 0); 

    int32_t totalBytes = 0; 
    printf("Bytes:\n"); 
    do { 
    //... 

url_open() Funktion folgt:

int StdioURLProtocolHandler :: url_open(const char *url, int flags) 
{ 
    if (!url || !*url) 
    return -1; 
    reset(); 
    const char * mode; 

    switch(flags) { 
    case URLProtocolHandler::URL_RDONLY_MODE: 
     mode="r"; 
     break; 
    case URLProtocolHandler::URL_WRONLY_MODE: 
     mode="w"; 
     break; 
    case URLProtocolHandler::URL_RDWR_MODE: 
      mode="r+"; 
      break; 
     default: 
     return -1; 
    } 

    // The URL MAY contain a protocol string. Find it now. 
    char proto[256]; 
    const char* protocol = URLProtocolManager::parseProtocol(proto, sizeof(proto), url); 
    if (protocol) 
    { 
    size_t protoLen = strlen(protocol); 
    // skip past it 
    url = url + protoLen; 
    if (*url == ':' || *url == ',') 
     ++url; 
    } 
// fprintf(stderr, "protocol: %s; url: %s; mode: %s\n", protocol, url, mode); 
    mFile = fopen(url, mode); 
    if (!mFile) 
    return -1; 
    return 0; 
} 
+0

Wie öffnen Sie diese Datei? – Mat

+0

Siehe Update 5. Sieht nicht verdächtig aus. – Dims

+1

Sieht verdächtig aus. Nein "b" im offenen Modus. – Mat

Antwort

1

Sollte im GIT-Repository auf dem CROSS_COMPILE Zweig befestigt werden, wie von heute. Ich werde dies später in dieser Woche/Anfang nächster Woche in die Spitze des Baumes rollen.

Nun ist die stdio Handler öffnet alle Dateien als binär.

+0

Danke. Ist es empfehlenswert den Benutzer 'cross_compile' zu ​​benutzen, um für Windows zu kompilieren? I.e. Ich kann den Compiler unter Linux ausführen, bekomme aber eine Binärdatei für Windows, richtig? – Dims

+0

Master enthält jetzt dieses Update und die vordefinierte JAR-Datei, die auf unserem Efeu-Repository verteilt wird, enthält alle OS. Sie werden Windows Builds NICHT standardmäßig erhalten, wenn Sie unter Linux bauen. Sie müssen Cross-Compiling aktivieren (suchen Sie im Blog nach wie). –