* [FFmpeg-devel] [PATCH] libavformat/usmdec: add support for HCA stream decryption
@ 2025-06-24 6:19 Pavel Roslyy
2025-06-24 6:25 ` Pavel Roslyy
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Pavel Roslyy @ 2025-06-24 6:19 UTC (permalink / raw)
To: ffmpeg-devel; +Cc: Pavel Roslyy
---
libavformat/usmdec.c | 53 +++++++++++++++++++++++++++++++++++++++++---
1 file changed, 50 insertions(+), 3 deletions(-)
diff --git a/libavformat/usmdec.c b/libavformat/usmdec.c
index fd28e935ce..c5f2e208df 100644
--- a/libavformat/usmdec.c
+++ b/libavformat/usmdec.c
@@ -19,6 +19,7 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#include "libavutil/opt.h"
#include "libavutil/intfloat.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/mem.h"
@@ -47,10 +48,14 @@ typedef struct USMChannel {
} USMChannel;
typedef struct USMDemuxContext {
+ const AVClass *class;
USMChannel ch[4][256];
int nb_channels[4];
uint8_t *header;
unsigned header_size;
+ int64_t hca_keyl;
+ int64_t hca_keyh;
+ int hca_subkey;
} USMDemuxContext;
static int usm_probe(const AVProbeData *p)
@@ -314,6 +319,7 @@ static int64_t parse_chunk(AVFormatContext *s, AVIOContext *pb,
par->sample_rate = ch->rate.num;
par->ch_layout.nb_channels = ch->nb_channels;
st->duration = ch->duration;
+ get_extradata = 1;
break;
}
@@ -323,7 +329,6 @@ static int64_t parse_chunk(AVFormatContext *s, AVIOContext *pb,
avpriv_set_pts_info(st, 64, ch->rate.den, ch->rate.num);
ffstream(st)->need_parsing = AVSTREAM_PARSE_TIMESTAMPS;
- get_extradata = ch->codec_id == AV_CODEC_ID_ADPCM_ADX;
ch->extradata_pos = avio_tell(pb);
}
@@ -333,10 +338,29 @@ static int64_t parse_chunk(AVFormatContext *s, AVIOContext *pb,
pkt_size = chunk_size - (ret - chunk_start) - padding_size;
if (get_extradata) {
- if ((ret = ff_get_extradata(s, st->codecpar, pb, pkt_size)) < 0)
+ AVCodecParameters *par;
+ par = st->codecpar;
+
+ // HCA decoder expects last 10 bytes to contain decryption keys
+ int key_buf = ch->codec_id == AV_CODEC_ID_HCA ? 10 : 0;
+ ret = ff_alloc_extradata(par, pkt_size + key_buf);
+ if (ret < 0)
return ret;
+
+ ret = avio_read(pb, par->extradata, pkt_size);
+ if (ret < pkt_size) {
+ av_freep(&par->extradata);
+ par->extradata_size = 0;
+ return AVERROR(EIO);
+ }
+
+ if (ch->codec_id == AV_CODEC_ID_HCA) {
+ AV_WB32(par->extradata + par->extradata_size - 10, usm->hca_keyh);
+ AV_WB32(par->extradata + par->extradata_size - 6, usm->hca_keyl);
+ AV_WB16(par->extradata + par->extradata_size - 2, usm->hca_subkey);
+ }
} else {
- if (ret == ch->extradata_pos && ch->codec_id == AV_CODEC_ID_ADPCM_ADX) {
+ if (ret == ch->extradata_pos && ch->type == AVMEDIA_TYPE_AUDIO) {
avio_skip(pb, pkt_size);
ret = 0;
} else {
@@ -416,10 +440,33 @@ static int usm_read_close(AVFormatContext *s)
return 0;
}
+#define OFFSET(x) offsetof(USMDemuxContext, x)
+#define FLAGS AV_OPT_FLAG_AUDIO_PARAM | AV_OPT_FLAG_DECODING_PARAM
+static const AVOption usm_options[] = {
+ { "hca_lowkey",
+ "Low key used for handling CRI HCA streams", OFFSET(hca_keyl),
+ AV_OPT_TYPE_INT64, {.i64=0}, .min = 0, .max = UINT32_MAX, .flags = FLAGS, },
+ { "hca_highkey",
+ "High key used for handling CRI HCA streams", OFFSET(hca_keyh),
+ AV_OPT_TYPE_INT64, {.i64=0}, .min = 0, .max = UINT32_MAX, .flags = FLAGS, },
+ { "hca_subkey",
+ "Subkey used for handling CRI HCA streams", OFFSET(hca_subkey),
+ AV_OPT_TYPE_INT, {.i64=0}, .min = 0, .max = UINT16_MAX, .flags = FLAGS },
+ { NULL },
+};
+
+static const AVClass usm_class = {
+ .class_name = "usm",
+ .item_name = av_default_item_name,
+ .option = usm_options,
+ .version = LIBAVUTIL_VERSION_INT,
+};
+
const FFInputFormat ff_usm_demuxer = {
.p.name = "usm",
.p.long_name = NULL_IF_CONFIG_SMALL("CRI USM"),
.p.extensions = "usm",
+ .p.priv_class = &usm_class,
.p.flags = AVFMT_GENERIC_INDEX | AVFMT_NO_BYTE_SEEK | AVFMT_NOBINSEARCH,
.priv_data_size = sizeof(USMDemuxContext),
.read_probe = usm_probe,
--
2.49.0
_______________________________________________
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".
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [FFmpeg-devel] [PATCH] libavformat/usmdec: add support for HCA stream decryption
2025-06-24 6:19 [FFmpeg-devel] [PATCH] libavformat/usmdec: add support for HCA stream decryption Pavel Roslyy
@ 2025-06-24 6:25 ` Pavel Roslyy
2025-06-25 22:12 ` Michael Niedermayer
2025-06-26 0:42 ` Andreas Rheinhardt
2 siblings, 0 replies; 12+ messages in thread
From: Pavel Roslyy @ 2025-06-24 6:25 UTC (permalink / raw)
To: ffmpeg-devel
Hello,
Here's a sample file for testing:
https://streams.videolan.org/ffmpeg/incoming/encrypted-hca_lowkey-3201512.usm
Use -hca_lowkey 3201512 for decryption.
One way to test would be the following command:
ffmpeg -hca_lowkey 3201512 -i encrypted-hca_lowkey-3201512.usm -filter_complex \
"[0:a]amerge=inputs=3[a]" -ac 2 -map 0:v -map "[a]" -c:v copy out.mp4
This file has one video stream and three audio streams (one is silence) and
merging the audio streams is reasonable because a game would normally play
every audio stream at the same time. If instead you want to test in some
other way, free free.
Regards,
Pavel Roslyy
_______________________________________________
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".
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [FFmpeg-devel] [PATCH] libavformat/usmdec: add support for HCA stream decryption
2025-06-24 6:19 [FFmpeg-devel] [PATCH] libavformat/usmdec: add support for HCA stream decryption Pavel Roslyy
2025-06-24 6:25 ` Pavel Roslyy
@ 2025-06-25 22:12 ` Michael Niedermayer
2025-06-25 22:40 ` Michael Niedermayer
2025-06-26 0:42 ` Andreas Rheinhardt
2 siblings, 1 reply; 12+ messages in thread
From: Michael Niedermayer @ 2025-06-25 22:12 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 561 bytes --]
Hi
On Mon, Jun 23, 2025 at 11:19:29PM -0700, Pavel Roslyy wrote:
> ---
> libavformat/usmdec.c | 53 +++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 50 insertions(+), 3 deletions(-)
will apply
please submit a patch adding documentation for both hca / usmdec to doc/
and also add a fate test
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 251 bytes --]
_______________________________________________
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".
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [FFmpeg-devel] [PATCH] libavformat/usmdec: add support for HCA stream decryption
2025-06-25 22:12 ` Michael Niedermayer
@ 2025-06-25 22:40 ` Michael Niedermayer
2025-06-26 7:04 ` Pavel Roslyy
0 siblings, 1 reply; 12+ messages in thread
From: Michael Niedermayer @ 2025-06-25 22:40 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 764 bytes --]
On Thu, Jun 26, 2025 at 12:12:46AM +0200, Michael Niedermayer wrote:
> Hi
>
> On Mon, Jun 23, 2025 at 11:19:29PM -0700, Pavel Roslyy wrote:
> > ---
> > libavformat/usmdec.c | 53 +++++++++++++++++++++++++++++++++++++++++---
> > 1 file changed, 50 insertions(+), 3 deletions(-)
>
> will apply
bug found, not applying yet
ret = ff_alloc_extradata(par, pkt_size + key_buf);
pkt_size + key_buf can overflow i think
also LIBAVFORMAT_VERSION_MICRO could be increased
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 251 bytes --]
_______________________________________________
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".
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [FFmpeg-devel] [PATCH] libavformat/usmdec: add support for HCA stream decryption
2025-06-25 22:40 ` Michael Niedermayer
@ 2025-06-26 7:04 ` Pavel Roslyy
2025-06-26 21:08 ` Michael Niedermayer
0 siblings, 1 reply; 12+ messages in thread
From: Pavel Roslyy @ 2025-06-26 7:04 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Hi Michael,
On Wed, Jun 25, 2025 at 3:13 PM Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> Hi
>
> [...]
>
> please submit a patch adding documentation for both hca / usmdec to doc/
> and also add a fate test
It might take me a few days since I don't know what I'm doing, but I will try.
Regarding the usm sample, I will try to see if I have something smaller.
On Wed, Jun 25, 2025 at 3:40 PM Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> [...]
>
> bug found, not applying yet
>
> ret = ff_alloc_extradata(par, pkt_size + key_buf);
>
> pkt_size + key_buf can overflow i think
If I'm understanding right, I don't think it can.
pkt_size = chunk_size - (ret - chunk_start) - padding_size;
(ret - chunk_start) should be at least 24 at this point, and I don't think
padding_size will be negative so pkt_size is at most UINT32_MAX - 24.
key_buf adds at most 10, which is not enough to overflow.
> also LIBAVFORMAT_VERSION_MICRO could be increased
Understood, will do that in a separate patch or bundled into a v2 of this
patch, whichever needs to happen.
Regards,
Pavel Roslyy
_______________________________________________
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".
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [FFmpeg-devel] [PATCH] libavformat/usmdec: add support for HCA stream decryption
2025-06-26 7:04 ` Pavel Roslyy
@ 2025-06-26 21:08 ` Michael Niedermayer
2025-06-27 19:20 ` Pavel Roslyy
0 siblings, 1 reply; 12+ messages in thread
From: Michael Niedermayer @ 2025-06-26 21:08 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 1194 bytes --]
Hi Pavel
On Thu, Jun 26, 2025 at 12:04:17AM -0700, Pavel Roslyy wrote:
> On Wed, Jun 25, 2025 at 3:40 PM Michael Niedermayer
> <michael@niedermayer.cc> wrote:
> >
> > [...]
> >
> > bug found, not applying yet
> >
> > ret = ff_alloc_extradata(par, pkt_size + key_buf);
> >
> > pkt_size + key_buf can overflow i think
>
> If I'm understanding right, I don't think it can.
> pkt_size = chunk_size - (ret - chunk_start) - padding_size;
>
> (ret - chunk_start) should be at least 24 at this point, and I don't think
> padding_size will be negative so pkt_size is at most UINT32_MAX - 24.
chunk_size is arbitrary 32bit thus pkt_size is arbitrary 32bit
>
> key_buf adds at most 10, which is not enough to overflow.
arbitrary uint32_t + 10 can overflow. Its a defined overflow
but the following allocation is then bad
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1
"Used only once" - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 251 bytes --]
_______________________________________________
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".
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [FFmpeg-devel] [PATCH] libavformat/usmdec: add support for HCA stream decryption
2025-06-26 21:08 ` Michael Niedermayer
@ 2025-06-27 19:20 ` Pavel Roslyy
2025-06-27 21:32 ` Michael Niedermayer
0 siblings, 1 reply; 12+ messages in thread
From: Pavel Roslyy @ 2025-06-27 19:20 UTC (permalink / raw)
To: FFmpeg development discussions and patches
On Thu, Jun 26, 2025 at 2:08 PM Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> Hi Pavel
>
> On Thu, Jun 26, 2025 at 12:04:17AM -0700, Pavel Roslyy wrote:
> > On Wed, Jun 25, 2025 at 3:40 PM Michael Niedermayer
> > <michael@niedermayer.cc> wrote:
> > >
> > > [...]
> > >
> > > bug found, not applying yet
> > >
> > > ret = ff_alloc_extradata(par, pkt_size + key_buf);
> > >
> > > pkt_size + key_buf can overflow i think
> >
> > If I'm understanding right, I don't think it can.
> > pkt_size = chunk_size - (ret - chunk_start) - padding_size;
> >
> > (ret - chunk_start) should be at least 24 at this point, and I don't think
> > padding_size will be negative so pkt_size is at most UINT32_MAX - 24.
>
> chunk_size is arbitrary 32bit thus pkt_size is arbitrary 32bit
>
>
> >
> > key_buf adds at most 10, which is not enough to overflow.
>
> arbitrary uint32_t + 10 can overflow. Its a defined overflow
> but the following allocation is then bad
I think what happens is arbitrary uint32_t - 24 + 10, which cannot overflow
but it looks like I wasn't convincing. I assume you want an overflow check?
if (key_buf > UINT32_MAX - pkt_size)
return AVERROR_INVALIDDATA;
Would this work or do you have a better suggestion?
Regards,
Pavel Roslyy
_______________________________________________
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".
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [FFmpeg-devel] [PATCH] libavformat/usmdec: add support for HCA stream decryption
2025-06-27 19:20 ` Pavel Roslyy
@ 2025-06-27 21:32 ` Michael Niedermayer
2025-07-03 22:28 ` Pavel Roslyy
0 siblings, 1 reply; 12+ messages in thread
From: Michael Niedermayer @ 2025-06-27 21:32 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 1607 bytes --]
On Fri, Jun 27, 2025 at 12:20:11PM -0700, Pavel Roslyy wrote:
> On Thu, Jun 26, 2025 at 2:08 PM Michael Niedermayer
> <michael@niedermayer.cc> wrote:
> >
> > Hi Pavel
> >
> > On Thu, Jun 26, 2025 at 12:04:17AM -0700, Pavel Roslyy wrote:
> > > On Wed, Jun 25, 2025 at 3:40 PM Michael Niedermayer
> > > <michael@niedermayer.cc> wrote:
> > > >
> > > > [...]
> > > >
> > > > bug found, not applying yet
> > > >
> > > > ret = ff_alloc_extradata(par, pkt_size + key_buf);
> > > >
> > > > pkt_size + key_buf can overflow i think
> > >
> > > If I'm understanding right, I don't think it can.
> > > pkt_size = chunk_size - (ret - chunk_start) - padding_size;
> > >
> > > (ret - chunk_start) should be at least 24 at this point, and I don't think
> > > padding_size will be negative so pkt_size is at most UINT32_MAX - 24.
> >
> > chunk_size is arbitrary 32bit thus pkt_size is arbitrary 32bit
> >
> >
> > >
> > > key_buf adds at most 10, which is not enough to overflow.
> >
> > arbitrary uint32_t + 10 can overflow. Its a defined overflow
> > but the following allocation is then bad
>
> I think what happens is arbitrary uint32_t - 24 + 10, which cannot overflow
> but it looks like I wasn't convincing. I assume you want an overflow check?
>
> if (key_buf > UINT32_MAX - pkt_size)
> return AVERROR_INVALIDDATA;
>
> Would this work or do you have a better suggestion?
ok
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Nations do behave wisely once they have exhausted all other alternatives.
-- Abba Eban
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 251 bytes --]
_______________________________________________
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".
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [FFmpeg-devel] [PATCH] libavformat/usmdec: add support for HCA stream decryption
2025-06-27 21:32 ` Michael Niedermayer
@ 2025-07-03 22:28 ` Pavel Roslyy
2025-07-04 1:40 ` Michael Niedermayer
0 siblings, 1 reply; 12+ messages in thread
From: Pavel Roslyy @ 2025-07-03 22:28 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Hello,
After experimenting, I think it would be a better idea to move the hca_*
options into libavcodec/hcadec.c rather than duplicating them into the usm
demuxer. Before I try to submit patches that do this I have some questions.
1) I plan on removing the hca_* options from libavformat/hca.c and placing
them into libavcodec/hcadec.c. Am I correct in assuming that this would be
considered an API deprecation and would require doing deprecation guards in
libavformat/hca.c?
2) If considered an API deprecation, would it make sense to consolidate
hca_lowkey and hca_highkey into a single hca_key option that takes 16 bits of
hexadecimal string (like most other decryption key options) rather than
keeping the options as integer hca_highkey / hca_lowkey in
libavcodec/hcadec.c?
Regards,
Pavel Roslyy
_______________________________________________
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".
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [FFmpeg-devel] [PATCH] libavformat/usmdec: add support for HCA stream decryption
2025-07-03 22:28 ` Pavel Roslyy
@ 2025-07-04 1:40 ` Michael Niedermayer
0 siblings, 0 replies; 12+ messages in thread
From: Michael Niedermayer @ 2025-07-04 1:40 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 1413 bytes --]
Hi
On Thu, Jul 03, 2025 at 03:28:32PM -0700, Pavel Roslyy wrote:
> Hello,
>
> After experimenting, I think it would be a better idea to move the hca_*
> options into libavcodec/hcadec.c rather than duplicating them into the usm
> demuxer. Before I try to submit patches that do this I have some questions.
>
> 1) I plan on removing the hca_* options from libavformat/hca.c and placing
> them into libavcodec/hcadec.c. Am I correct in assuming that this would be
> considered an API deprecation and would require doing deprecation guards in
> libavformat/hca.c?
If it could break a users script (by options disappearing) from a previous
release then it should be put under deprecation guards
>
> 2) If considered an API deprecation, would it make sense to consolidate
> hca_lowkey and hca_highkey into a single hca_key option that takes 16 bits of
> hexadecimal string (like most other decryption key options) rather than
> keeping the options as integer hca_highkey / hca_lowkey in
> libavcodec/hcadec.c?
Thats a question for the people working with and using this feature
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 251 bytes --]
_______________________________________________
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".
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [FFmpeg-devel] [PATCH] libavformat/usmdec: add support for HCA stream decryption
2025-06-24 6:19 [FFmpeg-devel] [PATCH] libavformat/usmdec: add support for HCA stream decryption Pavel Roslyy
2025-06-24 6:25 ` Pavel Roslyy
2025-06-25 22:12 ` Michael Niedermayer
@ 2025-06-26 0:42 ` Andreas Rheinhardt
2025-06-26 7:07 ` Pavel Roslyy
2 siblings, 1 reply; 12+ messages in thread
From: Andreas Rheinhardt @ 2025-06-26 0:42 UTC (permalink / raw)
To: ffmpeg-devel
Pavel Roslyy:
> ---
> libavformat/usmdec.c | 53 +++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 50 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/usmdec.c b/libavformat/usmdec.c
> index fd28e935ce..c5f2e208df 100644
> --- a/libavformat/usmdec.c
> +++ b/libavformat/usmdec.c
> @@ -19,6 +19,7 @@
> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
> */
>
> +#include "libavutil/opt.h"
> #include "libavutil/intfloat.h"
> #include "libavutil/intreadwrite.h"
> #include "libavutil/mem.h"
> @@ -47,10 +48,14 @@ typedef struct USMChannel {
> } USMChannel;
>
> typedef struct USMDemuxContext {
> + const AVClass *class;
> USMChannel ch[4][256];
> int nb_channels[4];
> uint8_t *header;
> unsigned header_size;
> + int64_t hca_keyl;
> + int64_t hca_keyh;
> + int hca_subkey;
> } USMDemuxContext;
>
> static int usm_probe(const AVProbeData *p)
> @@ -314,6 +319,7 @@ static int64_t parse_chunk(AVFormatContext *s, AVIOContext *pb,
> par->sample_rate = ch->rate.num;
> par->ch_layout.nb_channels = ch->nb_channels;
> st->duration = ch->duration;
> + get_extradata = 1;
> break;
> }
>
> @@ -323,7 +329,6 @@ static int64_t parse_chunk(AVFormatContext *s, AVIOContext *pb,
> avpriv_set_pts_info(st, 64, ch->rate.den, ch->rate.num);
>
> ffstream(st)->need_parsing = AVSTREAM_PARSE_TIMESTAMPS;
> - get_extradata = ch->codec_id == AV_CODEC_ID_ADPCM_ADX;
> ch->extradata_pos = avio_tell(pb);
> }
>
> @@ -333,10 +338,29 @@ static int64_t parse_chunk(AVFormatContext *s, AVIOContext *pb,
>
> pkt_size = chunk_size - (ret - chunk_start) - padding_size;
> if (get_extradata) {
> - if ((ret = ff_get_extradata(s, st->codecpar, pb, pkt_size)) < 0)
> + AVCodecParameters *par;
> + par = st->codecpar;
> +
> + // HCA decoder expects last 10 bytes to contain decryption keys
> + int key_buf = ch->codec_id == AV_CODEC_ID_HCA ? 10 : 0;
> + ret = ff_alloc_extradata(par, pkt_size + key_buf);
> + if (ret < 0)
> return ret;
> +
> + ret = avio_read(pb, par->extradata, pkt_size);
> + if (ret < pkt_size) {
> + av_freep(&par->extradata);
> + par->extradata_size = 0;
> + return AVERROR(EIO);
> + }
> +
> + if (ch->codec_id == AV_CODEC_ID_HCA) {
> + AV_WB32(par->extradata + par->extradata_size - 10, usm->hca_keyh);
> + AV_WB32(par->extradata + par->extradata_size - 6, usm->hca_keyl);
> + AV_WB16(par->extradata + par->extradata_size - 2, usm->hca_subkey);
> + }
> } else {
> - if (ret == ch->extradata_pos && ch->codec_id == AV_CODEC_ID_ADPCM_ADX) {
> + if (ret == ch->extradata_pos && ch->type == AVMEDIA_TYPE_AUDIO) {
> avio_skip(pb, pkt_size);
> ret = 0;
> } else {
> @@ -416,10 +440,33 @@ static int usm_read_close(AVFormatContext *s)
> return 0;
> }
>
> +#define OFFSET(x) offsetof(USMDemuxContext, x)
> +#define FLAGS AV_OPT_FLAG_AUDIO_PARAM | AV_OPT_FLAG_DECODING_PARAM
> +static const AVOption usm_options[] = {
> + { "hca_lowkey",
> + "Low key used for handling CRI HCA streams", OFFSET(hca_keyl),
> + AV_OPT_TYPE_INT64, {.i64=0}, .min = 0, .max = UINT32_MAX, .flags = FLAGS, },
> + { "hca_highkey",
> + "High key used for handling CRI HCA streams", OFFSET(hca_keyh),
> + AV_OPT_TYPE_INT64, {.i64=0}, .min = 0, .max = UINT32_MAX, .flags = FLAGS, },
Why are these two options instead of one? The HCA decoder also treats it
as 64bit value.
> + { "hca_subkey",
> + "Subkey used for handling CRI HCA streams", OFFSET(hca_subkey),
> + AV_OPT_TYPE_INT, {.i64=0}, .min = 0, .max = UINT16_MAX, .flags = FLAGS },
> + { NULL },
> +};
> +
> +static const AVClass usm_class = {
> + .class_name = "usm",
> + .item_name = av_default_item_name,
> + .option = usm_options,
> + .version = LIBAVUTIL_VERSION_INT,
> +};
> +
> const FFInputFormat ff_usm_demuxer = {
> .p.name = "usm",
> .p.long_name = NULL_IF_CONFIG_SMALL("CRI USM"),
> .p.extensions = "usm",
> + .p.priv_class = &usm_class,
> .p.flags = AVFMT_GENERIC_INDEX | AVFMT_NO_BYTE_SEEK | AVFMT_NOBINSEARCH,
> .priv_data_size = sizeof(USMDemuxContext),
> .read_probe = usm_probe,
_______________________________________________
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".
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [FFmpeg-devel] [PATCH] libavformat/usmdec: add support for HCA stream decryption
2025-06-26 0:42 ` Andreas Rheinhardt
@ 2025-06-26 7:07 ` Pavel Roslyy
0 siblings, 0 replies; 12+ messages in thread
From: Pavel Roslyy @ 2025-06-26 7:07 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Hi Andreas,
On Wed, Jun 25, 2025 at 5:42 PM Andreas Rheinhardt
<andreas.rheinhardt@outlook.com> wrote:
>
> Pavel Roslyy:
> > [...]
> >
> > +#define OFFSET(x) offsetof(USMDemuxContext, x)
> > +#define FLAGS AV_OPT_FLAG_AUDIO_PARAM | AV_OPT_FLAG_DECODING_PARAM
> > +static const AVOption usm_options[] = {
> > + { "hca_lowkey",
> > + "Low key used for handling CRI HCA streams", OFFSET(hca_keyl),
> > + AV_OPT_TYPE_INT64, {.i64=0}, .min = 0, .max = UINT32_MAX, .flags = FLAGS, },
> > + { "hca_highkey",
> > + "High key used for handling CRI HCA streams", OFFSET(hca_keyh),
> > + AV_OPT_TYPE_INT64, {.i64=0}, .min = 0, .max = UINT32_MAX, .flags = FLAGS, },
>
> Why are these two options instead of one? The HCA decoder also treats it
> as 64bit value.
I copied these options from libavformat/hca.c, and I'm not sure why that file
splits it, but I assume it would be best to keep the options the same across
both demuxers. And since hca.c works I figured it's best not to try to fix
it.
I'm open to any suggestions on the matter.
Regards,
Pavel Roslyy
_______________________________________________
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".
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2025-07-04 1:41 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-06-24 6:19 [FFmpeg-devel] [PATCH] libavformat/usmdec: add support for HCA stream decryption Pavel Roslyy
2025-06-24 6:25 ` Pavel Roslyy
2025-06-25 22:12 ` Michael Niedermayer
2025-06-25 22:40 ` Michael Niedermayer
2025-06-26 7:04 ` Pavel Roslyy
2025-06-26 21:08 ` Michael Niedermayer
2025-06-27 19:20 ` Pavel Roslyy
2025-06-27 21:32 ` Michael Niedermayer
2025-07-03 22:28 ` Pavel Roslyy
2025-07-04 1:40 ` Michael Niedermayer
2025-06-26 0:42 ` Andreas Rheinhardt
2025-06-26 7:07 ` Pavel Roslyy
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