🚀 go-pugleaf

Bart Vandewoestyne wrote:
> Yo,
> 
> Ben momenteel bezig met het porten van mmsclient 
> (http://www.geocities.com/majormms/) naar windows.  Ik ben op een punt 
> gekomen dat ik *iets* van stream downloadt, en dat dat weggeschreven 
> wordt naar een file, maar als ik die file dan probeer te openen in 
> Windows Media Player krijg ik de boodschap dat de file corrupt is.

OK, ik ben intussen al een beetje wijzer geworden... als ik een goede 
file gedownload met de werkende linux client vergelijk met de corrupte 
file van mijn eigen implementatie via het volgende commando:

cmp -l stubrubreed_goed stubrubreed_fout | more

dan krijg ik het volgende te zien:

  2053  12  15
  2054   0  12
  2056 210   0
  2057   0 210
  2059  17   0
  2060   0  17
  2061 131   0
  2062 125 131
  2063   0 125
  2065   1   0
  2066 126   1
  2067  25 126
  2068 126  25
  2069  25 126
  2070   1  25
  2071   0   1
  2073 100   0
  2074 244 100
  2075 320 244

met andere woorden op positie 2053 is daar ergens een waarde '15' 
ingeslopen die er niet mag staan... indien die waarde er niet zou staan 
is alles gelijk en vermoed ik dat de file niet meer corrupt zou zijn...

Nu rest alleen nog de vraag hoe die 15 daar in sluipt...

Iemand?

Greetzzz,
mc303

Bart Vandewoestyne wrote:
> Bart Vandewoestyne wrote:
> OK, ik ben intussen al een beetje wijzer geworden... als ik een goede
> file gedownload met de werkende linux client vergelijk met de corrupte
> file van mijn eigen implementatie via het volgende commando:
>
> cmp -l stubrubreed_goed stubrubreed_fout | more
>
> dan krijg ik het volgende te zien:
>
>   2053  12  15
>   2054   0  12
>   2056 210   0
...
> met andere woorden op positie 2053 is daar ergens een waarde '15'
> ingeslopen die er niet mag staan... indien die waarde er niet zou
> staan is alles gelijk en vermoed ik dat de file niet meer corrupt zou
> zijn...

Ben je daar zeker van? Misschien komt die 15 meermaals voor. Doe eens:
  cmp -l --ignore-initial=2052:2053 stubru_goed stubru_fout

Robrecht

Bart Vandewoestyne wrote:

> Ik *gok* dat daar dus iets verkeerd is... de hoeveelheid data die per
> recv() wordt ingelezen verschilt blijkbaar nogal van systeem tot
> systeem...

Bij een TCP stream is de grootte van de stukken in principe onvoorspelbaar, 
bij UDP moet het binnenkomen in stukken ter grootte van de pakketten. Ik 
heb totaal geen idee hoe mms:// werkt, maar aangezien het blijkbaar een 
(video of audio?) stream is, zal het waarschijnlijk wel UDP zijn.

-- 
Nicolas Barbier

Robrecht Jacques wrote:
> 
> Ben je daar zeker van? Misschien komt die 15 meermaals voor. Doe eens:
>   cmp -l --ignore-initial=2052:2053 stubru_goed stubru_fout

'k Moet hierbij toch opmerken dat die twee files die ik vergelijk vanaf 
een zeker punt inderdaad niet gelijk zijn, omdat ik niet perfect op 
hetzelfde moment beide clients zowel in linux en in windows kan opstarten.

De file die ik download is er echter blijkbaar ��n van het ASF type, en 
als ik het goed begrepen heb, hebben dergelijk soort files een bepaalde 
header die dan in mijn geval dus voor iedere download hetzelfde zou 
moeten zijn.  En die 15 die er teveel staat, dat is er volgens mij ��n 
die in de header voorkomt en die er dus teveel staat.

Vanaf een bepaald moment zijn de waarden dan inderdaad echt heel 
verschillend en merk ik die verschuiving van 1 plaats niet meer, doch 
volgens mij is dat dan omdat het dus gaat om 2 streams die ik op een 
verschillend moment heb gedownload, de data die in de body zit is dus 
anders.

Ik zou eens willen proberen om die octale waarde 15 op decimale positie 
2053 er uit te verwijderen en zien of ik die file dan kan afspelen, maar 
met hexedit lukt me dat precies niet... daar kan ik ze enkel op 0 
zetten, maar die byte verwijderen lukt precies niet :-(

Greetzzz,
mc303

Nicolas Barbier wrote:
>
> Bij een TCP stream is de grootte van de stukken in principe onvoorspelbaar, 
> bij UDP moet het binnenkomen in stukken ter grootte van de pakketten. Ik 
> heb totaal geen idee hoe mms:// werkt, maar aangezien het blijkbaar een 
> (video of audio?) stream is, zal het waarschijnlijk wel UDP zijn.

Nope, 't is TCP dat op de server connecteert op poort 1755:

...
sa.sin_port = htons(1755) ; /* be2me_16(1755);  mms port 1755 */
...
string_utf16 (&data[8], "\002\000\\\\192.168.0.129\\TCP\\1037\0000", 28);
...

Ethreal bevestigt dit.  Doch dit geheel terzijde ;-)

Greetzzz,
mc303

Bart Vandewoestyne wrote:
>
> Ben momenteel bezig met het porten van mmsclient 
> (http://www.geocities.com/majormms/) naar windows.  Ik ben op een punt 
> gekomen dat ik *iets* van stream downloadt, en dat dat weggeschreven 
> wordt naar een file, maar als ik die file dan probeer te openen in 
> Windows Media Player krijg ik de boodschap dat de file corrupt is.

Bon,

ben misschien weer een beetje dichter bij de oplossing... ik heb 
namelijk het volgende ontdekt...

Als ik de linux client run met mms://stream04.pandora.be/stubrubreed 
merk ik in het begin telkens volgende interactie tussen client en server:

request1) client -> 232 bytes -> server

answer1) client <- 128 bytes <- server

request2) client -> 112 bytes -> server

answer2) client <- 80 bytes <- server

request3) client -> 82 bytes -> server

answer3) client <- 152 bytes <- server

... enzoverder

Nu heb ik ontdekt dat bij mijn windows port answer1 en answer2 een 
foutmelding geven.  answer1 komt dan blijkbaar pas op de plaats van 
answer3 in de Linux client... 2 answers 'verschoven' dus (omdat de 
eerste 2 receives op mijn socket mislukken en de data er dan nog zit, en 
die wordt dan pas uitgelezen als ik een receive doe die wel lukt).

De twee receives die mislukken zijn de eerste twee recv() calls in de main:

len = recv(s, data, BUF_SIZE, 0) ;
...
len = recv(s, data, BUF_SIZE, 0) ;


De error die ik krijg is error 10014 en op de msdn site blijkt dit te 
betekenen:

<quote>
Bad address.
The system detected an invalid pointer address in attempting to use a 
pointer argument of a call. This error occurs if an application passes 
an invalid pointer value, or if the length of the buffer is too small. 
For instance, if the length of an argument, which is a sockaddr 
structure, is smaller than the sizeof(sockaddr).
</quote>

Nu snap ik niet wat hier verkeerd gaat... die recv() calls zijn mijn 
vertalingen van de Linux code:

len = read (s, data, BUF_SIZE) ;
...
len = read (s, data, BUF_SIZE) ;


Veel echt speciale dingen gebeuren hier toch niet, right?  Nu dacht ik 
vanwege die error 10014 echter wel dat data misscihen te klein was voor 
BUF_SIZE, en inderdaad... als ik ga kijken hoe BUF_SIZE gedefinieerd is 
in de linux code, dan zie ik daar dat die op 102400 gedefinieerd staat, 
terwijl data slechts volgende grootte heeft:

char data[1024];

Vandaar dus waarschijnlijk de error... als snap ik dan niet waarom die 
read wel lukt in de linux code ???

Ik vraag me dus af of het geen fout is in de linux code dat die BUF_SIZE 
op 102400 in plaats van 1024 gedefinieerd staat... vandaar dat ik in 
mijn windows code hem eens veranderd heb naar 1024, en als ik dat doe, 
dan lukken die twee eerste receives wel, maar dan crasht het programma 
verderop...

Wie ziet hier raad?  De code die ik tot nu toe heb staat op:

http://mc303.studentenweb.org/downloads/mmsclient/

Greetzzz,
mc303

Bart Vandewoestyne wrote:
> Bart Vandewoestyne wrote:
>>
>> Ben momenteel bezig met het porten van mmsclient 
>> (http://www.geocities.com/majormms/) naar windows.  Ik ben op een punt 
>> gekomen dat ik *iets* van stream downloadt, en dat dat weggeschreven 
>> wordt naar een file, maar als ik die file dan probeer te openen in 
>> Windows Media Player krijg ik de boodschap dat de file corrupt is.
> 
> Veel echt speciale dingen gebeuren hier toch niet, right?  Nu dacht ik 
> vanwege die error 10014 echter wel dat data misscihen te klein was voor 
> BUF_SIZE, en inderdaad... als ik ga kijken hoe BUF_SIZE gedefinieerd is 
> in de linux code, dan zie ik daar dat die op 102400 gedefinieerd staat, 
> terwijl data slechts volgende grootte heeft:
> 
> char data[1024];
> 
> Vandaar dus waarschijnlijk de error... als snap ik dan niet waarom die 
> read wel lukt in de linux code ???
> 
> Ik vraag me dus af of het geen fout is in de linux code dat die BUF_SIZE 
> op 102400 in plaats van 1024 gedefinieerd staat... vandaar dat ik in 
> mijn windows code hem eens veranderd heb naar 1024, en als ik dat doe, 
> dan lukken die twee eerste receives wel, maar dan crasht het programma 
> verderop...

Geen antwoord op je vraag, daarvoor ken ik niet genoeg van network
programming. Maar dat die BUF_SIZE op 102400 staat terwijl de buffer
maar 1024 bytes groot is wel eigenaardig; ik zou eens contact opnemen
met de auteur(s) van mmsclient.

-- 
"Codito ergo sum"
Roel Schroeven

Roel Schroeven wrote:
> 
> Geen antwoord op je vraag, daarvoor ken ik niet genoeg van network
> programming. Maar dat die BUF_SIZE op 102400 staat terwijl de buffer
> maar 1024 bytes groot is wel eigenaardig; ik zou eens contact opnemen
> met de auteur(s) van mmsclient.

Da's juist het probleem... vanwege het feit dat die mmsclient in feite 
dingen doet die Microsoft liever niet ziet, is de auteur niet gekend. 
Ik vind in alle geval nergens een referentie of emailadres terug... ik 
denk dat de auteur dus liever onbekend wenst te blijven...

Als iemand wel vindt wie de auteur is: laat maar weten.

Greetzzz,
mc303

Bart Vandewoestyne wrote:
> Ik ben op een punt 
> gekomen dat ik *iets* van stream downloadt,
				   ^^^^^^^^^

Mijn excuses voor deze toch wel deftige verkrachting van de Nederlandse 
taal ;-)

Greetzzz,
mc303

Bart Vandewoestyne wrote:
> Roel Schroeven wrote:
>> 
>> Geen antwoord op je vraag, daarvoor ken ik niet genoeg van network
>> programming. Maar dat die BUF_SIZE op 102400 staat terwijl de buffer
>> maar 1024 bytes groot is wel eigenaardig; ik zou eens contact opnemen
>> met de auteur(s) van mmsclient.
> 
> Da's juist het probleem... vanwege het feit dat die mmsclient in feite 
> dingen doet die Microsoft liever niet ziet, is de auteur niet gekend. 
> Ik vind in alle geval nergens een referentie of emailadres terug... ik 
> denk dat de auteur dus liever onbekend wenst te blijven...

Ziet er inderdaad naar uit... de eerste keer dat ik zoiets zie.

Er staat op de site wel

"This software would never have been possible without the help from
http://get.to/sdp"

Op die site staat

"... Our resulting implementation of our MMS document has lead to the
development of a MMS streaming receiver for windows media streaming. So
now, not only can you view the streaming media in preview mode, SDP
receiver downloads (or copies) the stream to your hard disk. ..."

Dus misschien kunnen zij je wel helpen. Zij hebben wel een emailadres:
sdp_man@hotmail.com.

Een andere mogelijkheid is degene die er een Gentoo package voor gemaakt
heeft, Chris Houser <chouser@gentoo.org>, hoewel ik niet weet in
hoeverre die iets kent van de interne werking van het beestje.

-- 
"Codito ergo sum"
Roel Schroeven

Roel Schroeven wrote:
>
> Ziet er inderdaad naar uit... de eerste keer dat ik zoiets zie.

Bij mij de tweede keer: ook ASFRecorder had oorspronkelijk geen auteur 
denk ik... nu staan op SourceForge blijkbaar wel 2 developers...


> Er staat op de site wel
> 
> "This software would never have been possible without the help from
> http://get.to/sdp"
> 
> Op die site staat
> 
> "... Our resulting implementation of our MMS document has lead to the
> development of a MMS streaming receiver for windows media streaming. So
> now, not only can you view the streaming media in preview mode, SDP
> receiver downloads (or copies) the stream to your hard disk. ..."
> 
> Dus misschien kunnen zij je wel helpen. Zij hebben wel een emailadres:
> sdp_man@hotmail.com.

Ik heb die mannen inderdaad al gemaild... zal zien of er iets uit de bus 
komt...

> Een andere mogelijkheid is degene die er een Gentoo package voor gemaakt
> heeft, Chris Houser <chouser@gentoo.org>, hoewel ik niet weet in
> hoeverre die iets kent van de interne werking van het beestje.

OK, zal hem ook eens mailen.  Tnx voor de tip!

Greetzzz,
mc303

Bart Vandewoestyne wrote:
>
> 'k Moet hierbij toch opmerken dat die twee files die ik vergelijk vanaf 
> een zeker punt inderdaad niet gelijk zijn, omdat ik niet perfect op 
> hetzelfde moment beide clients zowel in linux en in windows kan opstarten.

Djeezes... wat ben ik een eikel... waarom zoek ik niet gewoon een kleine 
file die aangeboden wordt volgens het MMS protocol, download ik die met 
mijn beide clients en vergelijk ik dan wat ik heb...

Als iemand een korte file weet staan die gestreamd wordt met MMS, dan 
zou ik u eeuwig dankbaar zijn... hoe minder lang dat ie duurt, hoe beter :-)

Greetzzz,
mc303

Bart Vandewoestyne schreef:
> Bart Vandewoestyne wrote:
> >
> > 'k Moet hierbij toch opmerken dat die twee files die ik vergelijk vanaf 
> > een zeker punt inderdaad niet gelijk zijn, omdat ik niet perfect op 
> > hetzelfde moment beide clients zowel in linux en in windows kan opstarten.
> 
> Djeezes... wat ben ik een eikel... 
> 
Wel, je hebt in ieder geval de energie om lang door te gaan met een 
project :-)

> waarom zoek ik niet gewoon een kleine 
> file die aangeboden wordt volgens het MMS protocol, download ik die met 
> mijn beide clients en vergelijk ik dan wat ik heb...
> 
Klinkt goed.

> Als iemand een korte file weet staan die gestreamd wordt met MMS, dan 
> zou ik u eeuwig dankbaar zijn... hoe minder lang dat ie duurt, hoe beter :-)
> 
Even zoeken met Google op bijvoorbeeld 'small mms stream' levert al snel 
<http://www.tntech.edu/its/pubs/Stream/default.htm#win> op waar o.a. de 
stream <mms://stream.tntech.edu/welcome1.asf> (17 seconde) op te vinden 
is.

> Greetzzz,
> mc303


Groet,

Wimjan

-- 
Iemands e-mailadres kwijt? Probeer m'n meta e-mail zoeker eens op 
<http://inventio.nl/metanamesearch/>

Wimjan wrote:
> 
>>Als iemand een korte file weet staan die gestreamd wordt met MMS, dan 
>>zou ik u eeuwig dankbaar zijn... hoe minder lang dat ie duurt, hoe beter :-)
> 
> Even zoeken met Google op bijvoorbeeld 'small mms stream' levert al snel 
> <http://www.tntech.edu/its/pubs/Stream/default.htm#win> op waar o.a. de 
> stream <mms://stream.tntech.edu/welcome1.asf> (17 seconde) op te vinden 
> is.

Bedankt!  Ik had wat zitten zoeken op 'MMS demo stream' of zoiets, maar 
vond niet direct iets korts... de link die jij postte is ideaal, ik weet 
weer wat gedaan vandaag :-)

Greetzzz,
mc303

Bart Vandewoestyne wrote:
> 
> Ben momenteel bezig met het porten van mmsclient 
> (http://www.geocities.com/majormms/) naar windows.  Ik ben op een punt 
> gekomen dat ik *iets* van stream downloadt, en dat dat weggeschreven 
> wordt naar een file, maar als ik die file dan probeer te openen in 
> Windows Media Player krijg ik de boodschap dat de file corrupt is.

Bon, misschien heb ik er een idee van waar de fout zou kunnen zitten... 
volgens mij gaat het ergens fout in de get_data() methode.  In de Linux 
client ziet die er zo uit:

static int get_data (int s, char *buf, size_t count) {

   ssize_t  len, total;

   total = 0;

   while (total < count) {

     len = read (s, &buf[total], count-total);

     if (len<0) {
       perror ("read error:");
       return 0;
     }

     total += len;

     if (len != 0) {
       printf ("[%d/%d]", total, count);
       fflush (stdout);
     }

   }
   return 1;
}

Ik heb ze als volgt vertaald naar windows:

static int get_data (int s, char *buf, unsigned int count) {

   unsigned int len, total;

   total = 0;

   while (total < count) {  /* while we don't have all data yet... */

     len = recv(s, &buf[total], count-total, 0);  /* receive the rest for
						    as much as we can
						    get */

     if (len<0) {
       perror ("read error in get_data():");
       return 0;
     }

     /* increase the number indicating how much we've read */
     total += len;

     if (len != 0) {
       /* print out how much we've read already */
       printf ("[%d/%d]", total, count);
       fflush (stdout);
     }
   }
   return 1;
}

Ik vermoed dat het ergens zit in het feit dat ik die read vervangen heb 
dor een recv... en dat die parameters niet hetzelfde mogen 
ge�nterpreteerd worden... zo zou bij recv() de derde parameter de lengte 
van de buffer moemten zijn... en bij read is dat 'het aantal bytes dat 
je wil lezen'... ik zou hier vermoeden dat het in feite toch op 
hetzelfde neerkomt... maar ik zie niet in waar het fout gaat...

Ziet iemand hier iets merkwaardigs?

De volledige source staat op 
http://mc303.studentenweb.org/downloads/mmsclient/

Greetzzz,
mc -puzzled here- 303

Bart Vandewoestyne wrote:
> Bart Vandewoestyne wrote:
>> 
>> Ben momenteel bezig met het porten van mmsclient 
>> (http://www.geocities.com/majormms/) naar windows.  Ik ben op een punt 
>> gekomen dat ik *iets* van stream downloadt, en dat dat weggeschreven 
>> wordt naar een file, maar als ik die file dan probeer te openen in 
>> Windows Media Player krijg ik de boodschap dat de file corrupt is.
> 
> Bon, misschien heb ik er een idee van waar de fout zou kunnen zitten... 
> volgens mij gaat het ergens fout in de get_data() methode.  In de Linux 
> client ziet die er zo uit:
> 
> static int get_data (int s, char *buf, size_t count) {
> 
>    ssize_t  len, total;
> 
>    total = 0;
> 
>    while (total < count) {
> 
>      len = read (s, &buf[total], count-total);
> 
>      if (len<0) {
>        perror ("read error:");
>        return 0;
>      }
> 
>      total += len;
> 
>      if (len != 0) {
>        printf ("[%d/%d]", total, count);
>        fflush (stdout);
>      }
> 
>    }
>    return 1;
> }
> 
> Ik heb ze als volgt vertaald naar windows:
> 
> static int get_data (int s, char *buf, unsigned int count) {
> 
>    unsigned int len, total;
> 
>    total = 0;
> 
>    while (total < count) {  /* while we don't have all data yet... */
> 
>      len = recv(s, &buf[total], count-total, 0);  /* receive the rest for
> 						    as much as we can
> 						    get */
> 
>      if (len<0) {
>        perror ("read error in get_data():");
>        return 0;
>      }
> 
>      /* increase the number indicating how much we've read */
>      total += len;
> 
>      if (len != 0) {
>        /* print out how much we've read already */
>        printf ("[%d/%d]", total, count);
>        fflush (stdout);
>      }
>    }
>    return 1;
> }
> 
> Ik vermoed dat het ergens zit in het feit dat ik die read vervangen heb 
> dor een recv... en dat die parameters niet hetzelfde mogen 
> ge�nterpreteerd worden... zo zou bij recv() de derde parameter de lengte 
> van de buffer moemten zijn... en bij read is dat 'het aantal bytes dat 
> je wil lezen'... ik zou hier vermoeden dat het in feite toch op 
> hetzelfde neerkomt... maar ik zie niet in waar het fout gaat...

Die fout die je krijgt, is dat WSAEMSGSIZE? Ik begin namelijk een
verschil te vermoeden tussen read en recv:

read leest in principe zo veel bytes als je vraagt. Als er minder
voorhanden zijn krijgt je er minder, als er meer staan te wachten krijg
je er zoveel als je gevraagd had, en de rest krijg je bij een volgende
call.

recv leest een message. Als die message kleiner is dan je buffer geen
probleem, als hij te groot is heb je wel een probleem. Eigenlijk moet je
er gewoon altijd voor zorgen dat je buffer groot genoeg is, als ik het
goed begrijp. MSDN zegt:
"If the datagram or message is larger than the buffer supplied, the
buffer is filled with the first part of the datagram, and recv generates
the error WSAEMSGSIZE. For unreliable protocols (for example, UDP) the
excess data is lost; for reliable protocols, the data is retained by the
service provider until it is successfully read by calling recv with a
large enough buffer."

De volledige data wordt, denk ik, achtergehouden tot je recv aanroept
met een buffer die groot genoeg is, in plaats van alleen datgene dat
niet meer in de buffer paste.

-- 
"Codito ergo sum"
Roel Schroeven

Bart Vandewoestyne wrote:
> 
> Bon, misschien heb ik er een idee van waar de fout zou kunnen zitten... 
> volgens mij gaat het ergens fout in de get_data() methode.

Nevermind mensen, ik heb de fout gevonden!  Dit was wat ik fout deed:

In linux wordt de (binary) file waarnaar de output wordt weggeschreven 
als volgt geopend:

output_fh = open (&file[1], O_WRONLY | O_CREAT | O_TRUNC, 0644);

Ik had die regel gewoon overgenomen... pas na het lezen van mijn 
'Practical C programming' O'Reilly boekje kwam ik erachter dat er in 
Windows ook nog zo'n flag bestaat als O_BINARY, en die heb je in Linux niet.

Na toevoegen van die flag werkt mijn proggie netjes, zonder dat ik 
Cygwin nodig heb, whoehoew :-)

Bij deze deel ik jullie dus mede dat ik volgens mij, als ik het allemaal 
goed voorheb, de trotste eerste auteur ben van een Open Source programma 
voor Windows waarmee het mogelijk is om MMS-streams � la bv. deze van de 
stubru site te downloaden.  Uiteraard dient iedereen te beseffen dat dit 
in feite illegaal is, en ik ben dus ook gewoon de auteur van een 
educatief ding dat ik enkel en alleen geschreven heb om mijn C-kennis 
weer wat op te frissen :-)

Ik ga nog effe wachten om de werkende code nu vrij te geven, eerst nog 
effe de boel wat proper opkuisen en wat mooie commentaar toevoegen.  Wie 
weet voelt iemand zich dan wel geroepen om dan later van tijd een GUI 
toe te voegen...

Greetzzz,
mc303

Bart Vandewoestyne schreef:
> 
> Bij deze deel ik jullie dus mede dat ik volgens mij, als ik het allemaal 
> goed voorheb, de trotste eerste auteur ben van een Open Source programma 
> voor Windows waarmee het mogelijk is om MMS-streams � la bv. deze van de 
> stubru site te downloaden.  
> 
En <http://sourceforge.net/projects/javamms/> dan? :)


Groet,

Wimjan

-- 
Iemands e-mailadres kwijt? Probeer m'n meta e-mail zoeker eens op 
<http://inventio.nl/metanamesearch/>

Wimjan wrote:
> 
> En <http://sourceforge.net/projects/javamms/> dan? :)

*fuck*
;-)

Greetzzz,
mc303

PS: krijg jij dat ding werkende?  Als ik da opstart en een mms:// url 
invul en op 'Go' druk gebeurt er na het ingeven van de output file niet 
veel...

Bart Vandewoestyne schreef:
> Wimjan wrote:
> > 
> > > [eerste mms-downloader voor Windows]
> > 
> > En <http://sourceforge.net/projects/javamms/> dan? :)
> 
> *fuck*
> ;-)
>
:)
 
> Greetzzz,
> mc303
> 
> PS: krijg jij dat ding werkende?  Als ik da opstart en een mms:// url 
> invul en op 'Go' druk gebeurt er na het ingeven van de output file niet 
> veel...
> 
Weet ik veel, ik zat je maar te pesten. Even checken.
*hoe werkt dat ook weer allemaal, pruts, fruttel*

Ah, 'java -jar JavaMMS.jar'. url opgeven, uitvoerbestand opgeven - hij 
loopt (de progress bar begint te lopen). Het gaat wel erg traag en in het 
DOS-venster komen talloze meldingen (foutmeldingen?). De download stopt 
trouwens bij mij op 96% (hoewel het filmpje wel compleet lijkt te zijn).


Had je op <http://javamms.sourceforge.net/> gelezen dat je minstens Java 
1.4 nodig hebt? Zie trouwens ook de link naar <http://sdp.ppona.com/> op 
de genoemde pagina - volgens mij wel interessant voor je:

<citaat>
We are a nonprofit team with only one goal - understanding (and 
documenting) MMS fully. Our resulting implementation of our MMS document 
has lead to the development of a MMS streaming receiver for windows media 
streaming. So now, not only can you view the streaming media in preview 
mode, SDP receiver downloads (or copies) the stream to your hard disk. 
This cannot be achieved with a standard Windows Media player. 
We believe our project to be the only one of its kind in the world (or at 
least the first of many!) with other MMS developers using our findings as 
a basis for their own code implementations. Of that we are proud and glad 
to be of service. We are always open to comments and feedback and of 
course your own findings and information on MMS are welcome.

Remember, SDP can now download the following protocols, not just mms:
Http v1.0 streaming protocol, Http progressive (simple http download) and 
of course: mms, mmst and mmsu over TCP or UDP transport protocol. That's 
everything you need for Windows� Media streaming. All with full proxy 
support.
</citaat>

En vlak daaronder kun je een spec van het MMS-protocol downloaden.


Groet,

Wimjan

-- 
Iemands e-mailadres kwijt? Probeer m'n meta e-mail zoeker eens op 
<http://inventio.nl/metanamesearch/>

Wimjan wrote:
> 
> Ah, 'java -jar JavaMMS.jar'. url opgeven, uitvoerbestand opgeven

Uh?  Waar geef jij de url en waar het uivoerbestand?  Ik krijg enkel dit 
te zien:

http://mc303.studentenweb.org/downloads/mmsdownloader.jpg

Ik zie daar maar ��n textveld bij mij... heb het op een linux bak ook 
gestart en net hetzelfde.


> Had je op <http://javamms.sourceforge.net/> gelezen dat je minstens Java 
> 1.4 nodig hebt? Zie trouwens ook de link naar <http://sdp.ppona.com/> op 
> de genoemde pagina - volgens mij wel interessant voor je:

Jaja, ik gebruik java 1.4.


> <citaat>
> We are a nonprofit team with only one goal - understanding (and 
> documenting) MMS fully. Our resulting implementation of our MMS document 
> has lead to the development of a MMS streaming receiver for windows media 
> streaming. So now, not only can you view the streaming media in preview 
> mode, SDP receiver downloads (or copies) the stream to your hard disk. 
> This cannot be achieved with a standard Windows Media player.

Inderdaad.  Dat had ik ook al gevonden, maar als ik het goed voor heb is 
  de code van dat ding niet vrijgegeven, right?

> Remember, SDP can now download the following protocols, not just mms:
> Http v1.0 streaming protocol, Http progressive (simple http download) and 
> of course: mms, mmst and mmsu over TCP or UDP transport protocol. That's 
> everything you need for Windows� Media streaming. All with full proxy 
> support.

Trouwens... nu we toch bezig zijn... weet iemand een Open Source tool om 
rtsp:// streams te downloaden?

> En vlak daaronder kun je een spec van het MMS-protocol downloaden.

Die heb ik uiteraard al lang gedownload en doorworsteld in de zoektocht 
om mijn eigen port naar Windows in orde te krijgen :-)

Greetzzz,
mc303

Bart Vandewoestyne wrote:
> 
> Ik zie daar maar ��n textveld bij mij... heb het op een linux bak ook 
> gestart en net hetzelfde.

Oops... foutje van mij... uiteraard komt het ingeven van de output file 
slechts als ge op 'Go' gedrukt hebt... Sorry voor deze blunder... :-)

Maar nog steeds loopt het vast op mijn WinXP bak... in linux werkt het 
blijkbaar wel naar behoren.

Greetzzz,
mc303

Bart Vandewoestyne schreef:
> Wimjan wrote:
> > 
> > Ah, 'java -jar JavaMMS.jar'. url opgeven, uitvoerbestand opgeven
> 
> Uh?  Waar geef jij de url en waar het uivoerbestand?  Ik krijg enkel dit 
> te zien:
> 
> http://mc303.studentenweb.org/downloads/mmsdownloader.jpg
>
> Ik zie daar maar ��n textveld bij mij... heb het op een linux bak ook 
> gestart en net hetzelfde.
> 
... maar je vond het blijkbaar zelf al:

> Oops... foutje van mij... uiteraard komt het ingeven van de output file 
> slechts als ge op 'Go' gedrukt hebt... Sorry voor deze blunder... :-)
> 
> Maar nog steeds loopt het vast op mijn WinXP bak... in linux werkt het 
> blijkbaar wel naar behoren.
> 
Geen idee waarom. Ik gebruik Win98se en daar loopt het -hoewel errug 
langzaam- iets heter.
 
> > Had je [...] gelezen dat je minstens Java 1.4 nodig hebt? 
> 
> Jaja, ik gebruik java 1.4.
>
Ok.
 
> 
> > <citaat>
> > We are a nonprofit team with only one goal - understanding (and 
> > documenting) MMS fully. Our resulting implementation of our MMS document 
> > has lead to the development of a MMS streaming receiver for windows media 
> > streaming. So now, not only can you view the streaming media in preview 
> > mode, SDP receiver downloads (or copies) the stream to your hard disk. 
> > This cannot be achieved with a standard Windows Media player.
> 
> Inderdaad.  Dat had ik ook al gevonden, maar als ik het goed voor heb is 
>   de code van dat ding niet vrijgegeven, right?
>
Right - er staat letterlijk: "we do not supply source code for our own 
implementations." 

> > En vlak daaronder kun je een spec van het MMS-protocol downloaden.
> 
> Die heb ik uiteraard al lang gedownload en doorworsteld in de zoektocht 
> om mijn eigen port naar Windows in orde te krijgen :-)
> 
Ok, 't was maar een suggestie.

> Trouwens... nu we toch bezig zijn... weet iemand een Open Source tool om 
> rtsp:// streams te downloaden?
>
Wellicht <http://mpeg4ip.sourceforge.net/>? 

> Greetzzz,
> mc303


Groet,

Wimjan

-- 
Iemands e-mailadres kwijt? Probeer m'n meta e-mail zoeker eens op 
<http://inventio.nl/metanamesearch/>

Wimjan wrote:
> 
>>Trouwens... nu we toch bezig zijn... weet iemand een Open Source tool om 
>>rtsp:// streams te downloaden?
> 
> Wellicht <http://mpeg4ip.sourceforge.net/>? 

Hmm... sorry... ik heb me te weinig concreet uitgedrukt... ik bedoelde 
eigenlijk voor 'Open Source tool voor Windows'...

Greetzzz,
mc303

Bart Vandewoestyne <Bart.VandewoestyneNOSPAM@pandora.be> schreef:

> Bij deze deel ik jullie dus mede dat ik volgens mij, als ik het allemaal 
> goed voorheb, de trotste eerste auteur ben van een Open Source programma 
> voor Windows waarmee het mogelijk is om MMS-streams � la bv. deze van de 
> stubru site te downloaden.

Kan mplayer dat dan niet?

<http://www.mplayerhq.hu/MPlayer/releases/win32-beta/>

Ik heb toch al een paar beta's met succes uitgetest om video & audio af te 
spelen, maar wel niet met mms: (of rtsp: wat dat betreft) om eerlijk te 
zijn...

Snel even getest met die mms: link ergens in deze threads en het lukt 
inderdaad...

-- 
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

JanC wrote:
> 
> Kan mplayer dat dan niet?
> 
> <http://www.mplayerhq.hu/MPlayer/releases/win32-beta/>
> 
> Ik heb toch al een paar beta's met succes uitgetest om video & audio af te 
> spelen, maar wel niet met mms: (of rtsp: wat dat betreft) om eerlijk te 
> zijn...
> 
> Snel even getest met die mms: link ergens in deze threads en het lukt 
> inderdaad...

Een paar andere mensen hebben me daar inderdaad ook al op gewezen, maar 
hierbij toch enkele vraagskes:

1) Ben ik juist als ik zeg dat die MPlayer voor Windows gewoon de linux 
MPLayer met Cygwin gecompileerd is, en dus in feite niet native windows is?

2) Kan je eens de exacte .zip file zeggen die jij gebruikt hebt?  Ik wil 
er namelijk ook eens mee spelen, maar er staan op die URL heel wat 
verschillende versies en op den duur weet ne mens niet meer welke em nu 
best pakt...

Greetzzz,
mc303

Bart Vandewoestyne <Bart.VandewoestyneNOSPAM@pandora.be> schreef:

> 1) Ben ik juist als ik zeg dat die MPlayer voor Windows gewoon de
> linux MPLayer met Cygwin gecompileerd is, en dus in feite niet native
> windows is? 

Ze zijn gecompileerd met mingw32 en dus native:
| MinGW: A collection of freely available and freely distributable Windows 
| specific header files and import libraries combined with GNU toolsets 
| that allow one to produce native Windows programs that do not rely on any 
| 3rd-party DLLs.

> 2) Kan je eens de exacte .zip file zeggen die jij gebruikt hebt?  Ik
> wil er namelijk ook eens mee spelen, maar er staan op die URL heel wat
> verschillende versies en op den duur weet ne mens niet meer welke em
> nu best pakt...

Ik heb voor die test de volgende gebruikt vziw:
mingw32-dev-CVS-030630.zip

Er staat nu blijkbaar ook een experimentele versie v/d GUI en een 
experimentele met SSE-optimalisaties of zo, die heb ik nog niet getest...

-- 
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9