[vlc-devel] vlc plugin and attachment:// URIs

[Rafal Chlodnicki]

On Mon, 20 Jul 2009 16:29:15 -0400, Rémi <Denis-Courmont" <remi at
remlab.net>> wrote:
>
>> Le lundi 20 juillet 2009 23:21:29 Michael A. Puls II, vous avez écrit :
>>> O.K. In this case, one just makes sure that they don't specify @data  
>>> and
>>> just stick to specifying an mrl param.
>>
>> I don't understand what you mean.
>
> I'm saying as long as one sticks to:
>
> <object type="application/x-vlc-plugin">
> <param name="mrl" value="uri">
> <param name="version" value="VideoLAN.VLCPlugin.2">
> </object>
>
> and doesn't use:
>
> <object type="application/x-vlc-plugin" data="uri">
> <param name="mrl" value="uri">
> <param name="version" value="VideoLAN.VLCPlugin.2">
> </object>
>
> or
>
> <object type="application/x-vlc-plugin" data="uri">
> <param name="version" value="VideoLAN.VLCPlugin.2">
> </object>
>
> , then there will be no browser stream to worry about.
>
> So, even though the standard way of loading a plug-in is to use @data,  
> in the vlc plugin's case, you just don't and you won't have any problem.
>
>>> However, with the attachment:// situation in Opera, do you think the
>>> browser's streaming would be flexible enough there (since the data
>>> wouldn't be coming over HTTP)? Or, do you think it'd be just as  
>>> inflexible?
>>>
>>> If so, what about for now, make it so that if after:
>>>
>>>
>>>   if( psz_target )
>>> {
>>>   // get absolute URL from src
>>> char *psz_absurl = getAbsoluteURL(psz_target);
>>> psz_target = psz_absurl ? psz_absurl : strdup(psz_target);
>>>   }
>>>
>>> psz_target still starts with "attachment:", make the video area say  
>>> "URI
>>> scheme not supported"?
>>>
>>> Would that be acceptable?
>>
>> If it is attachment:// it could be dealt with a patch.
>
> Do you personally know how to have the plug-in request the stream from  
> the browser in this case?
>
>> If it's attachment:/ as you said earlier, it's plain broken.
>
> Why would "attachment://" be any easier than "attachment:/" to tell that  
> you have an attachment URI?
>
> psz_baseURL could be converted from "attachment:/..." to  
> "attachment://..." if possible, I would think.
>
> Thanks

I will break threading with this message. Sorry about that but there is no
other option as I've just subscribed.

IMO, VLC plugin should not try any magic with converting attachment
scheme. In fact, it can't do anything because it won't be able to figure
out that "attachment:/789/file.ogg" should point to something like
file://C:/Opera/profile/cache4/ODF4434, actually.

Instead it should handle the stream that Opera sends. Opera _does_ send it
when opening attachment file.

Not sure if there are any more cases when it happens but Opera (probably
not only Opera) sends the stream when embedding with:
<embed src="URI" ...>
and
<object data="URI" ...></object>

I didn't think about that throughly but plugin logic could be to try to
handle URI by itself and if it fails for whatever reason (VLC can't
recognize URI or returns error on play) then listen to stream that browser
sends and try to handle that.

I've just been hacking VLC plugin a bit a found one bug that prevents this  
stream from working.

When opening ogg attachment in Opera mail:
1. Opera notifies plugin about stream (NPP_NewStream)
2. Plugin sets stream type to NP_ASFILEONLY which means that Opera should  
give URI to file when it completes loading it
3. Plugin gets call from Opera (NPP_StreamAsFile) with fname parameter  
pointed to real URI

VLC plugin should add "fname" parameter to playlist but it instead adds  
stream->url which is wrong this to do as it still points to attachment:/  
uri. See that code in projects/mozilla/vlcshell.cpp, function  
NPP_StreamAsFile.
Here is documentation for NPP_StreamAsFile:  
https://developer.mozilla.org/en/NPP_StreamAsFile

But, after making the fix to add fname instead (which looks like this:  
"c:\OperaBeta\build10.00.1642\profile\cache\opr0006W"), file still does  
not play for me. I'm not yet sure why, maybe plugin doesn't recognize the  
path as it expects it in localhost:// scheme? I'm not yet sure but will  
eventually check that.