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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
