Hello all, before taking part of this discussion, please make sure to have read the v4 wiki page: http://www.linuxtv.org/wiki/index.php/Linux_DVB_API_Version_4 In particular, please read the most recent Linux DVB API v4 documentation: http://linuxtv.org/downloads/linux-dvb-api-v4/linux-dvb-api-v4-0-3.pdf Please pay attention especially to chapter 1 "Introduction" and to the development history. Thank you! on 15.09.2007 18:03 Manu Abraham said the following: > We have an old V4 API that was supposed to be taking over the V3 API. The v4 API documentation states that v3 is a subset of v4, so it's possible to port drivers and applications. But this is not likely to happen and does not make sense (see below). In short: for x86 PCs with the usual mix of USB and PCI devices, v4 is not going to replace v3. > But V4 is considered almost dead due to lack of modern hardware support > such as SOC's for STB's. The v4 API is targetted at System-On-a-Chip (SOC) devices, where a CPU, data (transport stream) input, demultiplexing, audio and video decoding (with or without post-processing) and output capabilities are on the same device. The data flow is either handled in hardware of firmware. Usally this means that during normal decoding operation the main CPU is idle. The v4 API is mainly concerned about data flow through that *one* device, ie. from the data input, through the demuxer, through decoders and then to the output. The typical x86 PC with multiple DVB cards (either PCI or USB) does *not* fit into the scheme. Most of these setups don't have dedicated audio and video decoders (the work is done by the x86 CPU) and the data flow is not freely configurable. Even if you have a TTPCI card, this does not fit into the scheme. If you have one TTPCI DVB-S card and one USB DVB-T receiver, then you cannot route the DVB-T data stream to the TTPCI card internally. The data must be forwarded by the x86 CPU through userspace. Although an kernel API to handle this would be possible, the v4 API is *not* concernced about this. > While being on the V3 frontend API overhaul, i found to much dismay that > it would be much better to revamp V4 into a newer API version such as > V5, rather than scratching with V3 for ages together, resulting in just > unnecessary talks and discussions. The main problem why v4 did not get much attention is because most developers and users must not be concerned about it at all (see above). If you work on x86 hardware, then v3 just works, even if it has certain design flaws. v4 is most interesting for companies that produce digital TV SoCs. And there is just a handful of these companies and some of them are not intersted in open source. So the feedback on v4 was very low most of the time. > What i find interesting with the V4 API > * A better demuxer > * ARIB extensions > With both aspects taken into consideration, i am of the thought that we > should go ahead with taking the best of what we have as a new > experimental API altogether. Let's see. From the past I have learned a few things about certain devices that would not fit into v4 nicely. Let's wait for the discussion to start up, I'll try to collect some of the main concerns I have about v4. > I had talked with Michael and Ralph on this aspect, they were quite > happy to proceed in that direction. It would be nice to have your views > on this aspect of going ahead with the new API. It would be nice if v4 does not bit-rot completely. I cannot take part as an active developer any more, but I will help anybody to understand v4 better and help to take over development. Most critical for v4 is the data flow handling and making a good API to circumvent any stupid hardware limitations. But let's wait for some feedback from other people first. Best regards Michael Hunold. _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
