March 2020 - FFmpeg-trac - lists.ffmpeg.org

#5551(undetermined:new): av_bsf_send_packet can't take ownership on not reference-counted packets
by FFmpeg 01 Mar '20

01 Mar '20

#5551: av_bsf_send_packet can't take ownership on not reference-counted packets -------------------------------------+------------------------------------- Reporter: mrlika | Type: defect Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Because it doesn't know how to release it. And caller also doesn't know when to delete the packet passed to black-box algorithm. For not reference-counted packets it is more correct to create referenced- counted copy of the packet and leave ownership to the caller. For example av_grow_packet h264_mp4toannexb and h265_mp4toannexb already call av_grow_packet on input packets that just overwrites pkt->data field with newly allocated buffer for not reference-counted packets. It leads to memory leak. -- Ticket URL: <https://trac.ffmpeg.org/ticket/5551> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 7

#8544(ffmpeg:new): LUTRGB inaccurate, affects other colors
by FFmpeg 01 Mar '20

01 Mar '20

#8544: LUTRGB inaccurate, affects other colors ----------------------------------+--------------------------------------- Reporter: chris319 | Type: defect Status: new | Priority: important Component: ffmpeg | Version: unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ----------------------------------+--------------------------------------- Summary of the bug: LUTRGB inaccurate, affects other colors. When used on a white raster of R=255,G=255,B=255, LUTRGB=r=clip(val,47,194) returns:R=188,G=249,B=255. LUTRGB is not clipping to specified value of 194 and is affecting the green channel which is not specified in the command. Pixel format is RGB24 — no subsampling. Above command should return R=194,G=255,B=255, leaving green and blue unchanged. How to reproduce: {{{ ffmpeg -y -i "White.mp4" -c:v libx265 -crf 0 -vf scale=in_range=limited:in_color_matrix=bt709,format=rgb24,lutrgb='r=clip(val,47,194)',scale=out_color_matrix=bt709:out_range=full,format=rgb24 -r 59.94 -an clipped.mp4 Console output: ffmpeg -y -i "White.mp4" -c:v libx265 -crf 0 -vf scale=in_range=full:in_color_matrix=bt709,format=rgb24,lutrgb='r=clip(val,47,194)',scale=out_color_matrix=bt709:out_range=full,format=rgb24 -r 59.94 -an clipped.mp4 ffmpeg version git-2019-12-02-968c4cb Copyright (c) 2000-2019 the FFmpeg developers built with gcc 9.2.1 (GCC) 20191125 configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable- fontconfig --enable-gnutls --enable-iconv --enable-libass --enable- libdav1d --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-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt --enable-amf libavutil 56. 36.101 / 56. 36.101 libavcodec 58. 64.101 / 58. 64.101 libavformat 58. 35.100 / 58. 35.100 libavdevice 58. 9.101 / 58. 9.101 libavfilter 7. 67.100 / 7. 67.100 libswscale 5. 6.100 / 5. 6.100 libswresample 3. 6.100 / 3. 6.100 libpostproc 55. 6.100 / 55. 6.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'White.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf58.29.100 Duration: 00:00:04.00, start: 0.000000, bitrate: 20 kb/s Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709/unknown/bt709), 1920x1080 [SAR 1:1 DAR 16:9], 16 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default) Metadata: handler_name : VideoHandler Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> hevc (libx265)) Press [q] to stop, [?] for help x265 [info]: HEVC encoder version 3.2+15-04db2bfee5d6 x265 [info]: build info [Windows][GCC 9.2.1][64 bit] 8bit+10bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX x265 [warning]: halving the quality when psy-rd is enabled for 444 input. Setting cbQpOffset = 6 and crQpOffset = 6 x265 [info]: Main 4:4:4 profile, Level-4.1 (Main tier) x265 [info]: Thread pool created using 8 threads x265 [info]: Slices : 1 x265 [info]: frame threads / pool features : 3 / wpp(17 rows) x265 [info]: Coding QT: max CU size, min CU size : 64 / 8 x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3 x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00 x265 [info]: Cb/Cr QP Offset : 6 / 6 x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2 x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0 x265 [info]: References / ref-limit cu / depth : 3 / off / on x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1 x265 [info]: Rate Control / qCompress : CRF-0.0 / 0.60 x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip signhide tmvp b-intra x265 [info]: tools: strong-intra-smoothing lslices=6 deblock sao Output #0, mp4, to 'clipped.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf58.35.100 Stream #0:0(und): Video: hevc (libx265) (hev1 / 0x31766568), gbrp, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 59.94 fps, 11988 tbn, 59.94 tbc (default) Metadata: handler_name : VideoHandler encoder : Lavc58.64.101 libx265 Side data: cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A frame= 239 fps= 28 q=-0.0 Lsize= 36kB time=00:00:03.93 bitrate= 75.5kbits/s dup=139 drop=0 speed=0.454x video:31kB audio:0kB subtitle:0kB other streams:0kB global headers:2kB muxing overhead: 18.843916% x265 [info]: frame I: 1, Avg QP:7.53 kb/s: 721.68 x265 [info]: frame P: 76, Avg QP:8.00 kb/s: 62.57 x265 [info]: frame B: 162, Avg QP:10.72 kb/s: 55.94 x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0% x265 [info]: consecutive B-frames: 28.6% 11.7% 19.5% 1.3% 39.0% encoded 239 frames in 8.64s (27.67 fps), 60.84 kb/s, Avg QP:9.84 ffmpeg version built on ... }}} Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8544> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 4

#6414(avformat:new): Possible unintended/unintended access to "pkt->dts"
by FFmpeg 01 Mar '20

01 Mar '20

#6414: Possible unintended/unintended access to "pkt->dts" ----------------------------------+-------------------------------------- Reporter: petrum | Type: defect Status: new | Priority: minor Component: avformat | Version: git-master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ----------------------------------+-------------------------------------- While experimenting with a CodeSonar plugin we develop, we noticed a potential bug in file "FFmpeg/libavformat/mux.c" line 735: if (s->internal->avoid_negative_ts_use_pts) { if (pkt->pts != AV_NOPTS_VALUE && pkt->pts < 0) { av_log(s, AV_LOG_WARNING, "failed to avoid negative " "pts %s in stream %d.\n" "Try -avoid_negative_ts 1 as a possible workaround.\n", /*Line 735*/ av_ts2str(pkt->dts), pkt->stream_index ); } Shouldn't you access pkt->pts (instead of pkt->dts) as in the guard of the second if? Even the string message mentions "pts". How to reproduce: The issue has been detected directly at the source code level in the third party code of the chromium project that uses this code. -- Ticket URL: <https://trac.ffmpeg.org/ticket/6414> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

#7753(ffmpeg:new): yadif_cuda fails, with h264_cuvid decoder
by FFmpeg 01 Mar '20

01 Mar '20

#7753: yadif_cuda fails, with h264_cuvid decoder -------------------------------------+------------------------------------- Reporter: arrmo | Type: defect Status: new | Priority: normal Component: ffmpeg | Version: 4.1 Keywords: yadif_cuda | Blocked By: h264_cuvid | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: Trying to use yadif_cuda. It works fine for an mpeg2ts file, using the HW decoder mpeg2_cuvid ... but try the same thing on an H.264 input, and using h264_cuvid, then it fails. How to reproduce: {{{ % ffmpeg -threads 0 -hwaccel cuvid -c:v h264_cuvid -y -i input.MTS -vf yadif_cuda,scale_npp=1280:-1 -c:v hevc_nvenc -preset slow -cq 10 -g 150 -c:a aac -b:a 128k -metadata:s:a:0 language=eng output.mp4 ffmpeg version n4.1.1 built with gcc 8 (Ubuntu 8.2.0-7ubuntu1) }}} Error message(s) ... {{{ Parsed_yadif_cuda_0 @ 0x56524b398000] cuModuleLoadData(&s->cu_module, vf_yadif_cuda_ptx) failed -> CUDA_ERROR_UNKNOWN: unknown error [Parsed_yadif_cuda_0 @ 0x56524b398000] Failed to configure output pad on Parsed_yadif_cuda_0 Error reinitializing filters! Failed to inject frame into filter network: Invalid data found when processing input Error while processing the decoded data for stream #0:0 }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/7753> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 13

#8094(undetermined:new): Memory leaks from realloc
by FFmpeg 01 Mar '20

01 Mar '20

#8094: Memory leaks from realloc -------------------------------------+------------------------------------- Reporter: Suhwan | Type: defect Status: new | Priority: normal Component: | Version: git- undetermined | master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: There is a memory leak from realloc How to reproduce: {{{ % ./ffmpeg_g -i audio-gaps.ogg -loglevel 99 -c copy -map 0 -y -disposition:v:174 a64multi -c:a:171 a64multi -disposition:s:9 a64multi -stream_loop 24 -t 3 -target vcd -r 82 -ab 907 -ar 22050 -ac 4 -b:v 866k -level 12 -strict 3 tmp.mp4 ffmpeg version git-master built on ... clang-6.0 }}} ASAN report: {{{ ==48423==ERROR: LeakSanitizer: detected memory leaks Direct leak of 96 byte(s) in 3 object(s) allocated from: #0 0x4de8d0 in realloc (ffmpeg_g+0x4de8d0) #1 0x5ce398 in grow_array ffmpeg/fftools/cmdutils.c:2163:24 Indirect leak of 34 byte(s) in 6 object(s) allocated from: #0 0x4de8d0 in realloc (ffmpeg_g+0x4de8d0) #1 0x8500297 in av_realloc ffmpeg/libavutil/mem.c:144:12 #2 0x8500297 in av_strdup ffmpeg/libavutil/mem.c:256 #3 0x5b5001 in parse_optgroup ffmpeg/fftools/cmdutils.c:437:15 Indirect leak of 15 byte(s) in 2 object(s) allocated from: #0 0x4de8d0 in realloc (ffmpeg_g+0x4de8d0) #1 0x8500297 in av_realloc ffmpeg/libavutil/mem.c:144:12 #2 0x8500297 in av_strdup ffmpeg/libavutil/mem.c:256 #3 0x5b5001 in parse_optgroup ffmpeg/fftools/cmdutils.c:437:15 #4 0x69746c756d343660 (<unknown module>) SUMMARY: AddressSanitizer: 145 byte(s) leaked in 11 allocation(s). }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/8094> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 6