Re: [FFmpeg-devel] What is FFmpeg and what should it be

From: Nicolas George <george@nsup.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] What is FFmpeg and what should it be
Date: Thu, 3 Aug 2023 15:29:55 +0200
Message-ID: <ZMur03g2wvl5HcQm@phare.normalesup.org> (raw)
In-Reply-To: <e78f3d20bb6eb2b8465e76601aecae8cf0c1a46e.camel@haerdin.se>

Tomas Härdin (12023-08-03):
> I thought of another thing that bears mentioning: Michael has expressed
> interest in implementing DAB. This carries with it two problems:
> 
> * Each DAB ensemble is an MPEG-TS stream
> * There can be more than one ensemble on air
> 
> The first means mere demodulation is not enough - MPEG-TS must also be
> implemented somehow. This likely means a dependency on lavf, assuming
> we are not so insane as to have two independent MPEG-TS
> implementations. There might also be an impedance mismatch due to lavf
> pulling bytes from avio. There's no way to "push" bytes to a demuxer.
> Synchronization may be an issue, though I admit I'm not 100% sure here.
> Perhaps the device can pretend to be a protocol, entailing even tighter
> coupling with lavf? Also I don't think registering protocols from
> outside is allowed.
> 
> The second means that if such a DAB device is to work similar to the FM
> demodulator handling multiple stations, then somehow multiple MPEG-TS
> streams have to be dealt with. AFAIK lavd cannot do this. Merging MPEG-
> TS streams might be tempting, but is not guaranteed to work I think.

Or maybe Michael, being a very skilled hacker, will find a smart
solution that will make it work without code duplication.

You do not know what code he will submit. Why waste time speculating and
discussing nightmare scenarios that will probably not happen on this
mailing-list?

> I still don't understand why this must live in lavd rather than having
> a separate program that does this and does it well. There is useful DSP
> code in libav* that can then be motivated breaking out into a separate
> library.

Oh, yes, great idea! More administrative bloat.

You were complaining about wasting precious developer time on useless
tasks, you should start by yourself: wasting precious developer time on
maintaining extra build systems and packaging.

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".