[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200506110125.03f42b03@coco.lan>
Date: Wed, 6 May 2020 11:01:25 +0200
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: "Daniel W. S. Almeida" <dwlsalmeida@...il.com>
Cc: "sean@...s.org" <sean@...s.org>,
"kstewart@...uxfoundation.org" <kstewart@...uxfoundation.org>,
"allison@...utok.net" <allison@...utok.net>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
"skhan@...uxfoundation.org" <skhan@...uxfoundation.org>,
"linux-kernel-mentees@...ts.linuxfoundation.org"
<linux-kernel-mentees@...ts.linuxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC, WIP, v4 11/11] media: vidtv: Add a MPEG Transport Stream
Multiplexer
Em Wed, 6 May 2020 04:05:25 -0300
"Daniel W. S. Almeida" <dwlsalmeida@...il.com> escreveu:
> Hi Mauro! Thank you for reviewing this!
>
>
> >> Add a MPEG Transport Stream multiplexer 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.
> >>
> >> This patch includes a "channel" abstraction, which attempts to map a
> >> MPEG service into a struct that vidtv can work with.
> >>
> >> 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 bridg
> >>
> >> Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@...il.com>
> >
> > The same notes I made on previous patches apply here.
>
> I did not understand this. Do you mean to say that I should remove these
> dashes in the beginning of the lines?
No. I just meant to say that I won't be repeating the comments I made
about WARN_ON, bit order, and other generic comments on other patches
that will also apply here :-)
Thanks,
Mauro
Powered by blists - more mailing lists