OpenCloudOS-Kernel/drivers/media/test-drivers/vidtv/vidtv_channel.h

82 lines
2.9 KiB
C
Raw Normal View History

media: vidtv: add a bridge driver Digital TV devices consist of several independent hardware components which are controlled by different drivers. Each media device is controlled by a group of cooperating drivers with the bridge driver as the main driver. This patch adds a bridge driver for the Virtual Digital TV driver [vidtv]. The bridge driver binds to the other drivers, that is, vidtv_tuner and vidtv_demod and implements the digital demux logic, providing userspace with a MPEG Transport Stream. The MPEG related code is split in the following way: - vidtv_ts: code to work with MPEG TS packets, such as TS headers, adaptation fields, PCR packets and NULL packets. - vidtv_psi: this is the PSI generator. PSI packets contain general information about a MPEG Transport Stream. A PSI generator is needed so userspace apps can retrieve information about the Transport Stream and eventually tune into a (dummy) channel. Because the generator is implemented in a separate file, it can be reused elsewhere in the media subsystem. Currently vidtv supports working with 3 PSI tables: PAT, PMT and SDT. - vidtv_pes: implements the PES logic to convert encoder data into MPEG TS packets. These can then be fed into a TS multiplexer and eventually into userspace. - vidtv_s302m: implements a S302M encoder to make it possible to insert PCM audio data in the generated MPEG Transport Stream. This shall enable passing an audio signal into userspace so it can be decoded and played by media software. - vidtv_channels: Implements a 'channel' abstraction When vidtv boots, it will create some hardcoded channels: Their services will be concatenated to populate the SDT. Their programs will be concatenated to populate the PAT For each program in the PAT, a PMT section will be created The PMT section for a channel will be assigned its streams. Every stream will have its corresponding encoder polled to produce TS packets These packets may be interleaved by the mux and then delivered to the bridge - vidtv_mux - Implements a MPEG TS mux, loosely based on the ffmpeg implementation The multiplexer is responsible for polling encoders, interleaving packets, padding the resulting stream with NULL packets if necessary and then delivering the resulting TS packets to the bridge driver so it can feed the demux. Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-21 20:58:47 +08:00
/* SPDX-License-Identifier: GPL-2.0 */
/*
* Vidtv serves as a reference DVB driver and helps validate the existing APIs
* in the media subsystem. It can also aid developers working on userspace
* applications.
*
* This file contains the code for a 'channel' abstraction.
*
* When vidtv boots, it will create some hardcoded channels.
* Their services will be concatenated to populate the SDT.
* Their programs will be concatenated to populate the PAT
* Their events will be concatenated to populate the EIT
media: vidtv: add a bridge driver Digital TV devices consist of several independent hardware components which are controlled by different drivers. Each media device is controlled by a group of cooperating drivers with the bridge driver as the main driver. This patch adds a bridge driver for the Virtual Digital TV driver [vidtv]. The bridge driver binds to the other drivers, that is, vidtv_tuner and vidtv_demod and implements the digital demux logic, providing userspace with a MPEG Transport Stream. The MPEG related code is split in the following way: - vidtv_ts: code to work with MPEG TS packets, such as TS headers, adaptation fields, PCR packets and NULL packets. - vidtv_psi: this is the PSI generator. PSI packets contain general information about a MPEG Transport Stream. A PSI generator is needed so userspace apps can retrieve information about the Transport Stream and eventually tune into a (dummy) channel. Because the generator is implemented in a separate file, it can be reused elsewhere in the media subsystem. Currently vidtv supports working with 3 PSI tables: PAT, PMT and SDT. - vidtv_pes: implements the PES logic to convert encoder data into MPEG TS packets. These can then be fed into a TS multiplexer and eventually into userspace. - vidtv_s302m: implements a S302M encoder to make it possible to insert PCM audio data in the generated MPEG Transport Stream. This shall enable passing an audio signal into userspace so it can be decoded and played by media software. - vidtv_channels: Implements a 'channel' abstraction When vidtv boots, it will create some hardcoded channels: Their services will be concatenated to populate the SDT. Their programs will be concatenated to populate the PAT For each program in the PAT, a PMT section will be created The PMT section for a channel will be assigned its streams. Every stream will have its corresponding encoder polled to produce TS packets These packets may be interleaved by the mux and then delivered to the bridge - vidtv_mux - Implements a MPEG TS mux, loosely based on the ffmpeg implementation The multiplexer is responsible for polling encoders, interleaving packets, padding the resulting stream with NULL packets if necessary and then delivering the resulting TS packets to the bridge driver so it can feed the demux. Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-21 20:58:47 +08:00
* For each program in the PAT, a PMT section will be created
* The PMT section for a channel will be assigned its streams.
* Every stream will have its corresponding encoder polled to produce TS packets
* These packets may be interleaved by the mux and then delivered to the bridge
*
*
* Copyright (C) 2020 Daniel W. S. Almeida
*/
#ifndef VIDTV_CHANNEL_H
#define VIDTV_CHANNEL_H
#include <linux/types.h>
media: vidtv: add a bridge driver Digital TV devices consist of several independent hardware components which are controlled by different drivers. Each media device is controlled by a group of cooperating drivers with the bridge driver as the main driver. This patch adds a bridge driver for the Virtual Digital TV driver [vidtv]. The bridge driver binds to the other drivers, that is, vidtv_tuner and vidtv_demod and implements the digital demux logic, providing userspace with a MPEG Transport Stream. The MPEG related code is split in the following way: - vidtv_ts: code to work with MPEG TS packets, such as TS headers, adaptation fields, PCR packets and NULL packets. - vidtv_psi: this is the PSI generator. PSI packets contain general information about a MPEG Transport Stream. A PSI generator is needed so userspace apps can retrieve information about the Transport Stream and eventually tune into a (dummy) channel. Because the generator is implemented in a separate file, it can be reused elsewhere in the media subsystem. Currently vidtv supports working with 3 PSI tables: PAT, PMT and SDT. - vidtv_pes: implements the PES logic to convert encoder data into MPEG TS packets. These can then be fed into a TS multiplexer and eventually into userspace. - vidtv_s302m: implements a S302M encoder to make it possible to insert PCM audio data in the generated MPEG Transport Stream. This shall enable passing an audio signal into userspace so it can be decoded and played by media software. - vidtv_channels: Implements a 'channel' abstraction When vidtv boots, it will create some hardcoded channels: Their services will be concatenated to populate the SDT. Their programs will be concatenated to populate the PAT For each program in the PAT, a PMT section will be created The PMT section for a channel will be assigned its streams. Every stream will have its corresponding encoder polled to produce TS packets These packets may be interleaved by the mux and then delivered to the bridge - vidtv_mux - Implements a MPEG TS mux, loosely based on the ffmpeg implementation The multiplexer is responsible for polling encoders, interleaving packets, padding the resulting stream with NULL packets if necessary and then delivering the resulting TS packets to the bridge driver so it can feed the demux. Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-21 20:58:47 +08:00
#include "vidtv_encoder.h"
#include "vidtv_mux.h"
#include "vidtv_psi.h"
media: vidtv: add a bridge driver Digital TV devices consist of several independent hardware components which are controlled by different drivers. Each media device is controlled by a group of cooperating drivers with the bridge driver as the main driver. This patch adds a bridge driver for the Virtual Digital TV driver [vidtv]. The bridge driver binds to the other drivers, that is, vidtv_tuner and vidtv_demod and implements the digital demux logic, providing userspace with a MPEG Transport Stream. The MPEG related code is split in the following way: - vidtv_ts: code to work with MPEG TS packets, such as TS headers, adaptation fields, PCR packets and NULL packets. - vidtv_psi: this is the PSI generator. PSI packets contain general information about a MPEG Transport Stream. A PSI generator is needed so userspace apps can retrieve information about the Transport Stream and eventually tune into a (dummy) channel. Because the generator is implemented in a separate file, it can be reused elsewhere in the media subsystem. Currently vidtv supports working with 3 PSI tables: PAT, PMT and SDT. - vidtv_pes: implements the PES logic to convert encoder data into MPEG TS packets. These can then be fed into a TS multiplexer and eventually into userspace. - vidtv_s302m: implements a S302M encoder to make it possible to insert PCM audio data in the generated MPEG Transport Stream. This shall enable passing an audio signal into userspace so it can be decoded and played by media software. - vidtv_channels: Implements a 'channel' abstraction When vidtv boots, it will create some hardcoded channels: Their services will be concatenated to populate the SDT. Their programs will be concatenated to populate the PAT For each program in the PAT, a PMT section will be created The PMT section for a channel will be assigned its streams. Every stream will have its corresponding encoder polled to produce TS packets These packets may be interleaved by the mux and then delivered to the bridge - vidtv_mux - Implements a MPEG TS mux, loosely based on the ffmpeg implementation The multiplexer is responsible for polling encoders, interleaving packets, padding the resulting stream with NULL packets if necessary and then delivering the resulting TS packets to the bridge driver so it can feed the demux. Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-21 20:58:47 +08:00
/**
* struct vidtv_channel - A 'channel' abstraction
*
* When vidtv boots, it will create some hardcoded channels.
* Their services will be concatenated to populate the SDT.
* Their programs will be concatenated to populate the PAT
* For each program in the PAT, a PMT section will be created
* The PMT section for a channel will be assigned its streams.
* Every stream will have its corresponding encoder polled to produce TS packets
* These packets may be interleaved by the mux and then delivered to the bridge
*
* @name: name of the channel
media: vidtv: add a bridge driver Digital TV devices consist of several independent hardware components which are controlled by different drivers. Each media device is controlled by a group of cooperating drivers with the bridge driver as the main driver. This patch adds a bridge driver for the Virtual Digital TV driver [vidtv]. The bridge driver binds to the other drivers, that is, vidtv_tuner and vidtv_demod and implements the digital demux logic, providing userspace with a MPEG Transport Stream. The MPEG related code is split in the following way: - vidtv_ts: code to work with MPEG TS packets, such as TS headers, adaptation fields, PCR packets and NULL packets. - vidtv_psi: this is the PSI generator. PSI packets contain general information about a MPEG Transport Stream. A PSI generator is needed so userspace apps can retrieve information about the Transport Stream and eventually tune into a (dummy) channel. Because the generator is implemented in a separate file, it can be reused elsewhere in the media subsystem. Currently vidtv supports working with 3 PSI tables: PAT, PMT and SDT. - vidtv_pes: implements the PES logic to convert encoder data into MPEG TS packets. These can then be fed into a TS multiplexer and eventually into userspace. - vidtv_s302m: implements a S302M encoder to make it possible to insert PCM audio data in the generated MPEG Transport Stream. This shall enable passing an audio signal into userspace so it can be decoded and played by media software. - vidtv_channels: Implements a 'channel' abstraction When vidtv boots, it will create some hardcoded channels: Their services will be concatenated to populate the SDT. Their programs will be concatenated to populate the PAT For each program in the PAT, a PMT section will be created The PMT section for a channel will be assigned its streams. Every stream will have its corresponding encoder polled to produce TS packets These packets may be interleaved by the mux and then delivered to the bridge - vidtv_mux - Implements a MPEG TS mux, loosely based on the ffmpeg implementation The multiplexer is responsible for polling encoders, interleaving packets, padding the resulting stream with NULL packets if necessary and then delivering the resulting TS packets to the bridge driver so it can feed the demux. Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-21 20:58:47 +08:00
* @transport_stream_id: a number to identify the TS, chosen at will.
* @service: A _single_ service. Will be concatenated into the SDT.
* @program_num: The link between PAT, PMT and SDT.
* @program: A _single_ program with one or more streams associated with it.
* Will be concatenated into the PAT.
* @streams: A stream loop used to populate the PMT section for 'program'
* @encoders: A encoder loop. There must be one encoder for each stream.
* @events: Optional event information. This will feed into the EIT.
media: vidtv: add a bridge driver Digital TV devices consist of several independent hardware components which are controlled by different drivers. Each media device is controlled by a group of cooperating drivers with the bridge driver as the main driver. This patch adds a bridge driver for the Virtual Digital TV driver [vidtv]. The bridge driver binds to the other drivers, that is, vidtv_tuner and vidtv_demod and implements the digital demux logic, providing userspace with a MPEG Transport Stream. The MPEG related code is split in the following way: - vidtv_ts: code to work with MPEG TS packets, such as TS headers, adaptation fields, PCR packets and NULL packets. - vidtv_psi: this is the PSI generator. PSI packets contain general information about a MPEG Transport Stream. A PSI generator is needed so userspace apps can retrieve information about the Transport Stream and eventually tune into a (dummy) channel. Because the generator is implemented in a separate file, it can be reused elsewhere in the media subsystem. Currently vidtv supports working with 3 PSI tables: PAT, PMT and SDT. - vidtv_pes: implements the PES logic to convert encoder data into MPEG TS packets. These can then be fed into a TS multiplexer and eventually into userspace. - vidtv_s302m: implements a S302M encoder to make it possible to insert PCM audio data in the generated MPEG Transport Stream. This shall enable passing an audio signal into userspace so it can be decoded and played by media software. - vidtv_channels: Implements a 'channel' abstraction When vidtv boots, it will create some hardcoded channels: Their services will be concatenated to populate the SDT. Their programs will be concatenated to populate the PAT For each program in the PAT, a PMT section will be created The PMT section for a channel will be assigned its streams. Every stream will have its corresponding encoder polled to produce TS packets These packets may be interleaved by the mux and then delivered to the bridge - vidtv_mux - Implements a MPEG TS mux, loosely based on the ffmpeg implementation The multiplexer is responsible for polling encoders, interleaving packets, padding the resulting stream with NULL packets if necessary and then delivering the resulting TS packets to the bridge driver so it can feed the demux. Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-21 20:58:47 +08:00
* @next: Optionally chain this channel.
*/
struct vidtv_channel {
char *name;
u16 transport_stream_id;
struct vidtv_psi_table_sdt_service *service;
u16 program_num;
struct vidtv_psi_table_pat_program *program;
struct vidtv_psi_table_pmt_stream *streams;
struct vidtv_encoder *encoders;
struct vidtv_psi_table_eit_event *events;
media: vidtv: add a bridge driver Digital TV devices consist of several independent hardware components which are controlled by different drivers. Each media device is controlled by a group of cooperating drivers with the bridge driver as the main driver. This patch adds a bridge driver for the Virtual Digital TV driver [vidtv]. The bridge driver binds to the other drivers, that is, vidtv_tuner and vidtv_demod and implements the digital demux logic, providing userspace with a MPEG Transport Stream. The MPEG related code is split in the following way: - vidtv_ts: code to work with MPEG TS packets, such as TS headers, adaptation fields, PCR packets and NULL packets. - vidtv_psi: this is the PSI generator. PSI packets contain general information about a MPEG Transport Stream. A PSI generator is needed so userspace apps can retrieve information about the Transport Stream and eventually tune into a (dummy) channel. Because the generator is implemented in a separate file, it can be reused elsewhere in the media subsystem. Currently vidtv supports working with 3 PSI tables: PAT, PMT and SDT. - vidtv_pes: implements the PES logic to convert encoder data into MPEG TS packets. These can then be fed into a TS multiplexer and eventually into userspace. - vidtv_s302m: implements a S302M encoder to make it possible to insert PCM audio data in the generated MPEG Transport Stream. This shall enable passing an audio signal into userspace so it can be decoded and played by media software. - vidtv_channels: Implements a 'channel' abstraction When vidtv boots, it will create some hardcoded channels: Their services will be concatenated to populate the SDT. Their programs will be concatenated to populate the PAT For each program in the PAT, a PMT section will be created The PMT section for a channel will be assigned its streams. Every stream will have its corresponding encoder polled to produce TS packets These packets may be interleaved by the mux and then delivered to the bridge - vidtv_mux - Implements a MPEG TS mux, loosely based on the ffmpeg implementation The multiplexer is responsible for polling encoders, interleaving packets, padding the resulting stream with NULL packets if necessary and then delivering the resulting TS packets to the bridge driver so it can feed the demux. Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-21 20:58:47 +08:00
struct vidtv_channel *next;
};
/**
* vidtv_channel_si_init - Init the PSI tables from the channels in the mux
* @m: The mux containing the channels.
*/
int vidtv_channel_si_init(struct vidtv_mux *m);
media: vidtv: add a bridge driver Digital TV devices consist of several independent hardware components which are controlled by different drivers. Each media device is controlled by a group of cooperating drivers with the bridge driver as the main driver. This patch adds a bridge driver for the Virtual Digital TV driver [vidtv]. The bridge driver binds to the other drivers, that is, vidtv_tuner and vidtv_demod and implements the digital demux logic, providing userspace with a MPEG Transport Stream. The MPEG related code is split in the following way: - vidtv_ts: code to work with MPEG TS packets, such as TS headers, adaptation fields, PCR packets and NULL packets. - vidtv_psi: this is the PSI generator. PSI packets contain general information about a MPEG Transport Stream. A PSI generator is needed so userspace apps can retrieve information about the Transport Stream and eventually tune into a (dummy) channel. Because the generator is implemented in a separate file, it can be reused elsewhere in the media subsystem. Currently vidtv supports working with 3 PSI tables: PAT, PMT and SDT. - vidtv_pes: implements the PES logic to convert encoder data into MPEG TS packets. These can then be fed into a TS multiplexer and eventually into userspace. - vidtv_s302m: implements a S302M encoder to make it possible to insert PCM audio data in the generated MPEG Transport Stream. This shall enable passing an audio signal into userspace so it can be decoded and played by media software. - vidtv_channels: Implements a 'channel' abstraction When vidtv boots, it will create some hardcoded channels: Their services will be concatenated to populate the SDT. Their programs will be concatenated to populate the PAT For each program in the PAT, a PMT section will be created The PMT section for a channel will be assigned its streams. Every stream will have its corresponding encoder polled to produce TS packets These packets may be interleaved by the mux and then delivered to the bridge - vidtv_mux - Implements a MPEG TS mux, loosely based on the ffmpeg implementation The multiplexer is responsible for polling encoders, interleaving packets, padding the resulting stream with NULL packets if necessary and then delivering the resulting TS packets to the bridge driver so it can feed the demux. Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-21 20:58:47 +08:00
void vidtv_channel_si_destroy(struct vidtv_mux *m);
/**
* vidtv_channels_init - Init hardcoded, fake 'channels'.
* @m: The mux to store the channels into.
*/
int vidtv_channels_init(struct vidtv_mux *m);
media: vidtv: add a bridge driver Digital TV devices consist of several independent hardware components which are controlled by different drivers. Each media device is controlled by a group of cooperating drivers with the bridge driver as the main driver. This patch adds a bridge driver for the Virtual Digital TV driver [vidtv]. The bridge driver binds to the other drivers, that is, vidtv_tuner and vidtv_demod and implements the digital demux logic, providing userspace with a MPEG Transport Stream. The MPEG related code is split in the following way: - vidtv_ts: code to work with MPEG TS packets, such as TS headers, adaptation fields, PCR packets and NULL packets. - vidtv_psi: this is the PSI generator. PSI packets contain general information about a MPEG Transport Stream. A PSI generator is needed so userspace apps can retrieve information about the Transport Stream and eventually tune into a (dummy) channel. Because the generator is implemented in a separate file, it can be reused elsewhere in the media subsystem. Currently vidtv supports working with 3 PSI tables: PAT, PMT and SDT. - vidtv_pes: implements the PES logic to convert encoder data into MPEG TS packets. These can then be fed into a TS multiplexer and eventually into userspace. - vidtv_s302m: implements a S302M encoder to make it possible to insert PCM audio data in the generated MPEG Transport Stream. This shall enable passing an audio signal into userspace so it can be decoded and played by media software. - vidtv_channels: Implements a 'channel' abstraction When vidtv boots, it will create some hardcoded channels: Their services will be concatenated to populate the SDT. Their programs will be concatenated to populate the PAT For each program in the PAT, a PMT section will be created The PMT section for a channel will be assigned its streams. Every stream will have its corresponding encoder polled to produce TS packets These packets may be interleaved by the mux and then delivered to the bridge - vidtv_mux - Implements a MPEG TS mux, loosely based on the ffmpeg implementation The multiplexer is responsible for polling encoders, interleaving packets, padding the resulting stream with NULL packets if necessary and then delivering the resulting TS packets to the bridge driver so it can feed the demux. Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-21 20:58:47 +08:00
struct vidtv_channel
*vidtv_channel_s302m_init(struct vidtv_channel *head, u16 transport_stream_id);
void vidtv_channels_destroy(struct vidtv_mux *m);
#endif //VIDTV_CHANNEL_H