September 2022 - FFmpeg-trac - lists.ffmpeg.org

#9913(ffmpeg:new): HLS m3u8 segments are not URL encoded
by FFmpeg 08 Sep '22

08 Sep '22

#9913: HLS m3u8 segments are not URL encoded -------------------------------------+------------------------------------- Reporter: dbenesj | Type: defect Status: new | Priority: normal Component: ffmpeg | Version: git- Keywords: HLS hls | master m3u8 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- When HLS m3u8 playlist is generated with file name that contains % in it's name, segments in resulting m3u8 file are not URL encoded. As I understood the specification of m3u8 file, it needs to be URI and that means it needs to be URL encoded: * https://datatracker.ietf.org/doc/html/rfc8216#section-3 first paragraph * https://datatracker.ietf.org/doc/html/draft-pantos-hls- rfc8216bis#section-3 first paragraph When trying to use generated m3u8 file (without URL encoded segment URIs) it can't be played at least in VLC and video.js. When content of the m3u8 file is manualy changed to URL encode percent sign, it can be played by both mentioned players. The segment line as it is generated by the ffmpeg: {{{ list%20of%5Brec%5Dobjects0.ts }}} The segmeng line how it work in players (manual modification): {{{ list%2520of%255Brec%255Dobjects0.ts }}} How to reproduce: {{{ % ffmpeg -i "list%20of%5Brec%5Dobjects.mp4" -f hls -codec:v copy "list%20of%5Brec%5Dobjects.m3u8" ffmpeg version 5.1.1-essentials_build-www.gyan.dev Copyright (c) 2000-2022 the FFmpeg developers built with gcc 12.1.0 (Rev2, Built by MSYS2 project) }}} {{{ % ffmpeg -i "list%20of%5Brec%5Dobjects.mp4" -f hls -codec:v copy "list%20of%5Brec%5Dobjects.m3u8" ffmpeg version 2022-09-05-git-2ed5925e26-essentials_build-www.gyan.dev Copyright (c) 2000-2022 the FFmpeg developers built with gcc 12.1.0 (Rev2, Built by MSYS2 project) }}} {{{ % ffmpeg -i "list%20of%5Brec%5Dobjects.mp4" -f hls -codec:v copy "list%20of%5Brec%5Dobjects.m3u8" ffmpeg version 4.3.1 Copyright (c) 2000-2020 the FFmpeg developers built with gcc 10.2.1 (GCC) 20200726 }}} It behaves the same with version 5.1.1, build from current (2022-09-05) master and 4.3.1 -- Ticket URL: <https://trac.ffmpeg.org/ticket/9913> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

#9910(undetermined:new): suggestion for faster accurate trimming
by FFmpeg 07 Sep '22

07 Sep '22

#9910: suggestion for faster accurate trimming -------------------------------------+------------------------------------- Reporter: Jozef | Type: Chutka | enhancement Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: Trim | Blocked By: performance | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- While working with various options to trim video accurately (using `-ss`, `trim`, `select`), I believe to have discovered 2 step process which executes faster then a single step. Please consider if my findings can be incorporated into the `trim` or another filter. Lets have some (300 sec) long video with 10s keyframe interval (600 / 60), to demonstrate both trim accuracy and performance: ``` ffmpeg -filter_complex "smptehdbars=size=1920x1080:rate=60,drawtext=fontfile=c\\:/Windows/Fonts/arial.ttf:timecode=00\\:00\\:00.00:rate=60:fontsize=300:fontcolor=white:x=(w-tw)/2:y=10*h/100:box=1:boxcolor=0x00000000@1" -t 300 -c:v libx264 -x264-params keyint=600 -preset ultrafast -y source.mkv ``` Lets cut this video accurately at time 282 (4:42) to 293 (4:53) so neither of the time points is keyframe: ``` ffmpeg -i source.mkv -ss 282 -to 293 -c:v libx264 -preset ultrafast -y out1.mkv // takes 14.8 sec to complete ``` ``` ffmpeg -i source.mkv -vf trim=start=282:end=293 -c:v libx264 -preset ultrafast -y out2.mkv // takes 14.7 sec to complete ``` ``` ffmpeg -i source.mkv -vf "select=between(t\,282\,293)" -c:v libx264 -preset ultrafast -y out3.mkv // takes 15.1 sec to complete ``` Now here is the two step much faster accurate trim, in first step lets create inaccurate intermediate file, and fix the accurancy in the second step: ``` ffmpeg -ss 282 -to 293 -i source.mkv -output_ts_offset 282 -c:v copy -y out4-tmp.mkv ffmpeg -filter_complex "movie=out4-tmp.mkv,select=gte(t\,282)*lt(t\,293),setpts=PTS-STARTPTS" -c:v libx264 -preset ultrafast -y out4.mkv // takes 0 + 2.4 sec to complete ``` I believe the internal seeking within `trim` and `select` filters is much slower then the one used by `-ss (before `-i`)`. If the video is fast- seeked in first step, even though inaccurately, it can be fixed in the second step. The trick is `-output_ts_offset` argument in first step and `select` filter in the second. Both, out1.mkv and out4.mkv have same size and binary comparision seems almost perfect match. Although the first took 14.8 sec to complete, second one just 2.4. This process works ok with mkv and mp4 formats. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9910> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

#9894(undetermined:new): signal 11 (SIGSEGV), code 2 (SEGV_ACCERR) crash on Android 12 arm64 devices
by FFmpeg 07 Sep '22

07 Sep '22

#9894: signal 11 (SIGSEGV), code 2 (SEGV_ACCERR) crash on Android 12 arm64 devices -------------------------------------+------------------------------------- Reporter: Taner Sener | Type: defect Status: new | Priority: normal Component: | Version: git- undetermined | master Keywords: x264 | Blocked By: android arm64 | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- `ffmpeg` cross-compiled with `x264` for `Android arm64` architecture crashes when it is run on `Android 12 (Api Level 31)` devices. Don't know if it happens because of an invalid compile flag, setting, etc. Here is what we learned during our tests: - This case doesn't occur if `x264` is built without `asm`. - Command used to reproduce the crash uses `792x1568` dimensions. Not all dimensions cause a crash. `792x1568` is one of the dimension that does. - Older Android devices or emulators e.g. `Android 11 (Api Level 30)` doesn't have this issue. Android 11 have some new changes regarding `ARM Memory Tagging Extension (MTE)`. Maybe those changes are triggering it. See [Tagged Pointers](https://source.android.com/docs/security/test /tagged-pointers) for those changes. This is the `ffmpeg` command used to reproduce this case. `ffmpeg -v 9 -loglevel 99 -loop 1 -i pyramid.jpg -vf scale=792x1568 -c:v libx264 video.mp4` Full console output is available at [console- output.txt](https://github.com/tanersener/android-ffmpeg-x264-arm64-api- level-31/blob/main/console-output.txt) file. Below you can see the report generated. ``` Build fingerprint: 'google/sdk_gphone64_arm64/emulator64_arm64:12/SE1A.220630.001/8789670:userdebug /dev-keys' Revision: '0' ABI: 'arm64' Timestamp: 2022-08-28 11:31:51.574993028+0100 Process uptime: 1s Cmdline: ./ffmpeg -v 9 -loglevel 99 -loop 1 -i pyramid.jpg -vf scale=792x1568 -c:v libx264 video.mp4 pid: 31986, tid: 31986, name: ffmpeg >>> ./ffmpeg <<< uid: 0 tagged_addr_ctrl: 0000000000000001 signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xb400007a2a46b000 x0 b400007b5d718960 x1 b400007a2a420cd0 x2 b400007a2a425904 x3 b400007a2a433ee4 x4 b400007a2a46aff4 x5 0000007fc9bbd8ec x6 00000000fffffffa x7 0000000000000032 x8 b400007a2a4232b0 x9 b400007a2a4689b0 x10 0000007cdd03e738 x11 00000000000025e4 x12 0000000000008000 x13 0000000000000031 x14 0000000000000061 x15 0000000000007fff x16 b400007a2a433e74 x17 b400007a2a3ff3a8 x18 0000007cee20c000 x19 0000000000000027 x20 0000007fc9bbeb28 x21 0000000000000027 x22 00000000000012f2 x23 b400007ced0d6dd0 x24 b400007a2a431890 x25 b400007a2aa45c60 x26 b400007a2a433e74 x27 b400007b5d718900 x28 b400007a2a420c60 x29 0000007fc9bbd8f0 lr 0000007cdcffad9c sp 0000007fc9bbd8a0 pc 0000007cdd03e74c pst 0000000080001000 backtrace: #00 pc 000000000060c74c /data/local/tmp/org.ffmpeg.test/libavcodec.so (x264_8_mbtree_propagate_cost_neon+20) #01 pc 00000000005c8d98 /data/local/tmp/org.ffmpeg.test/libavcodec.so (macroblock_tree_propagate+540) #02 pc 00000000005bd9b4 /data/local/tmp/org.ffmpeg.test/libavcodec.so (macroblock_tree+856) #03 pc 00000000005bcef0 /data/local/tmp/org.ffmpeg.test/libavcodec.so (x264_8_slicetype_analyse+2844) #04 pc 000000000060f4c4 /data/local/tmp/org.ffmpeg.test/libavcodec.so (x264_8_lookahead_get_frames+264) #05 pc 00000000005962ac /data/local/tmp/org.ffmpeg.test/libavcodec.so (x264_8_encoder_encode+896) #06 pc 0000000000592360 /data/local/tmp/org.ffmpeg.test/libavcodec.so (x264_encoder_encode+16) #07 pc 000000000058c714 /data/local/tmp/org.ffmpeg.test/libavcodec.so (X264_frame+1272) #08 pc 00000000004838b8 /data/local/tmp/org.ffmpeg.test/libavcodec.so (ff_encode_encode_cb+36) #09 pc 0000000000483db0 /data/local/tmp/org.ffmpeg.test/libavcodec.so (encode_receive_packet_internal+340) #10 pc 0000000000483c10 /data/local/tmp/org.ffmpeg.test/libavcodec.so (avcodec_send_frame+516) #11 pc 0000000000035f14 /data/local/tmp/org.ffmpeg.test/ffmpeg (encode_frame+252) #12 pc 0000000000035950 /data/local/tmp/org.ffmpeg.test/ffmpeg (do_video_out+1840) #13 pc 0000000000034eec /data/local/tmp/org.ffmpeg.test/ffmpeg (reap_filters+280) #14 pc 000000000003129c /data/local/tmp/org.ffmpeg.test/ffmpeg (main+7160) #15 pc 00000000000488c8 /apex/com.android.runtime/lib64/bionic/libc.so (__libc_init+96) (BuildId: ba489d4985c0cf173209da67405662f9) ``` Steps we used to build and run `ffmpeg` and `x264` can be found under the [android-ffmpeg-x264-arm64-api-level-31](https://github.com/tanersener /android-ffmpeg-x264-arm64-api-level-31) repository. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9894> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 13

#9907(ffmpeg:new): Unicode accented o crashes ffmpeg with concat
by FFmpeg 06 Sep '22

06 Sep '22

#9907: Unicode accented o crashes ffmpeg with concat -------------------------------------+------------------------------------- Reporter: steven | Type: defect bensky | Status: new | Priority: normal Component: ffmpeg | Version: git- | master Keywords: concat | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: Accented ó character when used with 'concat' crashes ffmpeg. How to reproduce: create 2 files (contents are immaterial, can be empty): Tóp - Part 1.mp4 Tóp - Part 2.mp4 create a file, CONCAT3.TXT containing: file 'Tóp - Part 1.mp4' file 'Tóp - Part 2.mp4' run the command: ffmpeg -f concat -safe 0 -i CONCAT3.TXT -c copy "out.Tóp_CONCAT.mp4" ------- ffmpeg.exe from, https://github.com/GyanD/codexffmpeg/releases/tag/2022-09-05-git- 2ed5925e26 Win7 x64 -report: ffmpeg started on 2022-09-06 at 11:02:31 Report written to "ffmpeg-20220906-110231.log" Log level: 48 Command line: ffmpeg -report -f concat -safe 0 -i CONCAT3.TXT -c copy "out.T\xf3p_CONCAT.mp4" ffmpeg version 2022-09-05-git-2ed5925e26-full_build-www.gyan.dev Copyright (c) 2000-2022 the FFmpeg developers built with gcc 12.1.0 (Rev2, Built by MSYS2 project) configuration: --enable-gpl --enable-version3 --enable-static --disable- w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libaom --enable-libjxl --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-liblensfun --enable- libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda- llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libshaderc --enable-vulkan --enable-libplacebo --ena libavutil 57. 36.101 / 57. 36.101 libavcodec 59. 42.104 / 59. 42.104 libavformat 59. 30.100 / 59. 30.100 libavdevice 59. 8.101 / 59. 8.101 libavfilter 8. 48.100 / 8. 48.100 libswscale 6. 8.104 / 6. 8.104 libswresample 4. 9.100 / 4. 9.100 libpostproc 56. 7.100 / 56. 7.100 Splitting the commandline. Reading option '-report' ... matched as option 'report' (generate a report) with argument '1'. Reading option '-f' ... matched as option 'f' (force format) with argument 'concat'. Reading option '-safe' ... matched as AVOption 'safe' with argument '0'. Reading option '-i' ... matched as input url with argument 'CONCAT3.TXT'. Reading option '-c' ... matched as option 'c' (codec name) with argument 'copy'. Reading option 'out.TÃ³p_CONCAT.mp4' ... matched as output url. Finished splitting the commandline. Parsing a group of options: global . Applying option report (generate a report) with argument 1. Successfully parsed a group of options. Parsing a group of options: input url CONCAT3.TXT. Applying option f (force format) with argument concat. Successfully parsed a group of options. Opening an input file: CONCAT3.TXT. [concat @ 00000000003d8f80] Opening 'CONCAT3.TXT' for reading [file @ 00000000003d9580] Setting default whitelist 'file,crypto,data' [NULL @ 00000000003fa980] Opening 'Tóp - Part 1.mp4' for reading -- Ticket URL: <https://trac.ffmpeg.org/ticket/9907> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 1

#9060(swscale:new): libswscale crash with Neon - aarch64
by FFmpeg 05 Sep '22

05 Sep '22

#9060: libswscale crash with Neon - aarch64 ---------------------------------+-------------------------------------- Reporter: kuba456 | Type: defect Status: new | Priority: normal Component: swscale | Version: git-master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ---------------------------------+-------------------------------------- Hi there, this is my first post so please bare with me :) I'm currently in the process of debugging a ffmpeg crash and I'm reaching out for some tips how to approach this. Reproducing the steps may be quite involved as the crash happens in the application which depends on ffmpeg library (libswscale). This is a custom build of Blender animation package (build on Aarch64) and the crash happens if ffmpeg is configured with Neon instructions. Here is the stack trace: {{{ Thread 1 "blender" received signal SIGSEGV, Segmentation fault. 0x000000000257e320 in ff_yuv420p_to_rgba_neon () at libswscale/aarch64/yuv2rgb_neon.S:211 211 declare_rgb_funcs yuv420p (gdb) bt #0 0x000000000257e320 in ff_yuv420p_to_rgba_neon () at libswscale/aarch64/yuv2rgb_neon.S:211 #1 0x000000000257cfe0 in yuv420p_to_rgba_neon_wrapper () at libswscale/aarch64/swscale_unscaled.c:61 #2 0x000000000253361c in sws_scale () at libswscale/swscale.c:970 #3 0x0000000000dabd44 in IMB_anim_absolute () #4 0x0000000000b2384c in openanim () #5 0x0000000000a59850 in BKE_sequencer_add_movie_strip () #6 0x0000000000abd444 in sequencer_add_generic_strip_exec () #7 0x0000000000a06c38 in wm_operator_invoke () #8 0x0000000000a0a894 in wm_handlers_do_intern () #9 0x0000000000a0abf0 in wm_handlers_do () #10 0x0000000000a0b4b8 in wm_event_do_handlers () #11 0x0000000000a02590 in WM_main () #12 0x00000000009e27fc in main () Linux nano 4.9.140-tegra 2020 aarch64 }}} If I reconfigure ffmpeg and disable Neon all works great. I think my question at this point would be if anybody has seen similar issue in the past? Or could advise on the best way to narrow down the problem. Thank you, Kuba -- Ticket URL: <https://trac.ffmpeg.org/ticket/9060> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 6

#9563(ffmpeg:new): Conversion between lossless formats not lossless
by FFmpeg 05 Sep '22

05 Sep '22

#9563: Conversion between lossless formats not lossless -------------------------------------+------------------------------------- Reporter: Martijn van | Type: defect Beurden | Status: new | Priority: normal Component: ffmpeg | Version: git- Keywords: wavpack | master bits_per_raw_sample lossless | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: When converting a WAV file containing 32-bit integer PCM to wavpack, the resulting wavpack contains 24-bit integer samples. How to reproduce: {{{ % ffmpeg -i input.wav output.wv ffmpeg version N-104950-gc47896536c Copyright (c) 2000-2021 the FFmpeg developers built with gcc 10 (Debian 10.2.1-6) configuration: --enable-libx264 --enable-libfdk-aac --enable-libmp3lame --enable-gpl --enable-nonfree --enable-libopus libavutil 57. 11.100 / 57. 11.100 libavcodec 59. 14.100 / 59. 14.100 libavformat 59. 10.100 / 59. 10.100 libavdevice 59. 0.101 / 59. 0.101 libavfilter 8. 20.100 / 8. 20.100 libswscale 6. 1.101 / 6. 1.101 libswresample 4. 0.100 / 4. 0.100 libpostproc 56. 0.100 / 56. 0.100 Input #0, wav, from 'input.wav': Duration: 00:01:04.00, bitrate: 2822 kb/s Stream #0:0: Audio: pcm_s32le ([1][0][0][0] / 0x0001), 44100 Hz, stereo, s32, 2822 kb/s Stream mapping: Stream #0:0 -> #0:0 (pcm_s32le (native) -> wavpack (native)) Press [q] to stop, [?] for help Output #0, wv, to 'output.wv': Metadata: encoder : Lavf59.10.100 Stream #0:0: Audio: wavpack, 44100 Hz, stereo, s32p, 128 kb/s Metadata: encoder : Lavc59.14.100 wavpack size= 10720kB time=00:01:04.00 bitrate=1372.2kbits/s speed=86.9x video:0kB audio:10720kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000847% }}} Resulting wavpack file: {{{ % ffprobe output.wv ffprobe version N-104950-gc47896536c Copyright (c) 2007-2021 the FFmpeg developers built with gcc 10 (Debian 10.2.1-6) configuration: --enable-libx264 --enable-libfdk-aac --enable-libmp3lame --enable-gpl --enable-nonfree --enable-libopus libavutil 57. 11.100 / 57. 11.100 libavcodec 59. 14.100 / 59. 14.100 libavformat 59. 10.100 / 59. 10.100 libavdevice 59. 0.101 / 59. 0.101 libavfilter 8. 20.100 / 8. 20.100 libswscale 6. 1.101 / 6. 1.101 libswresample 4. 0.100 / 4. 0.100 libpostproc 56. 0.100 / 56. 0.100 Input #0, wv, from 'output.wv': Metadata: encoder : Lavf59.10.100 Duration: 00:01:04.00, start: 0.000000, bitrate: 1372 kb/s Stream #0:0: Audio: wavpack, 44100 Hz, stereo, s32p (24 bit) }}} I have tried to trace the origin of the bug in the hope of submitting a patch, but I don't know enough about ffmpeg internals to fix this alone. In fftools/ffmpeg.c, the following can be found {{{ if (ost->bits_per_raw_sample) enc_ctx->bits_per_raw_sample = ost->bits_per_raw_sample; else if (dec_ctx && ost->filter->graph->is_meta) enc_ctx->bits_per_raw_sample = FFMIN(dec_ctx->bits_per_raw_sample, av_pix_fmt_desc_get(enc_ctx->pix_fmt)->comp[0].depth); }}} If I remove ost->filter->graph->is_meta from the if, the conversion is lossless again. I think ost->filter->graph->is_meta is only initialized, not yet set at this point in the code. I'd like to fix this, but I'm not sure what to do. I think simply removing ost->filter->graph->is_meta as a condition is probably too simple. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9563> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 6

#9700(ffprobe:new): "451 Unavailable For Legal Reasons" instead of just HTTP_OTHER_4XX error
by FFmpeg 05 Sep '22

05 Sep '22

#9700: "451 Unavailable For Legal Reasons" instead of just HTTP_OTHER_4XX error -------------------------------------+------------------------------------- Reporter: Owyn | Type: defect Status: new | Priority: normal Component: ffprobe | Version: Keywords: 451 error | unspecified 4XX | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: HTTP error code for 451 is currently missing from FFPROBE so it just returns HTTP_OTHER_4XX error for it mixing things up and making it impossible to detect when a server is returning 451 for geo-blocked content and not the old-fashioned 403 forbidden How to reproduce: ffprobe a geo-blocked iptv channel ( for example - https://strm.yandex.ru/kal/rbc/rbc0.m3u8 ) Expected result: "Server returned 451 Unavailable For Legal Reasons" Actual result: "Server returned 4XX Client Error, but not one of 40{0,1,3,4}" -- Ticket URL: <https://trac.ffmpeg.org/ticket/9700> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#9749(undetermined:new): ffmpeg on mkv freezes system
by FFmpeg 05 Sep '22

05 Sep '22

#9749: ffmpeg on mkv freezes system --------------------------------------+---------------------------------- Reporter: eyrieowl | Type: defect Status: new | Priority: normal Component: undetermined | Version: 4.4.1 Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | --------------------------------------+---------------------------------- Summary of the bug: I have been running into an issue where when I try to transcode an mkv file above...some duration which I'm not quite certain about, it freezes the whole system after it's encoded to a certain point in time. With the input file that I'm sending information about, this seems to happen after it's encoded about 20 min of the movie. I'm running on Linux (extra info below); however, I've also attempted to get around the issue by running the encode in a VMWare VM running a Windows 10 guest and ffmpeg 5...and I saw the same behavior. I limited the guest to only two cores, and it never had the full memory available, and the same thing happened. It didn't just freeze the guest, it froze the entire machine.... When this happens, the machine is entirely unresponsive. The screen is still on, the time frozen, and no keyboard input or mouse input or remote login is possible. I've left the machine sitting overnight and well into the next day, nothing changes, the only remedy is to hard power off the machine. I've also tried using taskset in the linux host to limit the CPU ffmpeg can use, and that had the same result as well. My speculation is that something ffmpeg is doing is maybe hitting a bug in the CPU? I don't know. It does seem to be something about the mkv package...I've encoded many mp4 files without an issue. But I've encoded a couple mkv which both had the same outcome. I'll include information for both. I think I can't provide the original files, though, for legal reasons, but also size. The first file is 41GB. I'm happy to do whatever steps you want to gather more information, though. I also tried using Handbrake, with the goal of having it pick a different set of options. That also failed. How to reproduce: {{{ % ffmpeg -i THE\ GODFATHER_t00.mkv -map 0 -c:s copy TheGodfather.mkv }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/9749> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 9

#7182(avformat:new): Asynchronity when muxing Opus in Matroska
by FFmpeg 05 Sep '22

05 Sep '22

#7182: Asynchronity when muxing Opus in Matroska -----------------------------------+-------------------------------------- Reporter: mkver | Type: defect Status: new | Priority: normal Component: avformat | Version: git-master Keywords: mkv, opus | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -----------------------------------+-------------------------------------- Muxing opus in Matroska currently leads to asynchronity because the muxer doesn't account for the fact that Matroska's CodecDelay element already contains an implicit delay. Before turning to the more explicit explanation, let me say that I used this version of ffmpeg (latest version of Zeranoe's builds, still from today; I'm declaring the version to be git-master although git-master is ahead by one completely unrelated commit): {{{ ffmpeg version N-90920-ge07b1913fc Copyright (c) 2000-2018 the FFmpeg developers built with gcc 7.3.0 (GCC) configuration: --disable-static --enable-shared --enable-gpl --enable- version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable- libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable- libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth libavutil 56. 18.100 / 56. 18.100 libavcodec 58. 19.100 / 58. 19.100 libavformat 58. 13.100 / 58. 13.100 libavdevice 58. 4.100 / 58. 4.100 libavfilter 7. 21.100 / 7. 21.100 libswscale 5. 2.100 / 5. 2.100 libswresample 3. 2.100 / 3. 2.100 libpostproc 55. 2.100 / 55. 2.100 }}} The nullsrc and anullsrc filter create tracks whose timestamps (both pts and dts) start at zero: {{{ ffmpeg.exe -f lavfi -i nullsrc -f lavfi -i anullsrc -t 0.2 -f framehash -hash crc32 - #format: frame checksums #version: 2 #hash: CRC32 #software: Lavf58.13.100 #tb 0: 1/25 #media_type 0: video #codec_id 0: rawvideo #dimensions 0: 320x240 #sar 0: 1/1 #tb 1: 1/44100 #media_type 1: audio #codec_id 1: pcm_s16le #sample_rate 1: 44100 #channel_layout 1: 3 #channel_layout_name 1: stereo #stream#, dts, pts, duration, size, hash 0, 0, 0, 1, 115200, 2a01c517 1, 0, 0, 1024, 4096, c71c0011 1, 1024, 1024, 1024, 4096, c71c0011 0, 1, 1, 1, 115200, 2a01c517 1, 2048, 2048, 1024, 4096, c71c0011 1, 3072, 3072, 1024, 4096, c71c0011 0, 2, 2, 1, 115200, 2a01c517 1, 4096, 4096, 1024, 4096, c71c0011 1, 5120, 5120, 1024, 4096, c71c0011 0, 3, 3, 1, 115200, 2a01c517 1, 6144, 6144, 1024, 4096, c71c0011 0, 4, 4, 1, 115200, 2a01c517 1, 7168, 7168, 1024, 4096, c71c0011 1, 8192, 8192, 628, 2512, 3f99da8d }}} If one encodes the audio, the pts and dts of the audio are shifted by the amount of samples of encoder delay the encoding process entails so that the output audio that actually corresponds to input samples has the same timestamps as the corresponding input samples: {{{ ffmpeg.exe -f lavfi -i nullsrc -f lavfi -i anullsrc -c:a libopus -t 0.5 -f framehash -hash crc32 - #format: frame checksums #version: 2 #hash: CRC32 #extradata 1, 19, ea5d642a #software: Lavf58.13.100 #tb 0: 1/25 #media_type 0: video #codec_id 0: rawvideo #dimensions 0: 320x240 #sar 0: 1/1 #tb 1: 1/48000 #media_type 1: audio #codec_id 1: opus #sample_rate 1: 48000 #channel_layout 1: 3 #channel_layout_name 1: stereo #stream#, dts, pts, duration, size, hash 1, -312, -312, 960, 3, 8abe71cf 0, 0, 0, 1, 115200, 2a01c517 1, 648, 648, 960, 3, 8abe71cf 1, 1608, 1608, 960, 3, 8abe71cf 0, 1, 1, 1, 115200, 2a01c517 1, 2568, 2568, 960, 3, 8abe71cf 1, 3528, 3528, 960, 3, 8abe71cf 0, 2, 2, 1, 115200, 2a01c517 1, 4488, 4488, 960, 3, 8abe71cf 1, 5448, 5448, 960, 3, 8abe71cf 0, 3, 3, 1, 115200, 2a01c517 1, 6408, 6408, 960, 3, 8abe71cf 1, 7368, 7368, 960, 3, 8abe71cf 0, 4, 4, 1, 115200, 2a01c517 1, 8328, 8328, 960, 3, 8abe71cf 1, 9288, 9288, 960, 3, 8abe71cf 0, 5, 5, 1, 115200, 2a01c517 1, 10248, 10248, 960, 3, 8abe71cf 1, 11208, 11208, 960, 3, 8abe71cf 0, 6, 6, 1, 115200, 2a01c517 1, 12168, 12168, 960, 3, 8abe71cf 1, 13128, 13128, 960, 3, 8abe71cf 0, 7, 7, 1, 115200, 2a01c517 1, 14088, 14088, 960, 3, 8abe71cf 1, 15048, 15048, 960, 3, 8abe71cf 0, 8, 8, 1, 115200, 2a01c517 1, 16008, 16008, 960, 3, 8abe71cf 1, 16968, 16968, 960, 3, 8abe71cf 0, 9, 9, 1, 115200, 2a01c517 1, 17928, 17928, 960, 3, 8abe71cf 1, 18888, 18888, 960, 3, 8abe71cf 0, 10, 10, 1, 115200, 2a01c517 1, 19848, 19848, 960, 3, 8abe71cf 1, 20808, 20808, 960, 3, 8abe71cf 0, 11, 11, 1, 115200, 2a01c517 1, 21768, 21768, 960, 3, 8abe71cf 1, 22728, 22728, 960, 3, 8abe71cf 0, 12, 12, 1, 115200, 2a01c517 1, 23688, 23688, 312, 3, 8abe71cf, S=1, 10, 6ba9ada3 }}} If one now muxes this into Matroska (in order to use a valid codec in Matroska, I encoded the video with libx264 and -tune zerolatency in order not to run into #4536), the -312 samples (6.5ms) encoder delay from above lead to a shift of all timestamps by the same amount to make all timestamps non-negative; this happens with every audio codec and is not Opus-specific: {{{ ffmpeg.exe -f lavfi -i nullsrc -f lavfi -i anullsrc -c:v libx264 -tune zerolatency -c:a libopus -t 0.5 -f matroska test.mkv mkvinfo -s test.mkv Track 1: video, codec ID: V_MPEG4/ISO/AVC (h.264 profile: High @L1.3), mkvmerge/mkvextract track ID: 0, language: und, default duration: 40.000ms (25.000 frames/fields per second for a video track), pixel width: 320, pixel height: 240 Track 2: audio, codec ID: A_OPUS, mkvmerge/mkvextract track ID: 1, language: und, channels: 2, sampling freq: 48000, bits per sample: 16 I frame, track 2, timestamp 00:00:00.000000000, size 3, adler 0x05f302fa I frame, track 1, timestamp 00:00:00.007000000, size 812, adler 0x080a17e4 I frame, track 2, timestamp 00:00:00.021000000, size 3, adler 0x05f302fa I frame, track 2, timestamp 00:00:00.041000000, size 3, adler 0x05f302fa P frame, track 1, timestamp 00:00:00.047000000, size 51, adler 0xa07a11ec I frame, track 2, timestamp 00:00:00.061000000, size 3, adler 0x05f302fa I frame, track 2, timestamp 00:00:00.081000000, size 3, adler 0x05f302fa P frame, track 1, timestamp 00:00:00.087000000, size 61, adler 0x76721649 I frame, track 2, timestamp 00:00:00.101000000, size 3, adler 0x05f302fa I frame, track 2, timestamp 00:00:00.121000000, size 3, adler 0x05f302fa P frame, track 1, timestamp 00:00:00.127000000, size 65, adler 0x23a11875 I frame, track 2, timestamp 00:00:00.141000000, size 3, adler 0x05f302fa I frame, track 2, timestamp 00:00:00.161000000, size 3, adler 0x05f302fa P frame, track 1, timestamp 00:00:00.167000000, size 65, adler 0x249f181b I frame, track 2, timestamp 00:00:00.181000000, size 3, adler 0x05f302fa I frame, track 2, timestamp 00:00:00.201000000, size 3, adler 0x05f302fa P frame, track 1, timestamp 00:00:00.207000000, size 65, adler 0x334918bd I frame, track 2, timestamp 00:00:00.221000000, size 3, adler 0x05f302fa I frame, track 2, timestamp 00:00:00.241000000, size 3, adler 0x05f302fa P frame, track 1, timestamp 00:00:00.247000000, size 65, adler 0x34021860 I frame, track 2, timestamp 00:00:00.261000000, size 3, adler 0x05f302fa I frame, track 2, timestamp 00:00:00.281000000, size 3, adler 0x05f302fa P frame, track 1, timestamp 00:00:00.287000000, size 65, adler 0x42ac1902 I frame, track 2, timestamp 00:00:00.301000000, size 3, adler 0x05f302fa I frame, track 2, timestamp 00:00:00.321000000, size 3, adler 0x05f302fa P frame, track 1, timestamp 00:00:00.327000000, size 65, adler 0x085c17a3 I frame, track 2, timestamp 00:00:00.341000000, size 3, adler 0x05f302fa I frame, track 2, timestamp 00:00:00.361000000, size 3, adler 0x05f302fa P frame, track 1, timestamp 00:00:00.367000000, size 65, adler 0x17061845 I frame, track 2, timestamp 00:00:00.381000000, size 3, adler 0x05f302fa I frame, track 2, timestamp 00:00:00.401000000, size 3, adler 0x05f302fa P frame, track 1, timestamp 00:00:00.407000000, size 65, adler 0x180417eb I frame, track 2, timestamp 00:00:00.421000000, size 3, adler 0x05f302fa I frame, track 2, timestamp 00:00:00.441000000, size 3, adler 0x05f302fa P frame, track 1, timestamp 00:00:00.447000000, size 65, adler 0x2669188a I frame, track 2, timestamp 00:00:00.461000000, size 3, adler 0x05f302fa I frame, track 2, timestamp 00:00:00.481000000, size 3, adler 0x05f302fa P frame, track 1, timestamp 00:00:00.487000000, size 65, adler 0x2722182d I frame, track 2, timestamp 00:00:00.501000000, size 3, adler 0x05f302fa }}} So the encoder delay gets backed into the usual timestamps. But for Opus the encoding delay also gets signalled via the CodecDelay element in the Opus track header. The semantics of this field imply that the first 6.5ms of audio should be discarded and that the audio for time t has Matroska time t+6.5ms (i.e. the second opus block at 20ms actually has a timestamp of 13.5ms). This means that the synchronization of the opus track and the other tracks shifted by the encoder delay as can be seen e.g. in the output of the Matroska demuxer: {{{ ffmpeg.exe -copyts -i test.mkv -c copy -f framehash -hash crc32 - #format: frame checksums #version: 2 #hash: CRC32 #extradata 0, 40, 8237cd92 #extradata 1, 19, ea5d642a #software: Lavf58.13.100 #tb 0: 1/1000 #media_type 0: video #codec_id 0: h264 #dimensions 0: 320x240 #sar 0: 1/1 #tb 1: 1/1000 #media_type 1: audio #codec_id 1: opus #sample_rate 1: 48000 #channel_layout 1: 3 #channel_layout_name 1: stereo #stream#, dts, pts, duration, size, hash 1, -7, -7, 20, 3, 8abe71cf 0, 7, 7, 40, 812, dbac8e3e 1, 14, 14, 20, 3, 8abe71cf 1, 34, 34, 20, 3, 8abe71cf 0, 47, 47, 40, 51, 4885e758 1, 54, 54, 20, 3, 8abe71cf 1, 74, 74, 20, 3, 8abe71cf 0, 87, 87, 40, 61, 5c29c696 1, 94, 94, 20, 3, 8abe71cf 1, 114, 114, 20, 3, 8abe71cf 0, 127, 127, 40, 65, 2832137b 1, 134, 134, 20, 3, 8abe71cf 1, 154, 154, 20, 3, 8abe71cf 0, 167, 167, 40, 65, 985e3247 1, 174, 174, 20, 3, 8abe71cf 1, 194, 194, 20, 3, 8abe71cf 0, 207, 207, 40, 65, 85567570 1, 214, 214, 20, 3, 8abe71cf 1, 234, 234, 20, 3, 8abe71cf 0, 247, 247, 40, 65, c623be44 1, 254, 254, 20, 3, 8abe71cf 1, 274, 274, 20, 3, 8abe71cf 0, 287, 287, 40, 65, db2bf973 1, 294, 294, 20, 3, 8abe71cf 1, 314, 314, 20, 3, 8abe71cf 0, 327, 327, 40, 65, 49d46f1e 1, 334, 334, 20, 3, 8abe71cf 1, 354, 354, 20, 3, 8abe71cf 0, 367, 367, 40, 65, 54dc2829 1, 374, 374, 20, 3, 8abe71cf 1, 394, 394, 20, 3, 8abe71cf 0, 407, 407, 40, 65, 584b1113 1, 414, 414, 20, 3, 8abe71cf 1, 434, 434, 20, 3, 8abe71cf 0, 447, 447, 40, 65, 0aa1a42a 1, 454, 454, 20, 3, 8abe71cf 1, 474, 474, 20, 3, 8abe71cf 0, 487, 487, 40, 65, f52f7718 1, 494, 494, 20, 3, 8abe71cf, S=1, 10, 6ba9ada3 }}} (Without -copyts the timestamps would be shifted to make them non- negative.) As one sees, this is essentially a shift by the encoder delay. If one makes roundtrips demuxer->muxer, the tracks get ever more out of sync. -- Ticket URL: <https://trac.ffmpeg.org/ticket/7182> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 1

#9399(avcodec:new): ld: warning: could not create compact unwind
by FFmpeg 05 Sep '22

05 Sep '22

#9399: ld: warning: could not create compact unwind -------------------------------------+------------------------------------- Reporter: Daniel | Type: defect Schürmann | Status: new | Priority: normal Component: avcodec | Version: Keywords: dwarf stack | unspecified size compact unwind | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- When trying to link ffmpeg statically with Mixxx on macOS, the Apple linker is complaining: {{{ 2021-08-18T22:06:41.3473950Z ld: warning: could not create compact unwind for _ff_cfhd_init_vlcs: stack subq instruction is too different from dwarf stack size 2021-08-18T22:06:41.3475230Z ld: warning: could not create compact unwind for _ff_rl_init_vlc: stack subq instruction is too different from dwarf stack size }}} This happens with gcc and clang 12.0.0.12000032 The issue was original reported here: https://github.com/microsoft/vcpkg/issues/19699 Only these two functions are reported. When I disable cfhd encoder and decoder, one warning disappears. I can also specify {{{ LDFLAGS="-Wl,-no_compact_unwind" }}} to make remove this warning, but that will affect all functions. Both functions locate big arrays on the stack, my guess it that these arrays are too big for compact unwind. What is the best option to lower the used stack? Do you know what is the limit for unwinding, the dwarf stack size? Thank you. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9399> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 6