[vlc-devel] [PATCH] access: add rfb/vnc viewonly module.
remi at remlab.net
Sun Feb 24 22:41:36 CET 2013
Le dimanche 24 février 2013 21:38:30, Francois Cartegnie a écrit :
> Le 21/02/2013 19:32, Rémi Denis-Courmont a écrit :
> >> The fake+8bpp remoteosd filter trick being not sufficient and
> accessible to
> >> average user.
> > Yes. Please remove it in a separate patch.
> Can't: Not intended for the same use.
I don't see the implication.
> >> +#define DEMUX_TAG (void *)0x1
> > This is wrong and will cause a warning on 64-bits platforms.
> Wants a (void *) tag.
> "makes pointer from integer without a cast"
Then WTF did you submit the patch? After several years, you should know better
than to submit evidently broken patches.
> >> +
> >> + float f_fps;
> >> + int i_frame_interval;
> >> + mtime_t i_starttime;
> > This is not needed. Worse, it will prevent synchronizing with live
> > slave inputs.
> Still needed for computing DEMUX_GET_TIME.
I don't see that.
> >> + return var_InheritString( p_demux, CFG_PREFIX "password"
> > Looks leaky.
> Managed by libvnc.
> > For the umpteenth time. Please don't do arbitrary wakeups.
> > If you need to sleep in an access_demux, use your own thread (e.g. V4L2).
> I assume then that demux_t->pf_demux() isn't called its own separate
pf_demux is called in the input thread. Seriously, you could read the code,
and use gdb if in doubt. You are not a newbie anymore.
> >> + p_sys->p_client->MallocFrameBuffer = mallocFrameBufferHandler;
> > Most probably the whole point of this callback is to avoid raw picture
> > copying. Please avoid memory copying then.
> Problem is the framebuffer is built incrementally.
> I've change the way it is handled, but ended with a block_Duplicate...
Well, if it's used as a reference frame, at demuxer level, then you are forced
to add one more memory copy.
> Thought also about overriding block pf_release to use a unique or dual
> fb, but it wouldn't be able to synchronize writes and caching would
> provide stalled screen.
More information about the vlc-devel