Revision tags: v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10 |
|
#
1d2b2a6d |
| 23-Nov-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
media: vidtv: fix the network ID range
As defined at ETSI TS 101 162, original network IDs up to 0xfebf are reserved for registration at dvb.org.
Let's use, instead, an original network ID at the r
media: vidtv: fix the network ID range
As defined at ETSI TS 101 162, original network IDs up to 0xfebf are reserved for registration at dvb.org.
Let's use, instead, an original network ID at the range 0xff00-0xffff, as this is for private temporary usage.
As the same value is also used for the network ID, the range 0xff01-0xffff also fits better, as values lower than that depend if the network is used for satellite, terrestrial, cable of CI.
While here, move the TS ID to the bridge code, where it is used, and change its value, as it was identical to the value previously used by network ID. While we could keep the same value, let's change it, just to make easier to check for the new code while reading it with DVB tools like dvbinspector.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61 |
|
#
f90cf607 |
| 21-Aug-2020 |
Daniel W. S. Almeida <dwlsalmeida@gmail.com> |
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 coope
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>
show more ...
|
Revision tags: v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10 |
|
#
1d2b2a6d |
| 23-Nov-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
media: vidtv: fix the network ID range As defined at ETSI TS 101 162, original network IDs up to 0xfebf are reserved for registration at dvb.org. Let's use, instead, an original
media: vidtv: fix the network ID range As defined at ETSI TS 101 162, original network IDs up to 0xfebf are reserved for registration at dvb.org. Let's use, instead, an original network ID at the range 0xff00-0xffff, as this is for private temporary usage. As the same value is also used for the network ID, the range 0xff01-0xffff also fits better, as values lower than that depend if the network is used for satellite, terrestrial, cable of CI. While here, move the TS ID to the bridge code, where it is used, and change its value, as it was identical to the value previously used by network ID. While we could keep the same value, let's change it, just to make easier to check for the new code while reading it with DVB tools like dvbinspector. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61 |
|
#
f90cf607 |
| 21-Aug-2020 |
Daniel W. S. Almeida <dwlsalmeida@gmail.com> |
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
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>
show more ...
|