win mozilla plugin 0.9.2 - can't play http://* movies while QT GUI can
The mozilla plugin tries to play http://* movies with access_mms instead of access_http and fails to open the movie. It can play ftp:// and file:// movies at least.
It finds only one candidate for http (appears to be the access_mms one) when QT GUI find two (appears to be access_http before access_mms).
This bug is present on those plateforms at least: windows XP + FF2 ; windows vista + FF3
This bug does not appear with nightly 2008-09-12 (vlc1.0.0) and appear in official vlc 0.9.2 (from commit c3f827, 2008-09-13@23:54)
Activity
Mozilla plugin tries to open HTTP streams with access_mms : no video
Added attachment:
when removing access_mms plugin DLL, mozplugin find no candidate for http
Added attachment:
QT GUI find one more candidates for HTTP, appears to be the good access_http before the access_mms : video ok
Added attachment:
The easiest way to check is link1 (which should show direclty a video)
A more developer-focused way is to get debugs. You can use link2, close the bottom panel, replace bottom-left URL by a valid HTTP url (http://code.revolunet.com/VLCjs/rambo.mpg in some of my tests), clear bottom-right input box and click "play" button. (press F5 to be able to click play another time)
links:
1- http://code.revolunet.com/VLCobject/example2.html
2- http://athebird.free.fr/utest_vlc_js/unit_test_vlc-mozzplugin.html
To sum up :
-
latest good commit found is commit 0731fa5879c3e9ec51837668e8ccf4a5a132b417
Author: Antoine Cellerier dionoea@videolan.org Date: Wed Sep 10 02:35:12 2008 +0200 -
older commit found with the bug is commit c3f827a255cea0b4fe0190c14ef1f9289b4886db Author: Jean-Baptiste Kempf jb@videolan.org Date: Sat Sep 13 23:54:06 2008 -0700
-
Workaround
Copy third-party DLLs from VLC install dir to a folder in PATH (windows or system32 for example). I have copied those ones to C:\windows for my own:
* avcodec-51.dll * libfontconfig-1.dll * libfreetype-6.dll * libgcrypt.dll * libgpg-error-0.dll * libiconv-2.dll * libxml2-2.dll * libz-1-2.dlllinks:
* http://forum.golem.de/read.php?27792,1455317,1457456#msg-1457456 (thanks to someone which give it on IRC, Bond387?) * http://forum.videolan.org/viewtopic.php?f=14&t=50248added Difficulty::easy label
Maybe the workaround is not so simple. It works for me but seems not for Bond852. For me, adding VLC install dir to %PATH% works also. Does those workarounds work with you?
If yes, which patch is prefered? I think adding VLC install dir to PATH is more interesting than moving files outside VLC install dir but I guess another cleaner fix exists.
Replying to [comment:7 thannoy]:
Maybe the workaround is not so simple. It works for me but seems not for Bond852. For me, adding VLC install dir to %PATH% works also. Does those workarounds work with you?
If yes, which patch is prefered? I think adding VLC install dir to PATH is more interesting than moving files outside VLC install dir but I guess another cleaner fix exists.
I can confirm the "path" workaround is fine. If your browser have direct connection to the Internet it solves the access problems. If you are using the 0.9.2 mozilla plugin from behind a proxy, then probably there is a different bug preventing accessing files (see https://trac.videolan.org/vlc/ticket/2120)
assigned to @geal
Geal is working on this bug using a third method: manifest files (to inform about mozilla-plugin dll dependancies).
This bug envolve Opera9.52 for Windows too (which use mozilla-plugin), hope the fix will fix both. PATH workaround fixed both on my test. If needed, I can give example on how to modify NSI for the PATH workaround.
added Status::fixed label
mentioned in issue #2115 (closed)
