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

[Mark Gaiser <markg85@gmail.com>]

On Wed, Dec 28, 2022 at 3:27 PM Ronald S. Bultje <rsbultje@gmail.com> wrote:

> Hi Mark,
>
> On Tue, Dec 27, 2022 at 5:47 PM Mark Gaiser <markg85@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.

Today this works:
ffplay crypto://encrypted_file -decryption_key $AES_KEY -decryption_iv
$AES_IV

I'm proposing:
ffplay encrypted_file.crypto

The ".crypto" file hides the details that you'd otherwise have to pass
manually.

I am proposing a format for that file and was hoping for constructive
feedback to make sure I develop a format that is OK by the ffmpeg team and
could potentially be accepted when I send it as a PR.
That is the discussion I wanted to have here.
Not needless back and forth in details that "matter to my endgoal" but
don't matter for the feature i'm proposing.

With regards to your AVOption option remark.
What you don't say, but imply by it, is implementing ".crypto" support on a
per-application basis completely outside of ffmpeg.
That's a total 180 turn of what I meant to ask and not the intention at all!
_______________________________________________
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".