Dear Guennadi
> I've got a question to you, regarding your interlaced support
> implementation for the CEU: do I understand it right, that the kind of
> support you actually have implemented is, that if an interlaced format is
> now requested from the CEU, it will interpret incoming data as interlaced
> and deinterlace it internally?
It is correct excluding "interlaced format is now requested from the CEU".
Now, the device which request interlace format is video device.
If you use Ecovec, it is tw9910.
> If this is really the case, then, I think,
> it is a wrong way to implement this functionality. If a user requests
> interlaced data, it means, (s)he wants it interlaced in memory. Whereas
> deinterlacing should happen transparently - if the user requested
> progressive data and your source provides interlaced, you can decide to
> deinterlace it internally. Or am I misunderstanding your implementation?
Hmm...
Now only "CEU + tw9910" pair use interlace mode in CEU.
But it doesn't support interlace mode from "user space".
(I don't know how to request it from user space)
Now interlace mode is used internally.
This mean, it seems as "progressive mode" from user space.
> Regardless of theoretical correctness - does your patch still work? Have
> you been able back then to get CEU to deinterlace data, and when have you
> last tested it?
I tested CEU interlace mode by using Ecovec board.
I can watch correct video image on at least v2.6.34.
I used this command.
VIDIX="-vo fbdev:vidix:sh_veu"
SIZE="-tv width=1280:height=720"
NTSC="-tv norm=NTSC"
OUT="tv:// -tv outfmt=nv12"
DEVICE="-tv device=/dev/video0"
mplayer ${VIDIX} ${SIZE} ${NTSC} ${OUT} ${DEVICE}
Best regards
--
Kuninori Morimoto
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
