[vlc-devel] Re: input callback

[Sigmund Augdal Helberg]

On Thu, 2006-01-19 at 15:54 +0100, Vaclav Koldus wrote:
> Sigmund Augdal Helberg napsal(a):
> 
> >On Thu, 2006-01-19 at 13:03 +0100, Vaclav Koldus wrote:
> >  
> >
> >>Sigmund Augdal Helberg napsal(a):
> >>
> >>    
> >>
> >>>On Wed, 2006-01-18 at 16:05 +0100, Antoine Cellerier wrote:
> >>> 
> >>>
> >>>      
> >>>
> >>>>On Wed, Jan 18, 2006, Vaclav Koldus wrote:
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>That's why I would rather add a callback to input. Now this would work 
> >>>>>fine, but
> >>>>>in future I want to use VLM. Is there any possibility??
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>The issue is that you can't really add a callback to input since it is
> >>>>killed and respawned when a new one is needed. (Someone correct me if
> >>>>i'm wrong)
> >>>>
> >>>>And i don't know about any similar callback variable hat the vlm
> >>>>media element might update when changing the input it's using. (That
> >>>>wouldn't be too hard to add i guess)
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>You could probably grab a hold on the input (using vlc_object_find) and
> >>>then query it's b_die at regular intervals. And then trigger a name
> >>>renewal at this time. make sure you call vlc_object_release once b_die
> >>>is set, otherwise you'll get nasty errors. 
> >>>
> >>>After the current input has died there could probably be a while when
> >>>there is no input before a new one is spawned, you should handle this
> >>>case.
> >>>
> >>>Btw, what kind of module are you working on? If it is (as you say) a
> >>>child of the input, then the module will very likely be killed as well
> >>>when the input is.
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>Well, I don't know VLC object strucure well enough to say it is/isn't 
> >>child of the input. I've just tried to find parent and it worked.
> >>In fact I'm writing video filter module. It renders various videotext 
> >>informations on the screen. I wanted it to depend on
> >>the filename (to decide whether show some info.) At this rate I use 
> >>playlist so callback on playlist is OK now.
> >>Anyway video filter isn't killed with input as I've found out.
> >>
> >>In future I want to use VLM to achieve better timing of played files and 
> >>use the mosaic principle to show multiple videos
> >>in one output (PIP etc.) Because there are special requirements on this 
> >>filter I decided not to use VLC built in
> >>features and write my own. I've got my own YUV rendering library using 
> >>freetype to render text and simply
> >>draws images in native YUV. Screen templates are defined in XML files 
> >>and now I'm working on scheduling them
> >>by mysql based queue. I will need to solve another problem here, cause I 
> >>can't simply use the filename for
> >>decisions when there are multiple source files. I haven't thought over 
> >>this yet so there's probably no point in bothering
> >>with VLM sources now.
> >>
> >>Only original VLC filter I took advantage of is blending filter. Here 
> >>I've got a question. I don't understand
> >>the blending filter code a bit so I don't know. Is there any chance to 
> >>improve performance of blending
> >>by rewriting it in sse2 or mmx? I already had some performance issues 
> >>with my filter. I optimized
> >>colorspace conversions (in DV decoding/encoding, another part of my 
> >>project) by sse2 which was
> >>enough for now but what when the requirements raises again?
> >>I think blending is a good candidate for optimalization. Or am I wrong?
> >>    
> >>
> >Me too. I looked partially into this once, but never got around to write
> >any code. basically you need to grab some bytes and convert these into
> >16bit words. Do multiplication and addition and then convert back into
> >bytes.
> >
> >Regards
> >
> >Sigmund
> >  
> >
> SSE2 can do this. But only on some video sizes ( divisible by 4/8/16 
> depending on data type ).
> Seems blending module calls different functions for different formats so 
> I think I could rewrite some of them
> in sse2. I'll think about it more...
First of all video sizes are very often divisible by 4/8/16 because of
macro block sizes in the encoding. Furthermore you could easily do sse2
for the longest possible subline matching the divisible criteria and do
the remaining 3/7/15 pixels the old way. The speed up would still be
good.

Sigmund
> 
> V.
> 
> >>Thanks
> >>
> >>V.
> >>
> >>    
> >>
> >>>Hope this helps (and works).
> >>>
> >>>Sigmund
> >>> 
> >>>
> >>>      
> >>>
> >>>>-- 
> >>>>Antoine Cellerier
> >>>>dionoea
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>> 
> >>>
> >>>      
> >>>
> >
> >  
> >
> 
> -- 
> This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
> To unsubscribe, please read http://developers.videolan.org/lists.html
> 

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html