May 2015 - FFmpeg-trac - lists.ffmpeg.org

#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

#4024(avcodec:new): VP9 crash
by FFmpeg 03 Nov '21

03 Nov '21

#4024: VP9 crash ----------------------------------+-------------------------------------- Reporter: kyh96403 | Type: defect Status: new | Priority: normal Component: avcodec | Version: git-master Keywords: vp9 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ----------------------------------+-------------------------------------- When decoding some webm file(video codec is vp9), crash is occur. -- Ticket URL: <https://trac.ffmpeg.org/ticket/4024> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#4048(avformat:new): segment: Handle WebVTT as per HLS spec
by FFmpeg 02 Nov '21

02 Nov '21

#4048: segment: Handle WebVTT as per HLS spec ----------------------------------+--------------------------------------- Reporter: 11rcombs | Type: enhancement Status: new | Priority: normal Component: avformat | Version: git-master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ----------------------------------+--------------------------------------- As per the [http://tools.ietf.org/html/draft-pantos-http-live- streaming-13#section-4 HLS spec]: {{{ Subtitle segments MUST be formatted as WebVTT [WebVTT] files. Each subtitle segment MUST contain all subtitle cues that are intended to be displayed during the period indicated by the segment EXTINF duration. The start time offset and end time offset of each cue MUST indicate the total display time for that cue, even if that time range extends beyond the EXTINF duration. A WebVTT segment MAY contain no cues; this indicates that no subtitles are to be displayed during that period. }}} This means that the segment (or HLS) muxer needs to handle two particular cases, when muxing WebVTT for HLS: 1. No frames exist during a segment's duration, so a blank segment should be written. 2. A frame spans two or more different segments, so it should be written in all of them. This behavior could be triggered by an option, or automatically when the underlying format is WebVTT. Relatedly, the WebVTT muxer should provide an option to write the X -TIMESTAMP-MAP header for HLS synchronization. -- Ticket URL: <https://trac.ffmpeg.org/ticket/4048> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 6

#4437(avdevice:new): AVFoundation recording has consistent intermittent frame drops
by FFmpeg 18 Oct '21

18 Oct '21

#4437: AVFoundation recording has consistent intermittent frame drops -------------------------------------+------------------------------------- Reporter: LordHDL | Type: defect Status: new | Priority: normal Component: avdevice | Version: git- Keywords: | master avfoundation | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- '''Summary''': 60 FPS screen capture on OS X results in intermittent drops every 5-8 seconds. '''How to reproduce''': Record a video with AVFoundation using `-framerate 60`. {{{ ffmpeg -f avfoundation -pix_fmt 0rgb -framerate 60 -video_device_index 3 -i “” -c:v libx264rgb -crf 0 -vf crop=426:240:507:339 ~/Desktop/avfoundation.avi }}} Additional notes: * I have a SATA 3 SSD; plenty of disk write speed. * The source does not drop frames during recording, only the video does. * The source frame rate is exactly 60 FPS. * The frame drops have a fairly consistent timing. * Recording the same source in Windows does not produce these frame drops. * Media players will report an average rate of around 57.13 (it varies). * The `-r 60` output option will of course force the rate to 60, but not prevent the frame drops. * Example recording: https://www.dropbox.com/s/0dthf652g644ldq/avfoundation.avi.xz?dl=0 -- Ticket URL: <https://trac.ffmpeg.org/ticket/4437> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 50

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

29 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

#4499(undetermined:new): Parse internal subtitles in realtime
by FFmpeg 16 Jun '21

16 Jun '21

#4499: Parse internal subtitles in realtime -------------------------------------+------------------------------------- Reporter: SubJunk | 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: When using FFmpeg to overlay internal non-SSA subtitles (like SRT) there is a wait time before transcoding while FFmpeg parses all of the subtitles into SSA format, before the video starts transcoding. In some cases (10+GB MKVs) it can take minutes for the initial extraction to complete. We have had reports of 3+ minutes. It would be great if it was done as it goes along instead, so that extraction/conversion process is spread out. How to reproduce: {{{ % ffmpeg -i input.mkv -filter_complex subtitles=input.mkv -c:a ac3 -c:v libx264 -f mpegts file.ts ffmpeg version N-69972-g6c91afe Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.9.2 (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-lzma --enable-decklink --enable-zlib libavutil 54. 19.100 / 54. 19.100 libavcodec 56. 25.100 / 56. 25.100 libavformat 56. 23.100 / 56. 23.100 libavdevice 56. 4.100 / 56. 4.100 libavfilter 5. 11.100 / 5. 11.100 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 1.100 / 1. 1.100 libpostproc 53. 3.100 / 53. 3.100 }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/4499> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 13

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

08 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

#4455(undetermined:new): Better dependency tracking for ffprobe FATE tests needed
by FFmpeg 21 Apr '21

21 Apr '21

#4455: Better dependency tracking for ffprobe FATE tests needed -------------------------------------+------------------------------------- Reporter: | Owner: Timothy_Gu | Status: new Type: defect | Component: Priority: normal | undetermined Version: | Keywords: fate unspecified | Blocking: Blocked By: | Analyzed by developer: 0 Reproduced by developer: 0 | -------------------------------------+------------------------------------- Right now, ffprobe tests uses `tests/data/ffprobe-test.nut`, which depends on `ffmpeg$(EXESUF)`. However, ffprobe tests are not disabled with ffmpeg is disabled, like when `--disable-avdevice` is passed. This leads to errors when testing ffprobe. There are two variants: http://fate.ffmpeg.org/log.cgi?time=latest&log=test&slot=x86_64-archlinux- gcc-disable-everything: {{{ GEN tests/data/ffprobe-test.nut /home/ux/fate/ffmpeg/tests/Makefile:47: recipe for target 'tests/data /ffprobe-test.nut' failed make: *** [tests/data/ffprobe-test.nut] Error 1 }}} http://fate.ffmpeg.org/log.cgi?time=latest&log=test&slot=x86_64-archlinux- gcc-disableavfilter: {{{ make: *** No rule to make target 'ffmpeg', needed by 'tests/data/ffprobe- test.nut'. }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/4455> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

#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