can somebody explain to me why I can't upload my pov animations, MPEG 4
compressed, directly to my site?
The work fine when they're on my hd, but the browser won't read them off
the web.  I get that broken clip icon.

ADB.

Post a reply to this message

The problem is, that, although it works fine on my computer, once I upload
the file, not even quicktime will read it.  I get this error message that
says, "this file is not in a recognizable format." or somesuch.

ADB.

Darren New wrote:

> Anthony D. Baye wrote:
> > The work fine when they're on my hd, but the browser won't read them off
> > the web.  I get that broken clip icon.
>
> Sounds like your web server is not indicating the correct content-type.
> If it's IIS, make sure the server has an entry for the extension listed
> in "Tools->Folder options->File types" with the right mime type set. If
> it's Apache, look in something like "mime-types" or some such, and make
> sure the extension is mapped to the right content type.
>
> --
> Darren New, San Diego CA USA (PST)
>    I am in geosynchronous orbit, supported by
>    a quantum photon exchange drive....

Post a reply to this message

In article <40706b92@news.povray.org>, dne### [at] sanrrcom says...
> You also need to upload it in "binary" mode, if you're not already.
> 

You know.. I never quite understood why such and option even existed. If 
I upload a text file in binary mode is it going to explode or something? 
lol Seriously, the option of which of the two to use only adds confusion 
and makes it more likely that people will screw something up. Data is 
data and all of it is basically binary anyway, the servers don't bloody 
care.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Anthony D. Baye wrote:

> The problem is, that, although it works fine on my computer, once I upload
> the file, not even quicktime will read it.  I get this error message that
> says, "this file is not in a recognizable format." or somesuch.
> 
    If you upload by ftp, take care of the mode transfert:
    you must be in "binary" mode when transfering the file
    to the server.
    After upload you can check the "Content-type:" returned
    by the server, too. If you have an Unix box:
      $ lynx -head -dump http://serveur/foo.mpeg
    do the job.

-- 
http://tth.vaboofer.com/Cette/

Post a reply to this message

>>You also need to upload it in "binary" mode, if you're not already.

> You know.. I never quite understood why such and option even existed.

It's about line breaks. They are different on different systems (Windows 
CRL+LF, Un*x CR and Mac LF) and if you use ascii-transfer-mode, they 
will be automatically corrected to the ones the server uses.

Florian

Post a reply to this message

I tried your suggestions and I still get nothing.

I'm running a Mac G4, (OS 9.2.1) I upload my files using Fetch.
I honsetly know nothing about the server other than it belongs to the
school, and I get webspace on it.

ADB.

"Anthony D. Baye" wrote:

> can somebody explain to me why I can't upload my pov animations, MPEG 4
> compressed, directly to my site?
> The work fine when they're on my hd, but the browser won't read them off
> the web.  I get that broken clip icon.
>
> ADB.

Post a reply to this message

Anthony D. Baye wrote:
> I tried your suggestions and I still get nothing.
> 
> I'm running a Mac G4, (OS 9.2.1) I upload my files using Fetch.
> I honsetly know nothing about the server other than it belongs to the
> school, and I get webspace on it.

One possibility is that your movies are not 'flat'.

By default Mac QT movies store vital stuff in their resource fork.
This tends not to get copied across when you move something
to a non mac environment, and that environment wouldn't know what
to do with it anyway.

You need to see if the software producing the movie as a flatten movie 
option, its often called 'Make movie self-contained'.


Dave

Post a reply to this message

In article <4071ad90$1@news.povray.org> , David Burnett 
<var### [at] ntlworldcom>  wrote:

> Anthony D. Baye wrote:
>> I tried your suggestions and I still get nothing.
>>
>> I'm running a Mac G4, (OS 9.2.1) I upload my files using Fetch.
>> I honsetly know nothing about the server other than it belongs to the
>> school, and I get webspace on it.
>
> One possibility is that your movies are not 'flat'.
>
> By default Mac QT movies store vital stuff in their resource fork.
> This tends not to get copied across when you move something
> to a non mac environment, and that environment wouldn't know what
> to do with it anyway.
>
> You need to see if the software producing the movie as a flatten movie
> option, its often called 'Make movie self-contained'.

Well, all current versions of QuickTime produce flat movies by default.  And
the default configuration of Fetch used to be that it automatically binhexes
files with a resource fork.  Apart from that, he is talking about MPEG-4
files, so this should not be the issue anyway.  However, fact is that even
current versions of the two most popular web servers do not come with an
MPEG-4 content-type setting for files with an MPEG-4 file extension...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <407074fe$1@news.povray.org>, tor### [at] torfboldcom says...
> >>You also need to upload it in "binary" mode, if you're not already.
> 
> > You know.. I never quite understood why such and option even existed.
> 
> It's about line breaks. They are different on different systems (Windows 
> CRL+LF, Un*x CR and Mac LF) and if you use ascii-transfer-mode, they 
> will be automatically corrected to the ones the server uses.
> 
Hmm. Yeah. I remember reading that. It is still imho bloody stupid. Most 
'good' programs will also automatically work with both, so it is now 
still more of a pain in the backside than helpful now.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

In article <4070963a@news.povray.org>, dne### [at] sanrrcom says...
> Patrick Elliott wrote:
> > You know.. I never quite understood why such and option even existed.
> 
> Because FTP (and hence many other internet standards) use CR followed by 
> LF to indicate the end of a line, while UNIX went askew and decided to 
> drop the CR off the ends of lines to make it easier to program.
> 
> Hence, if you copy a Unix-based file with only LFs to a Windows-based OS 
> (or, for that matter, any of the many other OSes popular around the time 
> such things were being created), it needs to stuff a CR before each LF 
> in order to make it a valid text file.  If it's something like an 
> executable or a .gif or something, doing that will corrupt the file, 
> since those files aren't supposed to have CRs before every LF.
> 
> Had UNIX stuck with CRLF meaning end of line, or had internet standards 
> mandated that CR, LF, or CRLF would all be valid end-of-line markers in 
> a byte stream, we wouldn't need that.
> 
Yeah. I get that, but like anything else, it is a matter of designing the 
programs on the machine to handle the problem, not assuming that the guy 
downloading it will be on whatever system the machine storing it uses. I 
mean, lets say I upload a Windows file to a unix server, then later 
download it again to a Windows machine. Only in the last step I forget to 
do it in text mode. Oops! It creates problems, not solving it.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message