Re: V4L2 Advanced Codec questions

[Steven Toth <stoth@linuxtv.org>]

Hans Verkuil wrote:
> On Thursday 26 March 2009 16:59:11 Steven Toth wrote:
>> Hello!
>>
>> I want to open a couple of HVR22xx items up for discussion.
>>
>> The HVR-22xx analog encoder is capable of encoded to all kinds of video
>> and audio codecs in various containers formats.
>>
>>  From memory, wm9, mpeg4, mpeg2, divx, AAC, AC3, Windows audio codecs in
>> asf, ts, ps, avi containers, depending on various firmware license
>> enablements and configuration options. Maybe more, maybe, I'll draw up a
>> complete list when I begin to focus on analog.
>>
>> Any single encoder on the HVR22xx can produce (if licensed) any of the
>> formats above. However, due to a lack of CPU horsepower in the RISC
>> engine, the board is not completely symmetrical when the encoders are
>> running concurrently. This is the main reason why Hauppauge have disabled
>> these features in the windows driver.
>>
>> It's possible for example to get two concurrent MPEG2 PS streams but only
>> if the bitrate is limited to 6Mbps, which we also do in the windows
>> driver.
>>
>> Apart from the fact that we (the LinuxTV community) will need to
>> determine what's possible concurrently, and what isn't, it does raise
>> interesting issues for the V4L2 API.
>>
>> So, how do we expose this advanced codec and hardware encoder limitation
>> information through v4l2 to the applications?
>>
>> Do we, don't we?
> 
> Hi Steve,
> 
> If I understand it correctly, then a single analog source can be encoded to 
> multiple formats at the same time, right?

No.

> 
> Or is it that multiple analog sources can each be encoded to some format? Or 
> a combination of both?

Multiple analog sources can produce multiple formats, CPU power permitting.

> 
> Is there a limit to the number of concurrent encoders (except for CPU 
> horsepower)?

Not that I'm aware of, yet.

> 
> Basically, since you can have multiple encoders, you also need multiple 
> videoX nodes, once for each encoder. And I would expect that an application 
> can just setup each encoder. Whenever you start an encoder the driver might 
> either accept it or return -ENOSPC if there aren't enough resources.

This is fine, and expected.

> 
> You have to document the restrictions in a document, but otherwise I don't 
> see any reason why implementing this would cause any problems.
> 
> Adding new containers and codecs is easy: just add the missing ones to enum 
> v4l2_mpeg_stream_type, v4l2_mpeg_audio_encoding and 
> v4l2_mpeg_video_encoding and add any additional controls that are needed to 
> implement each codec/container.

Ahh, this is the magic information I was looking for.

> 
> In theory you can reduce the number of possible containers/codecs/bitrates 
> in the controls according to the remaining resources. But I think that will 
> be too complicated to do for too little gain, not only in the driver but 
> also in the application.

I think this is going to be the major issue and it will start to reflect itself 
through the API into the application. We'll see, maybe not.

Thanks,

Steve