[FFmpeg-devel] Would a crypto file be acceptable?

[Ronald S. Bultje]

Hi,

On Wed, Dec 28, 2022 at 11:14 AM Mark Gaiser <markg85 at gmail.com> wrote:

> On Wed, Dec 28, 2022 at 3:27 PM Ronald S. Bultje <rsbultje at gmail.com>
> wrote:
>
> > Hi Mark,
> >
> > On Tue, Dec 27, 2022 at 5:47 PM Mark Gaiser <markg85 at gmail.com> wrote:
> >
> > > The tricky part here is for anyone using this scheme to play this file.
> > > Right now i'm doing this with a command line like:
> > > ffplay crypto://encrypted_file -decryption_key $AES_KEY -decryption_iv
> > > $AES_IV
> > >
> > > For brevity's sake, consider the "metadata" file named above to be the
> > > _encrypted_ version of the ".crypto" file i'm proposing.
> > > [..]
> > >
> > There's many ways to do this key part. My intention for now was to keep
> it
> > > "simple" and have the key in the file itself.
> > >
> >
> > There's multiple things going on here, and you're sort of putting them
> all
> > together to solve all problems at once:
> > - a mechanism for crypto-data exchange in your application or
> server/client
> > protocol
> > - a way for your application to pass the crypto-data to the underlying
> > library
> >
> > I think once you split these out as separate entities, you'll see that
> you
> > don't necessarily need the same solution for it. The second one, in
> > particular, is already solved in FFmpeg, and this is called an AVOption.
> > (And the first question is really out of FFmpeg scope anyway.) Have you
> > considered simply using AVOption, and/or is there a reason AVOption
> isn't a
> > suitable solution for your use case?
> >
> > Hi Roland,
>
> There's definitely multiple things going on but it's not what you
> summarize.
>
> 1. DEV (me) goes to the mailing list to propose a new feature. Dev tries to
> be concise and to the point to not litter the request with irrelevant side
> details.
> 2. MU (mailing list user) is skeptical and needs more context - which is
> great!
> 3. DEV gives more context
> 4. MU now discusses irrelevant side-details that DEV tried to prevent in
> the initial post - this is where things go wrong
> 5. Topic is now derailed with side suggestions that have nothing todo with
> the initial proposal. Feature potentially never gets built.
>
> Point 5 is where we're roughly at right now. I will make this feature
> because I need to have it for my own project.
>
> I'm fine discussing the proposed format further.
> I know _exactly_ what i want to do.
>

But why? This is not a format. It's not a container, or a playlist. It's an
artificial key/value exchange protocol created just for you. That's even
the specific purpose of this format: it has no other purpose than to
circumvent AVOption because it's ... complicated? I really don't understand
why this is preferable over AVOption. Yet, you refuse to discuss this.

And aside: the "DEV" and "MU" people in your story are much more than a
fabulous white hat hacker vs. internet troll which you make it out to be
(in what order?). Don't forget "MU" carries the long-term maintenance
burden. This is not derailing; this is called design review.

Ronald