Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Kieran Kunhya <kierank@obe.tv>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH v6 0/1] avformat: add Software Defined Radio support
Date: Sat, 1 Jul 2023 21:42:14 +0100
Message-ID: <CAK+ULv6U_NqdqwT=N_7yeHdngvwuQ8Vk5X83VWLzf0HMBi+FFQ@mail.gmail.com> (raw)
In-Reply-To: <20230701200635.GH1093384@pb2>

>
> If we look at DAB or DVB in a more fundamental way, they have no need
> for mpegts.
> Should this (apparently unneeded) design decission in DAB/DVB dictate
> design on our side when it has not previously ?
>

What planet do you live on, of course they need MPEG-TS? How do you have
multiple programs in a mux and associated data for EPG?
Literally the whole point of Digital TV was that we could put more channels
in the space that one analogue channel took.
There are no other containers that support multiple programs.

For the rest of MPEG-TS justification I point you to:
https://www.obe.tv/why-does-mpeg-ts-still-exist/


> If so, what design ?
>

This is purely a flaw in FFmpeg that protocol/demux are joined up into the
same library. Also an assumption (coming from things like AVI and probably
reasonable at the time) that there is only going to be one layer of demux,
whereas in modern codecs (HEIF, LC-EVC, Dolby E etc) there can be many
layers of demux required.

Your logic is flawed, you base your assumption that everyone else is wrong
when it's in fact FFmpeg that's in the wrong by mixing transport and
container into the same library.


> > As for purely AM/FM, I'm not quire sure what the right level for
> > that is though.
>
> >
> > In any case, I disagree with the procedure of stating to push the patch
> if
> > there's no objections, when there has been numerous objections from
> > essentially most of the active community already.
>
> The objections have been unclear, are they against SDR, against the
> implementation.
> I took the liberty to be pushy here to get this more clear. And i will
> continue to do this until i get clear responses. Because otherwise
> iam just stuck as i dont know how to correct the design and code.
>

They are against SDR as this violates layering. FFmpeg doesn't handle the
physical layer, third party libs do upstream (e.g hardware capture).
Again, should we implement WiFi SDR in FFmpeg? Should we implement a
userspace TCP stack? Should we implement bitbanged Ethernet? All of these
things sit at a different layer to the data and transport layer that FFmpeg
sits in.

Regards,
Kieran Kunhya
_______________________________________________
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".

  reply	other threads:[~2023-07-01 20:42 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-28 21:25 Michael Niedermayer
2023-06-28 21:25 ` [FFmpeg-devel] [PATCH v6] " Michael Niedermayer
2023-06-29 15:43 ` [FFmpeg-devel] [PATCH v6 0/1] " Paul B Mahol
2023-06-30 14:08   ` Michael Niedermayer
2023-06-30 14:38     ` Jean-Baptiste Kempf
2023-06-30 17:40       ` Michael Niedermayer
2023-06-30 17:57         ` Paul B Mahol
2023-06-30 18:02         ` Michael Niedermayer
2023-07-01 15:28           ` Rémi Denis-Courmont
2023-07-01 18:56             ` Michael Niedermayer
2023-07-01 19:30               ` Paul B Mahol
2023-07-02  9:40           ` Nicolas George
2023-07-02 10:08             ` Paul B Mahol
2023-07-02 13:47               ` Rémi Denis-Courmont
2023-07-02 16:01                 ` Nicolas George
2023-07-02 18:21                   ` Rémi Denis-Courmont
2023-07-02 11:00       ` Michael Niedermayer
2023-07-02 16:11         ` Nicolas George
2023-07-02 18:55         ` Lynne
2023-07-02 21:14           ` Michael Niedermayer
2023-07-02 22:03             ` Lynne
2023-07-02 22:46               ` Michael Niedermayer
2023-07-10  6:57                 ` Lynne
2023-07-11 21:09                   ` Michael Niedermayer
2023-06-30 17:00     ` Kieran Kunhya
2023-07-01 15:20       ` Michael Niedermayer
2023-06-30 21:36     ` Martin Storsjö
2023-07-01 14:44       ` Michael Niedermayer
2023-07-01 19:41         ` Martin Storsjö
2023-07-01 19:56           ` Tomas Härdin
2023-07-01 20:06           ` Michael Niedermayer
2023-07-01 20:42             ` Kieran Kunhya [this message]
2023-07-01 21:25               ` Michael Niedermayer
2023-07-01 21:32                 ` Kieran Kunhya
2023-07-01 19:08       ` Anton Khirnov
2023-07-01 19:35       ` Michael Niedermayer
2023-07-02  9:58       ` Nicolas George
2023-07-02 10:10         ` Paul B Mahol
2023-07-02 10:43         ` Jean-Baptiste Kempf
2023-07-02 16:07           ` Nicolas George
2023-07-02 18:13             ` Jean-Baptiste Kempf
2023-07-02 18:20               ` Nicolas George
2023-07-02 18:32                 ` Michael Niedermayer
2023-07-02 18:52             ` Lynne
2023-07-02 19:52               ` Nicolas George
2023-07-02 20:29                 ` Lynne
2023-06-30 22:02     ` Tomas Härdin
2023-07-02  9:28       ` Nicolas George

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAK+ULv6U_NqdqwT=N_7yeHdngvwuQ8Vk5X83VWLzf0HMBi+FFQ@mail.gmail.com' \
    --to=kierank@obe.tv \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git