On 12/30/07 19:56, Reinhard Nissl wrote: > Hi, > > Klaus Schmidinger schrieb: > >>> I think sending the frame several times to the card should be omitted then. >> Tried that, but that doesn't work. Apparently the buffer(s) need to be filled >> up before anything is displayed. Maybe they could be filled with something >> else than repeating the actual frame data, thus avoiding the short flicker? > > Hmm, does it work to switch the mode before sending the data? > >>> Do you think there is the need to distinguish between progressive still >>> images and interlaced ones? >>> >>> It might be reasonable to show a frame picture for progressive images >>> and only the last field picture for interlaced images. >> I'm generating my images as "progressive" (at least that's what I think). >> The command I'm using is >> >> mpeg2enc -f 3 -b 12500 -a 2 -q 1 -n p -I 0 >> >> which gives the best results so far. If I use '-I 1' to have it "interlaced", >> the result looks just the same on the tv screen. > > Sure, but that's not what I've meant. The same function is being used to > show the image for a cutting mark. Such an image would be interlaced. > On my EPIA, vdr-xine would display it as progressive, just as the FF > card would do with the changed driver. Don't know whether this matters. When I jump to an editing mark with the modified driver, the display is just as smooth as when displaying a still image generated from a jpeg file. So the driver modification also improves this area. Klaus _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
