On Mon July 23 2012 14:35:14 Soby Mathew wrote: > Hi Hans, > Thanks for the reply and I was going through the HDMI1.4 spec again. > The 'active space' is part of the Vactive and Vactive is sum of active > video and active space. > > > No, as I understand it active_space is just part of the active video. So the > > timings struct is fine, it's just that the height parameter for e.g. 720p in > > frame pack format is 2*720 + vfrontporch + vsync + vbackporch. That's the height > > of the frame that will have to be DMAed from/to the receiver/transmitter. > > In this case (assuming frame packed) the total height should be 2*720 > + 30 + vfrontporch + vsync + vbackporch. > > Sorry, but if I am understanding you correct, in case of 3D frame > packed format, the height field can be 'active video + active space'. Right. > So the application need to treat the buffers appropriately according > to the 3D format detected. Would this be a good solution? Right. So the application will need to obtain the timings somehow (either from v4l2-dv-timings.h, or from VIDIOC_G/QUERY_DV_TIMINGS) so it knows how to interpret the captured data and how large the buffer size has to be in the first place. I think it will all work out, but you would have to actually implement it to be sure I haven't forgotten anything. Frankly, I'd say that the frame_packed format is something you want to avoid :-) It's pretty weird. Regards, Hans > > > > I think the only thing that needs to be done is that the appropriate timings are > > added to linux/v4l2-dv-timings.h. > > Yes , the standard 3 D timings need to be added to this file which can > be taken up. > > > Regards, > > > > Hans > > > > > Best Regards > Soby Mathew > -- 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
