April 2020 - ffmpeg-devel - lists.ffmpeg.org

[PATCH v3] Add support for playing Audible AAXC (.aaxc) files
by Vesselin Bontchev 31 Oct '20

31 Oct '20

From cb25a130797370e2801cecc34740764c6d2d264b Mon Sep 17 00:00:00 2001 From: Vesselin Bontchev <vesselin.bontchev(a)yandex.com> Date: Sat, 1 Jan 2000 09:00:00 +0000 Subject: [PATCH v3] Add support for playing Audible AAXC (.aaxc) files The AAXC container format is the same as the (already supported) Audible AAX format but it uses a different encryption scheme. Note: audible_key and audible_iv values are variable (per file) and are externally fed. It is possible to extend https://github.com/mkb79/Audible to derive the audible_key and audible_key values. Relevant code: def decrypt_voucher(deviceSerialNumber, customerId, deviceType, asin, voucher): buf = (deviceType + deviceSerialNumber + customerId + asin).encode("ascii") digest = hashlib.sha256(buf).digest() key = digest[0:16] iv = digest[16:] # decrypt "voucher" using AES in CBC mode with no padding cipher = AES.new(key, AES.MODE_CBC, iv) plaintext = cipher.decrypt(voucher).rstrip(b"\x00") return json.loads(plaintext) The decrypted "voucher" has the required audible_key and audible_iv values. Signed-off-by: Vesselin Bontchev <vesselin.bontchev(a)yandex.com> --- libavformat/isom.h | 4 ++++ libavformat/mov.c | 42 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 46 insertions(+) diff --git a/libavformat/isom.h b/libavformat/isom.h index 4943b80ccf..6f7de09155 100644 --- a/libavformat/isom.h +++ b/libavformat/isom.h @@ -285,6 +285,10 @@ typedef struct MOVContext { int activation_bytes_size; void *audible_fixed_key; int audible_fixed_key_size; + void *audible_key; + int audible_key_size; + void *audible_iv; + int audible_iv_size; struct AVAES *aes_decrypt; uint8_t *decryption_key; int decryption_key_len; diff --git a/libavformat/mov.c b/libavformat/mov.c index 0c4e468dd4..d31653eb6e 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -1085,6 +1085,39 @@ fail: return ret; } +static int mov_aaxc_crypto(MOVContext *c) +{ + int ret = 0; + + /* verify audible_key */ + if (c->audible_key_size != 16) { + av_log(c->fc, AV_LOG_FATAL, "[aaxc] audible_key value needs to be 16 bytes!\n"); + ret = AVERROR(EINVAL); + goto fail; + } + + /* verify audible_iv */ + if (c->audible_iv_size != 16) { + av_log(c->fc, AV_LOG_FATAL, "[aaxc] audible_iv value needs to be 16 bytes!\n"); + ret = AVERROR(EINVAL); + goto fail; + } + + c->aes_decrypt = av_aes_alloc(); + if (!c->aes_decrypt) { + ret = AVERROR(ENOMEM); + goto fail; + } + + memcpy(c->file_key, c->audible_key, 16); + memcpy(c->file_iv, c->audible_iv, 16); + c->aax_mode = 1; + +fail: + + return ret; +} + // Audible AAX (and AAX+) bytestream decryption static int aax_filter(uint8_t *input, int size, MOVContext *c) { @@ -1133,6 +1166,11 @@ static int mov_read_ftyp(MOVContext *c, AVIOContext *pb, MOVAtom atom) av_dict_set(&c->fc->metadata, "compatible_brands", comp_brands_str, AV_DICT_DONT_STRDUP_VAL); + // Logic for handling Audible's .aaxc files + if (!strcmp(type, "aaxc")) { + mov_aaxc_crypto(c); + } + return 0; } @@ -8073,6 +8111,10 @@ static const AVOption mov_options[] = { AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, .flags = FLAGS }, { "activation_bytes", "Secret bytes for Audible AAX files", OFFSET(activation_bytes), AV_OPT_TYPE_BINARY, .flags = AV_OPT_FLAG_DECODING_PARAM }, + { "audible_key", "AES-128 Key for Audible AAXC files", OFFSET(audible_key), + AV_OPT_TYPE_BINARY, .flags = AV_OPT_FLAG_DECODING_PARAM }, + { "audible_iv", "AES-128 IV for Audible AAXC files", OFFSET(audible_iv), + AV_OPT_TYPE_BINARY, .flags = AV_OPT_FLAG_DECODING_PARAM }, { "audible_fixed_key", // extracted from libAAX_SDK.so and AAXSDKWin.dll files! "Fixed key used for handling Audible AAX files", OFFSET(audible_fixed_key), AV_OPT_TYPE_BINARY, {.str="77214d4b196a87cd520045fd20a51d67"}, -- 2.26.0

2 2

[PATCH 0/5] libdc1394 enhancements
by Forest Crossman 28 Oct '20

28 Oct '20

I was having trouble with libdc1394 the first time I used it (e.g., setting unsupported video modes/framerates on cameras, trying to use multiple cameras, tring to figure out how to set the arguments so the command would actually work, etc.) so I thought I'd go ahead and add some ease-of-use enhancements to to the module and some examples to the documentation to help others get started. I also wound up finding a bug with some early PTS wrapping, and I guess some encoders masked the issue because when I tried dumping the raw video to an MKV file the matroska encoder complained _very loudly_ about the non-monotonic PTS/DTS values. I had some trouble determining the best way to write the mode/framerate support checks and how to present the information to the user (errors are obvious, but I didn't know when would be a good time to list the supported modes and how best to print them), so if anyone has any suggestions on how to make that more "elegant" I'd be happy to hear them! I also had some trouble with the camera GUID:unit parsing--it works, but if the input is slightly incorrect the parsing will fail in strange ways. It will also successfully parse incorrect specifiers like 0xabcdef001122334455.0 (the period should be a colon) and 0x0xabcdef001122334455 (there's an extra "0x" prefix) and I'd really prefer it if it would error out and alert the user instead of fail-succeeding silently, but I'm not very well versed in C's string parsing so I'm not sure how I can improve that without significantly increasing the code complexity. Forest Crossman (5): libdc1394: Enable listing sources libdc1394: Verify the camera supports the selected mode and framerate libdc1394: Enable specifying a camera by GUID[:unit] doc/indevs: Add examples for libdc1394 libdc1394: Fix PTS wrapping doc/indevs.texi | 54 ++++++++++ libavdevice/libdc1394.c | 217 ++++++++++++++++++++++++++++++++++------ 2 files changed, 240 insertions(+), 31 deletions(-) -- 2.23.0

3 20

[inline assembly compliance] Issues and patches
by FRÉDÉRIC RECOULES 20 Oct '20

20 Oct '20

Dear developpers, we are academic researchers working in automated program analysis. We are currently interested in checking compliance of inline asm chunks as found in C programs. While benchmarking our tool and technique, we found a number of issues in FFMPEG. We report them to you, as well as adequate patches. Actually, we found 59 significant compliance issues in your code. We join 3 patches for some of them, together with explanations and we can send you other patches on demand. * All these bugs are related to compliance between the block of asm and its surrounding "contract" (in gcc-style notation). They are akin to undefined or implementation-defined behaviours in C: they currently do not manifest themselves in your program, but at some point in time with compiler optimizations becoming more and more aggressive or changes in undocumented compiler choices regarding asm chunks, they can suddenly trigger a (hard-to-find) bug. * The typical problems come from the compiler missing dataflow information and performing undue optimizations on this wrong basis, or the compiler allocating an already used register. Actually, we demonstrate "in lab" problems with all these categories of bugs in case of inlining (especially with LTO enabler) or code refactoring. * Some of those issues may seems benign or irrealistic but it cost nothing to patch so, why not do it? We would be very interested to hear your opinion on these matters. Are you interested in such errors and patches? Also, besides the patches, we are currently working on a code analyzer prototype designed to check asm compliance and to propose patches when the chunk is not compliant. This is still work in progress and we are finalizing it. The errors and patches I reported to you came from my prototype. In case such a prototype would be made available, would you consider using it? Best regards Frédéric Recoules

4 8

[PATCH] avfilter: add vf_overlay_cuda
by Yaroslav Pogrebnyak 19 Oct '20

19 Oct '20

This patch adds 'vf_overlay_cuda' filter. It draws one picture on top of another on CUDA GPU. For the end-user, it's similar to 'vf_overlay_opencl' and other overlay filters. This filter would be especially useful for building video processing pipelines that execute fully on the CUDA GPU. For example, the following pipeline would be possible: decode -> scale -> overlay -> encode, without copying frames between CPU and GPU in between. Technical details. Supported sw input formats are NV12 and YUV420P for main input, and NV12, YUV420P and YUVA420P for overlay input. Main and overlay sw formats should match (i.e, overlaying YUVA420P on NV12 is not implemented). All pixel format conversions are needed to be done with 'format' or 'scale_npp' filters before 'overlay_cuda'. It was needed to slightly modify 'hwcontext_cuda.c' to allow overlays with alpha channel: - Allow AV_PIX_FMT_YUVA420P to enable hwuploading frames with alpha channel to GPU. - Do not shift Height of 4rd plane (alpha) when uploading to GPU. Examples. - Overlay picture on top of video (main: YUVJ420P->NV12, overlay: NV12) $ ffmpeg -y -init_hw_device cuda=cuda -filter_hw_device cuda -hwaccel cuvid \ -c:v h264_cuvid -i main.mp4 \ -i ~/overlay.jpg \ -filter_complex "[1:v]format=nv12, hwupload[overlay], [0:v][overlay]overlay_cuda=x=0:y=0:shortest=false" \ -an -c:v h264_nvenc -b:v 5M output.mp4 - Overlay one video on top of another (main: NV12, overlay: NV12) $ ffmpeg -y \ -hwaccel cuvid -c:v h264_cuvid -i main.mp4 \ -hwaccel cuvid -c:v h264_cuvid -i overlay.mp4 \ -filter_complex "[1:v]scale_npp=512:-1[o], [v:0][o]overlay_cuda=x=100:y=100:shortest=true" \ -an -c:v h264_nvenc -b:v 5M output.mp4 - Overlay picture with alpha channel on top of video (main: NV12->YUV420P, overlay: RGBA->YUVA420P) $ ffmpeg -y \ -init_hw_device cuda=cuda -filter_hw_device cuda -hwaccel cuvid \ -c:v h264_cuvid -i ~/main.mp4 \ -i ~/overlay.png \ -filter_complex "[1:v]format=yuva420p, hwupload[o], [v:0]scale_npp=format=yuv420p[m], [m][o]overlay_cuda=x=0:y=0:shortest=false" \ -an -c:v h264_nvenc -b:v 5M output.mp4 Patch attached. P.S. This is my first patch, I would be grateful for any feedback to know if I'm doing things correctly or not. Thanks! Signed-off-by: Yaroslav Pogrebnyak <yyyaroslav(a)gmail.com> --- configure | 2 + libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_overlay_cuda.c | 451 +++++++++++++++++++++++++++++++++ libavfilter/vf_overlay_cuda.cu | 54 ++++ libavutil/hwcontext_cuda.c | 3 +- 6 files changed, 511 insertions(+), 1 deletion(-) create mode 100644 libavfilter/vf_overlay_cuda.c create mode 100644 libavfilter/vf_overlay_cuda.cu

6 14

[PATCH v3] libavcodec/vp8dec: fix the multi-thread HWAccel decode error
by Shaofei Wang 23 Sep '20

23 Sep '20

Fix the issue: https://github.com/intel/media-driver/issues/317 the root cause is update_dimensions will be called multple times when decoder thread number is not only 1, but update_dimensions call get_pixel_format in each decode thread will trigger the hwaccel_uninit/hwaccel_init more than once. But only one hwaccel should be shared with all decode threads. in current context, there are 3 situations in the update_dimensions(): 1. First time calling. No matter single thread or multithread, get_pixel_format() should be called after dimensions were set; 2. Dimention changed at the runtime. Dimention need to be updated when macroblocks_base is already allocated, get_pixel_format() should be called to recreate new frames according to updated dimension; 3. Multithread first time calling. After decoder init, the other threads will call update_dimensions() at first time to allocate macroblocks_base and set dimensions. But get_pixel_format() is shouldn't be called due to low level frames and context are already created. In this fix, we only call update_dimensions as need. Signed-off-by: Wang, Shaofei <shaofei.wang(a)intel.com> Reviewed-by: Jun, Zhao <jun.zhao(a)intel.com> Reviewed-by: Haihao Xiang <haihao.xiang(a)intel.com> --- Updated typo in the commit message libavcodec/vp8.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c index ba79e5f..0a7f38b 100644 --- a/libavcodec/vp8.c +++ b/libavcodec/vp8.c @@ -187,7 +187,7 @@ static av_always_inline int update_dimensions(VP8Context *s, int width, int height, int is_vp7) { AVCodecContext *avctx = s->avctx; - int i, ret; + int i, ret, dim_reset = 0; if (width != s->avctx->width || ((width+15)/16 != s->mb_width || (height+15)/16 != s->mb_height) && s->macroblocks_base || height != s->avctx->height) { @@ -196,9 +196,12 @@ int update_dimensions(VP8Context *s, int width, int height, int is_vp7) ret = ff_set_dimensions(s->avctx, width, height); if (ret < 0) return ret; + + dim_reset = (s->macroblocks_base != NULL); } - if (!s->actually_webp && !is_vp7) { + if ((s->pix_fmt == AV_PIX_FMT_NONE || dim_reset) && + !s->actually_webp && !is_vp7) { s->pix_fmt = get_pixel_format(s); if (s->pix_fmt < 0) return AVERROR(EINVAL); -- 1.8.3.1

6 8

[PATCH] lavc/vaapi_encode_h265: fix max_transform_hierarchy_depth_inter/intra
by Linjie Fu 14 Sep '20

14 Sep '20

Set the max_transform_hierarchy_depth_inter/intra to 2 by default based on the Programmer's Reference Manuals (PRM) in [1]. Intel Encoder only supports 2 levels of quad-tree. That is: - max_transform_hierarchy_depth_inter/intra <= 2. [1] <https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-kbl-vol…> Signed-off-by: Linjie Fu <linjie.fu(a)intel.com> --- Fixed value for intel platform, makes more sense on TGL+ platform. (If conflict with other driver capability, we may add query support later) libavcodec/vaapi_encode_h265.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c index cd48545..d6cb82a 100644 --- a/libavcodec/vaapi_encode_h265.c +++ b/libavcodec/vaapi_encode_h265.c @@ -445,8 +445,9 @@ static int vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx) sps->log2_min_luma_transform_block_size_minus2 = 0; sps->log2_diff_max_min_luma_transform_block_size = 3; // Full transform hierarchy allowed (2-5). - sps->max_transform_hierarchy_depth_inter = 3; - sps->max_transform_hierarchy_depth_intra = 3; + // Default to 2 based on Programmer's Reference Manuals of Intel graphics + sps->max_transform_hierarchy_depth_inter = 2; + sps->max_transform_hierarchy_depth_intra = 2; // AMP works. sps->amp_enabled_flag = 1; // SAO and temporal MVP do not work. -- 2.7.4

5 5

[PATCH]lavf/img2dec: Autodetect Photo CD images
by Carl Eugen Hoyos 05 Sep '20

05 Sep '20

Hi! Attached patch depends on Paul's PhotoCD decoder. Please comment, Carl Eugen

1 1

[PATCH 1/9] avcodec/videotoolboxenc: remove spurious warning
by Aman Gupta 04 Sep '20

04 Sep '20

From: Aman Gupta <aman(a)tmm1.net> --- libavcodec/videotoolboxenc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c index eba6cc672f..a7bef72da8 100644 --- a/libavcodec/videotoolboxenc.c +++ b/libavcodec/videotoolboxenc.c @@ -1853,8 +1853,6 @@ static int get_cv_pixel_info( "Color range not set for %s. Using MPEG range.\n", av_get_pix_fmt_name(av_format)); } - - av_log(avctx, AV_LOG_WARNING, ""); } switch (av_format) { -- 2.13.5 (Apple Git-94)

5 16

[PATCH] fate: remove "-v 0" from ffprobe tests.
by Nicolas George 24 Aug '20

24 Aug '20

The FATE scripts separate stdout from stderr. Having a first idea about what went wrong in the log file is more convenient. Signed-off-by: Nicolas George <george(a)nsup.org> --- tests/fate-run.sh | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/tests/fate-run.sh b/tests/fate-run.sh index 3d58080..4b31b62 100755 --- a/tests/fate-run.sh +++ b/tests/fate-run.sh @@ -84,7 +84,7 @@ runecho(){ } probefmt(){ - run ffprobe${PROGSUF} -show_entries format=format_name -print_format default=nw=1:nk=1 -v 0 "$@" + run ffprobe${PROGSUF} -show_entries format=format_name -print_format default=nw=1:nk=1 "$@" } runlocal(){ @@ -93,24 +93,24 @@ runlocal(){ } probeframes(){ - run ffprobe${PROGSUF} -show_frames -v 0 "$@" + run ffprobe${PROGSUF} -show_frames "$@" } probechapters(){ - run ffprobe${PROGSUF} -show_chapters -v 0 "$@" + run ffprobe${PROGSUF} -show_chapters "$@" } probegaplessinfo(){ filename="$1" shift - run ffprobe${PROGSUF} -bitexact -select_streams a -show_entries format=start_time,duration:stream=index,start_pts,duration_ts -v 0 "$filename" "$@" + run ffprobe${PROGSUF} -bitexact -select_streams a -show_entries format=start_time,duration:stream=index,start_pts,duration_ts "$filename" "$@" pktfile1="${outdir}/${test}.pkts" framefile1="${outdir}/${test}.frames" cleanfiles="$cleanfiles $pktfile1 $framefile1" - run ffprobe${PROGSUF} -bitexact -select_streams a -of compact -count_packets -show_entries packet=pts,dts,duration:stream=nb_read_packets -v 0 "$filename" "$@" > "$pktfile1" + run ffprobe${PROGSUF} -bitexact -select_streams a -of compact -count_packets -show_entries packet=pts,dts,duration:stream=nb_read_packets "$filename" "$@" > "$pktfile1" head -n 8 "$pktfile1" tail -n 9 "$pktfile1" - run ffprobe${PROGSUF} -bitexact -select_streams a -of compact -count_frames -show_entries frame=pkt_pts,pkt_dts,best_effort_timestamp,pkt_duration,nb_samples:stream=nb_read_frames -v 0 "$filename" "$@" > "$framefile1" + run ffprobe${PROGSUF} -bitexact -select_streams a -of compact -count_frames -show_entries frame=pkt_pts,pkt_dts,best_effort_timestamp,pkt_duration,nb_samples:stream=nb_read_frames "$filename" "$@" > "$framefile1" head -n 8 "$framefile1" tail -n 9 "$framefile1" } @@ -306,10 +306,10 @@ concat(){ awk "{gsub(/%SRCFILE%/, \"$sample\"); print}" $template > $concatfile if [ "$mode" = "md5" ]; then - run ffprobe${PROGSUF} -bitexact -show_streams -show_packets -v 0 -fflags keepside -safe 0 $extra_args $concatfile | tr -d '\r' > $packetfile + run ffprobe${PROGSUF} -bitexact -show_streams -show_packets -fflags keepside -safe 0 $extra_args $concatfile | tr -d '\r' > $packetfile do_md5sum $packetfile else - run ffprobe${PROGSUF} -bitexact -show_streams -show_packets -v 0 -of compact=p=0:nk=1 -fflags keepside -safe 0 $extra_args $concatfile + run ffprobe${PROGSUF} -bitexact -show_streams -show_packets -of compact=p=0:nk=1 -fflags keepside -safe 0 $extra_args $concatfile fi } -- 2.8.1

2 4

[PATCH] avformat/movenc: write the colr atom by default
by Michael Bradshaw 21 Aug '20

21 Aug '20

The write_colr flag has been marked as experimental for over 5 years. I propose we do the following (as implemented by the attached patch): - Write the colr atom by default for mp4/mov if any of the following: - The primaries/trc/matrix are all specified, OR - There is an ICC profile, OR - The user specified +write_colr - Remove the experimental notice from the write_colr flag. - Keep the write_colr flag for situations where the user wants to write the colr atom even if the color info is unspecified (e.g., http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259334.html) This fixes https://trac.ffmpeg.org/ticket/7961 Please review. --Michael

3 7