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

#3950(undetermined:new): HEVC HM10 crash
by FFmpeg 28 Apr '22

28 Apr '22

#3950: HEVC HM10 crash -------------------------------------+------------------------------------- Reporter: Krakean | Type: defect Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- https://yadi.sk/d/0zGplttPbUQKp - this sample crashes on playback end. (in ff_hevc_nb_refs) https://yadi.sk/d/Xc0jl9tXbUQF3 - immediately crash. It's ok that ffmpeg doesn't support HM10, but I don't think that crash is good solution. Why to crash, if don't crash it's better? :) -- Ticket URL: <https://trac.ffmpeg.org/ticket/3950> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

#3811(undetermined:new): Misleading error when segmenting H.264 bitstream to MPEG-TS with wrong segment muxer
by FFmpeg 08 Apr '22

08 Apr '22

#3811: Misleading error when segmenting H.264 bitstream to MPEG-TS with wrong segment muxer -------------------------------------+------------------------------------- Reporter: slhck | Type: defect Status: new | Priority: normal Component: | Version: git- undetermined | master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- I was trying to segment an existing H.264/MP4 file into TS segments: {{{ ffmpeg -y -i tmp/tmpPass2.mp4 -c:v libx264 -acodec copy -map 0 -f segment -bsf h264_mp4toannexb -segment_time 5 -segment_format mpegts ./tsSegmentsDisplay/SRC04_Q1_%05d.ts ffmpeg version N-64919-ga613257 Copyright (c) 2000-2014 the FFmpeg developers built on Jul 23 2014 00:35:22 with gcc 4.8.3 (GCC) configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-decklink --enable-zlib libavutil 52. 92.101 / 52. 92.101 libavcodec 55. 69.100 / 55. 69.100 libavformat 55. 48.101 / 55. 48.101 libavdevice 55. 13.102 / 55. 13.102 libavfilter 4. 11.102 / 4. 11.102 libswscale 2. 6.100 / 2. 6.100 libswresample 0. 19.100 / 0. 19.100 libpostproc 52. 3.100 / 52. 3.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'tmp/tmpPass2.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf55.33.100 Duration: 00:00:56.66, start: 0.161134, bitrate: 8528 kb/s Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 8484 kb/s, 24 fps, 24 tbr, 12288 tbn, 48 tbc (default) Metadata: handler_name : VideoHandler Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 64 kb/s (default) Metadata: handler_name : SoundHandler [libx264 @ 0000000004db87a0] using SAR=1/1 [libx264 @ 0000000004db87a0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2 [libx264 @ 0000000004db87a0] profile High, level 4.0 [libx264 @ 0000000004db87a0] 264 - core 142 r2431 ac76440 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=12 lookahead_threads=2 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=24 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00 [mpegts @ 0000000006f42440] Using AVStream.codec.time_base as a timebase hint to the muxer is deprecated. Set AVStream.time_base instead. Last message repeated 1 times [adts @ 0000000006f567e0] Using AVStream.codec.time_base as a timebase hint to the muxer is deprecated. Set AVStream.time_base instead. Output #0, segment, to './tsSegmentsDisplay/SRC04_Q1_%05d.ts': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf55.48.101 Stream #0:0(und): Video: h264 (libx264), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 24 fps, 24 tbn, 24 tbc (default) Metadata: handler_name : VideoHandler encoder : Lavc55.69.100 libx264 Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 44100 Hz, stereo, 64 kb/s (default) Metadata: handler_name : SoundHandler Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264)) Stream #0:1 -> #0:1 (copy) Press [q] to stop, [?] for help [libx264 @ 0000000004db8340] Packet header is not contained in global extradata, corrupted stream or invalid MP4/AVCC bitstream Failed to open bitstream filter h264_mp4toannexb for stream 0 with codec libx264: Invalid argument [mpegts @ 0000000006f42440] H.264 bitstream malformed, no startcode found, use the h264_mp4toannexb bitstream filter (-bsf h264_mp4toannexb) av_interleaved_write_frame(): Invalid argument frame= 57 fps= 33 q=-1.0 Lsize=N/A time=00:00:02.69 bitrate=N/A dup=4 drop=0 video:201kB audio:21kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown [libx264 @ 0000000004db87a0] frame I:1 Avg QP:19.95 size:204698 [libx264 @ 0000000004db87a0] frame P:19 Avg QP:21.95 size: 42957 [libx264 @ 0000000004db87a0] frame B:37 Avg QP:26.12 size: 9696 [libx264 @ 0000000004db87a0] consecutive B-frames: 3.5% 7.0% 68.4% 21.1% [libx264 @ 0000000004db87a0] mb I I16..4: 36.5% 18.1% 45.4% [libx264 @ 0000000004db87a0] mb P I16..4: 7.0% 6.7% 1.7% P16..4: 32.9% 13.2% 7.7% 0.0% 0.0% skip:30.7% [libx264 @ 0000000004db87a0] mb B I16..4: 0.9% 1.2% 0.1% B16..8: 38.4% 3.9% 0.5% direct: 1.3% skip:53.7% L0:46.9% L1:44.3% BI: 8.9% [libx264 @ 0000000004db87a0] 8x8 transform intra:40.2% inter:58.4% [libx264 @ 0000000004db87a0] coded y,uvDC,uvAC intra: 33.5% 48.0% 23.3% inter: 11.4% 13.0% 1.2% [libx264 @ 0000000004db87a0] i16 v,h,dc,p: 33% 29% 19% 19% [libx264 @ 0000000004db87a0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 40% 19% 36% 1% 1% 1% 1% 1% 1% [libx264 @ 0000000004db87a0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 42% 34% 11% 2% 2% 2% 3% 2% 3% [libx264 @ 0000000004db87a0] i8c dc,h,v,p: 48% 23% 25% 4% [libx264 @ 0000000004db87a0] Weighted P-Frames: Y:0.0% UV:0.0% [libx264 @ 0000000004db87a0] ref P L0: 76.1% 14.4% 6.4% 3.1% [libx264 @ 0000000004db87a0] ref B L0: 86.1% 11.9% 2.0% [libx264 @ 0000000004db87a0] ref B L1: 86.7% 13.3% [libx264 @ 0000000004db87a0] kb/s:4647.21 Conversion failed! }}} It tells me: {{{ [libx264 @ 0000000004db8340] Packet header is not contained in global extradata, corrupted stream or invalid MP4/AVCC bitstream Failed to open bitstream filter h264_mp4toannexb for stream 0 with codec libx264: Invalid argument [mpegts @ 0000000006f42440] H.264 bitstream malformed, no startcode found, use the h264_mp4toannexb bitstream filter (-bsf h264_mp4toannexb) }}} But I'm already using said bitstream filter, which it can't open. In this case, the real solution would've been to use the ssegment muxer instead of segment, but this is absolutely not obvious from the error messages. There should be a hint to use another muxer when using .ts segments and H.264 bitstreams. The current error messages are misleading. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3811> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 13

#3788(undetermined:new): [SMK] Seek error
by FFmpeg 08 Apr '22

08 Apr '22

#3788: [SMK] Seek error -------------------------------------+------------------------------------- Reporter: | Type: defect Underground78 | Priority: normal Status: new | Version: git- Component: | master undetermined | Blocked By: Keywords: | Reproduced by developer: 0 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- The attached SMK file causes a seek error which is easily reproducible with ffplay (and probably ffmpeg since it affects other ffmpeg lib based tools). {{{ > ffplay.exe IVYDES.SMK ffplay version N-64796-gd5ee358 Copyright (c) 2003-2014 the FFmpeg developers built on Jul 19 2014 03:24:50 with gcc 4.8.3 (GCC) configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab le-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable- libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable- libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable- librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --en able-libvidstab --enable-libvo-aacenc --enable-libvo-mrwbenc --enable- libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable- libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable- decklink --enable-zlib libavutil 52. 92.101 / 52. 92.101 libavcodec 55. 69.100 / 55. 69.100 libavformat 55. 48.101 / 55. 48.101 libavdevice 55. 13.102 / 55. 13.102 libavfilter 4. 11.102 / 4. 11.102 libswscale 2. 6.100 / 2. 6.100 libswresample 0. 19.100 / 0. 19.100 libpostproc 52. 3.100 / 52. 3.100 Input #0, smk, from 'IVYDES.SMK': 0KB vq= 0KB sq= 0B f=0/0 Duration: 00:00:03.10, start: 0.000000, bitrate: 502 kb/s Stream #0:0: Video: smackvideo (SMK2 / 0x324B4D53), pal8, 200x136, 10 tbr, 10 tbn, 10 tbc Seek to 43% ( 0:00:01) of total duration ( 0:00:03) B f=0/0 IVYDES.SMK: error while seeking }}} I tried the file with RAD Video Tools without seeing anything strange but I don't know this format at all. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3788> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#3801(undetermined:new): SWSCALE: Incorrect Values in Full Range Conversion RGB to YCbCr
by FFmpeg 27 Feb '22

27 Feb '22

#3801: SWSCALE: Incorrect Values in Full Range Conversion RGB to YCbCr -------------------------------------+------------------------------------- Reporter: troy_s | Type: defect Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: FFMPEG is potentially delivering values that deviate from theoretical results in RGB to YCbCr conversions. This case applies to RGB to full range YCbCr conversion, using REC.709 coefficients on the input. {{{ ./ffmpeg -i ~/Documents/FFMPEG\ Color\ Research/ARIB_STD-B28.png -pix_fmt yuv444p -vcodec rawvideo -f rawvideo -vf scale="in_range=full:in_color_matrix=bt709:out_range=full:out_color_matrix=bt709" test-full.yuv ffmpeg version N-64958-gce8e27e Copyright (c) 2000-2014 the FFmpeg developers built on Jul 24 2014 10:54:07 with gcc 4.7 (Ubuntu/Linaro 4.7.3-12ubuntu1) configuration: --enable-gpl --enable-libx264 --enable-shared --disable- static --enable-pic WARNING: library configuration mismatch avutil configuration: --enable-gpl --enable-libx264 --disable-asm --enable-shared --disable-static --enable-pic avcodec configuration: --enable-gpl --enable-libx264 --disable-asm --enable-shared --disable-static --enable-pic avformat configuration: --enable-gpl --enable-libx264 --disable-asm --enable-shared --disable-static --enable-pic avdevice configuration: --enable-gpl --enable-libx264 --disable-asm --enable-shared --disable-static --enable-pic avfilter configuration: --enable-gpl --enable-libx264 --disable-asm --enable-shared --disable-static --enable-pic swscale configuration: --enable-gpl --enable-libx264 --disable-asm --enable-shared --disable-static --enable-pic swresample configuration: --enable-gpl --enable-libx264 --disable-asm --enable-shared --disable-static --enable-pic postproc configuration: --enable-gpl --enable-libx264 --disable-asm --enable-shared --disable-static --enable-pic libavutil 52. 92.101 / 52. 92.101 libavcodec 55. 69.100 / 55. 69.100 libavformat 55. 49.100 / 55. 49.100 libavdevice 55. 13.102 / 55. 13.102 libavfilter 4. 11.102 / 4. 11.102 libswscale 2. 6.100 / 2. 6.100 libswresample 0. 19.100 / 0. 19.100 libpostproc 52. 3.100 / 52. 3.100 Input #0, image2, from '/home/aphorism/Documents/FFMPEG Color Research/ARIB_STD-B28.png': Duration: 00:00:00.04, start: 0.000000, bitrate: N/A Stream #0:0: Video: png, rgb24, 1920x1080 [SAR 2835:2835 DAR 16:9], 25 tbr, 25 tbn, 25 tbc Output #0, rawvideo, to 'test-full.yuv': Metadata: encoder : Lavf55.49.100 Stream #0:0: Video: rawvideo (444P / 0x50343434), yuv444p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc Metadata: encoder : Lavc55.69.100 rawvideo Stream mapping: Stream #0:0 -> #0:0 (png (native) -> rawvideo (native)) Press [q] to stop, [?] for help frame= 1 fps=0.0 q=0.0 Lsize= 6075kB time=00:00:00.04 bitrate=1244160.0kbits/s video:6075kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000% }}} The above command delivers the attachment test-full-444-out.png, with Y, Cb, and Cr a pure dump of the results into the R, G, and B channels of the image. No color transformations have been applied. The file ARIB_STD-B28.png is an 8 bit representation of a SMPTE test pattern, based off of a 32 bit float version. The file ARIB_STD-B28_YCbCr_full.png is a theoretically correct transformation of the ARIB_STD-B28.png test pattern into YCbCr using REC.709 coefficients. It is based off of a 32 bit EXR input. The file test-full-diff.png is a heat-map difference, with red areas indicating deviations between the theoretical results and the actual. The SMPTE test pattern black set test stripes at the very bottom contain one stripe that sources at -2%, and as such, will always be incorrect unless float values are provided for input. As such, it is the single bar that can be ignored. Potentially Related Issues: https://trac.ffmpeg.org/ticket/3794 -- Ticket URL: <https://trac.ffmpeg.org/ticket/3801> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 13

#3683(avformat:new): ffmpeg misdetects duration for mpeg file generated using ffmpeg (one frame short)
by FFmpeg 10 Feb '22

10 Feb '22

#3683: ffmpeg misdetects duration for mpeg file generated using ffmpeg (one frame short) ----------------------------------+--------------------------------------- Reporter: rmk | Type: defect Status: new | Priority: normal Component: avformat | Version: unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ----------------------------------+--------------------------------------- The following sequence of commands shows the problem: ffmpeg -f lavfi -i nullsrc=s=256x256:d=1.0 -c:v mpeg2video out.mpg ffmpeg version N-63519-g61917a1 Copyright (c) 2000-2014 the FFmpeg developers built on May 28 2014 14:40:18 with Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) configuration: libavutil 52. 87.100 / 52. 87.100 libavcodec 55. 65.100 / 55. 65.100 libavformat 55. 41.100 / 55. 41.100 libavdevice 55. 13.101 / 55. 13.101 libavfilter 4. 5.100 / 4. 5.100 libswscale 2. 6.100 / 2. 6.100 libswresample 0. 19.100 / 0. 19.100 Input #0, lavfi, from 'nullsrc=s=256x256:d=1.0': Duration: N/A, start: 0.000000, bitrate: N/A Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 256x256 [SAR 1:1 DAR 1:1], 25 tbr, 25 tbn, 25 tbc [mpeg @ 0x7fedba801600] VBV buffer size not set, using default size of 130KB If you want the mpeg file to be compliant to some specification Like DVD, VCD or others, make sure you set the correct buffer size Output #0, mpeg, to 'out.mpg': Metadata: encoder : Lavf55.41.100 Stream #0:0: Video: mpeg2video, yuv420p, 256x256 [SAR 1:1 DAR 1:1], q=2-31, 200 kb/s, 25 fps, 90k tbn, 25 tbc Metadata: encoder : Lavc55.65.100 mpeg2video Stream mapping: Stream #0:0 -> #0:0 (rawvideo -> mpeg2video) Press [q] to stop, [?] for help frame= 25 fps=0.0 q=1.6 Lsize= 130kB time=00:00:00.96 bitrate=1109.3kbits/s video:127kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.983437% ffmpeg -i out.mpg ffmpeg version N-63519-g61917a1 Copyright (c) 2000-2014 the FFmpeg developers built on May 28 2014 14:40:18 with Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) configuration: libavutil 52. 87.100 / 52. 87.100 libavcodec 55. 65.100 / 55. 65.100 libavformat 55. 41.100 / 55. 41.100 libavdevice 55. 13.101 / 55. 13.101 libavfilter 4. 5.100 / 4. 5.100 libswscale 2. 6.100 / 2. 6.100 libswresample 0. 19.100 / 0. 19.100 Input #0, mpeg, from 'out.mpg': Duration: 00:00:00.96, start: 0.540000, bitrate: 1109 kb/s Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p(tv), 256x256 [SAR 1:1 DAR 1:1], max. 104857 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc At least one output file must be specified The duration is misdetected as 0.96 instead of 1.0, i.e. one frame short. Note that this is not a problem of the nullsrc filter. I have run into this problem with files generated via transcoding but have used the source example so no upload is required. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3683> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

#3409(undetermined:new): Impossible to transcode full range RGB videos with libx264, and keep full range + proper colors
by FFmpeg 15 Jan '22

15 Jan '22

#3409: Impossible to transcode full range RGB videos with libx264, and keep full range + proper colors -------------------------------------+------------------------------------- Reporter: mzso | Type: defect Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- I encountered this while trying to transcode screencasted videos with fraps or ut-video streams. When using yuv444p pixel format I get washed out, too light videos. "-color_range" has no affect. People suggested: "-vf colormatrix=bt601:bt709" But it also doesn't have an affect. x264 itself has issues with RGB full range videos, if I use i444 with it I also get improper output. But if I use "--output-csp rgb" it succeds in encoding a proper output file, though with a large file size. I can't even achieve this with ffmpeg because it doesn't let me use RGB with libx264: "Incompatible pixel format 'rgb24' for codec 'libx264', auto-selecting format 'yuv444p'" -- Ticket URL: <https://trac.ffmpeg.org/ticket/3409> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 24

#3389(ffmpeg:new): Feature Request - Isolate and normalize video content
by FFmpeg 28 Aug '21

28 Aug '21

#3389: Feature Request - Isolate and normalize video content -------------------------------------+------------------------------------- Reporter: Rafajafar | Type: Status: new | enhancement Component: ffmpeg | Priority: wish Keywords: feature | Version: request normalize video | unspecified Blocking: | Blocked By: Analyzed by developer: 0 | Reproduced by developer: 0 -------------------------------------+------------------------------------- Hey, I have an interesting problem and I'm solving it with OpenCV. It's be great if the solution could come straight from ffmpeg, though! I need to: 1) cropdetect 2) crop surrounding borders from a video 3) resize video to normalize its dimensions In other words, all I want is one command that will detect the frame-by- frame borders and in the same step, crop it, and also resize it. And I want this done for the entire video, not a single frame. It's gotta be possible, right? The applications are very useful in video analysis. I've spoken to colleagues of mine and they are doing this manually themselves. It would be great to be able to work this feature into the automation surrounding ffmpeg in our tools. My personal application, for instance, is in detecting videos that are similar using content perceptual hashing. Another colleague of mine works for the Center for Missing and Exploited Children. He does similar work, but with pHashing. I can see applications for ContentID type systems across the board. I'm sure this is a low on the totem pole request, but if you have any spare cycles, this would really rock in the world of computer vision and video analysis! Thanks for your consideration, --Collin -- Ticket URL: <https://trac.ffmpeg.org/ticket/3389> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 4

#3692(avcodec:new): dpx samples (possibly broken) look broken with FFmpeg, work fine with ImageMagick
by FFmpeg 07 May '21

07 May '21

#3692: dpx samples (possibly broken) look broken with FFmpeg, work fine with ImageMagick --------------------------------------+--------------------------------- Reporter: cehoyos | Owner: Type: defect | Status: new Priority: normal | Component: avcodec Version: git-master | Keywords: dpx Blocked By: | Blocking: Reproduced by developer: 0 | Analyzed by developer: 0 --------------------------------------+--------------------------------- http://www.simplesystems.org/users/bfriesen/dpx/ contains three dpx samples, one (16 bit) looks ugly with FFmpeg, ImageMagick and GraphicsMagick, the other two (8 bit) only look broken with FFmpeg. {{{ $ ffmpeg -i DLAD_8b_1c_big.dpx ffmpeg version N-63624-g4ba8560 Copyright (c) 2000-2014 the FFmpeg developers built on May 31 2014 12:24:49 with gcc 4.7 (SUSE Linux) configuration: --enable-gpl libavutil 52. 87.100 / 52. 87.100 libavcodec 55. 65.100 / 55. 65.100 libavformat 55. 42.100 / 55. 42.100 libavdevice 55. 13.101 / 55. 13.101 libavfilter 4. 5.100 / 4. 5.100 libswscale 2. 6.100 / 2. 6.100 libswresample 0. 19.100 / 0. 19.100 libpostproc 52. 3.100 / 52. 3.100 Input #0, image2, from 'DLAD_8b_1c_big.dpx': Duration: 00:00:00.04, start: 0.000000, bitrate: N/A Stream #0:0: Video: dpx, gray, 255x185 [SAR 1:1 DAR 51:37], 25 tbr, 25 tbn, 25 tbc At least one output file must be specified }}} {{{ $ ffmpeg -i DLAD_8b_3c_big.dpx ffmpeg version N-63624-g4ba8560 Copyright (c) 2000-2014 the FFmpeg developers built on May 31 2014 12:24:49 with gcc 4.7 (SUSE Linux) configuration: --enable-gpl libavutil 52. 87.100 / 52. 87.100 libavcodec 55. 65.100 / 55. 65.100 libavformat 55. 42.100 / 55. 42.100 libavdevice 55. 13.101 / 55. 13.101 libavfilter 4. 5.100 / 4. 5.100 libswscale 2. 6.100 / 2. 6.100 libswresample 0. 19.100 / 0. 19.100 libpostproc 52. 3.100 / 52. 3.100 Input #0, image2, from 'DLAD_8b_3c_big.dpx': Duration: 00:00:00.04, start: 0.000000, bitrate: N/A Stream #0:0: Video: dpx, rgb24, 255x185 [SAR 1:1 DAR 51:37], 25 tbr, 25 tbn, 25 tbc At least one output file must be specified }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/3692> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

#3785(undetermined:new): SWSCALE: in_range, in_color_matrix, out_range, out_color_matrix incorrect
by FFmpeg 24 Apr '21

24 Apr '21

#3785: SWSCALE: in_range, in_color_matrix, out_range, out_color_matrix incorrect -------------------------------------+------------------------------------- Reporter: troy_s | Type: defect Status: new | Priority: normal Component: | Version: git- undetermined | master Keywords: | Blocked By: colormanagement colorspace 709 | Reproduced by developer: 0 601 | Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- '''Summary of the bug''': Seems that swscale is still sadly mangling RGB to YCbCr and vice versa transforms. Disabled all ASM speedups to avoid code path issues, as were previously hard coded to 601 coefficents etc. '''How to reproduce''': Encode a test chart and check values. Test chart available from http://www .belle-nuit.com/test-chart. '''Expected versus Results''': BT.709 and sRGB share identical luminance coefficients. An sRGB image, encoded at full range using BT.709 primaries should decode to a perfect 1:1 regarding RGB values, compression notwithstanding. Sampling the upper row of colors using the provided test chart, we can see some issues with the encoding / decoding step, when using FFPLAY with the corresponding scale commands. For example, an encode using {{{ ./ffmpeg -loop 1 -i ~/Downloads/testchart.tif -t 3 -c:v h264 -vf "scale=in_range=full:in_color_matrix=bt709:out_range=full:out_color_matrix=bt709" out709-full.mp4 }}} Should produce a perfect 1:1 when played back with {{{ ./ffplay -vf "scale=in_range=full:in_color_matrix=bt709:out_range=full:out_color_matrix=bt709" out709-full.mp4 }}} When we sample the sRGB / 709 values using an image editor, the top row should result in RGB values as follows: {{{ Name R G B Yellow: 180 180 16 Cyan: 16 180 180 Magenta: 180 16 180 Green: 16 180 16 Red: 180 16 16 Blue: 16 16 180 }}} Given that 709 and sRGB share identical primaries, and broadcast scaling is set to full range, there should be a perfect 1:1 result with the values. However, what we find with playback via the ffmpeg command set with proper values is: {{{ Name R G B Yellow: 179 190 22 Cyan: 31 197 180 Magenta: 167 0 176 Green: 30 209 21 Red: 166 0 19 Blue: 17 5 173 }}} There appears to be breakage with regard to the application of the coefficients, as well as possibly misinterpretation of the full range settings. The are some transforms that yield vaguely close values. However, these suffer from quantization issues where no such should occur. It would seem that all transformations are likely being performed at the relative bit depth for performance. Sadly, this corrupts the values quite significantly. {{{ ./ffmpeg -loop 1 -i ~/Downloads/testchart.tif -t 3 -c:v h264 -vf "scale=in_range=full:in_color_matrix=bt601:out_range=full:out_color_matrix=bt601" out601-full.mp4 }}} The following, despite being 601 coefficients, should yield perfect 1:1 with RGB values (RGB being a relative color space) but quantization issues again result. {{{ ./ffplay -vf "scale=in_range=full:in_color_matrix=bt601:out_range=full:out_color_matrix=bt601" out601-full.mp4 }}} Further testing of the in_range and out_range specifics will be conducted when the basic color coefficients issue is corrected. '''Conclusion''': Some mangling is still present in the color handling in FFMPEG. Quantization issues can likely be expected until a float (likely non- realtime) option is introduced for higher quality frame by frame encoding / decoding. However, even with quantization issues, the encoding / decoding coefficients are not responding / respected in correct fashion for 709 to 709 (1:1 with sRGB content). -- Ticket URL: <https://trac.ffmpeg.org/ticket/3785> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 30

#3794(swscale:new): SWSCALE: Quantization Errors in Y Studio Range
by FFmpeg 19 Apr '21

19 Apr '21

#3794: SWSCALE: Quantization Errors in Y Studio Range ------------------------------------+-------------------------------------- Reporter: troy_s | Type: defect Status: new | Priority: normal Component: swscale | Version: git-master Keywords: 709 Y luma | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ------------------------------------+-------------------------------------- Summary of the bug: It appears FFMPEG has some +/- single unit quantization errors in the YCbCr transform. How to reproduce: Generate a raw YCbCr image and diff against theoretically correct values. {{{ ./ffmpeg -i ~/Documents/FFMPEG\ Color\ Research/ARIB_STD-B28.png -pix_fmt yuv444p -vcodec rawvideo -f rawvideo -vf scale="in_range=full:in_color_matrix=bt709:out_range=full:out_color_matrix=bt709" test.yuv ffmpeg version N-64815-gb53bdae Copyright (c) 2000-2014 the FFmpeg developers built on Jul 19 2014 16:33:49 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1) configuration: --enable-gpl --enable-libx264 --disable-asm libavutil 52. 92.101 / 52. 92.101 libavcodec 55. 69.100 / 55. 69.100 libavformat 55. 48.101 / 55. 48.101 libavdevice 55. 13.102 / 55. 13.102 libavfilter 4. 11.102 / 4. 11.102 libswscale 2. 6.100 / 2. 6.100 libswresample 0. 19.100 / 0. 19.100 libpostproc 52. 3.100 / 52. 3.100 Input #0, image2, from '/home/aphorism/Documents/FFMPEG Color Research/ARIB_STD-B28.png': Duration: 00:00:00.04, start: 0.000000, bitrate: N/A Stream #0:0: Video: png, rgb24, 1920x1080 [SAR 2835:2835 DAR 16:9], 25 tbr, 25 tbn, 25 tbc Output #0, rawvideo, to 'test.yuv': Metadata: encoder : Lavf55.48.101 Stream #0:0: Video: rawvideo (444P / 0x50343434), yuv444p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc Metadata: encoder : Lavc55.69.100 rawvideo Stream mapping: Stream #0:0 -> #0:0 (png (native) -> rawvideo (native)) Press [q] to stop, [?] for help frame= 1 fps=0.0 q=0.0 Lsize= 6075kB time=00:00:00.04 bitrate=1244160.0kbits/s video:6075kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000% }}} Diff'd versions of the theoretically ideal values versus FFMPEG's output. Lowest red stripe is due to theoretical version preserving the -2% patch, and not relevant. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3794> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 16