On 12/30/07 19:56, Reinhard Nissl wrote:
> 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.
vdr mailing list