By Date: <-- -->
By Thread: <-- -->

RFC: V4L2 MPEG Encoding API: Part 1

On Monday 01 May 2006 16:32, Alan Cox wrote:
> On Mon, May 01, 2006 at 12:37:54AM +0200, Hans Verkuil wrote:
> > However, there are NO applications that use this API. Instead, the
>
> The qx5 applications seem to do so minimally

Are you talking about this: 
http://www.linuxtv.org/v4lwiki/index.php/QX5_USB_microscope?

This driver uses MJPEG compression, it is not an MPEG encoder device.

> > Of course, the extended control mechanism allows other similarly
> > complicated APIs to add their own ID ranges in the future. However,
> > for now the API is limited to devices supporting the
> > V4L2_PIX_FMT_MPEG format, that is MPEG-1/2/4 type compression
> > streams.
>
> Gak, why not just pass XML, it's about as contorted and impossible to
> validate.
>
> The kernel API needs to be stable, it needs to be able to push as
> much verification as possible into the top layers to avoid
> duplicating errors.

The core problem with designing an API for MPEG encoders is that each 
chipset has its own idiosyncrasies. There are some core settings that 
are generally supported by each chipset (although for each chipset 
there are always some unsupported settings), and there are settings 
that are chipset specific. Furthermore, new chips implementing new 
compression standards like MPEG-4 will add still more settings in 
either category. Just what they will contain is unknown at this time.

While most settings fit in 32 bits, there are also settings that require 
more than 32 bits of data. In the current proposal these are not yet 
used, but one perfect candidate would be the 'custom data' setting 
where up to 8 u32 values can be passed to the MPEG encoder which 
inserts them either as a private packet or as extension data. This 
could be used to insert the name of the company or person producing the 
MPEG stream for example.

At this moment I am not certain whether this belongs to the core 
functionality of an MPEG encoder device, or whether it is cx23416 
specific. This needs more testing and this is also the reason why it 
isn't in the proposal.

Now, one option is to add another ioctl command. But there are already a 
lot of them in V4L2, and adding one that might be used by only one 
specific device seems a bad idea to me. It would also mean that while 
the other settings are done by controls, this particular property is 
now set using an ioctl. Confusing, I think.

Having it as a control containing a pointer to the data makes it more 
consistent and has the additional advantage that the application can 
test for the existence of this control using the usual control query 
API.

I admit, it would be great if we knew in advance what sort of data might 
need to be set for all possible MPEG encoder devices, now and in the 
future, but alas, we don't. For simpler devices (e.g. frame grabbers) 
you can allow for future expansion by adding a 'u32 reserved[...]' 
field at the end of a structure, but that simply isn't going to work 
for devices like this. These devices simply are too unpredictable with 
regard to their capabilities and number of settings.

I do expect that the number of settings that need a pointer is very low 
indeed. Probably no more than a handful, certainly for the current 
MPEG1/2 encoders. I don't know what we can expect from the MPEG-4 
encoders, though.

If you have better ideas or suggestions, please let me know! That's why 
it's an RFC after all.

Regards,

	Hans

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request (at) redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list