From: Mark Gaiser <markg85@gmail.com> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: [FFmpeg-devel] Would a crypto file be acceptable? Date: Wed, 21 Dec 2022 16:44:59 +0100 Message-ID: <CAPd6JnHEYqvDDy3b31ow4DCS8DiQ4U9ei7==3DL-9kEXum2sWw@mail.gmail.com> (raw) Hi, The ffmpeg crypto protocol handler [1] allows one to play encrypted media. The great thing here is that it allows playback of any media format that ffmpeg supports! Have a container format like mkv as an encrypted blob, no problem for the crypto plugin! I'm explicitly mentioning mkv (though there's many more) here because that isn't possible in HLS/MPD. While those streaming formats handle encryption too, they are very limited in terms of supported codecs and containers. Playback of encrypted data works like this: ffplay encrypted_file -decryption_key $AES_KEY -decryption_iv $AES_IV While this works just fine, it's limited in use because the cryptography details have to be passed on the command line. Applications that might well support much of ffmpeg functionality can't easily hook into the crypto functionality. Take KODI for example, it allows playback of many of the formats ffmpeg supports but anything with crypto just isn't possible. In fact, anything that requires custom command line arguments isn't possible. [2] My idea is to make a new file format that would be implemented and specced within [1]. My proposed format would be: --- CRYPTO-VERSION:1 CRYPTO-KEY:URI:..... CRYPTO-IV:URI:..... encrypted_file --- The URI would be a format type identifier where you can choose between URI (to pass a URL to a key blob), BASE64URL (key encoded as base64url) or HEX. The above proposed format should be stored in a file with ".crypto" as extension. The crypto plugin [1] would then handle that file. The arguments would be filled based on the "properties" in the file. So for example the `decryption_key` argument would be populated with the blob returned from CRYPTO-KEY:URI:<url>. Or with one of the other types. The "encrypted_file" would just be passed through ffmpeg's "ffurl_open_whitelist" like the crypto plugin currently does. Meaning that the file could be anything ffmpeg supports. Playing encrypted media would be as simple as: ffplay file.crypto With this mail I'm looking for a confirmation if the above concept would be allowed as a patch for ffmpeg? And if not, how can I achieve the same results in a way that would be acceptable? [3] Best regards, Mark Gaiser [1] https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/crypto.c [2] there are plugins to make it possible but then you have the extra requirement of a plugin []3 No, not HLS/MPD! They serve a different purpose. Extending them to serve my purpose is a lost goal to begin with so let's not even go there. _______________________________________________ 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".
next reply other threads:[~2022-12-21 15:45 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-12-21 15:44 Mark Gaiser [this message] 2022-12-21 16:00 ` Mark Gaiser 2022-12-22 19:14 ` Gregor Riepl 2022-12-23 1:26 ` Mark Gaiser 2022-12-23 17:45 ` Gregor Riepl 2022-12-22 10:40 ` Nicolas George 2022-12-22 15:53 ` Mark Gaiser 2022-12-22 17:50 ` Hendrik Leppkes 2022-12-23 11:04 ` Tomas Härdin 2022-12-23 16:31 ` Mark Gaiser 2022-12-23 16:33 ` Nicolas George 2022-12-23 17:00 ` Mark Gaiser 2022-12-23 17:38 ` Nicolas George 2022-12-26 10:58 ` Tomas Härdin 2022-12-26 11:00 ` Nicolas George 2022-12-26 11:18 ` Tomas Härdin 2022-12-26 11:24 ` Nicolas George 2022-12-27 18:24 ` Mark Gaiser 2022-12-27 21:40 ` Michael Niedermayer 2022-12-27 22:46 ` Mark Gaiser 2022-12-28 14:27 ` Ronald S. Bultje 2022-12-28 16:13 ` Mark Gaiser 2022-12-28 16:22 ` Nicolas George 2022-12-28 16:27 ` Mark Gaiser 2022-12-28 16:30 ` Nicolas George 2022-12-28 16:58 ` Mark Gaiser 2022-12-29 14:04 ` Ronald S. Bultje 2022-12-28 21:02 ` Michael Niedermayer 2022-12-29 14:51 ` Mark Gaiser 2022-12-29 22:34 ` Michael Niedermayer
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='CAPd6JnHEYqvDDy3b31ow4DCS8DiQ4U9ei7==3DL-9kEXum2sWw@mail.gmail.com' \ --to=markg85@gmail.com \ --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