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

#8792(avcodec:new): mpeg2video decode "end mismatch" errors and corrupted image output
by FFmpeg 18 Jul '20

18 Jul '20

#8792: mpeg2video decode "end mismatch" errors and corrupted image output ---------------------------------+-------------------------------------- Reporter: tmm1 | Type: defect Status: new | Priority: normal Component: avcodec | Version: git-master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ---------------------------------+-------------------------------------- Summary of the bug: I have an mpeg2 720p sample which fails to decode correctly with avcodec/mpeg12dec.c, producing visible corruption on the bottom of generated images. Using other hardware decoders, no such corruption is visible. How to reproduce: {{{ ffmpeg version 4.3 Copyright (c) 2000-2020 the FFmpeg developers built with Apple clang version 11.0.3 (clang-1103.0.32.62) configuration: --prefix=/usr/local/Cellar/ffmpeg/4.3_3 --enable-shared --enable-pthreads --enable-version3 --enable-avresample --cc=clang --host- cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librubberband --enable- libsnappy --enable-libsrt --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librtmp --enable-libspeex --enable-libsoxr --enable-videotoolbox --disable-libjack --disable-indev=jack libavutil 56. 51.100 / 56. 51.100 libavcodec 58. 91.100 / 58. 91.100 libavformat 58. 45.100 / 58. 45.100 libavdevice 58. 10.100 / 58. 10.100 libavfilter 7. 85.100 / 7. 85.100 libavresample 4. 0. 0 / 4. 0. 0 libswscale 5. 7.100 / 5. 7.100 libswresample 3. 7.100 / 3. 7.100 libpostproc 55. 7.100 / 55. 7.100 Input #0, mpegts, from 'https://tmm1.s3.amazonaws.com/mpeg12dec-err.ts': Duration: 00:00:00.52, start: 32081.276567, bitrate: 5539 kb/s Program 1 Metadata: service_name : Service01 service_provider: FFmpeg Stream #0:0[0x100]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, progressive), 1280x720 [SAR 1:1 DAR 16:9], Closed Captions, 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc Side data: cpb: bitrate max/min/avg: 80000000/0/0 buffer size: 9781248 vbv_delay: N/A Stream mapping: Stream #0:0 -> #0:0 (mpeg2video (native) -> wrapped_avframe (native)) Press [q] to stop, [?] for help Output #0, null, to '/dev/null': Metadata: encoder : Lavf58.45.100 Stream #0:0: Video: wrapped_avframe, yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 59.94 fps, 59.94 tbn, 59.94 tbc Metadata: encoder : Lavc58.91.100 wrapped_avframe [mpeg2video @ 0x7fd90200b400] end mismatch left=29 2 at 0 45 [mpeg2video @ 0x7fd90200b400] Warning MVs not available [mpeg2video @ 0x7fd90200b400] concealing 80 DC, 80 AC, 80 MV errors in B frame https://tmm1.s3.amazonaws.com/mpeg12dec-err.ts: corrupt decoded frame in stream 0 [mpeg2video @ 0x7fd90200b400] end mismatch left=30 3E at 0 45 [mpeg2video @ 0x7fd90200b400] Warning MVs not available [mpeg2video @ 0x7fd90200b400] concealing 80 DC, 80 AC, 80 MV errors in B frame https://tmm1.s3.amazonaws.com/mpeg12dec-err.ts: corrupt decoded frame in stream 0 frame= 31 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.51 bitrate=N/A speed=0.826x video:16kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown }}} The visual corruption can be seen in the bottom 16 pixels of mpeg12decframe-005.png as generated by this command: {{{ ffmpeg -i mpeg12dec-err.ts -map v -vframes 5 -y mpeg12decframe-%03d.png }}} A workaround is to disable the error as follows, which fixes the generated images: {{{ --- a/libavcodec/mpeg12dec.c +++ b/libavcodec/mpeg12dec.c @@ -1889,9 +1889,12 @@ static int mpeg_decode_slice(MpegEncContext *s, int mb_y, if (left < 0 || (left && show_bits(&s->gb, FFMIN(left, 23)) && !is_d10) || ((avctx->err_recognition & (AV_EF_BITSTREAM | AV_EF_AGGRESSIVE)) && left > 8)) { + /* av_log(avctx, AV_LOG_ERROR, "end mismatch left=%d %0X at %d %d\n", left, left>0 ? show_bits(&s->gb, FFMIN(left, 23)) : 0, s->mb_x, s->mb_y); return AVERROR_INVALIDDATA; + */ + goto eos; } else goto eos; } }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/8792> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 6

#8791(undetermined:new): Metadata will not copied over going from opus to mp4
by FFmpeg 17 Jul '20

17 Jul '20

#8791: Metadata will not copied over going from opus to mp4 -------------------------------------+------------------------------------- Reporter: Tupsi | Type: defect Status: new | Priority: normal Component: | Version: git- undetermined | master Keywords: opus, mp4, | Blocked By: metadata | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: I noticed that when I change containers and codecs for an audio file that for some combination the metadata gets lost in transit. For instance reencoding an audio file from aac (inside an mp4 container) to opus works fine, copying over all relevant meta data like album, artist, genre, date, title, comment, etc. e.g. ffmpeg -i input.m4b -c:a libopus -b:a 32k output.opus works, all meta is copied. ffmpeg -i input.m4b -c:a libopus -b:a 32k output.mp4 works as well, all meta is copied. Now if you copy the mentioned .opus above back into an mp4 container, the information is lost. ffmpeg -i output.opus -c:a copy newoutput.mp4 file runs fine (audio wise), but all meta is lost. No idea, which component is doing this, so I will leave that to you guys to change, sorry for that. How to reproduce:(you need the opus to have a few metadata like album, comment) {{{ % ffmpeg -i input.opus -c:a copy output.mp4 ffmpeg version git-2020-07-15-a54b367 built on with gcc 9.3.1 (GCC) 20200621 }}} Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8791> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#8798(avformat:new): SubViewer sbv to srt misses last caption
by FFmpeg 17 Jul '20

17 Jul '20

#8798: SubViewer sbv to srt misses last caption -------------------------------------+------------------------------------- Reporter: | Type: defect alexharrington | Status: new | Priority: normal Component: avformat | Version: git- | master Keywords: subviewer | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: ffmpeg 4.2, with patch applied from http://fftrac- bg.ffmpeg.org/ticket/8575 When converting from sbv to srt, the last caption in the source sbv file is not present in the output srt file. For example, the input: {{{ 0:01:48.079,0:01:54.880 and click to Log Out safely from your 0:01:51.880,0:01:54.880 session. }}} gives output {{{ 1 00:01:48,079 --> 00:01:51,880 and click to Log Out safely from your }}} How to reproduce: {{{ % ffmpeg -fix_sub_duration -i caption.sbv caption.srt ffmpeg 4.2 with patch as described above built on alpine-3.11 }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/8798> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

#8795(avformat:new): [Metadata] ID3 Lyrics are added as TXXX custom tags instead of proper USLT tag in MP3, etc.
by FFmpeg 17 Jul '20

17 Jul '20

#8795: [Metadata] ID3 Lyrics are added as TXXX custom tags instead of proper USLT tag in MP3, etc. -------------------------------------+------------------------------------- Reporter: blueset | Type: defect Status: new | Priority: normal Component: avformat | Version: | unspecified Keywords: ID3, lyrics | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: ID3 Lyrics are added as TXXX custom tags instead of proper USLT tag in MP3, AIFF (force ID3v2) and other formats. How to reproduce: {{{ % # Add lyrics metadata to an MP3 file % ffmpeg -i mp3.mp3 -map 0 -y -codec copy -metadata "lyrics=line 1\x0aline 2\x0aline 3\x0a\x0aline 4\x0aline 5" mp3out.mp3 ffmpeg version 4.3.1 Copyright (c) 2000-2020 the FFmpeg developers built with Apple clang version 11.0.3 (clang-1103.0.32.62) configuration: --prefix=/usr/local/Cellar/ffmpeg/4.3.1 --enable-shared --enable-pthreads --enable-version3 --enable-avresample --cc=clang --host- cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librubberband --enable- libsnappy --enable-libsrt --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librtmp --enable-libspeex --enable-libsoxr --enable-videotoolbox --disable-libjack --disable-indev=jack libavutil 56. 51.100 / 56. 51.100 libavcodec 58. 91.100 / 58. 91.100 libavformat 58. 45.100 / 58. 45.100 libavdevice 58. 10.100 / 58. 10.100 libavfilter 7. 85.100 / 7. 85.100 libavresample 4. 0. 0 / 4. 0. 0 libswscale 5. 7.100 / 5. 7.100 libswresample 3. 7.100 / 3. 7.100 libpostproc 55. 7.100 / 55. 7.100 }}} Inspect the `mp3out.mp3` file with other ID3 viewers/editors, it is seen that tag USLT is added by `ffmpeg` as a TXXX custom frame instead of a proper one. A proper USLT frame requires attributes like language and a content descriptor. The latter can be an empty string, while the former must a 3-letter language code. The language tag can be included as part of the input in the format of `lyrics-LANGUAGECODE` (e.g. `lyrics-eng`) like what is shown in the `ffprobe` output, or can be defaulted to `eng` for English or `und` for undetermined. ---- References: * [https://id3.org/id3v2.3.0 ID3 Specs] * [https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes ISO 639 language code list on Wikipedia] -- Ticket URL: <https://trac.ffmpeg.org/ticket/8795> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 1

#8747(undetermined:new): libswscale 4.3 crash if output buffer is not 16 bytes aligned for yuv2rgb conversion
by FFmpeg 15 Jul '20

15 Jul '20

#8747: libswscale 4.3 crash if output buffer is not 16 bytes aligned for yuv2rgb conversion -------------------------------------+------------------------------------- Reporter: melanconj | 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: With the 4.3 release, swscale now crashes if provided with an output buffer that is not 16 bytes aligned for yuv2rgb conversions. It used to work in previous releases. How to reproduce: {{{ #include <stdint.h> #include "libswscale\swscale.h" void main() { uint8_t* src = malloc(640*480); uint8_t* dst = malloc(640*480*4); if (((int64_t)dst & ~0xF) == (int64_t)dst) { dst += 8; // Ensure we are unaligned. Comment out to see it work } const uint8_t* srcSlice [3] = { src, src, src }; int srcStride[3] = {640, 320, 320}; int dstStride = 640 * 3; void *context = sws_getCachedContext(NULL, 640, 480, AV_PIX_FMT_YUV420P, 640, 480, AV_PIX_FMT_RGB24, SWS_POINT, NULL, NULL, NULL); sws_scale(context, srcSlice, srcStride, 0, 480, &dst, &dstStride); } }}} It seems to have been introduced by the SSSE3 codepath that was added in commit fc6a5883d6af8cae0e96af84dda0ad74b360a084. I also found ticket https://trac.ffmpeg.org/ticket/8532 that found the same issue as mine but with the input buffer, which was fixed. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8747> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 13

#8788(undetermined:new): Vorbis audio file doesn't play the same after seeking back to zero.
by FFmpeg 14 Jul '20

14 Jul '20

#8788: Vorbis audio file doesn't play the same after seeking back to zero. -------------------------------------+------------------------------------- Reporter: | Owner: dalecurtis | 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: Vorbis file only plays correctly the first time through, content is garbled after seeking back to zero. Seems some bug in vorbis decoder state. How to reproduce: - ffplay <file> - observe beginning of track is okay. - after high pitch shrieking, press left arrow until back at t=0. - observe beginning of track is now garbled Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8788> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 6

#8764(avfilter:new): Colorbalance filter overexpose
by FFmpeg 14 Jul '20

14 Jul '20

#8764: Colorbalance filter overexpose -------------------------------------+------------------------------------- Reporter: | Type: defect paulpacifico | Status: new | Priority: normal Component: avfilter | Version: git- Keywords: | master colorbalance | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: Since 4.3 release, colorbalance filter always overexpose picture. How to reproduce: {{{ % ffmpeg -i "image.png" -vf "colorbalance=rm=0.3" -f image2pipe - | ffplay - With pl=1 image is black and white. }}} Tested on FFmpeg 4.3 and git-2020-06-28-4cfcfb3 on Windows and Mac -- Ticket URL: <https://trac.ffmpeg.org/ticket/8764> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#4601(avcodec:new): jpeg2000: Support for image offsets is not implemented
by FFmpeg 13 Jul '20

13 Jul '20

#4601: jpeg2000: Support for image offsets is not implemented --------------------------------------+--------------------------------- Reporter: cehoyos | Owner: Type: defect | Status: new Priority: wish | Component: avcodec Version: git-master | Keywords: j2k Blocked By: | Blocking: Reproduced by developer: 0 | Analyzed by developer: 0 --------------------------------------+--------------------------------- {{{ $ ffmpeg -i p1_05.j2k ffmpeg version N-72797-g0916938 Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.7 (SUSE Linux) configuration: --enable-gpl --enable-libopenjpeg libavutil 54. 27.100 / 54. 27.100 libavcodec 56. 41.100 / 56. 41.100 libavformat 56. 36.100 / 56. 36.100 libavdevice 56. 4.100 / 56. 4.100 libavfilter 5. 16.101 / 5. 16.101 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 2.100 / 1. 2.100 libpostproc 53. 3.100 / 53. 3.100 [jpeg2000 @ 0x333c2c0] Support for image offsets is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [jpeg2000 @ 0x333c2c0] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel(a)ffmpeg.org) [jpeg2000 @ 0x333c2c0] error during processing marker segment ff51 [j2k_pipe @ 0x333b3e0] decoding for stream 0 failed [j2k_pipe @ 0x333b3e0] Could not find codec parameters for stream 0 (Video: jpeg2000 (JPEG 2000 no codestream restrictions), none): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options p1_05.j2k: could not find codec parameters Input #0, j2k_pipe, from 'p1_05.j2k': Duration: N/A, bitrate: N/A Stream #0:0: Video: jpeg2000 (JPEG 2000 no codestream restrictions), none, 25 tbr, 25 tbn, 25 tbc At least one output file must be specified }}} {{{ $ ffmpeg -i p1_05.j2k ffmpeg version N-72794-gdbbb31e Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.7 (SUSE Linux) configuration: --enable-libopenjpeg --disable-decoder=jpeg2000 libavutil 54. 27.100 / 54. 27.100 libavcodec 56. 41.100 / 56. 41.100 libavformat 56. 36.100 / 56. 36.100 libavdevice 56. 4.100 / 56. 4.100 libavfilter 5. 16.101 / 5. 16.101 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 2.100 / 1. 2.100 Input #0, j2k_pipe, from 'p1_05.j2k': Duration: N/A, bitrate: N/A Stream #0:0: Video: jpeg2000, rgb24, 512x512, 25 tbr, 25 tbn, 25 tbc At least one output file must be specified }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/4601> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 2

#8771(undetermined:new): nasm 2.15 generates lot of warnings when compiling ffmpeg.
by FFmpeg 12 Jul '20

12 Jul '20

#8771: nasm 2.15 generates lot of warnings when compiling ffmpeg. -------------------------------------+------------------------------------- Reporter: | Owner: dalecurtis | 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: nasm is more verbose on the warnings it's generating for misconfigured assembly code as of 2.15. So x86inc.asm generates lots of issues -- specifically the -w+error=macro-params-legacy warning. Here's a snippet of one of the warnings -- there are many more of the same type: ../../third_party/ffmpeg/libavcodec/x86/qpel.asm:88: error: improperly calling multi-line macro `SETUP_STACK_POINTER' with 0 parameters [-w+error =macro-params-legacy] ../../third_party/ffmpeg/libavutil/x86/x86inc.asm:555: ... from macro `PROLOGUE' defined here ../../third_party/ffmpeg/libavcodec/x86/qpel.asm:88: error: improperly calling multi-line macro `ALLOC_STACK' with 0 parameters [-w+error=macro- params-legacy] ../../third_party/ffmpeg/libavutil/x86/x86inc.asm:558: ... from macro `PROLOGUE' defined here How to reproduce: configure and build ToT ffmpeg using nasm 2.15 dav1d's x86inc.asm has fixes for this, but I was unable to merge them without breaking other pieces of code (specifically vf_overlay.asm and one more I don't recall (rv34.asm maybe?), so an expert will need to take a look. dav1d has the most recent version of x86inc.asm: https://code.videolan.org/videolan/dav1d/-/issues/343 https://code.videolan.org/videolan/dav1d/-/blob/master/src/ext/x86/x86inc.a… Fixes haven't quite made it to the x264 copy yet, but will probably be there soon: https://code.videolan.org/videolan/x264/-/blob/master/common/x86/x86inc.asm -- Ticket URL: <https://trac.ffmpeg.org/ticket/8771> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#8785(avfilter:new): af_loudnorm: Limiter does not handle new peaks in ATTACK/RELEASE states
by FFmpeg 12 Jul '20

12 Jul '20

#8785: af_loudnorm: Limiter does not handle new peaks in ATTACK/RELEASE states ----------------------------------+--------------------------------------- Reporter: slomo | Type: defect Status: new | Priority: normal Component: avfilter | Version: unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ----------------------------------+--------------------------------------- Currently the limiter would cause output with too high peaks if a new, higher peak occurs while inside the ATTACK/RELEASE states. These states don't check for any new peaks but simply reduce/increase the gain over the given window based on the previous peak / no peak being found before. This potentially causes clipping and did so when I tested my implementation. I've found this while porting the filter to Rust for a GStreamer plugin, the code of which can be found here: https://gitlab.freedesktop.org/gstreamer/gst-plugins- rs/-/blob/master/audio/audiofx/src/audioloudnorm.rs . This also contains lots of code comments for all the steps, which might be helpful to take over to the ffmpeg code too. My solutions to these issues might not be the best or most simple approach, but during my testing they worked so feel free to adapt them for the ffmpeg code. ATTACK happens over a 10ms window, RELEASE over a 100ms window and the peak detection uses a 10ms lookahead and returns the first true peak it found. ATTACK state: =================== This happens over a window of 10ms and the gain reduction is slowly increased until the peak that was detected (and is at the end of the window) would have exactly the configured maximum peak. Now what can happen is that during processing this window there is a new (higher!) peak after the end of the window (remember: 10ms window and 10ms lookahead for peak detection) that would require a steeper slope. We wouldn't detect this as no peak detection at all happens in ATTACK mode, and would let the peak through. So peak detection has to run, and once we're exactly 10ms before that higher peak the ATTACK state needs to be restarted with the steeper slope. A possible implementation for this can be found here: https://gitlab.freedesktop.org/gstreamer/gst-plugins- rs/-/blob/1730de6cea10cb73ff1ab882a8235d540bfa5061/audio/audiofx/src/audioloudnorm.rs#L924 See also the comments, there are a few tricky corner-cases to consider that also affect the SUSTAIN state. RELEASE state: =================== This happens over a window of 100ms, the gain reduction is slowly decreased until it is at 0 again. No search for a new peak inside this window or 10ms after it is performed, that means if a new peak is found during this window there are two possible cases a) New peak requires lower/equal gain reduction to the *current* gain reduction: in this case we have to switch back to SUSTAIN with the current gain reduction to ensure that this peak is reduced enough to stay below the configured maximum peak. A possible implementation can be found here: https://gitlab.freedesktop.org/gstreamer/gst-plugins- rs/-/blob/1730de6cea10cb73ff1ab882a8235d540bfa5061/audio/audiofx/src/audioloudnorm.rs#L1321-1331 b) New peak requires higher gain reduction: We need to go back to ATTACK mode, but we can SUSTAIN the current gain reduction until we're 10ms before the peak. ATTACK mode can start at the current gain reduction and go to the target necessary reduction as usual. A possible implementation can be found here: https://gitlab.freedesktop.org/gstreamer/gst-plugins- rs/-/blob/1730de6cea10cb73ff1ab882a8235d540bfa5061/audio/audiofx/src/audioloudnorm.rs#L1280-1319 -- Ticket URL: <https://trac.ffmpeg.org/ticket/8785> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5