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?
Or is it that multiple analog sources can each be encoded to some format? Or
a combination of both?
Is there a limit to the number of concurrent encoders (except for CPU
horsepower)?
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.
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.
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.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
