Closed Bug 122300 Opened 23 years ago Closed 23 years ago

(Quicktime)SMIL fails to load when content-length header is absent

Categories

(Core Graveyard :: Plug-ins, defect, P2)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME
Milestone:
mozilla1.0

People

(Reporter: arun, Assigned: serhunt)

References

(
URL
)

Details

1. Go to above-mentioned site (trailers.warnerbros.com) using any Gecko-based browser in which about:plugins (or visiting http://home.netscape.com/plugins/manager.html) tells you what you've got. Make sure you've got Quicktime, preferably the latest (5.02 and above). 2. Click on any movie trailer and choose Quicktime. You'll merely see a broken Quicktime icon. Explanation: along with the EMBED tag, the site is including the QTSRC attribute which gives the URL of a *.smil file. Depending on how we toggle with this, the content works: 1. If the QTSRC attribute is removed altogether, the trailer displays. The trailer is in fact a *.mov file, so doing away with the SMIL descriptor seems to work. 2. IF the SMIL file is NOT indented, the trailer works! This is ultimately the crux of the issue: who's fault is it that a SMIL file, when served over HTTP/1.1, shouldn't be indented? Necko's , Gecko's, or Quicktime's? :-) Expected Behavior: rather than a broken movie icon, Quicktime plays the video just as it does in Communicator 4.x. Actual Behavior: Broken Quicktime icon; no movie trailer plays.
Note: Bug 108726 provides some history that *may* be useful.
The problem with Mozilla not saving extensions in the cache (for plugins) is bug 90558. This also prevents us from working with the LiveAudio plugin which was shipped with 4.x.
Nominating nsbeta1 based on the nomination criteria -- this is important to Warner Bros., so someone ought to make a call on whether this is really a dup of bug 90558
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9.9
Adding gordon who is working on bug 90558.
This doesn't sound like the same problem as bug 90558. It sounds like there are a couple of work arounds to this one. cc'ing Darin for necko/http views. I'm not sure what it means to "indent" a SMIL file. I'm happy to be educated.
By indenting we mean tabbing the lines in the file, we thought having all the code left-justified would fix the problem, but it hasn't
Per a conference call with Apple, it was determined that Quicktime wasn't doing the right thing because it wasn't getting the right exention on a cached file from the NPAPI.
> Per a conference call with Apple, it was determined that Quicktime > wasn't doing the right thing because it wasn't getting the right > exention on a cached file from the NPAPI. This is not correct. Although the original file has an extension, the cached file (path passed to the plug-in in NPP_StreamAsFile) does not have an extension or a file type. Without either, it is impossible for QuickTime to unambiguiosly identify the file's contents in many cases.
I think that's what Peter was trying to say. The issue of the cache not setting file extensions is bug 90558. I had the impression there were additional issues in this bug. Is that correct, or does everyone really beleive this is just a duplicate of bug 90558?
It's true that workarounds exist for this issue, but if everything ran without workarounds, we're still broken on the deployment of SMIL files with the standard SMIL mimetype in Quicktime. So, this problem becomes bug 90558 provided that bug 90558 is fixed in a way that existing third party applications can determine extension from cache. If bug 90558 is fixed in a way that in the future third party applications have to change the way they determine extensions from cache, then this problem remains a separate one, e.g. I guess look at Darin's question in bug 90558 Comment 7 .
The following is our latest test group: http://trailers.warnerbros.com/dev/dave/test1.html Points to the generated smil file at: http://trailers.warnerbros.com/web/synmedia/GeneralPublicUS/trailers/us/quicktim e/rock_star_trailer.smil http://trailers.warnerbros.com/dev/dave/test2.html Points to the static smile file at: http://trailers.warnerbros.com/dev/dave/rock_star_trailer.smil All smil files are valid smil using XML declarations. The only difference we found was that the static file has the Content-Length present while the generated one has Content-Disposition.
Possible dup of bug 115308 ???
Plussing per ADT. I'll let someone else mark it as a dupe of other bugs mentioned here.
Keywords: nsbeta1 → nsbeta1+
Target Milestone: mozilla0.9.9 → mozilla1.0
Both tests are working for me in 0.9.8
How is this related to bug 115308?
According to the 0.9.8 release notes: Plugins that post data without http content length headers will fail. (Bug 115308 is fixed on the trunk.) Test one (comment #11) generates a smil file w/out the content-length header
After testing valid identical smil files on several different servers we found that smil worked on NS6/Moz on all servers except our generated smil files on trailers.warnerbros.com (static files on trailers.warnerbros.com worked). The generated files posted the following: HTTP/1.1 200 ok Server: Netscape-Enterprise/3.6 SP3 Date: Fri, 15 Feb 2002 21:34:42 GMT Content-Type: application/smil Content-Disposition: inline; filename=rock_star_trailer.smil Content-Language: en Connection: close While the working (static) files posted: HTTP/1.1 200 OK Server: Netscape-Enterprise/3.6 SP3 Date: Sat, 02 Mar 2002 01:18:55 GMT Content-type: application/smil Etag: "30b38-27c-3c6d968e" Last-modified: Fri, 15 Feb 2002 23:15:26 GMT Content-length: 636 Accept-ranges: bytes The difference we noted being that the generated file did not report the content-length header. We have since updated the system on our dev enviornment and retested NS 6.x and found that the smil files are working now. Although there may be other issues relating to QTSRC and caching, our issue was due to the absence of the header and has now been resolved, also it should be noted that this issue was not present on moz 0.9.8+
Depends on: 90558
Priority: -- → P2
We just tested this using the current trunk build (20020311) on win32 and the movies still don't launch correctly. I also tried this on IE6 and on 4.x and they didn't seem to work there either. I tried launching the new Austin Powers and Casablanca clips.
Did you see a broken plugin Icon or did it just load forever?
No broken icon, it just continues to cycle through the load sequence
You're probably behind a firewall so u have to change the QuickTime Streaming Transport settings: Go to you control panel Click on the quicktime icon from the drop down list select 'Streaming Transport' Change it to 'Use HTTP....' That should fix it...
yes, actually this works now(with the changes u mentioned in control panel)...
If this is working for everyone I suggegest the status be changed to fixed or duplicate (based on bug 115308) and the summary be changed to: (Quicktime)SMIL fails when content-length header is not present.
Serge said that he experimented hacking our code and found that if the correct extension is added to the cache file (or whatever file we feed the player with) everything works OK. The idea is that bug 90558 will definitely fix this one. Cc'ing serge for more input.
I think I've tested this before content-length header was added to the test environment, and by some reason without file extension nothing worked for "application/smil" mimetype at that point,(I was actually playing with live audio plugin bug 90558, I'll post my hack, which allows to save the filename+ext associated with particular mimetype into plugin's local cache, into that bug report) Now server side change seams to resolve this smil issue. I agree with David Pedowitz comment #23 we can resolve this as a WFM. I do not think this is a dup of bug 115308 which was about HTTP POST request, I have not seen any NPP_PostURL calls in above test cases.
Thanks, Serge! Resolving.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Thanks guys!!! Can we also change the summary (per comment #23)....
Summary: SMIL in QTSRC stops Quicktime from working properly → (Quicktime)SMIL fails to load when content-length header is absent
v
Status: RESOLVED → VERIFIED
This may be a long shot, but should this be added to the release notes for NS 6.x? As they are based on the previous releases of Moz where this is an issue...
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.