Hi, On Wed, Dec 28, 2022 at 11:14 AM Mark Gaiser <mark...@gmail.com> wrote:
> On Wed, Dec 28, 2022 at 3:27 PM Ronald S. Bultje <rsbul...@gmail.com> > wrote: > > > Hi Mark, > > > > On Tue, Dec 27, 2022 at 5:47 PM Mark Gaiser <mark...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
