Closed Bug 631792 Opened 14 years ago Closed 14 years ago

html5 video & source element work with ftp, but not with http

Categories

(Core :: Audio/Video, defect)

x86_64
Windows 7
defect
Not set
major

Tracking

()

VERIFIED INVALID

People

(Reporter: janbassez, Unassigned)

References

()

Details

User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b11pre) Gecko/20110202 Firefox/4.0b11pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b11pre) Gecko/20110202 Firefox/4.0b11pre http://ows.freeshell.org/test1.1.html Both latest firefox 4.0b11pre (build 2011-02-02) & latest firefox 3.6 just show the 'poster' image there. The files here (WebM used on FF4 & Ogv used on FF3.6) are hosted on a http server The same test here: http://ows.freeshell.org/test1.html Works fine, the only difference being the files are hosted on a ftp server. (The way it should be where my site is hosted) To make the problem even more complex: Chrome9 & Opera11 do the opposite. They work fine when the video files are hosted on http, but fail when they are on ftp... (chrome just shows control+poster image, Opera crashes) latest Safari works fine through the ftp, however, I've not yet tested it through the http test-page. (need to pump a mp4 vesion there first...) (IE9 simply doesn't work for the ftp page, have not yet tested it through http (also needs that mp4 version) Reproducible: Always Steps to Reproduce: 1. goto http://ows.freeshell.org/test1.1.html 2. see the video-poster, but not being able to play the file 3. goto http://ows.freeshell.org/test1.html 4. see that it works fine 5. compare the code of both pages and try to see why....? (look for the video source address, one links to an test1.1.html links to files on http server, test1.html to files on ftp server) Actual Results: test1.1.html: Poster image of video is shown, as you would expect if no file is either compatible or found. However, the same files, but hosted on ftp (in test1.html) do work correctly with the same code. Expected Results: both test1.1html & test1.html should yield the same results -> a working video file (a WebM for FF4, a Ogg video for FF3.6)
Component: Extension Compatibility → General
Keywords: html5
The following HTTP headers are sent by the web server of these pages: http://ows.untergrund.net/test/kingsq-test1.webm Content-Type: text/plain (This needs to be: video/webm) http://ows.untergrund.net/test/Asjbrain-WeRallKs&Qs-test4.ogv Content-Type: text/plain (This needs to be: video/ogg) See https://developer.mozilla.org/En/Media_formats_supported_by_the_audio_and_video_elements#section_4
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Component: General → Extension Compatibility
Keywords: html5
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
Component: Extension Compatibility → Video/Audio
Product: Firefox → Core
QA Contact: extension.compatibility → video.audio
Version: unspecified → Trunk
I just rechecked whole my code. made all details conform to w3c-validator for html5... Why do they return text/plain, the code defines them as video/webm & video/ogg?? Why the same code works when hosted on ftp, but not on http? why does it do the opposite on Chrome, IE9 & Opera? Did you check the source of the pages? (very small source, as it just contains the video in the body) I expect the same behaviour from http or ftp sources...
Status: VERIFIED → UNCONFIRMED
Component: Video/Audio → General
Product: Core → Firefox
Resolution: INVALID → ---
Version: Trunk → unspecified
Component: General → Video/Audio
Product: Firefox → Core
Version: unspecified → Trunk
The if the web server sends a mime type it is the most important one. Specifying it in the code is subordinate to the server mime type. If you are using Apache HTTPD see http://httpd.apache.org/docs/current/mod/mod_mime.html
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
Thanks a lot, problem solved! hope the same works for the other bunch of browser which show the opposite problem. (unfortunatly not everyone has FF:(
You need to log in before you can comment on or make changes to this bug.