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