From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 4D7C443BDC for ; Wed, 21 Dec 2022 15:45:21 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id CC78F68B82B; Wed, 21 Dec 2022 17:45:18 +0200 (EET) Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 268D5680536 for ; Wed, 21 Dec 2022 17:45:12 +0200 (EET) Received: by mail-ej1-f43.google.com with SMTP id bj12so37669726ejb.13 for ; Wed, 21 Dec 2022 07:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=/Cu0S9hoMIrbvuCCDWI5QXV1Z9MzbahUToDeR0Pttv4=; b=G4mIFvyyA+wjanUEdWSWpufbuB6A7zB5zVxA3cPHdN1mFlyx0uLXPF/iu421afTeWY Mct03KA8JUWC/+4ssDdkBP2CmGZ9tnYWT7DY0VKiXW6nuL58aHm5n/hQr/3V8KiMmAHK mgo0bi72MPPmQmjNZdKYejOqCBGlAdhhQF8DBsBv1ODAV5txTSHMOQ/C0zMUx1/A/Ng3 ZHER36R/+8DGE/IXTnN7toRl6Kdd8BGgOo/i3WqR7tAhJ4QQLVzBCAHPiMtjIfjDoPxC kskIoB3kBsbkqi0CmgiuT4puipQNgZMJM5rGswyZEbbM+ebxKw8HG+pGBxwXYMoINPMb g8Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=/Cu0S9hoMIrbvuCCDWI5QXV1Z9MzbahUToDeR0Pttv4=; b=lHS8ONASOQ1EIIhHl+Lvfg76ZgKTyFiNnABmHC9g63clAKjaiJtTx/yrcuDMtZPN8f k0m284V/pysH2Z9JRDm936ZP8gtLQRp84/0+KQn0h+aCVMzPIFYe8/cYT/BzqbkPsqp8 wG9dqSiVKQwHq0h3D8CIDpiSjYNTOdL0EbqNb/IOgSMLu2vkAIt4q1Gt9C4GWwCyxLJ/ J2p5IhXLiKlgTOThv0ghgmDg+CUxvSCqXHW/pBzrDy7x0ZWVJDBS1DSI5wqyDxW4Utpg bCEHXloemjPsu8bzwHy9PepnUaJRJFhMMiWxD6a2lQkYXNSdbq41a1tSmkFc1ACaff3S yclQ== X-Gm-Message-State: AFqh2kp+6ZRlAR+9O0Zyk63vO0X/25pphtwyA2FaGlW+yNy2v7xDcVLI kdgCzP6XpwhF1rSwKxV5V9388czyp0D8AUuHL2pyjc5+9U44fg== X-Google-Smtp-Source: AMrXdXuxywOSmfKXol6V7rQVy/no6ioOVn9oMHYs3/KgJYoxUhlzBEvC0o3thBq/pvT28/fdu3M1SnC9iv0M0an9PgU= X-Received: by 2002:a17:906:284a:b0:7c0:aff2:9cb8 with SMTP id s10-20020a170906284a00b007c0aff29cb8mr254897ejc.125.1671637511050; Wed, 21 Dec 2022 07:45:11 -0800 (PST) MIME-Version: 1.0 From: Mark Gaiser Date: Wed, 21 Dec 2022 16:44:59 +0100 Message-ID: To: FFmpeg development discussions and patches X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: [FFmpeg-devel] Would a crypto file be acceptable? X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: 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:. 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".