Em Wed, 25 Aug 2021 21:46:23 +0530 Manu Abraham <abraham.manu@xxxxxxxxx> escreveu: > > The "full-featured" API that it is implemented on av7110 always had > > troubles. This is not only my view, but also the view of the > > original API authors,as can be seen at the DVBv4 WIP documentation: > > > > https://www.linuxtv.org/downloads/legacy/linux-dvb-api-v4/linux-dvb-api-v4-0-3.pdf > > > > It clearly says that, on chapter 2.2: > > > > "2.2 Linux DVB API Version 3 problems > > > That's very misleading ! In fact, the legacy V3 API was upgraded to 3.1 and 3.2 > and those issues were ironed out. You are talking about V3 while V3.2 > fixed those > issues. No. When Linux version 2.6.12-rc2 started using git, the DVB API version was already 3.1. This was in April, 2005, which is the the same date that rev 0.3 of the DVBv4 spec was released[1]. [1] https://www.linuxtv.org/downloads/legacy/linux-dvb-api-v4/linux-dvb-api-v4-0-3.pdf DVB API version 3.2 was merged in 2007 on this commit: commit 2435be11ae1afb64ac7dfb25e10b6e3037ab0522 Author: Hans Verkuil <hverkuil@xxxxxxxxx> Date: Fri Apr 27 12:31:09 2007 -0300 V4L/DVB (5307): Add support for the cx23415 MPEG decoding features. The cx23415 adds some extra features that this DVB decoding API did not support. This API has been expanded to support the required features. Both source and binary backwards compatibility is kept intact by these changes. So existing applications are not affected. Signed-off-by: Hans Verkuil <hverkuil@xxxxxxxxx> Signed-off-by: Ralph Metzler <rjkm@xxxxxxxxxxxxxx> Signed-off-by: Oliver Endriss <o.endriss@xxxxxx> Signed-off-by: Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> The focus of this change was to add support to better control a MPEG2 decoder on an analog TV hardware (IVTV). That didn't bring any uAPI change for av7110. Between 3.1 and 2435be11ae1a ("V4L/DVB (5307): Add support for the cx23415 MPEG decoding features."), there were a couple of changes: +#define AUDIO_GET_PTS _IOR('o', 19, __u64) +#define VIDEO_GET_PTS _IOR('o', 57, __u64) -#define DMX_GET_EVENT _IOR('o', 46, struct dmx_event) +#define FE_TUNE_MODE_ONESHOT 0x01 +#define FE_SET_FRONTEND_TUNE_MODE _IO('o', 81) /* unsigned int */ Those don't cover the main proposed changes at DVBv4. Btw, what it is said there at at chapter 2.2[1] is still true: "Because of the architectual problems of the core, the inconsitency of the API and the lack of zero-copy DMA it’s not possible to simply extend the existing API. A complete new design is inevitable." > > The "modern" there refers to hardware back in 2005! > This is exactly what I wrote just above. Precisely. > Multiple frontends, tuners/demods, CAM's were already supported > There is no encrypt/decrypt hardware, either you have hardware > CAM's or SoftCAM's, which do the decryption for DVB streams. > These already exist with the old API itself. Yes, support for multiple fontends/demux/demods were added, but the A/V API only supports a 1:1 mapping between demux---> demod: typedef enum { VIDEO_SOURCE_DEMUX, /* Select the demux as the main source */ VIDEO_SOURCE_MEMORY /* If this source is selected, the stream comes from the user through the write system call */ } video_stream_source_t; typedef enum { AUDIO_SOURCE_DEMUX, /* Select the demux as the main source */ AUDIO_SOURCE_MEMORY /* Select internal memory as the main source */ } audio_stream_source_t; On other words, zero-copy decoding is only possible with 1:1 mapping: demux0 should route the video PID to video0 codec, demux1 should route the video PID to video1 codec ... demux<n> should route the video PID to video<n> codec There's no way to route a PID from demux3 to be handled by video0. Btw, if demux0 is filtering multiple video channels and the video codec accepts only a single video, with the current API, what channel would be decoded by its video0 codec? There's no way to set it with the existing API. > The S2 6400, KNC S2 Twin and most others do have multiple first > and second generation frontends. > > The DVB demux provides multiple PID's, you can have multiple PiP's > whatever you want. There's no provision at the API to control any parameters of PiP (like setting the position/size of the overlay area). Also, chipsets for TV sets expect zero-copy transfers between video decoders and GPU DRM planes. Most of such hardware are implemented with two separate chips (or two separate areas at the same silicon): - GPU + ISP + video memory; - ARM CPU. On such hardware, copying buffers via CPU is a very expensive operation. So, hardware pipelines should be programmed. For instance: frontend1 -> demux3 -> video0 -> DMA buffer 0 frontend1 -> demux3 --OSD pid--> DMA buffer 2 frontend1 -> demux3 --audio pid--> Audio input 0 frontend0 -> demux0 -> video1 -> DMA buffer 1 frontend0 -> demux0 --OSD pid--> DMA buffer 3 Then, the GPU's compositor will be programmed to properly place each DMA buffer at the composed PiP display, on whatever position the second video will be positioned at the composite screen. > For some SoC's with A/V codecs what you are saying is true. > It does not make sense for PCTV hardware to use the pipelines > you apparently describe. Such SoC's make use the extended API that > you advocate, but the standard PCTV, or standard STB hardware > we all are used to need not use the convoluted API being advocated. > For those SoC's one may use the V4L2 output. But for DVB output > devices, it makes no sense but going many steps backwards to use > the V4L2 output. The existing API works for simple hardware like av7110, but, in order to support what current chipsets provide, it has to be re-designed. As explained said at DVBv4 session 2.2[1]: "Linux DVB API Version 3 was focussed on the popular Siemens PCI DVB card." > > From driver's perspective, it makes no sense to keep support for av7110, > > as TI stopped production of TMS320AV7110 a very long time ago. They > > don't even mention this product number anymore on their website. > > > > What I meant: If there are some users for some hardware, it is impolite > to rip them out, especially when someone is volunteering to maintain them. > Rather than impolite, that's quite rude and arrogant. > > I believe that is the de facto Linux kernel principle still, unless > there is some > real reason to rip it out. > > FWIW, my 2c worth: > a) leave the headers where they belong, already done by Linus. Linus actually asked to copy such headers to the VDR source code. > b) av7110: hand over the maintenance to someone who is happy and has > time to fiddle around with Nobody that actually uses av7110 hardware (if are there any users for such hardware nowadays) ever sent a single patch upstream for quite a long time. See, from 2013 to today, there were 81 patches applied on it: $ git lg --since 2013 --follow -- drivers/media/pci/ttpci/|wc -l 81 None of those were produced by someone actually using av7110. No av7110 users ever replied to any of those patches with a Tested-by. So, nobody has shown any time/interest on maintaining it upstream for quite a long time. > c) Pull in the saa716x driver. I wrote the saa716x driver with NXP support > and with additional help from the community. It would be good to maintain > the credits to the original developers though. > > You can pull the saa716x driver from Soeren, if he needs some help, > I can chip in whatever possible way. Let him have some fun with the driver. It won't make any good to upstream a driver before discussing the API. Even low-end PC hardware (like those with Atom CPUs) nowadays are capable of decoding MPEG2 - and other video codecs - in hardware (at the GPU). This was a reality even back in 2005, as said at the DVBv4 doc, at section 2.1[1]: 'PCs and embedded platforms are divering. For PCs, new cards are only available as ”budget” cards, which means that they only provide the full, raw, unmodified TS to the system and put the burden of handling the data to the main CPU. On embedded platforms, however, dedicated STB/IDTV chipsets demultiplex the data for direct application use and specialized hardware or firmware on DSPs relieves the main CPU greatly.' As Honza pointed, a large amount of users of such API are the ones that have a DreamBox STB and decided to build their own firmware (like opendreambox), running a Kernel based on downstream patches[2]. Clearly, the main usage for a full-feat api is on Embedded hardware. [2] For them, it doesn't matter what API is at the upstream Kernel. All that matters is that the userspace software (like VDR) shall implement whatever API is used to communicate with the Enigma/Enigma2 DVB drivers. Thanks, Mauro
