CVS Commit: vlc

[Jon Lech Johansen]

On Mon, Feb 18, 2002 at 05:51:29PM +0100, Florian G. Pflug (fgp at phlo.org) wrote:
> On Mon, Feb 18, 2002 at 02:34:44AM +0100, cvs at videolan.org wrote:
> Hi
> 
> To whoever did this great patch.

That would be me :-)
 
> Wow. Great work. Nice to see someone taking my code, and improving it.

Thanks.

> But I have some questions/suggestions.
> 
> When I create the vlc_wrapper class, I wanted to seperate the interface from
> the inner structure of vlc. My goal was not to have any vlc-specific header
> included in intf_controller, but to just use functions provided by the
> wrapper.
> 
> In the same way, vout_macosx.h was ment should be seperated from the
> interface. It should only request a qdport, rescale the output when
> necessary, and release the qdport when it isn't needed anymore.

The old vout _requested_ the creation of a qdport and _requested_ the
release of the qdport. The new vout _creates_ a qdport and _releases_
the qdport. The problem with the old vout was that it requested the
release of the qdport in vout_End, and by the time [vlc manage] was
called and managed to lock the vout bank, the vout had been released.
The new vout does not have this problem, and is also much cleaner. 

> So I suggest some improvements.
> 
> I never really liked it that the interface part writes the qdport it created
> directly into p_vout->p_sys. If I understand your code correctly, you don't
> pass messages (asyncronous) bewteen the vout and the interface thread - you use
> (syncronous) calls (altough those syncronous calls are implemented in terms
> of message passing).

NSPortMessage is async, but CoSendRequest is sync. 

> So the interface thread could return the qdport it created instead of
> writing into the vout thread's structure.
> 
> The idea behind this is that I believe it would be quite easy to extend vlc
> to output not only on the main stream, but e.g. the firewire-port, or even a
> file (file is more difficult I guess since there is no qdport involved).

So you want to be able to send NSPortMessages to the main thread from
non-vout plugins?

> My second suggestions is much simples. I believe it would be more elegant if
> the VlcWindow wouldn't write the VLC_FULLSCREEN_CHANGE/VOUT_SIZE_CHANGE
> message to p_vout->i_changes, but call some function in vlc_wrapper for
> this.

I agree, but disagree about using Intf_VlcWrapper. A new interface,
Vout_VlcWrapper, is needed. Like you mentioned yourself, the vout should
be seperated as much as possible from the interface. This was not the
case with the old vout, which only supported one vout at a time, thus
preventing the wall filter from working. 

-- 
Jon Johansen
nanocrew.net

MR. LEVY:  I'm sorry, your Honor. I actually have a technology expert
  with me. Would the Court like to or would they agree to hear a very
  brief statement on this point from that expert?
THE COURT: No.  -- DVD CCA v. Reimerdes injunction hearing, 1/20/2000

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://www.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>