Page 1 of 1

VLC plugin and frames _Javascript pb solved!

Posted: 31 Mar 2009 02:38
by iwata
I have a very basic test page here : http://nozilla.free.fr/gabuzomeu.htm

I get nice results with the revolunet plugin (except for the timeline using .avi video via a web server) ,but
I am stupidly ( shame on me) stuck, unable to achieve a very simple 'target' scenario using two frames :oops:

I wish a click on (any) red camera icon in frame2 will launch a video via the plugin in Frame1 ; a basic correct 'target'
code line that matches onclick="vlc_controls.play , to do this simple thing...

http://img14.imageshack.us/my.php?image ... d01fpm.jpg

I am finally so puzzled that I am now even not sure whether the script code should be in Frame2 with the icon + the onclick event (thus Frame1 a sole 'target' passive container) or if the script shoudl be in ('display') Frame1 , in association with an appropriate code line on the (icon) link in Frame2 ! help most welcome then ... :roll:

Re: VLC plugin in a frames scenario (need help)

Posted: 31 Mar 2009 10:10
by revolunet
browse google with something like "javascript cross frame"

from frame2 :

Code: Select all

top.frame1.vlccontroller.play(uri);
would do the trick

Re: VLC plugin in a frames scenario (need help)

Posted: 31 Mar 2009 10:10
by revolunet
NB : both frames have to use the same domain/subdomain to prevent bowsers security restricitons

Re: VLC plugin in a frames scenario (need help)

Posted: 31 Mar 2009 19:44
by iwata
Thnx your answer; unfortunately I did not find anything that adresses this very point of js in cross-frame context :cry:

so , while disapointed about this "extra" VLC problem , may I ask now the revolunet dev about some points
concerning the Plugin ?

that is , first, why is the timeline not working with an .avi file served from a web http server (indeed the same
applies with the Player as well) ? the .avi container is definitely not well suited at all for providing 'true streaming' features such as seek, correct timeline position, etc... but it happens that the Mplayer can parse/seek (even quite fast !) and provides with a working timeline , in the very same conditions (http server) ; unfortunately ffmpeg is more buggy , under net fluctuations (image freeze with infinite audio looping ,..)

still maybe VLC could fix the missing timeline , no cursor, and absence of timecode issues...

another mindpuzzling point is that on (my) rather heavily compressed videos ala YouTube ( mine are mpeg4 SP @200kbits as for video track) I often have the visual feeling that overall Mplayer (ffpmeg) provides with a cleaner decode / smoother PP (post filtering)

while it is hard to make a statement as for the respective decode engine(s) aspects , still I notice that the VLC Plugin calls for the ffmpeg PP via ExternalLibLoader.js ( vlc_controls.options.set("ffmpeg-pp-q", 6); ) , then as such we should expect same efficiency of PP , same visual experience overall from VLC plugin ; and it is not the case , observing that Mplayer can/does provide with a 'smoother' ( artefacts better/smoother filtered ) visual experience with such heavily compressed videos ; while not a repetitive rule it seems to be quite visible sometimes , at least in 'my view'

indeed time is towards HD, high bit rate , etc... still there is obvious interest for YouTube like 'average' quality videos ( 320*240 @250kbps or lower)

my 2 cts , on these points (since otherwise VLC is overall a better option to Mplayer 8) ; imho )

------
oops, while previewing , I notice it is looong ! sorry :-|

Re: VLC plugin in a frames scenario (need help)

Posted: 31 Mar 2009 19:54
by revolunet
hi !

i think you can tweak the js for the crossframe problem. anyway you should better use ajax instead of iframes ;) (jquery rocks at this)

for the http/avi seek problem, the problem is internal to vlc, known, and is not yet resolved. maybe in 1.0 i cant say beacause this is very low level problems.

about the display quality, you can add video filters in the plugins, like deinterlace=blur for example. try first in VLC gui to find the best setting for you.

my 2 cts :)

Re: VLC plugin in a frames scenario (need help)

Posted: 31 Mar 2009 21:51
by iwata
Thnx your interest and help in my js problems ; I think my difficulty will be to find someone even only interested
at reading a ..frame problem in 2009 , even if he is 100% knowledgeable in Javascript ! :?

as for the .avi problem , yes I know it is on the ToDo list of VLC

it is possible to address the issue without any recompression of media tracks , simply by changing the container (to asf for instance) with ffmpeg ; and then you get back all features ( timeline, timecode, cursor, seek, etc..)

mkv could be another option , but it has some aspects still also on the VLC ToDo list, at least that's what I read :wink:

Re: VLC plugin in a frames scenario (need help)

Posted: 01 Apr 2009 23:38
by iwata
eventually it works :)

<a href="javascript:vlc_controls.play ('http://nozilla.free.fr/trane2.asf')" target="top">video01</a>

Re: VLC plugin in a frames scenario (need help)

Posted: 02 Apr 2009 01:55
by iwata
../..

for the http/avi seek problem, the problem is internal to vlc, known, and is not yet resolved. maybe in 1.0 i cant say beacause this is very low level problems.
it would be great if it is (was) fixed with the coming 1.0, since using of the .asf container is not 100% safe ; it raises some random image quality which I have definitely put in evidence .

while it is only some supposition it just looks like if it would 'miss' some key frames , sometimes ; then the consecutive image sequence is degraded until next key

indeed I am only pointing a problem that comes from using this container in a 'weird' codecs association (for this container) ; otherwise the PlugIn has no pb that I know with an .asf 'conform'' stream (Microsoft codecs inside)

could you see if the seek (in the timeline) feature could be at least 'operational' with the Plugin , like with the player, so we could wait till the all problem is fixed overall in VLC ; that is , as you know, the player does actually provide for seek but with poor image recovery and indeed no timeline_timecode ; still the seek feature is 'working' which is useful for any movie that is a bit long