Quicktime: plugin should respect qtsrcdontusebrowser (and qtsrc) parameter

[GoogleCodeExporter]

What steps will reproduce the problem?
Load a page that embeds a quicktime movie with the parameters: src="dummy.mov" 
qtsrc="theactualclip.mov" qtsrcdontusebrowser="true"

What is the expected output? What do you see instead?
The browser should download what is in "src" parameter (dummy.mov), but if 
"qtsrcdontusebrowser" parameters is set, the plugin should let the player 
download/stream what is in the "qtsrc" parameter (theactualclip.mov).
However, gecko-mediaplayer seems to emulate user-agent as "QuickTime/7.6.4", 
and downloads both what is in "src" and "qtsrc" - using the browser.

What version of the product are you using? On what operating system?
gecko-mediaplayer-0.9.9.2, Firefox-3.6.8, on Ubuntu 10.04 Lucid Lynx.

Please provide any additional information below.
N.B. totem-mozilla recently fixed this so that the plugin respects the 
qtsrcdontusebrowser/qtsrc parameters: 
http://git.gnome.org/browse/totem/commit/?h=gnome-2-28&id=058ce0c5076a2f49659390
1692be7dd0ab6dda72

Original issue reported on code.google.com by jasmine....@yahoo.com on 19 Aug 2010 at 9:43

[GoogleCodeExporter]

Interesting... I'll have to work on that

Original comment by kdeko...@gmail.com on 20 Aug 2010 at 1:51

[GoogleCodeExporter]

Can you see if SVN r394 works correctly?

Original comment by kdeko...@gmail.com on 20 Aug 2010 at 2:01

• Changed state: Started

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

No. Sorry, my original report was not very clear or misleading.. "qtsrc" and 
"qtsrcdontusebrowser" are independant, meaning, "qtsrc" can occur without 
"qtsrcdontusebrowser". Also, "qtsrcdontusebrowser" means "force streaming", not 
just ignore "src".

Per this: http://www.apple.com/la/quicktime/tutorials/embed2.html

On QTSRC:
The attribute treats it's value as a URL to load, and ignores any data loaded 
by the browser from the "src" parameter.

ON QTSRCDONTUSEBROWSER:
By default, the behavior is set to FALSE. When set to true, the URL specified 
in the QTSRC parameter is loaded using QuickTime's internal methods, instead of 
using the browser to fetch the file. This prevents the browser from caching the 
file, which speeds access to local movies and can help prevent copying movies 
over the Web.

The main issues:
----------------

1. "qtsrc" should always override "src"

2. "qtsrcdontusebrowser" parameter can be there but without a value set as in 
the example from apple.com, since the default is false, meaning default is to 
USE browser. There are quite a few sites using it that way. Therefore, unless 
we find a value explicitly set to false (or 0), its presence should mean what 
it says: "dont use browser". And since the value can vary in case, like: 
"false" or "False" or "FALSE", we shouldn't use (case-sensitive) strstr. Also, 
per the docs, the browser is not supposed to download/cache the file (like 
"nocache"), so we should set item->streaming = TRUE.

3. Unlike the "href" parameter, "qtsrc" path is not relative to "src", so lines 
171-179 actually cause none but problems. Consider the following scenarios:

* Scenario #1:

heirarchy of files relative to webroot:

/files/media/quicktime.html
/files/dummy.mov
/files/sample.mov

embed (in /files/media/quicktime.html) has the parameters:

src="/files/dummy.mov" (0 byte file)
qtsrc="/files/sample.mov"
qtsrcdontusebrowser="true"

After requesting http://my-site.com/files/media/quicktime.html, server log 
reveals:

1.2.3.4 - - [20/Aug/2010:16:23:49 -0500] "GET /files/media/quicktime.html 
HTTP/1.1" 200 1043 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) 
Gecko/20100723 Ubuntu/10.04 (lucid) Firefox/3.6.8"
1.2.3.4 - - [20/Aug/2010:16:23:49 -0500] "GET /files/dummy.mov HTTP/1.1" 200 
287 "-" "QuickTime/7.6.4"
1.2.3.4 - - [20/Aug/2010:16:23:49 -0500] "GET /files//files/sample.mov 
HTTP/1.1" 404 1249 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) 
Gecko/20100723 Ubuntu/10.04 (lucid) Firefox/3.6.8"

* Scenario #2:

same heirarchy of files (relative to webroot) as in Scenario #1:

/files/media/quicktime.html
/files/dummy.mov
/files/sample.mov

embed tag (in /files/media/quicktime.html) has the parameters:

src="../dummy.mov" (0 byte file)
qtsrc="../sample.mov"
qtsrcdontusebrowser="true"

After requesting http://my-site.com/files/media/quicktime.html, server log 
reveals:

1.2.3.4 - - [20/Aug/2010:16:49:57 -0500] "GET /files/media/quicktime.html 
HTTP/1.1" 200 1003 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) 
Gecko/20100723 Ubuntu/10.04 (lucid) Firefox/3.6.8"
1.2.3.4 - - [20/Aug/2010:16:49:57 -0500] "GET /files/dummy.mov HTTP/1.1" 200 
287 "-" "QuickTime/7.6.4"
1.2.3.4 - - [20/Aug/2010:16:49:58 -0500] "GET /sample.mov HTTP/1.1" 404 1249 
"-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100723 
Ubuntu/10.04 (lucid) Firefox/3.6.8"
1.2.3.4 - - [20/Aug/2010:16:50:01 -0500] "GET /favicon.ico HTTP/1.1" 200 1438 
"-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100723 
Ubuntu/10.04 (lucid) Firefox/3.6.8"

-> in both scenarios, GET requests for sample.mov are using the wrong path
as I said, due to lines 171-179.

Those three main issues were not difficult to fix, and patch attached :)

However, one remaining bug drove me nuts, and I'm not sure where it could be 
fixed or how (I suspect in plugin_dbus). When qtsrcdontusebrowser is set, and 
we're using a relative path for qtsrc, say qtsrc="sample.mov", the streaming 
(open_location) never happens; no request is made at all. Uncommenting some 
debug printf's in plugin_dbus reveals one notable difference in behavior 
between open_location and NPN_GetURLNotify. The latter properly translates the 
relative path of src="dummy.mov" to the full URL (relative to the embedding 
page), but the former (open_location) never does that, so always trying to open 
connection to "sample.mov" (from qtsrc). The only way the stream will happen is 
if one sets the full URL (http://my-site.com/files/media/sample.mov) in the 
qtsrc parameter. Can this be fixed?

Original comment by jasmine....@yahoo.com on 21 Aug 2010 at 12:45

Attachments:

• qtsrc.patch

[GoogleCodeExporter]

Can you try SVN r395, I reworked your patch a little and it should do what you 
want and use the existing techniques where possible. 

Original comment by kdeko...@gmail.com on 21 Aug 2010 at 1:02

[GoogleCodeExporter]

Good job, that does work, and also fixes the relative/absolute paths issue. 
Thank you :)

Can we invert the checks at 312-314 (and consequently the booleans at 315 & 
317), like lines 285-287 (to account for an empty qtsrcdontusebrowser as in 
apple's example - which is widely used) ?

Would also be nice if you could change all those scattered strstr's to 
g_ascii_strcasecmp for consistency (and coverage), just like lines 202, 
265-267, 275-277, 285-287, 299-301, 332, etc..

Original comment by jasmine....@yahoo.com on 21 Aug 2010 at 2:56

[GoogleCodeExporter]

I didn't invert the logic, but I set it to match on "" or blank I believe. Let 
me know if this is insufficient.

I also made the changes to the strstr, I don't think I messed up the logic 
here, still not real awake this morning.

Original comment by kdeko...@gmail.com on 21 Aug 2010 at 3:13

• Changed state: Fixed

[GoogleCodeExporter]

sadly, "" doesn't work when you have:
<embed src=dummy.mov qtsrc=clip.mov ... qtsrcdontusebrowser>
because there's no value set at all, i.e. it's NULL, not an empty string.

Original comment by jasmine....@yahoo.com on 21 Aug 2010 at 4:06

[GoogleCodeExporter]

r400 should fix that

Original comment by kdeko...@gmail.com on 21 Aug 2010 at 4:28

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Ok, now back to the streaming issue with open_location (not getting full URL) 
again, ugh :(

NPP_New called
gecko mediaplayer v0.9.9.2
Using player backend of '(null)'
DBUS connection created
Listening to path /control/53689
Set preference general.useragent.override to QuickTime/7.6.4, old value was ''
ARG: src = dummy.mov
ARG: qtsrc = sample.mov
ARG: type = video/quicktime
ARG: autoplay = true
ARG: controller = false
ARG: kioskmode = true
ARG: qtsrcdontusebrowser = 
ARG: height = 64
ARG: width = 64
Window resized
Calling GetURLNotify with item = 0xadff1000 src = dummy.mov
Window resized
New Stream Requested - http://my-site.com/files/media/dummy.mov
Entering destroy stream reason = 0 for http://my-site.com/files/media/dummy.mov
URL Notify url = 'dummy.mov'
reason = 0
dummy.mov

/control/53689
Sending Open sample.mov to connection 0xb19478f0
item->hrefid = 0 item->src = sample.mov
New Stream Requested - http://my-site.com/files/media/dummy.mov
item is NULL for http://my-site.com/files/media/dummy.mov
Entering destroy stream reason = 0 for http://my-site.com/files/media/dummy.mov
Leaving destroy stream - item not found

Original comment by jasmine....@yahoo.com on 21 Aug 2010 at 6:11

[GoogleCodeExporter]

Gonna take some work to fix this...

Basically for locations that begin with / we need to add the hostname to the 
beginning of the location. For locations that don't we need to add the location 
of the requesting page minus the page, which I'm not sure if we have that or 
not at the time. Been awhile since I have looked at this code.

Also, "src" is automatically requested by firefox, that page will always get 
requested, so that is why is getting it and then going immediately to destroy 
stream for that file.

Original comment by kdeko...@gmail.com on 22 Aug 2010 at 1:21

• Changed state: Started

[GoogleCodeExporter]

SVN r401 should fix that problem. Real minor change in that the code was 
requesting the first item on the playlist, even if it was not marked as 
playable.

Original comment by kdeko...@gmail.com on 22 Aug 2010 at 1:50

[GoogleCodeExporter]

I think r401 breaks the nocache option now.. I need to do some more testing. I 
just wanted to get it requesting the file first.

Original comment by kdeko...@gmail.com on 22 Aug 2010 at 2:27

[GoogleCodeExporter]

aha... that was driving me nuts too, I even had previously tried glist_remove 
to take it out of the playlist, lol..

Your approach is definitely much cleaner

As to breaking nocache, I think a proper fix would be to change the two 
newly-added lines 560-561 (plugin.cpp) to:

if (!item->play && !item->streaming)
  item = list_find_next_playable(playlist);

Original comment by jasmine....@yahoo.com on 22 Aug 2010 at 2:41

[GoogleCodeExporter]

I believe that if check is incorrect.. if we don't want to play it, they we 
dont care if it is streaming or not. I still think something is not quite right 
there.

Original comment by kdeko...@gmail.com on 22 Aug 2010 at 4:52

[GoogleCodeExporter]

Try SVN r402, I think this should do it. I tested with the following embed tag 
and everything seems to look correct...

<embed src="../dummy.mov" qtsrc="../sample.mov" qtsrcdontusebrowser 
mimetype="video/quicktime" autoplay="true" controller="true" height=128 
width=128 />

Original comment by kdeko...@gmail.com on 22 Aug 2010 at 5:39

[GoogleCodeExporter]

brilliant. works like a charm :)

Original comment by jasmine....@yahoo.com on 22 Aug 2010 at 7:11

[GoogleCodeExporter]

Original comment by kdeko...@gmail.com on 22 Aug 2010 at 7:45

• Changed state: Fixed

[GoogleCodeExporter]

I apologize for an error I made in one of my posts.

http://developer.apple.com/safari/library/documentation/QuickTime/Conceptual/QTS
cripting_HTML/QTScripting_HTML_Document/ScriptingHTML.html

"Important: If QTSRC is set to a relative URL, it must be relative to the movie 
specified in the SRC parameter, not the web page in which it is embedded."

So to clarify: iff QTSRC is a relative path, then it is relative to the 
location of the movie in SRC. However, if QTSRC is an absolute path, then it is 
relative to the web page loading the plugin.

Original comment by jasminea...@gmail.com on 8 Sep 2010 at 10:48

[GoogleCodeExporter]

I have to admit that is an odd requirement, it seems to break the consistency 
with how URIs are specified. 

Original comment by kdeko...@gmail.com on 8 Sep 2010 at 12:40

[GoogleCodeExporter]

Indeed. And I can happily ignore it, knowing that most content developers will 
rarely ever use it like this, as the most popular use of QTSRC will most likely 
be for absolute rtsp:// URL's, even per Apple's documentation link above.

And even if QTSRC is ever specified as relative path, it will be even rarer to 
see SRC also as relative path other than something like SRC="dummy.mov", in 
which case QTSRC will still work if relative to the page embedding it.

The only case where QTSRC relative path will not work (per the standard) in 
gecko-mediaplayer is if SRC is set to a relative path like SRC="../dummy.mov" 
or SRC="subdir/dummy.mov".

Just thought it's worth mentioning.

Original comment by jasminea...@gmail.com on 9 Sep 2010 at 6:08