On Fri, 10 Feb 2012, Sylwester Nawrocki wrote: > On 02/10/2012 09:42 AM, Guennadi Liakhovetski wrote: > > ...thinking about this interleaved data, is there anything else left, that > > the following scheme would be failing to describe: > > > > * The data is sent in repeated blocks (periods) > > The data is sent in irregular chunks of varying size (few hundred of bytes > for example). Right, the data includes headers. How about sensors providing header-parsing callbacks? Thanks Guennadi > > > * Each block can be fully described by a list of format specifiers, each > > containing > > ** data format code > > ** number of alignment bytes > > ** number of data bytes > > Each frame would have its own list of such format specifiers, as the data > chunk sizes vary from frame to frame. Therefore the above is unfortunately > more a frame meta data, rather than a static frame description. > > > Can there actually be anything more complicated than that? > > There is an embedded data at end of frame (could be also at the beginning) > which describes layout of the interleaved data. > > Some data types would have padding bytes. > > Even if we somehow find a way to describe the frame on media bus, using a set > of properties, it would be difficult to pass this information to user space. > A similar description would have to be probably exposed to applications, now > everything is described in user space by a single fourcc.. > > > Regards, > -- > Sylwester Nawrocki > Samsung Poland R&D Center > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
