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

#4829(swscale:new): Overflows (?) in xyz -> rgb conversion
by FFmpeg 26 Dec '24

26 Dec '24

#4829: Overflows (?) in xyz -> rgb conversion --------------------------------------+--------------------------------- Reporter: cehoyos | Owner: Type: defect | Status: new Priority: normal | Component: swscale Version: git-master | Keywords: xyz Blocked By: | Blocking: Reproduced by developer: 0 | Analyzed by developer: 0 --------------------------------------+--------------------------------- http://thread.gmane.org/gmane.comp.video.ffmpeg.user/58666 The sample attached to ticket #4827 is in fact decoded fine (at least visually) by the native jpeg 2000 decoder but the colourspace conversion shows posterization artefacts. This is also reproducible with the libopenjpeg decoder. {{{ $ ffmpeg -i frm_000127.j2c out.png ffmpeg version N-74866-g0cdba4a Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.7 (SUSE Linux) configuration: --enable-gpl libavutil 54. 31.100 / 54. 31.100 libavcodec 56. 60.100 / 56. 60.100 libavformat 56. 40.101 / 56. 40.101 libavdevice 56. 4.100 / 56. 4.100 libavfilter 5. 40.101 / 5. 40.101 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 2.101 / 1. 2.101 libpostproc 53. 3.100 / 53. 3.100 [jpeg2000 @ 0x33bd940] End mismatch 1 Last message repeated 4 times [jpeg2000 @ 0x33bd940] End mismatch 2 Last message repeated 1 times [jpeg2000 @ 0x33bd940] End mismatch 1 Last message repeated 28 times [jpeg2000 @ 0x33bd940] End mismatch 2 [jpeg2000 @ 0x33bd940] End mismatch 1 Last message repeated 19 times Input #0, j2k_pipe, from 'frm_000127.j2c': Duration: N/A, bitrate: N/A Stream #0:0: Video: jpeg2000 (JPEG 2000 digital cinema 2K), xyz12le, 2048x858, 25 tbr, 25 tbn, 25 tbc Output #0, image2, to 'out.png': Metadata: encoder : Lavf56.40.101 Stream #0:0: Video: png, rgb48be, 2048x858, q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc Metadata: encoder : Lavc56.60.100 png Stream mapping: Stream #0:0 -> #0:0 (jpeg2000 (native) -> png (native)) Press [q] to stop, [?] for help [jpeg2000 @ 0x3655fa0] End mismatch 1 Last message repeated 4 times [jpeg2000 @ 0x3655fa0] End mismatch 2 Last message repeated 1 times [jpeg2000 @ 0x3655fa0] End mismatch 1 Last message repeated 28 times [jpeg2000 @ 0x3655fa0] End mismatch 2 [jpeg2000 @ 0x3655fa0] End mismatch 1 Last message repeated 19 times frame= 1 fps=0.8 q=-0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A video:5354kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown }}} {{{ $ ffmpeg -vcodec libopenjpeg -pix_fmt xyz12le -i frm_000127.j2c out.png ffmpeg version N-74866-g0cdba4a Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.7 (SUSE Linux) configuration: --enable-gpl --enable-libopenjpeg libavutil 54. 31.100 / 54. 31.100 libavcodec 56. 60.100 / 56. 60.100 libavformat 56. 40.101 / 56. 40.101 libavdevice 56. 4.100 / 56. 4.100 libavfilter 5. 40.101 / 5. 40.101 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 2.101 / 1. 2.101 libpostproc 53. 3.100 / 53. 3.100 Input #0, j2k_pipe, from 'frm_000127.j2c': Duration: N/A, bitrate: N/A Stream #0:0: Video: jpeg2000, xyz12le, 2048x858, 25 tbr, 25 tbn, 25 tbc Output #0, image2, to 'out.png': Metadata: encoder : Lavf56.40.101 Stream #0:0: Video: png, rgb48be, 2048x858, q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc Metadata: encoder : Lavc56.60.100 png Stream mapping: Stream #0:0 -> #0:0 (jpeg2000 (libopenjpeg) -> png (native)) Press [q] to stop, [?] for help frame= 1 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A video:5354kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown }}} I don't know if this ticket is related to ticket #3643. -- Ticket URL: <https://trac.ffmpeg.org/ticket/4829> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 11

#9520(ffmpeg:new): Invalid pal8 -> gbrp conversion
by FFmpeg 26 Dec '24

26 Dec '24

#9520: Invalid pal8 -> gbrp conversion -------------------------------------+------------------------------------- Reporter: Robin | Type: defect Status: new | Priority: normal Component: ffmpeg | Version: 4.4.1 Keywords: pal8, gbrp, | Blocked By: pix_fmt | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: ffmpeg is not correctly converting pal8 input to gbrp output. I discovered this when encoding optimized PNGs to UTVideo. Here is the first 30 first frames from Elephants Dream: https://www.mediafire.com/file/knisxsozg41001l/Elephants_Dream_First_30_Fra… The package contains both the original PNGs from Xiph and the optimized PNGs I created with oxipng. The original PNGs are all 24 bit. But the optimized ones are a mixed of 1bit, 8bit and 24bit. Copying and pasting my post from doom9 forums: https://forum.doom9.org/showthread.php?t=183452 I tested the release builds and master branch from gyan and Btbn. How to reproduce: {{{ 1. Encode the 30 frames to FFV1 and UTVideo: ffmpeg -i ED-30-xiph-source\%05d.png -c:v ffv1 ED-xiph_ffv1.mkv ffmpeg -i ED-30-xiph-source\%05d.png -c:v utvideo ED-xiph_utvideo.mkv ffmpeg -i ED-30-opt\%05d.png -pix_fmt bgr0 -c:v ffv1 ED-opt_ffv1.mkv ffmpeg -i ED-30-opt\%05d.png -c:v utvideo ED-opt_utvideo.mkv NOTE: The pix_fmt bgr0 command is necessary when encoding from the optimized files to prevent ffmpeg from encoding to greyscale since the first optimized PNG is 1-bit color. It is actually not necessary for UTvideo since it does support a grey or mono colorspace so will default to the appropriate pixel format. 2. Export all videos and PNGs to BMPs: ffmpeg -i ED-30-xiph-source\%05d.png BMP\ED-xiph-%02d.bmp ffmpeg -i ED-30-opt\%05d.png -pix_fmt bgr24 BMP\ED-opt-%02d.bmp ffmpeg -i ED-xiph_ffv1.mkv BMP\ED-xiph_ffv1-%02d.bmp ffmpeg -i ED-xiph_utvideo.mkv BMP\ED-xiph_utvideo-%02d.bmp ffmpeg -i ED-opt_ffv1.mkv BMP\ED-opt_ffv1-%02d.bmp ffmpeg -i ED-opt_utvideo.mkv BMP\ED_opt_utvideo-%02d.bmp 3. Perform checksum on all results. I find all BMPs have the same MD5 checksum except: ED_opt_utvideo-12.bmp 02a34fc1e347889d5546b547fa63e6af ED_opt_utvideo-13.bmp ca40ed9fc4acc827a4a77051433f0102 ED_opt_utvideo-14.bmp e3666199f35234756dddac97b8e18488 The above are sourced from the 8-bit optimized PNGs. The correct MD5 is as following: ED-xiph_utvideo-12.bmp ba5d92ca99726d837859b4b05795d317 ED-xiph_utvideo-13.bmp 735ee7c8b493855480fd0f5847a66132 ED-xiph_utvideo-14.bmp b509c3ac24e3543e1f59a7f1456e924d Which are sourced from the original Xiph PNGs that are all 24-bit. }}} Adding -pix_fmt to the source (before -i) did not fix the issue. Someone on doom9 found that specifying the conversion process to bgr0 (What FFV1 uses) then to UTVideo's gbrp solves the problem: ffmpeg -i "PATH\ED-30-opt\%05d.png" -vf format=bgr0,format=gbrp -c:v utvideo ED-opt_bgr0_gbrp_utvideo.mkv Which means the pal8 input (which ED_opt_utvideo-12 though 14 are) conversion directly to gbrp has an issue. It is possible other output conversions may have errors as well. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9520> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 9

#9733(avcodec:new): Segfault while libaom-av1 2 pass encoding
by FFmpeg 24 Dec '24

24 Dec '24

#9733: Segfault while libaom-av1 2 pass encoding -------------------------------------+------------------------------------- Reporter: oloke | Type: defect Status: new | Priority: normal Component: avcodec | Version: git- Keywords: libaom-av1 | master libaom | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: Hello, I was trying to encode some videos into AV1 with libaom. Most of them encoded fine, but 4 out of 11 I tried, were constantly segfaulting. I also tried encoding the same videos with libvpx-vp9, and there was no issue. I reproduced the segfault using ffmpeg version n5.0 from Arch Linux repos and static build from johnvansickle. I recompiled ffmpeg as well as libaom in debug mode using [https://github.com/BtbN/FFmpeg-Builds/ FFmpeg-Builds] and ran ffmpeg with gdb. Now I'm not getting segfaults, just libaom assertion error. I picked one video out of few that were crashing. The first pass doesn't have any problems and exits with status code 0. The second one always crashes near the end of encoding. The video itself is 3840x2160 @30fps h264 yuvj420p, 1923 frames long, recorded using Oneplus phone. The libaom version I used is the latest git ([https://aomedia.googlesource.com/aom/+/refs/heads/main f78cf964666570438a022e6e67e597073a39ed62]). If that's libaom bug, sorry for reporting in the wrong place. I'm attaching the full report file as well as the shortened list of commands I ran. {{{ $ gdb --args /home/oloke/Sources/FFmpeg-Builds/artifacts/ffmpeg -i /HDD/Datasets/220416/VID_20220416_154320.mp4 -vf scale=-2:1080 -c:v libaom-av1 -b:v 3000k -minrate 100k -maxrate 4000k -crf 44 -row-mt 1 -tile-rows 2 -tile-columns 2 -cpu-used 4 -c:a libopus -b:a 64k -pass 1 -f null - $ gdb --args /home/oloke/Sources/FFmpeg-Builds/artifacts/ffmpeg -report -v 9 -loglevel 99 -i /HDD/Datasets/220416/VID_20220416_154320.mp4 -vf scale=-2:1080 -c:v libaom-av1 -b:v 3000k -minrate 100k -maxrate 4000k -crf 44 -row-mt 1 -tile-rows 2 -tile-columns 2 -cpu-used 4 -c:a libopus -b:a 64k -pass 2 VID_20220416_154320.av1.webm ... [extract_extradata @ 0x5555606ceac0] obu_type: 2, temporal_id: 0, spatial_id: 0, payload size: 0 [extract_extradata @ 0x5555606ceac0] obu_type: 3, temporal_id: 0, spatial_id: 0, payload size: 1 [webm @ 0x55555c0a5340] Writing block of size 124 with pts 63100, dts 63100, duration 20 at relative offset 848664 in cluster at offset 22991766. TrackNumber 2, keyframe 1 [webm @ 0x55555c0a5340] Writing block of size 120 with pts 63120, dts 63120, duration 20 at relative offset 848795 in cluster at offset 22991766. TrackNumber 2, keyframe 1 [webm @ 0x55555c0a5340] Writing block of size 5 with pts 63133, dts 63133, duration 33 at relative offset 848921 in cluster at offset 22991766. TrackNumber 1, keyframe 0 [extract_extradata @ 0x5555606ceac0] obu_type: 2, temporal_id: 0, spatial_id: 0, payload size: 0 [extract_extradata @ 0x5555606ceac0] obu_type: 6, temporal_id: 0, spatial_id: 0, payload size: 354 [webm @ 0x55555c0a5340] Writing block of size 114 with pts 63140, dts 63140, duration 20 at relative offset 848930 in cluster at offset 22991766. TrackNumber 2, keyframe 1 [webm @ 0x55555c0a5340] Writing block of size 123 with pts 63160, dts 63160, duration 20 at relative offset 849050 in cluster at offset 22991766. TrackNumber 2, keyframe 1 [webm @ 0x55555c0a5340] Writing block of size 359 with pts 63167, dts 63167, duration 33 at relative offset 849180 in cluster at offset 22991766. TrackNumber 1, keyframe 0 [extract_extradata @ 0x5555606ceac0] obu_type: 2, temporal_id: 0, spatial_id: 0, payload size: 0 [extract_extradata @ 0x5555606ceac0] obu_type: 3, temporal_id: 0, spatial_id: 0, payload size: 1 [webm @ 0x55555c0a5340] Writing block of size 109 with pts 63180, dts 63180, duration 20 at relative offset 849544 in cluster at offset 22991766. TrackNumber 2, keyframe 1 [webm @ 0x55555c0a5340] Writing block of size 5 with pts 63200, dts 63200, duration 33 at relative offset 849659 in cluster at offset 22991766. TrackNumber 1, keyframe 0 ffmpeg: /stage/aom/av1/encoder/temporal_filter.c:980: tf_setup_filtering_buffer: Assertion `to_filter_buf != NULL' failed. Thread 1 "ffmpeg" received signal SIGABRT, Aborted. 0x00007ffff7d1334c in __pthread_kill_implementation () from /usr/lib/libc.so.6 (gdb) bt #0 0x00007ffff7d1334c in __pthread_kill_implementation () from /usr/lib/libc.so.6 #1 0x00007ffff7cc64b8 in raise () from /usr/lib/libc.so.6 #2 0x00007ffff7cb0534 in abort () from /usr/lib/libc.so.6 #3 0x00007ffff7cb045c in __assert_fail_base.cold () from /usr/lib/libc.so.6 #4 0x00007ffff7cbf116 in __assert_fail () from /usr/lib/libc.so.6 #5 0x0000555557c608da in tf_setup_filtering_buffer (gf_frame_index=1065432237, filter_frame_lookahead_idx=25, cpi=0x5555611b3ba0) at /stage/aom/av1/encoder/temporal_filter.c:980 #6 init_tf_ctx (output_frame=0x44368c95dc1ded00, compute_frame_diff=1, gf_frame_index=1065432237, filter_frame_lookahead_idx=25, cpi=0x5555611b3ba0) at /stage/aom/av1/encoder/temporal_filter.c:1165 #7 av1_temporal_filter (cpi=cpi@entry=0x5555611b3ba0, filter_frame_lookahead_idx=filter_frame_lookahead_idx@entry=25, gf_frame_index=gf_frame_index@entry=0, frame_diff=0x55556113f760, output_frame=output_frame@entry=0x55556113f5b0) at /stage/aom/av1/encoder/temporal_filter.c:1243 #8 0x0000555557c60bfa in av1_tf_info_filtering (tf_info=0x55556113f4d8, cpi=cpi@entry=0x5555611b3ba0, gf_group=gf_group@entry=0x555561137528) at /stage/aom/av1/encoder/temporal_filter.c:1330 #9 0x0000555557c2f86c in av1_get_second_pass_params (cpi=cpi@entry=0x5555611b3ba0, frame_params=frame_params@entry=0x7fffffffd540, frame_flags=<optimized out>) at /stage/aom/av1/encoder/pass2_strategy.c:3820 #10 0x0000555557eb2f59 in av1_encode_strategy (cpi=cpi@entry=0x5555611b3ba0, --Type <RET> for more, q to quit, c to continue without paging-- size=size@entry=0x7fffffffd6d0, dest=0x7fff88b4c010 "\022", frame_flags=frame_flags@entry=0x7fffffffd6d8, time_stamp=time_stamp@entry=0x7fffffffd6e0, time_end=time_end@entry=0x7fffffffd6e8, timestamp_ratio=0x55556112c660, pop_lookahead=0x7fffffffd700, flush=1) at /stage/aom/av1/encoder/encode_strategy.c:1305 #11 0x0000555557bf9e12 in av1_get_compressed_data (cpi=cpi@entry=0x5555611b3ba0, cpi_data=cpi_data@entry=0x7fffffffd6c0) at /stage/aom/av1/encoder/encoder.c:4450 #12 0x0000555557bcb6b6 in encoder_encode (ctx=0x55556112bfd0, img=0x0, pts=<optimized out>, duration=1, enc_flags=<optimized out>) at /stage/aom/av1/av1_cx_iface.c:3036 #13 0x0000555557ba059c in aom_codec_encode (ctx=ctx@entry=0x55555c0a7850, img=0x0, pts=0, duration=1, flags=0) at /stage/aom/aom/src/aom_encoder.c:159 #14 0x0000555555e7274f in aom_encode (avctx=0x55555c0a7340, pkt=0x55555c0e3580, frame=0x0, got_packet=0x7fffffffd9c4) at libavcodec/libaomenc.c:1155 #15 0x0000555555d7a827 in encode_simple_internal (avctx=avctx@entry=0x55555c0a7340, avpkt=avpkt@entry=0x55555c0e3580) at libavcodec/encode.c:214 #16 0x0000555555d7ab00 in encode_simple_receive_packet (avctx=avctx@entry=0x55555c0a7340, avpkt=avpkt@entry=0x55555c0e3580) at libavcodec/encode.c:269 #17 0x0000555555d7ac47 in encode_receive_packet_internal (avctx=avctx@entry=0x55555c0a7340, avpkt=avpkt@entry=0x55555c0e3580) at libavcodec/encode.c:303 #18 0x0000555555d7adb2 in avcodec_receive_packet (avctx=avctx@entry=0x55555c0a7340, avpkt=avpkt@entry=0x55555c0e3580) at libavcodec/encode.c:404 #19 0x00005555558be5d9 in flush_encoders () at fftools/ffmpeg.c:1808 #20 0x00005555558be7e7 in transcode () at fftools/ffmpeg.c:4439 #21 0x00005555558bee0a in main (argc=35, argv=0x7fffffffdcf8) at fftools/ffmpeg.c:4625 (gdb) disass $pc-32,$pc+32 Dump of assembler code from 0x7ffff7d1332c to 0x7ffff7d1336c: 0x00007ffff7d1332c <__pthread_kill_implementation+252>: nopl 0x0(%rax) 0x00007ffff7d13330 <__pthread_kill_implementation+256>: mov $0xba,%eax 0x00007ffff7d13335 <__pthread_kill_implementation+261>: syscall 0x00007ffff7d13337 <__pthread_kill_implementation+263>: mov %eax,%ebp 0x00007ffff7d13339 <__pthread_kill_implementation+265>: call 0x7ffff7d62b60 <getpid> 0x00007ffff7d1333e <__pthread_kill_implementation+270>: mov %r12d,%edx 0x00007ffff7d13341 <__pthread_kill_implementation+273>: mov %ebp,%esi 0x00007ffff7d13343 <__pthread_kill_implementation+275>: mov %eax,%edi 0x00007ffff7d13345 <__pthread_kill_implementation+277>: mov $0xea,%eax 0x00007ffff7d1334a <__pthread_kill_implementation+282>: syscall => 0x00007ffff7d1334c <__pthread_kill_implementation+284>: mov %eax,%ebp 0x00007ffff7d1334e <__pthread_kill_implementation+286>: neg %ebp 0x00007ffff7d13350 <__pthread_kill_implementation+288>: cmp $0xfffff000,%eax 0x00007ffff7d13355 <__pthread_kill_implementation+293>: mov $0x0,%eax 0x00007ffff7d1335a <__pthread_kill_implementation+298>: cmova %ebp,%eax 0x00007ffff7d1335d <__pthread_kill_implementation+301>: jmp 0x7ffff7d132d2 <__pthread_kill_implementation+162> 0x00007ffff7d13362 <__pthread_kill_implementation+306>: nopw 0x0(%rax,%rax,1) 0x00007ffff7d13368 <__pthread_kill_implementation+312>: mov %r13,%rdi 0x00007ffff7d1336b <__pthread_kill_implementation+315>: call 0x7ffff7d0e370 <__lll_lock_wake_private> End of assembler dump. (gdb) info all-registers rax 0x0 0 rbx 0x7ffff7b838c0 140737349433536 rcx 0x7ffff7d1334c 140737351070540 rdx 0x6 6 rsi 0x26946 158022 rdi 0x26946 158022 rbp 0x26946 0x26946 rsp 0x7fffffffcd30 0x7fffffffcd30 r8 0x7fffffffce00 140737488342528 r9 0xa2e64656c6961 2865758500317537 r10 0x8 8 r11 0x246 582 r12 0x6 6 r13 0x3d4 980 r14 0x55555a616fae 93825076916142 r15 0x5555611b3ba0 93825189755808 rip 0x7ffff7d1334c 0x7ffff7d1334c <__pthread_kill_implementation+284> eflags 0x246 [ PF ZF IF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 --Type <RET> for more, q to quit, c to continue without paging-- gs 0x0 0 st0 <invalid float value> (raw 0xffff0000000000000000) st1 <invalid float value> (raw 0xffff4a82788278825782) st2 -nan(0xffffffffffffffff) (raw 0xffffffffffffffffffff) st3 <invalid float value> (raw 0xffff4a82788278825782) st4 <invalid float value> (raw 0xffff453e3028453e3028) st5 <invalid float value> (raw 0xffff5855545358555453) st6 <invalid float value> (raw 0xffff453e4a4558555757) st7 <invalid float value> (raw 0xffff4543474e4a787857) fctrl 0x263 611 fstat 0x0 0 ftag 0xffff 65535 fiseg 0x0 0 fioff 0x0 0 foseg 0x0 0 fooff 0x0 0 fop 0x0 0 mxcsr 0x11ba [ DE OE UE PE IM DM PM ] ymm0 {v16_bfloat16 = {0x0 <repeats 16 times>}, v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x0, 0x0, 0x0}, v32_int8 = {0x0 <repeats 32 times>}, v16_int16 = {0x0 <repeats 16 times>}, v8_int32 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x0, 0x0, 0x0, 0x0}, v2_int128 = {0x0, 0x0}} ymm1 {v16_bfloat16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,--Type <RET> for more, q to quit, c to continue without paging-- 0x0, 0x0, 0x0}, v8_float = {0x0, 0x0, 0x0, 0xffffffff, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x7fffffffffffffff, 0x0, 0x0}, v32_int8 = {0x0 <repeats 11 times>, 0xff, 0x0, 0x0, 0xff, 0xff, 0x0 <repeats 16 times>}, v16_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0xff00, 0x0, 0xffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int32 = {0x0, 0x0, 0xff000000, 0xffff0000, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x0, 0xffff0000ff000000, 0x0, 0x0}, v2_int128 = {0xffff0000ff0000000000000000000000, 0x0}} ymm2 {v16_bfloat16 = {0x0, 0x0, 0x0, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_float = {0x0, 0xffffffff, 0xffffffff, 0xffffffff, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x7fffffffffffffff, 0x7fffffffffffffff, 0x0, 0x0}, v32_int8 = {0x3a, 0x39, 0x38, 0x30, 0x3a, 0x20, 0x74, 0x66, 0x5f, 0x73, 0x65, 0x74, 0x75, 0x70, 0x5f, 0x66, 0x0 <repeats 16 times>}, v16_int16 = {0x393a, 0x3038, 0x203a, 0x6674, 0x735f, 0x7465, 0x7075, 0x665f, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int32 = {0x3038393a, 0x6674203a, 0x7465735f, 0x665f7075, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x6674203a3038393a, 0x665f70757465735f, 0x0, 0x0}, v2_int128 = {0x665f70757465735f6674203a3038393a, 0x0}} ymm3 {v16_bfloat16 = {0xa, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_float = {0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x7fffffffffffffff, 0x7fffffffffffffff, 0x0, 0x0}, v32_int8 = {0x20, 0x41, 0x73, 0x73, 0x65, 0x72, 0x74, 0x69, 0x6f, 0x6e, 0x20, 0x60, 0x74, 0x6f, 0x5f, 0x66, 0x0 <repeats 16 times>}, v16_int16 = {0x4120, 0x7373, 0x7265, 0x6974, 0x6e6f, 0x6020, 0x6f74, 0x665f, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int32 = {0x73734120, 0x69747265, 0x60206e6f, 0x665f6f74, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x6974726573734120, 0x665f6f7460206e6f, 0x0, 0x0}, v2_int128 = {0x665f6f7460206e6f6974726573734120, 0x0}} ymm4 {v16_bfloat16 = {0x0, 0xffff, 0xffff, 0xffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, --Type <RET> for more, q to quit, c to continue without paging-- 0x0, 0x0, 0x0, 0x0, 0x0}, v8_float = {0xffffffff, 0xffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x7fffffffffffffff, 0x0, 0x0, 0x0}, v32_int8 = {0x4c, 0x27, 0x20, 0x66, 0x61, 0x69, 0x6c, 0x65, 0x64, 0x2e, 0xa, 0x0, 0x55, 0x55, 0x0 <repeats 18 times>}, v16_int16 = {0x274c, 0x6620, 0x6961, 0x656c, 0x2e64, 0xa, 0x5555, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int32 = {0x6620274c, 0x656c6961, 0xa2e64, 0x5555, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x656c69616620274c, 0x5555000a2e64, 0x0, 0x0}, v2_int128 = {0x5555000a2e64656c69616620274c, 0x0}} ymm5 {v16_bfloat16 = {0x0, 0x0, 0x0, 0x3, 0x0 <repeats 12 times>}, v8_float = {0x0, 0x3, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x87, 0x0, 0x0, 0x0}, v32_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0xe0, 0x60, 0x40, 0x0 <repeats 24 times>}, v16_int16 = {0x0, 0x0, 0xe000, 0x4060, 0x0 <repeats 12 times>}, v8_int32 = {0x0, 0x4060e000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x4060e00000000000, 0x0, 0x0, 0x0}, v2_int128 = {0x4060e00000000000, 0x0}} ymm6 {v16_bfloat16 = {0x0, 0x0, 0x0, 0x1, 0x0 <repeats 12 times>}, v8_float = {0x0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x0, 0x0, 0x0}, v32_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xe0, 0x3f, 0x0 <repeats 24 times>}, v16_int16 = {0x0, 0x0, 0x0, 0x3fe0, 0x0 <repeats 12 times>}, v8_int32 = {0x0, 0x3fe00000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x3fe0000000000000, 0x0, 0x0, 0x0}, v2_int128 = {0x3fe0000000000000, 0x0}} ymm7 {v16_bfloat16 = {0x0 <repeats 16 times>}, v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x0, 0x0, 0x0}, v32_int8 = {0x0 <repeats 32 times>}, v16_int16 = {0x0 <repeats 16 times>}, v8_int32 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x0, 0x0, 0x0, 0x0}, v2_int128 = {0x0, 0x0}} ymm8 {v16_bfloat16 = {0xffff, 0xffff, 0x0, 0xffff, 0xffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_float = {0xffffffff, 0xffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x7fffffffffffffff, 0x0, 0x0, 0x0}, v32_int8 = {0x0, 0x68, 0x65, 0x6c, 0x70, 0x0, 0--Type <RET> for more, q to quit, c to continue without paging-- x55, 0x73, 0x61, 0x67, 0x65, 0x3a, 0x0, 0x25, 0x73, 0x20, 0x0 <repeats 16 times>}, v16_int16 = {0x6800, 0x6c65, 0x70, 0x7355, 0x6761, 0x3a65, 0x2500, 0x2073, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int32 = {0x6c656800, 0x73550070, 0x3a656761, 0x20732500, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x735500706c656800, 0x207325003a656761, 0x0, 0x0}, v2_int128 = {0x207325003a656761735500706c656800, 0x0}} ymm9 {v16_bfloat16 = {0x0 <repeats 16 times>}, v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x0, 0x0, 0x0}, v32_int8 = {0x0 <repeats 32 times>}, v16_int16 = {0x0 <repeats 16 times>}, v8_int32 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x0, 0x0, 0x0, 0x0}, v2_int128 = {0x0, 0x0}} ymm10 {v16_bfloat16 = {0x0, 0x0, 0x0, 0xffff, 0x0 <repeats 12 times>}, v8_float = {0x56000000, 0xffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x0, 0x0, 0x0}, v32_int8 = {0x60, 0x55, 0x55, 0x55, 0x55, 0x55, 0xe5, 0xbf, 0x0 <repeats 24 times>}, v16_int16 = {0x5560, 0x5555, 0x5555, 0xbfe5, 0x0 <repeats 12 times>}, v8_int32 = {0x55555560, 0xbfe55555, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0xbfe5555555555560, 0x0, 0x0, 0x0}, v2_int128 = {0xbfe5555555555560, 0x0}} ymm11 {v16_bfloat16 = {0x0, 0x0, 0x0, 0x1, 0x0 <repeats 12 times>}, v8_float = {0x0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x0, 0x0, 0x0}, v32_int8 = {0x4e, 0x55, 0x59, 0x99, 0x99, 0x99, 0xe9, 0x3f, 0x0 <repeats 24 times>}, v16_int16 = {0x554e, 0x9959, 0x9999, 0x3fe9, 0x0 <repeats 12 times>}, v8_int32 = {0x9959554e, 0x3fe99999, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x3fe999999959554e, 0x0, 0x0, 0x0}, v2_int128 = {0x3fe999999959554e, 0x0}} ymm12 {v16_bfloat16 = {0x1d20, 0x0, 0xb000, 0xffff, 0x0 <repeats 12 times>}, v8_float = {0x0, 0xffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0xffffffffffffffff, 0x0, 0x0, 0x0}, v32_int8 = {0xe9, 0x45, 0x48, 0x9b, 0x5b, 0x49, 0xf2, 0xbf, 0x0 <repeats 24 times>}, v16_int1-- Type <RET> for more, q to quit, c to continue without paging-- 6 = {0x45e9, 0x9b48, 0x495b, 0xbff2, 0x0 <repeats 12 times>}, v8_int32 = {0x9b4845e9, 0xbff2495b, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0xbff2495b9b4845e9, 0x0, 0x0, 0x0}, v2_int128 = {0xbff2495b9b4845e9, 0x0}} ymm13 {v16_bfloat16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x0, 0x0, 0x0}, v32_int8 = {0x0, 0x4, 0x8, 0x0, 0x0, 0x4, 0x8, 0x0, 0x0, 0x4, 0x8, 0x0, 0x0, 0x4, 0x8, 0x0 <repeats 17 times>}, v16_int16 = {0x400, 0x8, 0x400, 0x8, 0x400, 0x8, 0x400, 0x8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int32 = {0x80400, 0x80400, 0x80400, 0x80400, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x8040000080400, 0x8040000080400, 0x0, 0x0}, v2_int128 = {0x80400000804000008040000080400, 0x0}} ymm14 {v16_bfloat16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x0, 0x0, 0x0}, v32_int8 = {0x30, 0x10, 0x30, 0x10, 0x30, 0x10, 0x30, 0x10, 0x30, 0x10, 0x30, 0x10, 0x30, 0x10, 0x2f, 0x10, 0x0 <repeats 16 times>}, v16_int16 = {0x1030, 0x1030, 0x1030, 0x1030, 0x1030, 0x1030, 0x1030, 0x102f, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int32 = {0x10301030, 0x10301030, 0x10301030, 0x102f1030, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x1030103010301030, 0x102f103010301030, 0x0, 0x0}, v2_int128 = {0x102f1030103010301030103010301030, 0x0}} ymm15 {v16_bfloat16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_float = {0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x7fffffffffffffff, 0x7fffffffffffffff, 0x0, 0x0}, v32_int8 = {0x80, 0xfe, 0xff, 0xff, 0x80, 0xfe, 0xff, 0xff, 0x80, 0xfe, 0xff, 0xff, 0x80, 0xfe, 0xff, 0xff, 0x0 <repeats 16 times>}, v16_int16 = {0xfe80, 0xffff, 0xfe80, 0xffff, 0xfe80, 0xffff, 0xfe80, 0xffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int32 = {0xfffffe80, 0xfffffe80, 0xfffffe80, 0xfffffe80, 0x0, 0x--Type <RET> for more, q to quit, c to continue without paging-- 0, 0x0, 0x0}, v4_int64 = {0xfffffe80fffffe80, 0xfffffe80fffffe80, 0x0, 0x0}, v2_int128 = {0xfffffe80fffffe80fffffe80fffffe80, 0x0}} (gdb) }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/9733> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 2

#9192(ffmpeg:new): Command line switch sws_dither doesn't allow "none"
by FFmpeg 23 Dec '24

23 Dec '24

#9192: Command line switch sws_dither doesn't allow "none" -------------------------------------+------------------------------------- Reporter: | Type: defect Videogamer555 | Status: new | Priority: important Component: ffmpeg | Version: | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: When using the -sws_dither command line switch to disable dithering with the value "none", it still behaves as if it was using the default value of "ed" (which is error diffusion dithering). How to reproduce: {{{ % ffmpeg -i video_in.avi -swf_dither none animation.gif ffmpeg version is latest nightly Windows build "N-101948-g870bfe16a1 -ffmpeg-windows-build-helpers" built on April 14, 2021 }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/9192> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 12

#9413(ffmpeg:new): Feature request: WindowsGraphicsCapture API
by FFmpeg 22 Dec '24

22 Dec '24

#9413: Feature request: WindowsGraphicsCapture API -------------------------------------+------------------------------------- Reporter: MB SOFT | Type: | enhancement Status: new | Priority: normal Component: ffmpeg | Version: Keywords: | unspecified WindowsGraphicsCapture API | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Feature request: could you please add WindowsGraphicsCapture API as a method to capture a window? this would allow to capture any graphics in the window -- Ticket URL: <https://trac.ffmpeg.org/ticket/9413> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 13

#8054(ffmpeg:new): prores_ks codec does not allow 12bit pix_fmt
by FFmpeg 21 Dec '24

21 Dec '24

#8054: prores_ks codec does not allow 12bit pix_fmt --------------------------------------+---------------------------------- Reporter: shaocaholica | Type: defect Status: new | Priority: normal Component: ffmpeg | Version: 4.1 Keywords: prores_ks | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | --------------------------------------+---------------------------------- Summary of the bug: Apple prores4444XQ which is supported by prores_ks allows for 12bit RGB/YUV channels but when a 12bit pix_fmt is used a warning is given: {{{ Incompatible pixel format 'yuv444p12le' for codec 'prores_ks', auto- selecting format 'yuv444p10le' }}} How to reproduce: {{{ % ffmpeg -f image2 -r 24.0 -i sample_16bit.%4d.tif -c:v prores_ks -profile:v 5 -pix_fmt yuv444p12le -vf colormatrix=bt601:bt709 prores4444XQ.mov ffmpeg version 4.1-static https://johnvansickle.com/ffmpeg/ built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516 }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/8054> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#5083(avcodec:new): Conversion from yuv410p to rgb24 looks wrong
by FFmpeg 21 Dec '24

21 Dec '24

#5083: Conversion from yuv410p to rgb24 looks wrong ---------------------------------+-------------------------------------- Reporter: khali | Type: defect Status: new | Priority: normal Component: avcodec | Version: git-master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ---------------------------------+-------------------------------------- Summary of the bug: When generating still pictures from a yuv410p video stream in PNG or BMP format, the output looks incorrect. The same still pictures written as TIFF or JPEG pictures look right. Given that TIFF and JPEG store the data in YUV color space while PNG and BMP use the RGB color space, this makes me suspect that the conversion from yuv410p to rgb24 is broken. How to reproduce: {{{ % ffmpeg -f lavfi -i "color=color=white:size=16x16" -frames:v 1 -vf "format=yuv410p,drawbox=color=red:x=4:y=4:w=8:h=8" -f image2 410p.png ffmpeg version N-77180-g45938f0 Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.8 (SUSE Linux) configuration: --prefix=/opt/ffmpeg --enable-shared --enable-libmp3lame --enable-libxvid --enable-postproc --enable-gpl --enable-x11grab --enable- avfilter --enable-version3 --enable-libx264 --enable-pthreads --enable- libvorbis --enable-libtheora --enable-fontconfig --cpu=corei7 --enable- libfaac --enable-nonfree libavutil 55. 10.100 / 55. 10.100 libavcodec 57. 17.100 / 57. 17.100 libavformat 57. 19.100 / 57. 19.100 libavdevice 57. 0.100 / 57. 0.100 libavfilter 6. 20.100 / 6. 20.100 libswscale 4. 0.100 / 4. 0.100 libswresample 2. 0.101 / 2. 0.101 libpostproc 54. 0.100 / 54. 0.100 Input #0, lavfi, from 'color=color=white:size=16x16': Duration: N/A, start: 0.000000, bitrate: N/A Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 16x16 [SAR 1:1 DAR 1:1], 25 tbr, 25 tbn, 25 tbc Output #0, image2, to '410p.png': Metadata: encoder : Lavf57.19.100 Stream #0:0: Video: png, rgb24, 16x16 [SAR 1:1 DAR 1:1], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc Metadata: encoder : Lavc57.17.100 png Stream mapping: Stream #0:0 -> #0:0 (rawvideo (native) -> png (native)) Press [q] to stop, [?] for help [swscaler @ 0x1b9f4c0] Warning: data is not aligned! This can lead to a speedloss frame= 1 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown }}} The generated image file does not look good. While the generated pattern is fully symmetric, the output image is not. Same problem with 410p.bmp as the output. However both 410p.jpg and 410p.tiff look right. Also note that format=yuv420p and format=yuv411p both work properly. So this is not a generic problem with the YUV to RGB color space conversion, rather this seems to be specifically related to yuv410p. Converting from yuv410p to yuv420p seems to also be broken, but differently. See how {{{ % ffmpeg -f lavfi -i "color=color=white:size=16x16" -frames:v 1 -vf "format=yuv410p,drawbox=color=red:x=4:y=4:w=8:h=8,format=yuv420p" -f image2 410p_to_420p.tiff }}} manages to create green pixels from a picture that originally only had white and red. -- Ticket URL: <https://trac.ffmpeg.org/ticket/5083> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 6

#8871(swscale:new): swsscale crops image on yuv2rgb
by FFmpeg 17 Dec '24

17 Dec '24

#8871: swsscale crops image on yuv2rgb ---------------------------------+--------------------------------------- Reporter: xlp | Type: defect Status: new | Priority: normal Component: swscale | Version: unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ---------------------------------+--------------------------------------- Summary of the bug: swscale leaves a small right portion of the image out on yuv2rgb conversion. aka "crops it", so a bar of the destination-image on right side stays unwritten. this seems to effect only certain resolutions/linesizes - below is one given that seems to cause issues How to reproduce: {{{ // HAS NO ISSUES // int32_t width = 1600; // int32_t height = 900; // int srcLinesize[8] = {1664, 832, 832, 0, 0, 0, 0, 0}; // HAS ISSUES int32_t width = 1220; int32_t height = 1200; int srcLinesize[8] = {1280, 640, 640, 0, 0, 0, 0, 0}; struct SwsContext* sws_scaler_ctx = sws_getContext(width, height, AV_PIX_FMT_YUV420P, width, height, AV_PIX_FMT_RGB0, SWS_FAST_BILINEAR, 0, 0, 0); size_t destBufferSize = width * 4 * height; uint8_t* destBuffer = (uint8_t*) malloc(destBufferSize); memset(destBuffer, 0x00, destBufferSize); uint8_t* destLines[4] = {destBuffer, 0, 0, 0}; int destData[4] = {width * 4, 0, 0, 0}; // Make a dummy source with green footage uint8_t* srcData[8]; for (int i = 0; i < 8; i++) { if (srcLinesize[i] > 0) { size_t srcBufferSize = srcLinesize[i]*height; srcData[i] = (uint8_t*) malloc(srcBufferSize); memset(srcData[i], 0x00, srcBufferSize); } else { srcData[i] = 0x00; } } sws_scale(sws_scaler_ctx, (const uint8_t* const*)srcData, srcLinesize, 0, height, destLines, destData); }}} Produced Result: Green area with unwritten gap at the right side (here in the size of 4x1200) Expected result: Completely green area, as the provided YUV source contains -- Ticket URL: <https://trac.ffmpeg.org/ticket/8871> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 4

#4444(swscale:new): Transparency gets lost when scaling pal8
by FFmpeg 16 Dec '24

16 Dec '24

#4444: Transparency gets lost when scaling pal8 --------------------------------------+------------------------------------ Reporter: cehoyos | Owner: Type: defect | Status: new Priority: normal | Component: swscale Version: git-master | Keywords: pal8 alpha Blocked By: | Blocking: Reproduced by developer: 0 | Analyzed by developer: 0 --------------------------------------+------------------------------------ {{{ $ ffmpeg -i alpha.png -s 168x168 out.png ffmpeg version N-71320-gc4b2017 Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.7 (SUSE Linux) configuration: --enable-gpl libavutil 54. 22.100 / 54. 22.100 libavcodec 56. 34.100 / 56. 34.100 libavformat 56. 29.100 / 56. 29.100 libavdevice 56. 4.100 / 56. 4.100 libavfilter 5. 13.101 / 5. 13.101 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 1.100 / 1. 1.100 libpostproc 53. 3.100 / 53. 3.100 Input #0, png_pipe, from 'alpha.png': Duration: N/A, bitrate: N/A Stream #0:0: Video: png, pal8, 21x21 [SAR 5:6 DAR 5:6], 25 tbr, 25 tbn, 25 tbc Output #0, apng, to 'out.png': Metadata: encoder : Lavf56.29.100 Stream #0:0: Video: apng, pal8, 168x168 [SAR 5:6 DAR 5:6], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc Metadata: encoder : Lavc56.34.100 apng Stream mapping: Stream #0:0 -> #0:0 (png (native) -> apng (native)) Press [q] to stop, [?] for help [apng @ 0x36fd040] Only a single frame so saving as a normal PNG. frame= 1 fps=0.0 q=0.0 Lsize= 4kB time=00:00:00.04 bitrate= 823.4kbits/s video:3kB audio:0kB subtitle:0kB other streams:0kB global headers:1kB muxing overhead: 24.418253% }}} The output file is opaque. -- Ticket URL: <https://trac.ffmpeg.org/ticket/4444> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 2

#8496(swscale:new): Conditional jump or move depends on uninitialised value with small input
by FFmpeg 16 Dec '24

16 Dec '24

#8496: Conditional jump or move depends on uninitialised value with small input --------------------------------------+--------------------------------- Reporter: ubitux | Owner: Type: defect | Status: new Priority: important | Component: swscale Version: git-master | Keywords: Blocked By: | Blocking: Reproduced by developer: 0 | Analyzed by developer: 0 --------------------------------------+--------------------------------- {{{ ☭ valgrind ./ffmpeg_g -f lavfi -i color=white:s=2x2,format=rgba,scale=10x10 -frames:v 1 -f null - ==95117== Memcheck, a memory error detector ==95117== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==95117== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==95117== Command: ./ffmpeg_g -f lavfi -i color=white:s=2x2,format=rgba,scale=10x10 -frames:v 1 -f null - ==95117== ffmpeg version N-96482-ge931119a41 Copyright (c) 2000-2020 the FFmpeg developers built with gcc 9.2.0 (GCC) configuration: --cc=/usr/bin/gcc libavutil 56. 38.100 / 56. 38.100 libavcodec 58. 66.100 / 58. 66.100 libavformat 58. 35.104 / 58. 35.104 libavdevice 58. 9.103 / 58. 9.103 libavfilter 7. 71.100 / 7. 71.100 libswscale 5. 6.100 / 5. 6.100 libswresample 3. 6.100 / 3. 6.100 ==95117== Conditional jump or move depends on uninitialised value(s) ==95117== at 0xF25462: yuv2rgb_full_1_c_template (output.c:2102) ==95117== by 0xF25462: yuv2rgba32_full_1_c (output.c:2142) ==95117== by 0xF05B31: packed_vscale (vscale.c:134) ==95117== by 0xF01D20: swscale (swscale.c:503) ==95117== by 0xF02D5C: sws_scale (swscale.c:978) ==95117== by 0x3A5496: scale_slice.isra.0 (vf_scale.c:647) ==95117== by 0x3A5C76: scale_frame (vf_scale.c:809) ==95117== by 0x3A5D77: filter_frame (vf_scale.c:823) ==95117== by 0x2C85FC: ff_filter_frame_framed (avfilter.c:1066) ==95117== by 0x2C85FC: ff_filter_frame_to_filter (avfilter.c:1214) ==95117== by 0x2C85FC: ff_filter_activate_default (avfilter.c:1263) ==95117== by 0x2C85FC: ff_filter_activate (avfilter.c:1425) ==95117== by 0x2CBC1C: get_frame_internal (buffersink.c:108) ==95117== by 0x2A6917: lavfi_read_packet (lavfi.c:412) ==95117== by 0x5AEB2E: ff_read_packet (utils.c:857) ==95117== by 0x5AF4AA: read_frame_internal (utils.c:1588) ==95117== Input #0, lavfi, from 'color=white:s=2x2,format=rgba,scale=10x10': Duration: N/A, start: 0.000000, bitrate: N/A Stream #0:0: Video: rawvideo (RGBA / 0x41424752), rgba, 10x10 [SAR 1:1 DAR 1:1], 25 tbr, 25 tbn, 25 tbc Stream mapping: Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native)) Press [q] to stop, [?] for help Output #0, null, to 'pipe:': Metadata: encoder : Lavf58.35.104 Stream #0:0: Video: wrapped_avframe, rgba, 10x10 [SAR 1:1 DAR 1:1], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc Metadata: encoder : Lavc58.66.100 wrapped_avframe frame= 1 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A speed=0.113x video:1kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown ==95117== ==95117== HEAP SUMMARY: ==95117== in use at exit: 0 bytes in 0 blocks ==95117== total heap usage: 2,725 allocs, 2,725 frees, 926,979 bytes allocated ==95117== ==95117== All heap blocks were freed -- no leaks are possible ==95117== ==95117== Use --track-origins=yes to see where uninitialised values come from ==95117== For lists of detected and suppressed errors, rerun with: -s ==95117== ERROR SUMMARY: 100 errors from 1 contexts (suppressed: 0 from 0) }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/8496> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 1