On Mon, Sep 04, 2006 at 09:19:15PM +0100, Alasdair Campbell wrote:
> On 04/09/06, Marko Mäkelä <[EMAIL PROTECTED]> wrote:
> > In our family, vdr+softdevice has been in "production" use since the
> > spring of 2005, mostly for children's programs. Trying out patches at
> > night is not a problem. In fact, I did upgrade to softdevice CVS when
> > I upgraded to vdr 1.4.2.
>
> I find that I have very little chance of getting back to a succesful
> setup, after I've started trying out patches and new versions etc. It
> would be great if I could write a shell script that backed up all the
> vdr system files but I'm a complete novice.
>
> If I had a simple way of getting back to a production setup, then I'd
> be willing to put in lots of time testing.
I haven't seen the OSD artifacts you mentioned in your other message,
but the following combination works for me:
Linux kernel 2.6.16.x
DirectFB 0.9.25 (not CVS)
vdr 1.4.x
ffmpeg CVS from a few months ago
softdevice CVS
The system runs Debian GNU/Linux unstable, but I don't believe that it would
matter. Also, I don't think that the ffmpeg version matters, provided that
it is at most a year old. The Linux kernel might make a difference.
I haven't upgraded to 2.6.17.x yet, because I fear it would introduce some
bugs.
With DirectFB CVS (containing the Matrox patches for interlaced output),
I'd get broken OSD, and any black bars on top and bottom would not be
blanked.
When I scale the output (e.g., add black bars to view 16:9 on 4:3 screen),
I almost never see any interlacing artifacts, like you do. I only noticed
such artifacts a week ago. Maybe the field order is different from the one
assumed by the code?
Marko
_______________________________________________
Softdevice-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/softdevice-devel
