Re: [xine-devel] still frame detection

[Miguel F. <mi...@ce...>]

Harm van der Heijden wrote:

> Hi Miguel,
> 
> I haven't tried this patch yet, but can you perhaps give your thoughts
> about how dxr3 should handle it? 
> 
> Here's what happens now; the dxr3 decoder also announces as it's
> capability that it can handle BUF_VIDEO_FILL as well as MPEG.
> 
> In decode_data, the dxr3 decoder checks if type is BUF_VIDEO_FILL, in which
> case it just does img=get_frame, img->draw(img), img->free(img) and nothing
> else; if you don't sent the dxr3 any data it'll just keep displaying the last
> frame. (It might cause trouble if you're sending an ac3 stream to the dxr3
> audio device as well, but that's probably broken at the moment anyway.) 
> 
> Note that we don't have any frames to copy; we send the mpeg stream to
> the decoder and then it's gone.

Hi Harm,

Does dxr3 handles playing with overlays over static images? If so, them 
we shouldn't have any problems.

I guess dxr3 doesn't send anything to the video_out loop, then the still 
image detection would never be called. Probably it should be better to 
generate a different buf type (i used BUF_VIDEO_FILL to force the 
decoder flush) to avoid confusion.

regards,

Miguel

PS: the still frame isn't finished, although i would love if people 
could give it a try.... :)