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

#10945(undetermined:new): Compiling ffmpeg for Raspberry Pi5 fails
by FFmpeg 18 Apr '24

18 Apr '24

#10945: Compiling ffmpeg for Raspberry Pi5 fails -------------------------------------+------------------------------------- Reporter: f1faq | Type: defect Status: new | Priority: normal Component: | Version: git- undetermined | master Keywords: compilation | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- I try to compile ffmpeg (master) for a Raspberry Pi5 Compiling is done on the Pi5 which is running "Linux rasp5 6.6.20+rpt- rpi-v8 #1 SMP PREEMPT Debian 1:6.6.20-1+rpt1 (2024-03-07) aarch64 GNU/Linux" I strictly follow the "Compile FFmpeg for Ubuntu, Debian, or Mint" chapter Configure step runs well. Make fails while treating libavfilter giving an error : " invalid operand for code 'w' Hereafter an extract of the screen when make fails : CC libavfilter/vf_datascope.o CC libavfilter/vf_dblur.o CC libavfilter/vf_dctdnoiz.o In file included from ./libavutil/bswap.h:38, from ./libavutil/intreadwrite.h:25, from libavfilter/vf_curves.c:27: In function ‘av_bswap16’, inlined from ‘parse_psfile’ at libavfilter/vf_curves.c:610:5: ./libavutil/aarch64/bswap.h:33:5: error: invalid 'asm': invalid operand for code 'w' 33 | __asm__("rev16 %w0, %w1" : "=r"(y) : "r"(x)); | ^~~~~~~ ./libavutil/aarch64/bswap.h:33:5: error: invalid 'asm': invalid operand for code 'w' In function ‘av_bswap16’, inlined from ‘parse_psfile’ at libavfilter/vf_curves.c:614:9: ./libavutil/aarch64/bswap.h:33:5: error: invalid 'asm': invalid operand for code 'w' 33 | __asm__("rev16 %w0, %w1" : "=r"(y) : "r"(x)); | ^~~~~~~ ./libavutil/aarch64/bswap.h:33:5: error: invalid 'asm': invalid operand for code 'w' In function ‘av_bswap16’, inlined from ‘parse_psfile’ at libavfilter/vf_curves.c:617:13: ./libavutil/aarch64/bswap.h:33:5: error: invalid 'asm': invalid operand for code 'w' 33 | __asm__("rev16 %w0, %w1" : "=r"(y) : "r"(x)); | ^~~~~~~ ./libavutil/aarch64/bswap.h:33:5: error: invalid 'asm': invalid operand for code 'w' In function ‘av_bswap16’, inlined from ‘parse_psfile’ at libavfilter/vf_curves.c:618:13: ./libavutil/aarch64/bswap.h:33:5: error: invalid 'asm': invalid operand for code 'w' 33 | __asm__("rev16 %w0, %w1" : "=r"(y) : "r"(x)); | ^~~~~~~ ./libavutil/aarch64/bswap.h:33:5: error: invalid 'asm': invalid operand for code 'w' CC libavfilter/vf_deband.o CC libavfilter/vf_deblock.o CC libavfilter/vf_decimate.o make: *** [ffbuild/common.mak:81: libavfilter/vf_curves.o] Error 1 make: *** Waiting for unfinished jobs.... cma@rasp5:~/ffmpeg_sources/ffmpeg -- Ticket URL: <https://trac.ffmpeg.org/ticket/10945> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

#10967(avformat:new): MP4 Inconsistencies in presentation time when negative ctts_offsets are present.
by FFmpeg 18 Apr '24

18 Apr '24

#10967: MP4 Inconsistencies in presentation time when negative ctts_offsets are present. -------------------------------------+------------------------------------- Reporter: Casey | Type: defect Bateman | Status: new | Priority: normal Component: avformat | Version: 5.1.4 Keywords: fmp4 pts | Blocked By: cts dts dtsshift | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- I am attempting to encode HLS variants packaged with the fMP4 file type. I have noticed that there is a discrepancy in PTS time calculated by the demuxer (mov.c), and that calculated by the muxer (movenc.c). I believe this discrepancy is resulting in behavior making it difficult to align HLS segment boudaries. The demuxer will calculate PTS time using the following calculation: {{{ PTS = DTS + DTS_SHIFT + CTTS_OFFSET }}} Where as the muxer(movenc.c) calculates the earliest presentation timestamp shown in the sidx, or just the pts time of a packet using the following calculation: {{{ PTS = DTS + CTTS_OFFSET }}} The result is a sidx earliest presentation time that does not match the reported PTS time for the first packet in a video stream with negative cts offsets. This feels particularly problematic for my use case which is encoding HLS variant segments on demand. We do this to save on storage costs, as well as deliver dynamic qualities to users based on their specific needs and abilities. When I run my first segment through ffprobe to inspect the DTS/PTS of the first packet I get the following: {{{ ffprobe -show_packets -select_streams v -read_intervals "%+#1" -print_format json -hide_banner -loglevel error -i "concat:1080_0000.mp4|1080_0000.m4s" { "packets": [ { "codec_type": "video", "stream_index": 0, "pts": 4096, "pts_time": "0.320000", "dts": 2048, "dts_time": "0.160000", "duration": 512, "duration_time": "0.040000", "size": "452669", "pos": "2702", "flags": "K_" } ] } }}} I then attempt to encode the first HLS segment to a lower variant 720p, using the follow command and get the following output. {{{ ../../ffmpeg -i "concat:1080_0000.mp4|1080_0000.m4s" -color_trc bt709 -colorspace bt709 -color_primaries bt709 -vf "scale=width=1280:height=720:flags=bicubic, setdar=dar=16/9, setsar=sar=1/1" -c:v libx264 -pix_fmt yuv420p -max_muxing_queue_size 9999 -s 1280x720 -maxrate 1200k -bufsize 1200k -profile:v main -hls_segment_type fmp4 -hls_time 999 -hls_fmp4_init_filename "720_0000.mp4" -hls_segment_filename "720_%04d.m4s" -hls_segment_options "fragment_index=1:movflags=+frag_discont+cmaf+negative_cts_offsets" -start_number 0 -fps_mode passthrough -copyts -enc_time_base -1 "playlist_720.m3u8" ffmpeg version n5.1.2-6-gc3bdbb5 Copyright (c) 2000-2022 the FFmpeg developers built with gcc 10 (GCC) configuration: libavutil 57. 28.100 / 57. 28.100 libavcodec 59. 37.100 / 59. 37.100 libavformat 59. 27.100 / 59. 27.100 libavfilter 8. 44.100 / 8. 44.100 libswscale 6. 7.100 / 6. 7.100 libswresample 4. 7.100 / 4. 7.100 libpostproc 56. 6.100 / 56. 6.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'concat:1080_0000.mp4|1080_0000.m4s': Metadata: major_brand : iso6 minor_version : 512 compatible_brands: iso6cmfcmp41 title : Hudl encoder : Lavf59.27.100 Duration: 00:00:04.16, start: 0.320000, bitrate: 5609 kb/s Stream #0:0[0x1](und): Video: hevc (Main) (hvc1 / 0x31637668), yuv420p(tv, progressive), 1920x1080, 5603 kb/s, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0] encoder : Lavc59.37.100 libwz265 Stream mapping: Stream #0:0 -> #0:0 (hevc (native) -> h264 (libx264)) Press [q] to stop, [?] for help [libx264 @ 0x4b36640] using SAR=1/1 [libx264 @ 0x4b36640] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 [libx264 @ 0x4b36640] profile Main, level 3.1, 4:2:0, 8-bit [libx264 @ 0x4b36640] 264 - core 164 - H.264/MPEG-4 AVC codec - Copyleft 2003-2022 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x1:0x111 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=22 lookahead_threads=3 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 vbv_maxrate=1200 vbv_bufsize=1200 crf_max=0.0 nal_hrd=none filler=0 ip_ratio=1.40 aq=1:1.00 [hls @ 0x4b378c0] Opening '720_0000.mp4' for writing Output #0, hls, to 'playlist_720.m3u8': Metadata: major_brand : iso6 minor_version : 512 compatible_brands: iso6cmfcmp41 title : Hudl encoder : Lavf59.27.100 Stream #0:0(und): Video: h264, yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 25 fps, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0] encoder : Lavc59.37.100 libx264 Side data: cpb: bitrate max/min/avg: 1200000/0/0 buffer size: 1200000 vbv_delay: N/A [hls @ 0x4b378c0] Opening '720_0000.m4s' for writingbitrate=N/A speed= 0x [hls @ 0x4b378c0] Opening 'playlist_720.m3u8.tmp' for writing frame= 100 fps=0.0 q=-1.0 Lsize=N/A time=00:00:00.00 bitrate=N/A speed= 0x video:498kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown [libx264 @ 0x4b36640] frame I:1 Avg QP:36.23 size: 66380 [libx264 @ 0x4b36640] frame P:25 Avg QP:37.11 size: 14045 [libx264 @ 0x4b36640] frame B:74 Avg QP:41.92 size: 1235 [libx264 @ 0x4b36640] consecutive B-frames: 1.0% 0.0% 3.0% 96.0% [libx264 @ 0x4b36640] mb I I16..4: 21.9% 0.0% 78.1% [libx264 @ 0x4b36640] mb P I16..4: 0.8% 0.0% 0.3% P16..4: 37.0% 18.4% 12.2% 0.0% 0.0% skip:31.4% [libx264 @ 0x4b36640] mb B I16..4: 0.0% 0.0% 0.0% B16..8: 39.2% 0.4% 0.1% direct: 0.1% skip:60.3% L0:35.5% L1:64.3% BI: 0.2% [libx264 @ 0x4b36640] coded y,uvDC,uvAC intra: 66.2% 26.6% 0.1% inter: 5.9% 1.1% 0.0% [libx264 @ 0x4b36640] i16 v,h,dc,p: 28% 24% 29% 18% [libx264 @ 0x4b36640] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 13% 17% 26% 7% 9% 6% 11% 4% 7% [libx264 @ 0x4b36640] i8c dc,h,v,p: 85% 9% 6% 0% [libx264 @ 0x4b36640] Weighted P-Frames: Y:8.0% UV:0.0% [libx264 @ 0x4b36640] ref P L0: 68.7% 17.2% 12.0% 1.9% 0.2% [libx264 @ 0x4b36640] ref B L0: 98.3% 1.5% 0.1% [libx264 @ 0x4b36640] ref B L1: 96.8% 3.2% [libx264 @ 0x4b36640] kb/s:1017.76 }}} Then running ffprobe to query the first packet I see the following in the new variant: {{{ ffprobe -show_packets -select_streams v -read_intervals "%+#1" -print_format json -hide_banner -loglevel error -i "concat:720_0000.mp4|720_0000.m4s" { "packets": [ { "codec_type": "video", "stream_index": 0, "pts": 5120, "pts_time": "0.400000", "dts": 4096, "dts_time": "0.320000", "size": "67125", "pos": "1816", "flags": "K_" } ] } }}} When inspecting the sidx for both files, the earliest presentation time for the 1080_0000.m4s shows a value 2048, the 720_0000.m4s shows a value of 4096. Both show different PTS times in ffprobe due to the calculation of PTS including DTS_DRIFT. Basically I am unable to align timestamps successfully using this approach. So my questions are, Is there a bug in the calculation from the muxer? or demuxer? When aligning HLS segment boundaries in fMP4 which value (sidx > earliest_presentation_time or ffprobe packet -> pts) is correct as to not introduce discontinuities? I believe I can align the value reported in the sidx by using a `setpts` filter, but the ffprobe reported value I have been unable to align. -- Ticket URL: <https://trac.ffmpeg.org/ticket/10967> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#10937(undetermined:new): Build with libbluray fails
by FFmpeg 17 Apr '24

17 Apr '24

#10937: Build with libbluray fails -------------------------------------+------------------------------------- Reporter: martinr92 | Type: defect Status: new | Priority: normal Component: | Version: git- undetermined | master Keywords: bluray | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- The build using libbluray (`--enable-libbluray`) currently fails. {{{ STRIP libavutil/x86/tx_float.o AR libavutil/libavutil.a STRIP libavcodec/x86/vp9itxfm.o AR libavcodec/libavcodec.a LD ffmpeg_g LD ffplay_g LD ffprobe_g /usr/bin/ld: /home/ffmpegBuild/tool/lib/libbluray.a(libbluray_la-dec.o): in function `dec_init': /home/ffmpegBuild/source/libbluray/libbluray-1.3.3/src/libbluray/disc/dec.c:290: multiple definition of `dec_init'; fftools/ffmpeg_dec.o:/home/ffmpegBuild/source/ffmpeg/ffmpeg/fftools/ffmpeg_dec.c:1256: first defined here collect2: error: ld returned 1 exit status make: *** [Makefile:136: ffmpeg_g] Error 1 make: *** Waiting for unfinished jobs.... check failed: build failed }}} The build fails on Linux and macOS (amd64 and arm64). Possible cause could be the recent refactoring in commit https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/c4de5778bceab3c15f1239f1f16… -- Ticket URL: <https://trac.ffmpeg.org/ticket/10937> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#9883(ffmpeg:new): FFmpeg AVIF decoder does not seem to handle transparency when decoding YUV420P
by FFmpeg 17 Apr '24

17 Apr '24

#9883: FFmpeg AVIF decoder does not seem to handle transparency when decoding YUV420P -------------------------------------+------------------------------------- Reporter: btdmaster | Type: defect Status: new | Priority: normal Component: ffmpeg | Version: | unspecified Keywords: transparent | Blocked By: Blocking: #7621 | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- FFmpeg seems to ignore transparency when decoding YUV420P. For example, compare the following: {{{ % ffmpeg -i transparency-present.avif transparency-missing.png % convert transparency-present.avif transparency-present.png Arch Linux FFmpeg 2:5.1-1 }}} This can also be reproduced when printing the file with ffplay and mpv (which, from what I understand, also used FFmpeg) but not with firefox or chafa, hence suggesting FFmpeg is the culprit. I also found a similar limitation in libavif, though only for converting to yuv4mpeg2 (https://github.com/AOMediaCodec/libavif/blob/98a453fdbb0340eaf8bd6f79435948…) {{{ % avifdec -i transparency-present.avif -o transparency-also-missing.y4m Arch Linux libavif 0.10.1-2 }}} FFmpeg does not seem to use libavif, but I thought that may provide some insight into the problem. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9883> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#10965(avcodec:new): avcodec: h.264 decoder flags result as ER error_occurred with frame threading
by FFmpeg 16 Apr '24

16 Apr '24

#10965: avcodec: h.264 decoder flags result as ER error_occurred with frame threading -------------------------------------+------------------------------------- Reporter: jeeb | Type: defect Status: new | Priority: normal Component: avcodec | Version: git- Keywords: avcodec | master h264 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: With sample https://megumin.fushizen.eu/samples/2024-04-15-framethread_causes_er_errors… , in case of frame threading being enabled, the H.264 decoder flags multiple output frames with decode_error_flags: FF_DECODE_ERROR_DECODE_SLICES (8) before the sudden end at the end of the sample (where there are actual MB decoding errors), while disabling threading leads to this flagging not happening The data seems to match between these two cases and there is no visual corruption, so either both are fine or both are in some manner broken. I have not compared against the JM reference decoder yet. How to reproduce: {{{ % ffmpeg -threads:v 2 -i "https://megumin.fushizen.eu/samples/2024-04-15-framethread_causes_er_errors…" -f null pipe: ffmpeg version N-114837-g257bc2a82a Copyright (c) 2000-2024 the FFmpeg developers built with gcc 14 (GCC) configuration: --prefix=/home/jeeb/ownapps/encoding_prefix/ --enable- static --disable-doc --disable-stripping --enable-gpl --enable-version3 --enable-vaapi --enable-zlib --enable-libdav1d --enable-libx264 --enable- libsvtav1 --enable-libx265 --enable-libzimg --enable-gnutls --enable- libplacebo libavutil 59. 15.100 / 59. 15.100 libavcodec 61. 5.103 / 61. 5.103 libavformat 61. 3.100 / 61. 3.100 libavdevice 61. 2.100 / 61. 2.100 libavfilter 10. 2.101 / 10. 2.101 libswscale 8. 2.100 / 8. 2.100 libswresample 5. 2.100 / 5. 2.100 libpostproc 58. 2.100 / 58. 2.100 [h264 @ 0x5475300] Stream #0: not enough frames to estimate rate; consider increasing probesize Input #0, h264, from 'https://megumin.fushizen.eu/samples/2024-04-15-framethread_causes_er_errors…': Duration: N/A, bitrate: N/A Stream #0:0: Video: h264 (High), yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 1200k tbn Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> wrapped_avframe (native)) Press [q] to stop, [?] for help Output #0, null, to 'pipe:': Metadata: encoder : Lavf61.3.100 Stream #0:0: Video: wrapped_avframe, yuv420p(tv, bt709, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 25 tbn Metadata: encoder : Lavc61.5.103 wrapped_avframe [vist#0:0/h264 @ 0x6144c80] [dec:h264 @ 0x551c4c0] corrupt decoded frame Last message repeated 7 times [h264 @ 0x60bee40] error while decoding MB 64 10, bytestream -16 speed=1.92x [h264 @ 0x60bee40] concealing 6945 DC, 6945 AC, 6945 MV errors in P frame [vist#0:0/h264 @ 0x6144c80] [dec:h264 @ 0x551c4c0] corrupt decoded frame [out#0/null @ 0x5517800] video:18KiB audio:0KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: unknown frame= 42 fps=0.0 q=-0.0 Lsize=N/A time=00:00:01.68 bitrate=N/A speed=2.51x }}} Comparison with threading disabled: {{{ ffmpeg -threads:v 1 -i "https://megumin.fushizen.eu/samples/2024-04-15-framethread_causes_er_errors…" -f null pipe: ffmpeg version N-114837-g257bc2a82a Copyright (c) 2000-2024 the FFmpeg developers built with gcc 14 (GCC) configuration: --prefix=/home/jeeb/ownapps/encoding_prefix/ --enable- static --disable-doc --disable-stripping --enable-gpl --enable-version3 --enable-vaapi --enable-zlib --enable-libdav1d --enable-libx264 --enable- libsvtav1 --enable-libx265 --enable-libzimg --enable-gnutls --enable- libplacebo libavutil 59. 15.100 / 59. 15.100 libavcodec 61. 5.103 / 61. 5.103 libavformat 61. 3.100 / 61. 3.100 libavdevice 61. 2.100 / 61. 2.100 libavfilter 10. 2.101 / 10. 2.101 libswscale 8. 2.100 / 8. 2.100 libswresample 5. 2.100 / 5. 2.100 libpostproc 58. 2.100 / 58. 2.100 [h264 @ 0x605b300] Stream #0: not enough frames to estimate rate; consider increasing probesize Input #0, h264, from 'https://megumin.fushizen.eu/samples/2024-04-15-framethread_causes_er_errors…': Duration: N/A, bitrate: N/A Stream #0:0: Video: h264 (High), yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 1200k tbn Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> wrapped_avframe (native)) Press [q] to stop, [?] for help Output #0, null, to 'pipe:': Metadata: encoder : Lavf61.3.100 Stream #0:0: Video: wrapped_avframe, yuv420p(tv, bt709, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 25 tbn Metadata: encoder : Lavc61.5.103 wrapped_avframe [h264 @ 0x6de1580] error while decoding MB 64 10, bytestream -16 speed=1.16x [h264 @ 0x6de1580] concealing 6945 DC, 6945 AC, 6945 MV errors in P frame [vist#0:0/h264 @ 0x6d2ac80] [dec:h264 @ 0x61024c0] corrupt decoded frame [out#0/null @ 0x60fd800] video:18KiB audio:0KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: unknown frame= 42 fps= 34 q=-0.0 Lsize=N/A time=00:00:01.68 bitrate=N/A speed=1.37x }}} Some changes I have applied to check values: {{{ diff --git a/fftools/ffmpeg_dec.c b/fftools/ffmpeg_dec.c index 70de151301..5be43910ad 100644 --- a/fftools/ffmpeg_dec.c +++ b/fftools/ffmpeg_dec.c @@ -731,7 +731,8 @@ static int packet_decode(DecoderPriv *dp, AVPacket *pkt, AVFrame *frame) if (frame->decode_error_flags || (frame->flags & AV_FRAME_FLAG_CORRUPT)) { av_log(dp, exit_on_error ? AV_LOG_FATAL : AV_LOG_WARNING, - "corrupt decoded frame\n"); + "corrupt decoded frame. decode_error_flags: %d, AV_FRAME_FLAG_CORRUPT: %d\n", + frame->decode_error_flags, (frame->flags & AV_FRAME_FLAG_CORRUPT)); if (exit_on_error) return AVERROR_INVALIDDATA; } diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c index 727dc1a662..f31c936595 100644 --- a/libavcodec/h264dec.c +++ b/libavcodec/h264dec.c @@ -756,6 +756,9 @@ static int decode_nal_units(H264Context *h, const uint8_t *buf, int buf_size) if (h->cur_pic_ptr->decode_error_flags) { /* Frame-threading in use */ atomic_int *decode_error = h->cur_pic_ptr->decode_error_flags; + av_log(h->avctx, AV_LOG_WARNING, + "threaded error case: ret: %d, ER error_occurred: %d, decode_error_flags : %d\n", + ret, h->er.error_occurred, *h->cur_pic_ptr->decode_error_flags); /* Using atomics here is not supposed to provide syncronisation; * they are merely used to allow to set decode_error from both * decoding threads in case of coded slices. */ }}} Example of checking that the output is the same between the two cases: {{{ ffmpeg -threads:v 1 -i "https://megumin.fushizen.eu/samples/2024-04-15-framethread_causes_er_errors…" -f framehash pipe: > 01-hashes_threadless.txt ffmpeg -threads:v 2 -i "https://megumin.fushizen.eu/samples/2024-04-15-framethread_causes_er_errors…" -f framehash pipe: > 02-hashes_threaded.txt git diff --no-index 01-hashes_threadless.txt 02-hashes_threaded.txt }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/10965> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

#10964(undetermined:new): tf_level 4 Defect
by FFmpeg 16 Apr '24

16 Apr '24

#10964: tf_level 4 Defect -------------------------------------+------------------------------------- Reporter: Jigsawbg | Type: defect Status: new | Priority: important Component: | Version: git- undetermined | master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- When using the following settings for hevc_nvenc: -tune 5 -tf_level 4 -lookahead_level 15 The output file is reported as "isTruncated" in MediaInfo. The usual statistics(-stats) after the end of encoding are not displayed. It seems that shortly before it finishes encoding ffmpeg crashes silently. In the log file generated by -reoprt the encoding appears incomplete. With -tf_level 0 , everything seems fine. The problem also exists in version ffmpeg-git-full 2024-04-15-git- 5e380bcdb1. I'm on Windows 10 pro 22H2 OS build 19045.4291 Nvidia RTX 3060Ti Founders Edition Driver 551.86 -- Ticket URL: <https://trac.ffmpeg.org/ticket/10964> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 2

#10781(undetermined:new): undocumented movflags flags
by FFmpeg 15 Apr '24

15 Apr '24

#10781: undocumented movflags flags -------------------------------------+------------------------------------- Reporter: svnpenn | Type: defect Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- this page: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/movenc.c has these `movflags` flags, among others: - `cmaf` - `dash` - `delay_moov` - `frag_discont` - `frag_every_frame` - `global_sidx` - `isml` - `prefer_icc` - `skip_trailer` - `use_metadata_tags` - `write_colr` - `write_gama` however none of the above are documented on either of these pages: - https://ffmpeg.org/ffmpeg-all.html - https://ffmpeg.org/ffmpeg-formats.html -- Ticket URL: <https://trac.ffmpeg.org/ticket/10781> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 1

#4078(ffmpeg:new): Specify audio bitrate per-channel
by FFmpeg 15 Apr '24

15 Apr '24

#4078: Specify audio bitrate per-channel ----------------------------------+--------------------------------------- Reporter: Haravikk | Type: enhancement Status: new | Priority: normal Component: ffmpeg | Version: unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ----------------------------------+--------------------------------------- Fairly self-explanatory, but currently we can specify audio bit-rate for the entire stream, but this requires us to calculate the total bitrate from the number of input channels ourselves. This is fine for single files, but for batch-encoding a mixture of stereo and surround-sound content it's not as ideal, or even for encoding a file that contains multiple audio-streams. To accommodate these use-cases I'd like to request an alternative syntax for specifying audio channels with a per-channel bit-rate so that I can instead just specify say 64k per channel for AAC, with ffmpeg automatically using a total of 128k for stereo or 384k for 5.1 etc. I'm not sure what the best way to do this would be. I suppose one option would be to have a new parameter -bc for "bits per channel", so I could specify something like ffmpeg -i "$INFILE" -acodec aac -bc:a 64k "$OUTFILE" An alternative would be allowing some kind of suffix to the -b option such as: ffmpeg -i "$INFILE" -acodec aac -b:a 64k/c "$OUTFILE" -- Ticket URL: <https://trac.ffmpeg.org/ticket/4078> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 4

#10727(undetermined:new): Need clarification
by FFmpeg 15 Apr '24

15 Apr '24

#10727: Need clarification -------------------------------------+------------------------------------- Reporter: | Type: defect DeveloperEditor | Status: new | Priority: normal Component: | Version: 4.4.4 undetermined | Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: ffmpeg -hide_banner -i input.webm -i elem1.png -i elem2.png -filter_complex "[0:v]pad=ceil(iw/2)*2:ceil(ih/2)*2[v0];[1:v]scale=3840.0:2100.0 [im1];[v0][im1]overlay=0.0:0.0:enable='between(t,20.367686,25.367686)'[v1];[2:v]scale=3840.0:2100.0 [im2];[v1][im2]overlay=0.0:0.0:enable='between(t,47.649863,52.649863)'[v2];[v2]trim=start=18.41:end=93.07, setpts=PTS-STARTPTS [v3];[0:a]atrim=start=18.41:end=93.07,asetpts=PTS- STARTPTS [a1] " -map [v3] -map [a1] -b:a 96k -max_muxing_queue_size 4096 -vcodec libx264 -threads 15 -preset ultrafast -crf 28 -r 30 -movflags faststart video-recording.mp4 This is my ffmpeg command to overlay two images and trim the video. If i input the video with a 4k resolution, My docker machine(8gb ram and 180gb disk ) got rebooted, I thought may be due to the resource is occupied entirely. I am using ffmpeg of version 4.4.4. Where can I find the diff between the versions? and is there any way by altering the command to process the video without rebooting my docker. -- Ticket URL: <https://trac.ffmpeg.org/ticket/10727> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 1

#10763(documentation:new): Improve documentation for random() expression
by FFmpeg 15 Apr '24

15 Apr '24

#10763: Improve documentation for random() expression -------------------------------------+------------------------------------- Reporter: Michael | Type: Koch | enhancement Status: new | Priority: normal Component: | Version: git- documentation | master Keywords: seed | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Please add this to the documentation of the random() expression: random(0) uses the variable 0 as a seed value. The memory of variable 0 is a union of int and double. When used by the expressions ld() and st(), it's double. When used by random(), then it's int. Important thing to remember: If you want to set the random generator to a seed value much different from 0, then you have to use rather big numbers, for example st(0, 2^41). -- Ticket URL: <https://trac.ffmpeg.org/ticket/10763> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 7