Hi all
On VDD I was asked about (not) listing a release with SDR on the download page
and IIRC the consensus was to do a vote on it.
As you notice i am a bit hesitant to start a vote because its always better
to find solutions evereyone is happy with and not just a majority.
I also would prefer
On Sat, Jun 24, 2023 at 12:12:50PM +0200, Tomas Härdin wrote:
> fre 2023-06-23 klockan 23:36 +0200 skrev Michael Niedermayer:
> > On Fri, Jun 23, 2023 at 10:19:37PM +0200, Tomas Härdin wrote:
> > > fre 2023-06-23 klockan 22:18 +0200 skrev Tomas Härdin:
> > > > tor 2023-06-22 klockan 16:57 +0200
fre 2023-06-23 klockan 23:36 +0200 skrev Michael Niedermayer:
> On Fri, Jun 23, 2023 at 10:19:37PM +0200, Tomas Härdin wrote:
> > fre 2023-06-23 klockan 22:18 +0200 skrev Tomas Härdin:
> > > tor 2023-06-22 klockan 16:57 +0200 skrev Michael Niedermayer:
> > > > If we support just audio and video
On Fri, Jun 23, 2023 at 10:19:37PM +0200, Tomas Härdin wrote:
> fre 2023-06-23 klockan 22:18 +0200 skrev Tomas Härdin:
> > tor 2023-06-22 klockan 16:57 +0200 skrev Michael Niedermayer:
> > > If we support just audio and video (de)modulation it fits nicely in
> > > FFmpeg
> >
> > You have no idea
fre 2023-06-23 klockan 22:18 +0200 skrev Tomas Härdin:
> tor 2023-06-22 klockan 16:57 +0200 skrev Michael Niedermayer:
> > If we support just audio and video (de)modulation it fits nicely in
> > FFmpeg
>
> You have no idea what you are getting into. Are we going to implement
> a
> DVB-T demuxer
tor 2023-06-22 klockan 16:57 +0200 skrev Michael Niedermayer:
> If we support just audio and video (de)modulation it fits nicely in FFmpeg
You have no idea what you are getting into. Are we going to implement a
DVB-T demuxer in this project? For what purpose? You can just as well
implement a
On 6/22/2023 1:09 PM, Anton Khirnov wrote:
Hi,
I'm sorry to say, the patch at its current state is quite far from
something I'd consider acceptable for git master.
1) Given that there are sdr and sdrfile demuxers, it seems to me that
the transport layer should be split into a protocol rather
On Thu, Jun 22, 2023 at 07:43:11PM +0200, Michael Niedermayer wrote:
> On Thu, Jun 22, 2023 at 06:09:47PM +0200, Anton Khirnov wrote:
[...]
> > 3) sdr_read_header() and sdr_read_packet() are giant, hideous, and
> > unreadable.
>
> I disagree that they are hideous and unreadable. In fact its
On Thu, Jun 22, 2023 at 06:09:47PM +0200, Anton Khirnov wrote:
> Hi,
> I'm sorry to say, the patch at its current state is quite far from
> something I'd consider acceptable for git master.
>
> 1) Given that there are sdr and sdrfile demuxers, it seems to me that
> the transport layer should be
Hi,
I'm sorry to say, the patch at its current state is quite far from
something I'd consider acceptable for git master.
1) Given that there are sdr and sdrfile demuxers, it seems to me that
the transport layer should be split into a protocol rather than be
inside the demuxer
2) Threading inside
Am 22.06.23 um 17:01 schrieb James Almer:
On 6/22/2023 11:57 AM, Michael Niedermayer wrote:
Hi all
My humble opinion(s) and plan(s) about SDR
FFmpeg as a multimedia framework should support SDR.
The only practical way to support SDR in FFmpeg ATM is through a demuxer (or
equivalent)
Not
On 6/22/2023 11:57 AM, Michael Niedermayer wrote:
Hi all
My humble opinion(s) and plan(s) about SDR
FFmpeg as a multimedia framework should support SDR.
The only practical way to support SDR in FFmpeg ATM is through a demuxer (or
equivalent)
Not everyone is happy about a SDR demuxer.
The
Hi all
My humble opinion(s) and plan(s) about SDR
FFmpeg as a multimedia framework should support SDR.
The only practical way to support SDR in FFmpeg ATM is through a demuxer (or
equivalent)
Not everyone is happy about a SDR demuxer.
The "active" code could be in the demuxer itself or an
13 matches
Mail list logo
