June 2016 - FFmpeg-trac - lists.ffmpeg.org

#4127(undetermined:new): h264 DXVA2 decoding regression on Intel GPUs
by FFmpeg 13 May '22

13 May '22

#4127: h264 DXVA2 decoding regression on Intel GPUs -------------------------------------+------------------------------------- Reporter: johsmi | 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: h264 DXVA2 decoding regression on Intel GPUs caused by commit: http://git.videolan.org/?p=ffmpeg.git;a=commit;h=9e5ef1c5c37208326c59d642e2… This was first noticed as a green start on some h264 streams in Kodi Helix. See ticket http://trac.xbmc.org/ticket/15498 for additional history. How to reproduce: {{{ ffmpeg -v repeat+debug -hwaccel dxva2 -threads 1 -i green_start.mkv green_start.avi }}} Using this sample clip: https://www.dropbox.com/s/5rr66ptquuju5zz/green_start.mkv?dl=0 -- Ticket URL: <https://trac.ffmpeg.org/ticket/4127> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 4

#5404(avcodec:new): Missing output frames in h264 decoder with stream already demuxed from MPEGTS
by FFmpeg 11 May '22

11 May '22

#5404: Missing output frames in h264 decoder with stream already demuxed from MPEGTS -------------------------------------+------------------------------------- Reporter: pcabarat | Type: defect Status: new | Priority: critical Component: avcodec | Version: git- Keywords: h264 MPEGTS | master missing frames | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: .yuv direct output from .ts and .yuv output from demuxed .ts to .h264 are different when decoding. FFmpeg version info : {{{ ffmpeg version N-79243-g54c9146 Copyright (c) 2000-2016 the FFmpeg developers built with gcc 5.2.1 (Ubuntu 5.2.1-22ubuntu2) 20151010 configuration: libavutil 55. 20.100 / 55. 20.100 libavcodec 57. 33.100 / 57. 33.100 libavformat 57. 29.101 / 57. 29.101 libavdevice 57. 0.101 / 57. 0.101 libavfilter 6. 40.102 / 6. 40.102 libswscale 4. 1.100 / 4. 1.100 libswresample 2. 0.101 / 2. 0.101 }}} The h264 stream was obtained from the .ts this way {{{ % ./ffmpeg -i 5_OldTownCross_544p50_AVC_QP23.ts -vcodec copy -an -f h264 -copyts 5_OldTownCross_544p50_AVC_QP23.h264 }}} Here is how the .yuv output was directly obtained from the .ts file {{{ % ./ffmpeg -i 5_OldTownCross_544p50_AVC_QP23.ts oldtown_ts.yuv }}} Here is how the .yuv output was obtained from the demuxed h264 stream {{{ % ./ffmpeg -i 5_OldTownCross_544p50_AVC_QP23.h264 oldtown_h264.yuv }}} Size of . yuv files aren't the same and when trying to compare files {{{ % cmp oldtown_h264.yuv oldtown_ts.yuv }}} I compared both output results with the JM reference software output and the correct one is oldtown_ts.yuv After a quick analysis,I realized that frames 1 2 and 3 in display order (starting from 0) have gone missing in oldtown_h264.yuv Logs are to long to be reported here, since the bug seems reproducible, the stream I used is available here : [http://www.datafilehost.com/d/998fef61] The problem seems to be related to buffer reordering which does not occur when directly decoding from .ts {{{ [h264 @ 0x2fd8560] Increasing reorder buffer to 1 [h264 @ 0x2fd8560] no picture [h264 @ 0x2fd8560] Increasing reorder buffer to 2 [h264 @ 0x2fd8560] no picture ooo [h264 @ 0x2fd8560] Increasing reorder buffer to 3 [h264 @ 0x2fd8560] no picture ooo Last message repeated 1 times }}} (ooo) seems to mean a picture is out_of _order, in h264.c I think it has to do with h264 decoder way of handling its frame unreferencing at the beginning of decoding but I can't find the reason it works when decoding from the .ts and don't from the stream. -- Ticket URL: <https://trac.ffmpeg.org/ticket/5404> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 6

#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

#4304(avfilter:new): Add Spatial Information (SI) / Temporal Informatilon (SI) filter according to ITU-T P.910
by FFmpeg 05 Apr '22

05 Apr '22

#4304: Add Spatial Information (SI) / Temporal Informatilon (SI) filter according to ITU-T P.910 ----------------------------------+--------------------------------------- Reporter: slhck | Type: enhancement Status: new | Priority: wish Component: avfilter | Version: unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ----------------------------------+--------------------------------------- ITU-T P.910 ("Subjective video quality assessment methods for multimedia applications") specifies two metrics that can be used to classify content: == Spatial information == According to P.910: The spatial perceptual information (SI) is based on the Sobel filter. Each video frame (luminance plane) at time n (Fn) is first filtered with the Sobel filter [Sobel(Fn)]. The standard deviation over the pixels (stdspace) in each Sobel-filtered frame is then computed. This operation is repeated for each frame in the video sequence and results in a time series of spatial information of the scene. The maximum value in the time series (maxtime) is chosen to represent the spatial information content of the scene. == Temporal information == According to P.910: The temporal perceptual information (TI) is based upon the motion difference feature, Mn(i, j), which is the difference between the pixel values (of the luminance plane) at the same location in space but at successive times or frames. Mn(i, j) as a function of time (n) is defined as: [[Image(http://i.imgur.com/MRsJtdT.png)]] here Fn(i, j) is the pixel at the ith row and jth column of nth frame in time. The measure of temporal information (TI) is computed as the maximum over time (maxtime) of the standard deviation over space (stdspace) of Mn(i, j) over all i and j. [[Image(http://i.imgur.com/zRXcVJO.png)]] More motion in adjacent frames will result in higher values of TI. == What should be implemented == There should be a `siti` filter which outputs: * The SI value for each frame * Summary SI statistics (mean, min, max, median) for the sequence * The TI value for the sequence It requires no output video and would just print to the console. (This feature request serves as a reference for me and others; I might implement it some day, maybe when filter kernels are implemented.) -- Ticket URL: <https://trac.ffmpeg.org/ticket/4304> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 1

#4805(undetermined:new): swscale does not process pixels when only color-matrix differs between input and output
by FFmpeg 20 Mar '22

20 Mar '22

#4805: swscale does not process pixels when only color-matrix differs between input and output -------------------------------------+------------------------------------- Reporter: rmk | Type: Status: new | enhancement Component: | Priority: normal undetermined | Version: Keywords: | unspecified Blocking: | Blocked By: Analyzed by developer: 0 | Reproduced by developer: 0 -------------------------------------+------------------------------------- swscale does not seem to process pixels when only color-matrix differs between input and output (i.e. pixel format and size remain the same). It would be great to be able to use swscale also just for colorspace transformations like for bt601<->bt709 conversions. Observed this as api user but verified it by converting two files as follows and comparing them via framemd5: ffmpeg -i fcp7_xdcam_ex_1080_25p_1s.mov -vf scale=in_color_matrix=bt709:out_color_matrix=bt601 -c:v ffv1 -an scale_test_bt601.nut ffmpeg -i xdcam_ex/fcp7_xdcam_ex_1080_25p_1s.mov -c:v ffv1 -an scale_test_unscaled.nut The frames of the resulting files are identical. -- Ticket URL: <https://trac.ffmpeg.org/ticket/4805> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 9

#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

#5407(undetermined:new): WavePack correction file (hybrid mode)
by FFmpeg 23 Feb '22

23 Feb '22

#5407: WavePack correction file (hybrid mode) -------------------------------------+------------------------------------- Reporter: | Type: Underground78 | enhancement Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- As far as I can tell ffmpeg is currently not able to use WavePack correction file when decoding a WavePack track. It would be great if this could be implemented. Relevant excerpt from WavePack user documentation: > If the -c option is specified (in addition to the -b option), then WavPack will generate an additional file that will contain the information that was discarded to generate the lossy .wv file. This file will have the same name as the .wv file but will have the extension .wvc (the 'c' is for "correction"). When WvUnpack is used to restore the .wav file, it will attempt to find the .wvc file in the same directory as the .wv file. If it is found then the decompression will be lossless and will be reported as such, otherwise lossy decompression will be reported (assuming that any information was actually discarded during the original compression). -- Ticket URL: <https://trac.ffmpeg.org/ticket/5407> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 7

#4331(ffmpeg:new): Wish: Lossless macroblock padding
by FFmpeg 15 Feb '22

15 Feb '22

#4331: Wish: Lossless macroblock padding ----------------------------------+--------------------------------------- Reporter: richfife | Type: enhancement Status: new | Priority: wish Component: ffmpeg | Version: unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ----------------------------------+--------------------------------------- Add the ability to pad video files losslessly by adding blank macroblocks around the edges. For TVs that have problems with overscan for instance. -- Ticket URL: <https://trac.ffmpeg.org/ticket/4331> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 4