Sorry for cross-posting, but I think this might be interesting to DirectFB folks too (maybe even more than just for vdr-softdevice).
Malcolm Caldwell wrote: > Hello, > > I think I might be about display my lack of understanding... > > I have been thinking about the problems surrounding the croping under > matrox tv out using directfb. The current code produces weird field > based artifacts when you crop so a 16:9 image gets displayed letterboxed > on a 4:3 television. > >>From what I understand, The problem occurs because stretchblit is not > field aware, so in various bands there are sections where the fields are > correctly displayed and other where they are not. > > Now, I maybe off the planet here, but, maybe there is a workaround. Can > we pretend that the image is just twice as wide as it really is? > > Say our image is 720x576 > > Line > 1 1111111111111111111111 > 2 2222222222222222222222 > 3 3333333333333333333333 > 4 4444444444444444444444 > 5 5555555555555555555555 > 6 6666666666666666666666 > 7 7777777777777777777777 > 8 8888888888888888888888 > 9 9999999999999999999999 > 10 0000000000000000000000 > ... > 575 YYYYYYYYYYYYYYYYYYYYYY > 566 ZZZZZZZZZZZZZZZZZZZZZZ > > If we use the same image data, but lets just say our image is 1440x288. > > Line > 1 11111111111111111111112222222222222222222222 > 2 33333333333333333333334444444444444444444444 > 3 55555555555555555555556666666666666666666666 > 4 77777777777777777777778888888888888888888888 > 5 99999999999999999999990000000000000000000000 > ... > 288 YYYYYYYYYYYYYYYYYYYYYYZZZZZZZZZZZZZZZZZZZZZZ > > Now since we only crop in the vertical dimension we can crop this image > down to 1140xY, (is this value 288*(3/4)=216?) > > 1 11111111111111111111112222222222222222222222 > 2 33333333333333333333334444444444444444444444 > 3 55555555555555555555556666666666666666666666 > 4 99999999999999999999990000000000000000000000 > ... > 216 YYYYYYYYYYYYYYYYYYYYYYZZZZZZZZZZZZZZZZZZZZZZ > > And then re-cast it to its original horizontal size making 720x432. > (Again, this is if my calculation for the vertical scale factor is > correct). > > 1 1111111111111111111111 > 2 2222222222222222222222 > 3 3333333333333333333333 > 4 4444444444444444444444 > 5 5555555555555555555555 > 6 6666666666666666666666 > 7 9999999999999999999999 > 8 0000000000000000000000 > ... > 431 YYYYYYYYYYYYYYYYYYYYYY > 432 ZZZZZZZZZZZZZZZZZZZZZZ > > So, we can still use stretchblit, our fields are still in the currect > place and our image is now scaled. Or Have I missed something > fundamental. I *think* this will work with the image formats in > question. > > Or am I completely wrong? I don't know for sure if you're wrong, but that's an interesting idea, the devs should maybe think about it. I too have the same problems on *some* 720x576 content which has to be displayed letterboxed 16:9, whith any of the following DirectFB software decoders/players on my Matrox G400 TV-out: vdr/softdevice, df_xine, mplayer.... Any thoughts? _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
