[linux-dvb] Re: Generating progressive video

[Michael Plagge <plagge@onlinehome.de>]

On Tue, 2004-02-17 at 21:23, Michael Hunold wrote:
> On 02/17/04 21:05, Michael Plagge wrote:
> > On Tue, 2004-02-17 at 20:53, Michael Hunold wrote:
> >>On 02/17/04 15:33, Michael Plagge wrote:
> >>>On Tue, 2004-02-17 at 14:35, Michael Hunold wrote:
> >>>>On 02/16/04 23:38, Michael Plagge wrote:
> 
> >>>>Anyway, what solution (ie. which gfx adapter) do you have in mind to put 
> >>>>the result to your beamer via DVI?
> >>
> >>
> >>Have you checked if the DVI output is actually supported?
> >>
> > Yes, it works perfectly. I was able to use mplayer and fbtv and tvtime
> > with DirectFB and/or framebuffer. I also can use a X-Server with this
> > card. 
> 
> Good to hear. Does your setup work with a vertical refresh rate of 50Hz?
> 
Yes. I use the following fb.modes setting for my monitor resp. my 15:9
LCD-TV:

mode "1280x1024 50Hz 32bit"
    geometry 1280 1024 1280 1024 32
    timings 10707 248 16 144 38 1 3
endmode

mode "1280x768 50Hz 32bit"
    geometry 1280 768 1280 768 32
    timings 11415 248 16 144 30 1 3
endmode



> > To subsume this discussion, i have to do everything in software (with
> > non CLE266 hardware) to get a 'high quality' solution. 
> 
> I think yes. But even on a low-end CPU (VIA C3 1Ghz, Athlon 800Mhz) you 
> only need about of the 50% CPU power for pure audio + video decoding.
> 
> > I will think  a
> > little bit more about my last point (using movement vectors). Could be a
> > good starting point for working with mpeg2.
> 
> You would have to break up the decoding functions of libavcodec to get 
> the required informations, unless you don't want to parse the whole mpeg 
> stream twice. I don't say it's impossible, but you have a long way to 
> go. 8-) You could write a standalone tool that simply takes a video pes 
> stream, decodes and displays it -- without all the audio stuff and a/v 
> sync code. This should let you concentrate on the important things.
> 
> > Do you think it would be
> > interesting to add deinterlacing support to your softmpeg library, and
> > is it possible to support your work on the library.
> 
> Sure. Currently, "deinterlacing" on the "local" side (ie. not on the tv 
> out) is done in the sense of "stretching every field to the full frame 
> size and blitting every 20ms".
> 
> I admit that this is currently more or less hardcoded for Matrox and 
> cle266 and might not work for other adapters. (which aren't support by 
> DirectFB anyway *sigh*)
> 

Does this mean, you stretch one field (288 lines) to a full frame
without weaving two consecutive fields together for one frame. Wouldn't
it be easy to do at least some kind of weaving, which is perfect for
film mode material.

> We currently use triple buffering for video display and we don't buffer 
> decoded frames. It depends on the deinterlacing algorithm if you need to 
> access "older" frames, so you might need to implement decoded frame 
> buffering. The current logic does "just in time" decoding, then 
> memcpy()s the frame to the destination surface, then Flip()s it. This is 
> efficient and work very well to achieve good av sync.
> 
> On the cle266, the tv-out is programmed to output interlaced. I can n 
> confirm that it can output progressive, too, but we don't have means to 
> implement and test this currently.
> 
> As you can see, "libsoftmpeg" is performing quite well, but is 
> work-in-progress.

so i will have a look into it, to start to implement the things i would
like to see and perhaps if they are good enough they will make their way
back to the library.

Thanks
michael plagge



-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.